bon now

今日ふとあることに気づいた。僕が社会人になってまあまあな数のITプロジェクトを経験してきたけれど、僕の関わったプロジェクトで「これは失敗だった」というプロジェクトがほぼないということに。
今日気づいたので理由を真面目に考えたことももちろんないわけで、ちょうど良いからこの機会に少し振り返ってみる。ただし、もう眠いのである程度雑に振り返ることにする。

新卒1年目は経験不足による失敗

まず新卒1年目のプロジェクト。カスタマーサポートなのでプロジェクトという体系のものでもないのでカウント不可能ではあるが、顧客の対応1つ1つをミニプロジェクトと捉えてみる。
これは1つ確実に失敗したなっていうのがある。とあるユーザーのシステムの設定が急におかしくなり接続不可となったのであった。僕の案内した方法や再現手順、回避策はことごとくダメで、テキストベースでやり取りを繰り返すうちに認識齟齬も増えて結局訳わからない状態のまま先輩に引き継いだ。
今もしこれをやり直すことができるのであれば、こじれるまえに電話なりミーティングなりをやろうと提案してると思う。もしくはもっと早い段階で状況についてチーム内で共有し、開発元へエスカレーションすべく偉い人たちの意見を集めてクレーム化するという方法を取るだろう。SIにおいてはやはり偉い人の権力はとても強い（笑）
ということでこのプロジェクトが失敗したのは、単純に僕の経験不足に帰着する。他にも派遣終了が近づいた1ヶ月間くらいは重大な作業を任されなかったので暇つぶしにネットサーフィンとかやっていた。これも今なら情報共有やドキュメント整備とかもう少しやることあっただろと当時の自分を殴りたい気持ちはある。

新卒2年目は論文作成で失敗

その後はツール導入やらガラケー向けのWebアプリ開発とかをやったんだけど、こっちのほうは当時のパワー系プロマネ上司のおかげで残業しつつもいい感じに終わった。ガラケーアプリは日の目を見ることはなかったけれど、なんだかんだその後の自分のキャリアにJava開発者というタグ付をしてくれたのであながち失敗はしてない。なのでプロジェクトの失敗はこの時点ではなかったのだが、当時所属していた会社での一大イベントとして新卒2年目論文を書くというお祭りで下手こいた。
今考えるとほんと馬鹿だなって思うけど、仮説や前提を考える癖はこのあたりで身につけた気もしないでもない。(そうしないと部長に殴られる）

3〜5年はモチベ下がって失敗

仕事がなかったので保守案件に携わるようになり、ドキュメントの整備やリリース手順の確認など僕が苦手なドキュメントを眺める仕事が多くモチベ下がってた。あまりにも下がり過ぎて「このままじゃ無駄に時間が過ぎてしまう」という危機感を覚え出会ったのがRuby on Railsだった。
この頃にRailsでAPIのモックサーバーを作ったんだったなあ。。。当時はRESTでパラメータを分けることで動的値を返すという発想ができずに固定値を返すことしかできず、休憩時間中に必死にデモ向けのパラメータを書き換えるということをやっていた。また、地図アプリを作って任意の座標にマーカーを置くWebアプリを作ったりもした。このあたりにモチベを感じる人だというのが周りにも広まったせいか、その後ほぼプログラマにコンバートされた。

この頃にやってた要件定義フェーズのプロジェクトは失敗した。これは目的が曖昧で手段にばかり目を向けてたせいで進捗が著しくなく仕切り直しになったという流れなので、あまり僕自身が失敗したというわけではない。ただ、当時1年目の社員に愚痴ったのはかなりダサかった。

1社目の6年目以降は多分成功しかない

あれは失敗したなーという記憶がないので失敗してないはず。まあ当時ベテランのおじいちゃんプロマネがまとめてくれたり、後輩凄腕プログラマ兼PMが色々リカバリーしてくれたり、オフショア先の技術力が高かったりしたおかげではある。炎上プロジェクトに放り込まれたとき課長と喧嘩したのもいい思い出だ。おかげで生意気過ぎる情熱SEとして有名にはなれた。
一部リリース時に漏らした設定値があったり勝手に工数増やしてレイアウト対応したりもしたが、失敗という程の大きな問題ではないだろう（多分）
この頃の僕の功績としてはOSSライセンスをまとめたり他部署の課題を何故か無償で解決したりサーバー設定の助言をしたり明らかに役職の責任範囲を超えた仕事をやっていたことだろうか。当時の部長からも「お前が良いと言ったからって、それになんの価値があるの？」というお言葉をいただいたこともある。そのとおりだわ。

2社目も失敗は思い出せない

2社目でのプロジェクトも失敗というものはなかった。スケジュールもいい感じに調整したし、僕が「仕様制限でいいっすよ」と軽く実装者にのみ伝えて実装漏れがリリース直前まで気づかれなかったことも、なんとか仕様として回避することができた。
まぁ、失敗するような大きなプロジェクトを任されていないというのも理由の1つかもしれない。ある程度着実に進めることが前提の作業ばかりをKPI作りながら進めていれば、そりゃあ失敗はしないだろう。ということで失敗なし。（嘘だったらごめんなさい）
謎にPoCとしてKubernetesやGraphQLをやったりやらなかったりしたけど、プロジェクトの方向性自体は正しい方向に向かって推進できたはずなのでこれも失敗にはカウントしない。

現職も失敗はなさそう

個人的な失敗は山程あったけどプロジェクト全体での失敗は1つもないはずだ。とはいえ、ここでも優秀なメンバー、上司、関連部署社員に助けられたというのは明白な事実である。

結論

つまり周りの環境（人、運、プロダクト、チームなど）に恵まれていたために失敗が少ないと言えそう。つまりガチャ運が強かっただけだった。
これらの経験から、結局失敗する要因ってのは、ほとんどは集まった組織の人・プロダクトの質・リソースに左右されるということが個人的な結論だ。QCDとはよく言うけど、プロダクトを作り始める前段階で大体のQCDは決まってしまう。これをどう操作するかを考えることと、理想的な状態からのズレを常に意識しつつ、タイミングよくそれを調整していく事が重要そう。そしてこの作業には実タスクはあんまり関係ないと思う。実タスクはあくまで作業を明確化したものでありそれがAだろうがBだろうが、出来上がるもの、目指すべき方向が誤っていなければプロジェクトとしては失敗することはないのである。
この関係性を無意識のうちに気づいて実践できていたのだろう・・・と、個人的には分析する。

そんな感じで、プロジェクトのスタートとエンドの予想と実態にさえ気をつけていれば、ある程度適当でもなんとかなる。さあ、みんなもリーダー、マネージャーになって体験してみよう。

2021/10/3 追記

1つだけとんでもない失敗をしていたのを思い出した。要件定義時の非機能要件に応答速度を入れ忘れたせいで、サービスの要件を満たせないことに気づいたのがリリース前検証だったというプロジェクトがあった。
これを機に、素早く失敗する(素早く検証できるものはする)ということの重要性を学んだ。