最初に開発したシステムは使い物にならない【無能エンジニア論】

たかだか1万行程度のソフトウェア開発に、
何カ月もあるべき姿を議論し何カ月も課題を探す要件定義（？）に疑問を感じます。

GUIを持つアプリケーションであれば、1万行程度のものは画面数も片手で数える程度です。
慣れた言語でそこそこの経験があれば、開発は1人で2週間もあればそれなりの形になります。
テストも1週間もあれば終わるでしょうしドキュメント作成は数日で終わります。
1カ月がっつり使えれば普通に終わります。ぶっちゃけ1カ月も要りません。

前置き

今回作ったソフトウェアが丁度1万行でした。
以下の内容から多くのソフトウェア開発が1万行程度のものであることがわかっています。

「IPA – ソフトウェア開発分析データ集2020」より抜粋

今回の案件に関し何カ月も議論を重ねていたようですが、
負担が多く一向に進まなかったようで僕が参戦することになりました。
画面数は５つ。大した機能を持っていません。
データベースを使った、入力と検索のアプリです。

エクセルで良くね？みたいな話でしたが
一切ひく気はなさそうであったことと
僕も久しぶりにコーディングしたかったことから
ちょっとしたデスクトップアプリを作る方向で合意しました。

何カ月も議論してくれていたみたいで、資料は相当数出来上がっていました。
議事録は2週間に1度のペースで10回分あります。
1回あたり2時間議論されていたみたいです。
既に4カ月ほど経過しています。
参加者は平均で5人。毎度、特定の人に対して宿題があります。
もしかして、完璧な仕様書を作りたいのでしょうか？

最終的に出来上がっている内容で実装に入れるかというとそうではありません。
全資料に目を通したのですが初回に用意された思いの丈のつまった資料が一番有益でした。
あとは、ソフトウェアの仕様と関係なさそうな調査資料がたくさんあります。

ところどころ不安を語り合うだけの会議になっており
ツールを使いたくない人をどうするか
といった内容が議論されます。

会議で答えが出るのだろうか？
僕には疑問しかありませんが今回は無視します。

僕が着目したいのは4カ月の期間と100時間(2時間×10回×5人)という時間です。
宿題や議事録を書く時間を考えるともう少し時間はとられていると思います。

仕様調整

僕は最初の資料を作成した人を訪ね、わからないところをいくつか確認しました。
1対1で1時間弱の会話です。

1日かけて画面のイメージをつくってやりたい事のイメージと大枠があってるかの確認をしました。
また1日かけて、画面イメージの通りに画面と画面遷移を用意し実際に操作する感覚を見てもらいました。
あまり外れてなさそうだったので5日かけて5画面と主要な機能実装しました。
1日で1画面程度の簡単なものであることがわかります。

この段階ではテキストボックスへの入力制限やエラーチェックなどは細かい動きはほぼ作成していません。
評価してもらうにあたりアプリが落ちると格好悪いので最低限のnullチェックや範囲チェックはします。

ユーザー数名に実際に触ってもらい意見を聞いて2画面不要であることがわかりました。
僕自身も画面が分かれていることが不便に感じていたので当然の結果です。

その不要な2画面のユーザー意見は
たぶん、使わない
です。
「たぶん」に僕への遠慮が含まれています。

僕がいないところでは
「何でそんな設計になってるの？バカなの？」
くらいは言われているかもしれません。

コーディングはさほど苦痛ではないのですが、僕はテストが苦痛です。
ちょっと頑張った機能が不要の画面に含まれておりしょぼんとなりましたが
2画面分テストを減らせたのは何よりです。

実装

計3画面のアプリに仕立てました。
丸っと20日間、他事の割り込み会議や業務があるので、実質130時間ほどです。

他の仕組みへの影響もないことから、リリース後あっさり運用開始。
効果のほどは知りませんが、皆さん文句を言いながら使ってくれています。
まぁ、入力の手間の割にメリットが少なそうなので、その内使われなくなるでしょう。

1982年の古い資料が出典ですが面白いことを言っていたのでご参考まで。

ほとんどのプロジェクトでは,最初に開発したシステムは使い物にならない.
遅すぎるか,大きすぎるか,使いにくいか,あるいはすべてに当てはまるかもしれない.
残念だが賢明な方法は、初めからやり直す以外にない.
（中略）
新しいシステムを対象するときや新しい技術を使う時は、
1回で成功するような計画はあり得ないので,初めから廃棄されると決まったシステムを開発する必要がある.
パイロットシステムを開発するかどうかを検討するのではない。絶対に廃棄しなくてはならないのである.
唯一の問題は廃棄されるものの開発を事前に計画しておけるか,
それとも廃棄すべきものを顧客に納入すると約束してしまうかどうかである.

実践ソフトウェアエンジニアリング ソフトウェアプロフェッショナルのための基本知識 [ ロジャー・S．プレスマン ]より抜粋
元ネタはブルックス本の「ソフトウェア開発の神話 (1982年)」のようです。

今回のケースであれば、
会議している時間をかき集めれば1個アプリ作れますし
会議してる期間で4回リリースできます。

なぜ、とっとと失敗しないのか？

おわり