エンジニアとして生き残るための、たった１つの真実。
「生き残る」という言葉には2つの意味を持たせている。
- 老害エンジニアにならずに生き残る
- プロジェクトにつぶされることなく生き残る
ではどうすれば生き残れるのか？
大きなヒントがInfoQの記事にあった。
原則4:自分の仕事の仕方を常に疑う
InfoQ: トップスポーツチームの監督に教わる秘訣
老害エンジニアにならないために
先日テレビを見ていたら、水素自動車の特集をやっていた。
ホンダの社長がこんな感じのことを言っていた。
「技術はほしいと思ってもすぐにできるものじゃない。だから今のうちから研究する。」
クラサバからWebへシステム開発の主軸が移ったとき、多くのエンジニアが追いつけなかった。
それはほしいと思っても技術がすぐに身につかなかったからだ。
昔COBOLができれば一生食うに困らないと言われていたそうだ。
だが、現実は違った。
自分の仕事の仕方を常に疑おう。
「システム開発のデファクトはJavaであり続けるのか？」
答えは否だ。
「永遠にWebが基盤であり続けるのか？」
答えは否だ。
否であるならば、どうするか。
そうでなくなるときを見据えて、自分で研究していかなければならない。
技術の基盤はコンピュータサイエンスであるから、学術的にはどんなものがあるのかを調べれば、次世代の潮流を単語程度で拾える。
それも最新でなくていい。オブジェクト指向を考えれば、学術的に数十年前のものがやっと実際に使われる感じだから。
僕ははてなをやっているみんななら「今さら」と思うだろうけど、関数型言語を勉強している。
プロジェクトにつぶされないために
この考えをプロジェクト全体に広げよう。
プロジェクトのやり方を常に疑うんだ。
特に伝統のある会社において、プロジェクトの進め方は硬直化している。
「今までこうだったから」という理由でいつものやり方を進めている。
だけど、僕らを取り巻く時代自体は変化していて、その変化に対応できず、多くのプロジェクトが失敗している。
そのしわ寄せは開発者に来るわけで、自分自身を守る意味でもプロジェクトを成功させないとつぶされてしまう。
そのためには、プロジェクトのやり方を疑い、よりよい方法に昇華させなければならない。
「今までのやり方で成功するのか」
「この方法は効率がよいのか」
劇的に変化させる必要はないし、そんな権力を持ち合わせてもいないので、自分が関与する範囲で、かつ最もボトルネックになっている部分を変えていく。
先のInfoQの記事にもこうある。「原則2:異なるやり方のみが異なる結果を生み出す」と。
前提条件が同じであれば、同じ方法で実行した結果は常に同一である。
失敗したプロジェクトと同じ手法でやれば、結果は失敗となるということだ。
少し具体例を挙げると、僕は会議に注目している。会議は大人数の工数を使用するコストの高い作業であり、かつ内容が適切でない。
しかも「いつもと同じように」みな会議をする。無駄はなくならない。
エンジニアのモチベーションも大きく下げる。
時間を短く、かつ参加者にその価値があったと思わせられる会議をする。
フィードバックを早く、多くする。
現在のシステム開発では、開始時点で未知なことが多く、計画的な進行はほぼ不可能になっている。
さらにもともと設計というものは事前に完璧にすることが無理だともわかっている。
いかにフィードバックサイクルを早くするか。
設計で文書の体裁を整えるのは後だ。
ラフスケッチでも箇条書きでも、さらっと書いてすぐにレビューする。
レビューはかしこまらない。非公式に「だいたいの」方針を伝える。
一気にすべて実装しない。だいたいの設計に従って軽く実装する。
画面からの正式な結合テストはまだしない。だいたい動けばいろんな人に触ってもらう。
設計を修正する、詳細化する。また実装する。
こうすればしょーもないバグはつぶれるし、それから正式な結合テストをすればいい。
フィードバックを早く、多くするためには、「公式」をできるだけ少なくし、「非公式」を多く行う。
修正範囲が小さくて済む上、方針転換などの変化にも対応できる。
まとめ
長くなったけど、「自分の仕事の仕方を常に疑う」つまり「考える」ということがとにかく必要だということ。
今のままでいい、というものは意外に少ないことに気づく。
