小野 和俊
株式会社アプレッソ 代表取締役副社長 CTO
 |
ITアーキテクトが判断しなければならない重要な点の一つが，システムにどのような技術やアーキテクチャを採用するかということです。技術やアーキテクチャは「システムの要件が同じなら必ずこれが良い」というものではなく，開発チームのメンバー構成によって判断が変わってきます。
私はITエンジニアの性質は，“風林火山”で分類できると考えています。今回はこの分類の内容と，それを踏まえた上での技術やアーキテクチャの選択方法について考えてみたいと思います。
エンジニア“風・林・火・山”
私が考えるITエンジニアにおける“風林火山”とは，次のようなものです。これは以前ブログで紹介したことのある分類で，私が今日に至るまで出会ってきた様々なエンジニアの性質を，武田信玄の“風林火山”になぞって分類してみたものです。
| 分類 | 能力 |
| 風のエンジニア | 迅速な設計/実装によってチームを加速させる風のエンジニア。風のエンジニアがいない開発チームでは，ほかに先駆けて新製品やサービスをリリースすることが困難になる |
| 林のエンジニア | 突発的なトラブルが発生しても冷静に対処し，チームに乱れぬペースを提供する林のエンジニア。林のエンジニアがいない開発チームはトラブル発生時に何をすべきかの正確な判断を行えず，混乱に陥りやすい |
| 火のエンジニア | 新しい技術/方法/ツールの積極的な導入によって，チームや成果物の競争力を高める火のエンジニア。火のエンジニアがいない開発チームは同じやり方を繰り返すことはできるが，進歩する機会が少ない |
| 山のエンジニア | 厳密なエラー・チェックと堅牢なプログラミングによって成果物の安定性を高める山のエンジニア。山のエンジニアがいない開発チームは常に品質の低さからくる不安にさいなまれる |
最近知人からもらったメールで，こんなケースがあります。「システムで使用するJDKのバージョンを最新版にしたい」と社内の開発チームに提案したところ，ちょっとした言い争いが起きたというのです。提案したエンジニアは，最新版のJDKでは従来のバグが修正されており，新機能も搭載されているのでそれを使いたいと考えたわけです。
だがこの企業では，開発に使用するJDKのバージョンについての厳しい規約があり，JDKの安定性を重視すべき（＝規定しているJDKを使うべき）だという指摘を受けたそうです。最新版のJDKを使えば，新機能に新たなバグが含まれている可能性があり，従来版と異なる点の理解に時間を取られてしまう，という理由だったそうです。
これは言ってみれば，山のエンジニアが集まっているチームに，火のエンジニアが飛び込んで火消しをされてしまった例です。
別の例では，開発環境やツールの新バージョンがアナウンスされるたびに，最新版の新機能の恩恵を少しでも早く受けようとβ版から積極的に新しいものを使用した結果，“枯れていない”ツールの不具合や非互換機能に悩まされて開発効率がかえって低下してしまったというケースもありました。
このケースは，火のエンジニアばかりが集まったため，山のエンジニア的な視点が抜け落ちてしまい，新旧の技術を選択するバランスがうまくとれなくなってしまった例です。
“風林火山”マトリックスが重要な二つの理由
この“風林火山”マトリックスは，プロジェクト・マネージャがチームの特性を可視化するときに用いたり，個人が今後の自分のスキルセットを考えていくときに用いたりするもので，本来ITアーキテクトが使うものではありません。今回ITアーキテクトのブログであえてこのマトリックスを紹介したのには，二つの理由があります。一つめの理由は，冒頭に書いたように，技術やアーキテクチャの選択は，チーム・メンバーによって変わってくるからです。
例えば，火のエンジニアと風のエンジニアは，一般的な傾向として，その新規性や開発スピードと引き換えにテストやドキュメントの網羅性を犠牲にしがちです。もし開発チームに風林火山マトリックスを当てはめてみた結果，風と火のエンジニアばかりだったなら，テスト・ケースの自動実行を徹底し，開発の最中に何かこれまでと動作が変わるところがでてきそうなら，テスト・ケースの自動実行で検知してすぐにメールなどで通知する。このような仕組みを盛り込みやすいように，アーキテクチャを設計していくことが望まれます。
逆に，開発チームが山のエンジニアや林のエンジニアを中心に構成されていた場合，テストやドキュメントといった守りの部分については安心感が得られるので，新技術の採用などの攻めの開発の部分に少し重心を移してアーキテクチャを設計すると，プロジェクト全体が適度なバランスになることもあります。
二つめの理由は，選択した技術やアーキテクチャによって，チーム・メンバーの風林火山マトリックスを変化させていくことがあるからです。
筋力養成ギブスのような感覚で，山の開発チームにあえて火の要素の強い技術を導入してみたり，逆に火のチームにテスト関連のフレームワーク導入を徹底してみたりすることで，風林火山のバランス感覚を刺激します。
そうすることにより，今まで新しいことに着手しようとしなかったチームの中に新技術を導入しようとするメンバーが出てきたり，これまで短い期間での新規開発を重視していたチームに，テストやドキュメントといった守りの部分を強化していこうとする動きが出てきたりすることがあります。
そして，このような変化は往々にして開発チームの成果物のクオリティをより高いものにします。こうした変化は，現在のチームの性質と異なるベクトルを持ったメンバーがチームに参加することで自然と発生することもありますが，開発チームの各メンバーの性質を見ながら，意識的かつ戦略的にバランスを変えてみることも可能です。融合するITアーキテクトとプロジェクト・マネージャ
まだ，プロジェクト・マネージャ向けの話ではないかと思っている読者の方もいるでしょう。そういう面があるのは確かですが，こうした視点は，これからのITアーキテクトにとって無視できないものになっていくのではないでしょうか。私は，プロジェクト・マネージャとITアーキテクトは，どこかでやがて融合していくのではないかと考えています。
かつて，プログラマとデザイナとが別々の職業であったのが，Ajaxをはじめとした今日におけるインタラクティブなインタフェースのデザインにはプログラミングとデザイン双方のスキルが必要になってきたのと似ているのかも知れません。
チームの性質を分析した上でアーキテクチャを選択するのはもちろんのこと，アーキテクチャがチームを成長させるようなシステムの設計というものは，今でも意識的に行っていくことができますし，これからそうしたケースが増えていくのではないかと思っています。
|
