開発のやり方は実践してナンボのものですから

システム開発方法論は“いつ”ちゃんと学んだのだろう
システム開発をするためには、プロジェクト管理手法のフレームワークの上に、こうやって開発するのよ、というお作法や段取りを決めてから取り掛かるものです。

エンジニア一人が、顧客もプロジェクトマネージャもエンジニアもマネジメントもやるなら必要ありませんが、報告する上司がいるだけで、その上司へ何をどうするのか見通しを伝えるために、“こうやって進める”という意思表示するための思想として必要になります。

多くのエンジニアは、組織に入り、新人研修と称して集合研修を受けているときに、「当組織では、ほぼウォーターオールでシステム開発を...」などと教授されただけで、そのあとは経験だけがシステム開発手法を学ぶ機会でしかない、のではないかと思うのです。

ワタシとウォーターフォールとの出会い
ご多分に漏れず、当のワタシも−記憶にはないですけれど−、新人研修なるものでウォーターフォールに出会っていたのではないか、と遠い目をするほかありません。
＃何せ、記憶がないのだから仕方がない。

きちんと“意識をして”学んだのは、大規模プロジェクトで標準化に出会ったときです。多分、ウォーターフォールも途中途中で知識をアップデートしていたり、RADなど出会っていたはずですが、斜め読み程度で流していたのだと思います。

作業品質を目的とした標準化の観点で、システム開発方法論が実践に投入されいるのを肌で感じ、それを実行してもらう側に立つと、よくエンジニアがルールを強制させられると感じる“やらされ感”は全くなくて、如何にして“使ってもらうか”が物事の基軸になるので、読み手であり実行するエンジニアとは制定する文書への理解度が全く違うものだと今でも思います。

気にしたことの一つには、利用者であるエンジニアの利用シーン、今でいうユーザストーリを意識したということです。実際にハンズオンするエンジニアが読み、実践するときに迷わないような構成になっているか、などはとても気にしたものです。

あの経験があってこそ、プロジェクトマネージメントをエンジニアリングだとかサイエンスだと思うようになったし、重厚長大なシステム開発手法を知ったことが、後にシステム開発手法は“適用するプロジェクトごとにテラーリングしてナンボ”と思うようになったものです。

どんどん違うものを取り入れる
で、自分の中でウォーターフォールは、一つの形に形作られていくわけですが、「このやり方が最高！」なんてこれっぽちも思っていないので、−節操がないとも言えるけど−、西に良いやり方をやっていると知れば聞きに行き、東に楽チンな管理のやり方があれば教わりに行き、と、自分のプロジェクトをどうやったら上手くいくか“だけ”が関心事です。

theory of constraintsザ・ゴール ― 企業の究極の目的とは何かなんて、割と出てすぐに読んで、−確か流れ化の話でしたね−、一つひとつのWBSにバッファを持たせたままでプロジェクトを実行していて、どうもうまくいかないケースがあるときがあって、その時に一つひとつに含まれていた小さなバッファを削って、WBSを正味の稼働だけに改めてから作業納期を指示して、削ったバッファをプロジェクトマネージャが全部握って対処したこともありました。それって、結果的にTOCをやっていたのかと。

知の学びと実践とスピードと
自分自身がプロジェクトマネージャをしていなくてもロールとしてプロジェクトに関与していれば、少し進捗が芳しくないケースがあれば、何が上手くいかない原因で、その原因を解決するための冴えたやり方がないかを探すのです。プロジェクトマネージャではないので、直接の当事者ではありませんがステークホルダではあるので、プロジェクトの負のリスクの変化がとても気になるのです。

目的は、プロジェクトをうまく回すために。オンゴーイングなプロジェクトなわけですから、何時までも探したり、勉強しているわけにはいきません。すぐに手を打たなければ、芳しくない進捗は悪化します。それを望んでいるわけではないので。

気を付けたい点は、プロジェクトの状況をよく見て、いきなり、やり方を大幅に変えない方が良いのではないか、ということです。進捗が芳しくない原因がシステム開発手法として間違っているような、大きな部分を占めるなら話は別ですが。まぁ、そこまで影響範囲が広がる前にリスクを検知することが小さな変更でプロジェクトの進捗を改善するコツでもあります。

こういったオンゴーイングなプロジェクトの手当てをすることは、知の学びと実践がほぼ同時に起こります。その場での行為には、影響範囲の特定と変更に適用するやり方の効果の見定めと、変更する行為のスピードが必要なのです。