今までの成功体験を振り返ってプロジェクト成功の法則を考える

もう21世紀ですが、まだまだ苦しいプロジェクトは少なくないようです。どうすればプロジェクトを成功に導けるのかを、自身の経験から考えます。

成功したプロジェクトの思い出

長いことITエンジニアをやっていますが、自信をもって成功したといえるプロジェクトって驚くほど少ないです。売上として成功していても、過程に苦しい残業や手戻りが発生したことも少なくありません。

思い出せる範囲で成功プロジェクトを整理してみました。

①災害観測システム

概要: 山の中に埋めたセンサーの計測値をグラフ表示したり、そこから災害予測する指令室にありそうなシステムを作りました。
時期: 2000年ごろ
思い出: 初めて大きなプロジェクトを任せてもらって、当時としてはかなり先進的な技術を使わせてもらいました。; 今思うと無謀なチョイスもあった気がしますが、気心の知れたメンバーとの作業だったので、意思疎通しやすかったです。

②某転職サイトCMS化

概要: 某転職サイトをXoopsでCMS化しました。
時期: 2006年ごろ
思い出: 仕様とにらめっこしながらXoopsプラグインを書いたりして楽しかったなあ。; 何よりチームメンバーが仲良く切磋琢磨できたのが良かったです。; 大きな手戻りがなかったのはPJリーダーの設計が良かったのだと思います。

③自社サービスのリニューアル

概要: 古くなってきた自社サービスのWebシステム化（のテコ入れ）
時期: 2017年ごろ
思い出: 新卒3人の初めての実戦PJでボロボロだったところに立て直し要員としてアサインされました。; 開発作業を徹底的にルール化、手順化してとにかく終わらせることに集中しました。; そのサービスは今でも収益を上げているので成功と言って良いと思います。

成功要因

時期もメンバーも異なる3つの成功例から、法則は見いだせるのでしょうか？ワタシが思うに、以下の2点が良かったのではないかと思います。

何をするべきか明確だった
信頼できるメンバーと一緒だった

何をするべきか明確だった

②はリーダーが、③はワタシがゴールを明確に指示したことで、ゴールに向かって手戻り少なく走れたのだと思います。 ①はあまり厳密な設計を行ったわけではないですが、メンバーとの意思疎通でカバーできたのだと思います。

ソフトウェアの開発プロジェクトで一番大きな損失は手戻りです。特にゴールが定まらないことによる迷走は心も体も疲弊します。

失敗しないプロジェクトマネージメントのコツ

「何を作るのか」の決めは一番重要です。ここが崩れるとその先すべてに手戻りが発生してしまいます。

ドキュメントを書きたくなくて1枚絵だけで長年しのいで来た話

言ってしまえば発注者は自分の希望通りのものが予定通りできればOK、開発者は何を作ればよいのかが明確であればOKのはずです。

信頼できるメンバーと一緒だった

①②ともに、お互い尊敬しあえる仲間がいました。 ③は新人と先輩という立場でしたが、逆にまっさらな新人だったからこそ、ワタシの采配を信じて頑張ってくれたのかもしれません。

Googleの研究によると、心理的に安全なチームはより成果を出せるのだそうです。

心理的安全性を高める | re: Work

Google のリサーチチームが発見した、チームの効果性が高いチームに固有の 5 つの力学のうち、圧倒的に重要なのが心理的安全性です。リサーチ結果によると、心理的安全性の高いチームのメンバーは、Google からの離職率が低く、他のチームメンバーが発案した多様なアイデアをうまく利用することができ、収益性が高く、「効果的に働く」とマネージャーから評価される機会が 2 倍多い、という特徴がありました。

チームだけでなく組織も成果に大きく影響するそうです。これをコンウェイの法則あるいは逆コンウェイの法則などと呼びます。