未熟なアーキテクト - ぐだぐだ言ってないでコードを書けよ、ハゲ。

f:id:khei-fuji:20150416223111j:plain

世の中にはいろんなITエンジニアがいます。
最新の技術を活用、自動化を駆使して大きな成果を残す人。
そういう開発者を目標に向かっていく駆け出しの人。
スキルは誰かに教わることを前提として、割り当てられるギョームをただこなす人。

別に誰がいいとか悪いとかそういう話ではありません。
この話はアーキテクトの話です。

アーキテクトとは何かの問題解決のために、システム全体の構成や、採用するインフラなどを選定・導入する役割だと考えています。
アーキテクトのとり得る選択肢は、その知識や経験によって大きく変わってきます。

たとえば Jenkins なしに自由度の高い CI 環境の構築はなかなか大変そうですし、
Heroku なしに Hubot を導入する人はそんなにいない気がします。

アーキテクトが技術に造形が深いほど、適切な選択を取ることができるはずです。

しかし実際は周囲の人員の経験を加味する必要があります。
たとえアーキテクト自身が理解できていたとしても、周りの人がそれを理解できなければ、属人性が高まり、組織の弱点をつくってしまいます。

とはいえスキルが低い人に合わせてばかりでは、回り道を強いられすぎてムダにコストをかけてしまうことにもつながります。
このあたりのバランスをうまく取っていけるのが、きっと「いいアーキテクト」なのでしょう。さらに技術的なチャレンジをうまく入れつつ、周囲がスキルを磨くように導くこともアーキテクトに求められる役割なのだと思います。

「導く」なんていうのは自分にはおこがましい話で、人を動かすタイプではありません。
私自身が技術にこだわるようになったきっかけは、ハイスキルな人の活躍を見て、そうなろうと決めました。
自分がそういう姿を見せることで「いいアーキテクト」を目指していきたいものです。

<a href="http://xn--97-273ae6a4irb6e2h2ia0cn0g4a2txf4ah5wo4af612j.com/">ソフトウェアアーキテクトが知るべき97のこと</a>

そんなポエムな文章が、上を読んでたら湧いてきました。