ソフトウェア開発おける不確実性について

public.icon

最初に決めた計画で課題解決を達成できるかどうかは誰もわからない

課題を解決するためのプロダクトの開発に、リソースの予測が難しい

1. ソリューションを実現するためのプロダクトが、実際に問題解決をするかは分からない

実際にプロダクトを作ってみたけど、何にも問題を解決していない

2. 実際に問題解決がされたところで、利益となるかは分からない

コンテキストの変化が原因で、開発期間中に情勢が大きく変わり、解決されるべき問題が消失したり変容したりする

上記は事前のデータ解析によって予測できない

3. ソリューションを実現するためのプロダクトを開発するにあたり、期間・人員・リスク対策費などのリソースが正確に予測できない（期間と規模が大きいほど顕著）

そもそも”ソフトウェア開発”自体が、生産のための期間や必要なリソースを特定できない

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

そこで、開発者側は（世界線ではなく）「予算と計画」を提示する

1. ある問題を解決するにあたり、ソリューションとしてIT化が浮上

2. そのソリューションを実現するための期間とコストを概算

3. お金を出す人が承認（予算の確定）

4. 詳細な計画の作成と、リソースの確保

5. あとは何とか作りきろう

そうすると、以下のような「失敗（と、言われる虚構）」が存在する

予算オーバー & 計画遅延

上記の2つがあると、作っているものが「役に立たない」と分かっても軌道の修正に対して消極的にならざるを得ない

大層な時間とお金をかけて、役に立たないゴミを作ってしまう

結論：「予算と計画」というのが、そもそもソフトウェア開発における不確実性を非常に無視した概念である

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

決して止まらないカイゼン体制を作りたい（深津氏）

例えば、「こういう施策を打つと、利益が増えるのではないか？」という仮説を立て、施策を打ったグループAと打たなかったグループBに対してA/Bテストを実施し、数ヵ月後にその結果を統計的に検証する

仮説検証は全てのチームが自己完結的に持つべきスキル

対象としている業務や部門・サービスに対して（理想的には一つの）チームが永続的に関わり、仮説検証を繰り返す必要がある

システム化・アドリブ化（深津氏）

システムは外部のを使ってもいいよね、という概念

Agility経営（松本氏）

ソフトウェアの特徴である可観測性によって、課題の解像度を上げる

自治体・行政のシステムはウォーターフォール（「予算と計画」）での開発が多い

これは”大企業あるある”と言われることもあるけど、これを克服できて大企業であれば誰も追いつけない企業になる

「公共のシステムに求められること」と『私営のシステムに求められること』の違いに関してはこの記事が良かった

税金を使って最終保証を行うことで、経済市場を発展させる。そのためには”最低限の機能を持つものを公共として提供する”

だけど、ソフトウェアを開発していくのであればアジャイルで進めていくことは避けられないはず

各業界の人たちがどんどん参加してくれていて、みんなで日本をよくしていこうという1番面白いフェーズ

民間で結果出した人がこういう形で国・地域に還元してくれるのは嬉しいし、そんな人たちと一緒に未来を作っていきたい