構造（アーキテクチャ）ってなんだろう？

■ このセッションについての説明
司会進行　川口(以下:川口):
	最初に，システムやハードソフトを語るときに，その構造がしばしば大きな意味を持ちますが
	その言葉の意味が人によってまちまちです．
	そこでこのセッションでは構造の具体的な整理を試みたいと思います．

	さらに，それを踏まえて，良い構造悪い構造の議論ができればいいな，と考えています．

	パネラー紹介（名前と所属）
	赤星（ロジックリサーチ）
	奥村（ナレッジエッジ）
	杉浦（富士ゼロックス）
	橋本（ＳＯＮＹ）
	コーディネータ　川口

■ 議論の前提・ゴール
川口:	議論の前提１

	構造は対象があり，それをモデル化したものとします．
	ここでは，構造とアーキテクチャは同義とする
	今回は対象を組み込みシステムに限定します．（システムとはハードとソフトを含む）

	前提２

	利害関係者を使って，構造の作用を説明します．
	対象とその構造があったときにその周りにいる人として，
	発注者，こういうものを作ってという人
	開発者，受注したらこの人が作る
	ユーザ，対象の組み込みシステムを使う人
	を定義します．

	例えば，HDDプレイヤなら，発注する人，開発する人，使う人(消費者)，がいます．

川口:	議論のゴール

	構造によってもたらされる，ユーザ，発注者，開発者にとっての嬉しさを整理します．

	議論の流れですが，
	まず，モデル化に関する議論．何をモデル化しているのか，構造の利用に関する議論をします．
	これは，簡単には出てこないでしょうから，構造というものがあったときに，各々がどのようにそれを利用するのか？
	ということを議論します．
	また，構造を外からみてみます．
	５Ｗ１Ｈで定義できれば，構造のいい悪いが分かってくるはずです．

■ パネラー自己紹介

杉浦:
	ハード屋です．プログラムは書くけどソフトウェアではないです．
	何をやっているかというと，ハードの設計をしています．
	昔はＮＥＣで動作合成ツールを作っていました．
	今は，ＳＯＣとかその中の一部のハードウェア設計をしています．
	その上でのアーキテクチャの話をします．

	現状どんなアーキテクチャがあるか？
	例：パワーマックＧ４
	(PowerMac G4の内部アーキテクチャの図がプロジェクタに映し出される)
	(図を指しながら) 効率パフォーマンス重視でアーキテクチャを構築している事が分かります．

	実際に私が設計しているものだと，SOCアーキテクチャというものがあります．
	CPUやDSPとかメモリ，カスタムハードがあってそれをバスで接続しています．
	これを我々は一般的にハードのアーキテクチャと呼んでいます．
	このアーキテクチャの評価基準は，性能，コスト，設計期間，面積，電力，信頼性，，，などの順であると考えていきます．

	カスタムハードウェアの中のアーキもあります．
	これは自由度が高く，アプリに応じたアーキテクチャとなります．
	だけど，考えることはさっき(の評価基準)と全く同じです．
	
	今までの話をハード屋の中でまとめてみると，アーキテクチャとは
	「機能を実現+日機能要求をどれだけ満足するかの評価を行う」
	「非機能要求をバランスよく満足させること」
	かな．

橋本:
	アーキテクチャとはなんだろうじゃなくて，なんに使うのだろうという話をしたいと思います．
	ハード・ソフトに関係なく，上流の観点で議論したいです．

	簡潔に言えば，与えられた仕事を整理整頓する道具．整理した結果がアーキテクチャではないか，
	と考えられます．
	これにより，お客さんが知っておく必要がある事，自分たちがやりたい事，というものが分かります．
	「こういうモノを作る，こういった仕事をする」という説明の仕方が，そのものの構造なのではないかと思います．

赤星:
	私は橋本さんと逆方向のです．
	セットメーカなのでこてこてのところから考えます．
	だから現実に役に立たないものはアーキじゃないという観点で話しをさせていただきます．

	例えば，T-Engineの100年ソフトというのは良いアーキテクチャか？
	坂村先生の話を近くで聞くとその凄いオーラで思わずそれを信じてしまいますが，
	これは正しいのでしょうか？
	コンピュータ産業自体が誕生してから100年にも満たないのに，
	そんな予測ができるのでしょうか？仮に予測してもあまり意味はないでしょう．

	現場側の話をします．
	アーキや制御対象にも寿命があるといわれています．
	アーキがＯＳをたたき始めたりする．
	採用技術の変化や要求の変化にともない，アーキを無視した実装が行われることになります．
	これはアーキ自身に問題があるのではないかと．

	あるべきアーキテクチャとはなんでしょう．
	ハードを含めたシステムアーキテクチャには，技術の進化や進歩に柔軟に対応できる仕組みがほしいです．
	要素に変更があった場合に，その要素ごとに交換可能な仕組みを持つべきで，
	さらにアーキ自身の問題を解決できる仕組みを持つべきです．
	故障していたら自分で回路をつなぎなおす仕組みみたいな．
	こういった事故修復ができるのがいいアーキテクチャと思います．


奥村:	ソフトウェア開発の人です．
	最近，うち社内でもプロセスの改善．保守の改革が叫ばれています．
	こういう面でもアーキが非常に大きく影響を与えます．
	アーキは単体では評価しても意味がない，というかできません．
	もともとアーキテクチャというよりは商品です．
	だからアーキテクチャというよりいい商品をはやく安く出すのがメーカーの目的です．
	つまりそれを実現するアーキテクチャが大事．
	そういった商品を限られた時間やマンパワーでどうやって作り出すか，それを実現するのがアーキテクチャです．
	こういった方針にアーキの良し悪しは依存すると思います．
	
	アーキテクチャに影響を与える要素について．
	なぜオブジェクト指向を採用するか？をお客さんに説明するのですが，伝わらない事があります．
	カスタマを納得させる事ができるアーキテクチャがほしい．
	
	ソフトとハードのアーキテクチャの違いを考えるとき，ソフトはハードと違って目に見えない事があげられます．
	動的に動くものを静的に表現するのがソフトウェアです．
	そこでモデリングが重要になってきます．

	アーキテクチャの再利用について．
	たくさんの似たような商品を出しているが，それらの製品は厳しい競争にさらされている．
	ばらばらに開発していたらいけない．
	だから商品ごとに別々のアーキテクチャを使うのではなく，再利用が効くようにしなくてはなりません．

	組織戦略によるアーキテクチャへの取り組みについて．
	自分たちの商品はどういうものか，どういうものが登場してくるだろうか？どこに力を集約していけばいいのか
	それを考えると作るべきアーキが分かってきます．
	どのようなものが必要か，どのような改良が必要が必要かを考えます．
	そういったそこを読み間違えると余分な機能ができてしまいます．

	プロダクトラインの導入と成果について．
	アーキテクチャを明文化することのメリットとして，設計仕様書などを外注できることがあります．
	ただし，組織としての連携がないとせっかくよいアーキテクチャができても組織間で再利用できません．
	
自己紹介・パネル終了

川口:	ぱっときいた印象では，
	橋本・奥村　⇒　ビジネス・組織とか
	他　　　　　⇒　ものづくりからの視点
	という印象を受けました．

	これからも分かるようにアーキに対する認識が人によって広いですね．
	体系的に整理できるか分からないけど，議論してなんらかの結果が出ればいいな，と思います．

	それでは
	構造がモデル化するものは何？
	ということを議論していきます

	これは，ビジネス・ものづくり派で変わらないとおもうのですが…

橋本:	これから作りたいものをモデル化する
	システムにやらせたいこと・システムがこんなんであってほしいな，というものをモデル化する

川口:もっと具体的にいうとどんなもの？
	一言で！

橋本:	難しいねえ


杉浦:	何かを持ってきて一部をモデル化するということ．
	ハードの場合は，明らかにその時に箱を書くんですね．
	細かい機能を持った箱に分けてつないでやろう，
	それぐらいの意識でハードはやってるんだと信じています．

	ソフトは動的に動くものを静的に．
	ハードは動的な部分はないので，こうやって箱をつなげてやれば終わり．
	箱が増えたりしない．
	20個動かしたかったら20個箱を書くしかありません．

	ハードウェアのアーキテクチャは，ソフトウェアのサブセットで考えられるかもしれない．

川口:	それに関して異論はないですね＞奥村さん

奥村:	箱に分けるということと，その箱の意味というものは一緒ということは違うでしょう．
	箱に名前をつけることまでがモデル化では．

橋本:	複雑なものを抽象化して単純化して議論するための道具だと思っています．
	抽象化して目に見えるものになるということは大きなメリット．
	モデリングするにしても，全てのことを書くんじゃなくて単純にして議論する．
	アイディアをほかのものに広める．
	最終的なモデリングだけじゃなくて，スナップショットをほかのひとにみせるのも大事なこと．一種の成果．

川口:	箱に関しては異論はないか？

橋本:	ないけど，ただ，ソフトは複雑ですから単純化してやるのが大事だと思います．

杉浦:	作る立場からアーキテクチャ，ここでいう組み込みシステムはハードもソフトも箱が出てくる．
	それをどうやって表現するか？どうやってつながりを表現するか？
	ソフトとハードのパーティショニングの議論が必要ではないでしょうか．
	それをはずして議論すると一般論になってしまい，僕としてはつまらないなあ，と．
	もっと組み込みアーキに限定して議論したい．

奥村:	アーキテクチャというのは，
	ひとつめの段階としては上から見たい
	という段階がある．
	構造を垂直に見るのではなく，上から見るのがアーキ？
	それでハードソフトどちらで実装するのがいいかを考えていく．

川口:	モデル化に関しては結論がでたので次にいきます
	そういうモデル化をするメリットデメリットを整理していきます．

	まず，メリットは？
	・複雑なものを抽象化して単純化する・可視化
	これ以外には？

奥村:	可視化で数えられることが嬉しい．
	要素を一覧として数えられる．

川口:	漠然としたものが計数化できる要素になる，ということですね．

杉浦:	可視化によって発注者と開発者の間で分かり合える．信頼関係が生まれる．

川口:	困ることは？

橋本:	別に無いとおもうんですが，アーキテクチャは所詮モデルなので，整理した結果にすぎません．
	モノには直結せず，モデル化工数のオーバヘッドが増えます．

川口:	機能要求が表現しにくいと思うのですがどう思いますか＞橋本さん

橋本:
	なんらかの形でみんなモデル化はしていると思う．（モデリングしないと開発できない段階にきている）
	複雑化して作れないからモデリングしているわけで，それ以外の意味はない
	モデルを作るのが目的じゃないから，再利用したいとかそういった付加価値がないのなら
	最低限のモデルだけを作ることにしている．

川口:	次，構造の利用について

会場の方:
	アーキテクチャのメリットデメリットの話で，
	アーキテクチャ自体のメリットデメリットがあると思う．

	利点→例えば作業分担ができる．
	けど使うと型にはまってしまうというデメリットがあるのではないかと思う．
	そこらへんをどう柔軟に対処していくというか
	他にアーキテクチャを出すことによるメリットはないのか？

川口:これは５Ｗ１Ｈのなぜ利用するか？にあたると思います．
	
	なぜ利用するか？
	なんでもいいので，意見はないですか？

橋本:	アーキというのは組織の戦略によってどうなるべきか，ということについて．
	型にはめるということは，方針を与えるということ．
	ボトムアップ的なものは無理があります．
	型にはめるというのは組織がこうやると決めることです．
	ラインとかそういうところに柔軟性は必要がないのでその方が，開発スピードが上がります．
	これからはお客さんにスピードと品質のトレードオフを提案する事になります．
	
	開発者アセットチームと実際にセット開発チーム，フィードバックするチーム．
	これだと散発的な再利用にしかならない．結局複雑にモデル化しても誰が使うのという話になる．
	
	・発注者はいつ利用
	プロセス最適化のとき・型にはめるとき

	蛇足だけど，ソースのコピー＆ペーストは許されない．全てに修正しなくてはいけないから．アセットは必ずひとつで．
	コードはアセットでしか管理しないようにする．

川口:	組織への業務の割込み（強いデシジョンが必要）が必要，ということですね．

	開発者が利用するもの

橋本:	ホットスポット，フローズンスポット
	変わりそうなところ，換わらなさそうなところをわかるようにするために使う

	余分な可変性はいらない．こういうところを構造から知りたい．

赤星:	この機能をどうやって実現するかを考えたとき，どこに可変性があるかということを知りたい．
	それがハード・ソフトの切り分けにもつながる
	とはいっても可変性のみで切り分けるわけではなく，性能要求によって変わる

	コードレス電話で，ちょっとずつ仕様を変えるような場合，変わる部分はハードで作ると毎回チップを作ることになるので，
	あらかじめ可変部を知っておきたい．


？
	発注者はなぜりよう
		再利用の効果がどこに出るかを知りたい

杉浦:	発注者はなぜりよう
		拡張できるところをしりたい．
		精度の高い計画が立てられる　　⇒開発者に関しても同様のことがいえる

ユーザにとっては効用があるのでしょうか？

杉浦:	接続性の話になります．このせいひんはこういうＯＳで動かしているからつながるんだよというのがユーザの購買基準になっているのかもしれない．
	型にはまっていることで操作性があがる．
	構造を練ることで商品性があがる

ＨＤＤレコーダについて４に聞いたらあまりにもあれですかね

橋本:	一般のユーザが興味を持ってそれを知りたいとか，こちらからアピールしたいとか，そういうことをソフトウェアに関しては感じられない．
	ハードで具体的なスペックが出ると売り文句になるのですが．

奥村:	基本的はユーザ視点からはなにもないと思う．
	品質要求としてインパクトがある．
	接続性は，箱の分け方のの良し悪しによるかも．

杉浦:	もし車のブレーキングシステムがＭ社のＷなんとかだったらその車を買いたくなるでしょうか？
	型にはまっているからといって買いたくなるわけではないと思います．


川口:	構造の何を利用する？
	発注者・開発者が利用するもの
	箱の開発希望

奥村:	箱同士の接続の難しさを表現する．開発難易度を表現したい．

川口:	箱の中の難易度は？
	それはレベルを下げるとわかってくるもの？
	モデル化を進めると難しい部分が分かってきたりするか？

赤星:	箱の切り方でラフに見積もることはできると思います．
	これは危険そうだ，とかこれはできる，といったことはある程度分かります．

	わからないものはしょうがないので，さらにそこを詳細に検討していくしかないです．

川口;	分からないというのはいままでやったことがないということ？

赤星:	そういうことです．

川口:	分からない率はどれくらいのものなのですか？

赤星;	僕の感覚だとほとんどわかります．直感で．
	なぜかというと，分かる仕事を取ってきているからです（笑）

川口:	自分のドメインがわかるということですかね．

赤星:	自分がぜんぜんわからないものがありました．
	そういうものは箱をかなり詳細に切っていかないと分からなかったです．

川口:	規模とか難易度が分かるということですね．

会場　要求者がつかんでいる仕様と開発者がつかんでいる仕様が違うのではないか
	リバースエンジニアについては？

杉浦:	ドメインの構造知識からリバースして要求を抽出できるのでは

橋本:	ユーザも自分でどういう製品を出したらいいかわからない場合もあるので，
	こちらから提案させていただくことも多々ある．

杉浦:	現場まで足を運んでいると（密な関係を築くと），いやがおうにも要求が分かってくる．
	そういう分かる人がポリシーになってお客さんとコミュニケーションを取っていく必要がある．

奥村:	お客さんとは，信頼関係があります．
	「あの人がいないけど今回は頼んで大丈夫みたいなの？みたいな」
	こういった目に見えない構造(?)もある．

川口:	スキル標準のようなことができれば，よいのですね．

	最後に

会場の方:
	期待していたのが良いアーキテクチャ悪いアーキテクチャ，そういう話だったのですが，時間がなくてそこまではいかなかったので，
	何か一言，答えは無理だと思いますが，直感や経験から一言ずつお願いします．

赤星:	要求がきちんと反映されていれば良いアーキテクチャだと思います．
	たいてい失敗しているのは反映されていない．

奥村:	アーキテクチャは分かりやすい表現が大事．
	判断基準がないと良し悪しがいえないが，やはり常識はあります．
	単純に要素単位でみて理解できるかが良いアーキかの判断基準となると思います．

杉浦:	利益を供与するのが良いアーキテクチャ．
	エンジニアサイドからいくと，抽象的過ぎますが楽しくなるほうが良い．
	理解しやすいほうが良い．無駄がないほうが良い．誰にでも受けいられるのが良い．
	感覚としてきれいに見えなければ，いいものとはいえない．
	いいものは開発者が何をどうしようとしているか発注者がわかる，信頼関係を築きますが，
	反対に，悪いものは開発者が何を考えているのか発注者がわからず，信頼関係を壊します．

橋本:	今までのパネラの内容がそのものだと思います．
	ハードミドルアプリなど，それぞれのレイヤがあり，
	そのレイヤーごとに可変性拡張性があり，
	それぞれ並行に開発できるようなもの．
	また，それぞれに暗黙知がある．
	それを共有できるようなパターンを持つのが優れたアーキテクチャといえると思う．

川口:	終わりがない議論でしたが，また今度時間をとってやりたいな，と思います．