田中 洋一郎
株式会社エーティーエルシステムズ

　システム開発は，「ナイスショットを連発する」ことではなく，「ミスを最小限に食い止める」ことが大事です。では，どうすればミスを最小限に食い止めることができるのでしょうか。また，そこにおいて，ITアーキテクトの果たす役割とはどのようなものでしょうか。筆者なりの考えをまとめたいと思います。

複雑さがミスを生み出す

　考える材料として，「ITシステム」を取り上げます。ITシステムを単純にとらえれば，入力された情報を加工した後で出力します。こうとらえると，システム開発という作業も同じようなものといえるでしょう。入力に当たるのは，顧客が考える“欲しいシステム”。それをプログラミングという加工を施し，実際に稼働するシステムという出力を作ります。

　ただ，システム開発とITシステムでは，入力・加工・出力の複雑さに大きな違いがあります。ITシステムは，決められた入力情報を決められたルールで加工し，決められた出力を行うものです。システム開発はそれほど単純ではありません。人間が曖昧に表現した入力情報を扱いますし，加工方法も複雑です。

　ITシステムを引き合いに出したのは，システム開発は間違った出力をすることがあります（顧客が欲しいシステムではないものを作ってしまう）が，ITシステムは入力に対して正しく出力するからです（バグがなければですが）。

　つまり，システム開発でミスが起きるのは“複雑”だからといえるでしょう。人間は曖昧な情報を扱うことができるという特性を持ちますが，半面，間違いを冒しやすいという性質もあります。複雑さが増すにつれてミスを犯す確率も飛躍的に増えてしまいます。

　システム開発において複雑さを回避するには，各個人が担当する問題領域を明確にしたり，各個人の作業をできるだけ簡単にします。そうしたことを，要求分析，設計，開発，試験，不具合管理，品質確認，進捗把握，そしてリスク分析など，考えられるすべての作業において実施します。複雑なものをそのまま扱うのではなく，担当者が扱うときにはできるだけ単純化し，結果として複雑なものを作り上げるということです。複雑な命令セットで頭打ちになった「CISC CPU」に代わり，「RISC CPU」は単純な命令セットの組み合わせで処理効率を上げることに成功した，ということがありましたが，それと同じようなことです。

　システム開発の全工程において複雑なものを単純な作業にする。この役割を担えるのは「ITアーキテクト」しかいないと思います。ITアーキテクトはシステム開発のすべての作業にかかわり，ある担当者が生み出した情報（例えば設計書）を別の担当者が入力として使用する（例えば設計書からプログラムを書く）という加工作業すべてを把握します。

　そして，各担当者が解決すべき問題領域をできるだけ小さくし，作業内容の定型化と均一化を行って，仕事の仕方自体を各担当者に考えさせないようにします。こうすることは，生産性向上と品質確保の近道といえます。

標準化と単純化は別物

　複雑なことを単純作業にする際，そこには何らかのルールが生まれます。ですがそのルールを，「全社的な標準化」ととらえてはいけません。

　特に大手SIベンダーで盛んに行われてきた標準化策定と案件への適用は，うまくいっているという事例を見たことがありません。こうした標準化は一見，“銀の弾丸”のように感じますが，やはりシステム開発は，ドメインに特化した手法をその場その場で編み出していく，つまり目の前の開発に最適化された定型化および均一化を考えていくべきです。

　標準にこだわり続けると失敗する――ということは，きっと読者の方も経験から理解できることだと思います。目の前のドメインに最適な手順・手法を見いだし，作業の進捗と共に変化させていくことを怖がらないことが重要です。

　ここでポイントとなるのは，どこまでITアーキテクトによる作業手順・手法の策定を深くするか，ということです。極端にいえば，

・ITアーキテクトが成果物（＝情報の入力と出力の形式）を規定し，実際の仕事の仕方は各チームの自主性に任せる
・ITアーキテクトが成果物と仕事の仕方の両方について規定し，各チームの自主性を排除する

のどちらかを選択することになります。プログラム言語に例えるならば，ITアーキテクトがオブジェクトのインタフェースのみを決めて実装クラスの作成は完全お任せにするか，ITアーキテクトがオブジェクトのインタフェースと実装クラスの設計までやってしまうか，という違いです。

　これは，各チームを構成するメンバーのスキル，実際の作業の複雑さの度合い，案件の規模，さらに進捗および品質管理の厳格さのレベルといった要因すべてを考慮して決定すべきことであり，一概にどちらが正解といえるものではありません。一般的には，小規模なプロジェクトであればあるほど前者（自主性に任せる），大規模であればあるほど後者（規定する）という傾向があるようです。

　個人的な見解としては，管理が非常に難しくなることを承知の上で，やはり各チームの自主性に任せたいと思います。自主性に任せたうえで，それを最大限発揮できるようにITアーキテクトが導いている。そういうふうにプロジェクトを運営できたらと日々考えています。

　少なくとも，ITアーキテクトは「成果物の形式」と「作業の流れの中での各チームにおける成果物の入出力」を決める必要があります。これは，オブジェクト指向の設計手法に似ているという印象を持っています。つまり，「変化に強いアーキテクチャ」は「変化に強い開発プロセス」とほぼ同等であるということです。

　プロジェクトに必要な設計・実装・管理を，三つそれぞれで考えるのではなく，一つの見方の応用で考えてシンプルさを保つことは，ITアーキテクトという役割でなければできないことであり，ITアーキテクトとして最も面白く感じることだと思っています。