残業も減らせる!? 上級エンジニアになるためのDesign Doc超入門：プロジェクト成功確率向上の近道とは？（3）（3/3 ページ）

ITシステム開発の問題点の一つであるコミュニケーションの失敗。本連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、「技術視点」のドキュメントとして、2000年代以降注目されている「Design Doc」について解説します。

[寺田英雄，株式会社オープンストリーム CTO]

見せかけの納品用ドキュメントではない――Design Docを活用した開発

　Design Docは見せかけの納品用ドキュメントではありません。プロジェクトの中心に置いて実践的に活用することで真価を発揮します。ここでは、実際の開発プロジェクトに適用するときの使い方やポイントについて述べます。

どんな場合に書くのか

　Design Docをどういう場合に書いて、どういう場合に書かないのか？ 筆者の基準は『このソフトのプログラマーが自分だけであり、かつ実装時間想定が2〜3日以内』の場合にはまずDesign Docは書きません。ここまで小規模であれば書かなくても大した問題にならないからです。

　それ以外の場合（複数のプログラマーが関わっている、または実装に4日以上かかる）にはDesign Docを書くように心掛けています。

いつ書くのか

　要求仕様（要件）が一通り決まった後、実装フェーズの前に書きます。1〜2週間かけて書くことが多いと思います。それ以上時間がかかる場合は、単独で書くには大き過ぎる恐れがあります。範囲を分割して、Design Doc自体を分割して作ったり、複数のエンジニアで分担して書いたりすることを検討しましょう。

どう管理するのか

　Design Docはバージョン管理できる環境に置きます。Markdownなどのプレーンテキストで作成してソースコードと一緒にGitやSubversionのリポジトリに置いたり、Google Docで作成したりする方法です。メンバーがいつでも参照したり修正したりできることが大切です。

常に最新に保つ

　実装を進めていく中で設計変更が必要になることがあります。その場合はすぐにDesign Docを修正しましょう。緊急の場合をのぞき、Design Docを修正するまではコードを修正しないのが得策です。

コードレビューの必須資料にする

　Design Docのご本家、グーグルではコードレビューが制度化されており、その際必ずDesign Docの提出が求められるそうです。レビュワーはまずDesign Docを読み、それからコードをレビューするのです。この方法は非常に質の高いソフトウェアの開発につながることは容易に想像がつきます。ぜひ読者のチームでも取り入れてみてはどうでしょうか。

テスト計画を前倒しにする

　Design Docがあれば、実装と並行してテストケースを作ることができます。少なくとも「どういうテストを、どれぐらいの規模で実施しなければならないか」について基礎的な見積もりはできるはずです。

ユーザーマニュアルなどの作成を前倒しにする

　Design Docがあれば、実装と並行してユーザーマニュアルやPR資料を作ることができる場合もあるでしょう。これにより、営業や広報チームはいち早くマーケティング活動を開始できます。

「ソフトウェアを設計する」ことの意味とは

　当たり前の話ですが、Design Docを書くには設計という作業が必要です。最後に、「設計する」ことの意味について、あらためて確認しておきます。

『設計する』とは、何をすること？

　ソフトウェアの設計の本質は今も昔も変わりません。それは『データ構造』『アルゴリズム』『インタフェース』を目的に応じて適切に決定することです（図3）。

図3　ソフトウェア設計の主要要素

　時代と共にプログラミング言語や実行環境・開発方法論などは変化しますが、上記の設計の本質は変わっていません。従って、これらの本質をつかんでおけば、今後もさまざまな場面に適用することができるでしょう。

　以下では、その概要を簡単にまとめておきます。

データ構造の設計

　『データ構造の設計』とは、データベースのスキーマやファイルフォーマット、オブジェクト指向を適用する場合のクラス構造、変数の型や配置など、システム上でデータを格納する方法や形式を決定することです。

アルゴリズムの設計

　『アルゴリズムの設計』とは、上記のデータ構造にアクセスして、何らかの計算や変換・転送などを行うプログラム上の手順や方法・仕組みを決定することです。さらに、アルゴリズムは、『処理アルゴリズム設計』と『制御アルゴリズム設計』の2つに分けると考えやすいと思います。

• 処理アルゴリズムの設計

　『処理アルゴリズム設計』は、入力データを出力データに変換するまでの計算手順を決定することです。フローチャートやUMLアクティビティ図などを使って表現することができます。実装上は一つのメソッドや関数、APIなどの形を採ります。

• 制御アルゴリズムの設計

　『制御アルゴリズム設計』は、前記の処理アルゴリズムがいつ・どのような条件で実行されるのか、その順序やタイミングについて決定することです。状態遷移図や、タイミングチャートなどで表現することができます。実装上は、メインループやイベントディスパッチャなどで現れますが、最近はアプリケーションフレームワークの中にあらかじめ内蔵されていることも増えたので、フレームワークやミドルウェアを選択することもこの設計の範囲でしょう。

インタフェースの設計

　『インタフェースの設計』は、システム内・外で2つ以上の要素が交わる境界部分の仕様を決定することです。Web APIやBLEなどのデバイス・ノード間の通信のプロトコル、オブジェクト指向言語でのオブジェクトの呼び出しインタフェースなどがあります。

　ユーザーとシステムの境界も含めて考えると、ユーザーインタフェースもインタフェースの一種です。画面レイアウトや操作方法などを決定することも含まれます。

分割と階層化をうまく使う

　データ構造、アルゴリズム、インタフェース、どれもさまざまな要素が組み合わさって成り立っているのが普通です。一気にそれを設計しようとするのは無理がありますので、分割や階層化を行って適切なサイズで区切って設計していきましょう。

　複雑な問題を分割して解決する、これはエンジニアの基本スキルの1つです。

まとめ：Design Docを使いこなして設計できるエンジニアになろう！

　本記事では、Design Docの紹介と、書き方、そしてプロジェクトで活用する方法について概要を述べました。また、「ソフトウェア設計とは何をすることなのか」について簡単に述べました。

　Design Docが書けるようになると、ソフトウェア開発のスピードや品質は飛躍的に向上します。プロジェクト初期にやるべきことが明確化できますし、Design Docを通じてコミュニケーションを取ることができるので、チームメンバー間の認識の食い違いが少なくなり、無駄な手戻りなどが大幅に減らせるからです。何より、はっきりした目標を定めてからコーディングすると気分の良さが全く違うのです。残業も減ります。

　またIT業界の動向を考えると、今後は賃金の安い新興国勢や人工知能の発達などにより、設計できない（＝単純なコーディングしかしない）エンジニアの活躍の場は少なくなっていくでしょう。逆に、設計思想を持ち、“魂のこもった設計書”が作れる『本物の』エンジニアはいつでも引っ張りだこです。活躍の場が減ることはありません。

　このようにDesign Docを書く技術を身に付けると、さまざまなメリットがありますので、読者の皆さんにはこの記事をキッカケにして、Design Docが書けるエンジニア、すなわち、設計ができるエンジニアになってほしいと願っています。

著者プロフィール

寺田英雄

株式会社オープンストリーム CTO

1990年代から制御・FA系の画像認識、動画処理を中心としたソフトウェア開発に携わってきた。

2007年からはインターネットIT系に転身、モバイル系開発などを経て、2012年にオープンストリーム入社。

現在は数理アルゴリズムや機械学習・AIを応用した次世代の計算機システムに挑戦している。

『理論と現場の融合、知恵と勇気の開発』がモットー。