「アジャイル開発から要件定義・設計重視な開発への回帰(1/2)」社内プロジェクトマネジメント勉強会第2回前半
こんにちは、リチャード 伊真岡です。私が勤務しているマーベリック株式会社で行ったプロジェクトマネジメント勉強会第2回の内容についてブログに書き起こします。内容が長くなったので記事は2分割し、今回はその前半部分に当たります。前回同様、この勉強会は社内有志メンバーで業務時間外に行い、また業務機密を一切含まない内容なので私の個人ブログに掲載しています。
第1回の内容はこちら、
以下勉強会の発表内容です
どうも、今日もまた15分という短い時間でリチャードがITのプロジェクトマネジメントについてお話しします。今回はアジャイル開発から要件定義・設計重視開な発へ回帰、というタイトルです。営業や企画職の参加者のみなさんは、アジャイル開発に馴染みが薄いかもしれないので、簡単にアジャイルの歴史を説明したあとで、それに対する批判と、そこから見えてきた現代のソフトウェア開発の方向性のひとつをお話します。
それでは勉強会前半の内容をどうぞ!
アジャイルソフトウェア開発宣言
西暦2000年より以前、つまり20年前より昔のソフトウェア開発は、
- ソースコードを書く前、要件定義や設計に時間がかかる
- にもかかわらず、ソースコードを書きはじめた後で問題が多数見つかる
など大変非効率であったと言われています。そこで2001年に当時気鋭のソフトウェア開発者たちが集まって、「アジャイルソフトウェア開発宣言」というものを出します。
当時業界で似たような思いを持っていた人々は少なくなく、アジャイル開発はほどなくして広くソフトウェア開発の世界で浸透し始めます。アジャイル宣言の文言には要点が4つ述べられていて、
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
いずれも左の価値を認めながらも、右により価値をおくというものです。
しかし画期的な概念や手法が広まる際にありがちなことですが、熱狂的に受け入れられる一方で妙な誤解をされたり、アジャイルをかさにきて他者に攻撃的になるなど、困った人たちも出てくるものです。日本ではよくある例として「アジャイル vs. ウォーターフォールという謎の空中戦」が繰り広げられたり「一部の人々がSIerをバカにする間違った風潮」が今でも観測されます。
また「アジャイル狂信者問題」、つまり度を越してアジャイルを信奉する人々の間で**「アジャイル開発が成功すればアジャイルのおかげ、失敗すればアジャイルの理解が足りなかっただけ」で議論を片付ける**という、現実の問題をつぶさに分析することから目を背けて、アジャイルが絶対的な正義であるという結論ありきな態度が見受けられます。
こういった正当な批判にさらされていない一部のアジャイル開発に関する主張に対し、疑問を呈するエンジニアもいます。上下巻で1700ページを超える「オブジェクト指向入門」の著者として高名なバートランド・メイヤー博士は、別の書籍「アジャイルイントロダクション: Agile開発の光と影」の中で明確に批判しています。
メイヤー博士はアジャイル開発手法の、全部ではなく一部のみについてですが、「新しい手法ではないし、よい手法でもない」と言い、またアジャイル関連書籍で述べられる主張は論拠が乏しく、誇張を含むものが多いとしています。
誇張に関する問題は少なくない人々が認識しています。新規にアジャイル挑戦する人々の間では、その画期的な手法に魅了されたものの、思ったほど成果があがらず、後からデメリットや適用しづらいケースに気づき始めるというのが典型的です。そしてコミュニティのごく一部が過度に熱狂的であったり、批判に正面から向き合わない態度に嫌気が差す、というサイクルがは何度も繰り返されてきたので、数年おきに「アジャイルは死んだ」という主張をする人たちが出てきます。
- 2011 Agile is Dead - Craig Noil
- 2014 Agile is Dead (Long Live Agility) - Dave Thomas
- 2019 The Death of Agile and Beyond
2020年のアジャイル界隈はどうなっているのか？
熱狂的にアジャイルを信奉するのもバランスを欠く態度ですが、アジャイルが死んだとするのも極端な表現で、現実的ではありません。むしろアジャイル開発手法を部分的に取り入れている会社は今では非常に多くなっています。
アジャイル開発の2大手法といえばスクラムとカンバンですが、それぞれ最初の発表から20年、10年経っています。実はスクラム手法自体、カンバン手法自体はそのころから大きく変わっていません。
- 1999年: Extreme Programming Explained
- 2001年 Agile Software Development with Scrum
- 2010年 KANBAN
- 2011年 THE LEAN STARTUP
一方その間に、クラウドやモバイルに代表されるように、ソフトウェアが使われる環境は劇的に変わりました。プログラミング言語も大幅に進化し、開発ツールチェインもGitHubであったり、Continuous Deliveryであったりと登場時画期的であったものが今では当たり前になりました。20年前、10年前と比べてもソフトウェア開発を取り巻く状況は全く違うものになっているのです。
これだけ大きな環境の変化を経たので、現代の開発でアジャイルを取り入れるには、20年前、10年前の手法を教科書どおりに取り入れるのは難しく、今の技術や環境に合わせてアレンジしなければなりません。現代のソフトウェア開発でアジャイルをうまく取り入れている人々は、この理論と現実のギャップをしっかり認識しているはずです。
どんな業界でも似た構造が観測されるかもしれませんが、トップ層の人々はアジャイル開発手法だけでなく現代のソフトウェア開発技術に広く精通し、その下の層の人達はずっと昔と同じ古くなってしまった主張を今も繰り返している、というのが私の現状認識です。
ここで言うトップ層、長期間に渡って技術的にも商業的にもソフトウェア開発を成功させているプロジェクト・マネージャー達は日本にもたくさんいます。例えば私が講演を聞いたり著書・資料を読んでいつも参考にしている方々は:
- 市谷 聡啓さん @papanda ギルドワークス / 政府CIO補佐官
- @daiksy さん 株式会社はてな Mackerel ディレクター 認定スクラムマスター
- @songmu さん Nature株式会社 取締役CTO 認定スクラムマスター
- 黒田樹さん @i2key リクルートテクノロジーズ執行役員 認定スクラムマスター
- 鈴木雄介さん @yusuke_arclamp グロース・アーキテクチャ＆チームス（株） 代表取締役社長 日本Javaユーザーグループ サブリーダー
(もちろん、他にもたくさん)
アジャイル宣言の「左側の価値を認めながらも、右により価値を置く」ことへの疑問
ここからは私の持論です。アジャイルソフトウェア開発宣言を紹介した時、下図の4つの点について、左側よりも右側に価値を置くのがアジャイルだと述べました。
2000年当時は「左より右」が成り立っていたのかもしれませんが、
先程の技術や環境の大幅な変化を踏まえると、現代では左側を効率良く行うツールが多数登場したため、**左と右がだんだん等価になってきたのではないか？**ベスト・バランスが移動したのではないか？というのが私の見立てです。
1点目の「プロセスやツールよりも個人と対話を」については、SlackやZoomなど対話ツールが進化し、 実は個人との対話はコストが高い ことがわかってきたのがこの20年だったと思います。コストが高い割に、ウェブによる情報流通の加速にともなって知識それ自体の価値が下がり、「個人の頭の中に競争優位となる知識があり、対話でそれを引き出す」ことが成り立たなくなってきた開発の現場が多いでしょう。
情報自体の価値は下がる一方、それを文書にして整理・共有し、業務プロセスに組み込むまで昇華できる組織は競争力を高められます。いわゆる形式知です。それにはGoogle Docsなどの文書共有のツールとプロセスを整備した方が、個人間の対話を重視するよりはるかに効率がよいでしょう。
2点目の「包括的なドキュメントよりも動くソフトウェアを」は、2000年頃はソフトウェアがまともに動くだけで価値が高かったのかもしれませんが、今の時代ソフトウェアは動くだけではダメです。すっかりソフトウェアに対する要求基準は上がってしまいました。
ドキュメントを充実させることはソフトウェアの品質を向上させることにも重要な意味があります。ここ数十年大きく発展し続けてきたオープンソース・ソフトウェア群からは品質の高い物がいくつも生まれ、品質の高いオープンソースのプロジェクトはほぼ例外なく充実したドキュメントを残しています。とくに私が知る中ではMySQLのリファレンスは網羅性と情報の質で、世界で最も優れた技術文書の一例と考えています。
社内開発用のドキュメントに有名オープンソースと同等の品質を求める必要はありませんが、適切なコミュニケーションの手段として大いに見習うべきところはあるでしょう。Googleも社内向け開発ドキュメントの重要性を認識していて、Podcastでそれを浸透させる取り組みとまだまだ浸透しきれていない苦労を紹介しています。
3点目の「契約交渉より顧客との協調を」については省略します。
最後に4点目「計画に従うことよりも変化への対応を」については、前回のブログで紹介したように「開発終盤での作り直しが当たり前」の時代になりつつあるからこそ、逆説的にしっかり計画をたてる能力がやり直しを可能にすると考えています。やり直し！となった後でも計画が必要なことは変わらないので、素早く良い計画を作る能力、ここでは要件定義や設計と捉えますが、そこを鍛えていかなくてはなりません。
最近は要件定義や設計など、開発プロジェクトの中で早い時期に行う作業に比重を移すほうがリターンが大きく後工程がスムーズになる技術やプラクティスが広まってきました。
設計を支援する技術では静的型付言語の再流行やgRPCやGraphQLなどの型付APIの浸透、クラウドサービスの進化やそれに関わる設計ベスト・プラクティスの共有などがあります。いきなり実装にうつるより、慎重にこれらの技術を使って調査・検討を重ねて設計を行うと長期間に渡ってプロジェクトの開発速度を保てるでしょう。
要件定義プラクティスとしては私はRDRAに注目していて、次回の記事、勉強会の後半ではRDRAについて紹介していきます。
- 第1回の記事はこちら - 「ディズニー映画制作、ゲーム開発そしてソフトウェア開発の類似点」
- 第2回後半の記事を公開しました！ - 「アジャイル開発から要件定義・設計重視な開発への回帰」(後半)
- 第3回の記事を公開しました！ - 「並行作業とスキーマ駆動開発」
- 第4回の記事を公開しました！ - 「効果計測が当たり前のデジタル広告、計測が当たり前じゃないエンジニア生産性」