「こんな闇プロジェクトは嫌だ」アンケートをして開発プロジェクト落とし穴リストを作った話

この記事はSpeee Advent Calendar 2018 - Qiitaの12月24日の記事です。@hayato-iidaと@yuta-kobayashiが執筆しています。

TL;DR

• チームメンバーに「こんな闇プロジェクトは嫌だ」アンケートをした
• 想定の10倍闇の話が出てきた
• 分析した結果、頻出する落とし穴のパターンが見えてきたのでリスト化してみた

はじめに

クリスマスといえば自分の闇と向き合う季節ですね。

我々のチームで、現在、プロジェクトの成功率を高めるために良いプロジェクトのガイドラインを作成しているのですが、その議論のなかで「今までに経験した闇プロジェクトの話を集めたら反面教師的に参考になるのではないか」というアイディアからチーム内で過去の「闇プロジェクトあるある」を大喜利してもらったところ、転職経験のあるメンバーが多いおかげか予想以上に件数と内容が集まりました。これらを整理してとりまとめて見たところかなりプロジェクト状態の振り返りに役立ちそうなリストができたので、この記事で共有したいと思います。

以下の内容はフィクションです

ちなみに「以下の内容はフィクションです」的なノリと勢いでやったものですので 割と可愛い闇から、想像しただけで涙が出てきてしまいそうな闇まで出てきましたが あくまでフィクションです ので誤解のないようにお願いいたします。

それでは錬成された落とし穴リストを見ていきましょう

よくあるPJ落とし穴リスト

落とし穴リストTOP7

• 優先度の偏り
• 売上至上主義
• HRT（謙虚(Humility)、尊敬(Respect)、信頼(Trust)）の欠如
• 必要なロールの欠員
• コミュニケーション不全
• PJ運用のPDCA不全
• 根性論

その他の落とし穴リスト

• MVPでの検証がない
• クローズな情報共有
• セクショナリズム
• チーム開発への理解不足
• マナー問題
• 技術不足
• 極所負荷
• 権限一極集中の体制
• 社内政治
• 定量評価不全
• 目標不全

落とし穴リストの順位の付け方

TOP7がなぜこの7つなのかの理由です。 「プロジェクトの闇あるある」大喜利を実施したら、全部で 186個 の闇が錬成されました。 それぞれの「落とし穴分類」をざっくーりとしてみたところ 件数が多かったのがこの7つでした、という感じです。

落とし穴リストTOP7の解説

優先度の偏り

「その優先度づけでPJ進行させて本当によかったんだっけ？（ツライ）」という内容が集まっていました。

例

• 優先度が全部「高」
• 期限と機能優先しすぎてリリース後不具合連発で帰れない
• 「とりあえず動けばいい」が横行してしまう
• 一度に全部をリリースしようとする(基幹システム同時刷新)
• 新しい技術のキャッチアップ期間が工数として確保できない ( 休日やってきてね )
• バグの原因調査をしないまま見積もる
• バグを残したまま新規機能開発をし続ける
• 理由もなくテストの期間だけ圧縮される

こんな感じで、事情はわからなくもないけど、「その優先度の意思決定なんか偏ってないぃぃぃいい！？？」という時、PJは落とし穴にハマるようです。 その優先度の意思決定は、誰が見ても妥当ですか？関係者はちゃんと納得できていますか？十分な説明はされていますか？ とか問いかけてみると、未然に防げるのかもしれませんね

売上至上主義

「これってMissionの実現に紐づいてるの？目先の売上しか目に入ってなくない？」というような内容が集まっていました。 「売上は上がるかもしれないけどユーザーさんに優しくない気がする・・・」ような施策とかですかね。

例

• 根本的なところで売上を上げることだけが目的のPJ
• 季節限定商品に店舗ノルマがあって客には特に営業とかせずに従業員に買わせてノルマ達成しようとする
• お客さんといついつと握ってきちゃったんでと期限無視な要望がとんでくる（多分無理やり間に合わせるからプロダクトの品質が下がる）

こんな感じで、事情はわからなくもないけど、「これって本当にMission実現に向かってますよね？あれ、っていうか私たちのMissionってなんだっけワカラナイィー」という時、PJは落とし穴にハマるようです。 Missionってなんだっけ、Objectiveなんだっけ、KRってなんだっけ？ というのを常に問いかけられていればそんなことにはならないんじゃないかと考えるとやっぱりMVとかOKRってめっちゃ大事ですね

HRT（謙虚(Humility)、尊敬(Respect)、信頼(Trust)）の欠如

これはもう文化とかモラルというか、「なんか攻撃的で怖いよう」とか「なんでそんなこと言うんだよT.T」というような内容が集まっていました。

例

• 「あいつ気に入らない」って公言する人がいるPJ
• 「私〇〇さんのこと信用してないっすから」と僕に言ってくる人がいるPJ
• KPTで個人攻撃
• 批評をする人の割合が、行動する人よりも圧倒的に多い
• 「最初から自分は失敗すると思ってました」
• 俺が納得するまで開発はせんぞ！って言ってる人がいる。特定個人の納得よりもチームとしての決定や、施策責任者の意思を優先したい

こんな感じで、文化やモラルがHRT欠如状態だと、PJは落とし穴にハマるようです。 その発言、HRT持ててる？その態度、HRT持ててる？ というのをみんなが自分に問いかけ続けていて、そうしている人が多数派になれていれば自然とHRTを持てたチーム、PJになるような気がするんですがどうなんでしょうかね

必要なロールの欠員

PJの成功に「この役割必要だったよね」というロールってあると思うんですが、そこが欠員してる感じの内容でした。これはなかなかキビシイ

例

• 半年前から要請していたにもかかわらず、開発時に予定の半分の人員もいない
• Javaのプロジェクトにもかかわらず、設計者にJava経験者が自分しかいなかった
• データアナリストがおらず、誤った集計方法で誤った結論を出し、誤った認識のまま開発を進めている
• ディレクターがなんでも屋にならざるをえないチームになってる。必要な職能を持つ人がいない or 分業が正しくできていないので、足りないものをディレクターが全部すくってる感じ。
• 「技術」と「ビジネス」の間を、適切に繋げる役割の人がいない。エンジニアは技術だけ、ディレクターはビジネスだけを追ってて、どのように顧客にとって価値があるプロダクトを作り続けるかが議論されていない。

こんな感じで、PJの成功に必要なロールが欠員していると、そこにいる人たちでなんとか埋めようと頑張るんだけどPJが落とし穴にハマることが多いようです。 本当にこの役割分担でいけるのか？無理してないか？ というのを問いかけてみると、もしかしたら解決策が浮かんでくることもあるんじゃないかと思うのですがどうでしょうか （でも確かに人は足りてないんだけど頑張らないとっていうこともあると思うので難しいですね。ただ、「足りてないけど頑張っている」というのを適切にチーム内の共通認識にしておくのもまた大事なんじゃないかと思います）

コミュニケーション不全

これは「HRT（謙虚(Humility)、尊敬(Respect)、信頼(Trust)）の欠如」と似てたんですが、「ピリピリしすぎで怖い・・・」とか「お互いのこと何も知らないな・・・」みたいな内容でした

例

• PMが笑わない
• 基本MTGがお葬式
• お互いをなかなか信頼できず心理的安全性の低いチームでプロダクト開発が進んでしまう
• 無駄にピリピリしてるMTG
• 餅は餅屋すぎて同じチームなのに、まったく関わりがない。何やっているか分からない
• 雑談してると時間の無駄してる感じで見られる空気

こんな感じで、コミュニケーションがうまくいっていないとPJは落とし穴にハマるようです（当然っすな・・・）

ちゃんとコミュニケーション取れてる？そういう仕組み整えられてる？ とか問いかけると、改善しなきゃ！っていう意識が芽生えるのかもしれないですね

PJ運用のPDCA不全

これは「その闇って、なんでそのまま放っておかれたんだろう・・・」という内容が多かったです。普通にPJ運用のPDCAが回されていれば、改善のメスが入るよねという・・・

例

• 仕事時間の3/4がMTGで埋まる
• お正月に一回再起動が必要なプロダクトの原因を解決できない
• ディレクターにいろんな責任はあるが権限がない
• 業務コードでコードゴルフしてる人がいる（レビューがあれば引っかかるので「適切なレビューがない」という話かも?)

こんな感じで、PJ運用のPDCAは不全に陥らせたらダメですね。落とし穴にハマります。 今の運用方法でうまくいってる？KPTとかした？やめるべきもの続けてない？ とか問いかけると、PDCAが少しづつでも回るようになるのではないでしょうか

根性論

これはもう・・・そのまんまでしたw

例

• 「頑張って！」「この大変さはきっといい経験になる！」とだけ言われて誰も助けてくれない
• 週2回は会社に泊まってる…
• 上長に相談しても精神論しか返ってこない
• エンジニアのリーダーがサイヤ人理論を語りだし、若手エンジニアをとりあえず追い詰める
• 月に休みが1日しか取れなかったのに、もう1日休みをもらうのに電話口で泣いてしまうメンタルになってしまう
• 姿勢が悪いという理由で半日説教

根性論は時には必要かもしれないんですがやりすぎるとPJは落とし穴にハマるようです。 それは根性論ではないのか？本当に建設的な発言なのか？ というのは常に気をつけていたいですね

（番外編）プロジェクト末期症状

番外編として、「フィクションとはいえ大胆なの書いたなw」というのをいくつか紹介しておきます。 ここまで進行したプロジェクトを立て直せた経験は無いのでこうなる前にどうにかしましょう。

• チームのエンジニア2人が殴り合いの喧嘩をして翌日チーム全体で会議
• ディレクターがいないと思ったら非常階段の踊り場で立ち尽くしている
• 売上金を盗む人がいる
• 死人が出る

闇大喜利の効果

ノリで始めた大喜利でしたが、思った以上にチーム内で効果がありました。

プロジェクトと自分自身のチェックリスト

みんなが出した闇プロジェクトを眺めながら「こんなのありえんやろ」と笑っていましたが、人間知らないうちに闇に向かう事も多いので、 自分自身やプロジェクトのことを振り返る良いチェックリストになりました。

価値観の共有

「これが嫌だった」というのは翻ってその人が何を大事にしているかを知る機会になります。 今後の仕事の中でお互いの価値観を尊重しながら進められるようになる効果が見込まれます。

闇の共通語化

後日似たよう状況が起きたときに「このときに書いた状態に近いよね」という会話ができるようになります。 これは一度チーム全員の闇を吐き出したことで共通言語として闇が認識されることで、プロジェクトがまずい方向に向かっている兆候を早めに察知するスキルがチームとして備えることに繋がります。

まとめ

世の中には闇が多くありますが、それらもみんなで吐き出して、向き合うことで学びに変えて未来につなげる(=光に変える)こともできるかと思います。

皆様も是非クリスマスに向けてチームの闇の記憶を出し合ってみてはいかがでしょうか。