More than 5 years have passed since last update.

エイチームブライズ/エイチームコネクト/エイチーム引越し侍Advent Calendar 2018

@sho0211in

株式会社エイチームライフデザイン

めちゃくちゃ失敗プロジェクトを経験してきたアラフォーエンジニアが考える、プロジェクトを成功させるために必要なこと

Last updated at 2018-12-13Posted at 2018-12-13

この記事はエイチームブライズ/エイチームコネクト/エイチーム引越し侍 Advent Calendar 2018　14日目の記事です。本日はエイチームブライズの（自称）凄腕エンジニア @sho0211 が記事を書きます。

はじめに

僕は色々な場面でインセプションデッキを作ろう、ユーザーストーリーを作ろうと声をかけているけども、あまりうまくいったことがない。
もちろん一緒に動いてくれるメンバーはそれらを受け入れて、一緒に作り上げようとしてくれるが、それでもうまくいくわけではない。
そんなときに、ものすごく頼りになる3年目のエンジニア@GakuYasuiから言われた一言が突き刺さる。
「@sho0211がこの歳になるまでの（さほど自慢できるものでもない）経験を背景にしているのだから、それを伝えることから始めましょう」

確かに、ツールだけを押しつけてうまくいくわけがない。
自分が逆の立場であれば反発するだろう。
だから、今回は失敗談とともに何を必要としているのか、伝えられるものを伝えていきたい。

なぜ失敗談？

と始める前に、なぜ失敗談なのか。
世の中には成功分析とか、成功に学ぶ形の自己啓発本があふれているのに、失敗を語るのはなぜなのか。
言語化できるものとできないものが僕の中には渦巻いているが、端的に言えばこんなところだろう。

経験の中で失敗事例の方が遙かに多い
成功要因をスキルとして再現できるのか疑問
- 成功要因として語られるもののうち僕が経験的に納得できるものは、スキルではなく習熟によるもの
- 心理的安全性とかOKRとか¹
自己肥大せずに的確な成功分析をできるほどの素養を持っていない
- 失敗の分析はわかりやすい
- 実際には複数要因あって1つしか見つからないときでも無駄にはならない

プロジェクトの失敗とは何か

プロジェクトの失敗について語る前に、そもそも何をもって失敗とするかの共通認識が必要だろう。
大まかにこのような分類を用意してみた。
これらのいずれかに該当すれば、プロジェクトは失敗したと見なす。

その１：感情的な失敗

プロジェクトに参加したメンバーが失敗と感じたプロジェクト。
成功要件を定めずに走り続け、どこかで終焉を迎えたプロジェクトでは、この失敗のみが発生する。
さすがに成功要件を決めないとかそんなんないやろー、と思った方は運が良い。

失敗の指標

プロジェクトの途中・終了時にメンバーが「プロジェクトはうまくいっている（終了した）」と感じなかったときに発覚する。

その２：予定を逸脱したプロジェクト

プロジェクトの完了要件を定めたものの、そのプロジェクト完了要件を満たせなかったもの。
多くの失敗プロジェクトはここに属していると思われる。

失敗の指標

プロジェクトの途中・終了時に何らかの数値として計測可能。
例えば、コスト、納期などである。

その３：見込んだ成果を得られなかったプロジェクト

予定していた工数で、予定した期間内に、予定した機能をローンチしたものの、当初狙った効果を上げられなかったプロジェクト。
受託開発と割り切っていれば成功とも言えるが、本当にそうだろうか。
プロジェクトの完了後に効果が上がらなければ、継続した受注が難しくなるかもしれない。

失敗の指標

プロジェクトの終了後、運用を続ける中で何らかの指標を計測することで発覚する。
例えば、PV推移であったり、工数削減効果などである。

分類の見方

これらは排他的なものではないので、全てが重複することもある。
また、従属的な要素も加味していない。
その１：感情的な失敗などは、他の項目で失敗すれば往々にしてメンバーとしても失敗と感じるだろう。

プロジェクト失敗のケーススタディ

様々な失敗を繰り返してきた²それぞれのケースを挙げても冗長になるので、僕なりに失敗要因にまとめて紹介していこうと思う。
また、これらもMECEを意識しているわけではないので、お互いに重複している部分もあるのはご了承いただきたい。

その１：目的を見失うケース

顕在化する症状

設計フェーズがいつまでも終わらない
決定が覆されて手戻りが発生する
今日も終電・・・
終電で帰れればましだろ・・・

要因：そのプロジェクトで何を解決したいのかが明確でない

機能ベースで細かく仕様を詰めたとしても、課題とそれらの機能が有機的にリンクできないため、何度も手戻りが発生する。
なんとなくすごそうなシステムを提案したものの、そもそもそれが顧客の課題に正しくマッチしているかを確認せずに進んでしまうことでも発生しうる。

処方箋：課題と解決の「方向性」を常に確認する

解決方法はプロジェクト途中で変わることもあると認識した上で、解決したいものはなんなのか、それを解決することで誰が嬉しいのか、その人を嬉しくするために他の人を犠牲にしていないかに注目し続けること。

その２：予定した期間内に終わらない

顕在化する症状

ガントチャート通りに進んでいない
WBSにない作業が発生している
バッファぁぁぁぁ
今日も終電・・・
終電で帰れればましだろ・・・

要因：ソフトウェア開発をハードに計画して実行している

ソフトウェアの特徴はその可塑性と同時に不透明性である。
一般的な利用者にとって、ソフトウェアの中身はわからないし、成果物もお互いに勝手なイメージを持って話が進んでしまう。
ハードの設計図に相当してほしい設計書は、お互いに仕様が明確になって納得できるレベルまで作り込むのであれば、もはや完成品を作った方が早いレベルである³。
そして、不完全な合意の中で進み、古き良きKKD法によって見積もられた工数とは実装難度もかけ離れてしまう。
ハードウェアは調達サイクルがわかっており、それらを組み付けることにかかる工数が大きく異なることも少ない⁴。
ソフトウェアにハードウェア流の計画を持ち込み、その通りに運用することで、容易に破綻を迎えることができる。

処方箋：プロジェクトの柔軟性を作る

残念ながらソフトウェア開発が計画通りに進むことは稀である。
なぜなら、今までできていないことをする為にソフトウェアを開発するのであり、全てが新規事業であるからだ⁵。
新規事業が全て計画通りに行くのであれば、今すぐその職を辞して、会社を興すことをおすすめする。
では、計画を外れるときにどうすべきなのか。間に合わせるために人を投入するのか⁶、計画を変えるのか、別の解決方法を示すのか。
どのようなやり方でも良いのだが、計画を絶対的に遵守すべしという風潮を払拭することがソフトウェア開発では重要になる。
とはいえ、僕もSIerにいた経験から、客先との関係性で難しいことはよくわかるし、明確な答えを持っているわけではない。

その３：プロジェクトチームの機能不全

顕在化する症状

与えられた役割を全うしないメンバーがいる
作られた機能が当初の予定と全く異なる
あいつ、適当なことばかり言いやがって
俺の言うこと聞いておけばいいんだよ

要因：チームとしてのプロジェクトへのコミットメント形成不足

2018年末現在、自動で要求通りのソフトウェアを作り出すAIは生まれていない。
ソフトウェア開発のプロジェクトは是非がなくとも人を動かさなければならない。
ハードウェア製品では工作機械などで、特定の挙動を人間以上に精確に行うことができているが、開発でもそのように人を動かそうとする戦略は早晩失敗するだろう。

処方箋：実りのあるキックオフと定期ミーティング

アメリカではテメー（自分）の感情なんざどうでもいいからプロジェクトは成功させてやると考えるエンジニアが尊ばれるし、それを文化として持っているようだ。
しかし、それは自分が何をすべきだと考えているか発信できるだけの個人主義的な背景を持っているからこそと言える。
日本では、帰属意識を高めるためのキックオフが役に立ちそうだ。
自分の役割がなんなのか、そのプロジェクトの価値はなんなのか、どこに寄与できるのかを、自ら感じられるように導くことが重要だろう。
そして、その熱も冷めるので、定期的に自分たちがその時点でどこに立っているのかを常に確認することだ。

その４：使われなかったプロダクト

顕在化する症状

要件通りリリースできた！
どやぁ
nヶ月後「あれ・・・全然使われてない」
n年後「もう頼まないよ」

要因：ニーズの把握不足または解決方法の失敗

要件定義もした。設計レビューもした。受入テストでも該当機能が検収された。
しかしそれは作る側の論理である。
その２でも触れたように、システムを使う側は、もしかしたらシステムのユースケース自体を正しく理解しているとは限らない。
机上で繰り広げられた機能定義で本当に解決できるのかを本当に理解できているだろうか。

処方箋：段階的なテスト運用と継続的な改修

プロジェクトの失敗としてあげているが、このケースはまだましかもしれない。
フォローアップが可能だからだ。
しかし、プロジェクトの進行としても他にもやりようがあったかもしれない。
段階的にソフトウェアを使ってもらい、反応を収集し改善し続けるサイクルを回すことだ。
最終的な成果物が見えずに齟齬が生まれるのであれば、成果物を小出しにするのだ。

その５：終了すればいい

顕在化する症状

とりあえず作ったけど
そもそもなんでやるのかよくわかってない
その後もよくわからんけど
まあ終わったし

要因：不明なゴールと課題

社内プロジェクトに起こりがちな印象。
ある時トップダウンで「働き方改革を実施する！」
何を課題として戦っているのか誰も知らない。
とりあえずプロジェクトメンバーに入れられたから何か形を作ろうか。

処方箋：成果の測り方をあらかじめ決めておく

課題が曖昧だからこそ、成果物が本当に正しかったのかわからなくなる。
かと言って、課題を明確にしようという号令だけでは明確にならない（経験上）。
課題を明確にするには、成果の計測方法をあらかじめ決めておくことが肝心だ。
計測できるようになればその指標に対してのアプローチの仕方が明確になる。
プロジェクトを終わらすことが全てではない。

経験をもとにした解決策の抽象化

書ききれない失敗もまだあるし、類型化に失敗しているものもある。
しかしながらこれらを想起した経験から得た、僕なりの学びはこんなところだ。

目的は明確にしよう

これはプロジェクトに参加しているすべてのメンバー、ステークホルダーにとって明確であることを意味している。
そして、プロジェクトの成否を決めるのは、目的を達成したかどうか、である。
目的が明確でなければ、プロジェクトはいつまでも迷走を続けると断言しよう。
しかし、目的をすべてのメンバーが正しく理解し、その成果に対してコミットメントを持っていることで、プロジェクト進行の原動力となる。

計画はあくまで計画（あくまでソフトウェアの話）

段取り八分とはいうけれど、僕にとってそれは製造業の論理であってソフトウェアの話ではない。
少なくともWeb業界ではそんなことを言っていたら遅れてしまう。
プロジェクトを遂行している間にも刻一刻と周囲の状況は変わっていて、段取りをしている間に変化した市場に更に対応するための段取りをしていたら、プロダクトはいつまでたっても絵に描いた餅になってしまう。

僕の考える計画は

いつまでに
どのようなニーズを満たすのか
そのためにどれくらいのリソースを投入できるのか

くらいでいいのではないだろうかと思っている。
（ビジネスサイドから怒られるやつ）

譲れないものを決める

きっと頑張ってたてた計画はうまくいかないので、そのときにどう動けるのかを最初から話し合うべきだ。
いやいや、そんな保険をかけずに、うまくいかせるようにするのがプロジェクトマネジメントだろ、プロだろ、という意見もあるだろう。
そうではない。熊は予測できないから熊なのだ。
リスクははじめに話し合い、実際に訪れたそのときに慌てないことが重要だ。

プロジェクトの進度をわかりやすく測る

リスクを考慮できたのであれば、今度はプロジェクトの方向転換が必要なタイミングをいち早く知らなければならない。
プロジェクトが正しく進んでいるのか、最初に立てた計画はどうなりそうなのか、きちんと報告できるだろうか。
「大体30％くらい進んでいます」というのは根拠があるだろうか。
突然、思いもよらなかったタスクが生まれたときには正しくその影響を測れるだろうか。

方向転換は論理的であること

自分が関わってきたものが方向転換することになると、メンバーへのストレスはないだろうか。
築き上げたコミットメントは崩れないだろうか。
まず第一に、キックオフで定めた目的を覆すことはしてはならない。
仮に目的すら覆すのであれば、キックオフからやり直すべきである。

失敗を推奨する

プロジェクトを進めながら、小さな失敗を繰り返すはずである。
期待していた機能が使えなかったため、別の手法を試さなければならない。
見込んでいた市場で新たな法規制が入りそうだ。
便利機能を作り込んだらレスポンスが悪くなった。
それらを咎めるのではなく、称えることが望ましい。
なぜならば、プロジェクトの不確実性を減らすことに貢献しているからだ⁷。

自分自身を含めて人間は信用しない

どのように素晴らしいプロジェクトマネジメント理論も、それを実施するのが人間であれば、クズにも宝石にもなる。
どれだけ素晴らしいエンジニアであっても、事故にあってしまえばプロジェクトから離脱せざるを得ない。
どれだけ理解のある経営者であっても、運転資金が足りなくなれば苦渋の決断を下すことがある。
ミスを侵さない人間はない。
バグを産んだり、誤った判断を下すこともあるだろう。
それらに対して常に冷静に対処していこう。

ツールの話

さて、ようやくツールの話に入れそうだ。
冒頭のように僕はこれらの経験・考え方を踏まえて、いくつかのツールを推奨していきたい。
今のところ、声高に叫べていないため、記事に書くのが少しばかり気後れしている⁸。

なぜツールなのか

こういったことに気をつけてプロジェクトを進めよう、では信用ならないから。
いやー、攻撃的な発言だなぁ。
人は気をつけていても抜け漏れを防げないし、チェックリストでの運用も品質面までは保証しきれない。
例えば

計画の不確実性を考慮したか

という項目があって、どのように考慮したのかは千差万別になってしまう。
であれば、必要なことを網羅しているテンプレートを用意しようじゃないかという発想である。

インセプションデッキ

僕が今まで出会ったテンプレートの中で、プロジェクトのキックオフに必要十分な内容を最も簡潔に網羅しているため推奨。
この必要十分な内容というのは、前章で上げた経験をもとにした解決策のことである。
つまり、インセプションデッキは僕にとって最適と考えられるテンプレートであるが、果たしてその共通理解を得られるか、ということが懸念である。
そして、インセプションデッキは、一人で作っても効果は薄い。
最初は一人で作るかもしれないが、必ずプロジェクトメンバーが全員でその内容にコミットできるまで叩けき上げるようにしよう。
それこそが、キックオフミーティングである。
一方的に、こんなプロジェクトを始める、それぞれの役割で協力せよ、と要請するのはキックオフではない。
エレベーターピッチを作り、パッケージを作るところから一緒に作り上げて、プロジェクトの意義を理解し、また認識の齟齬を最初から減らしていくことが重要だと考えている。

ユーザーストーリー

ユーザーストーリーの重要なことは、「機能」ではないこと。
解決すべき小さな課題を浮き彫りにするのだ。
それに対しての機能は何通りあっても良い。最も筋の良いもの⁹を選択すれば良い。
機能先行でシステムを考えると、想像以上の解決策は生まれにくくなる。
これはプロダクトで勝負している事業会社にとって、成長の頭打ちを意味してしまう。
必ず、課題を先に出すこと。何を解決したいのか。機能を提案するのではない。

ストーリーポイント

プロジェクトの完了日（N日）を算出するには、ストーリーポイントをまず検討したい。

ストーリーポイントに対してFPなどもあるが、FPは手間の割に精度が高くならない印象を持っている。
誰がやっても同じようなポイントが出てくるのはいい面ではあり、見積もりの説明をするには一つの手段であるだろう。
しかし、ガッチリ見積もりを立てて計画通りに遂行するプロジェクトにはつらみがある、という今の僕の発言の立場からすれば、見積もりの説明に時間をさくくらいであれば、プロダクトを作り続けようと鼓舞することが大事だと考えているのである。
また、誰がやっても同じポイントが出てくるということは、チームの特性を正しく反映できないことでもある。
バックエンドに強いメンバーが多いのか、最新のフロントを追いかけているメンバーが多いのか、これからプロダクトの特性に合わせてチームを作るのかなど。

ストーリーポイントは当然、チームメンバーでプランニングポーカーをして決めるべきである。
場合によってはプロジェクト外からもポーカーのメンバーを連れてきていいだろう。
ともかく人ひとりの判断は誤ることを正しく理解しよう。

バーンダウンチャート

ストーリーポイントで見積もれたら、次はその進捗を測る必要がある。

正直に言えば、僕はガントチャートが嫌いだ。
建築を出自とするガントチャートをそのまま転用していることが気に入らない。
設計図上で強度計算され、部材の仕様まで明確に決まっている建築業と、ソフトウェアの良くも悪くも「いい加減」なプロジェクトを同一のツールで管理しようというのがナンセンスだというのが第一の主張。
第二の主張として、ガントチャートはこれまでの運用背景から「遅れてしまってはだめなもの」として扱われがちであること。
そして最大の理由が、新しいタスクが生まれたときにどう管理すべきか、依存関係を正しく把握できるか、その上でクリティカルパスを管理しきれるか、そういった柔軟性に対して非常に「使いづらい」ツールだからである。
数千人月というような巨大プロジェクトに対しては、正しくクリティカルパスを貼り、サブプロジェクトを定義し、全体の進捗を見ることに役に立つかもしれないが、僕自身の経験としてはないため、明言を避けたい。

その代わりに提案しているのがバーンダウンチャートである。
バーンダウンチャートなら、誤解を恐れずに言えばとても簡単に作れて、見た目がわかりやすい。
進捗をもとにチームの実力値がベロシティとして浮き彫りになる。
そしてそのベロシティの良し悪しをもとに、改善すべきこと、計画を変更すべきことがわかる。
新しいタスクが生まれたとき、手戻りが発生したときにも、消火具合は一目瞭然である。

なお、バーンダウンチャートを反転したようなEVMもあるが、EVMはやはり成果物を固定した思想のため「僕の」理想形からは外れている。

CI/CD

バーンダウンチャートまでは、人の申告によるものである。
チームの心理的安全性が確保されていなければ、虚偽申告が起こりうる。
プロダクトマネージャーや利用者に近いメンバーが、常に最新の開発状況を見ることができることは、プロジェクトの正確な進捗を把握するために欠かせないと思っている。
その時、人の手でデプロイしていると、バギーな状態でデプロイしたくないエンジニア心理が反映されてしまう。
しかし理想からすれば、バグを含んでいること、つまり修正に対してもまだ工数がかかることを明確にしなければならない。
そのためのCI/CDを確立しておくことが重要だ。

OKR

プロジェクトに対して全力でコミットするためにOKRが役に立つのではないだろうか。
あくまでGoogleの運用をもとにするが、失敗を前提とした目標を立てることに意義があると考えている。
失敗に対しての恐怖心が薄くなり、より積極的な活動が期待できる。
また、OKRを全社員に対してオープンにしておくことで、スポット業務に対してのエクスキューズが公正に行われるし、他スタッフも各人のOKRを意識した関わり方が可能になる。

まとめ

自分が今まで失敗してきた経験をもとに、プロジェクトを成功させるために何ができるのかを考えてみた。
そして、プロジェクトを遂行する人たちに負担を要請するのではなく、ツールでアシストすることが重要だというメッセージを乗せたつもりである。
しかし忘れてはならないのは、これらは僕個人の経験をもとにして、実践も未熟な中で主張していることである。

規模が急速に大きくなっている弊社が、これまで以上の成長を遂げるためには、複数のプロジェクトを同時に成功させていく必要がある。
そのときには、ぜひ俺の屍を越えていってほしい。
必ずしもここで提案したツールが最高というわけではないかもしれないが、失敗してきた部分を知ることで、対策が打てるようになるだろうとの思いで書き連ねた。
僕自身、自分が遠慮して主張できてこなかったこと¹⁰を、このようにまとめることができてスッキリした思いである。

参考文献

今の僕の考え方を形成しているのは経験と、その都度躓いては読んできた本たちである。
各項目で明確に引用を示すことはできないが、僕の血肉となって思想を形成している代表として、特に影響を受けたものを紹介しよう。
探しやすいのでAmazonへリンクを張っているが、アフィリエイトなどはないので安心して踏んでいただきたい。

お知らせ

エイチームグループでは一緒に活躍してくれる優秀な人材を募集中です。
興味のある方はぜひともエイチームグループ採用ページ（Webエンジニア詳細ページ）よりお問い合わせ下さい。

明日

明日は僕以上に神経太いんじゃないかという疑惑の新卒2年目の @nrainiero です。最近一緒に飯食いに行って、うまい麻婆豆腐の店を教えてもらいました。きっと記事でもエンジニアにとって美味しいレシピを教えてくれることでしょう。みなさんお楽しみに！

google好きなのは隠さない ↩
繰り返しているところが痛い ↩
僕自身はソースコードが設計書だと考えている。仕様書は必要だが設計書は不要という立場を取っているが、どこまでを仕様と呼ぶのかで議論が起こる。 ↩
僕が過去に所属していた、塗装品を扱う工場では、天候などの諸条件で歩留まりが変わることもあり、なかなかコントロールしきれずに計画を見直すことも多かったが。 ↩
既存の組み合わせで解決できる課題なら、そのまま使うべきだ。既成のもので解決できることのために新しく作るのはナンセンスで、怠惰の精神を持つエンジニアとして恥ずべき行為である。 ↩
人月の神話で有名なブルックスの法則はちゃんと知っていてね。 ↩
チャレンジそのものを称えることも良いだろう。しかし、僕はプロジェクトの進行に対しての行動として賞賛することを望ましいと感じる。自分が貢献しようと思っている部分で貢献できていることの認知こそ、求めている承認であるためだ。 ↩
前述の通り、成功すると確信しているわけではないからというのが一番の理由。あとは、個人的な好き嫌いを含んでいる部分なので、推奨することがはばかられている。 ↩
エンジニアにとって魅力があるものかもしれないし、UXとして素晴らしいものかもしれない。 ↩
おそらく周りは今でも主張が激しいと感じているだろう ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up