太陽がまぶしかったから

C'etait a cause du soleil.

コードの書けないディレクターだけど「各論」を把握するためにPR全部読む

コードの書けないエンジニア問題

 僕自信のキャリアを考えると本当に「コードの書けないエンジニア/ディレクター」の道を歩んできたと思う。そこには能力の壁と業務管掌の壁がある。SIer のプロジェクトリーダーとしても、事業会社のディレクターとしても「自分でコードを書くのはNG」どころか「個別実装に口を出すのもNG」ぐらいの立ち位置を求められてきたし、それでよいと思っていた。

 だけども、自分で手を動かしながら「各論」を理解していかないと、そもそも正しい道筋を作ることなんてできないのではないか。デジタルトランスフォーメーションやら破壊的イノベーションに至る前段階の基礎的なデータ解析や生産性向上でさえ、上辺同士の話をしていると見誤る。実行可能ではないポンチ絵を描くことこそが退屈なのだ。

 そんな意識が芽生えてきた時に『自走するIT組織 リクルートのエンジニアはこう動く』を読んだ。著者は「リクナビ」「SUUMO」「ホットペッパービューティー」などの設計・開発・運用を担うリクルートテクノロジーズのCTO。リクルートの関連会社が共通的に使うオープンテクノロジーによる会計システムの内製開発に経理部として関わりながらリクルート流のIT組織を作り上げていく。

各論を知らずして問題解決はできず

 本文中で繰り返されるのが「各論」の把握である。

「他人まかせにしない」「自分の目で直接見て確認する」。これらの行動原理の重要性を、私はよく「総論と各論」という表現に言い換えて説明します。

(中略)

「これまでのシステム開発のやり方は、一体何がまずかったのか。色々な問題があるだろうけど、一番は設計や実装をすべて外部の開発会社に任せっぱなしだったことにあると思うんだ。自分自身が、プロジェクトの具体的な成果物やそこに使われている技術の中身、つまり"各論"をきちんと把握していなかった」

 ディレクターとしては要件定義や開発期間や予算などの「総論」に注力すべきだと考えていたが、その中身を丸投げしていると実現可能性の検討や正しい開発期間を見積もるのは難しい。中身を把握しているからこそ作業工程のボトルネックが理解できるし、自動化の勘所も分かってくるという当たり前の話だ。

Pull Request 全部読む

 もちろん、ゼロから全部を作るという話をしているのではないのだけど、少なくとも自分のプロジェクトで誰がどのような変更を加えて、システムがどう動いているのかについては中身まで把握しておくべきだと思う。僕自身が利用しているのは Github だ。

 プログラムコードやデザインテンプレートはもちろんこと、Infrastructure As Code の考え方で作成されたDB構成や仮想サーバー構成や cron に至るまでを設定コードに切り出してPull Request を作ってもらい、差分や修正の背景をコードレベルで理解することを試みる。自分がロジックとして理解できないことはなんらかの無理をしている可能性が高いし、結果としてテスト工程前に不具合や技術的負債を発見できることもある。

 「門前の小僧習わぬ経を読む」ではないが、他人のソースコードをひたすら読んでいれば自分でも簡単なものは書けるようになってくるし、どこに躓きがちなのかも分かってくる。なにより「プログラミングは黒魔術じゃない」という実感が得られた。そんなわけで、遅まきながらも技術ブログ的なことをやっていきたい気持ちが高まっている。