| ● | アーキテクトはスーパーマンのように思った。スーパーマンは数が多くないはず。今後、若い人がアーキテクトになるためにはどのようにすれば良いか？ |
| | ○ | 誰にでもなれるものではないので、単に人を集めて教育すれば良いというわけではない。アーキテクトというタイプの人種が必要で、それを使ってく体制、足を引っ張らない体制が必要。試験では適当な教育対象者を選べないので、それらしい人を選ぶことになる。アーキテクト育成教育は知識教育でない。組織の中で作っていくもの。 SESSAMEで考えたときには、国内にアーキテクトは1,000人程度で、その下にしっかしした中級技術者が10万人程度いることを想定していた。 |
| ● | 「心をこめて実行する」とあるが、現実にはスケジュール優先など阻害要因があり育たない。アーキテクトはマネジメント（トップ）と、どのように接していくべきか？ |
| | ○ | 自分一人で対処は難しい。上手に我慢すること。価値観の重要性をトップに分かってもらえるように、啓蒙することが必要。例えば今回のような別の場面で言い続けることも必要である。トップマネジメントに直訴し、圧力をかけてマネジメント変わってもらうこともできるが、短期的な効果しかない。ちょっと暴言かもしれないが、マネジメントが変わりそうもなければ、辞めてしまうというのもあり。 |
| ● | アーキテクトとは一流の技術者と思う。ソフトウェア開発のアーキテクトの場合、建築のアーキテクトのように担当する範囲を特定できない。ソフトウェア開発のアーキテクトには、すべてのことを期待するのか？ |
| | ○ | 当然ながら、狭い領域の専門技術まで一人ではカバーできない。狭い領域の専門技術については、それぞれの領域の専門技術者を集めてくれば良い。どこが重要かという勘がある程度働かないといけないので、その分野の技術の専門家でもないといけない。あとは、マネジメント力として、人を集めてきて組織で対応する能力が必要になる。上手に人を選んで、チームを作り、課題を定義し、進捗を管理できるということである。 |
| ● | オープンソースなど、設計書がないソフトを利用する場合が多い。オープンソースが再利用されている事実からすると、設計書が必要なコンテンツは再利用できないのではないか？ドキュメントがないプログラムを使うことを前提に何か施策やアーキテクト育成することを考えていないでしょうか？ |
| | ○ | 今回の発表ではホワイトボックスの設計の話はしていない。それらを利用するアーキテクチャレベルの話をしている。もちろん、中身の設計を書くかどうかの議論は別に必要だと思う。 |
| ● | ルールを単純にして制度を回すのは良いと思う。表記法を３つの図に絞った経緯は？少なくとも３つということか？ |
| | ○ | 昔からやってきたとおり、静的な構造と動的な構造がある。その中で静的構造図、タスク関連図、状態遷移図の3つの図を選択した。誰にでもできるようにまずは少なくとも3つの図は作るようにした。それ以外に必要なものは、必要に応じて作りなさいという方針にした。 |
| ● | 設計意図を残すのは、その3つの図で残すのか？文書で残すのか？ |
| | ○ | なぜそういう構造にしたかは残す必要がある。そのため構造の設計の前に、要求や目論見が必要である。アーキテクチャ設計のインプットとして要求、目論見、商品戦略があり、それらを部品との関係を示す図や文章を使って残している。 |
| ● | アーキテクチャ設計レベルの定義の中で、アーキテクトのレベル定義ではないと考えていいのか？ |
| | ○ | アーキテクチャ設計レベルと同じである。毎年変わっていくアーキテクチャを維持することも必要なスキルである。 |
| ● | アーキテクチャが既に存在している場合に、アーキテクチャを維持するだけのレベル定義はあるのか？ |
| | ○ | 崩れたアーキテクチャを維持することは想定していない。ソフトウェア構造が可視化できていないと、アーキテクチャが崩れているかどうかが分からない。 |
| ● | 教育内容について教えてほしい。応用研修の前に何か習得すべき前提はある？ |
| | ○ | 応用研修の前に、設計手法は知っていることが前提である。応用研修では、2日間かけて、3つの図を書けるようになる。実践研修では、3日間かけて、大きな製品を想定した演習を行う。最後は自業務の設計書を書いて発表をしている。 |
| ● | リファクタリングしているが、マネージャーや品質管理部は品質に不安があるので実施がなかなかできない。変更に不安を持つ人をどう説得するのか？ |
| | ○ | 結果を見せてしまうのが早い。結果を見ると自発的に直そうということになった。 3つの推進チームにすることで、あるチームがここを治すなら、別のチームはあそこを治すというようにお互いに牽制しながら進められていた。また、全て直すのではなく、枯れていて直さなくていいなど必要な部分だけに対応するという逃げ道も用意している。 |
| ● | リファクタリングによる品質（信頼性）への担保の仕方の工夫は？ |
| | ○ | 確かに、積極的な人はどんどん直してしまい、不具合を出してしまう。だから、今は事前にチームでレビューして、適度にブレーキをかけながら実施している。 |
| ● | アーキテクトへどれだけの権限の与えるかポイントだと思う。アーキテクトはプロジェクトチームの中に置くべきか、外（品質保証）に置くべきか？ |
| | ○ | どんな製品を作るかを自ら考えるのがアーキテクトだと思うので、外から力ずくというのはないと思う。 |
| ● | リファクタリングとアーキテクト活動を同時進行させたのがみそだと思う。上位方針と現場改善要望との調整の工夫は？ |
| | ○ | アーキテクトと改善チームの関係としては、アーキテクトが上位という感じではない。以前は10個ぐらいの改善施策がありアップアップしていた。今回はその反省を踏まえて３つのチームに分けて活動するようにした。チームごとにアーキテクトがバックアップ（支援）して、チームの中にいて一体の活動とした。 |
