素人なので短期間でのアジャイルなエンジニアの育成方法を教えていただけませんか

アジャイルなエンジニアの育成は素人なので、ぜひ教えを請うことをご了解いただきたい。

tech.nikkeibp.co.jp

ところで、アジャイル開発には『アジャイルマニフェスト』というものがあり、度々引用されるので食傷気味かもしれない。もし、知らなければこれを機会にリンク先をご覧いただければと思う。

アジャイルマニフェストを読むと短い文章である。それでも、たった下記の数行で従来のSI案件の価値観とは違う方向性を持っていると認識している。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。

従来のSI案件の契約は適用できない。何より、顧客も契約や役割分担などでの振る舞いを変えてもらわなければならない。一番変わらなければならないのはエンジニアや営業であることは間違いないが。

このアジャイルマニフェストで誤解され易い一文がある。それは2行目であることは有名かもしれない。これは決して『アジャイル開発ではドキュメントを作らないと言っているわけではない』ことに注意が必要である。

必要な文書は作るし、契約で顧客が求めれば話は変わってくる。必要なものは作るが、価値のない文書は作る必要がないということだ。

価値を知りたければ右辺を下から読めばいい。変化に対応できているか、顧客と協調しているか、動くソフトウェアをリリースできているか、対話を行なっているかを自問するのである。

アジャイルマニフェストはこのくらいにして、ベンダやSIerに重くのし掛かるのは『アジャイル宣言の背後にある原則』である。こちらもしばしば引用されるのでその内容に胃もたれされているかもしれない。こちらもご存知でなければこの機会で一読されると原則の濃厚さをご理解いただけると思う。

自分は素人であるから、この原則をある程度実務で実行できるエンジニアを育てるには相応の時間とバジェットを要求するだろう。間違っても、集合研修を1回や2回受講した程度ではアジャイル開発を出来るエンジニアだと他所様には言えない。

引用　Q2 顧客システムのアジャイル開発プロジェクトに携わるエンジニアの数 | 日経 xTECH（クロステック）

さすが、日本を代表するベンダである。どうやってアジャイル宣言の背後にある原則を実行できるエンジニアをお湯をかけて待てば出来上がるように量産できるかを教えて欲しい。

従来のSI案件では、受け身で、指示待ちで、決められたスコープで、作業を工程で分断して、長い開発期間で、文書を求められるがままに作るエンジニアが重宝がられている印象を持っている。それが自分の間違った理解なら問題ないのだろう。

ただ、自分の経験としてSI案件をやっていたエンジニアのマインドを謂わゆる超上流のIT企画の業務を遂行できるように意識を変えるだけで数年かかっている（それでもまだ十分ではない）ことを念頭に置くと、一度刷り込まれた開発手法やプロジェクトマネジメントは早々変わらない。行動様式として意思決定の判断基準がそれになってしまっているからである。それはそう易々とは置き換えられない。

もしかすると、既にアジャイルなエンジニアをスタンばらせているのかもしれない。であれば、さすがベンダである。