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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メンバーの心理的安全性を確保できるマネージャーになりたい

広木　Good Moneygerも、今後エンジニアを増やしていくよね。自分がマネージャーになったら、心掛けたいことはある？

松下　「直接話す」コミュニケーションを重視したいですね。仕事を進めていく上で不安なことって毎日あると思うのですが、そうした不安はオープンにしづらいもの。体は不安を感じていてもうまく言葉出せないとか、感じていることと違うことを話している、というのは日々行われているんじゃないかな。

だから「大丈夫だよ、俺もそういう時期あったよ」というふうに話しかけて、何でも話せる雰囲気を作るのはすごく大事なのかなと。

広木　心理的安全性ね。ただ不快な思いをしない、させない、というのではなくて、自分が今一番不安なことを上司やチームメンバーに話せて、お互いに向き合い問題解決ができるという環境を作ることが大切です。

松下　うまくコミュニケーションをとって信頼関係が築けていたら、無駄なバッファも積まないし、自分たちがどのくらいのペースで開発ができるか正しく見積もれますよね。

僕がエンジニアリングに対して不安があったように、仕事とプライベートを問わず、世の中にはいろいろな不安を抱えているものの、その不安をうまく人に話せず抱え込んでしまう人が少なくありません。今取り組んでいるサービス、資産運用やお金の不安もそうした悩みのひとつだと思うんです。

2年間今の事業に携わって、開発に使えるマネジメントとお金の管理は、すごく近しいところがあるのかなと感じています。だから今取り組んでいるサービスを通じて、「お金に対する不安をなくす」世界の実現に貢献したいです。

広木　未来のことは分からない。でも分からないことをマネジメントしていくには、不安をできるだけ解消しないといけないからね。そういった意味では、老後のお金の不安もプロジェクトの不安も同じものだよね。

取材：仁田坂淳史（ZINE）／執筆：薄井千春（ZINE）／写真：林ユバ