私は入社して8年、ずっと開発部に所属しプログラマとしてソースコードを書いてきました。その中で経験したプロジェクトの一つで、いつもとは違う役割を受け持つことがありました。

「スペックライター」という役割を担当し設計書を書くことに専念する時期があったのです。この経験によって今までとは少し違った視点でプロジェクトを見ることができました。「設計書を書くより実装した方が早い」そんな現場の雰囲気にちょっと違うぞ、という思いが出てきたのです。
この違和感は何だったのでしょうか。

アーツテックの開発手法

一般的にウォーターフォール型と呼ばれる開発手法では、まず要求・要件のヒアリングをおこない、概要設計、詳細設計などのプロセスを順に踏みながら設計書などのアウトプットにまとめていく流れになります。
この段階で出来上がった設計書に基づいて実装がおこなわれるわけです。

アーツテックの開発では、対照的なアジャイル的開発手法を取り入れています。 なぜこのような開発手法を採用しているかというと「最初からお客様の要望が整理されている訳ではない」ということが理由の一つにあげられます。
お客様から最初に出てくる要望は曖昧さや矛盾を含んでいます。（これは当たり前のことです）

また、お客様自身も気づいていない要望もあります。そのため何度もヒアリングを重ねて要望をまとめ、システム上矛盾が起きないように整理していくことが開発者には求められます。
この隠れた要望まで聞き出し実現していくために、アジャイル的開発手法を取り入れているのです。

ヒアリングから出てきたイメージを少しずつ文章や図に書きおこすことで、設計書の初稿が出来てきます。それと同時に実際にプログラムを書いて動くイメージを見てもらうことで細かい仕様を詰めていきます。
こういった開発手法を採用しているので、実装と設計書作成は同時進行で進んでいきます。

設計書には何を書くのか？

どんな情報を設計書に書くのかといえば、もちろん「システム（仕様）について決定したこと」を書きます。曖昧な部分についても「要検討」として残しつつ情報を書いていくことになります。

しかし、設計書と実装が同時進行する故の問題点もあります。

• 実装が先行している場合、実装内容が設計書にフィードバックされにくい。
  
  開発の現場では設計書よりも実装を優先させる傾向があるため、あとでまとめて書こうと考えてすぐにはフィードバックされない現状があります。
  このため書き漏らしが出たり、スタッフによる情報共有が徐々にできなくなってしまいます。
• 仕様が不明瞭なまま実装をすすめる場合があるので、実装途中でお客様へ仕様の確認をする必要がある。
  
  そうなるとお客様からの回答が来るまで実装が止まってしまいます。
  
• テスターがテストケースを作成できない。
  
  テストケースを作成するためには明確な仕様が必要です。
  仕様書がないとテストの精度が落ちたり、テスターの進捗に遅れが出てしまいます。
  

そこで感じたのが、

「『設計書をベースにした仕様の検討』が重要なのではないか？」

ということです。
初めから仕様を決めることに必死になってしまっては、変化するお客様の要望に柔軟な対応がとれません。
しかし設計書を書くことで「この項目を書くための情報が決まっていない」と具体的に不明点を洗い出せれば、動くアプリケーションを見る前でも具体的な要望を引き出せるのではないでしょうか。

早い段階で設計書の精度を上げることができれば、同時進行の問題点を解決し、実装やテストでの負担が軽減できる。設計書と実装をうまく同時進行させることで、プラスの相乗効果をあげることができるだろうと感じたのです。

残したものを活かすために

プロジェクト自体は順調に進みスムーズに納品することができましたが「もう少しこうすれば良かった」「この情報を残した方が良かった」と思うものが見えてきました。それは何でしょうか？

当社はありがたいことに、一つの案件が継続しそのお客様と長いお付き合いになることが多くあります。そのため数年後に仕様変更が発生した場合、当初受け持っていた担当者が変わっていることが考えられます。

また新入社員が入り、初めてのプロジェクトとして関わることも当然あります。
そういったときに、現在の仕様に関する資料はもちろん、プロジェクトの経緯がわかる情報や仕様変更が起きた際の変更理由などの情報が残っていることが重要な意味を持ってくるのです。

限られた時間の中で設計書作成に割ける時間は多くありません。その中でも残すべき情報は必ずあります。また、残した情報が役に立つ形で残っていることも重要です。適切な内容を、適切なタイミングで書き残し、更新し、運用していくことができれば、開発の現場はより良くなっていくでしょう。

アーツテックではドキュメンテーションに対する意識は年々高まっていますが、まだそのノウハウが足りないと感じています。
どのような情報をどのような状態で残していくかなどの課題はたくさんありますが、一つ一つ解決していき、会社全体で通用するルールを作っていきたい。
それが開発の現場を充実させ、生産性向上につながっていくのではないかと思うのです。