特別講義レポート-2012年度特別講義-
日にち |
特別講義タイトル |
講演者 |
---|---|---|
第1回 |
野中 誠氏(東洋大学) |
|
第2回 |
小谷田 一詞氏(日本自動車研究所) |
|
第3回 |
栗田太郎氏(フェリカネットワークス) |
|
第4回 |
ソフトウェア品質シンポジウム2012(会場:東洋大学/東京) |
|
第5回 |
安藤 昌也氏(千葉工業大学) |
|
第6回 |
細谷 泰夫氏(三菱電機株式会社) |
|
第7回 |
田村 泰彦氏(株式会社構造化知識研究所) |
|
第8回 |
榊原 彰氏(日本アイ・ビー・エム株式会社) |
|
第9回 |
分科会成果発表会 |
第1回特別講義 レポート
日時 |
2012年5月11日(金) 10:10~12:00 |
---|---|
会場 |
日本科学技術連盟・東高円寺ビル 地下1階講堂 |
テーマ |
「ソフトウェア品質技術研究~あなたを変える、組織を変える、社会を変える~」 |
講師名・所属 |
野中 誠氏(東洋大学) |
司会 |
SQiP研究会運営委員長 秋山 浩一氏 (富士ゼロックス株式会社) |
アジェンダ |
1. ようこそ、SQiP研究会へ |
アブストラクト |
ソフトウェア品質技術は、さまざまな「価値」を生み出す有用な技術です。すなわち、顧客にビジネス価値をもたらし、安心・安全な社会を実現し、組織の強みを増幅させ、そして、あなた自身の成長につながります。 |
<講義の要約> ◆ようこそ、SQiP研究会へ SQiPの「P」には、高度な教育訓練を受けた専門的職業を意味する「プロフェッション(Profession)」という語をあてている。ソフトウェア技術者は聖職者・弁護士・医師に次ぐ「第4のプロフェッション」となるべく自覚を持って行動する時期にきている。 SQiP研究会は、その先にある、SQiPシンポジウムや世界ソフトウェア品質国際会議(WCSQ)などの広範なソフトウェア品質活動への「入口」である。また、オープンイノベーションを起こせる場でもある。オープンイノベーションとは、企業内部と外部のアイデアを有機的に結合させ、価値を想像することである。ソフトウェア品質もオープンイノベーションが必要である。自社の取り組みや情報を社外には出せないため論文が書けない、という話を聞くが、取り組みを社外に出したところで、他社はそう簡単には真似できない。実際、組織に根付かせ、効果がでるまで長い歳月がかかる。研究会は外部のアイデアを得るよい場である。是非ベストプラクティスの共有をしていただきたい。 ◆ソフトウェア品質技術が生み出す「価値」 開発スピードを加速させるために、欠陥の検出・除去・混入予防に必要な活動を定義する。単にレビューやテストに時間をかけるだけではなく、そもそも設計をどうするか?を考えることで混入予防につながる。また、混入をさせてしまうメカニズムはいろいろなところにある。単に作りこみ過程だけでなく、組織体制などにも問題があるだろう。品質部門と開発部門の役割が分かれ過ぎていると、「あとはやってくれるだろう」と甘えがちになる。 この段階のテスト、レビューでは、どういう観点で行うべきだろうかを考えることも必要である。 価値提供の結果を評価し、欠陥に学ぶことで、意味のあるフィードバックができる。一連のフィードバックを積み重ねることで組織は賢く、強くなれる。賢く、強くなった組織は、幸せになる。 品質にしっかりと取り組めば、開発コストを下げられる。安易な品質コストの削減は、取り返しのつかないところまで組織能力を衰退させる。 ◆ソフトウェア技術者への期待:品質技術の研究 社会人心得には、発信力、傾聴力が大切であることと、柔軟性、情況把握力、規律性、ストレスコントロール力が必要であることが書かれ、技術者心得には、手と機械と心を一体化させることや、知識と智慧を身につけること、世界観を持つこと、心で現象を見ることの大切さなどが書かれている。 ソフトウェア品質技術・施策を研究するにあたり、「社会人心得・技術者心得」を心に留めてほしい。 ◆ソフトウェア品質技術研究の例:メトリクスの基礎と応用研究 しかしメトリクスは万能ではない。実世界で測定できることは、測定したい概念のごく一部にすぎない。メトリクスの限界を理解した上で“Informed decision”に役立てる。 測定には信頼性と妥当性が求められる。具体的には、信頼性は「誰が何度測定しても同じ結果が得られるか」、妥当性は「測定したい概念を正しく捉えているか」「意思決定や予測に役立つか」「測定したい概念を十分カバーしているか」が挙げられる。また、メトリクスを用いて何を評価したいのか、目的を意識すること。実体把握に用いるなら、目的によって要求される精度は異なる。予測や計画に用いるなら、精度は粗くてもよいが手順の再現性を重要とする。評価に用いるのなら、高い精度が必要となる。 上流工程までの欠陥除去率を評価しようとして、上流工程までの欠陥除去数を欠陥総数で割ると、上流工程での欠陥除去率が実際より低くなる場合がある。これは下流工程で混入した欠陥数も総数に含めてしまった結果である。下流工程で除去した欠陥については、混入工程を把握しておく必要がある。また、目標値を意識するあまり、実際の欠陥の粒度を変えて件数を増やし数字合わせをするというような、期待外れな行動にでてしまうことがある。欠陥の粒度のガイドラインを定めておく必要がある。欠陥を管理している組織は多いが、欠陥の粒度定義と測定精度の確認を行なっている企業は少ない。 欠陥の数え方は、組織によって様々である。また、欠陥1件の粒度について、IEEE標準やISO規格では特に言及していない。ここでソフトウェア欠陥1件の数え方の例を挙げる。開発プロセス全体で欠陥の粒度に一貫性をもたせ、欠陥除去工程のパフォーマンスを正しく評価したい場合、プロダクトの原因部分で集約して1件と数える。プロセス単位で集約してしまうと、何もかも1件として集約されてしまう可能性が高まる。あくまで見逃した欠陥はいくつか?を考える。 欠陥識別のタイミングをどこにするか?非公式レビューにおける指摘も欠陥数に含めるのか?欠陥識別のタイミングについて「原則」を定めることは難しい。 欠陥測定の信頼性を高めるには、開発プロセスと欠陥メトリクスを紐付けることも重要である。欠陥の混入と除去に関連するアクティビティを定義する。 欠陥の数を扱う前に考えなければならないことは、「何に関する欠陥なのか」と「どこまでを欠陥とするのか」である。欠陥には計算ミスなど現時点で修正が必要な機能性欠陥と、コードの読みやすさなど将来の機能性欠陥につながる発展性欠陥がある。欠陥除去のフロントローディングを議論するときは機能性欠陥に着目する。また、発展性欠陥は、早い段階で除去する。欠陥のタイプに応じて、どのタイミングで指摘し、欠陥除去するべきかを考えることが重要である。 DRE(Defect Removal Efficiency)は各工程またはプロセス全体の欠陥除去率で、欠陥除去能力の低い工程を特定し重点的に改善する目的で用いる。PDCE(Phase Defect Containment Effectiveness)はフェーズ欠陥阻止率(各々の欠陥除去工程で除去すべき欠陥をどれだけ除去できたか)で、見逃した欠陥に着目し、レビュー技法やチェックリストの改訂を行う目的で用いる。どちらも終わったプロジェクトに対して測定する。プロジェクト中に介入し判断したい場合、欠陥除去率の分母は予測値になる。 ソフトウェア欠陥数の予測に、欠陥数と相関の高い変数を用いて予測精度を高めることは可能であるが、因果関係の有無を確認しないまま用いている場合もある。なぜ相関が高いのかまで分析して用いることが大事である。 有用そうな変数について、箱ひげ図を描いて欠陥数に影響する要因を探ってみる方法もある。ただし、相関係数を高くすることにこだわりすぎて、変数の入れ替えに専念してしまってはいけない。 fault-prone(欠陥が含まれていそうな)モジュールの予測のイメージを説明すると、コーディング/単体テストが終わった時点で、ソースコードから測定可能なプロダクトメトリクスやプロセスメトリクスを用いて、機能テスト/システムテストで欠陥が見つかりそうなモジュールに対してレビューやテストの優先度/重要度を決め、効率/効果を高める。 欠陥修正の有無を何らかのメトリクスで予測する事例の紹介。 データ分析により、複雑度重み付き規模(WMC)、結合度(CBO)、凝集度の欠如度合い(LCOM)の3つの変数により、欠陥修正の有無を高い精度で予測できた。100%ではないが、どのモジュールに対し欠陥が発生したのか、ある程度説明できるものがでてくる。 メトリクスをとる上で大事なことは、分析をしたところから踏み込めること。レビューやテストなどのアクションや品質に繋げられること。そこから根っこのしっかりした議論ができる。 John Maynard Keynesの言葉に「精密に誤るよりも、漠然と正しくありたい」というものがある。メトリクスの取り組みで忘れてはいけない基本姿勢である。取り組んでいるうちに、精密に相関係数を見だしたり、相関係数が高くなることにこだわったりしてしまうが、それが狙いではない。あくまで「このメトリクスでこういうことが得られたから、ではこういうアクションを取ろう」という正しい意思決定に役立つことが目的である。 ◆質疑応答 Q. 欠陥の数え方について、重み付けがあると思う。もっと複雑ではないか? Q.マネージャに対して、メトリクスとは何なのか(メトリクスは何のためにとるのか)を、説明するには? <講義の感想> |
第2回特別講義 レポート
日時 |
2012年6月15日(金) 10:00~12:00 |
---|---|
会場 |
日本科学技術連盟・東高円寺ビル 2階講堂 |
テーマ |
「機能安全を切り口としたソフトウェア品質改善文化構築について」 |
講師名・所属 |
小谷田 一詞氏(日本自動車研究所) |
司会 |
阪本 太志氏(東芝デジタルメディアエンジニアリング 株式会社) |
アジェンダ |
1. プロフィール |
アブストラクト |
"ISO26262 is Japanese supplier killer!" これが、私の機能安全に対する最初の 印象でした。 |
<講義の要約> ◆プロフィール ◆機能安全との出会い ISO26262を最初に手に取った印象は「ISO26262 is Japanese Supplier killer」だった。 日本人にありがちな間違いとして、真面目すぎて手段が目的になってしまう点がある。ISO9000の時代にはQCD達成よりも如何に準拠するかが目的となってしまった組織は多い。その再来なのかと疑問が出てきた。 ◆VDA conference発表と日本での活動 ISOの成立ちを考える上で、日本と欧州における文化の違いを理解する必要がある。欧州は大陸と陸続きであり、他国からの侵略に備える必要が昔からあった。その備えが規格であり、対して日本は海に囲まれているおかげで侵略への備えを欧州ほど意識する必要がなかった。 また欧州においてはISO標準化委員会で決めたことを現場でパイロットプロジェクトとして展開し、そのフィードバックを返す協力関係が長年続いている。現場では機能安全文化が醸成され、プロセス改善の文化が定着しているため、アセスメントにも抵抗がない。 日本は規格を展開するだけでは上手く行かない、どう取り入れるか計画を立てて活動を進めて欲しい。 欧州に調査へ赴いたことで、ISO26262は「Japanese Supplier killer」でない事が分かった。ISO26262に対応するメリットとしては、国際標準に従った品質確保の活動による訴訟リスクの低減、またISO26262対応の部品を使用することによる自動車保険料の軽減などが挙げられる。今後欧州に商品を販売する際に必要な規格となるだろう。 ドイツではVDA指導の基に業界が動いている。また「ISO26262を実施する第一ステップは、SPICE活動である。」と明言し、業界をあげてプロセス改善活動を基礎とした活動が根付き、「Safety Culture」が形成されている。 日本に戻ってからは機能安全に関する講演を実施し、各社の要望や悩みを収集した。そこで出てきた悩みとしては、機能安全活動に対する認識不足や機能安全の前にSPICE活動が根付いて無いことなどが挙げられる。 機能安全への取組みにおける課題は2つある。1つは「Safety Culture」に対する虚弱性で、過去の商品開発実績に対する自負や個人レベルの頑張りに支えられた開発形態から、会社組織活動としての品質(QCD)改善文化が重要になってくる。もう1つは機能安全教育に対する脆弱性で、欧州コンサルタントの英語講義における非効率な通訳や教育コンテンツの不足などが挙げられる。 そこで日本の自動車業界の用語を使用したSPICE活動の考えを盛り込んだ教育コンテンツを開発するため、JARI(日本自動車研究所)に転職することとした。 ◆JARI activity 日本でISO26262に準拠する際の問題点について欧州の関係者に相談すると、日本は元々高品質の製品を開発しているのだから別に対応しなくてもよいのではないか、自分で工夫して新しく規格を作ればよいのではないかと返事が来た。だがISO26262を利用しない手はない、ISO26262に日本の文化を取り入れていきたい。 ◆日本の技術者に贈る言葉 なぜ計画を立てるのか、その理由は3つある。 2番目は次回のプロジェクト開発の計画策定を精度良くするためである。常に次の機会を考え、規模、工数、コスト、品質を計画時に見積もり、実績値との差異を分析する。見積もりの際は過去の類似プロジェクトを参考にすると良い。 3番目はソフトウェアプロジェクトの進捗管理に使用するためである。計画があることで実績と比較してずれを直ぐに認識することが出来る。またずれを認識するには数値で比較可能にする工夫が必要である。そのずれをどう埋めるかは進捗会議で決定する。 ◆質疑応答 A:日本と欧州とでは文化が異なり、日本では規格作成に向けて音頭を取る人が出てこない。それよりも既存の規格に対する日本の影響力を増加する方向に働きかけてみてらどうか。ISO26262も改訂中で、そこに日本の知恵を取り入れていく方が良いのではないか。 ◆感想 |
第3回特別講義 レポート
日時 |
2012年7月19日(木) 13:30~16:00 |
---|---|
会場 |
箱根ホテル小湧園 蓬莱 |
テーマ |
「チームビルディングの実践と理論 ~組織とコミュニケーションのモデリング~」 |
講師名・所属 |
栗田 太郎氏(フェリカネットワークス株式会社) |
司会 |
演習コースII 形式手法と仕様記述 主査 栗田 太郎氏(フェリカネットワークス株式会社) |
アジェンダ |
1. [簡単な解説] 「モデル」とは |
アブストラクト |
モデリングやコミュニケーション、チームビルディングに関する基本的なことがらを確認したあと、個人やチームでブロックを用いたモデリングを行いながら対話をしていくことで、自己紹介やチームビルディングを試行し、研究会におけるチームの形成と、ひとりではできないソフトウェアの品質確保に向けたコミュニケーションの重要性の再確認を行う。 |
<講義の要約> ◆「モデル」とは コンピュータ用語は、英単語本来の意味から比喩的に使われているものが多い。例えばCPU等に用いられる「アドレス」という用語は本来「住所」という意味だが、そこから「番地」というイメージを彷彿させることから、「番地」に相当するものに対し「アドレス」と呼んでいる。 ◆チームビルディングとその必要性 ◆[ワークショップ]手はじめ・手ならい/自己のモデリングと紹介 ワークショップはブロックを用いて行われた。まず個人演習から始まった。 ◆ シリアスプレイとは ◆ [ワークショップ]チームでのモデリング ◆ コンストラクショニズムとシリアスゲーム ◆チームビルディングとコミュニケーション <講義の感想> |
第5回特別講義 レポート
日時 |
2012年10月12日(金) 10:00~12:00 |
---|---|
会場 |
日本科学技術連盟・東高円寺ビル 2階講堂 |
テーマ |
「UX(ユーザエクスペリエンス)の考え方とアプローチ」 |
講師名・所属 |
安藤 昌也氏 (千葉工業大学 工学部 デザイン科学科) |
司会 |
金山 豊浩氏 ((株)ミツエーリンクス) |
アジェンダ |
・“体験”こそ製品 |
アブストラクト |
昨今、ユーザ体験を意味するユーザエクスペリエンス(UX)に関する議論が様々なところで行われています。確かに、よいユーザ体験を作りこみ、実現することは製品やサービスづくりの目標であることに異論がある人はいないでしょう。しかし、UXの捉え方によっては、よい製品づくりにつながらない可能性もあります。また、ユーザビリティとの違いにも混乱があるかもしれません。本講演では、UXに対する考え方を整理するとともに、具体的な製品・サービスづくりにおいて留意すべきポイントについてお話します。 |
<講義の要約> ◆前置き UXは定義を求めるより“観点”を理解することが重要である。世界のUX研究者が集まり基本コンセプトを整理した議論の成果を「User eXperience White Paper」にまとめた。その邦訳も「UX白書」で検索出来るので目を通しておいて欲しい。 もしUXについて専門的に学びたい場合は、以下の産業技術大学院大学の履修証明プログラム「人間中心デザイン」への参加を検討して欲しい。 ◆“体験”こそ製品 ◆サービス経済から経験経済へ 経験経済は製品購入にも大きく影響している。製品購入前の体験機会が少なかった時代は購入後に初めて製品を評価可能だったが、現代は口コミなどの擬似的な体験機会が購入判断に影響を与えている。 ◆様々な視点からのUX ・利用前:「予期的UX」(経験を想像する)→ 例:CMや口コミ ◆実利用の評価を左右する心理的要因~SEPIA法の視点 (1)ミニマム利用ユーザ(製品関与:低、自己効力感:低) (2)期待先行ユーザ(製品関与:高、自己効力感:低) (3)冷静・合理的利用ユーザ(製品関与:低、自己効力感:高) (4)マニアユーザ(製品関与:高、自己効力感:高) ◆UXとUXD 以下はUXDの議論を始める前に押さえておくべき三つの事柄である。 (2)消費者とユーザの連続性 (3)時間的・長期的視点 ◆UXは本当に上手くデザインできるのか? ユーザビリティの場合は、主な目的はトレーナーと同じ動きが出来るようになることで、その為にビデオの構成は段階的に上達できる教材としての役割を持つ。 UXDの場合は、主な目的はユーザ自身が決めるので、ビデオの構成はユーザの熟達度や気分に応じて目標を決められるように踊りの上手な人やそうでない人など様々な人物を登場させたり、飽きずに続けられる様に演出を工夫したりしている。 ◆UXDを小手先なものにしない3つのポリシー (2)アクティビティ指向でプロダクトを発想すること (3)ビジュアル・モーション指向でUIを発想すること ◆まとめ ◆質疑応答 A:まずその質問が出て来た背景を考えてみて欲しい。ユーザが「安全体験」を求めているか調査したことがあるだろうか? 先進運転支援システムの「EyeSight」は安全を可視化することで人気が出た。ユーザは安全を求めている。安全が可視化されていないことが潜在的なニーズで、求められている安全をどう経験させるか、そのデザインが求められている。 ◆感想 |
第6回特別講義 レポート
日時 |
2012年11月16日(金) 10:00~12:00 |
---|---|
会場 |
日本科学技術連盟・東高円寺ビル 2階講堂 |
テーマ |
「アジャイル開発における品質向上の取り組み-フレームワーク、プロセス、型-」 |
講師名・所属 |
細谷 泰夫氏(三菱電機株式会社) |
司会 |
SQiP研究会運営委員長 秋山 浩一氏(富士ゼロックス株式会社) |
アジェンダ |
1.アジャイル開発とは? |
アブストラクト |
ここ数年、ソフトウェア開発においてアジャイル開発が採用される事例が増加しています。 |
<講義の要約> 冒頭で、聴講者が3~4名のグループを形成し、「アジャイルと品質について知りたいこと」を共有し、中でも最も知りたいことを一つ付箋紙に記載した。その後、黒板を「タスクかんばん」にして、左側を「ToDo」右側を「Done」とし、左側(ToDo)に付箋紙を貼っていった。 ◆アジャイル開発とは? ◆スクラムの概要 プロダクトの品質が悪くなる原因の一つとして、階層式の組織とオーバーコミット(スコープに対しコストや期間がアンバランスな状態でのコミット)が組み合わさった時がある。 スプリントのスコープを器に例えると、器の大きさが見積りとなる。見積りは、ほとんど自動的に決まるのが理想である。器に対して「優先順位の高いストーリーから入れていく」「いつまでたっても終わらないと言って器を大きくしない(オーバーコミットをしない)」「見積りどおりチームが淡々とつくる」ほうがトータルとして効率がよいという考え方があり、それを破ることを徹底的に排除する。 フレームワーク、プロセス、型について、サッカーを例に解説すると、「ルールに従って行う」ことがフレームワークの部分であり、よいゲームをするにはプロセスや型が必要である。型は「ヘディングがちゃんとできるか」というような基本動作を示す。ソフトウェアで言えば「コーディング規約に基づいてプログラムができるか」「同値分割を適切に行えるか」といったものである。プロセスや型はチームメンバーのスキルによって変わってくる。 ◆型、プロセスの例 ◆アジャイルテストをプロセス、型という観点で考える ◆ドキュメンテーション ◆まとめ 最後に講演の振り返りとして、「ToDo」に貼った付箋の中で「すっきりとはいかなくても何かしら得るものがあった」事項について、付箋を書いたグループに問いかけながら軽くまとめ、「Done」に移していった。 <講義の感想> |
第7回特別講義 レポート
日時 |
2012年12月21日(金) 10:00~12:00 |
---|---|
会場 |
日本科学技術連盟・東高円寺ビル 2階講堂 |
テーマ |
「構造化知識の活用による設計不具合の予測と未然防止」 |
講師名・所属 |
田村 泰彦氏(株式会社構造化知識研究所) |
司会 |
阪本 太志氏(東芝デジタルメディアエンジニアリング(株)) |
アジェンダ |
1.不具合に関する設計知識の問題点と構造化の狙い |
アブストラクト |
設計変更により、ある品質特性が悪化し、設計開発でそれに気づけないために不具合が発生するということを私たちはしばしば経験します。このような不具合を防ぐ活動を効果的に行うには、変更点に関わる設計対象の機能・処理・構造上の関係知識、システムで生じる望ましくない挙動の知識が必要です。 |
<講義の要約> ◆本日の特別講義で説明する3つの話題 ■その1:不具合に関する設計知識の問題点と構造化の狙い 不具合に関する記録を、今後の未然防止や再発防止の活動に再利用するためには、不具合情報をどう活かすかという観点で記録しないと情報共有や知識伝承が上手くいかず、以下の問題が発生する。 不具合に関する知識の構造化とその運用の狙いは以下である。 ■その2:不具合に関する構造化知識の獲得方法 1, 知識の分節性 2,知識の一般性 3,知識の関係性 ◆構造化知識の抽出イメージ ◆SSM(Stress-Strength Model:ストレス-ストレングスモデル) SSMの知識分節は以下で表現している。 また発生要因を新たな不具合モードとして、関連する構造化知識の抽出作業を行っていく。 ◆不具合モードの発生メカニズム 1,相対的因果メカニズム 2,絶対的因果メカニズム 3,断片的因果メカニズム ◆不具合の因果連鎖の知識構造 例:リレーの接点障害 ・知識分節(2)(知識分節(1)のストレス要因を不具合モードとして表現) ・知識分節(3)(知識分節(2)のストレス要因を不具合モードとして表現) ◆ソフトウェアSSMの基本構造 2,開発プロセス業務上の知識 ■その3:不具合に関する構造化知識の活用方法 ※その他、活用ツールとしてSSM master を紹介していた。 ◆QA 質問2:知識構造化の具体例についての情報は何処を調べればよいか? 質問3:ある項目の内容を記述する必要がない場合でも、不要な理由を書いておかないと後日問題にならないか? 質問4:DBの作成は誰がどのタイミングで行うのが適切か? ◆感想 |
第8回特別講義 レポート
日時 |
2013年1月18日(金) 10:00~12:00 |
---|---|
会場 |
日本科学技術連盟・東高円寺ビル 2階講堂 |
テーマ |
「ITアーキテクチャ設計とITアーキテクトの着眼点」 |
講師名・所属 |
榊原 彰氏(日本アイ・ビー・エム株式会社) |
司会 |
SQiP研究会第3分科会主査 細川 宣啓氏(日本アイ・ビー・エム株式会社) |
アジェンダ |
1. アーキテクト、アーキテクチャそしてアーキテクティング |
アブストラクト |
本講義ではITアーキテクチャ設計の基本からはじめ、アーキテクトの思考法、使いこなすべきテクニックを解説する。また、ITアーキテクチャ設計がより効力を発揮するために、ITの視点のみならずビジネス的な観点からの最適化、講演者が現在取り組んでいるスマーター・シティ施策におけるアーキテクチャ設計の位置づけまでを論ずる。 |
<講義の要約> ◆アーキテクト、アーキテクチャそしてアーキテクティング ソフトウェアやシステムで一般的に言われることであるが、アーキテクチャは目に見えないため、アーキテクチャ記述を書くことで目に見えるようにする。アーキテクチャ記述を読みやすくし、物事を明確に共有するために、モデル(共通のルールで表現されたもの)を用いる。
アーキテクトとは、アーキテクティング(アーキテクチャを構築する活動)を実践し、アーキテクチャを構築するプロフェッショナルを指す。 ソリューション・アーキテクチャとは個々のアーキテクチャの集合であり、ビジネス・アーキテクチャ、アプリケーション・アーキテクチャ、配置(データサービス/アプリケーション)、インフラストラクチャ・アーキテクチャ等が含まれる。また例えば企業社内において複数のソリューション・アーキテクチャがつながりを持つ様に全社的にまとめたものがエンタープライズ・アーキテクチャである。 ステークホルダーとは、「システムに関して興味または関心事を有する個人、チーム、組織(IEEE Std.1471-2000)」である。アーキテクトがアーキテクチャ記述する事でステークホルダーの関心事を根拠付ける事が出来る。関心事を細かく分けるとビューポイント(特定の視点)になる。ビューポイントをもとにビューを作成する。 変更の難しいアーキテクチャに関しては開発の初期段階で意思決定を行う必要がある。しかし最初の時点では実際のシステムは存在せず、少ない情報の中でアーキテクチャ上の意思決定を行わなくてはならない。そのために過去の情報収集やパイロットプロジェクトでの検証が必要となる。また、決められたチェックポイントで再評価を行い、いかに段階的・継続的にリスクを減らしていくかを考える。 ITアーキテクトが押さえるべき4つのアプローチは以下である。 ◆ITアーキテクチャの構築 ビューとは、「関連する一組の関心事の視点からシステム全体を表現したもの(IEEE Std.1471-2000)」であり、ビューポイントとは「ビューを作成し、使用するための約束事の詳細仕様(IEEE Std.1471-2000)」である。また、ビューポイントとは「ビューの目的や利用者を明確にして、それぞれのビューを作成するためのパターンもしくはテンプレートであり、それらを作成し分析するためのテクニック(IEEE Std.1471-2000)」である。 一般的にビューに基づいてダイアグラムが描かれる。しかしこのダイアグラムそのものがモデルではなく、ダイアグラムで表されるものがモデルである。複数のダイアグラムで一つのモデルを表すことも、一つのダイアグラムが複数のモデルを表すこともある。 ビューポイントには要求ビューポイント、機能ビューポイントといった、独立した基本ビューポイントと、セキュリティービューポイント、パフォーマンスビューポイントといった、基本ビューポイント全体に対する横断的ビューポイント(パースペクティブ)がある。基本ビューポイントと横断的ビューポイントの組み合わせにより必要な成果物を決めて作成に取り掛かる。 アーキテクチャの構築対象となるシステムの特徴により、作業時に重点をおくところは異なる。従ってアーキテクチャ記述で重要なのは、メリハリをつけたアプローチである。具体的には、既知のベストプラクティスの適用や未経験の領域への挑戦、先進技術の適用などには重点を置く必要がある。例えば新しい技術を取り入れるならばどこでリスクを解消するか、ということも記述する。また、採用した技術についてその選択根拠を記載することもある。 アーキテクチャは多様な側面から設計する必要がある。例えば家を建てるための設計図は平面図や外観図など複数必要になる。システムも同じである。全体をいかに「切り分け」て、いかに「組み合わせ」るかが重要となる。また切り分けることで各アーキテクトに設計を割り振ることが出来る。アプリケーションアーキテクトは機能モデル、インフラアーキテクトは配置モデル、データアーキテクトはデータモデルを成果物(ワークプロダクト)として作成する責任を持つ。これらのモデルをまとめ、リードアーキテクトは成果物としてアーキテクチャ評価、アーキテクチャ上の判断、アーキテクチャ概要、アーキテクチャ構想実証、ソフトウェアアーキテクチャ文書などを作成する。 アーキテクチャの機能的側面を表現するときにはコンポーネントをベースとして考えると良い。コンポーネント設計においては、いくつかの重要な設計原則があり、Open-Closed Principle(「(モジュールは)拡張に関してして開いており、修正に関して閉じていなければならない」というBertrand Meyer氏が提唱した原理)や、GRASP( General Responsibility Assignment Software Patterns:汎用責務割り当てパターン(5つの基本パターンと4つの応用パターンを定義している))などが挙げられる。 ITアーキテクチャ設計の手順としては、まず概念モデルから設計し、詳細モデルへ、そして物理モデルへと落としこんでいく。それぞれ機能的側面と稼働的側面があり、両者に対しNFR(非機能要求)の考慮が必要になる。 アクティビティには要件定義アクティビティとアーキテクチャ作成アクティビティ等がある。 例えば、予約システムを対象として具体的に各アクティビティを説明すると以下の様になる。 アーキテクチャ構成の基本原則として以下の4つの事項が挙げられる。 アーキテクチャの稼働インフラ側面を表現する際に、インフラ設計の抽象化を行う。プロキシやサーバ、クライアント等はノードと呼ばれる。ノードはロケーション(本社、視点、データセンターといったものが含まれる)に配置される。ロケーションにはゾーニング(内部ネットワーク、外部ネットワークなどといったゾーン分け)がある。ノード間にはコネクション(二重化させる、迂回させる、などのつなぎ方)がある。
このような稼働インフラ・アーキテクチャを表現するモデルとして、オペレーショナル・モデルがある。オペレーショナル・モデルとは、システムのユーザーや関連する外部システムとシステムの構成要素及びその配置や相互の関係を表現した、新システムの全体像を示すものである。 このようにすべての設計に対し、筋道をたてて根拠を示すことが、アーキテクチャ構築の最重要課題である。言い換えればアカウンタビリティ(説明責任)を重要視するのである。 ◆ITソリューションの構築手法決定 IT構築は基本的に手探りで進むため、実装終了間近まで要求の実現可能性を確信しづらい。Standish Group "Chaos Report 2007"によれば、プロジェクト成功率は28%である。このような背景から、ITソリューションの構築手法の選択はリスクヘッジの組み込みでもあると言える。リスクヘッジの手法には、プロトタイピング、モデル駆動型開発、反復型開発プロセス、スモールリリースと継続的インテグレーション、ビジネスプロセス・モデリングとシミュレーション等があり、軽減したいリスクに対応した手法を選択することが肝要である。 ◆ ITソリューションの最適化
最適なソリューションを生むために必要なものとして、ドメイン知識、実現技術を選択するための知識、問題分析とパターン化の知識(要求工学プラクティス)が挙げられる。 ◆ビジネス戦略・課題の領域からIT領域まで ◆ニュー・パラダイムへの挑戦 ITが進みすぎて、企業システムの価値や求められる優先順位が変化している。QCDというキーワードの時代は過ぎ去りしものとなり、フォーカスされなくなっている。近年はAgility(連続的な変化への柔軟かつ迅速な対応)が必要とされてきている。更に将来は Dynamic / Optimization(動的な最適化)が必要になるだろう。 技術の変化に追随しつつ、技術の断片に惑わされない原則を身につけることが、アーキテクトの醍醐味である。 <質疑応答>
Q:リードアーキテクトは、ドメイン知識の他にどのようなスキルが求められるか?
Q:バージョンアップによりアーキテクチャが崩れていくことや、ビジネスのアジリティに追いつけないことがある。新しいものを導入するのが良いかこれまでのものを利用するのが良いか悩むこともある。どうしたらよいか?
Q:アーキテクトは成果物に対しフィードバックを受けて評価するということだが、具体的にはどうするのか?
Q:ITアーキテクトの評価をするガイドラインはあるか?
Q:ビジネスモデルに対する発想を広げる前に、説明能力を鍛えることが必要か? <講義の感想> |