概要

最適化プロジェクトは, 構造的な問題から世間一般での開発プロジェクトと比較して難易度が高いです. その結果, 現場の人間が苦しんだり, プロジェクトが失敗に終わったりといった事態になります.

本記事では, 最適化プロジェクトをアジャイル開発で進めることの意義について説明したうえで,

アジャイル開発は「ちゃんと」やれ
「ちゃんと」やるにはどうしたらいいか?

ということを議論していきたいと思います.

対象読者

最適化プロジェクトのプロジェクトマネージャー(PM), ないしリーダーの役割を担っている人
- 特に, アジャイル開発をやってみて「うまくいかなかった」と結論づけた人
- PM初心者の方
最適化プロジェクトでメンバーとして参画しているエンジニア

最適化プロジェクトは難易度が高い

一般に（少なくとも日本の）最適化プロジェクトは, プロジェクトマネジメントの難易度が高いとされています¹.
原因はさまざま考えられますが, 本記事ではそのうち, アジャイル開発によって避けられると考える以下2つについて取り上げます.

急な要件変更が前提となる
過度な期待を持たれやすい

急な要件変更が前提となる

『実務で学ぶ数理最適化の考え方』では, 「頻繁に生じる急な要件変更」がアンチパターンとして挙げられていました.

「頻繁に生じる」という部分は確かにアンチパターンだと思いますが, 「急な要件変更」についてはある程度仕方がないと割り切るしかないと思っています.

「急な要件変更」が生じる主な理由は, 現場のユーザーは自分がしていることを言語化しにくく, またユーザーによって基準が異なるから, と私は考えています.
普段ユーザーは「なんとなくこっちの方がよい」という感覚で業務をこなしていることが多く, 最適化プロジェクトではまず何をもってよしとするかの探索から始まります.
幸運にもユーザーの一人が言語化が得意でも, ユーザーによって基準が異なる場合もあります.
そのため, 最適化の結果を見せると「何か違う」となってモデルを組みなおすことになったり, 「こういう状況ではこっちの方がいい」といったように追加要件が出ることが多いです.

以上から, 急な要件変更は, 最適化プロジェクトの性質的に前提として考えた方がよい, というのが私の意見です.

過度な期待を持たれやすい

『実務で学ぶ数理最適化の考え方』でも「過度な期待」がアンチパターンとして紹介されており, その原因として以下のように記載されています.

数理最適化プロジェクトは技術的に高度な部分が多いため, 関係者の理解が乏しい場合, 過度な期待が生まれやすいです. プロジェクトに参加している技術提供側の各社の窓口は, 数理最適化の限界や解の実用性をステークホルダ（特にエンドユーザー）に適切に説明し, 現実的な期待値を設定することが求められます.
『実務で使える数理最適化の考え方』 8.4.5節「数理最適化のアンチパターンと対応策」より

技術的に高度なため, どうしてもユーザーなどの関係者には「なんでもできるんでしょ」と思われがちです. そこをマネジメントするのがPMの役割なのですが, ここで一つ考慮しておきたいことがあります.
それは, PM の PM としての経験値についてです.

引用した通り数理最適化は技術的に高度なため, 自然と企業の中でもデータサイエンティストであったり, 技術を専門とした職種の人がPMに着きます.
こういった方は PM が専門ではない(ことが多い)ため, ユーザーの期待値のコントロールに長けていない, むしろ経験的にそういった人は少ないです. 結果, ユーザーから過度な期待を持たれがち, という状況になっていると推察します².

数理最適化プロジェクトにアジャイル開発を適用する意義

そもそも, 急な要件変更が発生するプロジェクトは, 難易度が高いです.
PMのスキルが不足がちな方にとっては, どうやってプロジェクトマネジメントを学べばよいかわからない場合もあるのではないでしょうか.

私は, 最適化プロジェクトを難しくする原因への対処法として, アジャイル開発をお勧めします.
理由は以下2つで, 順次解説していきます.

急な要件変更を前倒しする
期待値コントロールしやすい

本記事での「アジャイル開発」の定義

最適化プロジェクトにアジャイル開発を適用すべき理由について述べる前に, 本記事内での定義について述べておきます.

「アジャイル開発」と言っても, 現代では意味の希薄化が発生し, いろんな解釈がされています. スクラム³で開発することがアジャイルという人もいれば, お客さんからの要望に都度答えて開発していればアジャイル, という人もいます.

本記事では, 名著である『アジャイルサムライ』に則り, 以下2点を実践している開発プロジェクトを「アジャイル開発を実施している」とします⁴.

イテレーション⁵で区切って開発する
1. イテレーションごとに, 動くソフトウェアが完成する
ユーザーストーリー⁶毎に見積もりする

急な要件変更を前倒しする

最適化プロジェクトにおいて急な要件変更は前提となる話は前項で記述しました.
同じ要件変更がプロジェクト中に起こるのであれば, できる限り前倒しすることが, プロジェクト失敗というリスクを低減する上で重要になります.

では, 要件変更を前倒しするためにはどうしたらよいでしょうか?
私は, ユーザーに「頻繁に」「完成したものを」見てもらうことが重要だと考えます.

ユーザーに「頻繁に」見てもらう

「頻繁に」見てもらうことの意義は, 想像に難くないと思います.
前述した通り, ユーザーは自身の業務について詳細に言語化できるわけではないので, 実際に見てもらって初めて要件が明確化していきます.
見てもらう頻度が増えれば, 試行回数が増え, 言語化の精度も上がります.
結果, プロジェクト終わり間際に「これでは使い物にならない」と言われるリスクを減らせます.

ユーザーに「完成したものを」見てもらう

イテレーション毎に開発することで, できた最適化の結果を「頻繁に」ユーザーに見せる.
これは, アジャイル開発でないとしても, ユーザーとの定期的なミーティングがあるために実質的にそうなっているプロジェクトは多いと思います. ここで重要なのは, ユーザーから要件変更を引き出すことができるかです.

定期的なミーティングで結果を見せる際, 「この制約は入っていませんが」とか, 未完成を前提としたことがある方は少なくないと思います.
が, 未完成な結果を見せたところで, ユーザーは「未完成なのね」という前提でものを見ます⁷.
何かフィードバックを入れたところで「未完成なので」と逃げられてしまうので, 「いいんじゃないですか」程度のコメントしか引き出せません. ユーザーから真に要件変更を引き出すためには, 完成したものを見せる必要があります.

また, 数理最適化の性質上, すべての制約条件が揃わないと解が意味を為さない, という事情もあります.
一つの制約が解の質を大きく変えること(ある制約を1つ入れたら求解速度が突然遅くなった, など)は多々あります. そのため, 最適化モデルとして完全, 完成版であることも, フィードバックをもらう上で重要となります.

「動くソフトウェア」を完成させることが, 最適化プロジェクトにおいてユーザーの要件変更を促し, 結果的に要件変更を前倒しします.
動かない(制約が入っていないなどの理由で未完成となっている)ソフトウェアは, 完成したうちに入らないのです. ユーザーに「あとちょっとで完成です」などと言っても, 「はぁ, そうですか」程度のコメントしか引き出せません.

期待値コントロールしやすい

過度な期待を持たれやすいことが, プロジェクトを難しくしている一因だと述べました.
では, 現実的な期待値を設定するためにはどうしたらよいのでしょうか?

筆者は, 頻繁にユーザーに結果を見せることもそうですが, それと同時に 「プロジェクト終了までに何ができるか」を根拠をもって説明することが, 期待値を適正に保つ助けになる と考えています.

人間はわからないものに対して, 楽観的な見積もりをしがちです.
例えば夏休みの宿題. どれくらいで終わるか見積もりしたことはありますか? 「毎日コツコツやっていれば夏休み半ばには終わるだろう」と考えて, その結果実際に夏休み半ばに終えられた人は少数でしょう. 逆に, 夏休み終盤で全く手をつけていなくても, 「夏休み最終日までには終わるだろう」と考えた人⁸は少なくないと思います.

このように, わからないもの（=夏休みの宿題の全量⁹と, 自分が1日あたりどれくらい消化できるか）に対する見積もりは得てして楽観的となり, 結果期待値が大きくなる(=宿題の全量を過小に見積もる or 自分の1日あたりの消化量を過大に見積もることで, 夏休み半ばに終えられる or 夏休み最終日に間に合うと考える)わけです.

この問題に対応するための一つの方法が, アジャイル式の見積もりです.

『アジャイルサムライ』の見積もりに関する考え方に従うと, ユーザーストーリーごとにいくらかかるかを見積もります(この見積もりした値をストーリーポイントと呼びます). そうすると, 実際に1イテレーションで消化できるストーリーポイント数(ベロシティと呼びます)が, 実際にイテレーションを回せばわかります. これにより,

残イテレーション数 × ベロシティ

が, プロジェクトでこなせる総ストーリーポイント数となります.
つまり, 「プロジェクト終了までに何ができるか」というのは, 上で求めた総ストーリーポイント数分のユーザーストーリーとなります.

「いつまでに何ができるか」が明確になると, 期待値はコントロールしやすくなります.
仮にユーザーに「この機能は入れないと使い物にならない」という要件がプロジェクト途中で来たとしても, その機能に対する見積もりを実施し, 「それは機能として大きすぎるので, 入れるのであればこの機能とこの機能は落とす必要があります」というように交渉することが可能です¹⁰.
その根拠も, 実際に開発したことによる実績に基づいていますから, 納得感も得られます¹¹.

「ちゃんと」やろう

ここまで, 最適化プロジェクトとアジャイル開発の親和性を説明してきました.
これによる結論が「アジャイル勉強した方がいいよ」だと当たり前というか, 今時のシステム開発であればアジャイルは常識になってきていますので, 情報量がありません. もう少し進んだ議論をしたいと思います.

それはすなわち, 「ちゃんと」やれ, ということです.

「ちゃんと」やる, とは?

「ちゃんと」やる, とはどういうことでしょうか?
本記事を読んだ方には, 以下のように考える人もいると思います.

うちは言われなくてもアジャイル開発やってるわい, だけど全然効果がない.
お客さんは要件無理やりねじ込んでくるし, ベロシティも全然上がらない.
やっぱアジャイルはクソ

しかし, 本当に「アジャイルはクソ」と言い切れるほど, アジャイルを実践されているでしょうか?

『アジャイルサムライ』の通りにやるにしても, 以下は守れているか考えたことはありますか?

インセプションデッキ¹²の作成にユーザーなどの顧客を巻き込めているか
「いつまでに何ができるか」を, 簡潔に顧客に説明できるか¹³
イテレーションごとに「動くソフトウェア」までこぎつけているか

どれも現場で実践するには, 難易度の高いことばかりだと思います.

「これは実践が難しいからやらないでおこう」といったことが, 1つや2つではないはずです. それなのに「ウチはアジャイル開発やってるよ」なんて言っているのは, どうにも論理破綻しているように聞こえます. 薬は用法容量を守って正しく服用することで, 欲しい効能が得られるものです.

「ちゃんと」やるにはどうしたらいい?

さんざんでかい口叩いておいて, 「じゃあちゃんとやるにはどうしたらいいのよ」ということに答えられないようでは, ただの批評家でしかありません. 冷たくあしらわれるのがオチでしょう.

なので, 著者が「ちゃんと」やるために心掛けている2点を共有します.

教科書通りにやる

とにかく教科書を読みましょう. 『アジャイルサムライ』を教科書とするのであれば,

インセプションデッキの作成をお客さんと実施しましょう
ユーザーストーリーをテクノロジの側面で記載せず, ユーザーのビジネスにとって価値ある言葉で記載しましょう
日数ではなくポイントで見積もりましょう
イテレーションごとに「動くソフトウェア」を完成させましょう
テスト駆動開発¹⁴を実践しましょう

そして, それらをそのまま実践しましょう. 「なぜそれをするのか」を, 実践を通して理解しましょう.

おそらく, 開発現場から反発があると思います¹⁵.

（お客さん含め）会議を増やしたくない
テクノロジ的に高度だから, 技術の言葉で記述しなければわからない
人月/人日計算の方が慣れていてわかりやすい
複数イテレーションかけないとできない大きな機能に取り組んでいる
テスト駆動開発はやったことないから開発速度が落ちる. 従来通りの開発をすべきだ
etc...

やらない理由はいくらでも挙げられます.
環境が変われば, 慣れるのに時間がかかるのは当然です.
最初はうまくいかないでしょう.

しかしそこを堪え, 教科書通りに実践するのです.
体が新しいやり方に慣れれば, 以前と同じようになります.
むしろ, 新しいやり方による効能を実感し, より効率的に働けるようになるでしょう.

自分にできる範囲で勝手にやる

「ちゃんと」やれ, と言ったら, 以下のような反論があるかもしれません.

契約がWFだからアジャイル開発は無理
お客様が忙しくて, アジャイル特有のミーティングに参加する時間が取れない
メンバー or リーダーに, アジャイルでやることを納得してもらえない

しかし, 自分にできる範囲でアジャイルにやることはできるはずです.

我々は何のためにここにいるのか, を言語化する
どの機能をどのイテレーションで作るか決める
イテレーション毎に「動くソフトウェア」として完成させる

こういったことは, 別にプロジェクトが「アジャイル開発でやります」と大手を振って進めなくとも, 開発者だけで勝手にできるはずです.
自分たちのできる範囲で, 勝手にやればいいのです.
後から何か言われたら, 謝ればいいのです¹⁶.

ただし, 決して無責任になんでもやっていいよ, という話はしていません.
当然外形(契約の形態, 成果物など)は保つべきです.
内部でどのようなふるまいをするかは, 自分たちの好きなようにしていいはず, ということです¹⁷.

アジャイルやるなら「ちゃんと」やろう

本記事を1行でまとめると, 以下になると思います.

数理最適化プロジェクトは, 「自分たちのできる範囲で」「教科書通りに」アジャイル開発を実践すると, 少しは楽になるはずだよ

守破離を大切に

そもそも, アジャイルとは「やるもの」ではありません.
アジャイルの語源となった agile というのは形容詞で, 「俊敏な」といった意味の英単語です.

Don't DO Agile, BE agile.

というフレーズもあります. 「XXXをしているからアジャイル」ではないのです.

アジャイルのプラクティスの背後にある理念を理解すること, 理念を通した振る舞い(=イテレーションで開発する, などのプラクティスの実践)をすること. これが「アジャイルになる」ということだと, 私は思います.

守破離¹⁸の精神を守りましょう.　初心者が型を守らずやっていたらただの「型なし」になるだけです. まずは教科書通りにやり, 型を「守」ることから始めましょう. 個々のプロジェクトに合わせて改変する（=「破」）のはその後です.

このあたりは『SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意』に, アジャイルに対する向き合い方などが記載されていますので, ぜひご一読ください.

それでも「ちゃんと」やるのは難しいし大変

ただし, そもそもアジャイル開発というのは, 開発者の理想論的なところ¹⁹から始まっていますので, 実践が難しいのは当然です.
それを地でやろうとしているわけですから, 最適化プロジェクトも難しくなるのは必然ですね.

私も, 完璧に「ちゃんと」やっているかというと, 微妙なところです.

「このベロシティではこれ以上機能追加できない」とどんなに主張しても顧客には無理くり押し込められてしまいますし, 「動くソフトウェア」にこぎつけないイテレーションだって多々あります.
それでも, 最適化プロジェクトにアジャイル開発を適用することはよりよいシステム開発につながると信じているので, 今日も頑張っています.

「お互い最適化にまつわるエンジニア/プロジェクトマネージャーとして頑張りましょう」 という激励の言葉で締めたいと思います.
ご一読いただきありがとうございました.

余談

Q. 最適化プロジェクトに限った話ではなくない？

記事でも述べたように, PMの経験が少ない人が最適化プロジェクトのPMにつきがちです.
こうなると, 何から調べればよいかわからない人もいます.
そういった人たちに認知してもらうようにするため, あえて「最適化プロジェクトのPM向け」の記事にしました.

『実務で学ぶ数理最適化の考え方』には, 最適化プロジェクトのアンチパターンがいくつか挙げられています. また, リクルートの梅谷先生の記事にも, 最適化プロジェクトの際に考えなければならないことが記載されています. これらを, 通常のプロジェクトマネジメントに加えて考えなければならない訳で, なかなか考えるべきことが多く大変です. ↩
統計を取ったわけではないです ↩
スクラム: おそらく, 一番有名なアジャイル開発のフレームワーク, やり方 ↩
『アジャイルサムライ』の中では, インセプションデッキを作成することがプロジェクトの方向性を定めるものとして, 重要という位置づけがされています. しかし本記事では, 「アジャイル開発のプロセスが最適化プロジェクトにおいてどう活きるのか」という文脈で解説するため, インセプションデッキの作成について言及を避けます. ↩
イテレーション: 区切られたタイムボックス. 1週間~1カ月が目安. ↩
ユーザーストーリー: ユーザーがソフトウェアで実現したいこと ↩
もちろんユーザーの気質に寄りますが ↩
そしてその結果, 夏休み最終日で泣きを見る ↩
計算ドリルなどのページ数が決まっているものは明確です. ただし, 理科の自由研究などは, いつまでに企画を構想して...など, 全量としてどれくらいか定量的に判断しづらいですね. ↩
場合によっては, 「どの機能もないと話にならないので, 落とせる機能がない」という状況になるかもしれません. そんなときは, 「本当にどの機能もないと話にならないのか」, もしくは「見積もりを小さくできないか」を議論しましょう. システムでなんとかするのではなく, 人手で対応できるところはないか? 最適化に組み込むのではなく, 前処理/後処理など決定論的に扱えないか? それでも「絶対にすべて必要」という主張を曲げられないのであれば, イテレーションを増やす(=プロジェクトの延長)か, 涙を呑んで残業でやるか, でしょう. ↩
ストーリーポイントの見積もりは開発者が主体となって実施するので, 場合によっては顧客から「開発側の都合に合わせた, 恣意的な見積もりだろ」と言われかねないことは承知しています. 明確な解決策は, やはり「顧客（ユーザー）にも見積もりに参加してもらう」でしょうか. ↩
インセプションデッキ: プロジェクトの方向性を指し示すもの. 『アジャイルサムライ』では, 10の質問とその回答によって構成される. プロジェクト憲章のようなもの. ↩
開発が遅れていても, 理屈を並べればお客さんも納得してくれるでしょう. しかし, 大事なのは「簡潔に」です. 理屈を考える時間を, 開発を進めることに費やす方がいいですよね. ↩
テスト駆動開発: テストファースト(テストコードから開発を始めること)と自動テストからなる, コーディング手法の1つ. 品質を向上させることが良く知られている. 『テスト駆動開発』を参照のこと. ↩
『アジャイルサムライ』でも『チーズはどこへ消えた?』を例に, やり方を変えることに対する反発があることを記載しています ↩
グレース・ホッパーの名言, It's easier to ask forgiveness than it is to get permission.（事前に許可を得るより, あとで許してもらうほうが楽）より. ↩
プロジェクトによっては, どんな名前のソースコードを提出するか, までガチガチに決められた開発になる場合もあるかもしれません. そうなると自分たちで好きにする余地というのはなくなるのですが, そもそも, そういったマイクロマネジメント的な開発の契約をしている時点で最適化プロジェクトとしては黄色信号だと思います. ↩
日本の武道・芸道における修行の過程を表す概念 ↩
アジャイルソフトウェア開発宣言のこと ↩