はじめに
Photoruction Advent Calendar 2021 4日目です。
株式会社フォトラクションのPMチームに所属しています。神澤です。
最近は海外Youtuberのデスクツアーを見るのが好きで、机の裏を光らせようか真剣に悩んでいます。
3日目に投稿された記事は見ていただけましたでしょうか。
今回は別視点で、このプロジェクトの担当PMの、様々な問題点を赤裸々に語ろうと思います。
まず自分語り
一年半前、2020年4月にフォトラクションにジョインするまでは、建設業の世界で生きていました。
主に、建物の新築や改修工事の予算を計算するお仕事。他にも色々していましたが割愛。
これまでは、人と話すなら対面か電話、文章連絡やデータ送信はメールで、他社の話を聞いた際にNAS（ネットワークHDD）が設置されている会社に出会うと「進んでいるなぁ」と感じるほど。
Excelのvlookupと最低限のVBAが扱える程度で「お前はシステムに特に強いから」という評価を受けていました。
そんなIT素人とも言える私ですが、ビジョンへの共感と業界を良くしたいという想いを評価いただき、当初はドメインエキスパート（業界出身としてのシステム企画担当）として入社させていただきました。
現在では、プロジェクトマネージャーとしての役割に、この職務を吸収した形になっています。
新米PMでバックグラウンドが業界知識特化のため、とにかく初期はメンバーに支えられました。
プロジェクトマネジメントを先人（入社当時はCEO中島さんしかPM担当者がおらず兼任状態）から教わり、PMとは、システムとは、を学びながら仕事を進めていました。
現在も学びの連続です。
職人の技量頼りの監督
PM経験一年程で、3日目に投稿された記事のプロジェクトがスタートしました。
何回か案件を重ね、それなりに開発サイクルの理解も深まってきたと感じていた頃です。チョットワカル曲線でいう「完全に理解した」状態だったと思います。
この時点では「企画段階で新機能の期待動作が網羅出来ているドキュメントを作れば、とりあえず開発は上手くいく！！！」と考えていました。
これが間違っていたと考えた事象を以下に挙げます。担当エンジニアと記載していますが、一人ではなく、プロジェクトメンバー全員に対しての記載です。
- 担当エンジニアの経験則に依存していた
- 既存コードの理解が追い付いていない可能性のフォロー必要性が抜けていた
- プロダクトの仕様の理解が追い付いていない可能性という発想がなかった
- 「ワカッタツモリ」を「今のところ開発進行上には問題がないだろう、詳細を詰めたら分かるだろう」と受け取ってしまった
- 担当エンジニアの技量に依存していた
- どのエンジニアも時間をかければ既存コードの書き方に同意できるし、そのやり方に沿った改修が出来るもの、と考えていた
- 期待動作のアクションは他の機能の傾向を見てよしなに判断できるだろう、と考えていた
- メンバーの「正解が分かってないんだけど何が分からないのか分からない」問題を、ヒアリングで解決できると信じていた
- チームとして必要になるタスクを軽視していた
- OS差分や、ブラウザとアプリの差分、他諸々の懸念点はメンバーレイヤーで全て解決できると思っていた
- 他メンバーに依頼しなければならないタスクの洗い出しを行わず、とりあえず自分の領域を終わらせようというスタンスで考えていた（合わせるための検討や考え方の統一を後回しにしてしまった）
- 個々人が100点になれば総じて100点になると信じていた
振り返ると、相当酷いマネジメントだったなと思います。
「信じる」の言葉の履き違え方がすごいですね。
チームタスクはチームで支え合って進められている
自分のプロフェッショナル領域に責任を持つという価値観は大事だと思います。少なくとも私は尊重したいなと思っています。
しかし、だからといって一方的に任せてよいという理由にはならないことを改めて痛感しました。
個々人のタスクが各々で完了すれば全体も完成する、というのは、全体に必要なタスクを個人タスクに落とし込めている前提です。
チームである以上、各メンバーは他のメンバーに「支えてもらっている」面があります。
PMとしても「各メンバーのタスクを終わらせるためには」の視点以外に「他の人の仕事がスムーズに終わるには」「チーム全体のタスクを達成するには」と、メンバー同士のコミュニケーションを促進する働きを行う責任があると考えています。
もっと言うと、メンバー同士が自主的に尊重し合える文化作りまで必要ですね。
どうしていくべきか
誰しもが成長途中で、その時々の仕事内容で不足する知識や技量は往々にして存在します。なので失敗しない仕事もないし、攻略本のように全て予測可能なマニュアルを作る事もできません。
ただし、だからといって毎回失敗していいという訳でもありません。可能な限り、失敗を減らそうと考え続けることが大事だと考えています。
主にマインドの話になりますが、以下がまとめです。
- その場にいるだけで人を支えているし、人に支えられている。支えられてなくて無関係ということはない。リスペクトが大事。
- 問題が起きてから消火活動を始めるのではなく、起きる前の防災活動が大事。作りたい成果物から逆算して必要なタスクや懸念点を考える必要がある。
- 個々人で100点が出るのを待っていたのでは確認が遅い。早く失敗して、早く改善したかった。
- 単純な仕組み（部分プロセスの最適化）だけでは解決しない、新たなプロセスのたびに考え、正しい結果を出すための方法論を都度模索していくべき。
これらはPMである私だけでなく、チームメンバー全員で持っているべきマインドであると思っています。そのためには、まず火種役の私から持つべきだ、とも強く思っています。
これらは、フォトラクションMVVに通ずる話が多いです。私の体験談からでも紐づけることのできる、とてもよく出来ているバリューなので、今後も意識し続けていきたいです。
https://www.wantedly.com/companies/photoruction/post_articles/339794
おわりに
前編、後編、という形で、プロジェクトの振り返りをしてみました。
案をくれた田中さんへ、スペシャルサンクスです。
「完全に理解した」って本当に成長曲線の通りなんだな、これ考えた人天才だな、と思っています。とはいえ、なにもわからない、と言える自信はないです。
プロジェクトマネジメント、マジデゼンゼンワカラナイ。
明日は更に後編へ、、、とは続きません。
また別の視点でのエントリーをお楽しみください。
株式会社フォトラクションでは一緒に働く仲間を募集しています
