最初はかすり傷だと思ってバンドエイドで治療してたけど1ヶ月後にレントゲンとったら骨折してた話

私のなかで2017年上半期のやらかし大賞に選ばれたので後世の私のために書き残す。

※あまり推敲はしていない。そろそろ忘れそう(発生から3ヶ月くらいたった)なので書いた。

結論

簡単な方法で対処したけど影響を見誤ってて、結局大きな改修が必要だった。冷静に影響範囲を判断して適切に対応しましょうねという事案。

私 : 企画者兼プロダクトマネージャー兼サーバサイド等担当。特にphpでのサーバサイド開発に自信が無い。

2016年末にリリースしたサービスの姉妹サービスの開発をやっていくプロジェクトが2017年2月に始動し、私は前回のアプリから引き続きプロジェクトを主体的に進めていく役割でチームを作った。

前回よりも画面数が2倍、機能数が4倍あったのでオーナーさんにお願いして助っ人の開発者さんをお願いした。開発3名(うち1人は私)デザイン1名という人員で、フルコミットは私一人、開発者の人とのコミュンケーションは基本チャットで。必要なタイミングで対面で打ち合わせを行うという体制。

いろいろあって3月初旬に本格的に開発に入っていった。

開発しているサービスで、とあるイベントを発火させるタイミングをずらすというサービス仕様の変更があった。

※ちなみにこの変更は私の仕様の勘違いで発生した><;;

当時は開発スケジュールに遅れがでており、さらに仕様は議論を重ねた上でオーソライズされたもので、且つ私の勘違いに起因するものだったので心理的な障壁があった。また、リモートで作業してもらっている中で改修のプロセスを踏もうとするとメンバーへの負担が大きくなることが容易に想定できた。

ということで当時必要とされていた機能に画面・ソースコード、DBの関係から問題ないことを確認して、そのイベントの発火タイミングを調整するという対処を行った。

それから約1ヶ月が経過してスケジュールに予定されていた部分は完成した。

そして機能テストを開始し概ね改修が終わった当たりで問題が起こった。

アプリの根幹をなす重要な機能がうまく動作しないという問題で、これは大変だと調査を進めていくと、アプリの根本的な設計がまずいことがわかった。

そしてその設計がまずい部分が、先に私のミスでずらしたイベントの発火タイミングだとわかった。

そのことがわかってからは、

などという誰もが思いつくような問答が繰り返された。

最終的にはきちんと改修してリリースするということになって、通常納期から2週間の遅れが発生することになった。

間違えた道案内をしてしまい、雨の降っている中一回登った山を降りてもらって別な道から登ってもらうという謎の行為をさせてしまった後のような気まずい精神状態になった。

設計時にズレに気づくことはできなかったのか?モックアップを作り、全ての画面と機能を網羅できていたのであれば、見つけることができたのでは?

はい。すべての画面と遷移をモックアップにして、すべてのボタンや遷移を実装した機能面も含めたレビューをすれば見つけることができたと思う。

今回のプロジェクトでは問題になった部分も含めモックアップは用意されており、レビューもされていたが、画面の配置やデザインが主たる確認部分となってしまい、機能のレビューが完全には行われていなかった。

モックアップ作成の目的に機能の確認を入れるならやりきる。入れないなら入れないで別な場所で確認するといった決めが必要だったと思う。

修正のタイミングで気づくことはできなかったのか? はい、少し考えれば正しい道筋を見つけることが出来たと思う。しかし当時は考える方向性を誤ってしまった。

自分のミス起因、スケジュールの遅れ、開発者さんたちとの調整、自分で埋め合わせをすることが出来ない、オーソライズされた設計を変える….

これらの思い(動揺とプレッシャー)から目先のことしか考えられなくなっていた。

感情の動きが激しい時こそ。
- ミスした時、怒った時こそ冷静になる。
作業に曖昧な意味を持たせない。
- ついでに◯◯もチェックできるやんけ!効率的に物事を進めるのは良いことだけど、やるならやりきる。
最終判断者はあなた。
- プロダクトマネージャが道に迷うと一緒に道に迷う人がいる。
- みんな様々な利害関係を持っている。あなたのこと(あなたのプロダクト)を本気で考えるのはあなただけ。

という気持ちでやっていく。

一度みんなで決めてわりとしっかりしてるなって思ってたものをあらためて見直すって行為、知能的にも心理的にもかなりのパゥアーが必要な気がした。
ビジネスロジックが変わるから当然それに紐づいてる設計とか実装に影響あるよねって話。
ざざざっと勢い良く作ってる時にこうするべきなのでこうしようとかって差し込んでいくの野暮な場面もあるよね。
細部までやりきるのって大変だね。
イベント発火のタイミングは、ユーザ有利か会社有利のどちらかで、私はユーザ有利なタイミングを正と認識としていたが、オーナーとかは会社有利なタイミングを正と認識していた。なんでズレたんだろう。
一息の思考の深さ大事(ハチワンダイバー並感)。
俯瞰できる範囲って想定できるアクシデントと同じっぽい。ということはInput量とか経験で決まりそう(小並感)。
クライアントサイド(スマホアプリ)とサーバーサイド(API)だとクライアントサイドのほうが10倍くらい大変なんだよね。という前提をもってる。