アーキテクチャ・ジャーナル

アーキテクトが必要ないということはない!

Joseph Hofstader
2008/10/20
Page1 Page2 Page3 Page4

「ザ・ホーマー」を作らないこと

 有能なアーキテクトが持つすべてのスキルをもってしても、多数のオプションを絞ってソフトウェア ソリューションで使用するものを決定するのが難しいということはよくあります。特定の領域で定義されている標準規格、ソフトウェア システムの概念化に代わる方法、多数の技術的オプション、および拡張性と再利用を促進するための多数のパターンとの間で板挟みになって、堅牢なソフトウェア システムよりはアルファベット スープに似た盛り沢山のソリューションを設計してしまうことはたやすいことです (図 5)。

図 5: アルファベット スープを作るアーキテクト

 ソフトウェア システムを簡素化するための第一のステップは、新しい技法やテクノロジを試すのがどんなに楽しくても、それはシステム要件のコンテキストで応用されなければならないということを理解することです。私が『Design Patterns』を読んだ後で設計した最初のシステムにはその本の中で定義されていたパターンのほとんどすべてが入っていたのは偶然ではありません。何度か苦い経験をした後で、要件を満たす最小限のテクノロジを使うというミニマリズムのアプローチがいつも最良の結果をもたらすということを学んだのは何年も経ってからです。

 私がソフトウェア ソリューションを設計するときによく思い出す「ザ・シンプソン」のエピソードがあります。そのエピソードでは、頭のあまり良くないホーマーという名前の父親が、自動車会社に車の設計を頼まれます。ホーマーが設計した車は、全体のコストも客受けするかどうかも考慮せずに、複数のクラクション、ドリンク ホルダー、毛足の長いカーペットのような必需品以外のものを満載していました。その試作車は、「ザ・ホーマー」と名付けられましたが、コストがあまりにも高く客受けしないその製品のおかげで会社は倒産してしまいます。ソリューションを設計するとき、またはソリューションの設計を評価するとき、私はいつも、その結果できる製品が「ザ・ホーマー」に似たものになってしまわないかどうか頻繁に自問します。答えがイエスなら、必要不可欠な機能とそのソフトウェア システムを完成するために必要なテクノロジにもう一度はっきりと焦点を合わせます。

短い話を長くすると…

 2 か月ほど前に、顧客側のイベントでプレゼンテーションの出番を待っていたとき、そのイベントに Microsoft からアーキテクトとして参加していた開発者に紹介されました。「はじめまして、どうぞよろしく」といった普通の挨拶を期待していたところ、開口一番「アーキテクトは過去のものだと思います」と言われて驚きました。プレゼンテーションの出番を前にして議論に巻き込まれたくなかったので、にっこりと笑顔を作って「そうじゃないことを期待したいですね」と答えておきました。

 以来、思いをめぐらし、開口一番なぜあのような発言をする必要を感じたのか、いろいろ考えてみました。あの日は虫の居所が悪かったのでしょうか。アーキテクトに苦い経験をさせられたことがあったのでしょうか。ソフトウェア開発でのアーキテクトの貢献に気付いていないのかもしれません。彼のソリューションは、堅牢なソフトウェア ソリューションの構築に必要な配慮を理解する必要がないほど優れたアーキテクチャに基づいていたので、開発要員は機能要件のコード作成とテストの心配をすればいいだけだったのかもしれません。

 貧弱なアーキテクチャに基づいたプロジェクトは成果が上がらす難渋するか、お粗末な結果で終わることになります。一方、よくできたソフトウェア ソリューションは、領域の知識があって、概念的な思考ができ、技術的な洞察力があって、問題解決にパターンを利用する能力がある人によって構築されたしっかりしたアーキテクチャに基づいています。この役割に対する業界での肩書きには、アーキテクト、テクニカル リード、その他いろいろありますが、この役割の重要性ははっきりしています。私たちは、この役割の重要性について議論するような時間の無駄遣いは止めて、テクノロジを駆使して問題を解決することに専念すべきなのです。End of Article

【参考資料】

著者について

Joseph Hofstader : Microsoft Developer and Platform Evangelism
組織に所属するアーキテクトです。デンバー大学の Information
Technology and Electronic Commerce ( 情報技術と電子商取引) 学部で非常勤教授も務めています。Microsoft に入社する前は、Avaya 社の主要技術要員として活躍していました。通信業界でソリューションのアーキテクチャ、設計、開発などに携わってきた経歴を持っています。コメントは までお寄せください。


 

 INDEX
  [アーキテクチャ・ジャーナル]
  アーキテクトが必要ないということはない!
    1.アーキテクトは何者なのか
    2.問題空間で求められるアーキテクトのスキル
    3.ソリューション空間で求められるアーキテクトのスキル
  4.アーキテクトが注意しなければいけないこと

インデックス・ページヘ  「アーキテクチャ・ジャーナル」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間