2018-02-06

開発の“無理ゲー進行”はこう回避せよ！若手エンジニアが締め切りを健全に守るためのストラテジー

開発の“無理ゲー進行”はなぜ起きる？その原因を、さまざまな企業の技術組織顧問を務める広木大地さんがひも解きます。

エンジニアにとっての永遠のテーマ、「締め切りはどうしたら守れるか」。上司に言われるままにタイトなスケジュールを押し付けられた経験があるエンジニアは少なくないはずです。

「無理ゲー進行」を生み出す要因はいくつもあります。「完全版をリリースしなけばいけない」という固定観念や、期日だけを厳密に管理して現場へプレッシャーをかけるプロジェクト進行、無理なプロジェクト進行を経営課題と認識せず、現場の「頑張り」に甘えて放置している経営者（意志決定者）など。顧客（クライアント）や上司から押し付けられる「無理ゲー進行」に、工数見積もりに慣れていない若手エンジニアはどう対処していけば良いのだろうか――。

無理ゲー進行の原因をひも解いていくのは、かつて株式会社ミクシィにて最年少で執行役員に就任し、現在は株式会社レクターでさまざまな企業の技術組織顧問を務める広木大地さん。対談のお相手は、広木さんも技術顧問として参画しているGood Moneygerで、投資アドバイスツール「VESTA（ベスタ）」の開発・運用を手掛けるエンジニア・松下清隆さん。VESTAの開発当時に抱えていた悩みを振り返りながら、プロジェクト進行に潜むワナを探ります。

広木大地（ひろき・だいち／ @hiroki_daichi）（写真・右）: 株式会社レクター取締役・株式会社Good Moneyger 技術顧問。新卒第1期として株式会社ミクシィに入社。同社メディア統括部部長、開発部部長、サービス本部長執行役員などを歴任。2015年同社を退社。現在は技術組織顧問として複数社のCTO支援を行なっている。近著に『エンジニアリング組織論への招待』（技術評論社）※2018年2月22日発売

松下清隆（まつした・きよたか／ @kiyotaka86）（写真・左）: 株式会社Good Moneyger エンジニア。大手通信会社にて受託開発や社内システム開発に従事。興味があった金融業界で、自らの手でサービスを作りあげたいという思いから、当時、立ち上げ間もないFinTechベンチャーであるGood Moneygerの創業期メンバーとして参画。“投資初心者も安心して利用できる”をコンセプトに、ロボアドバイザーを活用しIFA（独立系ファイナンシャルアドバイザー）を半自動的に行う「VESTA」を開発、運用する。

若手エンジニア・松下さんが抱えていた不安

松下　2015年10月に2人目の社員としてジョインしてから、開発期間14カ月を経て2016年12月のサービスリリースまで、いろいろありました。今思うと、先が見えずにモヤモヤしてつらい時期でした。

モヤモヤ1. リリース日までの見通しが立てられない

松下　特につらかったのは一番初めのリリース。1年前の2016年12月にはリリース予定日が確定していた（と思い込んでしまっていた）のに、実装を間に合わせる見通しが立てられなくて。

広木　当時、社長からも「（松下が）なんかつらそうなんです」と相談を受けていました。でも、やるべきタスクなどは整理できてたんですよね。

松下　リリース時に必要な機能も分かっていたので、タスクの優先度順に並べた「やることリスト」は準備していました。でも、期日までに間に合わせるメドが立たなかった。

広木　そのとき僕が提案したのが、1日の稼働時間を8時間、コーディングに割ける時間を6時間と仮定して、タスクリストから工期日数を計算してもらうこと。“見える化”してみると実はリリース予定日まではだいぶ余裕があって、実装が期日までに間に合わないという状況でもないことが分かった。よくよく聞いてみると、理由は別のところにあったんですよね。

松下　ネックは「他社とのつなぎ込み部分」だったんです。情報を取得するために、自分たちで制作する箇所とは別に、他社の仕様に合わせて開発する部分があって。秘匿性が高い情報なので外部からアクセスできず、システムに触れるのは週1回の打ち合わせ数時間のみ。平日週5日稼働しても手が付けられる日が限られている上に、マニュアルを読み解きながら進めなければいけない。「手元で開発できない」不安が大きくて、どうすればいいねんと思っていました。

モヤモヤ2. 「どう納期を守るか？」SIerだったときとの違い

広木　たしかにリリースまでの流れが見通せないのはつらいけど、松下くんは特にその悩みが大きい気がしました。

松下　それは、前職での仕事のスタンスに起因するかもしれません。前職は新卒で入社したSIerで、業務課題は「納期をいかに守るか」でした。仕様をきっちり決めて、納期までに完璧なシステムを作らないといけなかった。だから今の会社に来たばかりのころは、「社長が決めた仕様を全力で作る。なるはやで常に走り続けないといけない」ともう必死に働きました。

広木　あのころは、見えない何かと戦っていたよね。明るい性格だったはずなのに、口数が減りストレスを感じていそうな表情をしている、という話が社内で出ていて。もともと松下くんは体育会系で「つらいことは当たり前だし、修行になる」くらいの考え方だったのに。社長からも「（松下が）ソワソワしている」と相談されていました。

松下　当時を思い返してみると、見えない何かと戦っている、という意識すらなかった。広木さんからのアドバイスを聞いて初めて、完璧に作ってリリースしなければいけない強迫観念があったことに気付きました。

広木　業務上の悩みだけじゃなくて、今までのキャリアからベンチャーに行って、開発スタンスが変わったのも不安要素のひとつだったのかもね。

松下　そうかもしれません。SIerは仕様や納期が決まっていて、期限までに納品できればお金がもらえるというビジネス。一方、自社事業では仕様や納期を自分たちで決めることが多いので、「どう納期を守るか？」だけを考えると、バッファを多く積むようになってしまいます。当時「なるはやで対応する」タスクは120個を超えていました。

広木　「初めて取り組むからたくさん時間がかかりそうだ」と思い込んじゃって、タスクひとつひとつに必要以上のバッファを積んじゃっていたよね。

松下　新しいことにチャレンジし続けているので、ワクワクするのと同時に、日々不安と向き合っていく必要がありました。

不安だと思っているタスクから着手すればいい

広木　今回の不安の原因は2つ。見積もる時のタスクの粒度が大きすぎたことと、公開までに完璧なプロダクトを作らないといけないという使命感でした。

松下くんが「時間がかかる」と考えていたタスクを改めて見直したところ、僕には、彼がやっても見積もっているような時間が必要なタスクに見えなかった。やったことがないという不確定要素によって安全のためのバッファが増えて、結果、見積もり工数が不安に比例して大きくなっていた。

いつ終わるか分からない、どうやったらいいか分からないタスクは不安になるし「長く時間がかかるのでは」と思ってしまう。そういう場合は、タスクを見積もる前に「分かる／分からない」の軸で分けてリストアップし、最も気掛かりな部分から手を付けていけばいい。時間的制約や場所的制約などを含めて不安に感じる要因を洗い出していって、どうすれば課題をクリアし、分かりやすいタスクに分解できるかを考えていくのです。

見通しが立たないままずっと心に引っ掛かっているから不安に思うわけで、一番大きな不安から手を付ければストレスもおのずと減っていきます。

でも、これを自分一人でやると難しい。夏休みの宿題に例えてみましょう。ゴールが見えている学習ドリルは取りかかりやすい。でも自由研究は何をしたら進むか分からないという不確実な要素が多いから、どうしても後回しにしてしまう。結果、8月末まで手付かずのままだった……という人も、少なくないと思います。

松下　この場合は自由研究をとりあえず始めてみて、その中で「すでに知っていることと、まだ知らないこと」に分類していけばいいんですね。

広木　松下くんの一番大きな不安は「他社とのつなぎ込み部分の開発」だったから、社外に出る回数やタイミングといった制約がある中、作業時間を確保する方法がないか一緒に考えました。細かく見ていくと、詳細が分からないのはバックエンドに関する一部分だけで、社内で作れる部分も多くあるということに気付いた。だから「ダミーサーバを立てて、分からない部分だけ他社への往訪時に確認する」という結論になりました。

松下　タスクの粒度を1時間、2時間ぐらいでできるまで小さくして、ゴールが見えるところまでくれば、後はやるだけです。自分では気付きませんでしたが1、2時間まで粒度を小さくすることで心理的抵抗が減りました！

広木　その後はダミーの環境を作るタスクと環境を立ち上げるタスクを立てて、最初の往訪時にダミー環境を作れるように準備をしました。この環境を使えば、作業時間も十分に確保できます。

広木　ダミー環境作成以外にも、全部のリストの中から不安そうなタスクをリストアップしていきました。次に「今不安に思っている部分や、分からない箇所をある程度分かる状況にする」というタスクをリストに入れ、順番に対処してもらう。分からない部分をクリアにして仕事を進めていくと、「終わりが見えない」という不安は減ったんじゃないかな。

締め切りを守ることが本当の目的じゃない

広木　そもそも「締め切りを守ること」は本当の目的ではありません。VESTAのリリース時も、きちんと登録ができる、情報が閲覧できるなど、経営者も巻き込んだ上で最初の顧客価値がちゃんと提供できていたら問題はないと助言しました。

松下　VESTAは、IFA（金融商品仲介業）の半自動化というビジネスの仕組み上、100ユーザーぐらいまでは裏側の仕組みを自動化しなくても人力の作業で対応できると分かっていました。しかもユーザーが100人集まって、証券口座の開設をし、投資のアドバイスを見て取引を始めるまでにも時間があります。

広木　もし予想外なことが起きて手作業での運用になったとしても、システム上にToDoリストを作って、複数人で順番に対応できる体制を整えてもらいました。

松下　どうしても完璧なものを作らないといけない、と思っていたので「完全な機能をリリース日までに全て実装できなくても問題ない」と分かったときは安心しました。リリースまでに必要な機能を優先させて、後回しできるものは後回しにする、というのはSIerでの開発と大きく違ったところですね。

顧客からのフィードバックを早期にもらう

松下　とはいえ、かつての僕のように、顧客（クライアント）から提示された納期を必ず守らなければいけない、という環境で働くエンジニアの方も少なくないと思います。顧客と開発会社がスクラムを組めれば、顧客が欲しいものと別のものが完成してしまう、ということは防げるでしょうが、実際にできるかどうかは分からないな……。それ以外の方法はあるんですかね、先生。

広木　最初の段階で顧客がフィードバックできる形で渡すことが重要だね。どんな仕事でも、最終的には決裁者が確認して了承したら前に進む。だから顧客が「いい」と判断できるものを提示できていないと、判断がつかない。フィードバックをもらうフェーズが遅れたり、相手が判断しづらい形で確認を取ろうとしたりしていると、後から仕様が覆ってしまいがちです。この場合の顧客、つまりお客さんが求めているものを知っているはずの人は経営者なので、彼に見てもらうのが一番最初のフィードバックになる。

だからいきなりデータベース設計書や画面仕様書を見せるより、プロトタイプやモックアップなど、アタリを付けた「完成形が見える」形で渡す。そうすれば顧客も意見を言いやすく、結果的にお互いの認識の齟齬（そご）が減る。「この機能ができたので触ってみてください」と定期的にコミュニケーションがとれたら、ささいな要望も拾えます。全部出来上がってからのフィードバックは手戻りになってしまうし、ストレスもかかるしね。

広木　一方、「誰かがカチッと仕様を決めて、それを作り切ったら完了」という考え方でいると、顧客のイメージと違うものが完成してしまう、ということが起こる。予想と違うものを納品された発注者（顧客）も、作り直す制作者（開発会社）も幸せになりません。ですから、まずは仕様変更の不確実性を減らすことが大切。見えない部分のクオリティは後からでも上げていけます。

スクラムで開発するとか、ウォーターフォールで開発するとかみたいに、決まったやり方にこだわる必要はあまりない。でも、作ったものを早めにフィードバックがもらえる単位にして、お客さん（あるいはそのニーズを知っている人）に見せて、フィードバックしてもらう機会をちゃんと設けることにはもっと注力すべき。それはSIerでも、自社サービスの会社でも同じです。

正解は分からない。だからやってみてフィードバックをもらう

広木　フィードバックを避けたい、と思ってしまうのは学校教育も一因かも知れません。学校のテストでは、決まった時間を制限いっぱい使って100点の答案を作ることが評価されます。

松下　間違えばバツがつきますし、学力テストの最中に先生に質問をすると「何言っているの？」と返されてしまいますもんね。

広木　対して、仕事では分からない部分を聞いて確認する方がうまくいく。フィードバックを受けるときに怒られたり、嫌な体験をしたりということもあるでしょうが、フィードバックを避けていくほど、発注者の認識と離れていってさらに嫌な思いをする。繰り返していくうちに「できる限りフィードバックを避けよう」と考えてしまうことは、業界や業種を問わずあると思います。

学力テストには正解があるけど、仕事上での正解を知っている人はいません。だからこそ早いうちに認識をすり合わせて、期待値の差を減らしていく。「もうちょっとこういう形にできればいいよね」という話し合いをすればいいのです。まずは何かしら行動しないと、顧客の気持ちは分からないもの。分からないなら聞いてみるしかないんです。

エンジニアは土台から作りたいが、顧客はウワモノを見たい

松下　相手に合った粒度で見せて、ズレたらまた作り直す、という感じでしょうか。「できた！」と思ったら持って行って、フィードバックを受ければいいのかな。

広木　その「できた！」と考える部分がズレている可能性もあるからね。エンジニアやデザイナーなどの専門職は、土台から順番に組み上げていきがち。「土台がしっかりしていないと、ウワモノは作れないじゃん」という感覚があるし、僕自身もコードを書くときは土台から書いた方が楽な感じはある。

でも、発注者やユーザーは、成果物を上から見る。上から見るということは、土台よりウワモノの方が変わりやすい。ウワモノが変わりやすいんだから、先にこちらを固めないと土台も固まらない。

ということは、プロダクトを土台から一段ずつ積み上げて、積み上げきった後に提出するんじゃなくて、機能をひとつずつ増やしていきながら、顧客に確認を取っていった方がいい。ユーザーストーリーという単位で縦に切るんです。

広木　作っていくうちに、共通の土台が使えそうと思うなら後からでも調節できます。ウワモノを見せないと顧客が判断できない以上、下から積み上げていっても、顧客の求めるものがきっちり作れるとは限りません。しかし完成形のイメージが一致すれば、後からの仕様変更もそれほど多くないし、作り直すコストも少ない。

松下　早めに完成形を共有した後に、整えていくのがいいんですね。

広木　ブレやすい部分を決めてから進めると、土台部分も自然と固まるからね。松下くんに話したかもしれないけど、「何かライブラリを作って、そのライブラリを使うコードを後から書く」より、使うコードを書いてから架空のライブラリを呼び出し、想定通りに振る舞うライブラリを後から書く方がいい。TDD（テスト駆動開発）は、こういう考え方の矯正器具でもあるんです。

TDD（テスト駆動開発）
アジャイル開発手法で用いられるプログラム開発手法のひとつ。はじめにテストコードを書き、そのテストに通る最小単位のソースコードを実装させたのち、コードをブラッシュアップしていく。

「何を作るか？」の工程も含めてスケジュールマネジメントする必要がある

広木　時間がなくなるもう一つの原因が、スケジュールマネジメントの開始時期が遅いこと。これはエンジニアだけの問題ではなく、経営者も含めて意識しないといけない。無理ゲー案件の最大の原因は、無理な計画でものづくりしないと二進も三進もいかない状況に追い込まれるまで、経営問題を放置することですから。

「顧客の要求を整理し、要件仕様を固めるまでに時間がかかり、実際に作る段階で日限が迫っている」というケースが結構あります。全行程の半分以上を企画フェーズで使ってしまうと実装にかけられる時間が短くなり、現場は「このスケジュールで進めるの？」と苦しんでしまう。

本来は、要件決めから納品までの全行程をプロジェクトマネジメントしないといけない。「要求仕様があいまいだから、決めるまでにふんだんに時間を使っていい」なんて理由はありません。時間は経営の中で最も重要な資源です。

そういう場合僕は、あいまいな要求仕様の段階でエンジニアが大雑把に見積もって、期間の幅で見積もろうというアドバイスをしています。見積もるといっても、前例がなければ分からないことが多く、いつ終わるかが明確には分からない。だから期日ではなく「いつから開始していつごろまでに終わる」という納期の幅で表現する。詳細化していくにつれて工期の幅が短くなっていけば、プロジェクトが順調に進んでいると分かります。

納期に対してプレッシャーをかけるのはマネジメントではない

広木　対して期日ベースで管理していくと、顧客も期日までにできると思い込んでしまうし、エンジニアの考える見積もりにバッファがどれくらい積まれているかも分からない。

そもそも企画フェーズで実施したことや、かかった工数はあいまいなのに、プロジェクトの詳細が見えてくる実装フェーズは細かく締め切りを切って管理していく、というのはおかしい。マネジメントはプロジェクト全体を見て、うまく進んでいるかどうかを把握しなければいけません。

松下　プロジェクトの初期段階で「期日を過ぎてしまう」と気付けて、適切に対処するのが重要なんですね。

広木　例えば「今から来年のクリスマスに向けて何かやりましょう」となったとき、クリスマスを過ぎたら価値がないものになってしまうなら、クリスマスを死守しなきゃいけないじゃない？でも6月に「クリスマスに間に合わないぞ」と感じたら、残りの半年をどう使うか意志決定できる。これが12月の頭になって間に合わないから判断しろ、と言われても選択肢がないから「なんとか頑張ってくれ、残業してくれ」と言うしかない。そうしたら嫌な上司、嫌な意思決定者になっちゃうわけです。

納期に対してプレッシャーをかけるのはマネジメントではない。マネジメントの正しい姿は、まずはプロジェクトの状態を見えるようにすることです。プロジェクトの全貌が見えていれば「今後どうしようか」という話し合いができ、プレッシャーをかける必要がありません。

松下　自分ではプレッシャーを受けていた実感はないですが「遅れているなら、もっと働けばいい」とは思っていました。ギリギリまでいけるなと（笑）

広木　メンバーに必要以上にプレッシャーをかけすぎると、プロジェクトの全貌が見えなくなってしまう。このことはプリンシパル＝エージェント理論で説明できます。

プリンシパル=エージェント理論
プリンシパル（依頼人）の利益のために働くエージェント（代理人）が、プリンシパルの利益に反してエージェント自身の利益を優先した行動を取ってしまうこと。仕事を依頼する人と、それを請け負う人という関係性であるものの、依頼人は、自分ができないことを代理人に依頼するので、その依頼が正しいかどうか分からない。よって依頼主は受託側から出された見積もりに関してノーと言えない。同様に、上司は部下がバッファを積んだ見積もりやスケジュールが本当に正しいかどうか判断できない。

広木　特にSIerでは納期までに完成しないと、損害賠償を求められることもある。だから絶対に完成するラインしか言えなくなってしまうのです。ユーザー企業の社内やチーム内でこの「分からない」状況が発生すると、無駄が生まれて会社が損をするだけ。「期限までに終わらなかったらすごく怒られる」と警戒すると、次からもう少しバッファを積んで、安全なラインを上司に伝えよう、いっぱいバッファを積もうと学習してしまいます。

松下　今考えると、不安な気持ちや「締め切りを守らなければいけない」プレッシャーから、必要以上にバッファを積んでしまって、プロジェクト全体が見えづらくなっていたかも知れません。

広木　松下くんはストレス耐性があるから、頑張る意識が強いんじゃない？立ち上げたばかりのベンチャー企業で初期にジョインする人には、努力目標を予測にしちゃう癖がありがち。こうした人たちは「いつまでに終わらせたいからとにかく頑張る！」と、逆にバッファを薄くしてしまう。

努力目標で頑張ろうとしているのは悪いことじゃないけど、頑張りを前提に全てのビジネスを動かしたら、達成されなかったときにみんな困ってしまう。経営者やビジネスサイドは「納期に遅れが出たら困る」と考えるので、エンジニアを責めてしまいがちです。一度同様の経験をしたエンジニアは、責められるのを避けるためにバッファを積み、絶対リリースできる見積もりを提示します。そして、バッファが多く積まれたスケジュールを見た経営者は、開発のスピードが落ちたように感じてしまう。こうした関係性ではプロジェクトの状況が見えづらい。

ときどき「うちのエンジニアは頑張っているようだけど、納期に間に合わせられない。質が低いのかな」という相談を受けます。僕はこれもマネジメントが間違っているんじゃないのかな、と思っていて。マネージャーの役割は、プロジェクトの中の「分からない部分」を見える化して、どうしたらいいかメンバーと一緒に考えていくこと。そのためには、プロジェクトの状況を把握することは不可欠です。