ブリッジエンジニアはコードを書くべきではないか(いや、書くべきだ)

ブログに書いた記事の転載です。
https://munchkins-diary.hatenablog.com/entry/2018/11/09/100136?_ga=2.146368883.670655470.1541714486-1598871862.1541527477
※この記事は過去の自分に対する自戒と体験共有の意味を含んでいます。

Shut the fxxk up and write some code!

御託はいいからさっさとコードを書けなんて名言がまかり通る世界ではありますが、一部例外的に実装の現場にいながらあまりコードを書かない人がいますね。

そう、オフショア開発におけるブリッジエンジニアです。

技術関連記事三稿目です。

彼ら、そして私たちブリッジエンジニアは高い(かどうかは知らん)語学力とマネジメントスキルを買われ、遠い海の向こうで働くプログラマの同志たちに、仕様を伝え、進捗を管理し、品質を担保してデリバーすると言うしちめんどくさい 重要な役割を任されているわけなのです。

このブリッジエンジニア、基本的にコード書きません。

自分の仕事は仕様書の英訳と問い合わせ対応と進捗管理だみたいな認識の人もいますし、そういう認識を持っていなくても立場上それらの仕事に専念せざるをえない人もいます。

本題

さて、今回の記事では、ブリッジエンジニアがコードを書くべきだと言う理由をつらつらと並べ立てて行こうかなと思っております。

特に、コードに自信がある、コーディングが好きだ、もしくはコーディングに興味があるのに、このしちめんどくさい(もう消さない)役職を押し付けられてしまったエンジニアの方々が、自分で書きたいと言う意思を上司なり元請けなりに説得する材料になればいいんじゃないかなと思っています。

そう言う意思があるのに書けなくてやめていく同僚を見てるのも苦しいしね。

メリットとしては、以下の四つをあげています。

1. 進捗見積もりが正確になる

2. 多少の遅れは自分で巻きとれるようになる

3. メンバの教育ができるようになる

4. 双方のモチベーションが上がる

説得の材料になりそうで、具体性がある物を先に書いていきましたが、現場の人間としてメリットを感じているのは4->1の順番です。

好きなものだけ好きに使ってください。

書くべきメリットその１ 進捗見積もりが正確になる

進捗見積もりというのはオフショア先で勝手に見積もられるものだったりしますが、これが全くあてにならないのが世の常です。

この見積もりの曖昧さを起源とする遅延を、「途上国のルーズな時間感覚」や「先方の技術力不足」のせいにする発注者は非常に多いのですが、実際開発の見積もりなどというのはもともと決してあてになるものじゃないというのはアジャイル開発における前提認識のようなものです。

なんだそれ聞いたことねーよという方はアジャイルサムライの3章くらいを参照（）してください。

この本ではだいたい3ヶ月後くらいまでの開発計画が予測可能な限度だと紹介されており、実際にはその3ヶ月ですら開発者のレベルや使用される技術に対する習熟度などによって大幅に遅れることが経験的にわかります。

(ちなみに具体的な現場でどのように対応すべきかなども紹介されているので、読んだことない方はぜひご一読することをお勧めします。)

では仮に3ヶ月で見積もりを行うとして、その判断材料となるのは何があるでしょう？

* 過去の実績 => 全く同じシステムと技術を扱うわけでもない

* 先方の見積もり => あてにならないから今まで遅延したプロジェクトが出てきた

* かつて見たメンバの力量 => オフショアに置いてあなたの知ってる先方エンジニアが今もいる可能性は限りなく薄いです。彼らはすぐ辞めるので。

そう、実際にその見積もりに対して十分に有益になりうる材料って意外とないのです。

しかし、もしあなたが現場で彼らと一緒にコーディングを行っていればどうでしょう。

もしあなたが使用する言語やフレームワーク、ライブラリに対する知見があれば？

当然ながら、実装に時間がかかるポイントや習熟にかかる時間、また実装に関する具体的なイメージが持てるので、当然見積もりはより正確になります。

コーディングでは、書かなければわからないことなど山のようにあります。そのイメージが持てるでも見積もりに対して大きな判断材料となり得るでしょう。

書くべきメリットその2 多少の遅れは自分で巻きとれるようになる

僕の尊敬するエンジニア兼マネージャの方の受け売りなのですが、自分が部下に好きにさせていいのは自分が巻きとれるとこまでなのです。
オフショアの発注先は部下ではありませんが、それでも大きな遅延が発生した時は自分(もしくは自社の人間)で巻き取らなくてはいけないケースも多々あります。

自分がコードを書いていない場合、まず技術のキャッチアップに始まり、既存コードの把握し、遅延分のコードを書き始めるというデスマの夜が始まります。

設計はなんとなくわかるけど全く読んだことのないコード、しかもレビュがないので信じられないくらい汚いコードがそこに横たわっている。  
「どこから手をつけよう。」  
「まずは読まなきゃ。」  
「うーん、読めない、なんstepあるんだこのメソッド。」  
「リファクタリングするか。」  
「いや、テストがない。これではリファクタリングもできない。」  
「テストを書くか。」  
「いや、それでは間に合わない。そもそも入出力が全く参照透過じゃない。」  
「くそ、とりあえずコメント書きながらでも読むしかない。」  
「あぁ、朝だ…あと三日で終わらせないと…」  

こんなケースが現実に十分起こりうるわけです。

※この記事は過去の自分に対する自(ry

現場で一緒にコーディングを行うことで、ブリッジはコードの構造や設計、実装に対して当然ながら現場開発者並みに詳しくなります。

テストが必要な箇所や汚いコードに対してコメントすることもできます。

遅れが発生していた場合も、あなたはその遅れの最前線にいるので、その遅れを真っ先に知ることができます。

そして結果として、あなた自身がその遅れをコーディングによって比較的早い段階で容易に取り返すことができます。

遅れが発生して自分で巻き取らなくてはいけない状況というのは、ブリッジエンジニアとしてはマネジメント能力不足を問われかねない悲しい状況ではありますが、プロジェクトの目的は顧客に対して納期通りにデリバーすることです。

自分で巻きとれず遅延したり、全く知らないコードに苦悶しながらデスマしたりするよりかは、自分自身でいつでも巻きとれるようにしておくというのは、確実に顧客にとっても自分自身にとっても価値のある行為でしょう。

書くべきメリットその３ メンバの教育ができるようになる

このメリットは自分もコードが書けるのに書かせてもらえない方向けのメリットになります。

メリットその１の冒頭で例示した先方エンジニアの技術力不足というのは実は当たらずも遠からじです。

なぜなら、途上国におけるITビジネス、特にオフショア開発というのはまさに発展途上で、日本に比べて経験豊富なエンジニアの数というのが比較的少ないのです。

これは大学で理数系を専攻していた人間しかエンジニアになれないという海外では当たり前の採用基準も関係してたりするのですが。

何はともあれ、先方のエンジニアは年が若く技術力もまだまだ発展途上なことは非常に多いです。

では、そんな彼らに全ての実装を任せっぱなしにしていいのだろうか、いや良くない。

彼らの国では手本となる先輩も少なく、自然言語上のマイナ言語ではqiitaやstackoverflowなどのサービスもないのです。

では、ブリッジが一緒に現場で書いていればどうでしょう？

自分の書いたソースを参考として見せることも出来ますし、Pull Requestに対してコメントしたり、テストの書き方を教えたり、時には設計に関する講座を開いたり、ペアプログラミングなどで手っ取り早く技術力向上を測ったりできるわけです。

先方のエンジニアにとっても技術力向上の機会は得難いもので、喜ばれること間違いなしです。

書くべきメリットその４ 双方のモチベーションが上がる

実は個人的に一番メリットを感じてるのはここなんですよね。

ブリッジエンジニアと現場のエンジニアって、かなりクライアントと発注先という壁があってチームとして活動してる感覚がない人が多いんです。

酷い場合だと先方の代表者とだけしか話せなかったりして、現場の開発者の顔も名前も知らないなんてことはザラですね。

人間って基本的に顔を知ってる人のためには頑張るし、顔を知らない誰かに対しては平気で無責任になれるんですよ。

ブリッジが顔を知らない開発者に対して怒りをぶちまけたり、逆に向こうの開発者が悪びれもなく遅延して来たりするのもこれが大きな原因だったりします。

それでは、もしブリッジが一緒に現場で開発していたらどうでしょう？

誰かが作ったモジュールに対して質問をしたり、逆にブリッジが質問されたり、当然現場の開発者とのコミュニケーションが増えます。

ブリッジがコーディングの現場に開発者として参加するだけで、顔の見える人間同士のチームとしてのコミュニケーションが可能になるんです。

ブリッジが十分にコーディング力のある開発者であれば尊敬されることも増えて来ます。

偉そうに踏ん反り返ってる発注元のおっさんから、尊敬するエンジニアの一人に成れればこちらのものです。

先方のブリッジに対する信頼と開発に対するモチベーションは確実に高まるでしょう。

ブリッジ自身のモチベーションもそうです。自分自身でコードが書ける上に、きちんとリスペクトを払ってもらえる。ただ発注元として進捗管理していた時は味わえない感覚です。

当然、先方のエンジニアから学ぶこともあります。僕は「SpringのAutowiredはプロパティベースよりコンストラクタベースの方がいいよ。」というのを先方のエンジニアに教えてもらいました。

考えてみれば当たり前なのですが、仕事としてコードを書くことから離れ、趣味でしか書けなかった時代にはなかなかたどり着けなかったでしょう。

自分でコードを書き、自分のコードを相手に見せているからこそできる体験です。発注者として進捗管理をしていたらきっと僕はいまだにfield値にAutowiredしていたことでしょう。

最後に

ブリッジエンジニアがコーディングを行うメリットをつらつらと書いてきましたが、いかがだったでしょう？

前時代のSIer的なオフショア開発は双方にとってあまりメリットがなく、双方がリスペクトしあい、発注者・受注者の垣根なく開発を楽しめる現場を作るためにも、ブリッジエンジニアもどんどんコードの開発現場に入っていくべきだと僕自身は考えております。

今もしコードが書きたいのに立場上書けないエンジニアの方々がいらっしゃれば、ぜひこの記事を参考に上司に掛け合ってみてもらいたいです。

コーディングは楽しいですし、コーディングと技術を愛するブリッジが現場に入ることはきっと製品にとっても有益なはずです。

以上、エンジニアはコードを書くべきではないか(いや、書くべきだ)でした。