🤔

フロントエンドエンジニアのミッションステートメントを作成して得たチームと私の学び

2022/05/30に公開

どうも、株式会社iCAREのフロントエンドエンジニアoreoです。

先日、弊社フロントエンドエンジニアで、ミッションステートメントを作成しました。今回の記事では、具体的な作成手順を交えながら、チームと私が得た学びをご紹介させていただきます!

1 はじめに

iCAREでは、事業拡大に伴い開発部が急拡大しています。フロントエンドエンジニアでいうと、2021年4月からの1年間で、4人 → 10人と2.5倍になりました(※パートナさんを除いています)。

組織拡大に伴って、フロントエンドにおけるテスト体制構築など様々な仕組み作りが進められています。このように、長期的な目線で仕組みを考えなければならない状況下で、フロントエンドエンジニアとして何を大事にすべきか?という議論が始まり、最終的にミッションステートメントという形でまとめることとなりました。価値観を言語化することで、メンバーの方向性を合わせ、仕組みを作る上での指針を作成することができたかと思います。

フロントエンドエンジニアとして優先事項がわからない、チームの足並みが揃わない、メンバーとの会話が減ったなどの悩みがある方に、何かしらのヒントとなれば幸いです。また、この記事のようなやり方で個人のミッションステートメントを作れば、キャリアなどプライベートで悩まれている方にも参考になると思います。

2 どうやって作ったか?

2-1 概要

大きな流れとしては👇のように進めました。
メンバー全員で定期的に集まりながら、4ヶ月程度で作りました。毎回1時間の議論で、合計10回程度集まったかと思います。課題のブレストから始まり、まとめ方を模索しながら進めて行きました。

作成手順

2-2 具体的な手順

2-2-1 課題と解決策の洗い出し

基本的な考え方

ダブルダイヤモンドという考え方に則り、まずはフロントエンドの現状の課題とそれらに対する解決策を洗い出しました

ダブルダイヤモンドとは、以下のような課題解決方法の一つです。

ダブルダイヤモンドは、2005年に英国デザイン協議会で初めて導入された、2つのダイヤモンドを描くように発散と収束を行う課題解決方法のひとつ。

ダブルダイヤモンド

参照元:https://uxdaystokyo.com/articles/glossary/doublediamond/

左のダイヤでは、正しい課題を見つけるために、課題を幅広くリストアップし、その中で解決すべき課題を絞り込みます。

右側のダイヤでは、絞り込まれた課題に対しての解決策をリストアップし、その中で解決策を絞り込みます。

このようにして、2つのダイヤを描くように課題解決方法を見つける手法です。

課題の洗い出し

まず個人作業として、各メンバーで、以下5つの問に対する答えを考えました。

(1)コンポーネントを実装していて不安なところはどこか?
(2)コンポーネントを実装していて確認に手間がかかるところはどこか?
(3)ページ実装(コンポーネントの繋ぎ込み)をしていて不安なところはどこか?
(4)ページ実装(コンポーネントの繋ぎ込み)をしていて確認に手間がかかるところはどこか?
(5)過去に不具合を発生した箇所は?

個人作業の後は、全体で集まり、Google Jamboardを使いながら、各々が考えてきた答えを共有し、課題のリストアップを行いました。

ex:問(2)に対する課題感の洗い出し
課題のブレスト

その後、課題のグルーピングなどを行いながら、解決すべき課題として、以下のようにまとめました。

ex:課題のまとめ
課題のまとめ

解決策の洗い出し

続いて解決策の洗い出しです。課題の時と同じように、まず個人作業として、各メンバーで、以下の問に対する答えを考えました。

どの部分を改善したらフロントエンドエンジニアとして価値が出せるか?

個人作業の後は、全体で集まり、各々が考えてきた答えを出し合い、現状の課題に対して何ができるのかを考え、解決策を洗い出しました。

ex:解決策(以下画像の青色付箋)の洗い出し

解決策のブレスト

その後、現時点での優先順位を考え、優先的にすべき解決策にダイヤマークをつけて、まとめました。

ex:解決策の優先付け
解決策のまとめ

2-2-2 ミッションステートメントのたたき台を作成

前の作業で、現状の課題と粒度がバラバラな解決策を洗い出しました。そこから、今後の方針を文章化するために、ミッションステートメントを考えました。

基本的な考え方

洗い出した課題と解決策を元に、エレベーターピッチのような形式で、ミッションステートメントをまとめることにしました。

エレベーターピッチとは、以下のようなものです。

エレベーターピッチというのは、忙しい投資家に対して、エレベータに乗っている30秒間という短時間で起業家がプレゼンするというシーンを指しています。
30秒間という短時間にエッセンスを詰め込むからこそ、プロダクトの本質を表現した文章になるので、プロダクトのイメージを強く形付けることが出来ます。

参考:https://everyday.mof-mof.co.jp/entry/2018/02/22/122833

議論する上での状況設定

抽象的な状態だと議論が進みにくいので、より具体的なイメージと緊張感を持てるように以下のような状況を仮設定し、議論を行いました。

X年後のある日、経営陣からフロントエンドエンジニアに対して以下の告知がされます「成長を見込んで採用を行なったが想定していたバリューが出せていないようだ」「とあるフロントエンドに特化したエキスパートの集団に委託する目処が立ったので、彼らに任せようと思う」そんな状況を乗り越えて今のメンバーこそが Carely のフロントエンド開発をする集団として最適だと説得できるピッチを考えてくださいそして、それに従って日々開発することで X年後のクライシスを回避しましょう

※フィクションです

エレベーターピッチ(ミッションステートメント)を考える

以下①〜⑧の流れで、個人作業、グループ議論、全体議論を行いピッチを作り上げました。

①個人作業

テンプレートを👇として、(1)~(7)を埋める形で、まずは各個人でエレベーターピッチを考えました。各々が、弊社Purposeやこれまでの実装を振り返りながら、自分の言葉でピッチを考えました

[(1)潜在的なニーズを満たしたり、潜在的な課題を解決したり]したい、
[(2)対象顧客]向けの、
[(3)プロダクト名]というプロダクトは、
[(4)プロダクトのカテゴリー]です。
このプロダクトのフロントエンドでは、
[(5)フロント目線での重要な利点(価値)、対価に見合う説得力のある理由]ができ、
[(6)現状のフロントの課題]とは違って、
[(7)現状のフロントの課題に対して行う具体的な施策]が備わっている。

参考:https://everyday.mof-mof.co.jp/entry/2018/02/22/122833

ex:個人で考えたエレベーターピッチの例
エレベーターピッチの個人作業

②全体議論

各個人が考えてきたエレベーターピッチを発表し合い、議論しました。議論の中では、各々がそう考えた背景や各ピッチで良いと思ったこと等を話し会いました。

メンバーが考えたピッチを俯瞰すると、ポジティブな部分を増やす趣旨のもの(つまり、新しい価値を提供するもの)と、ネガティブな部分を減らす趣旨のもの(つまり、課題改善するもの)の2種類に分類することできました。そのため、それら趣旨で2種類のピッチを作り、最終化することとしました。

③グループ作業

3グループに別れて作業を行いました。グループ毎に、メンバーが考えたピッチの中から大事だなと思うところを抽出し、それらを再構成し、新しい価値を提供するピッチと課題改善するピッチの2つのピッチを作成しました。

④全体議論

グループで考えたピッチを全体で発表し、各ピッチに対して、ピッチの聞き手の立場に立って、反論意見を出し合いました

ex:反論意見の例
反対意見

⑤グループ作業

再び同じグループに別れ、④で出た反論意見に耐えるように、ピッチを修正し、ブラッシュアップしました。

⑥全体議論

各グループが考えたピッチを再度発表し、良いと思ったピッチの投票を行って、叩き台としての2つのピッチに絞り込みました。

⑦個人作業

各個人で、⑥で作成した2つのピッチを 「本当に自分達がやるべきことが、過不足なく含まれているか?」、「これを実直に実践した時にきちんと自分の目指す理想のスキルが付けられそうかどうか?」の視点で見直し、各々の言葉で個人総評を考えました

ex:個人総評の一例
個人総評

⑧全体議論

最後に、個人総評を全体で発表し合いました。それらを踏まえて、「やっぱりここは足した方がいいのでは?」、「こういう表現の方が良いのでは?」などを議論し、さらなるブラッシュアップを行いました。

2-2-3 経営層へのプレゼン

ここで、メンバーで作成した2つのピッチを経営層にプレゼンしました。経営層からは現状のフロントエンドに求めることや長期的にどのように成長してほしいか等、非常に高い視座でのフィードバックを頂き、最後のブラッシュアップを行いました。

2-2-4 完成したミッションステートメント

完成したミッションステートメント

2-3これからの方針

アクションプランの作成

現在、ミッションステートメントに則った具体的なアクションプランを洗い出しています。

ex:アクションの一例
アクションプランの例

議論の中で、「y軸:フロントの独自性」、「x軸:自動化できるのか」の四象限にアクションをプロットしながら、「ここらへんをもっと拡充して行きたいね」などと議論しながらアイディアだしを行っています。

ex:四象限の図
プロット

今後は、洗い出したアクションプランに優先度をつけ、それを実行していくことで、ミッションステートメントを実現したいと思います!

ミッションステートメントのアップデート

半年後に、作成したミッションステートメントを「実践できているか」「見直しが必要か」の視点で振り返りを行う予定です。

今回のミッションステートメントは、絶対的なものではなく、継続的に見直しを行い、その時々の状況にあった望ましいものにアップデートしていきます。

3 チームと私が学んだこと

今回、私が一連の議論の取りまとめをさせて頂きました。オンラインMTGが中心でメンバーの顔色が読み取り辛い、議論が収束しない、MTGの間が空くと前回の議論を忘れてしまう、グループワーク設計方法わからない等々、たくさんの辛みがありましたが、様々な方のお力を借りて形にすることができました。

3-1 チームの学び

個人的には、ミッションステートメントとして文章化できたことよりも、フロントエンドメンバー全員で議論し、まとめたことが、何よりも良かったです。
弊社では、機能ごとに開発チームが分かれており、コロナによるオンライン主体の勤務形態も相俟って、他チームのフロントエンドエンジニアと深く話す機会は限定的でした。しかし、この議論を通じてメンバー間での会話の機会が増え、他チームの状況や各個人の考え方などを知り、相互理解が進んだかと思います。
また、各メンバーが広い視野での課題に気づき、自分自身の価値観や弊社の方向性などを再考する良いきっかけになったかと思います。議論で上がった開発環境系の課題に対して、issueを立てて実装してくれたメンバーもおり、先んじて行動に移してくれたことは、非常に嬉しかったです。

3-2 個人の学び

また、ソフトスキル面で個人的な学びがありました。大きく括ると2つあります。
1つ目は、オンラインでのファシリテーション方法です。議題が抽象的かつ参加者が多いので、最初は、なかなか議論が盛り上がりませんでした。ファシリテーションの本を読み、大きめのリアクションを取る、全員に話題を振るなどの、工夫をすることで少しは改善できたと思います。
2つ目は、MTGやワークショップの設計方法です。MTG後に議論した内容の纏めと次回の宿題を共有する、MTG開催前には事前にアジェンダを共有する、などの細かい情報共有を徹底することで、決められた時間で議論が収まるように工夫することができました。また、ミッションステートメントを纏めるワークショプを行う際には、弊社フロントエンド技術顧問大谷さんにファシリテーションをお願いし、グループ作業や全体作業の使い分け方、時間の使い方などを学ぶことができました。
辛みが多かったですが、取りまとめを通じて、大きく成長できたかと思います。

3-3 最後に

これからが一番大変かと思いますが、ミッションステートメントを実現するために、アクションプランを運用に落とし込み、愚直に消化していきたいと思います。また、今回作ったミッションステートに固執しすぎず、柔軟にアップデートしながら、我々のプロダクトをもっともっと良くしていきたいと思います。

4 謝辞

今回のミッションステートメントを考えるに当たって、様々な方にご助言頂きました。

特に、弊社フロントエンド技術顧問の大谷さんには、議論の方向付け、ワークショップの開催方法など、終始多大なご助言を頂きました。このような形で纏めることができたのも、大谷さんのご指導のお陰です。また、視座の高いフィードバックをくださったよしさん、オギジュンさん、安田さん、事前相談に乗ってくれたいっせいさん、ジャッキーさん、巽さん、ご指摘を下さった吉川さん等々、改めてありがとうございました。

最後に、フロントエンドメンバーへ、粘り強く議論に付き合ってくれたお陰で完成することができました、本当にありがとうございます、引き続きDEV DRIVENを体現していきましょう!

5 採用情報

iCAREではエンジニア・デザイナーを絶賛募集中です!少しでも気になる方は、カジュアルにお話しできればと思いますので、是非ご連絡ください!

https://herp.careers/v1/icare/requisition-groups/a834f71a-27b8-43e6-b533-6fa4f17f48a8

Discussion