1998年、私が立命館大学の情報学科で学んだ事で今でも覚えていることがあります。

・1960年代末「ソフトウェア危機」というものがあった
・ウォーターフォールという開発手法がある
・プログラマはテストをしてはならない

「ソフトウェア危機」というものがあったので、何が問題で、上手に開発するにはどうすればいいんだろう？という議論や研究があり、プログラミング技法やソフトウェアの開発手法やテスト方法などなどが編み出されたのだと思います。

「ソフトウェア危機」とは？

ソフトウェア危機（ソフトウェアきき、Software Crisis）とは、高性能化するハードウェアのコストは低下する一方、複雑化するソフトウェア開発のコストは上昇する傾向が続くことにより、将来的にソフトウェアの供給が需要を満たせなくなるという考え方である。

Wikipediaより

要件の肥大化、ソフトウェアの複雑化、対価と期間の最小化要求に伴い、以下のような問題が発生したそうです。

・予算超過
・期間超過
・低品質化
・要件を満たさない
・保守困難

残念ながら50年以上経った今でも同様の問題は50%のプロジェクトで発生している、というのが日経ビジネスさんの記事にありました。

ウォーターフォールソフトウェア開発

様々な問題を解決するために、「ちゃんと管理すれば大丈夫」的に昔から使われているのがウォーターフォールです。端的にまとめると、ソフトウェア開発の設計・開発・リリース・検証の各段階で成果物（ドキュメント等）を残し、次の段階に渡すことで合意形成を容易にし、手戻りを最小化しようという開発手法です。水（成果物）が上から下に流れていくように開発が進んでいくので、ウォーターフォールです。

手戻りが最小とはいえ、もし開発途中で手戻りが発生した場合、設計の段階に戻って資料の修正からやり直しになるので、遅い開発手法なのではないかという問題があります。そして、開発途中でクライアントから変更要望が来るのはよくあることで、予算や期間が固定された請負契約では計画の変更や工数の追加はトラブルになりがちです。

アジャイルソフトウェア開発

そんな中、2000年代になって登場したのがアジャイルと呼ばれる開発手法です。端的にまとめると、設計・開発・リリース・検証の各段階でドキュメントよりも対話によって合意形成を行い、開発サイクルのスピードを上げ、クライアントからの変更要望にも素早く対応できるようにしようという開発手法になります。経済産業省のアンケート結果（PDFのp70「(12)利用している開発手法」）によると、2016年時点のソフトウェア開発の55%がウォーターフォールで、アジャイルは20%だそうです。現在ではもう少しアジャイルの比率が多いかと思います。

ドキュメントよりも対話やノウハウの蓄積を重視しているので、必然的にメンバーが対話不能なほどプロジェクトが大きいと破綻しますし、ノウハウが属人的なので転職等で人がいなくなると途端にノウハウは失われます。他にも設計段階の弱点が指摘されているようです。

また、近年ではリモートワークが進んだ事により、チームが一箇所にまとまって存在しない場合もあり、随時ビデオミーティング等で意思疎通が必要になります。（少人数なら問題ないでしょう）

ウォーターフォール vs アジャイル

ウォーターフォールもアジャイルもどちらか片方が優れているということはなく、ソフトウェア開発プロジェクトの特性に応じて使い分けるものかと思います。

	ウォーターフォール	アジャイル
プロジェクト規模	中規模以上に向く	小規模に向く
バージョンアップ	ある程度まとめて段階的	小規模を随時
合意形成	ドキュメントによる	対話による
ノウハウ	ドキュメントによる	経験の蓄積による
権限	トップダウン	チームに移譲
全体工数の計算	安易	難しい
簡単な仕様変更	ドキュメント修正や、実装修正の手配分時間がかかる	安易
複雑な仕様修正	時間はかかるが影響範囲の特定が可能で、作業の計画も可能	影響範囲を明確にし、複数人に渡る作業を計画することは苦手
契約形態	請負	準委任

アジャイルは価値観であって開発手法と一体ではないそうなので、反復型ウォーターフォールも存在するのではないかと思うのですが、一旦置いておきます。

とりあえず、「その場その場で開発内容を決めて随時実装したい」のがアジャイル、「ソフトウェアの完成形を予め決めて、全てを計画通りに実装しよう」というのがウォーターフォールという感じです。

LUXALAは何故ドキュメント化を重視するか？

ウォーターフォールもアジャイルも「ソフトウェア危機」の頃からずっと存在している問題に対するアプローチ方法ということになります。一方は「全てを上手に管理しよう」、もう一方は「管理は不可能なので、適宜対応していこう」という考え方ですね。弊社は設計・開発会社ですので、必然的にウォーターフォール向きという事になるのですが、何故ドキュメント化を重視するのでしょうか？

（その１）コミュニケーションコストが最も高い

私個人の考えですが、「世の中の多くの問題がコミュニケーションに起因する」「合意形成が最も高くつく」と感じています。大きくは国同士のいざこざ、小さくは個々人の言った言わない。自分の考えや情報を正しいタイミングで正確に伝えるのは誰もができることではなく、口頭による情報のシェアやメンバー間の話し合いにはめちゃくちゃコストがかかり、リスクが高いと考えています。昨今の社員募集でも「コミュニケーションスキル」を求められる事が多いですが、全員ができることであればわざわざ記載されない要件ですよね？ましてシャイな理系の多い日本のプログラマ達。コミュニケーション問題が起きないわけがないと考えます。

ソフトウェア開発上の問題は端的に言って「発注者との合意形成」「プロジェクトメンバー（プログラマやテスターや運用チームや経営陣）内での合意形成」に終始すると考えています。それをウォーターフォールではドキュメント化と管理でアプローチし、アジャイルでは対話と反復でアプローチするという事になるのですが、対話でなんとかなるのは3人までと私は考えており、設計者を必要とするような規模のプロジェクトで口伝はまったく使えないです。誤解されて伝わった場合そのまま実装され、どこかの時点で手戻りが発生しますが、準委任契約の場合、コミュニケーション問題による手戻りコストを発注者に押し付けていることになるのではないでしょうか？（作り方のマズさは発注者の責任ではないのに）

Aさんには伝わっているけれど、Bさんには伝わっていないということもありえます。特にリモートワークも多くなってきた今、定例以外にも適宜ビデオミーティングで開発中の疑問点・問題点を相談するということはよく起こるのですが、そこで話した事はその場のメンバーしか知らないわけで、ミーティングへの呼び忘れはもちろん、当日休みの人、プロジェクトに後から参加した人等にも間違いなく情報が伝わっている必要があります。Slack等非同期テキストコミュニケーションを使用するのはもちろん、仕様のように大事なものはドキュメント化し、誰がいつ見ても同じ結果を得られるようにしておかないと、後に問題を起こしかねないと考えます。

（その２）開発は作って終わりではない

ソフトウェアは1回作って終わりではなく、テスターさんにテストをしてもらい、ユーザーや運営チームに使ってもらい、バージョンアップを重ねてより良くしていくものだと思います。

対話による開発はプログラマ間は良くても、テスターに最終仕様を伝えテストしてもらい品質管理を行うという点において問題があります。作ったプログラマー自身がテストするとなると「プログラマはテストをしてはならない（作った人は動くと思っているのでテストが甘くなる）」という原則に反し、より大きな問題があります。アジャイルでは問題が起きたらすぐ直せば良いという考え方になるのですが、小さな問題はそれで良くても、大きな問題を起こした場合は会社の信用問題になります。テスターに正しく仕様を伝えるためには口伝は不可です。弊社では仕様書とテスト仕様書を用意しています。

最終仕様があいまいなため取扱説明書が作成されず、「使って慣れろ」的にユーザーや運営チームにソフトウェアが渡されていないでしょうか？何がどう変わったのかカスタマーサポートや広報にも伝わっておらず、問い合わせがきてオロオロなんてのが目に浮かびます。

バージョンアップの際に影響範囲を特定しきれず、開発がちぐはぐになる可能性は無いでしょうか？例えば、データにある項目が増えたのでAさんが実装したけれど、AさんはBさんに連絡しておらず、Bさん担当のファイル出力にはその項目が含まれていないままなど、サービス全体として整合性が取れなくなる事が考えられます。人数が少ないうちは連絡も密に取られるでしょうが、10人、20人となってくると、誰が何を担当しているかを全員が把握しているということはないでしょう。

このように、ソフトウェア開発・運営には様々な人が関わるため、その人数が増えれば増えるほど対話ベースのコミュニケーションで完結させることは難しいと考えます。

（その３）属人的な開発はメンバーの入れ替わりに弱い

弊社は現在（2022年12月）プログラマを社内に抱えていませんので、必然的に外注の開発会社さんにお願いすることになります。業務委託契約になりますので、「誰が働くか」を指定することはできず、プログラマが交代することも多々ありました。新入社員だったり、外国籍の方だったり、転職したての人だったり。

既存メンバーがプロジェクトを離れてしまうのは痛手ではありましたが、それでもオンスケで開発できたのは、綿密なドキュメントで「誰が担当になっても同じように実装できる」という事を担保していたからです。（開発環境の準備や開発コードに慣れる時間は必要でした）

対話での開発は履歴がどこにもなく属人的になるため、どうしてもノウハウが人と一緒に失われてしまいます。もちろん引き継ぎ期間があったりしますが、対話で行われた全てを引き継ぎとかは不可能です。次第に「時間をかけてソースコードを読むしかない」とか、「何故こうなっているか分からないけど、担当者がもういないので触れない」みたいな事が出てきてしまいます。

（その４）品質管理の考え方に反する

前のプロジェクトで、医療機器のソフトェア品質管理の国際規格ISO13485に準拠して作成してほしいという要望があったのですが、要約すると設計・開発・テスト・運用の各段階でドキュメントを残し、承認プロセスを設け、テスト結果を残しなさいというような事が書いてあります。

言い換えるとこのような事を行わないと品質や安全性が担保できないだろうというのがISOが提示している事なのですが、対話によって記録を残さない開発手法はこの考え方の真逆であり、責任者や問題の発生箇所を曖昧にし、品質や信用にかなりリスクを抱えることになるだろうと考えます。

ドキュメントが無いことのデメリットは他にも多々ありますが、ドキュメントを必要としないような規模・内容の開発であれば対話ベースでも良いかと思います。簡単なWebページを作成したいとか、社内業務ツールに機能を1つ追加して欲しいとか、イベントで1ヶ月間しか使わないスマホアプリを開発したいとか、自社で全て責任を持てるWebサービスの開発とか。

アジャイルが使われるべきプロジェクトを間違っていないか？

アジャイルはそもそも予測が難しい課題に対して話し合いやドキュメントを書く時間は無駄なので、要望に対して即座に実行し、テストし、だめだったらまた別のものを試そうという価値観です。

逆に言うと、予測可能なものについてはドキュメント化し、ソフトウェア開発上の数々の問題をシステマティックに回避するべきだと考えます。人材募集を見ると、仕様書を描ける人がいない、あるいは予算がないのでプログラマに仕様書を書かせようというプロジェクトが多々あるようです。他人事ながら、その後問題が起きないと良いのですがと思うばかりです（繰り返しですが、世の中の50%のプロジェクトは要件定義の曖昧さから何らかの問題を発生させています）。開発手法はプロジェクトの性質によって正しく選択するべきでしょう。

ウォーターフォールの弱点は克服できないのか？

前出の通り、ウォーターフォールの弱点もあります。プロセスの長大化による反復性のなさが指摘されているのですが、アジャイルは価値観であって開発手法そのものではないという事から、短期間反復型ウォーターフォール開発というものがあっても良いということになります。

仮にアジャイルで1つの仕様変更を即日実装、翌日リリースできたとします。これを弊社で行っていたウォーターフォールのプロセスで考えてみます。

・クライアントから仕様変更要望が来た時点で合意済みとみなす。
　場合によってはXDで画面を作成したり、要件定義まで遡って合意形成。
　今回は1日で実装できる程度の機能なので、即日合意できたとする。
・即日仕様書更新
・即日～翌日発注
・即日～翌日実装完了
・翌日オンライン/オフラインマニュアル更新
・翌日～翌々日テスト
・翌日～翌々日実装完了をお伝えし、リリース日時を決めてもらう
　BtoBのプロジェクトだったため、クライアントのクライアントに連絡が必要なレベルの内容だと1週間待ちとかもありうる。
・翌日夜～翌々日リリース

といった感じでしょうか？できないわけではありませんが、仕様書更新というプロセスは必要なため、アジャイルよりは一手遅いかもしれません。また、こういう作業が五月雨式に起こるようなプロジェクトですと、やはりドキュメント化作業とバージョン管理が破綻するだろうと感じます。

前のプロジェクトは中規模（プログラマが最大で10人）で、3～4ヶ月に1度のバージョンアップを何度も繰り返していましたが、基本的には要件定義でしっかり合意済みでしたので「気に入らないので作り直し」というよりは「機能追加の実装」に集中できていたかと思います。リリースまでの間隔を短くして、小さい機能をなる早でリリースしていくということもできたかと思いますので、短期間反復型ウォーターフロー開発も不可能ではないと思いますが、バージョンが増えると年中テストとデバッグばかりしていて新機能が実装のために時間が使われないという事にもなり、ちょっともったいないとも感じますので、機能の緊急性を考慮し、リリースタイミングやリリース間隔を調整していくのが良いかと思います。

まとめ

ウォーターフォールもアジャイルもメリット・デメリットがありますので、プロジェクトの性質に合わせて選択するのが良いかと思います。スピード感アップのためにドキュメント化を重視しないアジャイル開発は適切なプロジェクトで使用しないと、後々大きなリスクとなってしまいそうです。逆に、予測が難しくトライ・アンド・エラーを繰り返したいプロジェクトではチーム規模を小さく保ち、アジャイルを選択するべきです。

LUXALAは詳細な「要件定義書」と「仕様書」作成が得意なので、中規模以上のウォーターフォール型開発に向いています。コミュニケーション問題、品質問題、人の入れ替わりなどにも強い開発ができますので、設計・開発の依頼先をお探しの場合は是非弊社にお問い合わせください。