初めての「アーキテクト」体験：あるエンジニア、かく語りき（3）（2/3 ページ）

[松坂高嗣，＠IT]

アヒルとアーキテクト

　若手中心のアーキテクトチームが招集され、われわれは「何を目指すか」を考え始めました。

　上司の考えはこうでした。アーキテクトとは、

フレームワークやライブラリを書き、アーキテクチャを策定し、基本設計や非機能要件に関わり、開発標準を定義する人である。必要に応じて上級エンジニアとして開発にも携わる。業務と技術のエキスパートである。会社のエンジニアの技術的な底上げをする。そして生産性と品質を上げる。

　私は短期間で複数のプロジェクトを転々としていましたし、客先のアーキテクトチームに常駐して、フレームワーク開発や開発標準検討に参加していたので、その仕事のイメージ自体は理解できました。

　しかし、肝心の部分である「うちの会社で、どのように振る舞うチームなのか」というところは分かりませんでした。「そんな万能のドリームチームを作るのに、なぜベテランを集めないのか」という疑問もありました。現実的なゴールイメージをうまく設定できず堂々巡りをしていましたが、上司は複数の案件を抱えていて多忙であり、議論にはなかなか参加できませんでした。

　つまり、アーキテクトチームが立ち上げられたものの、具体的なアクションは各自に任されている状態で、われわれは自分たちなりに目指す結果と行動を見つける必要がありました。

　ところで、ダック・テストという言葉をご存じでしょうか？

もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルである

　という帰納的な考え方です。そこで、当時の私はこう考えました。

アーキテクトのように考え、アーキテクトのように行動するならば、それはアーキテクトである

　追い詰められた結果ではありますが、後から振り返るとこれは大きなパラダイムシフトだったのだと思います。自分が何者として振る舞うべきなのかというところから、行動や判断を導いていくというやり方は、私にとって納得のいくものでした。

　とある有名なゲームに、こんな台詞（せりふ）がありました。

忘れるな、イメージするものは常に最強の自分だ

イメージと現実のギャップは大きかった

　最強の自分をイメージしても、現実というものがあります。私は新卒で2年程度の経験しかなく、それなりに仕事をこなせるようになってはいましたが、「アーキテクト」という肩書を背負う限り「レベル1」にすぎません。

　最初は上司の意見に従い、Javaのコーディング規約とかStrutsベースのフレームワークの検討とか開発ツールとかを、派遣仕事の傍らで整備し始めました（アーキテクトチームの多くは専属で仕事をしているわけではなく、日銭を稼ぐべく他部署の開発プロジェクトに貸し出されていました）。並行して、社内の読書会的なものに参加したり、新入社員教育プログラムに関わったりと、それなりに忙しくいろいろなことをしていた記憶があります。

　社内でチームについて説明する機会が、何度もありました。

　われわれは開発標準を策定し、全社の開発効率を高めます！ フレームワークや共通ライブラリなどを整備し、高品質と生産性を両立します！ 社外へも「アーキテクト部隊がいる」と説明できて、プレゼンス高くなりますよ！

　自宅で資料を作っていて「ほんとか？ ほんとにそうか？」と自問しました。

　それは全部、上司とか経営層から求められているものをまとめただけではないのか。雑誌やWebメディアの特集で語られている「アーキテクトは、なぜ必要なのか」「真の課題解決」「アーキテクトは経営とITの現場をつなぐ」みたいなメッセージを真に受けて話してないか？

　「それは、自分がアーキテクトの気持ちになって考えた結論なのだろうか？」そのような自問はずっと続いていました。

　皮肉なことに自分なりの答えが出たのは、前回書いたプロジェクトの失敗があった後でした。