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

ご存知の方も多いと思いますが、ここ最近、うちの会社の歌って踊れる DevOps エバの牛尾さんが、こんなエントリを書かれていました。 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い http://simplearchitect.hatenablog.com/entry/2016/06/20/080807 「自分で人生を決めない」ことが、決定的に業界の進化を遅らせているのかもしれない http://simplearchitect.hatenablog.com/entry/2016/06/24/080049 特に前者は炎上気味でしたが;、二回分のエントリを通して読めば、牛尾さんが言いたいことは極めてシンプルで、『変わらないのは回りのせいじゃなくて、あなた自身が変わらないせいだよね』(他責じゃなくて自責で考えよう)ということはわかるはず。伝え方の部分に関しては少し(いやかなり;)乱暴だとは思いますが、メッセージ自体は実におっしゃる通りで、耳が痛いという人もきっと多いと思います(私もそうです;)。そんな自由人な牛尾さんを見てすごいなぁとは思うものの、その一方で、はてブの反応を見ていると、そんなこと言ってもじゃあどうすればいいのよ? と思っている人も多いんじゃないかと思います。 もちろん本質的な意味で、人を成長させることができるのは、その人本人だけです。その人が自分の頭で考えて、自分の体で頑張るしかない。けれども、変われないと揶揄されている人たちだって、変わりたいと思っているけれどもきっかけやヒントが掴めなかったりして苦しんでいる人が圧倒的多数で、その苦しみの表れが、「現状や周囲に対する不満や文句」じゃないかと思うのです。だから、ちょっとしたヒントやきっかけ、ちょっとした環境変化、あるいは何かしらの実践可能かつ具体的なアイディアがあれば、それらを元に変われる人って実は多いんじゃないかな? とも思います。もともとこの話は先日の de:code 2016 のセッションで時間の関係上語れなかった後半のネタであること、また言いっぱなしで済まされない開発現場で生きてきたコンサルタントの自分としては、なるべくロジカルかつ具体的かつ実践可能なヒントやアイディアを提供したいと思ってこのエントリを書くことにしました。長文ですが、お付き合いいただければ幸いです。 なお念のため先にお断りしておきますが、私は本業のプロマネではなく、またこの手の話に唯一無二の正解は絶対に存在しません。数千万円の開発規模での常識が数十億円~数百億円の現場で通じるとは思いませんし、マイクロソフトのようなパッケージ製品開発の会社の常識や手法が、カスタム SI 開発の世界にもそのまま当てはまるとも思いませんし、契約形態にしろシステム特性にしろ成熟度にしろ、現場ごとに常識も違えばソリューションも違います。主にはエンプラ系 SI 開発現場を想定してこのエントリを書いていますが、個々の皆様の開発現場とはそぐわないところが多いと思います。そこは差し引いて読んでください。 とはいえ皆様一人一人が、自分のかかわるシステムの特性をきちんと把握し、自分自身の問題として何をどう変えられのか、誰に何をどうやって訴えかけるべきなのかをロジカルに考えることが最も大切です。そんなに簡単に物事は変わりませんが、それでも変えていく努力を続けることが、私は大切だと思います。 ■ V 字型モデル、ウォータフォール型開発、スパイラル開発、アジャイル型開発 話を始める前に、まずこれらの基本的な違いをシンプルに説明してみたいと思います。(※ 以下はわかりやすくするために超乱暴な議論をしています。そこは承知しているので、わかっている方は申し訳ないですが差し引いて読んでください。また、学術的な定義はズレてるかもしれませんが、このエントリではここに書く内容を定義として使わせてください。) 世の中には様々な開発方法論がありますが、どのような開発方法論であっても、その根底にあるものは V 字型モデル、すなわち段階的詳細化と段階的テストです。要するに、与えられた要件を段階的に詳細化してプログラミングし、出来上がったモジュールを、段階的にくっつけながらテストする、というモデルです。 この V 字型モデルの考え方、すなわちモノ作りは「設計」→「実装」→「テスト」によって行われる、という考え方は、ウォータフォールだろうとアジャイルだろうと基本的に変わりません。たまに勘違いしている人がいますが、アジャイルだって設計もするしテストもするし、必要に応じてドキュメントだって書きます。むしろこれらをないがしろにすれば、アジャイルでも品質があっという間に破綻します。(もちろん無駄なドキュメントは書かないようにしますが) では、ウォータフォール開発、スパイラル開発、アジャイル開発の違いは何かというと、複数の機能群を作らなければならないときに、これらをどのように並行開発するのか、という点に違いがあります。例えば、A~D の 4 つの機能を開発しなければならないときを考えてみます。 ウォータフォール型 4 つの機能を、いっせいに同期を取りながら、設計→実装→テストします。各作業が同期を取って進むために、プロジェクトの管理がしやすい(というかラク)というのが特徴です。 その一方で、「動くもの」が出来上がるタイミングがかなり遅くなります。このため、仕様ミスなどの発覚が遅れ、修正コストが高くつきやすくなります。また後から仕様変更が発生した場合も、仕様変更を取り込みにくいという難点があります。 スパイラル型 ……であるのなら、まず特に重要な機能(この図だと A, B)に絞って先に設計→実装→テストしてしまい、その後に残りを開発する、というモデルにすればよいはずです。これがスパイラル型開発です。開発リソースを A, B に集中できる分、「動くもの」が出来上がるタイミングはウォータフォールよりは早くなります。 しかしここで問題になるのは、『いくつのスパイラルに分割するのか?』です。「早くにとりあえず動くものができる」「仕様変更の取り込みタイミングが増える」というメリットを追求するのであれば、2 スパイラルよりも 3 スパイラルの方がよく、また 3 スパイラルよりも 4 スパイラルの方がよい、ということになっていきます。 アジャイル型…

0

de:code 2016 「拝啓『変わらない開発現場』を嘆く皆様へ」を担当して

実に2年ぶりのエントリになりますが;、今日はこちらの話題を。 少し前の話になりますが、5 月下旬に弊社イベント de:code 2016 で、ちょっと変わったセッション「拝啓『変わらない開発現場』を嘆く皆様へ ~エンプラ系 SI 開発現場の「今」を変えていくために~」を担当させていただきました。内容は、エンプラ系 SIer のプロパー(PL, PjM, SE)の方々向けに、設計やテスト手法の改善テクニックの要点などを通して、開発現場を改善していくための考え方を解説する、というもの。未来をお届けするイベントなのに最新技術を一切説明しないという異色のセッションにもかかわらず、参加者満足度(NSAT)ランキングで全 125 セッション中 2 位という結果になったことに大変感謝する一方で、私自身、いかに日本のエンプラ系 SI の闇が深いのか、を改めて実感することになりました。 セッションの内容については近いうちにテキスト化してこの blog にも掲載したいと思っているのですが、できればぜひ 1 時間ほど皆様のお時間をいただき、録画ビデオを見ていただければと思います。ダウンロード可能なので、通勤中にスマホなどで見ることも可能です。(はてブでは 100 人以上の方からブクマいただきました。ありがとうございます。m(_ _)m) そして、この内容がよいと思われた方は、ぜひ周りの方にこのビデオをそのままご紹介ください。特に SIer のプロパー(SE, PL, PjM)の皆様、そしてさらにその上司であるマネージャの方々に。 もちろん、現場の皆様ご自身がこうした訴えかけをロジカルかつ根気強く上申していくことが最も重要ですが、その一方で、「当事者が言っても意見を聞いてくれない」という話もよく聞きます。そういう場合には、外部の第三者の声をうまく使って伝えていくことも必要なのだと思います。ぜひ、そうした目的のためにこちらのビデオや資料をうまく活用していただければと思います。社内勉強会やコミュニティなどでもぜひご活用ください。 ……というわけで、ここから先は私個人の「つぶやき」です。(できればビデオを見た後に読んでください。)

2