YOJOエンジニア組織が求めるマインドをまとめてみた

開発のbonです。

私が5人目の社員として入社したことで、エンジニアメンバーも徐々に増えきたのと同時に会社のフェーズも少しずつ大きくなってきていました。社内で一緒に働くメンバーとスクラムをやったり、採用活動や面談などを通じて色々な方とお話をしたり、選考させていただきました。

その過程でYOJOのエンジニアがどういう観点で働いているのか、何に重きを置いているのかを言語化することが難しいなと感じることがあり、再度エンジニア全体で認識を合わせておこうということで2021/11くらいに簡単なワークショップをやってみました。

目次

1. 最初に結論
2. ワークショップを開くうえで気をつけたこと
3. ①開催日
4. ②目的とやりたいことの明確化
5. ③ツール選定
6. 結果
7. ①Start With Me （まずはエゴからはじめよ）
8. ②Learning Monsters（狂ったように学べ）
9. ③Best Practice Company（ベスト・プラクティスを妥協しない）
10. ④Hyper Ultra Psychological Safety（心理的安全性の向こう側のその先へ）

すべて表示

最初に結論

まず最初に結論を記載しておきます。

・ワークを通してエンジニアチームが求める仲間の価値観が共通認識になった・採用にも活用できそう・患者満足度世界一を本気で考えているからこそのマインドが出てきた

採用面でもさることながら、弊社の掲げるミッションである患者満足度世界一を目指し、一致団結する形で認識を揃えることができたのはとても良かったなと思います。

ワークショップを開くうえで気をつけたこと

①開催日

1〜2時間でできるだけ意見が言いやすいような環境と時間帯を選択しました。例えば夕方であれば、ワークショップが終わったらそのまま仕事を終えることもできますし、お酒やおつまみも用意できるかもしれません。お昼であればランチしながら実施できます。

②目的とやりたいことの明確化

目的を明確にするためにワークショップを開始する前にミーティングのカレンダーやメールなどに目的と背景を書きます。準備不足でもこれだけは書いておくことで、「目的が分からないので説明してください」という状況になってワークショップに使う時間が減ることを極力防ぐことができます。念の為ワークショップ内でも目的の説明は実施します。

③ツール選定

ノート1本(スプレッドシートやBoxNote、Notionなど)で文章管理するのも良いのですが、ブレストや意見集めはMiroやFigjamのような付せんボードが役立ちます。なぜなら、共同編集が簡単ですし、色や枠、オブジェクトなどを活用することでカテゴリ分けや投票管理など簡単に行なえます。以下に我々が利用したFigjamのボードの例を載せます。

結果

ブレストして意見を出し合った結果、いくつかの候補が出てきました。後はそれに対して良い感じにキャッチーな言語化をするかです。これも別途エンジニアメンバーでブレストして投票しました。その結果がこちらです。

Start With Me （まずはエゴからはじめよ）- 自分の感性に従う- 自分→チーム→患者→社会へと伝播させる- 前人未踏の地をゆくLearning Monsters（狂ったように学べ）- 広く見渡し深く潜る- チームで学ぶ- 発信モンスターになるBest Practice Company（ベスト・プラクティスを妥協しない）- ベスト・プラクティスを選択する- ベスト・プラクティスを進化させる- ベスト・プラクティスを生み出すHyper Ultra Psychological Safety（心理的安全性の向こう側のその先へ）- 隣人を成功させる- 凸凹を愛する- チームを楽しむ

エモいワードが揃っているのは、それくらい飛び抜けたワードでないと覚えないでしょという表れです。文化や言語化はやったら終わりではなく、それを行動や態度、言動で示し続け組織に浸透させることのほうが重要ですよね。

以下よりそれぞれの項目について少し詳細に説明します。

①Start With Me （まずはエゴからはじめよ）

エゴという言葉からは利己的で自己中のような印象を受けがちですが、要するに自分の信念や信条に従った行動や態度にまずは軸を置いてみてもいいんじゃないか？ということです。「先ず隗より始めよ」が元ネタですね。
YOJOのエンジニアとしては、自分の軸を持ったうえでそれに自信や確信を肉付けしながら、7つの習慣にある「影響の輪」を大きくしていくことを推奨しているということになります。

②Learning Monsters（狂ったように学べ）

学ぶというのは例えば本を読む、勉強するという行為もありますが、弊社の場合それにとどまらず、実践する、挑戦するという点も含まれています。弊社のバリューでもある「智を創発する」に代表されるように自分の専門領域の知識をインプットし、それをアウトプットして周りに影響を与えていくというところを推進していこうという思いが込められています。(この記事もアウトプットの1つです)

③Best Practice Company（ベスト・プラクティスを妥協しない）

この言葉は個人的に少し思い入れがあって、私が新卒のときに働いていた会社で私が同僚に言い放った言葉が採用されました(笑) 実際、答えのない問題や課題って仕事を通じてたくさんあると思います。ただその中でも自分がその時点でベストだと思う答えを引っ張り出すなり考えつくなり行動するなりすることが、結果自分の成長とプロジェクトの成功につながっていくのではないかと思います。そして、それを真似た他のメンバーもまた同じように成長していくことでしょう。

私の場合は妥協せず頑張った結果、再利用しづらいRubyスクリプトを書いてしまったがために、本番のイレギュラーデータに対応できずその場で色々と書き直すハメになりました。ただ、その失敗を今でも覚えているのと、2度同じ失敗はしないぞという決意ができましたので良い失敗だったなと胸を張って言えますね。(その後2度同じ失敗をしてしまいましたが)

④Hyper Ultra Psychological Safety（心理的安全性の向こう側のその先へ）

こちらはここまでの3つで真面目にやりすぎてネタに走った標語です。小学生くらいにヒーローや戦隊モノが好きだった人は誰でも考えるのではないかと思いますが、最強の必殺技につける名前(エターナルフォースブリザード)みたいなやつです。

心理的安全性を確保することが組織の成長やイノベーション創出につながるというのはいろんなところで言われているとおりだと思いますが、結局成長やイノベーションの過程には必ず大小様々な衝突が発生します。率直なフィードバックもあるでしょうし、辛辣な批判も受け入れる必要があるでしょう。

それらはすべてチームのため、愛情の裏返しであることを認めつつ、それを楽しむくらいの気持ちで皆で頑張ろうということをこの言葉は示しています。

やってみた感想

こういう開発やプロダクトとは直結しないワークショップを時間をとってやる際に、メンバーから「何のためにやるんですか」とか「意味があるんですか」という言葉が挙がってくるときがあります。私も経験があります。これがなぜ起きるのかというと、一番はやはり信頼関係の差だと思います。

メンバーからの信頼度の高い場合「やるよ！」というと、案外他人は面白そうだとか何か意味があるに違いないと感じるのですが、信頼度が低い場合は最初に疑問や不安がくるのは必然です。個人的にはこういうワークをするときは権力のある人を巻き込むとか、すでに信頼を得ている人をフロントに立て自分は裏から支援するという方針だとうまくいきやすいと思います。これが本当に良いソリューションなのかはともかくですが。

また、普段あまり会話しないメンバーや社歴の違うメンバーで違った組織の見方や捉え方をしていることもあるので、ワークショップをすることで埋められるところは出てきます。新規メンバーが参入する度に形や体裁は異なるにしても、このようなワークショップで親睦を深める・価値観を合わせるのはアリだなと思いました。

ただ、成長期のフェーズでワークショップを毎回やっていると、初期からいたメンバーは「またやるの？」とか「声掛けだけでなんとかなるんじゃない？」とか発生するだろうなと想定できます。そういう側面から発生するのが「文化は暗黙知として引き継がれていく」というところかなと個人的には考えてます。

つまり、普段の行動や態度で上述した4つのマインドが体現される状態であれば、小さなワークショップを開くだけであとは「他のエンジニアに従ってくれたらOKですよ」って言えるようになるわけです。 いろんな書籍や勉強会は、ここに至るまでのフローを省略して結果論だけのベストプラクティスを提案しているだけに過ぎず、その過程での苦労や困難は自分達で乗り越え、形にしていくんだっていう最も重要な部分は意外と語られていないよなーと感じています。多分語れないからでしょうけど……。

このワークショップを経て、弊社ではどういう変化が起きるかなーと楽しみです。語れるような状況になれば、その際は別に記事を書こうと思います。

最後に、決まったYOJOエンジニアチームのCultureは以下にまとまってますので是非一読ください。

これからも患者満足度世界一を目指して良いエンジニアリング組織になっていけるような仕組み作り、文化作りをやっていきます！