BSA
共同で作業する †
マーケティング部門がアホで開発部門は彼らが招く面倒に耐えなければならない、というディルバートのマンガを私は受け入れず、マーキテクトとターキテクトは全体システムが目的を達成するよう共に作業すべきだ。しかし聞こえはいが努力する価値はあるのだろうか？
長年に渡りマーキテクトは開発チームにより作られたシステムの真の能力を過小評価または理解するのに失敗していることが分かった。ターキテクトまたは他の開発者と作業することで予想外のそして多くの場合喜ばしいシステム能力をマーキテクトに見せることができる。プラグインやAPIで拡張可能なシステムを作ること(拡張性については第8章参照)で、想像を超えた将来性を信じさせてくれる。
あるプロジェクトで既存のサーバ機能を改修する際、使いづらい古いアーキテクチャを使いやすいものにしたことで、必須ではなかった一般化によりマーキテクトが採用(tap)する新機能を生み出した。
別に無駄な金メッキ処理を提唱しているわけではない。クリエイターの視点からシステム能力を理解するのに失敗しているマーキテクトは貴重な潜在的な活用機会を失う。ターキテクトとの強力な関係を築くことにより、マーキテクトはすぐに豊かな想像力を活用できる。
ターキテクトのエネルギーは最も楽しく実際の顧客の実際の問題を解くことに向けられている。マーキテクトと密接な関係を維持することで、ターキテクトはこれらの問題を学習し、解決に動く。別にターキテクトが問題を解決したいとか解決することがクールだとか新しい技術を学びたいということを言ってるわけではない。直接の解決にはならないが前述の地図上に捕獲された深い問題について言っている。
次のセクションではマーキテクトとターキテクトの間の健全な協力関係を促進するのに有効な施策について記載する。
合意達成する †
プロジェクト管理の原則に関する合意と、結果として得られるプロジェクトを駆動する活動。様々な原則はいかなるプロジェクトを駆動でき、プロジェクトリーダーは具体的な手法を選択する。原則とテクニックとの間にはマーキテクトとターキテクトとの間に不必要な摩擦を引き起こす可能性がある。
多くのプロジェクトは「十分に良い」品質のアプローチで進めるが、時には人間の安全を扱うものはより厳密さを求められ、マーキテクトとターキテクトとの間に異なる原則を引き出す。良いでも悪いでもなく、ただ異なる。
マーキテクトとターキテクトが共同で働けるよう、ドキュメントスタイルからプロジェクト管理ツールまでの一連の原則に合意する。前述したようにこの合意は開発チームの文化的な要件を満たすためにも必要である。
データ利用可能にする †
マップや機能への見える化は非常に重要である。データが隠れていると、これまで述べてきた現状把握や将来計画のアプローチはどれも良くならない。イントラネットやLotus Notes、Swiki、Twiki、CoWeb?などのツールを使うこともあればシンプルにポスターをたくさん作るチームもあり、企業文化に依存する。真剣に可視化にこだわることはマーキテクトとターキテクトとの協力を確かなものにする協力なツールになる。
担当者のつぶやき †
- (マ|タ)ーキテクト間の可視化方法は色々ありそうなので聞いてみたい。エンタープライジーな会社に一番多そうなのは共有フォルダに置かれたExcel(&日付がついたファイル名でバージョン管理)？
みんなの突っ込み †
