LUXALAでは絶対にプロジェクトで失敗しないのか？とお思いになった方もいらっしゃるかと思います。
結論から先にお伝えしますと、現在の仕様書の書き方、プロジェクト管理の方法になってからは1度も失敗しておりません。
が、それまでには苦い経験もしています。このコラムではいかに弊社がソフトウェア開発の「3つの問題」を改善してきたのか、過去のプロジェクトの実録をご紹介したいと思います。
とあるソフトウェア
最初は設計のみのご依頼。仕様書のクオリティを見ていただき、開発もお願いしたいとのことで、開発ディレクター兼SEという立場で関わりました。（PMと言ってしまうと語弊がありそうなので、ここでは開発Dと言っておきます）
バージョン1.0（スケジュール遅れ・クオリティ問題あり）
社内でGoサインは出ているものの、「事業計画書」や「企画書」は存在していないご様子。まずは社内でもプロジェクトの全容がシェアされていない状態でしたので、1ヶ月かけてヒアリングを行い「事業概要説明書」を作成しました。
「事業概要説明書」によって目的、目標、ペルソナ、何のために何を作るのか、どういうUXにしたいのかがシェアできるようになった所で、「要件定義書」の作成に移行。モック状態で画面と機能の設計を行い、決まっていないことを洗い出し随時チームで決定し、約1ヶ月半で「要件定義書」が完成。
「要件定義書」に従い「仕様書」の作成に入り、並行してアプリのルック＆フィール（アプリの色合いとか世界観）を決めるために、Webアプリについてはログイン画面と主要画面の2つを、スマホアプリについてはホーム画面の1つをデザイン会社2つのコンペとし、良かった方の会社にデザインを発注することにしました。
「仕様書」については2ヶ月で完成していたのですが、先方の忙しさもあり、レビューに1ヶ月半かかり、やっと開発フェーズ分のお見積りと開発会社の選定に。この時の弊社はタスク分解を画面単位とAPI数で行っており、開発環境やサーバーの準備等にかかる時間、開発メンバーの習熟度に関する補正については考えていませんでした。また、進捗の把握も時間ではなくて消化されたチケット数という曖昧な基準で行っていました。
3.5ヶ月ほどで終わるはずだった開発なのですが、開発経験が浅いメンバーが多かったり、デザイン納品が遅れたり、仕様書の書き方がマズかったりで時間が消費された結果デスマーチが始まり、テスト開始日には全ての実装が終わっておらず、画面を開いただけでエラーが出てまともに使えず、機能は何一つ動かず、テストどころではなく開発は2ヶ月延期、発注者のご厚意で1ヶ月分コストを上乗せしていただけましたが、ソフトウェア開発の「3つの問題」すべてを起こしてしまいました。
バージョン2.0（オンスケ・クオリティ問題あり）
バージョン1.0の反省を活かし、タスク分解の際に目標時間を設定しました。チームの実力はバージョン1.0で見れたので、新規API1つ実装するのに8時間、このボリューの機能を持つ画面であれば40時間といったふうに積み上げ、全体時間から必要なプログラマ数と期間を割り出し、バージョン2.0に臨みました。ただしこの時はまだチケット数メインで進捗管理していました（終盤には時間も見ていました）。
「バージョン1.0」の時のコードが良くないので、作り直したいというチームの要望があり認めざるを得ず、一部メンバーはデスマーチにはなりましたが、オンスケ・追加コストなしで終了することはできました。が、この時の弊社はまだある程度開発メンバーに仕様書の解釈を委ねる形（例：DBテーブル名を指定せずに「〇〇のデータを取得する」等）で仕様書を描いていました。結果、テスト開始時には大量のバグがまだ発生していました。
「要件定義で合意した内容と相違ない物を実装している」という点ではバージョン1.0からクリアしているのですが、「いつかユーザー環境で問題を起こしかねない」というクオリティの問題はまだ解決できていないという認識でした。
バージョン2.1（454時間・オンスケ・クオリティ問題あり）
バージョン2.2（1557時間・オンスケ・クオリティ問題あり）
バージョン2.3（280時間・オンスケ・クオリティ問題あり）
この頃からAPI仕様書にはどこのDBにどういうパラメータでアクセスして〇〇を取り出したら、次は〇〇のXXを使って△△のDBにアクセスしてとステップごとの詳細を書くようにし、API実装上の誤解の余地を無くすように仕様書を改善しました。
「こういうつもりで動作内容を書いておいたのに全く違う実装がされてしまった」という事が減り、一段回テスト開始時のクオリティを上げることができましたが、テストされていないプログラムの納品は続いていました。（単体テストはテスターがやるものという文化があった？）
バージョン3.0（2641時間・オンスケ・クオリティ問題あり）
バージョン3.1（843時間・オンスケ・クオリティ問題あり）
バージョン3.2（2354時間・オンスケ・クオリティ問題あり）
バージョン3.3（1357時間・オンスケ・クオリティ問題あり）
基本的にプログラマーがテスターにプログラムを見てもらう時は、「動作確認はしたので基本的には動くと思いますが、普通でない入力とか操作では見逃したバグが出るかもしれません」というレベルのものが納品されるべきと考えています。でなければ、プログラマは一体何を実装したのか？自分で動作確認しながら実装したのか？という事になります。
私が過去にプログラマとして某プロジェクトに参加していたときには、2ヶ月作ったものをテストしてもらうと片手で収まるレアバグしか出しませんでした。
テスト＝問題が無いことを発注者に確認してもらう検品
と考えるか、
テスト＝様々出るであろうバグを他人任せで洗い出してもらう
と考えるかの意識の違いがあったように思えます。
「ネジを発注されたとして、納品する前に発注通りの規格でできたか自分で確認するのは当たり前」という感覚なのですが、意識の改革については後のバージョンで行いました。
それはさておき、外部テスターさんを呼んでテストする場合には、人数はかけているのにテストが止まってしまうという無駄な時間が発生するし、バグレポート数が多いと1日で確認できるテスト項目数が減ってしまい、期間内にテストが終わらなくなるリスクも抱えることになります。テストはしっかり行っていたのでリリース後にクリティカルな問題は発生していませんでしたが、まだまだ改善が必要でした。
差し当たりテストが始まる2週間前から、できた分について先行して軽くテストを行う「ディレクターチェック」という期間を設けることにしました。これにより、画面を開いただけでエラーが出るというようなレベルのバグはテスト前に除去できるようにはなったのですが、テスト項目数に対するバグ率（30%程）としてはまだ下がっていませんでした。
スケジュール管理に対してはこの頃からチケット数ではなく目標時間に対して今どれくらいなのかを管理するようにし、急いだほうが良いのか、今のペースで大丈夫なのかを見える化しました。
バージョン3.4（759時間・オンスケ・クオリティ問題解決）
バージョン3.5（375時間・オンスケ・クオリティ問題解決）
バージョン4.0（496時間・オンスケ・クオリティ問題解決）
バージョン4.0.1（438時間・オンスケ・クオリティ問題解決）
バージョン4.1（1220時間・オンスケ・クオリティ問題解決）
テスト開始時のバグ数が多いことについて、ついに開発メンバーの意識改革を行いました。「3件に1件壊れているとは何事だ。他人に見せる前に自分で動作確認するように」と。これにより、「作業完了」とする前に自分たちで動作確認してからテストに臨むように作業フローが改善されました。
結果、「ディレクターチェック」レベルで発見される単純なバグは激減し、その後のテストでのテスト項目数に対するバグ率は10%台まで下がり、バグの内容も「単純な操作で動かない」というものから「特定の条件下でのみ動かない」という風に変化し、クオリティに関する問題も解決できたと考えています。
10%でも多いと思われるかもしれませんが、弊社のテストでは入力等かなりいじめ抜くテストを行いますので、他社だと見逃されているバグも拾っているかと思います。実際、世の中にリリース済みのWebサービスを弊社基準で入力テストすると結構バグが見つかったりします。数値よりもバグの質が変わった点にご注目いただければと思います。もちろん見つかったバグは修正してからリリースします。
まとめ
このように、LUXALAも過去の苦い経験からソフトウエア開発の「3つの問題」と戦ってきました。
・進捗はプログラマの感覚ではなく数値で管理する
・仕様書は誤解の余地が入らないように、詳細に書いてしまう
・新規メンバーは手持ち工数に補正をかける
・テスト前にテストする価値もないようなバグは除去しておく
・プログラマの品質に対する意識を上げる
等々の改善を経て、
・スケジュール問題なし
・コスト問題なし
・クオリティ問題なし
というプロジェクト進行を実現しました。開発メンバーも定時で帰れるプロジェクトでした。私以外は。
各バージョンが終わったらすぐ次のバージョンの開発に入れるように、開発・テスト期間中に次のバージョンの要件定義と仕様書更新を済ませておかなければならなかったので、開発ディレクター兼SEな私は中々時間のないプロジェクトでしたが、お陰様で他社に負けない仕様書と開発管理方法を編み出せました。
弊社の設計・開発にご興味のある方はぜひお問い合わせください。