こんにちは、モバイルエンジニアのころむにーです。
普段、モバイルアプリを通じたユーザーへの価値提供を目指すプロジェクトに、技術リードという立場で参加しています。
本記事では、プロジェクトマネージャーという職種について、私個人が最近考えていることをまとめてみます。
はじめに
今まで、複数のプロジェクトマネージャーの方々と一緒に働く機会がありました。
プロジェクトマネージャーの方々は、スピーディーに決断を繰り返し、様々な立場の人を巻き込んでアクションをとることで、継続的な価値提供にコミットしていました。
この営みは多面的なノウハウやスキルが必要であり、私にとって非常に魅力的で尊敬すべきものでした。
私自身も、プロジェクトマネージャーの営みの一部を担えるようになりたいと考えています。
そのために、プロジェクトマネージャーの方々がどのような考えでアクションをとっているのかを、自分なりに解釈し、整理してみることにしました。
本記事で書くこと
本記事では「プロジェクト」という単位で動く時の考えについて書いていますが、もっと小さい単位の「タスク」にも適用できることを意識しています。
また、所属するメンバーが、それぞれ現時点で最大限のパフォーマンスを発揮して、プロジェクト全体でベストな成果を出すために必要なことを考えます。
メンバーの成長や、組織設計なども考慮に入れると考えることが増えますが、それは本記事の対象外とします。
本記事の読み方
私が解釈したプロジェクトマネージャーのノウハウを、構造化し、各項目ごとに独立した形で書いています。
そのため、目次を見て気になった項目だけを読んでいただいても、問題なく理解できるようになっています。
もちろん、上から順番に読んでいただいても問題ありません。
1. 環境を明確にする
プロジェクトには目的や制約などの環境があります。
そうした環境に対する理解は、プロジェクトで効率的にアクションをとるために重要です。
1-1. 目的を明確にする
プロジェクトには必ず目的があります。これを明確に理解しておくことが重要です。
日々の決断を繰り返す中で、元々の目的に立ち返ることで、より良い道が見つかったり、間違いに気づくことはよくあります。
目的は、以下のようなものがあります。
機能 A が技術的に実現可能なのかを知りたい。
機能 B にニーズがあるかを知りたい。
1-2. 制約を明確にする
プロジェクトには必ず制約があります。これを明確に理解しておくことが重要です。
また、制約には「動かせる制約」と「動かせない制約」があるため、このような制約の「固さ」も明確にすると良いです。
制約には、以下のようなものがあります。
3 ヵ月後には iOS のアプリストア審査におけるポリシーが変更され、新しいポリシーに準拠した形でアプリを修正する必要がある。
この期限は動かせない。
1 ヵ月後に機能 A をリリースする予定である。
この期限は対外的に公表されているものではないため、社内の合意が取れれば動かせる。
上記 1 つ目の例のように動かせない「期限」だった場合、そのスケジュールにマッチする実現方法のみを考えれば良いことになります。
このように、動かせない制約を把握することで、選択肢を削り、効率よく進め方を考えることができます。
2. 人を把握する
プロジェクトは自分を含め基本的には複数のメンバーが関わるものです。
そのため、自分自身や関わるメンバーに対して真摯に向き合い、適切な役割分担やコミュニケーションをとることが重要です。
2-1. 各メンバーが判断できる領域を把握する
自分を含めた各メンバーがどのような能力や情報を持っているかを把握することで、プロジェクトで必要な各種判断における効率的な役割分担ができます。
判断の例としては、以下のようなものがあります。
機能 A のリリースには、サーバー側の機能とクライアント側の機能両方を開発する必要がある。
クライアント側の機能は、自分で最適に設計できる。
サーバー側の機能は自分でもある程度設計できるが、最適な設計は B さんの方ができそうだ。
バグ C の解消には仕様の微修正を含めた対応が必要である。
この微修正は小さいものであるが、プロダクトの中心的価値を担う部分の修正であるから、妥当かの判断は自分だけではできなさそうだ。
プロダクトオーナーの D さんは自分よりユーザーの要望や視点を把握しているため、D さんに判断してもらうのが適切だろう。
しかし、この領域の線引きは、一般的に難しいことです。
以下のような機会を活用して、自分が認知できていない領域外の存在を感知することが重要です。
- 普段の会議や雑談などで、他メンバーが何をやっているのかの情報を得る
- 知らない単語が出てきたら、その聞いたり意味を調べたりして、自分なりに理解して咀嚼する
- 自分の判断により手戻りが発生する失敗をした際に、その原因を分析する
2-2. 人間の性質に向き合う
プロジェクトにおける各種アクションは、合理的に進めればそれで全て上手くいくわけではなく、人間の非合理さや感情的な部分と真摯に向き合う必要があります。
以下では、項目に属するトピックのうちプロジェクトで意識したことがある例をいくつか挙げてみます。
例 1. 何度も伝える
複雑な伝達事項を 1 回伝えただけで理解して記憶してもらえることは稀です。
重要な伝達事項は、以下のような手段で相手にきちんと伝わるようにコストをかけることが重要です。
- 伝達を繰り返す
- 口頭と文面の複数の伝達方法で伝える
- 伝わっているかを確認するためのフィードバックをもらう
例 2. 伝え方を気を付ける
人は自分の意見を正論で否定されると、つい防御的になってしまうことがあります。
建設的な議論を進めるためには、以下のように、お互いを尊重しつつ話し合っている内容にフォーカスすることが重要です。
- 最終的な目指す方向の目線合わせをする
- お互いの意見を丁寧に理解する
- 自分と相手で理解している情報や前提としていることに差がないかを確認する
例 3. 心身の健康を保つ
心身の健康が保たれていない場合には、パフォーマンスが落ちます。
以下のように、思い切ってタスクを後回しにして休むことも重要です。
頭が回っていないし、相手の言動にイライラしてしまうな。
こういう場合は、心身の健康が保たれていない可能性があるから、一旦休憩してリフレッシュしよう。
3. 情報を整理する
プロジェクトには多くの情報が流通します。
それらの情報を適切に整理し、活用していくことが重要です。
3-1. 外部記憶を活用する
情報を外部記憶に残すことで、人間の脳で覚えておけない量の情報も扱えるようになります。
また、正確に情報を外部記憶に残しておくことで、多くのメンバーの時間を節約できます。
以下のように、外部記憶をうまく活用することが重要です。
バックログや Wiki などの情報を残し、定期的にメンテナンスしておくことで、必要な情報をすぐに取り出せるようにしておく。
分からないことがあった場合に、Wiki と Slack の情報を確認することで、自己解決できた。
また、誤解のないように情報を正確に残すことや、アップデートがあった場合にはリアルタイムに更新することが重要です。
Slack で方法 A と方法 B のどちらがいいかを議論していた。
文面でのやり取りは効率が悪かったので途中で口頭での議論に切り替え、方法 B を採用することにした。
この際、Slack のやりとりに結論を追記しておいた。
3-2. 一次情報にあたる
伝聞情報は正確性に欠けることがあるため、可能であれば発信者から直接情報を得ることが重要です。
プロジェクト内部でのやり取りも該当しますし、技術的な情報も該当します。
例えば、以下のような行動を取ることが重要です。
他の人から伝わった内容によると緊急度が高いタスクだと思っていたが、発信者本人に直接聞いてみたらそこまで緊急ではないタスクだった。
機能の実装方法を第三者の技術記事で見つけたが、公式のドキュメントでは非推奨の方法だった。
ライブラリで使いたい機能に関して、公式ドキュメントの日本語翻訳ページには使い方が記載されていなかったが、英語のページには記載されていた。
3-3. 情報を圧縮する
情報は、抽象化や取捨選択などにより圧縮して整理することが重要です。
情報の量が減ると、一度に頭の中で考えられる情報の総量が増え、結果的に全体像を把握しやすくなります。
以下のような手段で、情報を圧縮することが重要です。
選択肢 A で利用する技術〇〇は、〇〇の機能を実装する部分で〇〇という課題があり、上手く実装ができるか現時点では不明である。
これはつまり、「選択肢 A は、仕様の再検討などの手戻りリスクやスケジュール遅延のリスクがある」ということである。
また、バックグラウンドの異なる人同士での議論の際に、適度な取捨選択がされた情報を用いることで、全員が議論の内容を理解しやすくなります。
各選択肢の実装方法を具体的に考えた上で、工数やスケジュールリスクなどのみを議論の場で伝え、合意形成を進める。
4. 決断する
プロジェクトでは、多くの場面で決断を下す必要があります。
その際には順番に必要なステップを踏むことで、より良い決断を下すことができます。
4-1. 選択肢を発散させる
何かを決断する時、複数の選択肢の中から最適なものを選びます。
その前段で、取りうる選択肢をあらゆる観点から網羅的に洗い出しておくことが重要です。
以下では、項目に属するトピックのうち、盲点となりやすいと感じた例をいくつか挙げてみます。
例 1. 小さく始める選択肢を考える
何かアクションを取ろうとしている時、それらが細かく分解できないかを考えることが重要です。
段階的にアクションをとることで、早期に軌道修正ができます。
例えば、以下のようなアクションが該当します。
最初の時点では、機能 A と機能 B の両方を実装する予定だった。
しかし、機能 A のみでもユーザーに一定の価値を提供できるので、まずは機能 A をファーストリリースすることにした。
機能 B はファーストリリースのあとに、ユーザーの反応を見ながら実装するかを検討することにした。
例 2. 何かをやめる選択肢を考える
何かをやめるというのは、意識的に考えないと思いつかないことが多いです。
一方で、何かをやめることで、他の重要なことにリソースを割り当てることができます。
例えば、以下のようなアクションが該当します。
機能 A の実装に着手したが、想定よりも工数が膨大にかかることが判明した。
そのため、一旦機能 A の実装を中断し、要望が高まっている別の機能 B に注力することにした。
4-2. 選択肢を収束させる
選択肢を発散させたあと、収束させていき、最終的には 1 つの選択肢に絞り込みます。
収束させる際には、各選択肢のメリットとデメリットを比較し、ベターな選択肢を選んでいくことが重要です。
以下では、項目に属するトピックのうち、実際のプロジェクトで重要と感じた例をいくつか挙げてみます。
例 1. 選択肢のリスクを考える
各選択肢に対し、リスクを洗い出してそれに対して有効な事前対策と事後対策ができるかを考えることで、選択肢を効率的に絞り込むことができます。
例えば、以下のような内容を考えます。
- リスク
- 選択肢 A はサーバーへの負荷が高く、サービスのパフォーマンスが低下するというリスクが考えられる
- リスクへの事前対策
- サーバーの負荷を減らすためのコードレベルの改善やインフラのチューニングができるかを検討する
- 負荷テストを行い、リスクの大きさを調査する
- リスクへの事後対策
- リリース後の監視を強化し、パフォーマンスが低下した際には早期に切り戻しを行う
技術的な内容だけでなく、以下のようにビジネスや業務フローに対するリスクも考慮が重要です。
- 既存のユーザーが新しい機能にスムーズに移行できない
- エンドユーザーからの問い合わせが増えて、サポートのコストが上がる
例 2. 1 つピックアップして深掘りする
選択肢をどう選べば良いか見当がつかない場合、任意の 1 つの選択肢を深掘りしてみるという手段が有効です。
これにより、他の選択肢をどの程度深掘りすれば良いか、深掘りにどの程度時間がかかりそうかなどの理解が得られ、次に進めやすくなります。
例えば、以下のようなやり方が該当します。
選択肢 A について、実際の設計や実装における技術的な内容を深掘りし、おおよそのコストや不確実性を把握した。
これにより、選択肢 A が 5 スプリント程度の工数かかりそうなことがわかった。
また、選択肢 B は A よりもさらに複雑であるため、来月のスケジュールがマストであるこの状況には適さないと判断し、選択肢から除外した。
4-3. スケジューリングする
実際にアクションを進めていくには、スケジューリングをすることが必要です。
スケジューリングの精度は、プロジェクトのスピードや成果に影響してくるため重要です。
以下では、項目に属するトピックのうち、実際のプロジェクトで重要と感じた例をいくつか挙げてみます。
例 1. クリティカルパスを考慮する
クリティカルパスとなっているタスクを優先的に進めることが重要です。
クリティカルパス上のタスクは、遅れるとプロジェクト全体の遅れに繋がるため、優先度を高くする必要があります。
例えば、以下のような判断をすることが該当します。
タスク B とタスク C は、タスク A が完了しないと着手できないため、タスク A を最優先で進める。
例 2. 不確実性の高いものから取り組む
タスクは、不確実性の高いものから早めに取り組むことが重要です。
これにより、「取り組んでみると予想以上に時間がかかる」などの想定外のリスクを効率的に減らしていくことができます。
例えば、以下のような判断をすることが該当します。
タスク A は作業量が多いものの、以前にも似たようなことを実施した経験があるため、ある程度見通しが立っている。
一方で、タスク B は作業量自体は多くなさそうな感覚があるものの、未経験の技術を使うため、見通しがあまり立っておらず不確実性が高い。
このため、タスク B に先に取り組むことにした。
5. アクションを取る
プロジェクトでは、情報整理、決断、合意形成、作業などさまざまなアクションを取ります。
その際、以下のような考えを持つことで、より効率的にアクションを進めることができます。
5-1. 人を頼る
自分で全てをやろうとしても、使える時間や能力の限界などの制約があるため、上手く人を頼ることが重要です。
自分でアクションを取るのが難しかったりリスクがあったりする場合、以下のような手段を使うことで、より安全にアクションを進めることができます。
- 自分より適切なメンバーに一任する
- 自分でとろうとしているアクションを、より知見のあるメンバーに共有し、進め方に関してフィードバックしてもらう
この項目は、例えば以下のようなアクションが該当します。
緊急度の高いホットフィックスリリースを実施しようとしている。
リリース手順は自分でも理解していたが、もし手順の不備で失敗した際のリスクが大きい。
そのため、他メンバーにもリリース手順をレビューしてもらい、不備がないかを念の為確認した。
5-2. 自分でやる
1 人でやるのと、分担してやるのとでは、コミュニケーションコストの違いがあります。
1 人でやるとコミュニケーションコストがかからないため、効率的に進めることができます。
例えば、以下のように工夫するアクションが該当します。
他チームからの仕様確認があった。
以前調査したドキュメントを元に自分だけで回答を十分に作成できたので、チームメンバーには相談せずに打ち返した。
5-3. スピードを保つ
決断や合意形成のスピードが鈍化すると、それを元に動くメンバー全員のスピードが遅くなるため、スピード感を持つことが重要です。
こうした機会では、広く浅く考えることでスピードを保つ意識が重要になってきます。
例えば、以下のようなアクションが該当します。
会議で選択肢 A と選択肢 B のどちらかを決める必要があった。
各選択肢のメリット・デメリットを抽象的なレベルで議論し、あえて具体的な技術や実装には踏み込まないようにした。
これにより、会議での議論がスムーズに進み、選択肢 A を採用することにした。
上記のように、決断や合意形成は会議で行うことが多いです。
会議の場で決められることは決め、持ち帰ってタスクを溜め込まないようにすることが重要です。
最後に
価値提供にコミットするプロジェクトマネージャーの理想形は、さまざまなものがあると考えています。
そのうちの 1 つの形を、自分なりに解釈し、整理してみました。
本記事でまとめた内容は、私自身の今後のプロジェクトでの動きや考えに活かしていきたいと考えています。
Discussion