JQに入社後、私はクレジットカード会社の案件に携わることになりました。
オンプレからクラウドへのシステム移行という大きなプロジェクトで、全体PMOとして進捗管理と課題管理を任されました。
参画したてで、案件の内容や実態についてもわからないことが多く、PMOとしてどう振る舞うべきかも自信が持てない状況でした。
例えば、課題管理業務においては、
「これは課題として起票するべきなのか？」
「まだ整理できていないのに出していいのか？」
「PMOとして的外れなことを言っていないか？」
と迷い、結果として課題を起票できないことが続きました。
QAや課題管理は起票のハードルが高く、曖昧な状態では扱いづらいと感じていました。
そんな中、先輩が「もやもやリスト」を作り、毎日の内部定例でモヤモヤを解消する場を設けてくれました。
そこでは不明点だけでなく、案件を進める上での改善提案や要望を書くことができ、非常に扱いやすいと感じました。
課題は整理されてから起票するものだと思っていた
それまで私は、QAや課題管理に対して
「ある程度整理され、影響範囲や対応方針が明確になってから起票するもの」
というイメージを持っていました。曖昧な状態で出すのはよくない、という感覚がありました。
起票のハードルが高いと感じていた理由は、他にもありました。
影響度や優先度を書かなければいけない、誰が対応するかを明確にする必要がある、事実と推測を分けて整理する必要がある—まだ全体像も理解できていない中で、そこまで言語化するのは難しいと感じていました。
また、「的外れだったらどうしよう」という不安もありました。
もやもやリストを知る前、不明点や違和感は自分の中で整理しようとしていました。
あるいは、個別に先輩へ確認することもありましたが、「このレベルで聞いていいのか」と迷うことも多く、結果的に抱え込むこともありました。
不明点が蓄積していく感覚がありました。
小さな違和感がそのまま残り、モヤモヤが増えていく状態でした。
また、PMOとしてどこまで踏み込んでよいのか分からず、動きが慎重になりすぎていました。
「いきなり課題にしなくていい、まずはもやもやで出そう」
先輩は、もやもやリストを導入するとき、こう説明してくれました。
「いきなり課題にしなくていい。まずはもやもやで出そう」
「整理はみんなで一緒にやればいい」
さらに、「たくさん質問する人ほど成長が早い」とも言われました。
だからこそ、曖昧な状態でも出せる「もやもやリスト」が必要だと。
正直、安心しました。
それまでは、「的外れだったらどうしよう」「レベルが低い質問だったらどうしよう」と考えて、慎重になりすぎていました。
でも、「質問すること自体が成長につながる」と言われて、出さないことのほうがリスクなのだと気づきました。
先輩は、もやもやリストの重要性について、こう語ってくれました。
「違和感は早いほうが価値がある」「出さない情報が一番怖い」
小さなもやもやが、後から大きな課題になることもある。
だからこそ、精度よりもスピード。その言葉が印象に残っています。
さらに、先輩はもやもやリストと課題管理の違いについても説明してくれました。
課題管理は「解決する」ための仕組み。もやもやリストは「発見する」ための仕組み。
このシンプルな言葉が、私の中で大きな気づきとなりました。
芽の段階で気づきを共有することの意味
もやもやリストを使い始めて、最初に書いたのは「各チームの進捗・TODO管理の基準がそろっていないのでは？」という違和感でした。
問題だと言い切れない違和感でしたが、出してみると基準が明文化されていないことが分かり、すり合わせのきっかけになりました。
課題にする前の「芽」を扱うことの意味を実感しました。
最初は正直、戸惑いがありました。
任されたばかりで全体も見えていない中で、これを出していいのかと迷いました。
でも「いきなり課題にしなくていい、まずはもやもやで出そう」という言葉を思い出し、正解でなくていいから出してみようと思いました。
内部定例では、否定されることはなく、「それはどんな基準？」と一緒に整理してもらえる雰囲気でした。
もやもやを出すようになってから、問題を探すというより、違和感に気づいたら早めに言語化する意識に変わりました。不安を抱え込むことも減りました。
未整理の情報を可視化し、チーム内で早期に認識を揃える
今の私にとって、もやもやリストは「まだ課題と断定できない違和感を外に出すための仕組み」だと考えています。
問題が起きてから整理するのではなく、芽の段階で気づきを共有することで、後の大きな手戻りを防ぐ役割を持っていると理解しています。
プロジェクトでは「明確な課題」ばかりが管理対象になりがちですが、実際には曖昧な違和感の中にリスクの兆候が潜んでいることが多いと感じました。
もやもやリストは、そうした未整理の情報を可視化し、チーム内で早期に認識を揃えることで、リスク管理や認識ズレの防止に繋がる仕組みだと考えています。
この考え方はプロジェクト管理だけでなく、コミュニケーションや日々の業務整理にも応用できると感じています。
例えば、会議で感じた小さな違和感や説明しにくい不安も、一度言語化することで思考が整理され、次の行動が明確になると実感しました。
現在も「違和感に気づいたらその日のうちに言語化する」ことを意識しています。
完成された意見を出そうとするのではなく、未整理でも早く共有することで、チーム全体の認識合わせに貢献できると考えています。
未整理でも早く出すことで、チームの思考材料になる
入社してまだ1ヶ月ほどですが、先輩から学ぶことの多さに驚いています。
「もやもやリストの運用」という一つの学びから、プロジェクトマネジメント全体に通じる考え方を教わりました。
特に大切にしたいのは、「完成された意見を出そうとしすぎないこと」です。
未整理でも早く出すことで、チームの思考材料になる。その価値を忘れずにいたいです。
これからも、先輩の背中を見ながら、一つ一つ学んでいきたいと思います。
新人や若手PMOの方には、「質問することや違和感を出すことは、成長の近道になる」と伝えたいです。
完成された意見でなくてもいい。まずは出してみる。
その積み重ねが、自分の視点を広げ、プロジェクトを見る解像度を上げてくれると感じています。
