ソフトウェア開発で失敗しないためには? “失敗に対してゆとりがない”時代だからこそ伝えたい傾向と対策『「失敗」の教科書』

私の失敗談を共有することで、ソフトウェア開発に携わる皆さんの成功を少しでも後押しできればと思い執筆しました。前職の後輩たちに、私の失敗を踏み台にして「成功してほしい」という想いもあります。

大学時代は応用機械工学を専攻し、ソフトウェア開発は独学でやっていました。経験もないのに「俺はソフトウェアができる」という謎の自信を持っていて、詳細を把握しないまま友人からソフトウェアづくりを安請け合いすることも。その結果、期日に間に合わず大迷惑をかけることもありました……。その時、最初の要件整理とリソース確認が大切だということを、身をもって理解したのです。

入社したのがハードウェア製造の会社で、入社当初に配属されたのはソフトウェアと関係ないコピー機の印字方式を研究する部署でした。日々の業務のなかで、「良いハードウェアだけでは良い印字はできず、ハードウェアとそれをコントロールする良いソフトウェアが揃い、その両方を理解することで、はじめてより良い製品が作れる」という気づきを得て、自主的にソフトウェア開発にも挑戦。しかし、当然最初からうまくいかず数々の失敗をやらかしました。

はい、その後ソフトウェア開発部門に異動してからもいろいろな失敗がありましたが、会社は私の新たなチャレンジを支援してくれました。新しいプロジェクトのリーダーなどもまかせていただき、とても感謝しています。

本当にそう思います。ただ今は当時と違って、社会全体で失敗に対してのゆとりが少なくなっているように感じます。だからこそ、ソフトウェア開発に携わる方々ができるだけプロジェクトを成功に導けるように、私の失敗談が少しでも役に立てば本望です。

現場でよくあるのは、機能がてんこ盛りで実装が間に合わない「全部入りソフトウェア」の失敗です。顧客や販売サイドから求められる機能を全部入れようとして納期に間に合わない。「こんな機能が欲しい」という機能面の要望と、「いつまでに完成させて欲しい」という開発スケジュールの要望が両立せず、デスマーチに陥ってしまいます。

はい、最初は営業担当者からの期待もあり「何とかやりきるぞ」とがんばるのですが、想定以上の工数が必要になり毎日残業する状況に陥ってしまいます。

まず、開発メンバーが初期の打ち合わせや企画に参画すること。そして、機能と日程のミスマッチが起きないよう、営業サイドも含めた関係者の目線を合わせて開発スケジュールを決めることです。

現実的な開発リソースを鑑みて、削減するべき機能をすり合わせることが必要になってきます。最終的にソフトウェアに求められるのは機能の数よりクオリティです。質を担保するためには「この日程ではこの機能までしか搭載できない」ということを正直に説明して理解いただく。そのうえですべてのステークスホルダーが納得できる落としどころをすり合わせることが重要です。

顧客の本当の困りごとを捉えていない「顧客要望通りの使えないソフトウェア」という失敗があります。私たちの業界では、「顧客は自分の欲しいものを知らない」と言われることもあり、「顧客の欲しい機能＝顧客の困りごとを解決する機能」ではない場合が往々にしてあります。

対策は2つあります。まず、顧客からの困りごとや課題、開発するソフトウェアでどんなことを成し遂げたいのかを詳細に聞きだすことです。顧客の多くは、本当の課題に気づいていなかったり、うまく言語化することができなかったりするので、機能面の要望にとらわれず開発側が掘り下げて質問することが必要です。

例えば「ハードウェアからデータを抽出」という機能要望があったとしても、データ活用の目的によって抽出の仕方が変わります。データ抽出でどのような課題を解決するのかわからなければ適切なソフトウェアをつくることはできません。「データを抽出したい」という要望だけでソフトウェアをつくってしまうと、現場で使えないものができてしまうわけです。

「使えないソフトウェア」にしないためのもう一つの対策としては、機能にユーザーが遊べるゆとり、つまり自由度を持たせるということです。顧客の課題を解決するソフトウェアができたとしても、使いにくければ現場で活用されません。そのために、顧客が使いたいように機能を選択できる自由度を持たせることが大切です。

データ保存を例にすると、オリジナルのフォーマットだけではなく、汎用的なCSVで保存する方が良いユーザーもいます。人によっては些細なことでも「少し工夫することで課題を解決できる」ということは最終的な満足度に大きく影響すると思います。

実装を具体的にイメージできない「ふんわり仕様」に注意が必要です。一見すると問題なさそうに見えて、具体的に作業をしようとすると仕様書の詳細があいまいで作業ができない。それを私は「ふんわり仕様」と呼んでいます。

大きく分けると2つの失敗があります。まず必要な工数を見誤ってしまい、納期に間に合わなくなってしまうこと。もう一つは、詳細がよくわからないまま進めた結果、オーバースペックや機能が足りないなど、間違ったソフトウェアをつくってしまうことです。つくるものを間違えることはソフトウェア開発における最大の失敗だと考えていますが、それを誘発するのが「ふんわり仕様」です。

「利用シーン仕様書」というものを作成しています。これは、ソフトウェアの具体的なシーンを考え、利用シーンごとに要件となぜその要件が必要なのかを書き添えたものです。失敗しないソフトウェアづくりで最も重要なことはコミュニケーションであり、仕様書は重要なコミュニケーション手段の一つです。開発者が自分の思い込みで作らないように「利用シーン仕様書」で意思疎通を図っています。例えば、アームチェッカーのデータ確認シーンでは、次のような内容を伝えるといいでしょう。

もちろんこのような書き方でなくても、表や箇条書きなどでも大丈夫です。大切なのは、顧客がこのソフトウェアをどのように使おうとしているのか、どういうシーンで、どういった課題を解決しようとしているのかを伝えることです。

まず、前提として仕様書は正確に伝わっていないと認識しましょう。そのうえで、開発者のひとりよがりにならないよう、販売や品質保証の担当者なども交えて利用シーンを考え、全体の合意を得られるように進めていくことをおすすめします。

設計思想がない「形だけインターフェース」という失敗があります。設計当初にイメージしていたアーキテクチャがつくるうちにどんどん崩れていき、バグを直してもまた次のバグが出て、収束が困難な状態に陥るという私がやらかした最大級の失敗です。

そうなんです。その背景として、ソフトウェアを多数のメンバーでつくるようになり、「なぜそのソフトウェアをつくるのか」という目的や、「その目的をどのように実現するのか」という設計思想が十分に理解されないまま業務が進んでいることが挙げられます。その結果、エンジニアが自分の解釈でインターフェースを迂回したり、ルールとは異なるデータのやりとりをするなど、個々の最適化が原因でいつのまにかアーキテクチャの全体像が崩れてしまうわけです。

対策として私は仕様書に設計思想を明記しています。一般的な仕様書には「なぜこの構造になったのか」「どうしてこのようなインターフェースになっているのか」といった設計思想が書かれていない場合が多いんですね。設計思想が共有されないため、エンジニアがそれぞれに解釈してしまい、インターフェースが形だけのものになってしまうんです。

解釈のバラツキを最小減にするため、「なぜこの構造になっているのか」といった設計した人の意図や志を明記し、説明することが大切です。例えば、私の場合はアーキテクチャ全体の機能ブロック図を手書きで書いて示しています。そうすると機能とその関係性が理解でき、「万が一、共通演算部分を修正するとアルゴリズム全体に影響ありそう……」など、やってはいけないことがイメージしやすくなります。

特に海外のメンバーがいる場合は、文化が異なり言葉だけでは伝わりにくいこともあるので、私はいつも小さなホワイトボードを携帯し、図にして会話していました。また、相手が話していることを理解できていないケースも多いので、私の理解が間違っていないか必ず確認するようにしています。

まず、リーダーが自分からアクションをしない「聞くだけ進捗会議」という失敗があります。私の経験上、一番失敗に近づく方法は「何もしない」ことです。ソフトウェア開発は、未解決の課題を決められた期間内に解決することであり、いわば問題を抱えた状態からのスタートです。そのため、業務を進めるうえで「問題が発生することは当たり前」と思ったほうが自然です。

つまり、プロジェクトはスタート時点から必ず「問題」をはらんでいるので、何もしないでいられるわけがありません。ところが私はなにごとも波風を立てたくないタイプの上司だったため、進捗会議で報告を聞くだけで疑問を持たず、課題があっても先送りしてしまう*ことがありまして。その結果、アーキテクチャ崩れなどの失敗をおかしてきました。

そのとおりです。そして「課題に気づくことは良いこと」だと捉える姿勢も大切です。課題の発見をネガティブに捉えてしまうと開発者から課題があがってこないという状況に陥り、課題を見逃すんですよね。その背景には、面倒をおこしたくないという気持ちがあるのかもしれません。

そのような意識は、リーダーだけではなくメンバー側にもあります。チームから課題や失敗の情報が上がってこない「怖い会議」も失敗のよくあるケースです。

開発メンバーが課題に気づいても、責められるのが怖くて開発リーダーに伝えないことから発生する失敗です。メンバーが進捗会議で開発の遅れをリーダーに伝えると、「先週も進んでなかったよね？」「どうやって遅れを取り戻すの」などと質問されるケースが度々見られます。

リーダーとしては「遅れた理由」を知りたいだけだったとは思いますが、担当者としては自分が責められていたり、原因を追求されたりしているように感じてしまう。そのような環境では、担当者が課題に気づいてもリーダーに報告しなくなり、リーダーが課題に気づいたときには手遅れの状況に陥っていることもあります。

私が開発リーダーのときに意識していたのは、課題や困っていることを何でも言い合えるチームにすることです。「心理的安全性」ということが注目されて久しいですが、失敗して怒られるのではなく、相互的なコミュニケーションを心がけていました。

「こんな失敗しちゃってさぁ」と、自分から率先して自分のダメなところをメンバーに話します。また私からメンバーに「ここ困っているんだけど、助けてくれない」と相談を持ちかけ、解決したら「助かったよ、ありがとう！」とお礼を言う。そうやって相談しやすい場づくりを心がけた結果、小さなことでも課題をあげてくれるようになりました。

そもそもプロジェクトの遅延は担当者が悪いわけではなく、さまざまな要因が関連して起こることが大半です。そのため、できるだけ話しやすい関係性をつくることを意識していました。

ほかにも、進捗会議をできるだけ楽しくリラックスできる場にしたいと思って、会議でおやつを配り、ざっくばらんに話をしていました。いわゆる「もぐもぐタイム」ですね。些細なことですが、小さなことの積み重ねが心理的安全性につながると思っています。

ソフトウェア開発は「失敗」か「成功」かの2択ではなく、失敗を積み上げた先に成功があります。そのため、業務への影響が小さい段階で失敗に気づいて取り除くことが大切で、それを繰り返すと小さな失敗に気づく嗅覚が少しずつ養われます。失敗というのは再現性が非常に高いので、失敗のプロセスや要因がわかっていれば、あらかじめ失敗に備え、対処することができるんです。私の失敗事例を伝えることで、皆さんの「失敗に気づく嗅覚」が少しでも養われるとうれしいです。

失敗は恐れるのではなく「楽しむ」のが一番ではないでしょうか。誰でも日々の業務で何らかの失敗をします。そのため全力を尽くしているのであれば、「失敗」をくよくよ悩んだりするよりも、「誰かに話せるネタができた」とポジティブに捉える方が健康的だと思います。本書はそんな思いで執筆した「失敗ネタ」の集大成なので、各エピソードを楽しく読みながら日々の業務に活用していただけるとうれしいです。