お疲れ様です。
ブログでは初めましてになります。8月入社のKWと申します。
現場で勤務していて思ったことをもとに記事を投稿します。
見苦しい箇所もあるかと思いますが、お手柔らかによろしくお願いいたします。
無くても良いけれども
皆さんは現場等で仕様書は書いていらっしゃるでしょうか？
私が現在お世話になっている現場では、基本的に機能仕様書というものがありません（テスト仕様書はあります）。
正確に言いますと、仕様書はあるのですが、現状のシステムの状態が反映されたものではないそうです。
機能説明の際も仕様書でなく、お客さん向けのマニュアルを見たり、実際にシステムを触ってみるということがほとんどです。
改修や実装の指示も口頭ベースでメールや簡単なメモだけだったり。
現場の方曰く、毎年アップデート・改修がある古いシステムでお客さんとの信頼関係があるから都度都度は作っていない、とのことでした。
ですが、私のように外部からお邪魔している側からすると、やはり仕様を知るには仕様書があると助かるなあと思うことも正直なところです。
この現場だけではなく、仕様書をいちいち修正しないという場合があることに以前の私は驚いたのですが、今回、少しだけ初心に帰り、仕様書にまつわる考えをいくつか整理してみたいと思います。
※仕様書はあったほうが良い、とか仕様書がないと困る、などと非難するものではございません。
思い出
私は新卒で入社した会社が厳しめで、仕様書はもちろん、その他ドキュメントや成果物等の書き方はしっかり指導がありました（と記憶しています）。
いわゆるウォーターフォール型の開発手法を採用している会社でした。
仕様書のレビューを待っている間に実装を着手していようと、仕様が固まらずスケジュールが怪しくなってきていようと、仕様書ありきでの実装工程ですので、まずは仕様書を仕上げます。当たり前ですがスケジュールの前半は手戻り前提です。
そのような中で私が気を付けていたのが、「分かりやすい文章で書くこと」です。
単純なようですが当時の私にしては試行錯誤していたように思います。
ITやシステムに詳しくなくても理解してもらえるように書きたいと思ったので、ITの世界では常識、というか普通なことでも端折らず書いていました。
また、説明になると接続詞が連続するなどで一文が長い文章が多い印象があったので、一文を短くして分岐条件は改行したり、例外処理は後述したり、とにかく「読む気が起きない」といったことを減らしたいと考えていました。
（BtoCの案件がほとんどで、実際にシステムを使うのがシステム担当者ではないことが多かったです）
幸い、当時はソースを日本語にしただけの状態のような仕様書を推している会社でしたので、気持ちが乗ってくると私には好きな工程で、「いかに読みやすい仕様書を書くか」が楽しくなってしまいました。
などなどの理由もあり、個人的には、仕様書を見ながら実装するという順番が身に付いているため、仕様書が無いという事実がむず痒いのです。
スピード感のために
とはいえ、仕様書のレビューや承認を待っていられない場面も認識しております。
（言葉選びがよろしくないですが）手順を踏まえたお役所仕事的なやり方だとスピード感が足りない、という場合です。
動いているシステムの改修で「この不具合で何日も止まるのは困る」ということは必ずあります。
そういった場合に備えて即時対応ができる体制を保証する契約をしている現場にいたこともありますが、いろいろと大変そうではありました（人員不足）。
このような場合ウォーターフォール型ですと、まず仕様書の修正からです。
ですが、「まずは動くように修正して日常の業務に支障が出ないようにしてほしい」という考えはもっともだと思います。
お客さんとのメールや電話の「ではここはこう直しますね」というやりとりで承認とみなし、とにかくお客さんの希望通り動くものを、という対応も大事だと思います。
希望や依頼含めレスポンスが早いということはどの分野でも印象の良いものだと思います。
コードを読んで仕様を知れと言われる場合もありますが、そのようなシステムに限ってコードのコメントが少なくて可読性が低かったりします。
設計した人・コーディングした人にしか分からない仕様というのは、実に不親切だなと思うのです。
そういうとき、やはり仕様を知るための媒体として、「仕様書があったらなあ」と思わずにはいられません。
まとめ
仕様書を作っておくことの利点がもう1つあります。
「お客様とはこの仕様書に基づいてシステムを作りますという約束をしています」と言えます。
つまり何か不具合かも？ということが起きた場合に「これは仕様書に書いていないので」と言ってしまえます。
もちろん印象は悪くなるかもしれませんので一概には言えませんが、要望として上がってきていないことを、開発者が察して考慮できるとも限りません。
「こう動かないのはおかしい！不具合だ！」と言われても、「その考慮は入っていないんです、仕様書にも書いていないでしょう？対応してほしいなら仕様変更ですね（お金もらう）」という流れを何度か耳にしています。
ユーザーによって独自ルールや暗黙のルールがあったりもしますので、本当は仕様確定時のヒアリングの際に漏れがないようにできるのがお互いにとっても一番良いことだとは思うのですが。
以前勤めていた会社の先輩に言われたことで印象に残っていることがあります。
「何かが起きてしまったときに自分を守るため、少し手間がかかってもエビデンスを残しておくことは悪いことではない」
これを言われたのは当時担当していた定常作業の対応手順をまとめている時でしたので、厳密には状況は違うのですが、確かに、確実に自分の責任ではないことを説明するのに、それを補う証拠がないことは説得力に欠けてしまいます。
もし、それが仕様書だったら。仕様書に書いている・書いていないことで、お客さんが承認済みの仕様書だったら。
責任逃れのための備えをしておこうということではありませんが、理不尽な状況を回避出来る可能性はあると思います。
成果物に厳しい現場もたくさんあると思いますが、もし「仕様書ってめんどくさいなあ」と感じてしまっている方がいたら、単なる成果物としてではなく、「自分の立場を少しでも安全なほうへ連れて行ってくれるかもしれない」と考えてみるのはいかがでしょうか。
私個人としては、この考え方をプラスしたことによって、仕様書だけではなく成果物に取り組むモチベーションが変わってきました。
仕様書があるに越したことはないけど、時間も人も割く余裕がない、というケースももちろん認識していますが、仕様書、あるとやっぱりいろいろ助かるよね、ということで、今回の記事のまとめとしたいと思います。
