稲村 創
株式会社モンスター・ラボ 最高技術責任者

　私は以前SIベンダーに所属し，Web系システムのソフトウエア・アーキテクチャを設計，開発していました。正直に打ち明けると，そのころはシステムの設計や開発と比べ，運用や保守をあまり楽しい仕事だと考えず，そうした仕事を避けていたと思います。こんなことを書くと怒られるかもしれませんが，ITアーキテクトを志す人には，そういう方が少なくないのではないでしょうか。

　現在は音楽配信サイトのベンチャー企業を立ち上げ，自分たちで設計・開発したシステムを自分たちで運用・保守する立場になりました。そしてやってみて，私は心底ガックリしました。ほかでもない，自分の設計にです。本エントリではこの経験を基に，「ITアーキテクトと運用・保守」について，考えをまとめたいと思います。

　まずは，ちょっとまどろっこしいかもしれませんが，ITアーキテクトと呼ばれる役割の仕事について，レストランのシェフに例えて少し想像しながら考えてみたいと思います。ひと口にITアーキテクトといっても幅広いですが，ここではSIに携わる，一般的（最も想像されるという意味です）なITアーキテクトを指していると考えて下さい。

ITアーキテクトとシェフ

　あるパーティーの料理を任されたシェフは，おそらく提示された要求に基づいてメニューを考えることから始めるでしょう。システム構築におけるITアーキテクトの仕事でいうと，機能要件や非機能要件に基づいてハードウエアの構成や採用するソフトウエア技術を選定し，設計することに当たります。

　メニューが決まれば材料の調達と下ごしらえ。このあたりからシェフだけではなく，シェフの下で働く料理人たちも参加するようになります。この仕事は，開発環境の構築とプロジェクトのフレームワーク作り，プロトタイピングといったところでしょうか。

　準備が整ったら，いよいよシェフの指揮の下で調理が始まります。シェフの指示に従って料理人たちが調理することもあれば，大事なところではシェフが自ら腕を振るう場合もあります。適切な順序で，できるだけ無駄が無いようにチーム・プレーで料理を作り上げていきます。この調理フェーズは，システム構築でいえば開発フェーズ。料理人はプログラマに近い感じがしますね。

　なおシステム構築ではシステム・エンジニアやプロジェクト・マネージャといった役割もありますが，ここでは話を分かり易くするために省略します。ついでにいうと，システム構築ではしばしば途中で仕様の変更（料理なら途中でスープの種類が変更するようなもの）があったりしますが，同様に割愛します。

　さて，おいしい料理が出来上がり，きれいに盛り付けて完成しました。後はウェイター／ウェイトレスがお客さんのテーブルに届けてくれるので，これにてシェフのミッション完了。「お疲れ様でした！」「いやー，今日もいい仕事したねぇ。」

　------本当にこれで終わりでしょうか？

　一流のシェフは，自分たちの料理がお客さんにどのように届けられているか，お客さんがおいしく食べているかをとても気にかけています。だから，目立たないところからお客さんの様子をうかがったり，メイン・ディッシュを自ら配膳して料理を説明するなかで感想を尋ねたりしているのです。

　なぜなら，シェフ（＝料理に責任を持つ立場）として，お客さんが自分たちの料理に満足したかどうか，もし不満や改善点があるならそれは何なのか，といったことを知りたいし，知る必要があるからです。そのためには食べ終わった皿の様子を見て汚れていたら食べにくいのかもしれないと考えたり，料理が残されていたら量が不適切だったかもしれないと考えたりもするそうです。こうしたことの積み重ねで，料理やメニューの質を高め続けているのです。

　ITアーキテクトも同じだと思います。システムを作ってリリースしたらそこで終わるのではなく，「ちゃんと予定通りに運用できているか」「利用者は迷うことなく操作できているか」「トラブル時のログの出力は適切か」「善かれと思って付けた機能が逆にわずらわしくなっていないか」---など，リリース後も気にしなければならないことがたくさんあるはずで，そこからフィードバックを得ていくべきなのです。