この記事は、Code for Japanの運営する「Civictech 1年目 Advent Calendar 2020」の12/17のものになります。

これまで高校1年生から、2年間ほど ソフトウェア開発の現場に従事していました。

そして、今年の10月にCivichatという会社で代表取締役を務める事になり、Code for Japanなどのコミュニティに出入りする機会も増えたので、現時点での私自身の考察で「ソフトウェア開発において最も重要視するべきこと」を書こうと思います。

アジャイルやウォーターフォールという開発手法に関しての考察にくわえ、ソフトウェア開発では切り離せない「不確実性」についても触れます。

記事中での一貫した結論としては、（少し言い過ぎかもしれませんが）「ソフトウェア開発における『計画』とは幻想である」というものになります。

「予算」や「期間」などの（現状のほとんどのプロダクトの開発手法である）ウォーターフォールでの開発手法にみられる「計画」は、（工場などの大量生産とは違って）"不確実性の高い ソフトウェア開発"という工程では役に立たないと考えています。

なぜなら、「最初に計画したソフトウェアの仕様で課題解決を達成できるかどうかは誰もわからない」の加えて、「リソースの予測が難しい」というのが理由です。

「ソフトウェア開発における不確実性」とは何か

ソフトウェアを開発するに当たって、（大量生産方式を採用するような工場と違い）「不確実性」という概念には必ず触れておきたいと思います。

あくまでも「ソフトウェア開発」という行為自体が、"新しいものを作り出す" というクリエイティブな作業である以上 次のような不確実性が存在します。

1. ソリューションを実現するためのプロダクトが、実際に問題解決をするかは分からない
    ・実際にプロダクトを作ってみたけど、何にも問題を解決していない
2. 実際に問題解決がされたところで、利益となるかは分からない
    ・コンテキストの変化が原因で、開発期間中に情勢が大きく変わり、解決されるべき問題が消失したり変容したりする
    ・上記は事前のデータ解析によって予測できない
3. ソリューションを実現するためのプロダクトを開発するにあたり、期間・人員・リスク対策費などのリソースが正確に予測できない
    ・期間と規模が大きいほど顕著

以上が「ソフトウェア開発における不確実性」と考えることにします。

では、これだけのリスクに対して、今までどう対処してきたかというと「（契約し、）外注する」という方法を取ってきたと考察します。

上記の不確実性があるのに、なぜ「計画」を立てたがるのか

「外注」という行為は、不確実性に対処できません。なぜなら、計画がないとお金を出してくれないから。外部から輸入してくる際には必ず契約を行わなければいけないですよね。

そのために、ソフトウェアの開発において（決められるはずのない）「予算」「期間」などの計画を打ち出さなければいけません。（取り決めのない契約などは成立しないので、）契約を取るために。

発注側は「お金を出すに足る理由」を求めているので、開発者側は（プロダクトが課題を解決した世界線ではなく）「計画」を提示するということです。

わざとプロジェクトを失敗させようとしているのではなく、”それがないとプロジェクトが発足しない”ということです。

多くの人は、以下のような流れでソフトウェアを開発すると思います。

1.　ある問題を解決するにあたり、ソリューションとしてIT化が浮上
2.　そのソリューションを実現するための期間とコストを概算
3.　お金を出す人が承認（予算の確定）
4.　詳細な計画の作成と、リソースの確保
5.　あとは何とか作りきろう

そうすると、「失敗（予算オーバー or 計画遅延）」が存在することになってしまいます。（「予算を決めるから予算をオーバーする」みたいな概念）

加えてより最悪なケースとして、「予算オーバー＆計画遅延（≒ 失敗）」が存在おすることで、作っているものが「役に立たない」と分かっても軌道の修正に対して消極的にならざるを得ないというものがあります。

これによって、大量の時間とお金をかけて、役に立たないゴミを作ってしまうことが最も最悪なものと言えるでしょう。

そういった点を踏まえて、「計画」というのが、そもそもソフトウェア開発における不確実性を非常に無視した概念であると考えています。

要はアジャイルは行き当たりばったりってことですか？

私たちは、予算と計画という考えから脱し、「ソフトウェア開発における不確実性」に向き合う必要があるということは理解できたと思います。

しかし、どのようにして不確実性と向き合うのがいいのでしょうか？私の中の現時点での答えは、「アジャイル」手法です。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

https://agilemanifesto.org/iso/ja/manifesto.html

「予算を決めてソフトウェアを買う」という考えを捨て、『課題解決をソフトウェアがある世界線で行う』と考えた方がいいでしょう。

対象にしている課題と全く同じものが歴史の中にある場合は、すでにあるもの・開発フローが確立されているものを購入（外部委託）すればいいと思いますが、たいていの問題はそうではありません。

そのためには、短期間での仮説検証を繰り返しながら、常にプロダクトを改善し続ける姿勢が必要になります。

ソフトウェア開発（アジャイル）における「仮説検証」は、全ての人間が自己完結的に持つべきスキルの中の1つと考えています。

これは、A/Bテストなどと言われることが多く、ソフトウェアの特徴である「可観測性」によって実現できる、課題の解像度を上げるための手法です。

仮説検証を繰り返し、ある程度の勝ち筋が見えてきた部分では、A/Bテストを辞め、「システム化」（対義語：「アドリブ」）を行ってもいいでしょう。

常に新しい機能を試行し続けるのには、ある程度の失敗も想定しなければいけません。

なぜなら、失敗を許容されない場合（0に限りなく近づける必要がある場合）では「新しい機能を追加開発しない」という負のインセンティブが働いてしまいます。

AWSなどを代表とする、クラウドサービスは「SLI / SLO」（サービスレベル契約・サービスレベル品質）などという可用性を表す単語が使われています。

これは失敗を許容する、「失敗の予算化」と呼ばれるような考え方で、アジャイル開発での止まらない改善体制を支える文化の一つです。

以上、ウォーターフォールの弱点や、アジャイル開発におけるポイントなどを書きました。

この記事を通して伝えたかったこととしては、「課題解決は買えない」ということです。いくら予算があろうと、外注という手法でソフトウェア開発におけるポイントを殺してしまっているのでは、小さなスタートアップでも数人のエンジニアが毎日議論し、小さく機能を改善しDeployしている組織には勝てません。

課題解決はお金では買えないのです。「とりあえずお金はあるし、俺はビジョンだけ打ち出すから、そのコード書いてくれればいいよ。」という姿勢ではいいプロダクトは作れません。

そんなソフトウェア開発だからこそ、「ともに考え・ともにつくる」。そういった姿勢が求められているのだと痛感します。

一つのソフトウェアで、社会を変えられる。Code for Japanのみなさま、これからもよろしくお願いします！