arclamp.jp アークランプ

　最近、コードをいっぱい書いています。仕事半分、趣味半分というか。OSSのプロダクトですが、将来はビジネスにすることも踏まえています。今週、金曜日にデモをしないといけないので、かなりピンチです。それはさておき（置いといちゃいかんのだが）。

手を動かし続けること
　手を動かし続けることは大事だなと思っています。僕はアーキテクトを「使う側と作る側をつなげる人」と定義しています。その点において「手を動かし続けること」はとても大切なことです。いまのシステム開発は作ることの品質が安定していないから、特に作る側に対する理解が重要なのです。少なくとも、この10年は同じ状況が続くでしょう。

　プレイングマネージャーが辛いのはよく分かるので、案件の中で100%コードを書けとは言いません。でも、あるフェーズでは手を動かしたほうが絶対にいい。そうしないと現場が見えてきません。

　現場できちんと手を動かしてことがある人はチーム内でコミュニケーションすることの大事さが分かっている。本当にくだらないことでチームがうまくいかなくなったり、しょうもない仕様でアーキテクチャがだめになることも分かる。構成管理、ソースコード管理、継続的インテグレーション、イシュー管理、情報共有の重要さが分かっています。

　そこまで要求しないでも、って思うかもしれないけど僕はそこまで要求したい。だってさ、アーキテクチャの設計で、メンバーの苦しみがすごい変わるんですよ。「僕じゃない他の誰が使う」っていう気持ちでアーキテクチャを作ったら絶対にだめです。理想論や思い込みでアーキテクチャを作るのは、本当に危険なこと。

　何度も書いていますが、アーキテクチャはプロジェクトの成否を決めます。以前「TOYOTAで考えた、見える化の本質」で書いたとおり、

　見える化というキーワードだけに特化していると、これをプロジェクトマネージメントの問題と考えがちです。しかし、僕はTOYOTAが見える化を可能にしている最大の理由はモジュール化にあると考えています。

　気付くためにも、広めるためにも、比べるためにも、その基本となるモジュール概念がシェアされていなくはいけません。見積もり項目と作業項目がずれていれは気付けもしません。パーツの名称や意味があいまいでは広められません。歴代の設計がばらばらでは貯めても比べられません。

（中略）IT業界ではプロジェクトマネージメントが注目されていますが、アーキテクチャがちゃんとしてないのにマネージメントしても、これっぽっちも、まったく、すっかり意味がありません。

という状況には変わりはないのです。マネージメントをきちんとするためには、アーキテクチャがきちんとしないといけない。プロジェクト・マネージメントだけをいくら論じても答えはありません。

根っこをつかむこと
　でも、全てのことに手を動かすことはできません。だからといって、放置してもいけない。

　先日、ちょっとした事件がありました。僕があるプロダクトにネガティブな指摘をしたメールを書いたら「使い込んでないのにDISらないでください」と怒られたのです。彼が言うことは正しくて、確かに僕のコメントにはプロダクトに対する誤解があって、指摘は的外れなものでした。そのあと彼に教えてもらい、僕はプロダクトを理解することができました（もちろん、彼が言う使い込むレベルには程遠いわけですが）。

　小さなことかもしれないですが、これではいかんなぁと思った次第です。全てのプロダクトを使い込むことも完璧に理解することもできません。でも、ある一定のレベルで理解をしておかなくてはいけない。それはプロダクトの思想だったり、考え方だったり、根っこの部分。

　例えばSpringであれば、以下のような理解が想定できます。

・システムをコンポーネント単位で分割して開発するためのプラットフォーム型のフレームワーク
・設定ファイルによってコンポーネントの組み立てを行うのがポイント
・トランザクションやログなど、ロジックに関係部分はコンポーネントの組み立て方の中で行う
・既存のツール型のフレームワークを自在に組み合わせられる

　ここまで理解していれば、以下のような想像ができます。

・コンポーネントの役割やメッセージング・パターンによって、チームの役割を分割するのだろう
・設定ファイルの管理が肝だな
・案件にフィットしたツールはなんだろうか

　これが求めすぎかどうかは環境によっても変わるでしょうが、アーキテクトやマネージャーと言われる人には理解しておいてもらいたいです。なぜなら、これで作り方が変わってしまうからです。作り方が変わればメンバーの管理方法も変わります。

　
僕なりのサバイブ
　ソフトウェアの可能性を広げるには、手を動かすか、少なくとも根っこをつかんでおくしかない。それが、ソフトウェア開発ではとても大切なことです。

　というか、これは僕なりのサバイブ術です。僕よりも技術が優れたエンジニアもアーキテクトもいくらでもいます。そこで勝負しても絶対に勝てない。であれば、僕は「ビジネスと技術の間にいるアーキテクト」として生きていくしかないのです。そのためには技術については効率よく手を動かして、根っこをつかんでおくしかない。

　そんなわけで、たまには実装に沈む時期も重要。ここで面白いこと見つけて、皆と話ができるようにならなきゃいけない。さて、実装に戻るとしますか。