我々は、なぜ設計書を作成するのか
はじめに
先日、「設計書の書き方」セミナーで、設計の効率化＆品質向上のために下記3つのうちどれが一番大切だと思うかを聞いてみました。みなさんなら、どれを選びますか。
- (A)設計スキルを教育する
- (B)設計の標準化を進める
- (C)設計ツールを導入する
システム設計ツール(CAD)を自らの効率化のために作った身からすると、今こそ(C)は重要だと思っています。しかし、そんな私でもこの3つはどれも大切で、どれが一番とは甲乙つけがたいものと感じています。
内心、票が割れるかなと思っていたのですが、結果は(B)の標準化に手を上げる人が圧倒的に多くいました。
それほど多くの人々が重要視している設計書の標準化ですが、その割にはチームごと、部署ごとにフォーマットがバラバラで、「組織単位で設計書を標準化できている」と胸を張れる会社は多くありません。そこで、令和時代の設計書の標準とはどうあるべきかをテーマにしている本連載ですが、今回はその前に設計書そのものについて考えてみたいと思います。
我々は、なぜ設計書を作成するのか
アジャイル開発のプロジェクト憲章として使われるインセプションデッキ(Inception Deck)をご存じでしょうか。これはプロジェクトスタート時にチーム内で10の質問を行い、プロジェクトの目的や方向性を共有するものです。これ、2019年の流行語大賞になった“One Team”を作るのにすごく有効なので、私も仕事でよく使っています。
なかでも第1の質問「我々はなぜここにいるか(Why Are We Here?)」は、そもそものプロジェクトの意味や目的を共有するのに有効で、プロジェクトの途中で振り返ったときも原点はなんだったかをハッと気づかされます。これを適用してみましょう。「我々は、なぜ設計書を作成するのか?」という問いになりますね。そうです、設計書の標準化を行うには、そもそも設計書を作成する意味や目的を明確にして共有する必要があるのです。
設計書を作成する目的は、主に次の3つです(図1)。
図1：設計書を作成する目的
(1)完成イメージを共有
あなたが宝くじに当選して家を建てるとしましょう。「洋風のモダンな感じ」「子供も持ちたいので3階建て」「1部屋は和室も欲しい」など建築士に好みを伝えると、建築士はその要望に沿った家をイメージして設計してくれます。
ただ、口頭で希望を言ってお任せしただけでは、いざ出来上がったときに「え、全然イメージが違う!」となりかねません。建築士は、あなたの望みに沿った設計書を作成し、それを見てあなたも「ここはこう変更して」と具体的に指示する。そんなことを何回か繰り返して、ようやくあなたと建築士は完成イメージを共有できるわけです。
この完成イメージは、建築士だけでなく、棟梁以下大工さんや左官屋さん、内装屋さんにとっても重要です。彼らも彼らなりの裁量で作業するところもあるので、完成イメージを持たずに指示された通りをやるだけだと、どうしてもちぐはぐした家になってしまいます。
これはシステム開発でも同じです。顧客の要件を聞いてイメージできたとしても、それは顧客の思っているものとは違うかも知れません。そのため要件定義なら要件定義書、基本設計なら基本設計書、詳細設計なら詳細設計書、というようにドキュメントに起こして顧客に確認を取るのです。
通常、顧客と設計ドキュメントを共有する(レビューミーティング)のは基本設計までで、詳細設計は“提出するので確認の上ご承認ください”というスタンスが多いようです。家を建てる際も同じで、コンセントの位置や電球の配置などが描かれた詳細な図面までは細かく説明しないことも多いです。
ただ、顧客側でそれをきちんと確認して「寝るとき電球を消せるように枕元にもスイッチが欲しい」「ドライヤーは左手に持つので、コンセントは左側に付けて」など細かなレベルで指示しないと、建った後で後悔する場面が出てきます。
(2)プログラマーに対する仕様提示
大工さんは、建築士の作成した詳細な設計図をもとに家を建てていきます。同じようにプログラマーは、システムエンジニアの書いた詳細設計書を見てプログラミングします。ここをクリックしたときにどのようなイベントが発生し、どのようなロジックで処理が行われるか、その記述があるからこそプログラマーは要求仕様通りのものを作ることができるのです。
先ほど、顧客とのイメージ共有は基本設計レベルのことが多いと説明しましたが、プログラマーが必要とするのは詳細設計レベルです。つまり、基本設計書は顧客がイメージしやすいことを念頭に書き、詳細設計書はプログラマーが作業しやすいように配慮して書くことが肝要です。
(3)保守・運用の負担を軽減する
システムを開発した人が、必ずしもそのシステムの保守や運用を行うとは限りません。通常は別の人が保守業務を担当しますが、もし、設計書がなければ、問い合わせ対応や障害調査、障害の修正に対応するためにソースコードを解析して理解するしかありません。
これは、第三者でなく本人が保守するときでも同じです。誰しも1年前、2年前に開発したシステムの内容はきちんと覚えていないので、やはり設計書がないと効率がぐっと落ちてしまいます。
変更を依頼するユーザーからすると「なんでこんな軽微な変更にそんな工数がかかるの?」と疑問に思うのですが、まともな設計書がない状態では、軽微な変更でもどうしても膨大な時間を要します。新規開発時にメンバー全員がひたすらシステムに向き合っていたときとは違うのです。保守フェーズは、ともすると10倍、20倍も効率が落ちていたりもして、第1回で説明した「保守・運用にコストの7割がかかっている」という好ましくない状況の原因になっているのです。
- 麻里：家を建てるのに設計図は必須ですよね。これまでの説明を聞いていると、システム開発だって設計書が要ると思うんだけど、なんで設計書が不十分なシステムが多いのかしら?
- 先輩：う～ん、そうだねぇ。いくつか理由があるかな。1つはSEとPGが同じってケース。建築の場合、建築士と大工さん、左官屋さんは別の人だけど、システム開発では設計者自らがプログラミングするってことがある。
- 麻里：最近、そういうパターンが増えているって聞いたことがあるわ。
- 先輩：ロケーションの問題もあるね。建築の場合、大工さんが現場で作業しているところに建築士はいないけど、通常システム開発ではSEとPGは一緒にいるから阿吽の呼吸で伝えたり、質問を受けたりしやすいんだ。
- 麻里：たとえ離れていてもチャットでやり取りできますしね。
- 先輩：それと後から変更が効きやすいって面もある。建築の場合、右に付けちゃったコンセントを左に移すってのは大変だろ。だけど、システム開発ならコントロールの位置をずらすなんて簡単にできる。
- 麻里：建築だときちんと設計しないと大ごとになるけど、システム開発なら軽微な変更を許容できる柔軟性があるってことね。
- 先輩：でも、建築だってラフな設計図でかまわない場合があるよ。例えば犬小屋を作るとしたら、ささっとイメージをデザインして、後は“現合”で作っていくだろう。でも、家やビルを建てるには、そういったアジャイル式は通用せず、きちんとした設計書がないととんでもないことになる。
- 麻里：規模の問題ね。大規模システムはウォーターフォールが多く、小さなシステムはアジャイルが用いられ易いのがうなずけるわ。
- 先輩：まあ、そんなことをいろいろ総合的に判断して、設計書をどこまでビシっと作るか決めているってことなんだろうね。
- 麻里：でも、優秀なプログラマーに甘えて、設計がタコってケースもありますよね。先輩も、いつも指示がアバウト過ぎますから、ちょっとは反省してください。
- 先輩：お、そうか。じゃあ、お詫びに何かおごろう。今晩、いつものところで、あれ食べに行こうか?
- 麻里：えーと、叙々苑で雪会席ですね。了解しました～♪
設計書は、なぜ信頼できないか
もともと設計書を作らないアジャイル開発ならいざ知らず、きちんと設計書を作ったはずのウォーターフォールでも、とかく「設計書が古い」「あるけど信頼できない」となっています。新規開発に使われた設計書が保守運用の際は信用できないものになってしまい、結局、いちいちソースコードを解析する羽目になるのはなぜでしょう。この問題について少し考えてみます。
せっかく作った設計書が、保守運用の際に信用できなくて役に立たなくなる原因は、なんといってもシステム改修・変更の際に変更内容をきちんと設計書に反映しなかったことが原因です。一般に、システムが初期のままずっと使われることは稀です。通常は、障害(バグ)の対応、使いにくいところの改良、機能の向上、プラットフォームの世代進化への対応、ビジネスの変化への対応などにより、何度も何度も追加開発が行われます。
その全てをきちんと設計書に反映しておけば、設計書が信用できないなどという事態には陥りません。しかし、こうしたシステム変更においては、まず、プログラムを変更した後から設計書に反映するようなことも多く、初期のようにきちんと設計レビューをして記載洩れや記載ミスを防止するような慎重さはが薄れます。また、担当者も都度変わるので、一貫した設計品質を保つのがだんだん難しくなってきます。さらに、ちょっとでも手抜いたところがあれば、もはや次からは信頼されなくなるのです(人間の信頼関係に似ていますね)。
人が歳を取るとあちこちガタが来るように、この経年劣化を防ぐことは不可能に思えますね。しかし、保守運用コストがこれほど膨大になっている現状を鑑みて、仕方がないとあきらめてしまうのは努力不足かも知れません。前向きな人が、若さを保つために健康な生活をして手入れを怠らない努力をするように、設計書を役立つもののままにすることを考えてみましょう。
設計書の品質を維持して、保守運用を楽にするには
(1)変更の際も必ずレビューする
システムの改修・変更作業は担当者任せにしがちです。なるほど、変更したソースを本番システムに適用する際は慎重にテストを行いますが、設計書への反映に関しては「設計書も直しといて」のひと言で終わりです。ともすると設計書を書いたことのないプログラマーが見よう見まねで設計書に反映することもあり、初期に決めた設計書記述レベルに至らないのです。
これを防止するには、システム改修の際も組織で「設計書の品質を保つ」という意識を共有することが大切です。その意識があれば、自然と複数メンバーで設計書の変更時にレビューを行うようになります。そして、ここが肝心なのですが、これをきちんとルール化して明文化し、どの時代でも守ってもらうようにするのです。
(2)モジュールの関連が分かるように設計書を書く
改修・変更を行う際に大きな工数を取ってしまうのは、変更による影響範囲の調査にかかる時間です。「このテーブルに列を追加した場合はどこに影響するか」「このロジックを変更したらどこに影響するか」など、影響しそうなモジュール全部を洗い出して、1つずつソースコードをgrep検索したりして調査する必要があります。これだけでも大変なのに、漏れがあって思わぬところで不具合が生じ、さらに大きな工数がかかってしまうこともままあります。
この問題を解消するには、モジュールの関連が分かるように設計書を書いておく必要があります。ただし、これはかなり設計書のメンテナンスコストがかかるので、実質的に専用の設計ツールがないと難しいでしょう。ExcelやWordなどワープロ作業による設計書では実現不可能とも言えるので、みんなあきらめて勘で影響範囲の当たりを付けているのが実情です。実は私が設計書作成CADツール「Object Browser Designer」を作った理由の1つは、CADという現代的ツールによって、この課題を解決しようと考えたからなのです。
通常、アジャイル開発では設計書を作りません。当社でもパッケージソフトやクラウドサービスのように「納期」や「コスト」より「売れるものを作る」が至上命題のものは、アジャイル開発を用いていますが、設計書は書いていません。
こうしたソフトウェア製品は長年に渡って改良し続け、バージョンアップを繰り返します。機能もどんどん増えて行くので、当初よりもプログラム数や内容が大きく増えることになります。
そこで徐々に顕在化する問題が保守コストの増大と機能変更時のコストアップです。前述の通り、設計書がないためちょっとした内容でも作業工数がかかり、それがビジネスのスピードとコストのネックとなったりします。
この状態を何とかする方法があることはあります。それは、アジャイル開発においてもシステムができた後から設計書をきちんと書くことです。ただし、前述の設計書を書く理由の1と2はほぼ役目を終えているので、3の効果しか望めません。設計書を書くには相応のコストがかかるので、その先の保守運用コストの低減に見合うかをビジネス的に判断することになります。
当社の主力製品の1つにプロジェクト管理システム「Object Browser PM」があります。2008年にバージョン1をリリースしたこの製品が、最近、まさにそのような判断を迫られる状態でした。初期リリースから10年間ずっとアジャイル開発で機能アップを行ってきたのですが、今回のメジャーバージョンアップの際についに設計書を作成する決断をしました。AIを使ったリバースエンジニアリングで既存システムから設計データを生成し、それをObject Browser Designerで取り込んで設計書を作成したのです。それなりに工数はかかったのですが、設計書がある状態で大型バージョンアップ開発を行っているため生産性も高くなっています。この経験から、アジャイル開発でも後から設計書を起こすニーズは、これからますます高まっていくように感じています。
おわりに
今回は、Inception Deckにならい、そもそもなぜ設計書を書くのかをテーマに解説しました。次回からは、多くの人が最も重要だと指摘する設計書の標準化について掘り下げていきます。お楽しみに!
