チームが自走するためにやったことの備忘録

はじめに

事業会社に転職しました。一応デザイナーという職種なんですが、いわゆるデザインっぽい作業は3日しかやってません笑
入社して約3週間駆け抜けてきたので、自分自身の振り返りも兼ねてチームが自走するために行ったことを備忘録としてまとめます。何かのお役に立てれば幸いです。

1. ＜下地＞納得感と期待感をつくる

私が入社して少し経って着手したのがCSチームが使う管理画面のリニューアルでした。
私が入社した時点で、すでにリニューアル計画は半年ほど続いており、その中で度重なる方向転換を重ね、エンジニアは疲弊していました。（ちなみに私が入社するまでデザイナーは0人でした）
「どうせリリースはまた遅れる...」「どうせまた要望が無視されるんだろう...」そんな閉塞感からエンジニアチームとCSチームとのコミュニケーションはほぼ断絶されていました。

私は今回のリニューアルを死ぬ気で成功させなければならないとその時覚悟しました。なぜならエンジニアチームとCSチームの「どうせ」が本当になってしまったら、今後の人生に「どうせ」がつきまとい、本人と組織の成長を止めてしまいます。短期的には、思考停止し工夫することをやめ、生産性が下がってしまいます。（これは自分の経験からの考察です）
今の組織に必要なのは成功体験であり、それだけを考える人になろうと思いました。

要件やワイヤーフレームを整理して進めようと思っていましたが、何よりこの閉塞感を打破しなければいけないと思い、まずエンジニアチームとCSチームの情報格差をなくす会を開きました。
CSチームは業務フローや改善要望を発表し、エンジニアチームは現状開発しているものを共有しました。その後もCSチームやエンジニアチームの時間を奪うことを覚悟の上、対面のMTGの時間を増やし、合意形成を目的としたMTGを継続的に行いました。

文章のコミュニケーション（Slack、メールなど）に比べて、対面のMTGは相手の時間を拘束し、文章による再利用性の恩恵も受けませんが、表情や声のトーンなど得られる情報が多いため、少し言いにくいことも伝えやすかったり、合意形成において有効でした。
「思っていたことを言える」「経緯が共有される」場を作ることで、自身の納得感や期待感に繋がり、「どうせ」から「もしかしたら」に変えることの一歩になったと思います。（具体的な指標はありません、まだ検証中です）
その後発散した情報から、そもそもの目的やリニューアルコンセプトを簡単にまとめ、CSチームとエンジニアチームとの合流点として、毎回のMTGで共有するようにしました。

またMTGの納得感と期待感を上げるために、
MTGの目標を達成したら「いや〜参考になりました！めちゃくちゃいいものになりそうです！」と言い、
未達成なら「いや〜すみません、どこらへんを改善すれば良かったですかね？」とMTG後にヒアリングするというのもやりました。（すごく地味です）

2. 早く並列化できる点をつくる

1週間ほどで下地段階は一旦完了し、次はいかにリリースまでのスピードを上げるかを考えました。その中でまず最初に考えたことはエンジニアチームとCSチームとの間で依存関係があるタスクの洗い出しです。

考えてみると、今回の管理画面でどこまでできるようになるのか？が明確にならないとCSチームの方でオペレーションを変更する点が分からず、「待ち」の状態が続いてしまいます。
そうなると、管理画面の開発は完了しても、使う人のオペレーションが整わず、結局リリースできないというリスクに繋がります。
この「待ち」を解消するためには、「MUST要件の明文化」と、「WANTの優先順位 / 対応目処」が必要でした。つまり、今後の開発計画です。
上記は価値の洗い出しやユーザーストーリーマッピングという手法で行い合意しました。（詳細は割愛します）

ここで自分自身気をつけなければいけないと思ったのが、リリースを優先させるのであれば、エンジニアのリソースの確保に動いてしまいがちですが、そうなると全体としてのゴールが達成できなくなるということが往々にしてあります。
まず注目するのはゴールを達成するために依存関係がどこにあるか、また依存関係を解消するために必要なインプットを見極め、なるべく早く並列化させることが重要だと改めて気づかされました。

またエンジニア陣も今までフワフワしていたスコープが明文化され具体的な目標ができることでスピードが上がるのではないか？という仮説を立てたため、理由を説明しエンジニアチームの時間をもらい、要件に対しての見積もりを行いました。その後MUST要件とリリース後3ヶ月のプロダクトバックログを作成し、CSチームに共有し、オペレーションの変更を進めてもらいました。

こうして約2週間で、ようやくエンジニアチームとCSチームが並列化して目標に向かって走り出せるようになりました。全員で行う対面のMTGはなくし、定例MTGで進捗共有を行うようにしました。

 3.作業モードと俯瞰モードを切り替える環境をつくる

エンジニアチームとCSチームが並列化したのち、私はエンジニアのタスクの整理に取りかかりました。
今までは「◯◯周りの実装」というように、何のために作るのか、何をしたら完了なのかが分からず、タスクが膨らみ、1〜2週間「in Progress」にいるというような進捗が見えづらい状態でした。

エンジニアチームは稼働が100%の人が不在なのと、稼働する時間がバラバラなため、対面のMTGを定期的に設けるのとチームで助け合うのは難しい状況でした。
なので、なるべく他人に依存することなく自分で進められる環境を整えようと思いました。

これは個人的な考えなのですが、抽象と具体を切り替えられる環境が一番生産性が高いと思っています。
具体的なことをすることを「作業モード」、抽象的なことを考えることを「俯瞰モード」と呼ぶことにします。
作業モードの時間がないと実際の価値やアウトプットに繋がりません。また作業モードがずっと続くと視野が狭くなり、本来の目的とずれて進んでしまうリスクがあります。
作業モードと俯瞰モードを一定のリズムで切り替えられる環境があるとき、人は目標からずれることなく生産性が高い状態を維持することができると思います。

作業モードから俯瞰モードへのスイッチは、そのタスクが完了しているかを確信できたときです。「完了の定義」がないと、ダラダラと作業モードを続けることになり生産性の低い時間を長く過ごすことになります。

また俯瞰モードから作業モードへのスイッチは自分自身で「なぜやるのか？」を納得することです。自分で納得できずにモヤモヤすると作業モードに入ることができず、別のことを考えてしまったり、納得するために他の人に話を聞く必要があるなど自分以外に要因が発生してしまいます。

私が好きなジョジョの名言の中で下記のようなセリフがありますが、まさにそのとおりで、納得すれば自分を作業モードにすることができ、前に進むことに集中できます。

「納得」は全てに優先するぜッ！でないとオレは「前」へ進めねえッ「どこへ」も！「未来」への道も！探すことは出来ねえッ！

引用: ジョジョの奇妙な冒険 Part7 スティール・ボール・ラン

作業モードと俯瞰モードを一定のリズムで切り替えられる環境、かつそのスイッチを他人に依存することなく自分で入れるようにできることが今回は必要でした。

具体的にやったことは下記です。

①価値の単位で要件を切り直し、完了の定義を定めました。
②価値をなるべく1日で終えられる単位にし、なぜ作るのか？（価値）と何を作るのか？（機能）をタスクに書きました。
③テストのことを考え管理画面で完結しない機能から優先順位を高くし、エンジニアが上から開発していけばいい状況にしました。
④対面で説明する時間をとり、出た疑問点や不明点の議論をログに残しました。
⑤毎日作業予定以外に課題や不安な点をSlackに投稿してもらいました。すぐに解決できるものは解決し、解決できないものはバックログに積んでおきました。
⑥前段で決めたリニューアルの目的やコンセプト、またユーザーストーリーマッピングなど抽象的な情報にすぐアクセスできる環境を整えました。

スクラムのルールを参考に特に新しいことはしていないです。ルールに従えば自動的に作業モードと俯瞰モードが切り替えられる仕組みになっていて、改めてこの仕組みの偉大さに気付かされました。

さいごに

以上がチームが自走するためにやったことです。
特に作業モードと俯瞰モードをメンバー自身が行き来するための環境づくりがマネージャーやリーダーに求められるところだと思うので、引き続き研究を続けていきます。

今のはエンジニアチームとの話なのですが、同時にデザイナーチームにおいても下記を進めたのでどこかのタイミングでまとめられるといいなと思います。

・デザイナーチームの進捗可視化
・デザイナーの役割明文化
・役割に対しての振り返り設定

雑な文章ですみません。最後まで読んでいただき、ありがとうございました！