こんにちは。ディレクター（PM）の山中です。
わたしはコーディングの経験はあるのですが、エンジニア経験がない。
そんなわたしですが、企画から開発完了まで約半年かかったシステムをバグ０で納品できました。今回はこのプロジェクトを進めるにあたって実践したことを振り返りつつ、まとめてみました。
※この記事では、バグとは仕様どおりにソフトウェアが動かないことと定義させていただきます。
ヒアリングではわかったふりしない
システム開発のスタートの多くはお客様から「こんなシステムをつくりたい」と要望を受けることから始まります。しかしながら、この時点での要望はシステムを完成させるには、足りない情報が多々あるのが通常です。
そのため、要望を具体的にする・定義する・目的を明確にするためにヒアリングすることからシステム開発はスタートします。
このヒアリングの時点で心掛けたのは「わかったふり」をしないこと。
お客様にとっては通常業務であっても、わたしにとっては経験したことのない業務ばかりです。面倒な人だなとか、こんなことも知らないの？と思われるかもしれないと内心ビクビクしてますが、お客様の通常業務を理解していないと、完成した時に「思ってたのと違う」という結果になりやすいとわたしは思っているので、わかったふりをしないよう心掛けてヒアリングしました。
自分の認識がズレていないか確認するために、わたしがよく使うテクニックは「具体例を自分から挙げる」です。しかも、イメージしやすいように、お客様の名前や商品名を使います。
例えば「太郎さんがAを仮予約中、花子さんはAを予約も削除も変更もできないという認識でよろしいでしょうか？」といった具合です。具体例が正しいか質問することでお客様と認識をあわせやすくなりますし、自分から具体例が挙げられない場合は理解度が低い可能性が高いと判断できますよ。
要件定義する時点で簡単なテスト仕様書を作る
ヒアリングした上で、要件定義をしていきます。通常、要件定義の段階ではテスト仕様書を作ったことはありませんでした。
しかし、今回の案件で初めて要件定義の段階で簡単なテスト仕様書を作成しました。QAエンジニアさんから、要件定義を作成する時期に、たまたまテストについて教えてもらったことがきっかけでした。
狙った訳ではなかったのですが、結果的にシステムの精度を高めることにとても役立ちました。
お客様と要件定義をする時にも、エンジニアに開発を依頼する時にも簡単なテスト仕様書を使いながら説明したのですが、何が正解なのか、ゴールなのかを明確にしやすくなるんです。
PMがソフトウェアテスト技法を学ぶことはメリットがすごく大きいことを体感したので、まだ学んでない方がぜひ取り入れてみてください。
お客様にできないことをはっきり伝える
システム開発がスタートしてからでも仕様の変更ができるのか？追加費用が発生するのは、どの段階になるのか？など、お金と時間の問題が、お客様とシステム会社とで曖昧になりがちです。
私自身、過去にこの点の曖昧さが仇になり問題になった経験があります。そのため、今ではお客様にできないこともはっきり伝えるよう心掛けています。
しかしながら、予算内で対応するのが困難な追加要望の場合、即答はしないケースがほとんどです。なぜなら、お客様が追加したい気持ちもよくわかるので、エンジニアに作り方を変更したり、一部だけの機能で相手の要望の半分でも実現できないか相談した上で、お客様に返答と提案させていただくケースがほとんどだからです。
ビジネスであるために、損することは避けねばなりません。だからこそ、その予算の上限いっぱいまで使って、頭をフル回転させて、良いシステムを提供させていただけるよう努力を続けたいなと思っています。
まとめ
ここまでエンジニア経験のないPMがバグの少ないシステム開発のために実践した３つのことをまとめてみましたが、いかがでしたでしょうか。
仕様は何が正解なのかゴールなのか定めたものだと思っています。PMがゴールをはっきりさせることでお客様がゴールの位置がそこでよいのか判断しやすくなり、エンジニアやデザイナーが動きやすくなりますよね。
これからもPMを担当させていただく機会があれば、お客様もエンジニアもWinWinの関係になって、気持ちよくゴールを決めるアシストができるよう努力したいなと思ってます。
では、みなさま、今日もよいシステム開発を。
