エンジニアがビジネスチームを加速させる為に取り組んだ4つのアプローチ
Posted on
はじめまして。100kmマラソンの持ちタイムは9時間48分44秒、プレイドの @y-meguro です。
今回はエンジニアである私がビジネスチームに加わって、チームリーディングに取り組んだ話を書いてみます。
開発チームにビジネスメンバーが加わったり、エンジニア視点でビジネスを考えたりすることはあるかと思いますが、効果的なチームリーディングを行うために、エンジニアがビジネスチームに入ることはあまりないのではないでしょうか。
エンジニア的な思考を使って、どうチームリーディングすることが効果的なのか。今回は私が取り組んだいくつかの試みの中から、特に効果が高かった4つのアプローチを紹介させていただきます。
はじめに
いきなりアプローチを記載しても、イメージが伝わりにくいかと思うので、最初にどのようなミッションを掲げて、どのようなチームで取り組んでいたか、書いておきます。
ミッション
ミッションは「3ヶ月間で弊社サービスであるKARTEのオンボーディングプログラムを作り上げる」というものでした。
なかでも重要な課題であったのは、オンライン動画コンテンツの作成です。全部で6時間程度の学習動画をどう作っていくか。社内でも特に知見がない状態であったため、ゼロからのスタートとなりました。
チーム
チームは私を含めて5名。私以外はビジネスメンバーで、セミナー経験が豊富な方や、カスタマーサポートに知識の深い方たち。ただし、既存のお客様対応やセミナー対応もあるため、100%の時間をこのチームに使えるというわけではなく、60〜80%のリソースを当てられる、というような状態でした。
今回私がこのチームに加わることになったのは、お客様の知識が深いビジネスメンバーの知見と、私が持つエンジニアリングの知識を掛け合わせることで、より良いプログラムを作成できるのではないか、という組織としてのトライがありました。
結果
結果的に、3ヶ月間で無事に計6時間におよぶ動画コンテンツを作成し終わり、動画コンテンツ以外も含めて、無事に新しいオンボーディングプログラムをスタートさせることができました。早速新しいプログラムを褒めてくださるお客様もおり、動画コンテンツだけでも作り終わらないかも…という当初の周囲の期待値を考えると、良い結果を出せたなと自信を持って言えます。
では早速、特に効果的だったアプローチを紹介していきます。
1. OODAを意識し、現場をよく見て、真の課題を発見する
OODAとは、John Boydによって提唱された、不確実で混沌とした環境で勝利を手にするための戦略理論です。
- Observe（観察する）
- Orient（方向づける）
- Decide（決定する）
- Act（行動する）
の頭文字を取ったもので、これらの4プロセスからなります。
ポイントは現場をよく観察することです。何か良い手法を知っていても、手法を適用することが目的になってしまうと、本末転倒です。
特にこれまで馴染みの少ない課題に取り組む場合や、はじめて一緒に働くメンバーがいる場合は、自分に見えていない課題があったり、自分が勝手に想定した課題があるように感じてしまったりすることが往々にしてあります。
まず観察からはじめることで、正しく課題を捉えることが大切です。
今回の場合は、はじめて働くメンバーが多かったため、1人1人のことをよく見るように注意しました。
- 何か困っていないか
- どういう考え方をするか
- チームに活かせる強みはどこか
- どうすれば成長するか
- どうすれば進捗が上がるか
といったところです。1人1人をよく見て、課題をできるだけ明確に捉えることで、方向づける際に、より良い選択肢を持つことができました。
また、この後に記載している各アプローチについても、手法ファーストで考えたわけではなく、課題ファーストで考え、各課題にふさわしいアプローチを選択したことで、良い結果を得ることができたと考えています。
2. 変化に適応できるスケジュールを設計する
次がスケジュール設計です。私たちには2つの不安がありました。
1つはどのような動画コンテンツを作ればいいのかわからない、という不安です。そしてもう1つはどう作っていくのが効率的かわからない、という不安です。
エンジニアリング組織論への招待では、これを「目的不確実性」・「方法不確実性」と呼び、両方を構成する大きな不確実性から優先的に対応するアジャイル型の開発が紹介されています。
私たちのチームでも、アジャイル型のコンテンツ作成を行うべく、MVP（Minimum Viable Product）を意識したスケジュール設計を行いました。複数のループを設定し、最短の時間で、その時点で最も大事なことを検証していく、というやり方です。
今回の場合のポイントは
- 次のループで何を検証するか、正しく優先順位をつけること
- 検証すべきことが検証できるように、アウトプットのイメージを正確に共有すること
です。
特に新しいチームの場合は、イメージを共有できていると思っていても、ずれが生じやすいので注意が必要でした。
- 前提・背景が違ってずれる
- 同じ言葉を使っていても、具体的なイメージが違ってずれる
- ずれている可能性があるのに、確認を怠ってずれる
といったことがあるので、チーム結成当初はしつこいくらいに確認するのがちょうどいいかなと思っています。
3. 透明性を高め、全員で問題を考える
スクラムには「透明性」という理論があります。スクラムガイドでも
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
例：
• プロセスの用語を参加者全員で共有している。
• 作業をする人とその作成物を受け取る人が「完成」の定義を共有している。
と書かれています。
私たちのチームに当てはめると、いまチームがどういう状況にあって、どういう問題を抱えているか、全員で共通認識を持つことが必要となります。
全体スケジュールを見える化し、定期的に更新して共有することで、チームの状況を正確に把握できるように意識しました。
また、チーム内で情報の置き場が整理されていなかったり、情報をオープンにする意識が低かったりすると、情報の非対称性が生まれてしまいます。こうした問題が発生しないよう、常に情報が整理された状態となるよう、ガイドを作成し、チェックすることも意識しました。
副次的な効果として、チーム外に対しても情報がオープンになり、必要な情報に対してアクセスしやすい環境が作れました。その結果、他チームへの説明コストが下がったり、関係するチームから意見をもらったりしやすくなるといったこともありました。
4. リズムを作りながら、正しく検査する
3でスクラムの「透明性」について書きましたが、「検査」では以下のようなことが書かれています。
スクラムのユーザーは、スクラムの作成物や進捗を頻繁に検査し、変化を検知する。ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。熟練の検査人が念入りに行えば、検査は最大の効果をもたらす。
またスクラムでは、「デイリースクラム」が設定されています。スクラムガイドによると、
デイリースクラムとは、開発チームが活動の速度を合わせ、次の24時間の計画を作る15分間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。
デイリースクラムは毎日、同じ時間・場所で開催する。これは、複雑にならないようにするためである。デイリースクラムでは、開発チームのメンバーが以下のことを説明する。
• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
• 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか？
と書かれています。
私たちのチームの場合、エンジニアと異なり、以下のようなことがリズムを阻害します。
- お客様との打ち合わせ・提案があることにより、同じ時間に同じ作業をすることが難しい
- セミナー講師を担当するため、同じ時間に同じ作業をすることが難しい
また、日ごとでチームのタスクに割ける時間が異なるため、ある量のタスクをこなしていても、以下のどちらに当てはまるのか検査が難しい、という問題がありました。
- 少ない時間の中でそれを達成できたのか
- 時間はたくさんあったが何か困難があって、その進捗になっているのか
これらの課題に対し、チームのリズムを作りながら、問題を素早く発見するために、私たちはDaily Mtgを行っていました。
特に午前中は同じ時間に集まることが難しかったため、時間は夜の18時半から。リモートでの参加も可能にしました。
また、毎日の検査を適切なものにするため、毎朝GitHubのissueに、その日やることと、何時間取れそうなのか、宣言してもらう形式としました。
※ 弊社はエンジニア以外もGitHubを活用しています。詳細はこちら
ここでのポイントは、「検査」という言葉を使っていますが、監視されているような雰囲気をチーム内に作らないことです。あくまでチームとして助けあうために宣言してもらうことを、繰り返し強調しました。そして目標を達成できた時は、全員で祝福することが大切です。
また、ただの進捗報告会にならないよう、困っていることを相談できる雰囲気を作り、まだ発見されていない問題をいち早く発見できるように気をつけていました。
考察
ここまで効果的だったアプローチを紹介しましたが、なぜうまくいったのか、特に影響したと感じる考え方・要因を2つあげてみます。
チームビルディングファーストではなく、パフォーマンスファースト
今回私はあまりチームビルディングすることは意識していなかったのですが、私自身も含めてチームの成長を強く感じることができました。もちろん「いいチームである」から「パフォーマンスが高い」のですが、それと同時に「パフォーマンスが高い」ことで、余裕と心理的安全性が生まれ、学びが多くなり、モチベーションがあがって「いいチームになる」のではないかと思います。上記の4つも、チームビルディングのためではなく、パフォーマンスを高めるためのアプローチであったことが、結果的に良かったと感じています。
鶏と卵のようなもので、どちらが先とはっきり決まるものではないかもしれませんが、今回の場合はパフォーマンスを高めることから始めるという考え方が、有効であったと感じています。
素直さという価値
今回の記事では、私がチームリーディングをする際に効果的だったアプローチを紹介させていただきましたが、それと同時に、私自身も他のチームメンバーにリードされることで、このようなアプローチにたどり着くことができたと考えています。
特に私をモチベートしてくれたのはチームメンバーの「素直さ」です。何かを伝えれば、しっかりと受け止めてくれる。この素直さへの感動が、もっとこのチームに貢献したい、という強い思いに繋がったのだと感じています。
今後の展望
ビジネスチームに入っていた3ヶ月が終わり、現在私は開発チームで働いています。今回の学びをどう開発チームで活かすか、2点考えています。
「当たり前」を疑うことで、正しい課題を見つけに行く
今回が、私にとってはじめてのビジネスチームであったため、良くも悪くもゼロベースで全ての観察を行うことができました。ただ、これまでの自分を振り返ってみると、開発チームという慣れた環境にいたことで、知らず知らずのうちに「当たり前」と感じて、見逃してしまっていた課題があったのではないかと思います。
どんな環境においても、自分の認知が偏っていないか注意し、正しい課題を見つけられるように注意したいと思います。
誰も見つけていない課題を見つけにいこう
もう1つ、私にとって発見だったのは、チームの中で誰も見つけていない課題を見つけると、チームのパフォーマンス向上に大きく貢献できるということです。ビジネスチームの中ではバックグラウンドが違ったことで、自然と自分が早く見つけられる課題があったのですが、開発チームに戻っても、この意識は常に忘れたくないなと感じました。
注意深く観察することはもちろんですが、意識的に視点を逆に振ることで、見落としてしまっている課題がないか意識しようと思います。
おわりに
エンジニアがビジネスチームにいることで、バグを見つけた時にすぐ直せる、生のデータをすぐに取得して分析できる、といった強みはもちろんあるのですが、今回の記事ではチームリーディングに焦点を当てて、私が貢献できた4つのアプローチを記載してみました。
たった3ヶ月という期間でしたが、エンジニアである私にとって、ビジネスチームに入って、ビジネスメンバーと一緒に働くということはとても大きなチャレンジでした。
自分と異なるバックグラウンドを持つメンバーと働くことで、学びや発見も多く、自分自身もとても成長できた期間であったと思います。
なかなかエンジニアがビジネスチームに入る機会は少ないかと思いますが、課題と真摯に向き合い、自分の持てる知識を最大限に使うことで、周囲の期待を超えるようなパフォーマンスを出せたのかなと感じます。
もし、同じような立場を経験される方がいた時、この記事が少しでも参考になれば幸いです。
参考文献
- アジャイルソフトウェア開発宣言
- アジャイル宣言の背後にある原則
- スクラムガイド
- エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング
- リーン開発の本質
- SCRUM BOOT CAMP THE BOOK
仲間を募集しています
CX（顧客体験）プラットフォーム「KARTE」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。
詳しくは弊社採用ページまたはWantedlyをご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！