Lichtwork（リヒトワーク）では様々な形でシステムやアプリの開発や運用をお手伝いさせていただいています。やはり開発についてのご依頼が多いのが現状です。

開発を行うに関して、Lichtwork（リヒトワーク）では設計書を「そこそこ」作成します。

弊社の場合、チームとしてまるっと開発やデザインを担当する場合と、プロジェクトマネージャーの立場で開発を支援する場合がありますが、前者の場合だと意思伝達に苦労することがないのですが、後者の場合は会ったことがない人との開発の業務になることもあり、どういう風に作って欲しいかをある程度提示する必要があるためです。もちろん、どういうものを開発したかお客様に提示する必要があるため（お客様が引き継いだ後困らないように）作成するということもあります。

故に状況によって分量の違いはあれど創っていることが現状です。

私が設計書をかく時に意識していること

私が設計を書くときは「使いやすく」や「便利に」、「メンテしやすく」、「自動で」などフワッとしているところを開発者に対して具体的な方法を提示することを意識します。

例えばアプリを起動して通信中になるとき、どういう形式の読み込みにするのか、読み込み中にユーザー操作は許可するのか、どれくらいでタイムアウトさせるのかなどバックエンド側の仕様を加味しながら、使いやすい挙動を指示します。

また、全体設計や非機能設計、画面設計といったことを行う中で不確定要素がないかを確認します。不確定なところにプロジェクトとしてのリスクがあることが多く、早期に問題を洗い出して話し合うことができます。そうすることで今のAPIではアプリ側が実現できなかったなど後で発覚することをできるだけ防ぐことができます。

アジャイルのような開発の進め方であっても全体設計や非機能設計は最初の段階で行っておき、「最終的にはこうなっているべきだよね」的な共通認識をチームで持ちつつ、各機能の設計はスプリントごとに行っていく形を取ります。

設計書を書くべきなのか議論

全体的な設計書や、画面設計書、共通仕様書（エラー周りなどアプリやシステムで全体的に影響する仕様書）、非機能設計書など作るものは様々ですが設計書を作る場合に「デザインあるし設計書いらないんじゃない？？」や「設計書あっても、メンテできなくなるしいらないんじゃない？」という話には偶になります。

前者の「デザインあるし設計書いらないんじゃない？？」論については作ったデザイナーやお客様、開発チームの距離感によると思います。デザイナーやプロダクトマネージャーなどが密に連携している環境であれば可能かもしれないですが、受託のような場合だと難しいと思います。連携できるような環境であっても、エラー系であったり、システムやアプリとして使いやすいような内部の作り、どういう技術を採用するか、非機能部分等デザイン面で描かれない部分を設計しておくことはどうしても必要になります。言語化しなくてもチームの文化の中で様々考慮することは目指すべきですが、曖昧なことはカルチャーにしづらく、定着しづらいのではと思います。文字や図として表現されていることで、チームとしての共通認識や目指すべき方向が見え、それが文化となっていくのではないかと考えています。

後者の「メンテできなくなる」論については設計書の問題ではないと思います。タスクに紐づく仕様の変更の際に設計書を修正すれば良いだけの話で、できなくなるのは人手が足りない、どこに設計書があるかわからんなど体制の問題なのかなと思います。

次回以降具体的にどういう内容の設計書をそれぞれ書いているか少しずつ紹介できればと思います。