読了したのでレビューです。面白かったです。
現在のプロジェクトと自分の立ち位置
とあるプロダクトを開発、成長させるプロジェクトに1年以上携わっています。ゼロからプロダクトを立ち上げるところから参画していて、最近は「リーダー的」に立ち振る舞うようマネージャーから求められています。
責任ってなんだ
一メンバーから「リーダー的」な役割になると責任が増大するような気がします。しかし、私は、この責任というものがどういう義務を負った状態なのか、長らく分かっていませんでした。
本書239ページにその答えが記載されています。
権限を委譲された側は、その権限に見合う会社のリソースを取り扱うことができ、その権限に見合う自由度を手にすることができます。一方で、権限にはそれに対応する責任が伴います。これを「説明責任」といいます。
説明責任とは、与えられた権限に対して、何を行い、どのような結果をもたらしたのかという説明を、権限を付与した人に報告する責務のことです。
なるほど。マネージャーからしたら、確かに説明はしてほしいですね。
なぜ開発が失速するか
本書では、プロダクトの開発スピードが、だんだんと遅くなっているという悩みが251ページから解説されています。スピード低下の理由は、システムが複雑になるから、機能を追加するために、既存の設計を変更する必要があるから、といったものでした。
これはまさに私がいまプロジェクトで経験しているものと同じで、初期のころに比べると多くの機能が追加されるとともに、設計が大きく変わっています。そして、開発スピードは当初に比べると今は遅くなっています。
所感ですが、機能追加よりも、機能を変えずに設計を変えていくほうが難しいような気がしています。
技術的負債の位置づけ
「技術的負債」というワードは、意外と説明するのが難しいですが、「見える・見えない」、「プラスの価値・マイナスの価値」を軸に、新機能、バグ、アーキテクチャ、と比較することで理解しやすくなります。*1
エン組第5章、「見える/見えないの軸」と「プラス/マイナスの価値」の軸が分かりやすい。
— アレク (@alek30313) December 23, 2018
こういうのを図示されると、もやもやと考えていたことがクリアになりますね。
コミュニケーション
順番は前後しますが、第2章はメンタリングの話です。メンタリングはコミュニケーションを通じて行うため、コミュニケーションのやり方についての記述が多いです。
コミュニケーションをやっぱりサボっちゃいかんな、と反省しました。
また、以下のような感想を持ちました。
エン組第2章、読者がメンティーで、作者がメンターであるという構造を感じる。スキマ時間で一気読み。
— アレク (@alek30313) December 8, 2018
読んでいるとメンタリングは相手にがっつり向き合わないとできないように感じますが、私は第1章・第2章を読み終えた際、なんとなくメンタリングを受けたような気持ちになりました。
まとめ
対象読者が明記されていないのですが、私は以下だろうと思いました。
- ITエンジニアで、特に自社サービスの開発に携わっている人
- チームで業務に取り組んでいる人
- もうちょっとうまいこと仕事が回らんかな～ともやもやしている人
読んでみると、そういったもやもやがはっきりとした問題になるかもしれません。問題が分かれば、あとは解決していくだけです*2。
