Usual Software Engineer

よくあるソフトウェアエンジニアのブログ

エンジニアリーダー論（仮）

スクラム アジャイル開発 エンジニアリーダー論 Environment Engineer マネージメント

珍しく技術の知識エントリじゃなく、自分の近況のエントリを書いてみます。

現在ベンチャー企業で技術責任者として奮闘しています。
プロジェクトは2つ動いていて、両方の技術の根幹を担っているわけですが、 そのうち1つのプロジェクトではプロジェクトマネージャーとして動いています。
もともと会社が立ち上がってから最初のエンジニアとしてジョインし 自分としてもCTOの動きをするべきであるという思いもあり
それまでの1エンジニアとして全力でコミットするというメンタルとは大きく変わりました。
まだ会社としてはリリースされたプロダクトもなく、CTOという肩書きも存在しないわけですが エンジニアリーダーとしてどう動くべきか、どういったことが必要なのか今後の糧としてまとめておきたいと思います。

プロジェクトマネージャーと言っても、その言葉から想起される役割とは少し違っていて
アジャイル開発のスクラムでいうスクラムマスターとして、時にはフルスタックエンジニアとして
開発の部分で全体をまとめつつ手を動かすということを実践してきました。
世間で一般的であると思われるSIerのPMの動きとは違うと思うしそれについては正直わからないので触れません。
僕の考える最強のエンジニアーリーダーとまでは言いませんが
自社プロダクト開発のエンジニアのこうあるべきだという自身の見解を以下の5つとしました。

チームの障害を率先的に取り除く

これはスクラムマスターそのものの役割なので言うまでもなく重要なのですが
おそらく所謂プロジェクトマネージャーの場合だとチーム外との調整を重視していて
チーム内の障害を直接取り除くことへの意識の度合いは違いそうだなと思いました。
マネージメント層のあるあるだと思いますが
コードを書かなくなったり、バグ修正をしなくなったり、開発環境に触れなかったりしていると
どうしても実際に開発を行っているメンバーの視点や考え方を理解しづらくなってしまいます。
「コードを書きながらマネージメントをするのは難しい、できない」ということをよく聞きますし
自分も同じ状況になるだろうと予想していたので
それなら「機能開発はせずに開発環境を全部受け持とう」という発想に切り替えました。
これがうまくいけば、チームの開発効率改善に力を注げて、
どういう部分に開発の障壁があるのか捉えやすくなるし、コードを読んでバグの修正も行えて、
機能開発はやらないからマネージメントの時間も確保できる理想の形だと思いました。
言うならば、Environment EngineerでEEですね。Java EEみたいｗｗ
開発環境だけじゃなくてスクラムマスターとしてメンバーの進捗やコミュニケーションもマネージメントするので
まさに"環境エンジニア"というところ。
エンジニアがマネージメントをやるならこういった工夫をしてエンジニアで居続けることが重要ではないかと思いました。

部分最適よりも全体最適

ベンチャー企業なら人数が少ないことによる意思決定のスピードが武器ですが
すでにファウンディングメンバーだけじゃなくて委託のメンバーもいるので
すぐ動くことが重要と言いつつよく考えて動かないとメンバーが混乱したりしらけたりしてしまいます。
1メンバーならすぐ意見を挙げることは全く悪くないことですが
チームのリーダーなら部分最適ではなく全体最適を考えられる人であるべきだと思います。
パッと見で効率が上がるように思える作業でも、実際はのちのち不要になったり
導入したことで継続コストの方が大きくなったりすることがあります。
例えば、ローカルで開発を完結したいからエンジニアが仮想マシン上にサーバを立てて開発していて
それが便利なのでデザイナーも同じ方法をやろうとし、
ブラックボックスすぎて導入にも利用にもコストがかかり過ぎた、みたいなことです。
リーダーはこれを正しく見極める必要があって、メンバーの意見を何でも聞き入れてしまうことは
かえってチーム全体の力を下げてしまったり信頼をなくしたりすることになってしまいます。
当然ながら、チームで一番チームの現状とこの先を見据えておく必要があります。

意見を収集できる仕組み作り

メンバーの意見を何でも聞き入れることはチーム力を下げる、なんて書いてしまったので
リーダーが偉いみたいな間違った認識をしないために、次はメンバーの大事さについて書きます。
一人の意見で決めたことが多くを幸せにすることはほぼありません。
チームでやっている以上、リーダーの能力にチームの能力が制限されてしまうのは悪だと思います。
だからこそ意見を収集しなければいけず、それをどう集約するかが重要になってきます。
スクラムでもそうですが、基本的に各々のメンバーが自律的に動いてチーム自体が自己組織化されることが
良いプロダクトを作り続けるために必要なことなので、リーダーはそれを裏でサポートする役割を実行しなければいけません。
例えば、全員でプロダクトを触る時間をとって話し合って改善案を出して実際に改善したり
進捗が思わしくなくてスケジュールに影響しそうであれば個別にコミュニケーションをとってフォローしたり
当たり前のことかもしれませんがこれがプロダクトの良し悪しにものすごく影響します。
メンバー1人1人が自分でプロダクトを作っているという意識が芽生えるように
意見を吸い上げて集約したりプロダクトに反映したりする仕組みを作ることが大切です。

決定力と判断力

今までの項目とは少し違った内容になりますが、
1エンジニアとエンジニアリーダーで大きく違うのは
長期的に考えて今やるべきなのか、その技術を採用するべきなのか、開発チームの体制を変更するべきなのか
といった未知の大きなことに対して判断する必要がある点です。
これは1機能の設計の話とかではなく、正解がないけれど判断を間違うと影響が大きいような技術決定に関しての話です。
開発だけじゃなくて運用を考えて、今後の技術的な方針を考えて。でも技術だけじゃなくてビジネス的なマイルストーンも考えて。
こればっかりはいきなりうまくできる人はあまり多くはないだろうなと思っていて
リーダーになるっていうのはこういう判断の経験を積んでいくことなんだと思います。
経験の浅いうちは判断ミスも起こりますが、ビビっていても仕方ないので
責任者として正しくというよりも考えて「決定する」ことが重要なのだと実感しました。

マネージメントもエンジニアリングしよう

エンジニアはエンジニアにマネージメントしてもらわないと不幸せになりやすいです。
少なくとも、技術の話をわかろうとしないディレクターにエンジニアのマネージメントができるはずがない。と思っています。
多くの企業でビジネス優先で物事が進むことは仕方のないことですが
技術への理解なしにプロダクトを開発しようとしていることが哀れなことか気づくべきだと思います。
とはいえそういった組織でエンジニアがマネージメント層にいくとそれもまたその人が不幸になりがちですが
"エンジニアとして"という信念をもって工夫すれば道はあるんじゃないかなと思っています。
その答えが、上述したEnvironment EngineerでEEですね。二度言いました。
マネージメントとは、環境づくりではないでしょうか。
コードを書くことが大好きでマネージメントをしたくないようなエンジニアも
一人では作りきれない規模のプロダクトをチームで作れて、
チームの開発効率をアップするサポート的な開発は大いに楽しめると思いますし、
エンジニアで居続けることが可能です。
SlackやGitHubやJenkinsやHubotやTaigaを導入するのも楽しく感じるでしょう。 だから、マネージメントもエンジニアリングしてしまえばいい。

エンジニアリーダー論は以上でしたが、「（仮）」が付いているのは理由があって
このエントリは3ヶ月前に下書き保存してあとで文章直してアップしようとしていたものだったのですが
そうこうしているうちにチームの開発の状況も時々刻々と変わって
「エンジニアリーダー論」と言えるほどうまくいかないという現実にぶち当たりました。 現在進行形で成功と失敗を重ねているので
開発が落ち着いたら改めて振り返りのエントリを書こうと思います。