せっかく予算をかけてシステムを発注するのだから、何か問題が生じたりせず無事にプロジェクトを完遂してほしいというのは誰もが願うところだ。しかし実際には、世の中の開発プロジェクトの約50％において、何らかの問題が生じているという。
LUXALA株式会社では、開発プロジェクトにきちんとSEを立て、要件定義から仕様策定までをしっかりと行い、詳細な「要件定義」と「仕様書」であいまいさを排除することで、問題の発生しない開発プロジェクトを行っているという。そこで、LUXALA株式会社の代表取締役の山本 竜司氏に、開発プロジェクトにおける問題発生の原因と、プロジェクトを成功に導くポイントについてお話を伺いました。
成功率50％とも言われる開発プロジェクトの原因とは？
―― システムソフトウェアの開発は難しいものなのでしょうか？
LUXALA株式会社 山本氏 発注先の企業がきちんとしていれば、難しいことはありません。しかし、ある調査では、システムの開発プロジェクトの約50％において、スケジュール・コスト・クオリティなど、いずれかの面で問題が発生しているといいます。発注企業から見れば、1/2の確率で問題の生じるプロジェクトに当たってしまうことになります。スケジュール通りにサービスを開始できないとか、ブランドを毀損するといった重要な問題も起こりうるので、コインを投げて運よく表が出るかどうかに賭けるようなことはするべきではありません。
―― 半数で問題発生というのは大きいですね。そうした問題は、なぜ発生するのでしょうか。
山本氏 いくつかの原因はありますが、その多くは要件定義段階のあいまいさが、開発やテスト段階の問題となっていることが指摘されています。ソフトウェア開発発注時のポイントがあるので、紹介していきましょう。
要件定義があいまいだと何が起きるのか
―― 要件定義があいまいだと問題が生じるというのは、どういうことでしょうか。
山本氏 発注先である開発企業と、発注元であるユーザー企業と間で合意形成がなされていないので、開発後や開発途中で「これでは困る」というような仕様変更が多発し、作り直しの時間やコストが必要になるというのが典型的なケースです。
代表取締役 山本 竜司氏
要件定義があいまいだと、それを基に作成される仕様書もあいまいになります。プログラマを集めて「さぁ開発スタートだ」となった時に、まずやることが仕様の確認です。このとき仕様書があいまいだと「こういうケースではどうするのか」といったことを、開発中もずっと逐一確認し続けなければならず、開発にかける時間が足りなくなってしまいます。
また、どういう仕様になっていれば正解かなのかが定義されないため、後工程となるテストフェーズにおいても何がどう動いていれば正しい動作なのかが分からず適正なテスト作業ができません。
そうして時間や予算が足りなくなった結果、いわゆる「デスマーチ」が始まり、さらに仕様がカットされた結果、望んだものと違うものが出来上がってしまいます。
―― 発注側にとっても受注側とっても不幸な結果ですね。
山本氏 しかもこれは開発時だけではありません。仕様書が作成されていないので、バージョンアップ時にどこからどこまでが影響範囲なのか、担当者一人一人に聞かないと分からないといったことも起きかねません。担当者が転職等でプロジェクトを離れると、何が仕様で、どう変更すればよいのかといったノウハウが失われてしまいます。そのリスクにいくら払いますかということなのです。
プロに頼んだのだから任せておけば良いというわけではない
―― 発注側にとってはプロにお任せするのだから、そういうところは、しっかりやってくれているものと思ってしまいます。
山本氏 本来はそうあるべきです。しかし、全ての開発会社が手間暇かけたプロフェッショナルな作り方をしているとは限りません。お寿司を食べるとして、回転寿司店も高級寿司店もお寿司を提供しますが、そのクオリティには差がありますよね？ それと同様のことが、システム開発にもあるということです。
ヒアリングの段階でスケジュールや予算を正確に見積もることは不可能で、過去の経験や勘で「目標」とか「上限」として根拠なく設定されています。
短納期・低予算のために要件定義もそこそこに、いきなりプログラマを集めて開発に入ってしまう事も少なくありません。予算の問題からプロのテスターではないプログラマにテストをさせるといった事も多くなります。
―― プログラマがテストを行うと問題が生じるのでしょうか。
山本氏 プログラマは作った本人ですから、自分では動くと思い込んでいます。そのため、動く範囲のデータでしかテストをしないことが多いですね。たとえば半角数字のフィールドに半角記号を入力するようなテストが漏れたりします。リリース後に重大なバグ、たとえばデータベースに想定外のデータが格納されてしまうなど、といったことが見逃される確率が高くなります。
3つの問題を回避するためのLUXALAの取り組み
―― そうした問題が生じないようにLUXALA様が取り組んでいることとは、どのようなものでしょうか。
山本氏 当社では、発注者側も受注者側も幸せなプロジェクトとするために、弊社では要件定義によるクライアントとの合意形成を最重要視しています。具体的には、プログラマではなく設計業務を専門とするSE（システムエンジニア）が担当します。
ITに馴染みがない方にはプログラマとSEの違いが、あまりよく分からないかもしれませんが、よく、家を建てるときの建築士の大工さんにたとえられます。建築士は設計を専門としていて、大工さんは建築士が設計した図面を基に、現場で家を組み立てていきます。
同様にSEは、要件定義段階で全画面についてどういう機能・画面遷移があって、どういう制限や懸念事項があるのか全て洗い出し、曖昧性を徹底的に排除します。
SEが定義した要件を基に、プログラマやテスターが必要とする情報が全て網羅されているレベルの仕様書を作成することで、プログラマ間の相談の必要を極力なくし、プログラム作成に集中できるようにしています。
また、テストフェーズでは、仕様書を元にテスト仕様書を作成し、何がどう動いていたら正解なのかを明示的に定義して、テスターがテストをする時に抜けや漏れが無いようにしています。こうすることにより、仕様を完全に把握している弊社スタッフや外部のプロのテスターによるテストを行い、様々な知見を使ってソフトウェアのクオリティをアップさせます。
―― SEが入ることで、開発スケジュールやコスト増、開発後のバージョンアップについても解決しますか。
山本氏 はい。開発全体で何時間必要なのかを1時間単位で明示し、コストとスケジュールの根拠を提示可能です。また、全時間中何時間が完了したのか、定量的に進捗を把握しています。
たとえば、開発メンバーの交代が起こっても仕様書が存在するので新規メンバーのキャッチアップが早くなります。
また、バージョンアップの際も、影響範囲の洗い出しはSE一人で完結でき、何をどう変更するのかも仕様書で明示されています。
―― いわゆる炎上プロジェクトやデスマーチにならないということですね。
山本氏 日経クロステックに掲載された「プロジェクトの本質とはなにか」（2013年10月16日：プロセスデザインエージェント 芝本秀徳氏著）という記事によると、不確実性コーンという考え方があり、見積りのズレは時系列とともに二次関数曲線のように収束していくというもので、ヒアリング段階の見積りは、本来かかる工数やコストに対して最大で4倍、最小で0.25倍のズレが生じてしまう危険性があり、これが詳細設計完了段階でならプラスマイナス10％程度しかズレないということです。本来の工数やコストとあまりにも大きなズレが生じてしまうようでは、発注者にとっても開発者にとってもリスクが高過ぎます。
したがって、安全面を考えるなら設計段階と開発段階で契約を分け、ヒアリング段階の見積もりで全ての契約をしないという進め方を考慮してみてください。きちんとSEが入って設計してもらってから再度見積もりを出し、そこで判断することで大きなリスクは避けられるでしょう。
ソフトウェア開発で失敗しないための8つのポイント
―― 失敗しないために、どのようなところに気を付ければ良いのでしょうか。
山本氏 事前に「SEはいますか？」「テスターいますか？」ということを、しっかり確認することです。「プログラマがやります」はNGです。「テスト仕様書はありますか？」と聞くのも効果的です。
プログラマ一人で完結できるような小規模のプロジェクトも存在するので、あくまでも「事業計画書が必要となるような規模のプロジェクト」では、という前置きをした上で、開発会社選定時には以下のようなポイントを押さえておくと良いかと思います。
【1】納期・予算を十分に用意する
納期が短いのは、設計・相談にかける時間がカットされているのかもしれない。予算が少ないのは、プログラマしか参加させず、SEやテスターのコストがカットされるのかもしれない。何かが削られているとすれば、それが何かを知るべき。
【2】コストの安さよりも、クライアントとの合意形成を重視している会社を選択する
どういうプロセス・スケジュールで、どういう資料を作成してもらえるのか聞いておく。
【3】誰が仕様書を作成するのか確認する
専任のSEが仕様書を作成する会社を選択するべき。プログラマが作成する＝人数集まってコストがかかっているのに、相談ばかりで時間もかかる。
【4】まずは要件定義まで、可能であれば仕様書作成までを発注し、見積もりの基礎となる資料ができてから開発以降の見積もりを取る
ヒアリング段階の見積もりは不正確な上にトラブルに備えるためのスケジュール・費用が多めに計上されている（最大で4倍のズレが出るリスクも）。要件定義の段階で1.5倍、仕様書作成の段階で1.1倍にまで誤差を無くせる。
【5】進捗はどのように把握するのか
プログラマの感覚任せだと危険。全タスクのうち何％まで終わっているかを定量的に把握できる進め方かどうかを確認しておく。
●プログラマの感覚と実際の進捗とのズレ
【6】テスト仕様書が存在するのか、テストは誰が行うのか確認する
仕様を把握している人か、外部テスターが行うべき。プログラマによるテストを信用してはいけない。
【7】要件定義に積極的に参加し、不明点・懸念点はこの段階で全て洗い出す
システム要件はユーザー側のニーズに基づいて定義されるため、そこに積極的に参加するのは大前提。機能面だけではなく、運用面や制限事項についても少しでも懸念があれば、この段階で明らかにしておく。
【8】開発に入ったら極力仕様を変更しない
変更する場合はスケジュールとコストに対するダメージをよく相談する。α版、β版を作って見せて手直しという手法もあるが、コストと時間がかかる。設計段階できちんと見ておくことが大切。（最終仕様の予測・決定が難しく、開発中の仕様変更が高頻度になることがやむを得ない場合にはアジャイル型開発という手法もありますが、メリット・デメリットがあるので、正しく運用しないと失敗する確率が逆に上がってしまうと弊社では考えています。）
以上、項目は多いのですが、結局のところ発注者と開発者との間のコミュニケーションがきちんと取れているかということが根底にあります。上記のポイントを踏まえてコミュニケーションを取ることが重要だと思います。
■関連リンク
