天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

「アーキ部#9~古典探訪 Warterfall~」に参加してきた

architect-club.connpass.com

今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

イベントの概要

古典リーディング企画、第1回目はウォーターフォールという名称のもとになったRoyceの「MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS」です。

「そもそも、本論文ではWaterfallとは一言も言ってない」とか「工程の戻りを正式に定義したものだ」とか聞きかじりでは、そういうふうに言われてきた論文ですが、実際にはどうなのか? 何が書かれていて、何が書かれていないのか? 実物を読んでみて、生の言葉で理解してみましょう、という試みです。

 

会で印象的だったこと

Kawashimaさんが論文を事前に日本語訳してくれて、全体向けに読み上げをしていく形式で進みました。
論文の中で印象的だったことを以下に記載します。

ドキュメントの重要性

また、ドキュメントがどれくらいの量必要かが定量的に記載されていたのも、印象的でした。
500万ドル(当時の金額で概算すると15億)のソフトウェアであれば1,500ページくらいのドキュメントが必要だろうということです。勿論、ページ数がいくら多くても、かさ増しされてしまっていたら意味はないですが...
1970年代での話ということを踏まえると、そこまで違和感はない(むしろ少なめと感じるのでは?)と思いましたし、システム関係者の共通理解を形成するという意味で、ドキュメントの重要性を改めて実感しました。*1

ウォーターフォールというイメージから離れた記述が50年前の論文にあった

2回工程を繰り返そう(プロトタイプを事前に作って顧客に見てもらおう)という主張や、できるだけ早い段階で顧客を巻き込んで商品を検証しようという話など、現代でも中々できていないことが、システム開発の成功のためにやるべき作業として定義されていたのに驚きました。
全体を通して、フィードバックが遅くなることで発生するリスクを低減するための提案が多かったのも印象的でした。
ちなみに、Royceがプロトタイプ作成に書けて良いと考えている期間は、リリースまでにかかる期間の1/3~1/4ほどでした。

マイナス記号や2の係数の欠落の欠落などは目視で管理すべき(コンピューターを使うには高価すぎる)という主張

今回のイベントで、時代の変化を一番個人的に感じた場面がこの部分でした。
マイナス記号の欠落などを目視で確認するというのは、今では有り得ない話ですが、コンピューターが高価だった当時としては自然な発想だった模様です。

シンプルなウォーターフォール開発で上手くいった試しがないというRoyceの主張

論文のまとめの部分で、シンプルなウォーターフォール(要件定義→設計→開発→テスト...)で上手くいくわけがないという主張がはっきりとされていました。

また、ウォーターフォール文脈の「手戻り」にコストを使うくらいなら、プロトタイプを開発したり、ドキュメントを充実させた方がまだ健全だという主張もあり、シンプルなウォーターフォールを、肯定しているというよりも否定していた点が印象的でした。

全体を通した感想

古典的な論文(原典)に改めて向き合うと、自分が理解していた内容とは全然違う主張が展開されていて、驚きと共にこれまでの自分の無知を痛感しました。

Kawashimaさんが論文を全部日本語訳した上に落ち着いた声でゆっくり読み上げをしてくれて、会の途中でお金を払わずして参加してて良いのかが不安になりました。
古典的な論文(原典)を読む貴重な機会を得ることができて、得られた学びも多く、参加していて楽しかったです!

参考資料

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS(ウォーターフォールという名称のもとになったとされるRoyceの論文)

http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

【参考】マーチンファウラーのWaterfallに関する言及

ウォーターフォールプロセス

*1:論文中でドキュメントが作成されていないPJで起きる良くない兆候が記載されていて、耳が痛くなる話が幾つかありました