はじめに
はじめまして、リンクアンドモチベーションでプロダクトマネージャーを行っている原田です。
主に担当させていただいているのは、弊社サービスであるモチベーションクラウドの「新規顧客の獲得」をミッションとした開発組織です。
（具体的な業務は、過去に弊社野田が投稿したこちらの記事をご覧ください！！)
本記事では、私が所属しているチームが「タスク志向」から「ミッション志向」になるまでの道筋をご説明いたします。
そもそもの組織の変わるきっかけ
モチベーションクラウドシリーズの開発組織は昨年の夏に、大きな組織編成が行われ、
これまでは「PJT単位でチーム編成が変わる」組織だったところから、「ミッション別でチーム編成が固定される」組織へと変わりました。
（詳しくは、過去に弊社有田が投稿したこちら記事をご覧ください！）
それにより、これまでは「PJTの成功（リリース）のために頑張る」であったり、短い期間の即興チームであったため「チームワークを意識する」より「個人のタスクを早く終わらす」＝「タスク志向」であった開発チームが、「ミッションの実現のためにチームで頑張る」＝「ミッション志向」という状態を求められるようになったのです。
顧客志向になったことによる変化
組織改編が行われ約１年の月日が流れましたが、そのなかで「ミッション志向組織」への変化を遂げていくにあたり、組織の状態としては大きく以下のような変化が見られました。
チーム内での動き方や、各人への働きかけ方、そしてなにより「自分たちの仕事への誇り」が格段にレベルアップしたことが、組織の性質変化によってもたらされた最大の効果だったなと思います。また、チームの中でのコミュニケーションも「何したらいいですか」といったタスクに関する会話から「新規顧客のために解決すべき課題は何か」といったミッションに関する問いがでるようになったのも大きな変化の一つだと思います。
組織改編に伴っておこなったこと
では、実際にどのように変化してきたのか？組織の形が変わったと言えど、これまで培ってきた「習慣・文化」をいきなり変えることは難しいです。ここでは、私自身が所属しているチームが「ミッション志向組織」に変わっていくまでに行ったことをステップごとに紹介していければと思います。
STEP１：個人志向からチーム志向へ
まず、最初に行ったことは「エンジニアへのプロジェクトマネジメント業務の移管」でした。
これまでは、「PJT単位で短期的なチームを結成」という文化から、エンジニアも含めて全員でワンチームというのがなかなか成り立っていませんでした。
「チェスター・バーナードの組織の成立要件」によると、『組織（チーム）が成立するためには「共通の目的・協働意志・コミュニケーション」が必要である』。これに沿って考えると、「共通の目的」がそもそもエンジニアの中で存在していないという状況だったわけです。
そこでまずは、プロジェクトマネジメントの責任をエンジニア側に移管することで、「プロジェクトを成功させる」という１つの目標をエンジニア側に立て、エンジニアチーム内に「共通の目的」を作ったのがSTEP１です。
STEP２：受発注志向から協働志向へ
エンジニア側がチームになってくると次のSTEPです。それは、プロダクトマネージャーとエンジニアとの「協働意志」を紡いでいく、ことです。過去の組織体制やPJTの性質から、プロダクトマネージャーとエンジニアはどうしても「受発注関係(対立構造)」になりがちでした。（責任はプロダクトマネージャー、エンジニアはプロダクトマネージャーからもらうお仕事をする）
ですが、これまでと違い、チームメンバーが変わることもあまりなく、１つのミッションの実現のため、職種間を超えて協働していくことが必要となりました。
そこで、「機能の仕様検討」の責任をプロダクトマネージャーからエンジニアへ移管する、を行いました。そのため、これまでの体制上仕方なくウォーターフォール的にプロダクトマネージャーが仕様を考え、それをエンジニアにバトンを渡すという形式を取っていましたが、組織改編をきっかけに、アジャイル的な開発の進め方に変更をし、その中で仕様の検討をエンジニアに責任を持ってもらう体制に変更しました。これにより、プロダクトマネージャーとエンジニアの関係性を「協働志向」へとシフトすることに成功しました。
STEP３：How志向からWhat志向へ
さて、STEP２までの道のりがとても大変でしたが、STEP２までくると、かなりチームとしてまとまりが出てきます。ここからは、ワンチームになっている組織が「どの基準で束ねられている」組織か、という組織のレベルアップの話になってきます。「ISSUEからはじめよ」という書籍でも示されている通り、大切なのは「どのように解決するか」ではなく「どの課題を解決するのか」という課題立脚で思考できることが開発においても重要になってきます。
そこで、チームが意識する観点の水準を上げパフォーマンス向上を目指し、How（どのように作るのか）＝＞What（何を作るのか）＝＞Why（なぜ作るのか）という意識する水準を一段ずつあげていくことにしました。
まずは、How（どのように作るか）からWhat（何を作るか）というところに水準を上げるために、要件定義の場にエンジニアにも入ってもらい、What（何を作るか）を議論する機会を増やしました。これにより、エンジニアがこれまで「プロダクトマネージャーが考えた機能を作る人」から「プロダクトマネージャーと一緒に何を作るか、から考える人」になっていったわけです。ここらへんからチーム全体として「解決策ドリブン」なチームから「イシュードリブン」なチームへと進化していきました。
STEP４：What志向からWhy志向へ
そして、最後はWhat（なにを作るか）＝＞Why（なぜ作るか）への水準を上げることですが、実際に行ったことは①営業への同行②開発のアウトカムの設定をプロダクトマネージャーとともに行う、の２点を行いました。
①は、実際の顧客の声や顧客のリアルを体験することで、自分たちがとくべき課題は何なのか？をイメージしやすくすることが目的です。（この開発は、誰のどのような課題を解決するのか、のイメージング）
②は、自分たちが解決したい課題を解決するということはどのような状態になっていることか、を考えることでその後の要件検討や開発において、課題解決の当事者の意識を芽生させることが目的でした。
これらの活動を通して、私が所属しているチームは「タスク志向」だったところから「ミッション志向」なチームへと進化を遂げていくことができました。
おわりに
最後まで読んでくださりありがとうございます。
書いていることは随所随所省いて要点だけをまとめていますが、ここまでくるのには、本当に多くの課題や挫折がありました。ですが、チームとしてここまで来れたのは紛れもなく、チーム全員の成長意欲や、チャレンジ精神に支えられたものです。（ここまで一緒に戦ってくれたチームの皆さんには感謝しかありません。）
組織やチームにおける葛藤は数々あるとおもいますが、皆様が抱える葛藤の解決に少しでもお力添えができていれば幸いです。
