arclamp.jp アークランプ

　昨日、ご縁があってTOYOTAでチーフエンジニアを務められていた方から、自動車の開発プロセスについてお聞きする機会に恵まれました。

　まずTOYOTAにおけるチーフエンジニアという役割を理解しなくてはいけません。チーフエンジニアは、ある車を開発する場合のコンセプト作り、役員プレゼン、車体コンセプト設計、予算・原価管理、プロジェクトマネージメント、販促、マーケティングまでの全てに携わります。単純に「車を設計すればいい」というものではなく、車を作って売るというプロセスの全てに関係するというものです。
　今回の講演ではプロセス全般についてざっくり触れていただくという内容でした。なおTOYOTAの取り組みについては非常に多くの本があるかと思いますので、見える化をキーワードにして、心に残った点だけをエントリすることにします。

見える化の目的
　車の生産過程ではなく開発過程においても「見える化」という言葉が良く出てきます。見える化する目的は、次の3つではないでしょうか。

- 気付く
- 広める
- 比べる

"気付く"ための見える化
　プロジェクトを進めていると、もちろん予定外や誤差が出てきます。大事なことは、それに早く気付くこと。TOYOTAでは時間による管理が個人レベル、車のモジュールレベルで行なわれており、マクロ・ミクロ視点でのレポートがあがってきます。いわゆる原価管理。専門の社内部署もいるそうで、そこの担当メンバーが逐次レポートを送ってくれるそうです。そして、このレポートを見ることで異常に"気付く"ことができます。
　印象的だったのは「気付くのは責めるためではなく、助けるため」とのこと。問題を発見すると、なぜ問題が起きたのかをヒヤリングし対応策を検討します。そして判断し適切と思われる対応を行なうわけです。それは「対応策はたくさんある。切り札はないけど」というように地道な作業です。

"広める"ための見える化
　プロジェクトの中でカイゼン事項や次回に活かしたい事があると、それを広めるためにレポートが必ず求められます。それは2,3行ではなく、1項目につきA4用紙で1枚。ある程度の技術者なら理解できるレベルです。これを一品一葉と呼んでいます。
　これは「小さく生んで、大きく育てる」ため。このレポートをみて周りの人が理解し、そしてもっと良い意見を集めるために使われるのです。

"比べる"ための見える化
　では、見積もりの妥当性をどう見るのか。これは過去から蓄積されたデータと比べることで確認します。
　比べられる、ということは継続的に同じようなモジュール管理が行なわれていることを示します。「この車のこの部分は****時間でできているのに、なぜ、今回はできないのか？」といったようなことを数千から数万項目も確認するそうです。

見える化はなぜ可能なのか？
　さて、こうして考えてくるとIT業界における見える化には、まだまだ甘いところがあることが分かります。というか、あまりうまく行っていません。

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

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

　見える化の基本はモジュール化にあるといえるのではないでしょうか。

IT業界の見える化実現に向けて
　IT業界では、まだまだモジュール化が進んでいません。というか安定しません。現時点で無理に安定させると（例えば社内標準の作成とか）、それがすぐに形骸化してしまいます（皆さん、ご存知の通り）。

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

　正しくチームやアーキテクチャが分割されていなくては、マネージメント（ついでもテスト）もへったくれもありません。例えばですが、今すぐ使えるのであれば以下のようなものがあります。
- 3層設計（プレゼンテーション、ビジネスロジック、パーシステンス）
- O/Rマッパー
- DIコンテナ
- 単体テスト
- コードメトリクス（スタイルチェッカー）
- 様々なEffective Java的コツ（Enumとか）
- IDE

　未来を見ればSOAは有望株でしょう。サービスを切り口にアーキテクチャが分割できると、データによる連携に比べてかなり緩やかな分割が可能になります。僕はSOAを開発手法として考えています。

まとめ
　見える化に特化してしまいましたが他にもいろいろな話がありました。もしかしたら2回目を書くかもしれません。

　なんでしょう、やはりTOYOTAがすご過ぎます。
　ですが、僕らがそこに行けないわけではありません。今のTOYOTAは成功者ですが、そこに至るまでに数々の努力があったはずです。20年前、金太郎飴と評されたTOYOTAがあったのは事実です。
　同じように僕らも努力しなくてはいけません。未来残る作業をしなくてはいけません。
　うっすらと遠くの頂は見えている気がします。やるべきことはたくさんありますが、地道に積み重ねるしかないのです。それだけが偉大な企業を作るための唯一の方法なのでしょう。