続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール & アジャイル編~


ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。

特に前者は炎上気味でしたが;、二回分のエントリを通して読めば、牛尾さんが言いたいことは極めてシンプルで、『変わらないのは回りのせいじゃなくて、あなた自身が変わらないせいだよね』(他責じゃなくて自責で考えよう)ということはわかるはず。伝え方の部分に関しては少し(いやかなり;)乱暴だとは思いますが、メッセージ自体は実におっしゃる通りで、耳が痛いという人もきっと多いと思います(私もそうです;)。そんな自由人な牛尾さんを見てすごいなぁとは思うものの、その一方で、はてブの反応を見ていると、そんなこと言ってもじゃあどうすればいいのよ? と思っている人も多いんじゃないかと思います。

もちろん本質的な意味で、人を成長させることができるのは、その人本人だけです。その人が自分の頭で考えて、自分の体で頑張るしかない。けれども、変われないと揶揄されている人たちだって、変わりたいと思っているけれどもきっかけやヒントが掴めなかったりして苦しんでいる人が圧倒的多数で、その苦しみの表れが、「現状や周囲に対する不満や文句」じゃないかと思うのです。だから、ちょっとしたヒントやきっかけ、ちょっとした環境変化、あるいは何かしらの実践可能かつ具体的なアイディアがあれば、それらを元に変われる人って実は多いんじゃないかな? とも思います。もともとこの話は先日の de:code 2016 のセッションで時間の関係上語れなかった後半のネタであること、また言いっぱなしで済まされない開発現場で生きてきたコンサルタントの自分としては、なるべくロジカルかつ具体的かつ実践可能なヒントやアイディアを提供したいと思ってこのエントリを書くことにしました。長文ですが、お付き合いいただければ幸いです。

なお念のため先にお断りしておきますが、私は本業のプロマネではなく、またこの手の話に唯一無二の正解は絶対に存在しません。数千万円の開発規模での常識が数十億円~数百億円の現場で通じるとは思いませんし、マイクロソフトのようなパッケージ製品開発の会社の常識や手法が、カスタム SI 開発の世界にもそのまま当てはまるとも思いませんし、契約形態にしろシステム特性にしろ成熟度にしろ、現場ごとに常識も違えばソリューションも違います。主にはエンプラ系 SI 開発現場を想定してこのエントリを書いていますが、個々の皆様の開発現場とはそぐわないところが多いと思います。そこは差し引いて読んでください。

とはいえ皆様一人一人が、自分のかかわるシステムの特性をきちんと把握し、自分自身の問題として何をどう変えられのか、誰に何をどうやって訴えかけるべきなのかをロジカルに考えることが最も大切です。そんなに簡単に物事は変わりませんが、それでも変えていく努力を続けることが、私は大切だと思います。


■ V 字型モデル、ウォータフォール型開発、スパイラル開発、アジャイル型開発

話を始める前に、まずこれらの基本的な違いをシンプルに説明してみたいと思います。(※ 以下はわかりやすくするために超乱暴な議論をしています。そこは承知しているので、わかっている方は申し訳ないですが差し引いて読んでください。また、学術的な定義はズレてるかもしれませんが、このエントリではここに書く内容を定義として使わせてください。)

世の中には様々な開発方法論がありますが、どのような開発方法論であっても、その根底にあるものは V 字型モデル、すなわち段階的詳細化と段階的テストです。要するに、与えられた要件を段階的に詳細化してプログラミングし、出来上がったモジュールを、段階的にくっつけながらテストする、というモデルです。

clip_image001

この V 字型モデルの考え方、すなわちモノ作りは「設計」→「実装」→「テスト」によって行われる、という考え方は、ウォータフォールだろうとアジャイルだろうと基本的に変わりません。たまに勘違いしている人がいますが、アジャイルだって設計もするしテストもするし、必要に応じてドキュメントだって書きます。むしろこれらをないがしろにすれば、アジャイルでも品質があっという間に破綻します。(もちろん無駄なドキュメントは書かないようにしますが)

では、ウォータフォール開発、スパイラル開発、アジャイル開発の違いは何かというと、複数の機能群を作らなければならないときに、これらをどのように並行開発するのか、という点に違いがあります。例えば、A~D の 4 つの機能を開発しなければならないときを考えてみます。

clip_image002

  • ウォータフォール型
    • 4 つの機能を、いっせいに同期を取りながら、設計→実装→テストします。各作業が同期を取って進むために、プロジェクトの管理がしやすい(というかラク)というのが特徴です。
    • その一方で、「動くもの」が出来上がるタイミングがかなり遅くなります。このため、仕様ミスなどの発覚が遅れ、修正コストが高くつきやすくなります。また後から仕様変更が発生した場合も、仕様変更を取り込みにくいという難点があります。
  • スパイラル型
    • ……であるのなら、まず特に重要な機能(この図だと A, B)に絞って先に設計→実装→テストしてしまい、その後に残りを開発する、というモデルにすればよいはずです。これがスパイラル型開発です。開発リソースを A, B に集中できる分、「動くもの」が出来上がるタイミングはウォータフォールよりは早くなります。
    • しかしここで問題になるのは、『いくつのスパイラルに分割するのか?』です。「早くにとりあえず動くものができる」「仕様変更の取り込みタイミングが増える」というメリットを追求するのであれば、2 スパイラルよりも 3 スパイラルの方がよく、また 3 スパイラルよりも 4 スパイラルの方がよい、ということになっていきます。
  • アジャイル型
    • これを究極的に推し進めると、『重要な機能から、五月雨式に機能を作っていく』『必要に応じて随時、仕様変更を取り込んでいく』となるはずです。これがアジャイル型です。

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

  • ウォータフォールだろうがアジャイルだろうが、ある特定のひとつの機能だけ取ると V 字型モデル。よって、段階的詳細化と段階的テストをちゃんと実践できない人は、そもそもアジャイル云々以前の問題。V 字型モデルをちゃんと実践できない人がアジャイルに取り組もうものなら悲惨なことになります;
  • ウォータフォールからアジャイルに向かっていく際のメリットは、動くモノが早く出てくることと仕様変更の取り込みタイミングが増えていくこと。逆にデメリットは、プロジェクト管理が複雑化すること。例えば進捗管理で言えば、五月雨式に進んでるけどいつ終わるの? という質問にパッと答えにくくなりますし、変更管理で言えば、いつどこでも発生してくる可能性のある変更をどうやって管理するんだ? という話になります。これらをうまく管理しようと思うと、数値ベースのプロジェクト管理技術が必要で、昔ながらの KKD (勘と経験と度胸)に頼った Excel ベースのゆるふわプロジェクト管理では、全く歯が立ちません

clip_image003

様々な開発現場を見てきた経験から言うと、特に大規模開発では純粋ウォータフォール(=一発勝負での開発)でやっていることなんて皆無で、少なくともスパイラルに開発してたりプロトタイピングによってリスクヘッジしてたり、何らかの工夫をしているのが普通です。要件定義フェーズのみアジャイルで、以降の開発ではウォータフォール的に進める、なんていうこともよくあります。重要なのは、方法論の特性の違いを正しく理解し、対象システムや開発現場の特性、契約形態などに合わせて最適な方法論を使うことです。(少なくとも現時点ではそうしないと、実際のプロジェクトはうまくいかないです。十把一絡げに Scrum でいいじゃん! というわけにはいかないのが今の日本の実情です。それが必ずしも望ましいことだとは言いませんけれども。)

また、私の経験からすると、実際の現場はたいてい WF vs agile のレベル以前のところに大量の問題があります。すなわち段階的詳細化と段階的テストが正しくできておらず、V 字型モデルの作業でムリ・ムダ・ムラがめちゃめちゃあります。これは先日の de:code で話した通りで、このため、現在のウォータフォール/スパイラル開発のままでもまだまだ相当の改善の余地があります。というわけで、まずはアジャイル云々以前の話として、現状の開発作業のムリ・ムダ・ムラを取り除き、ちゃんと効率的な V 字モデルを実践できるようになってほしい、と思います。

……というわけで以上で終わりです、とか言うとボコボコにされそうなので;、以降はアジャイルの話にいったんフォーカスを絞ります。

 


■ 日本でなぜアジャイルが進まない?

よく言われることですが、日本でアジャイルが進まない原因のひとつに、SI の多重請負構造があります。まあ要するに、いつ終わるかわからない仕事を、完成責任を負わせられない形で任せるなんてできないよ! という話で、まったくもってごもっとも。そしてこの話になると、だから請負じゃなくて委任にすべきなんだ! 日本の悪しき伝統文化を終わらせるべき!的な議論とかが出てきて、信者同士の不毛な話になります。私は正直、そんな不毛な言い争いには全く興味がないというかそんな宗教論争みたいな話をしているからアジャイル技術の活用が進まないんだと思う)ので;、もうちょっと別の角度から話を整理してみたいと思います。

現場目線で言うと、アジャイルに関してはまず 2 つのレベル(粒度)に分けて考えた方がよい、と思います。

  • ①日常的なタスクといった細かい粒度でのプロジェクト管理手法としてのアジャイル
  • ➁サブシステム開発といった比較的大きな粒度でのプロジェクト管理手法としてのアジャイル

そしてもう一つ重要なポイントですが、一般論として、アジャイルは請負契約の境界を越えて適用するのが非常に難しい技術です。背景には、発注側と受注側の力関係による、変更管理の難しさがあります。

  • 例えばマイクロソフトのような内製中心の会社の場合、アジャイル技術や DevOps 技術を多用して、随時仕様変更を取り込むとともに、生産性を高めていくことは非常に有効ですし、やりやすいです。なぜなら、たとえ仕様変更が後から多発してお金が追加でかかってしまった場合でも、請負契約があるわけではないので、自社の中の問題として対処していくことができるためです。
  • 一方で、カスタム SI の請負契約の場合、ウォータフォールだろうとアジャイルだろうと、後から発生した仕様変更を正しく変更管理し、必要に応じて追加請求を行うことができないと、請負契約はあっさり破綻します。しかし、発注側が「アジャイル」という手法に最も期待するのは、「仕様変更をバンバン取り込んで、自分の望むものを完璧に作り上げてくれること」です。このため、ベースライン(どこからを変更とみなすのか? の基準となるもの)をきっちり合意し、そして発注側から要求される仕様変更をきっちり管理し、必要に応じて請負側からお金を追加請求できる状態になっていないと、うまくいくはずがありません。このことは、正直、仕様をかっちり決めてそれに基づいて進めるという合意があるはずのウォータフォールですら難しい(追加費用なしで後から仕様変更を無理矢理ねじ込まれる)のが実態なので、アジャイルであればなおさら難しいことになります。

ウラを返せば、アジャイルは請負契約の境界を越えなければ、適用するのが割と容易な技術です。例えば以下のようなケースを考えてみます。

  • エンド企業が SIer に対して請負契約で発注。
  • SIer が協力会社から開発者を準委任で集めてシステム開発を担当。(※ 実際には多重請負構造になっていることがほとんどですが、話を単純化するためにこの設定にします。話の本質がわかれば、ここがカスケードの請負契約になっている場合の解も論理的に検討できると思います)

clip_image004

この場合、最も簡単なのは、SIer + 協力会社の中に閉じてアジャイルプラクティスを回す方法です。


■ 請負契約の内部でのアジャイルプラクティスの活用

SIer + 協力会社の内部で作業効率を高めたい場合には、まず以下の 2 つの Agile プラクティスの活用がオススメです。前者の方が応用範囲が広いので、ここでは前者のみ解説します。

  • 日常的な担当者レベルの作業管理に Scrum のスプリントプラクティスを活用する
  • 実装作業において、CI/CD プラクティスを活用する

[Scrum のスプリントプラクティス]

Scrum って世の中でいろいろ説明されてるのですが、一般的な説明は正直わかりにくいと思うので、私なりの現場目線で Scrum のスプリントプラクティスを語ってみたいと思います。(専門家の方の中には「ちげーよ;」という方もいらっしゃるかもしれませんが、片目を瞑るぐらいで読んでいただけると助かります;)

  • まず、システム開発の作業を 1~3 週間程度の固定の長さ(スプリントと呼ばれる)ごとに区切る。(※ スプリント期間の取り方はフェーズや状況によりまちまちですが、基本的には比較的短めに切る。)
  • 各スプリントの初日のタイミングで半日程度をかけて、各作業者にそのスプリントに実施する作業タスクと、その作業時間の見積もりを作ってもらう。この際、各タスクは、1 タスクあたり最大でも 10h ぐらいになるまで細かく分解する。(スプリント計画ミーティングと呼ばれる)
  • 作業担当者には、毎日 1 回、帰り際に、「今日終わったタスクはどれか?」「明日やるタスクはどれか?」「終わらなかったタスクについては、あと何時間で終わらせられるか?」を報告してもらう。

プロジェクトマネージャは、残っているタスクの作業時間を毎日一回合算してグラフ化します。そうすると、下図のように「残りの作業時間がどんどん減っていき、スプリントの最後ではゼロになる(はず)」というグラフができます。このグラフをスプリントバーンダウンチャートと呼びます。

clip_image005

実際にやってみると、スプリントバーンダウンチャートはそんなに綺麗な図にはなりません。例えばこんな感じ。タスク見逃しで、なぜか途中で総作業残時間が増えたりすることもよくあります。また下図では示していませんが、各スプリントの最後で残作業時間がゼロにならない(=計画した作業が終わらない)なんてこともよく起こります。(※ この場合でも、スプリント期間を延長することはしません。終わらなかったタスクは次のスプリントに繰り越します。)

clip_image006

このスプリントの仕組みの最大のメリットは何か? いろいろ言われていますが、私が思う最大のメリットは、現場担当者のボトムアップの作業見積もりスキルを向上させることができるという点です。現場目線で言うと、このメリットの大きさは計り知れないモノがあります。少し補足すると、以下の通りです。

  • WBS に基づく見積もりを行う場合、一般的に見積もり手法には、トップダウンアプローチとボトムアップアプローチがある。このうち、一般的にはボトムアップアプローチの方が見積もり精度が高いと言われるが、実際にはうまくいかないことが多い。これは、現場担当者が普段から見積もり作業に慣れているわけではないために、やたらとバッファーを積んだり、逆にできもしない作業を少ない作業時間見積もりでできると言ってしまったりするため。結果的に、各作業者から提示された見積もり作業時間を、PjM が KKD で増やしたり減らしたりして使っているのが実態だったりします。
  • これに対して Scrum では、スプリント終了時に各作業者に振り返りをしてもらい、次のスプリントでの見積もりに生かしてもらう、ということをします。往々にして現場担当者は見積もりを大きく外すのが常ですが、同じタイムボックス(※ スプリントの長さは必ず一定)を何度も繰り返していれば、それなりに見積もりスキルが上がってくるはずです。
  • 現場担当者の見積もりスキルが上がってくれば、チームが 1 つのスプリントでこなせる作業量が正確に見積もれるようになってきます。それがわかると、スプリントを繰り返していったときに当該システムの開発が本当に期間内に終了するのかどうか、というのが見えてくることになります。(これをリリースバーンダウンチャートと呼びます。)

clip_image007

これが Scrum のスプリントの基本的な仕組みなのですが、このミクロスコピックな作業管理のやり方は、ウォータフォールなどの大きなレベルでのシステム開発の進め方と全く矛盾しません。ですから、例えばシステム開発全体のプロジェクト管理としてはウォータフォール的にやるけど、ミクロスコピックな日常的な作業管理としては Scrum でやる(それによって設計フェーズの作業がちゃんと期間内で終わるかどうかの予測が立てやすくなる)、なんていう組み合わせ方は、割と取り組みやすいアジャイルプラクティスの導入方法です。

……一流のアジャイラーとかからすると眉間に皺を寄せられそうな断片的な使い方かもしれませんけど;、実際の現場経験からするとこれだけでもかなり効果絶大なのです。いやだって、現場エンジニアって割といいかげんな作業計画で日々の仕事を進めていることが多いので、毎週の仕事をきちんと宣言してもらって予実管理するだけでも、ものすごい効果があるのですよ^^。

[スプリントプラクティス導入時の 2 つのポイント]

ただしこのスプリントプラクティスを導入する際には、いくつか注意点があります。中でも大きいのは以下の 2 つです。

  • タスクボードなどを導入し、作業者と PjM にほとんど負担をかけずにバーンダウンチャートを作る必要がある。
  • PjM/PL は、メンバーのやる気やモラルを最大限に引き出すことに注力する必要がある。

まずはタスクボードから。タスクボードとは、作業内容と残作業時間を書き出した付箋紙をホワイトボードに貼り付けたようなもので、3 つのレーン(未着手、作業中、作業終了)間で付箋紙を移動していくというものです。各作業担当者は、毎日、帰りがけにこの画面を開き、付箋紙をレーン間で移動させ、終わっていないタスクについては残作業時間をアップデートします。そうすると、システムがこれを自動集計してバーンダウンチャートを作ってくれます。超便利 & 超らくちんです。

clip_image008

タスクボードは、マイクロソフト製品だと Team Foundation Server 上に実装されており、オンライン版(Visual Studio Team Service)であれば 5 ユーザまで無償で使えます。めちゃめちゃ素晴らしいツールなのですが、より詳細な使い方についてはここでは説明しませんので、DevOps エバの牛尾さんに聞いてみてください。(ぉ

ちなみにこのタスクボードの仕組みから理解していただけると思いますが、Scrum のすごいところは、プロジェクト管理の仕組みの本質を捉えることで、非常にシンプルな「残作業時間の足し算」という仕組みだけで、手間をほとんどかけずに、プロジェクトの状況のリアルタイム把握を可能にした点です。もちろん、大規模システムへの適用などに関してはそんなに単純ではないのでいろいろ工夫が必要なのですが、KKD、あるいはやたらと複雑な仕組みを使いたがるプロジェクト管理というものを究極的に単純化し、数値ベースでの管理を実現した、という功績は非常に大きいです。初めてこの仕組みを知ったときには舌を巻きました。これ考えた人、マジで神だと思いますよ、ええ。

もう一つ、この仕組みが機能するための絶対必要条件は、各作業担当者から申告される残作業時間に、嘘偽りがないことです。当たり前ですが、実際には 3 時間で終わる作業を 10 時間と報告された瞬間に、このプロジェクト管理の仕組みは破綻します。しかし、もし各人が誠実に自分と向き合い、正しく作業時間を報告したとするのなら、自分のパフォーマンスを正確に知ることができますし、また自分のパフォーマンスが伸びたことも明確に数値に現れます。かつて 10 時間かかった作業が、スキルアップで 5 時間で終わるようになったら、エンジニアとしてはうれしいに決まってますよね^^。

しかし皆様もご承知の通り、普通、現場メンバーは馬鹿正直にかかっている工数を報告したりなんてしないのが普通です。なぜって、馬鹿正直に報告すれば、その分、上からの締め付けが厳しくなるだけだからです。

clip_image009

一般に、多重請負構造を基本としている日本の開発現場には、職種による階級制度が引かれていることがほとんどです。プロマネが一番偉くて、次に SE、そしてデベロッパー、テスターは最下層、なんていうことが一般的でしょう。しかしこうしたピラミッド型の組織構造、すなわちロール間に職能的上下関係が存在すると、モラルハザードが起こりやすくなり、上の人間は権力を振りかざし、下の人間は事実を隠ぺいするようになるのが普通です。これでは Scrum のプロジェクトマネジメントの仕組みがうまく機能するはずがありません。

こうした問題を踏まえ、Scrum(というかアジャイル)を実践する組織では、フラットな組織構造(チームモデル)とするのが基本です。職種の違いは役割の違いであるとして互いが互いを尊重し合い、悪いことも包み隠さず正直に言える環境がないと、現場から正しい数字は出てきません。このため PjM の人は、指示命令を与えることが仕事ではなく、むしろ現場の他のメンバーの人たちにいかに気持ちよく働いてもらい、いかにメンバーのやる気やモラルを最大限に引き出すかに注力することになります。

現場のメンバーの人たちに気持ちよく働いて最大限のパフォーマンスを発揮してもらえるように、リーダーの人は、メンバーの人たちの奴隷になって働く。それによってチームとしての結果を出す=リーダシップを発揮するわけです。この考え方をサーバントリーダシップと呼びます。

……もっとも、トップダウン型組織よりもフラット型組織の方が常に素晴らしいかというと、そういうわけではない、という点には注意してください。一般的に、トップダウン型組織は有事に強く、フラット型組織は平時に強い組織モデルです。要するに、指揮命令系統がはっきりしていると、戦争のような有事のときには軍隊のようにがちっと動けるけれども、逆に現代のような時代の場合には、末端の一人ひとりが自発的に考えて動いてもらわないと困るので、末端の人たちが考えて自由に動けるフラット型の組織モデルの方が強くなる、ということです。

また、日本の場合、給与モデルが職種によって階層化されていることが多い、という大きな制約事項もあります。簡単に言うと、優秀なデベロッパーよりも無能なプロマネの方がお金をもらっている、という話なのですが、これは欧米には当てはまりません。欧米では、優秀なテスターは新人のプロマネよりも高い給与をもらっています。組織モデルを考える際、給与モデルと切り離して考えることはできないことがほとんどです。こうした背景もあり、現時点の日本においては、トップダウン型組織構造とフラット型組織構造との間の折衷案を使うのが現実的なことが多いです。

ただ、最も重要なことは、仮にトップダウン型組織構造に近いモデルであったとしても、現場の他のメンバーの人たちにいかに気持ちよく働いてもらい、いかにメンバーのやる気やモラルを最大限に引き出すかが PjM の重要な役割になる、というポイントはきちんと押さえておく必要があります。

[近代的な『プロマネ』技術の必要性]

こうして考えると、現代のプロマネには、昔からあるような PMBOK 的なスキルセットはもちろんですが、それに加えて、計数ベースのプロジェクト管理技術や、モダンなサーバントリーダシップ的な考え方と対人スキルが求められると言えます。請負契約の契約境界の内側の方がアジャイルプラクティスは実践しやすいと思いますが、その際であっても、プロマネ技術の近代化が必要になってくると思います。


■ 請負契約をまたがる場合の考え方

先に述べたように、原理的に、請負契約をまたがる形でアジャイルプラクティスを実践していくのは非常に困難です。それは、発注側が「アジャイル」という手法に最も期待するのは「仕様変更をじゃんじゃん取り込んで、自分の望むものを完璧に作り上げてくれること」である半面、「請負契約」ではきちんと「範囲(仕様)」を決めて請け負う必要があるためです。仕様変更の管理と仕様変更に伴う追加請求が正しく機能しないと、原理的に、顧客が期待するものと発注方法とが矛盾してしまうからです。

clip_image010

ではどうすればよいのか? 上で述べた、請負契約とアジャイルが相反する理由を元に考えると、基本的な選択肢は以下のようなものになります。どれがよいのかはケースバイケースですが、いずれの方式も、エンプラ系企業では導入ハードルがかなり高いです。

  • エンド企業が、自ら内製に取り組む
    • 社内に開発リソースを持つか、あるいは請負契約ではなく準委任のような発注形態を取るようにして、自分たちで自ら開発の手綱を握る、という方法。
    • よく言われる方法である半面、現実的にはエンプラ系だとそのままでは取り組みが難しい方法。
      • 例えばオンラインゲームのように、自らがサービス提供者であり、かつ高速な開発とインクリメンタルなサービス増強を続けなければ生き残れない場合には、必然的に内製化や DevOps が進むが…
      • 多くのエンプラ系企業では、そもそもシステム開発そのものは戦略事業ではなく、システムを作ること自体は SIer または SI 子会社にアウトソースしたいというのが普通であるため。
    • やるとしても、コンシューマ系のサービスや小規模システムなど、取り組みやすいものから始めるのが現実的。
  • SI 企業側が請負型カスタム SI をやめ、SaaS 型でのサービス提供を行う
    • 請負型カスタム SI は、お客様の要求に振り回されることが多い。このため逆転の発想で、SaaS 型サービスにすることによって、開発のコントロールを自社側に持ってきてしまう、という方法。
    • カスタマイズ型パッケージ SI 製品の場合には実際に採用可能な戦略で、過去いくつかのお客様でこの手の戦略を聞いたことがあります。
  • エンド企業と SIer との間で、変更管理をきちんとやる
    • アジャイル型でシステムを段階的に構築していく場合であっても、そこに対する仕様変更についてはきっちりとお金をいただく、ということを最初にきちんとネゴる方式。
    • 理屈上は契約書で縛れるはずだが、現実的にはエンド企業と SI 企業との間の力関係によっては全く機能しないモデル。
    • さらに、実際にこれが成立するためには、エンド企業と SI 企業とが対等な関係であることはもちろんだが、それに加えて小規模ロットの見積もりがきちんと素早く精緻に行えること、そしてその見積もりに対して速やかに逐次で契約処理できるようになっていることが必要。これもまた実際にはハードルが高いです。

もしこの記事を読んでいる皆様が意思決定者またはそれに近いところにいる方であるのなら、上記のようなことを考えて部分的にでも実践するのは非常によいことだと思います。一方、皆様が現場担当者だとすると、これらを解決するのはかなりハードルが高いです……というよりほとんど無理;。うっかりすると、転職するのが最適解かもしれません。(※ 別に転職を薦めているわけではないです、念のため;。)

ただ、最初の議論に戻りますが、そもそも我々にとってアジャイルは手段であって目的ではない、ということは理解する必要があります。アジャイルの導入目的や効果はいくつもありますが、同じ目的や効果を狙う手法はアジャイルだけとは限りません。例えば…

  • 仕様変更を高速に取り込んですぐにリリースできるようにする。(オンラインゲームみたいなケース)
    • この場合は、そもそも開発リソースを社内に抱えて、内製化を強力に推進すべきです。
    • ……というよりこのケースは、すでに内製化を進めて DevOps とかやってるケースがほとんどでしょう。
  • よりよいサービスやよりよい業務アプリを、より安価に作りたい。
    • 業務アプリの品質の良し悪しは、業務設計の良し悪しによって大きく左右される。なので、要件定義フェーズ+プロトタイプ開発のみ切り出して、準委任+アジャイルでやればよい。要件が早期の段階できっちり煮詰まれば、後ろのフェーズの手戻りも必然的に減るので、構築をウォータフォールでやっても開発リスクなどは下がる。
    • 「安価に作る」ことに関しては、開発プロセスの無駄を取り除くことでもまだまだ実現できる余地がある。典型的には、発注側が要求している無駄なドキュメント納品物を割愛するなど。(ただし発注側と請負側の両者が Win-Win にならないとうまくいかないので、実際には何らか一工夫が必要)

他にもいろいろあると思いますが、ただ、アジャイルを導入したいという前に、そもそも何を目指したいのか? をはっきりさせましょう。日本はソフトウェア開発の後進国で、欧米からは 5~8 年ぐらい遅れているわけですが、もしそうだとするのなら、型落ちの改善手法でも十二分に改善できる可能性はあるのです。欧米の最新手法がそのまま導入できればそれに越したことはないかもしれませんが、Fit & Gap が大きすぎるから今のままでもいいや、となることの方がよほど大きな問題です。少しずつでもよいから改善していくこと、これを常に念頭に置いていただければと思います。いやー、実際の開発現場なんて、そんなすぐに改善できませんって、ホントに;。


■ でもって、どこから始めるの?

というわけでいろいろ書いてきましたが、上の方に書いた、「システム開発を請け負う側の内部に閉じてアジャイルプラクティスを使う」ことや、「ウォータフォール型による全体管理と、ミクロスコピックな Scrum スプリントプラクティスを組み合わせる」ことは、エンプラ系開発現場でも割と取り組みやすい手法だと思います。使えそうであれば、ぜひ使ってみてください。

 


■ 『変わらない開発現場』を嘆く皆様へ

なんかいろいろ書きたいことがたくさんありすぎて、ぼろぼろと重要なことを書き漏らしている気はするのですが;、その辺は皆様からのコメントで補完していただくことにして、最後につぶやきを少しばかり。

別に私はアジャイラーでもなければアジャイル信奉者でもなんでもない(使えるのであれば使うというスタンス)のですが、アジャイルの考え方の中に、私が非常に大好きなところがあります。それは、「人」を信じて、「人」の能力を最大限に引き出し、そして育んでいこうとするところ。アジャイルは基本的に性善説に立っており、「その人の善なる部分をいかに引き出すか?」「いかに人を成長させていくのか?」というところにものすごく腐心している、と思うのです。

翻って、日本の開発現場ってどうでしょうか?

例えば「開発標準」や「フレームワーク」といった言葉。もちろん今でも重要だとは思うのですが、最近、日本でこの言葉を聞く場合、そこにはこんな話がついてきます。「スキルの低い人であっても、一定の品質のアプリになるようにするものです」と。これ、今どきの開発の考え方として、本当に正しいんでしょうか?

スキルが低い人に、「何も考えなくてもモノが作れるツール」なんてものを与えたら、その人はますますモノを考えなくなる。それは単なる『生殺し』に他なりません。そしてモノを考えない人を増やし続ければ、結果的にはその人たちを潰してしまうばかりでなく、巡り巡って自分たちに跳ね返ってきます。確かにすべてのエンジニアのスキルが高いとは思いませんし、すべてのエンジニアのモチベーションがめちゃめちゃ高いとも思いません。残念ながらそれは事実でしょう。だけれども、大半の下請けエンジニアのスキルはおしなべて低い、という「前提条件」を常に引き、下請けエンジニアを「人手」とみなす、旧態依然とした考え方が横行していることにも問題がある、と思うのです。

たとえそこに受発注、あるいは職種という上下関係が存在していたとしても、同じゴールを目指す仲間として、互いを尊重し、高め合うような人間関係に育まれた開発現場がもっと増えてほしいと切に願いますし、そのためのアイディアや情報が世の中にもっと増えてほしい、と思います。(エバと違ってコンサルは情報発信が本業ではないので、なかなか blog が書けないのは恐縮なのですが;。ごめんなさい;。)

そういう意味で最初の話に戻りますが、変わりたいと思っている、けれどもどうすればいいのよ? と悩んで具体的な手法やヒントを欲している人や開発現場はきっと多いはず。そして多くのエンプラ系開発現場(そして人生)は、大量のしがらみと、ほんの少しの、物事を変える勇気からできている、と私は思います。このエントリであれこれ書いた話が、『変わらない開発現場』を嘆く皆様が物事をどう変えていくのかを考える際のヒントになれば、そして実際に一歩目を踏み出す手助けに(少しでも)なれば幸いです。


※ やや蛇足的ですが、おまけエントリを書きました。意思決定者への伝え方に悩まれている方向けのエントリです。よろしければこちらもどうぞ。
「『変わらない開発現場』を変えていくために。」
https://blogs.msdn.microsoft.com/nakama/2016/07/03/nextstep/


Comments (0)

Skip to main content