システム開発にドキュメントは必要か？(Joel on Softwareを読んで)
僕らのシステム開発の世界には、常に戦争がある。vi VS emacs戦争、スペース VS タブ戦争から始まりウォーターフォールかアジャイルかで論争を繰り広げ、MVCかMVVMかで揉める。
古い議論から新しい議論まであるが、もう２０年以上前からありいまだに普遍的な論点の１つに「設計ドキュメントを書くべきか」議論があると思う。プロジェクトが進むたびに悩み、働く組織を変えるたびにその方針はみんな異なる。
18年前、僕は新卒でITコンサルの会社に入り、いくつかのシステム開発プロジェクトを経験した。顧客は大企業でシステムはミッションクリティカルなでかいシステムであることが多く、プロジェクトは当然のごとくウォーターフォール、基本設計書から詳細設計書まで山のようにドキュメントを書いた。
一方で外のイケイケなITベンチャーが出す「時代はアジャイル！コードがドキュメント！」「システム納品のスケジュール？そんなのない。完成した時が納品の日だ！」(もちろん実際のアジャイルはそんなんではない)みたいな講演会や本を読んで時代遅れのくそ開発から脱したいと何度も思った（そして、プログラムを書かないスーツな顧客・同僚にイライラしていた）。
僕は、その後数社のスタートアップでシステム開発の現場を経験してきたが、そこでの開発プロジェクトは時代の最先端をいく夢のノーストレスな開発経験だったかというとそんなわけもない。やはり、みな色々な課題と非効率に苦しんでいた。
2022年現在、世界はシステム開発手法におけるベストな手法をまだ完全に見つけ出せてないと思う。しかし、一方で僕も含め多くの人は過去に苦しみ解決策を求めた先人の成果を理解せず、同じ苦しみを経験してるようにも思う。
先日、僕はふと部屋の本棚の隅っこにある黄色い本を見つけた。2000年頃に書かれたJoel on Softwareは、僕が20代の頃読んだ本の中でも５本指に入るくらい心に残っている名著だと思う。とはいえ、感動したことは覚えていたが正直中身をちゃんと覚えてるわけではなかった。
20年の時を経て読んだ内容は、この移り変わりの激しいテクノロジーの世界においても色褪せてはいなかった。もちろん技術内容は20年前の話ではあるが、そこにある著者の哲学、経験値からくるベストプラクティスは、2022年の開発現場で起こる課題のソリューションにも十分になり得る話である。
Joel on Softwareは、MicrosoftでExcelなどの開発に従事した著者が開発に関するさまざまな話題に言及し意見を述べたブログをまとめた本である。色々な話題がありどれも面白いのだが、ここで「設計ドキュメントを書くべきか」議論に戻ってこよう。
Joelは、設計ドキュメントの必要性について以下のように述べている。
仕様書の最も重要な役割はプログラムをデザインすることだ。
たとえあなたがすべてのコードを1人で書いているのだとしても、純粋に自分自身のためだけに仕様書を書くのだとしても、仕様書を書くという行為自体によって一プログラムがどう機能するか詳細に記述するということによって
一プログラムを実際にデザインするように強いられるのだ。
人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。
ワープロ文書の段落を1つ削除するのを残念に思う人はいない。
しかし、あなた がプログラミング言語で製品をデザインしているなら、
反復デザインには何週間もかかる。さらに悪いことに、あるコードを書くのにはんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせることはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。
それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになる。
僕はこの経験を何度も経験している。プログラミングをする時は、少なくともそのコードを書いてる時はそのメソッド・その機能の一部のことしか考えていない。全体のアーキテクチャは当然頭の中で事前に考えているのだが、基本的に細部が色々抜け落ちている。そして、抜け落ちていたポイントはその部分のコードを書いて初めて気づく。「あれ、ひょっとして前に３日かけて書いたモジュールは、このコードだと使えなくない？」。そして、とりあえず無理矢理使えるようコードを取り繕い、「技術負債はリファクタリングで直そう！また今度！」となる。
一方で、プログラマーにとってとにかくコードを書いて動くもので試したい衝動は相当なものだ。ドキュメントなんか書いて苦労して他の人に説明するよりコードで動かして「ドヤっ」って言って終わらせたい。だがこの感情が品質の低いプロダクトを作る原因の１つになるのだろう。
またコミュニケーションの時間を節約できるというのもドキュメントを書く大きな理由だと彼は言っている。マーケティング担当者から品質保証のテスター、もちろんエンジニアに至るまで全ての人がそれぞれの仕事をするために必要な機能理解を１人１人に口で説明しなくて済む。
「いや、わかるんだけど、でもやっぱりドキュメントは時間かかるし放っておくと陳腐化するし、（エンジニアは）日本語書くよりコードを書きたいんだよ」
そういう想いは前述の通り、僕もずっと持っていた。その回答として彼は「プログラムマネージャー」というロールを採用するべきと言っている。プログラムマネージャーは
それ以来、Microsoftのプログラムマネージャたちは要求を集め、コードが何をすべきか見極め、そして仕様書を書いている。通常、プログラムマネージャ 1人に対しプログラマが5人いて、このプログラマたちにはプログラムマネージャが仕様書の形で表現したことをコードに実装する責任がある。プログラムマネージャはまた、マーケティング、 ドキュメンテーション、テスト、国際化、その他プログラマが時間を費やすべきでないあらゆる煩わしい詳細に関して調整を行う必要がある。最後に、Microsoftのプログラムマネージャは、この会社の 「ビッグピクチャー」を心に抱いていることを期待されており、一方、プログラマたちはといえば、正しいコードを書くことに専念することができる。
である。
これを見て僕は改めて時代は変わってないなと思った。今プロダクトマネージャーという職種が非常にニーズがあり人材が枯渇している。企業によりプロダクトマネージャーの定義は異なるが、僕は「プロダクトをどのように改善していくか計画し、機能仕様を考え関係者に共有し完成までドライブする」というロールだと思っている。この本で言っているプログラムマネージャーと被るところが大いにある。
また、プログラムマネージャーは誰がなれるのかという話において「プログラマーを昇進させてプログラムマネージャーにしてはいけない」「マーケティングの人間をプログラムマネージャーとして採用してはいけない」と言っていて、プログラムマネージャーは独立したキャリアパスであると言っている。理由は本書を参照して欲しいが、そら今のプロダクトマネージャーも人材不足になるよなーと思う。
著者の毒舌を織り交ぜながら口語調で書かれていて、非常に読みやすくコードを読み解く技術書ではないので、非エンジニアでも楽しめると思う。ぜひお試しあれ。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？