Engineers in VOYAGEの2章について熱いコメントをいただいた
「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」の2章に対するがっつりとした書評というか感想をいただいたのが非常に嬉しかったので、コメントを書かせていただこうと思い筆をとりました。
Zucks社のフルサイクル開発者
書いていただいた内容の通りです。
ただこのスタイルに固執しているわけではないです。規模が大きくなったり、メンバ構成が変わったときにも同じような状態が望ましいかはわかりませんし、変化に柔軟でありたいと思っています。
とはいえ野望というかスタイルとしては、わたしはフルサイクル開発者が好きですし、引き続きそうありたいと思っています。事業に直結するであろう価値を自分で届けられる、やはりこれに尽きるのではないかなと。
ところで、NOTエンジニアな社外の方たちと話をするとき、フルサイクル≒フルスタックのような話をされることがありますが、フルサイクル≠フルスタックです。フルサイクル開発者については弊社のtechlogが参考になります。
ジョイン初日にリリースする
> これがあるのに初日リリース出来ているのには矛盾
— Kazunori Otani (@katzchang) February 4, 2021
リリースをするためにはすべてを知る必要はないんですよ。全体の把握を前提としないバリューストリームを作っている。もちろん、把握してクセを掴んで変えていくのは大事なので、オンボーディングの後半で全体把握をしていく流れです。
この文化を作った大谷さんも言ってくれていますが、わたしもそう思います。全部を知ってから入っていく必要はない。まずはアウトプットすることに価値がある。その後はその後です。
というのと、そこまで難易度の高いタスクを用意しているわけではない、ということです。適切に管理しているかと言われると困るところですが、「これは初日リリース用に良さそう」というラベルをつけているチームもあります。
実はリモートワークになってからもこちらは継続中です。初日にいろいろなオリエンテーションがありますが、可能な限り必要なものに限定し、翌日でよいものは翌日以降に回すように。もちろんまだまだ課題はありますけどね！
ドキュメントレス文化
最近の傾向として、issue以外にもgoogle ドキュメントにまとめている内容もあります。例えば障害対応の時系列とその対応内容やKPT、はたまたこのアーキテクチャどう？といった内容まで。複数人でざっくばらんにアウトプットしたり、自分の認識・考えをひとに共有してコメントをもらったりするのに、issueよりも適しているなと思っています（まぁそのURLをissueに貼り付けるわけなんですがw）。
新人向けのコストについても言及されていますが、最初から全部の知識がまとまったものを渡されるより、任されたissueへの対応に必要な箇所から周辺コードにその知識を広げていくのだと、後者の方が課題解決にフォーカスできるのではないかと。とはいえこれは主に経験からくる意見であって、定量的に分析したことはないです！
本当に読み込んでいただいていて嬉しいので、簡単にですが、現在の考え含めアンサーさせていただきました。
この記事が気に入ったらサポートをしてみませんか？