JEITA

＜組込み系ソフトウェア・ワークショップ2012：資料室＞
日本の組込み系開発におけるアーキテクト
〜アーキテクトは何を解決するか〜

■ 講演の概要 ■
会場の様子
会場の様子

講演

開会の挨拶： ソフトウェア事業基盤専門委員会の活動について、ワークショップ2012の狙いと課題認識
基調講演： アーキテクト〜アーキテクトは何ができるのか？〜
事例講演1： ソフトウェアアーキテクチャ開発とは
事例講演2： アーキテクチャの定義から読み解く、アーキテクトに大切な３つのこと 〜ソフトウェアの過去と未来、そして現在を作る〜

1. 開会の挨拶：ソフトウェア事業基盤専門委員会の活動について、ワークショップ2012の狙いと課題認識
●ソフトウェア事業基盤専門員会の活動の出発点となった課題認識は、『擦り合わせなるものが日本の開発力の強みと言われているが、急激に増大している開発規模や短納期化の中で、「擦り合わせ」が強みになっているのであろうか』であった。
●この課題認識に基づいた2005年度から2011年度までの活動内容の要点と今年度(2012年度)の活動について報告した。2005年度からの3年間は「品質」をメインテーマに、 2008年度からの3年間は「開発スピードアップ」をテーマにしてきた。その活動を通して重要であったアーキテクトについて 2011年度から活動をしてきている。
●2010年度までの活動での課題やそれを解決するための提言では、「アーキテクチャ設計」が弱く、さらにそのための「アーキテクト」が必要であることが何度も出てきた。そこで2011年度から始まる3年間の活動では、このアーキテクトそのものをテーマにしている。このテーマで2011年度にワークショップを開催し、今年はアーキテクトに関するワークショップの2回目に当たる。今回のワークショップでは、「アーキテクトは何を解決するか」と題して、昨年度の議論を深堀するところから始めていきたい。
●以上からこのワークショップをスタートし、開発者視点に立脚して、組込み系ソフトウェア開発におけるアーキテクトについて、参加された方々との議論の中から明らかにしたい旨が当専門委員会委員長 五味氏より紹介された。
五味氏
JEITAソフトウェア事業基盤専門委員会委員長 五味氏（ＯＫＩ）


2. 基調講演：アーキテクト〜アーキテクトは何ができるのか？〜
●専攻はアーキテクチャ
　○アーキテクトの職種と能力について広い分野で研究している
　○幅広くできることを述べている
　○アーキテクチャのイメージを捉えて欲しい
●自己紹介
　○三菱電機で人工衛星を開発15年
　○輸送機を含むシステムのアーキテクチャ設計を担当
　○準天頂衛星システムのシステム設計
　○ほどよし信頼性工学
　○アーキテクティングラボ
　○ソフトウェア以外のアーキテクチャ研究
　○ISO/IEC 42010 日本の代表
●SDM研究科紹介
　○アーキテクトの職種と能力について広い分野で研究している
　○マルチディシプリンな問題解決出来る人を育てる
　○システムズエンジニアリングを基礎に拡張
　○3つの学
　　・システム学
　　・デザイン学
　　・マネジメント学
●アーキテクチャ
　○アマゾンで調べるだけで、ソフトウェア以外のアーキテクチャもいろいろ出てくる
　　　The art of systems architecting
　○定義
●宇宙開発での事例
　○人工衛星：部品点数多い70万点から100万点。グラム単価は金同等
　○こうのとり
　　・アーキテクチャ
　　・安全設計
●アーキテクトの能力
　○一番大事なのは、「多視点」
　○ある一つの事象も見る視点が変われば変わってしまう
　○ISO42010の視点
●いろいろなアーキテクチャ
　○保険金不払い・支払い漏れ問題
　○欲求連鎖分析
●新たな世界へ
　○異なるライフサイクルから、新たな価値を生む
　○システム全体の安全をどのように確保するか
白坂氏
白坂 成功　准教授(慶應義塾大学)

【Q&A】
Ｑ１．日本の政治の方向性も定まっていない。政治家のアーキテクチャはあるのか。直接、政治家を教えたことがあるのか。
Ａ．政治家を目指している人はいる。 アーキテクチャを理解した後は、それが大事だということがわかった。 アーキテクチャで全体像を間違うと大きな問題になる 役人の方々はアーキテクチャを理解した後は、きちんと理解している。
Ｑ２．ヒューリスティックスは大事だと思う。どうやって手に入れるのか。
Ａ．アーキテクトを育てる仕組みを作ることは大事 設計の幅は広いので、すべてのアーキテクチャを自動では出来ない。 無から産み出すことは大変なこと。経験、センスに依存している。 それは、教えることは出来ない。 大きな方向として、アーキテクチャの例や方向性、評価方法を知っていることは大事。 自分の経験を整理できるので、経験値の伝え方が変わってくる。 ベースの知識が必要。
Ｑ３．多視点という話があったが、会社でも多様性が大事だと言われる。 現在いる人間の多様性を確保するにはどうすればいいのか。
Ａ．SDMでは多様性を重視して人を取っている。 イノベーションとダイバーシティの関係。ダイバーシティを上げないとイノベーションが上がらない。 ハーバード・ビジネス・レビューで言われている。 会社の方針として、同じ事をしたいならダイバーシティを取らなくていい。 企業は気にしてイノベーションとダイバーシティの関係を受け入れる必要ある。 新しいことを産むには、ダイバーシティを増やす必要がある。意識的にやらないといけない。 異業種交流会などで、オープンレクチャで交流を増やす。待ってても出来ない。



3. ソフトウェアアーキテクチャ開発とは
●自己紹介
　○アーキテクチャの実態を追求・追究。
　○アーキテクチャを定義すると、ソフトウェアには重要なのはわかるけど、実態はわからないもの。
　○ネットワーク製品開発に携わる。
●アーキテクチャとは
　○アーキテクチャの良さは変化への対応力が良いもの。
　○アーキテクト=波平
　○コスト=フネ
　○変更容易性=サザエ
　○拡張性=カツオ
●アーキテクチャの目的
　○将来の変化に対して最小限のQCDとなるように予め設計等に仕込むこと。
　○特性の評価軸：再利用性が高いもの。
●事例紹介
　○崩れたアーキテクチャ
　○アーキテクチャが規定するのは外部。内部は規定しない。
　○設計ルールは全体に及びかつ予め仕込むもの。
　○アーキテクチャが崩れてしまう（崩してしまう）要因は、
　　・アーキテクチャの目的・構想が開発者に伝わらない
　　・目論見を理解できずに（意識せずに）インタフェースを変更してしまう
　　・コンポーネントの仕組み理解不足による狙いとずれた変更
●改善取り組み事例
　○防止への取り組み
　　・再利用戦略を明確化
　　・変更（可変性のアセット）
　　・禁則（想定できる変更方法に対してアーキが崩れるケースを例示）
　○崩れ防止のフォーメーション
　　・アーキテクトの役割を２分割
　　・方式アーキテクト（抽象化分割
　　・実装アーキテクト（具現化分割）
　○アーキテクトの育成
　　・本質は上級アーキテクトから。分割が肝。
　　・勘所は専門家から
　　・経験させる場の提供（プロマネが支援）
保土原氏
保土原 行彦 氏(富士通株式会社)

【Q&A】
Ｑ１．機能分割が本質という話。いいところだと思う。機能分割（目標を副目標に分割）は属人性が高い。その部分をセオリーする、方針を伝えるときの工夫はあるか。
Ａ．抽象化機能分割について答えを持っていない。常日頃悩んでいる。一緒にやらせることで経験をつませることがよいと思う。レビューや障害対応の現場で、自分の経験を引き出して教えていくくらいである。
Ｑ２．分割の話で分割の本質はおっしゃるとおり。分割の視点とそれを評価することが大事だと思う。分割が変わると評価関数が変わると思うがいかがでしょうか。
Ａ．MFLで分割しているが、評価は、最初の時点ではできていない。次の開発で評価ができる状態となり、その時に作ったときの評点が出来ればと思っているが、現状できておらず今後の取組になっている。



4. アーキテクチャの定義から読み解く、アーキテクトに大切な３つのこと〜ソフトウェアの過去と未来、そして現在を作る〜
●自己紹介
　○担当業務はソフト工学の導入推進。
　○EE1394 WDMドライバ開発。
　○業務用小型プリンタのアーキテクチャ設計。
●アーキテクチャとは何か
　○アーキテクチャはシステムの基本構造である。
　○何になぜ適合したか目論見で語りシステムの過去を示す。
　○方針を徹底しシステムを未来まで存続させる。
　○ソフトウェアの現在を設計方式で語る。
　○アーキテクトが過去から未来へ橋渡しする。
●コンポーネントと環境との関係
　○変化する環境にアーキテクチャを適合させる。
　○機能の進化にアーキテクチャが追いつかない。
　○アーキテクチャが崩れ単純さを保てなくなった。
　○動くプロトタイプを作って関係者を巻き込む。
●設計と進化を導く方針
　○アーキテクチャで束縛タイミングを決める（言語や手法ではない）。
　○設計の原則を定める。
　○データ抽象を活用する
　○MDD導入による制約で原則と方針を満たす。
●コンポーネント相互の関係
　○組みを抽象化する力をトレーニングする。
　○仕組みの抽象化には仮想性と透過性を使う。
　○常に関連から考える。
　○モデリングで抽象化力をつける。
●まとめ
　○アーキテクトは単純な仕組みに抽象化する。
萩原氏
萩原 豊隆 氏(セイコーエプソン株式会社)

【Q&A】
Ｑ１−１．御社の組込み商品開発において、ソフトウェア設計者がアーキテクトになるのか。
Ａ．実際には、全体設計する人はソフト屋だけではなく、システム全体としてしては、メカ・エレキ屋が多い。
Ｑ１−２．全体設計がうまくいかないことはないか。
Ａ．コミュニケーションがうまくいかないことはある。ただし、製品が出るくらいはきちんとしている。
Ｑ２−１．単純な仕組みで抽象化する問うことであるが、大きな目標を個別に分けたときに、組み合わせの問題はないか。
Ａ．単純な尺度としは、人間が理解できる尺度である7±2に分割すること。粒度が高いところと小さいところを分けて設計すれば問題はない。
Ｑ２−２．単純に分けても制御できるのか。
Ａ．システムは７つぐらいに分けていく事で対応できる。細かくなっているところは統合することもありえる。

©JEITA,2012