普段、エンジニア業務に励んでいる中で開発手法というのは、やはり好き嫌いが分かれるように思える。実は、それらは一長一短であり、トレードオフなのだ。

開発手法について最近思っていること
一旦、視座をエンジニアを統括する事業部長クラスにして、考えてみる。

CONTEXT: 「会社単位で開発手法を確立させるが何がいいか？」というのはよくあるISSUEだ。
一方で、エンジニアの世界には、「ジュニア・シニア・ミドル・リード・ディレクター」の5区分がある。
しかし、ジュニアがミドルの開発方法を真似ても、実際はキャッチアップに時間がかかる。
それはAIがあっても埋められない経験値。

FIRST_ISSUE: では本来のISSUEはなんなのか？

MAIN_ISSUE: 5区分それぞれで最適な成果を出せる開発手法を会社単位で確立することなのでは？

基本的にはディレクターは希少であり、ジュニア・シニア・ミドルに向けて、開発手法が組まれることが多い。
ルール・規約など、それらはジュニアから見たら、実装上、守らないといけないことが多くて、自由が効かないと思うかもしれない。
しかし、ミドルから見たら、それは自由を制限するためのものであって、リード・ディレクターから見ると、最終地点、プロダクトが安全に生み出されるための滑走路を走る車＿乗っている彼らは必要最低限のシートベルトをしている。事故にあった時、リスクヘッジするためのもの。

ここで、(Case) 納期が早く、リスクよりも完成させることに重きを置く場合、それらのシートベルトは外して、ある程度のアクセスを踏む必要がある。
このとき、リードとジュニアが協力すると必ず発生するのは、リードがジュニアにする教育であり、ジュニアはそれを守って、実装していく。

この時、ジュニアがつけるシートベルトがリード用すぎて馴染まない場合は、ジュニアは自らの意思で自らの安全装置をつけてしまう。
そこで、彼らにあった開発手法とはなんなのか？

その原点に戻って、ゼロから考えていきたい。

今はAIがある。
だからこそ、シートベルトが緩いと、ジュニアは一生安全に滑走路を走れなくなる。

THEORY: Caseによって、それらを柔軟に変えられ、最適な成果を出せる開発手法をエンジニアの5区分で適用できる組織は強い。なんなら、「自走するエンジニア」を生み出す上で、それらを適切に理解し、自らの意思で進められる人こそが、真の「自走するエンジニア」なのかもしれない。