「失敗は成功のもと」という使い古された言葉を引くまでもなく、明日の成功をつかむためには、失敗からいかに多くを学び取るかが一つのカギとなるだろう。

だが、失敗を糧に大きく成長する人がいれば、いつまで経っても同じ失敗を繰り返してしまう人もいる。その差を分けるのは何だろうか。

エンジニアtypeと@typeが主催する、エンジニアのキャリアを考えるためのワークショップ型イベント『キャリアごはん』。第3回は3月24日、「サービス開発の失敗学～仕事の”しくじり”をその後のキャリアに活かすには～」をテーマに開催した。

ゲストスピーカーには経験豊富な以下の4人の著名エンジニアを迎え、失敗を成功へとつなげるために必要なこと、さらには開発、チーム運営、キャリア形成における自身の失敗談と、それをどう乗り越えたかについて語ってもらった。

　■ クレイジーワークス 代表取締役総裁　村上福之氏
　■ カブク CTO　足立昌彦氏
　■ ドリコム テクノロジー本部 アプリケーションスペシャリスト　大仲能史氏
　■ Cerevo CTO　松本健一氏

ここでは、当日のパネルディスカッションの模様をレポートしよう。

ウイルス混入、仮想通貨の誤配……若いころはみな、失敗している

業界では名の知れた存在である4人だが、長い仕事人生においては、多くのエンジニアがそうであるのと同じように数々の失敗を経験してきているようだ。

村上氏は大手家電メーカーに入社して半年ほどの若手時代、ウイルスに感染したPCでプリンタドライバを製造してしまい、世に出る直前の倉庫にチーム総出で出向いて回収するという騒動を起こしたことがあった。

松本氏がCTOを務めるCerevoでも、会社初のプロダクトを出荷した後にミスが発覚し、製品を全数回収したことがあったという。

ソフトウエアでも同様のことは起こる。Android用IME『Simeji』の開発者である足立氏は、プライベートプロジェクトとして立ち上げた当初は「すべてが失敗で、リリース後にユーザーに指摘されてばかりだった」と振り返る。

ドリコムが手掛けるソーシャルゲームの業界では、ゲーム内で使用できる仮想通貨がある。これを何十万人というユーザーに誤配すれば、たとえ単価は安くても損害は数千万単位になる。こうした致命的なミスは、実は業界では「あるある」なのだと大仲氏は言う。

振り返れば血の気の引くような大きな失敗も少なくない。失敗自体は誰もが通る道だと言うことができるだろう。

失敗と向き合わない人、失敗に気付かない人

では、こうした失敗を糧に成長する人と、いつまで経っても成長できない人とは、どこが違うのか。村上氏や足立氏は、成長できない人は「自分のミスを認めずに、ごまかそうとする傾向が強い」と主張する。

「できない人ほどプライドが高く、自分の失敗を認められない。実際にはできていないのにできていると主張する人が、実は結構多い気がします」（村上氏）

「プログラマーは、どこが間違っていたのかを理詰めで考える人たちの集団なので、失敗を隠し通すことはできません。ミスをしてしまったら、どうごまかすかより、その後にどう活かすかという方向に頭を働かせるのが、あるべき姿では」（足立氏）

しかし、より大きな問題かもしれないのは、松本氏が指摘するように、「失敗を認めない人と同じくらい、自分が失敗していることに気付いていない人がいる」ことだ。

「失敗に気が付かないと、それを改善することもできないですから。例えば、エンジニアには『こう作るべき』といった様式美に対するこだわりの強い人が少なくないですが、Cerevoの場合は『最終的に製品を売ってナンボ』という考え方を採っているため、売ることに向かっていないこだわりは、それがどんなに美しいコードだったとしても、正解だとは言えません」（松本氏）

そもそも間違いの定義が分かっていない人は、自分でも気付かないうちに失敗する可能性が高い。

正解を判断するには、自分の立ち位置を知る基準が必要

もちろん、コードは必要なだけ整理されたものであるべきだし、エンジニア的なこだわりが全て否定されるべきものというわけではない。「最終的にユーザーに買ってもらう製品であるという意識が抜け落ちたこだわりには意味がない」というのが松本氏の真意だ。

「もしこだわりを押し通したいのであれば、ビジネス的要件との両立を実現する必要があると思います。自分がその立場ならば、徹夜してでもやるかもしれない。そうやって、自分のこだわりと、チームのメンバー全員が納得いくものとの両立をしてモノを作り上げるべきです。逆に、そこまでやらないこだわりは、こだわりとしては認められません」（松本氏）

とはいえ、何が正解かはサービスのフェーズや自分たちの力量によっても、その都度変わるものでもあるだろう。適切な「正解」を設定するためには、「自分たちの立ち位置を知るための比較対象を多く持っておく必要がある」と大仲氏は言う。

「業界の水準と比較して自分たちの力量が十分に上ならば、売ることに注力するのが正解だろうし、逆に力量が足りていないのならば、目先の結果よりもよりスキルを上げることに勤しむ必要があるかもしれません」（大仲氏）

新卒プロパー社員で社内の”常識”しか知らないと、こうした判断の基になる客観的な視点は育ちにくい。ドリコムが社会人交換留学の制度を設けて外を知る機会を作っているのには、こうした基準を育む狙いがあるという。

とりあえず作って世に出し、反響から学べ

足立氏も、以前はエンジニアとしてのコードに対するこだわりが強く、他のエンジニアに認められたいという欲求が強かったという。しかし現在は、「製品として売ってナンボ」、「ユーザーに使ってもらってナンボ」の価値観に傾いたと話す。

価値観が変わったのは、「実際に自分でアプリを作って、世に出すようになってから」だという。

Android用IME『Simeji』はリリース当初、全くの個人の趣味として制作したものだったため、仕様書もコードレビューもなかった。案の定、前述したようにユーザーからさまざまな欠陥を指摘され、対応に追われることになった。

「自分がこだわりを持って作った機能がほとんど見向きもされない自己満足に終わる一方で、思いもよらない部分がユーザーから評価されることも少なくないということに気付かされました」（足立氏）

こうしたフィードバックを得て、適切な箇所にフォーカスした開発を行うことは、結果として失敗を減らしたり、開発スピードを上げたりすることにもつながる。世に問うことなしには、失敗する機会さえ得られないということだ。

村上氏が自作し、海外も含めて多くのメディアに取り上げられた国会議員への意見投稿サービス『Japan Changer』は、「某テレビ局から最初に取材を受けた時点では、完成していたのは入力フォームの部分だけで、実際にFAXを送信するシステムは未開発だった」という。

しかしそれでも世に出したことで、評判が評判を呼び、結果として自分でも予想しなかった大きな反響が得られた。エンジニアにとって、プロダクトなりサービスなりを「とりあえず世に出すことが重要」だと、村上氏は強調する。

失敗を回避するのは、仕組みと責任感の両輪

失敗を犯せば当然、チームのメンバーや取引先との関係悪化も懸念されるが、「とりあえず謝る」、「ただ謝る」のは良策とは言えないという。「ミスに対して取引先や上司が求めるのは、解決策や代替案。それなしにただ謝るのでは、何の意味もない」（足立氏）からだ。

逆に言えば、できるだけ早く直す、より良いものを作るというクリティカルなリカバーが可能なのがエンジニアだということもできる。

村上氏が若手時代、何度か大きな失敗を犯してしまった時に上司によく言われたのも、「まず直せ。謝罪はその後でいい」というひと言だったという。仮にミスを犯したとしても、より良い代替案を自ら作り出せば、結果的に信頼を回復することができる。これはエンジニアだからこそのリカバリー方法だ。

ゲームアプリ開発のリーダーシップを取る立場となった大仲氏は、今ではメンバーからミスを報告される側だ。事業を成功させる立場にあるリーダーは、メンバーのミスとどう向き合えばいいのだろうか。

「サービスをスケールさせるためには、ミスの可能性があっても仕事を任せ、チームとしての底上げを図らなければならない。最終的には責任者である自分が”最後の砦”となって作り直せるくらいの覚悟と、そのためのバッファを確保した上で仕事を振るようにしています」（大仲氏）

個人に失敗を恐れることなく伸び伸びと仕事をさせつつ、チームとして失敗しないためには、ミスをリカバーする仕組み作りが欠かせない。ただし、仕組みだけで全てが上手くいくわけでもないようだ。

松本氏は「やはり自分たちが作っているのはユーザーに使ってもらう製品であるという意識を持つことが、メンバー1人1人に責任感を生む。最近は、良いチームにはこの責任感と（失敗をリカバーする）仕組みの両方が必要なのではないかと思っています」と話していた。

取材・文／鈴木陸夫　撮影／佐藤健太（編集部）