変わらないエンジニアのみなさまへ

on


昨日の英国のEU離脱決定を受けた為替市場は急激な円高に向かっていますが、個人輸入を時々しているわたしにとってはこれ幸いなのです。$1=80円のときなんて、$1=100円と比べたらいつでも2割引の感覚でお買い物できるし、anual saleのときはそこから25%や40%になるのでfedexの送料や関税を支払っても国内で買うのが馬鹿らしくなるんですよね。プロジェクトマネージャの認定のPMPの更新料も同じなのですよ。更新するときだけは円高になって！って思う。ちょうど、イヤフォンのコードの皮膜が切れてきたところだったのでamazon.co.ukでお買い物。国内正規価格の2/3だもの。並行輸入より3Kくらいやすいし。


さてさて与太話はここでおしまいで、例のアレがらみで新たなエントリがあったのでそれを下敷きに。引用しているエントリ、なかなか良いと思います。例のアレの書き手の方と同じ会社のようですし、いろいろ気遣いかながら書いている感じが大変好感が持てますねー。


さて、普段わたしが言っていることと同じことを言っています。それは、ウォーターフォール（アジャイルでもいいけれど）ひとつ、ちゃんとできないシステムエンジニアにアジャイル（アジャイルの場合はウォーターフォール）ができるわけがない。

こういう構図で考えた場合、ウォータフォール型開発とアジャイル型開発の基本的な相違点として、以下があることがわかります。

ウォータフォールだろうがアジャイルだろうが、ある特定のひとつの機能だけ取ると V 字型モデル。よって、段階的詳細化と段階的テストをちゃんと実践できない人は、そもそもアジャイル云々以前の問題。V 字型モデルをちゃんと実践できない人がアジャイルに取り組もうものなら悲惨なことになります；。
続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール ＆ アジャイル編～ – とあるコンサルタントのつぶやき


アジャイル開発というよりは、プロダクトバックログの優先順位の考え方やWIPやカンバンの考え方が好きなので、ときどき勉強会に行くのですがそうしたところでの恣意的なウォーターフォールvsアジャイルの環境を作って一方的にウォーターフォールなんて、と言っているシステムエンジニアには

「別におじさんは困らないけれど、キミたちはプロジェクトの特性で選択することになるシステム開発手法に対応できるのかな」


と内心思っているのです。余計なお世話ですが。ウォーターフォールやアジャイルはシステム開発手法であって、単なる手段です。それを叩いで世の中が変わるのでしょうか。叩いているあなたのプロジェクトが良い方向に変化するのでしょうか。


１ミリも変わりません。


それより叩いているシステムエンジニア自身のプロジェクトに対する姿勢が悪くなりますよ。だって、好きなんじゃないんですから。少なくとも、ニュートラルな気持ちでいないと好きにもなれないんですよ。知り合い、友達から好きなところに気づいて片思いするのと同じですよ。


上記の引用では、ろくにウォーターフォールもできないシステムエンジニアがアジャイルを始めたら「悲惨になる」とかなり優しい言葉を選んでいますけど、わたしがプロジェクトマネージャならお作法程度のウォーターフォールの所作ができないシステムエンジニアなんてご縁がありませんでした、と退場を謹んでお願いするところです。


ウォーターフォールでのシステム開発は労働集約型でのプロジェクトが多いですから、スキルやスキルレベルが多少歪でもプロジェクトチームの人数が多いので自然とカバーし合っていることをそろそろ気がつかないといけないのです。


言い換えれば、キミはできていると思っているかもしれないけれど、プロマネから見たら一人前の貢献もできていないところを他のメンバが補っているんだよ、ということです。そういったことを前提に「チームとしてのスキルセット」が揃うようにチーミングしているのということをマジで認識してほしいものです。


繰り返しますが、キミ自身が気づかなくてもこちらは困らないのです。チームとしてスキルセットが成立しているから。でも、個々人の単位で見たら、キミの価値はそれほどないことにキミ自身が気づかなければ、一生勘違いしたままなんだろうし、６０歳くらいになっても指示待ちシステムエンジニアになってしまうかもしれないんだけれど、それはキミのマターなので言及しませんです、はい。


こうした自分のスキルの評価をできないとか、プロジェクトが上手くいかないことをシステム開発手法に押し付けているシステムエンジニアは、イメージだけでアジャイルに手を出すと火傷をします。



例えばスクラムの最適なチームメンバは５人±２人とかいいますね。そのとおりだと思います。でも、現実のプロジェクトだと５人より少ないチームで組むプロジェクトもあります。この時チームで何が起きるか。


わたしの経験からも少ない人数のチームは、トラックナンバーの問題が如実に現れます。チームメンバの人数の母数に対する１人の占める割合が大きくなるからです。当たり前です。１０人のチームに占める割合と３人のチームに占める割合は全然違います。


必然として、一人が「マルチ」で動けないければチームが回らないし、動けるためには相応の技術やマインドを持っていないとチームが歩きもできないのです。ちなみに、この少人数のチームメンバに対する少数だからこそ精鋭化しなければチームが成り立たない、ということの本質は、アジャイルだろうがウォーターフォールだろうが同じです。というか、アジャイルは精鋭を前提にしているんですよ。


そこにはシステム開発手法にケチをつけているようなシステムエンジニアには入る余地がないのです。


たまたま、わたしはそのようなビジネスを長い間マネジメントしていたのでプロジェクトマネジメントの観点やシステムエンジニアの技術的な育成の観点でどうしたら上手くいくか多分他の人よりは「チョットデキル」かなぁ、と思っていたりします。


でも、こうしたことを教えてくれる本はほとんどなくて、唯一あるのがこれくらいしか知らない。


そろそろ気づきた方が良いと思いますよ。