waterfall,agiliそしてエンジニアの成長の機会

waterfallとagiliを考えていて、一つの違い、そうプロジェクトのタイムスパンが与えるエンジニアへの影響はあるのだろうか。
一人一人のエンジニアの経験なんてそれこそ唯一であって、エンジニアの成長の比較なんてできるのかと思うけれど、それでも大雑把に差異があるのかを考えてみた。


大規模プロジェクトの良いところ
タイムスパンが長いプロジェクトなら、エンジニアを育てる良い機会になる。
先が長いから、一つずつ確実にプロジェクトの工程を経験することが計画でき、実践できるから。

ラインマネージャの立場だと、可能であれば体系立って経験をさせたいという気持ちがある。
ITSSなどでエンジニアのキャリアパスの細分化が進んだここ5年くらいを思い出すと、体系だった育成は一段と意識せざるえない。
エンジニア一人ひとりの学び、吸収する時間軸が違うから、可能であればある程度のプロジェクトの期間が欲しくなる。
もちろん、タイムスパンの長いプロジェクトの方があっているエンジニアばかりではないので、短期だろうがどんどん水を吸収するスポンジのように気にならないエンジニアもいることは少なからずいることは確かだ。

小規模プロジェクトの場合、少人数だからこそ、一人がいくつもの帽子(=役割)を担って、幾つもの責任を果たすことになる。
これ自体、中堅エンジニア以降に求められるマルチスキルの訓練になるので良いと思うのだが、ひとつの技術領域を試行錯誤しながら深堀できるかというと役割が多くなる分、割ける時間が減るのでハードルが上がるだろう。



小規模プロジェクトでの成長の機会
なら、大規模プロジェクトより小規模プロジェクトに入ったエンジニアの方が自己の成長を促すことは過酷なのだろうか。
小規模プロジェクトならタイムスパンの余地が少ないということが、それぞれのエンジニアにそれだけ明確な責任が果たされることを期待しなければならない。
大規模プロジェクトのエンジニアは、楽チンなのかというと担当する業務はあるわけで、小規模プロジェクトより楽ということはない。
それより、小規模プロジェクトのエンジニアは、明示的に担当する作業の成果を求められ、アウトプットできないとプロジェクトに直接インパクトを与えてしまうことを実感することができ、そのことによる期待されていることをより感じることができる。
カンタンに言うと、必要とされることが実感できるということだ。
これは、モチベーションが上がる。
一方、エンジニアのバラツキを平準化できてしまう大規模プロジェクトは、たとえ一人の成果が期待とおりに出なくても、リカバリできてしまうのでそれこそ、歯車の一つと感じてしまったら、モチベーションを維持することは難しいだろう。




そうは言っても
そうは言っても、大規模で短期のプロジェクトなんて、そうそうあるものではないので、大規模がいいとばかり言ってられない。
現実的に存在するプロジェクトは、小規模で短期間が多いのだから。
長期でじっくりできない分、数をこなし、成長するステップをより意識して育成していけるような助言を与えるほかない。
育ってほしい人材像に、その時々の環境を踏まえて機会の提供と意識づけを。



  • 道具室(アプリとか)

愚者のエンドロール (角川文庫)

愚者のエンドロール (角川文庫)

読み始めた...。

  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します)

画像は、amazonでのお買いもの。テキストリンクは、itunesでのお買いもの。


  • 視聴覚室

iTunesLantisとか買えないよね、今。
一体どういったことなのさ。

  • 調達室