Feedforce Developer Blog

フィードフォース開発者ブログ

Feedforce のエンジニア行動指針作りをファシリテートした話

こんにちは! id:pokotyamu です。

いよいよ来週スターウォーズ最終章エピソード9が公開ですね! 自分は、19日(木)の24時スタートのチケットを取りました。あと1週間、待ちきれない!!!!

この記事は Feedforce Advent Calendar の13日目です。

adventar.org

昨日は、我がメンティーねこにしの記事でした。

note.com

1on1 の中でもこのマインドセットの片鱗を見れているので、この記事読んで涙ちょちょぎれる気持ちになりました。これから後輩もできて先輩として良いものを伝えていってほしいなと思います。

エンジニアの行動指針とは?

この Advent Calendar 10日目に id:meihong が書いたこちらの記事を読んでから、この記事は読んで頂けると! 前後編の後編みたいなものです。

damelog.com

自分はファシリテーター役として呼ばれて、 FF Engineer's Principles の作成に関わらせてもらいました。

そこで自分がどんなことをしてきたか?どんなことを意識していたか?を書いていこうと思います。 もし、うちの会社でも作ってみたいなと思った時の参考になれば幸いです。

スケジュール

今回のざっくりスケジュールはこんな感じでした。

  • 9月末にチーム発足
  • 10月活動開始
  • 12月完成予定

実質2ヶ月で作りきる必要があったため、週2ペースで MTG を行いました。 その MTG の中で行ったワークについて紹介していきます!

ワーク1(発散フェーズ)

1つ目は、「FF らしくないエンジニア」「FF らしいエンジニア」を書き出してみるです。(FF は Feedforce の略。FINAL FANTASY ではない。)

人間は否定的な意見を考える方が考えやすいので、まずは「FF らしいくないエンジニア」を考えて、次に肯定の「FF らしいエンジニア」を考えてみました。

f:id:pokotyamu:20191212190550j:plain
初回 MTG

これに関しては、開発チーム全体でやっている勉強会の時間を使って全エンジニアの協力の元でも意見を集めました。 Principles メンバーと開発チームとで大きなズレがなかったのも良かったなと思いました。

f:id:pokotyamu:20191011163218j:plainf:id:pokotyamu:20191212190643j:plain
開発チームみんなの意見も吸収

ワーク2(収束フェーズ)

2つ目は、ワーク1で出てきた意見をグルーピングし、どんなアクション(抽象的なもの)から思ったか?を出して、文章化を試みるです。

f:id:pokotyamu:20191007165736j:plain
時期尚早だった...

はっきり言って、このワークは失敗でした。 まだワーク1レベルでは、意見の深層化が出来ておらず表面的な言葉に踊らされて、どこかしっくり来ない状態になりました。 結局このワークをやったのは1回だけですぐに次のワーク3に行きました。

ワーク3(発散フェーズ)

ワーク2で問題だった抽象度の高いアクションを元にするのではなく、俺たちが称賛していきたいエンジニアってどんな人達だろうね?をより具体的に列挙していくために、3つ目のワークとして、ワーク1の「FF らしいエンジニア」で挙がったものとして実際どんな振る舞いがあったか?を出すことにしました。 フォーマットとしては以下のものを使いました。

XXXさんが、
YYYな時に、
ZZZなことをした。

FF らしいエンジニアに対する具体例なので、挙がったとしても変な空気になるものではなく、むしろ他チームのいい話をたくさん共有できた時間になりました。 エンジニアの行動指針を作る上で自分達がよいとしている文化ってこんな行動をしている人だよねというのがたくさん出たのも良かったです!

f:id:pokotyamu:20191212190857j:plain
意外と隣のチームのことは知らないものです

ワーク4(収束フェーズ)

4つ目のワークでは、ワーク1の付箋を剥がして、ワーク3で出た具体例をグルーピングし、それらのグループにある要因ってなんだろう?を考え、それを絵にしてみました。

あえて元々のワーク1の付箋を剥がすことによって、先入観なく意見出しができたのが良かったポイントでした。 最初は、またワーク1と同じワードが出てくるかとも思ったのですが、意外と違った言葉にも変わって、かなり深いレベルで明文化できたと思います。さらに失敗したワーク2の時よりも納得感の高いものになりました。

f:id:pokotyamu:20191114124111j:plain
Share Everything の原型

ワーク5(収束フェーズ)

5つ目は、絵をいい感じの文章と言葉にするです。

ここまでくれば、後はいい感じの文章にするだけでした。 コピーライター的な仕事の方に残りを任せても良いのですが、いままで考えてきたものの背景などがわからないままキャッチーな言葉を当てられてもしっくりこないだろうなと思い、このまま自分たちで考えました。 いつもの会社で付箋使って考えるというのも良かったのですが、クリエイティビティーを上げるために、ひゃっこいルービー飲みながら考えました。

f:id:pokotyamu:20191115212357j:plain
お好み焼きは美味しい

ワーク6(収束フェーズ)

最後は、出来上がった文章を並べて、全体のバランスを見るです。 並べてみて、被っているところはないか?どの順番で見せると自分たちが大事にしている意図が誤解なく伝わるか?というのを調整しました。

f:id:pokotyamu:20191121184234j:plain
付箋に書き出して位置関係の最終調整

こうして出来たのがこの6つの Principles です。

f:id:pokotyamu:20191212191132p:plain
FF Engineer's Principles ver1.0🎉

エンジニアへのお披露目の時も、ポジティブな意見をたくさんいただくことが出来ました!

ファシリテーションで気にした3つのこと

最後に自分がワーク1~6をファシリテートして気にしていたことを書いてみます。

1. サブプロジェクトなので MTG の時間をフルに使えるようにする

今まで説明してきたワークを本業でやるのであれば簡単なのだが、自分たちは本業とは別のプロジェクトとしてやりました(各チームへのお願いはした上で)。 サブプロジェクトに時間をかけすぎて本業に支障をきたすとなってしまっては、本末転倒です。その中で、2ヶ月強で結果を出さなければならないというのが今回の難しいポイントでした。

そこで自分が徹底したのは場作りです。

例えば、前回と同じワークをやる日でも、あえて最初の5分は今日のゴールとワークのルール説明を行いました。 ゴールでは、最低限ここを決めたい(こんな成果物を作りたい)。ここは時間があったらで大丈夫。というのを説明しました。 ルール説明では、「これは今考えなくていいです。」というのを明確にすることで、考えることの方向性を統一しました。

これによって、事前の宿題はなしでも、その日に作りたい成果物に向けて 100% の時間と全員の脳みそをコントロールしやすくなります。 もちろん、会場設営でホワイトボードを用意したり、ワークで使う付箋を用意したり、話すための十分なスペースを用意したりといった場作り(物理)も行っていますが、個人的には、ゴールやワークのルールなどの目に見えない場作りもファシリテーターとしては必要になってくると思います。

f:id:pokotyamu:20191114123453j:plain
場作り(物理)の工夫

この場作りを怠らなかったことがダレずに2ヶ月走り抜けれたことにつながったと思います。

2. 自分の役割の範囲を超えない

冒頭のスケジュールにも書いたように12月までにというのが今回の締め切りでした。 あくまで自分はファシリテーターとして入っているので、成果物の質の部分に関してはオーナーに持ってもらうほうが良いと考えていました。 オーナーが求める質に向けてチームの力を 100% 出し切る為に自分が入っていると考えれば、オーナーとの意識合わせは必ず必要になってきます。オーナーの意に反して進めては元も子もないですしね。

なので、全体のスケジュールを見た時にいつまでに何を作成できていれば良いのか?は適宜打ち合わせながら進めていきました。 いつまでは話を発散させて良い。そろそろ収束に向かったほうが良い。みたいなやり取りを繰り返していた気がします。 ありがたいことに、どんなワークをするか?は信頼の上で私に任されていたので、こんな成果物を作りたいからこんなことをしようと思っているという話を断られたことはなかったです。

今考えたら、オーナーが任せきれずに一緒にワークを考えたり関わっていたらもう少し時間がかかっていたと思います。 プロダクトオーナーとファシリテーターの役割の違いにおける権限を意識してお互い動いたのは非常に良かったです。

3. チームの状態を見極める

最終的な成果物の正しさが見えていない中で進んでいく必要がある今回のプロジェクト。ワークの1~6は最初からそれで行くぞ!と決めていたものではなかったです。

今の自分達が進んでいる方向性大丈夫そう?不安ない?を確認するために積極的に、 MTG 中に「今のワークどうです?」を聞いていました。 また、各ワークの1回目は試しにやってみるというのを意図的に強調することで、やり方を調整していきました。 このままのやり方で進んでいった先に目指している成果物が作れるか?もっと意見を進化させるための工夫はないか?などは常に考えていた気がします。

時にはワーク進めて10分ぐらいで全然上手く行かなさそうだったらやり方をアドリブで変えるというのもやったときもあります。 瞬時に切り替えれる引き出しの多さも大事ですが、意外と「自分で一回やってみる」というのをやったら問題点に気づく場合もあります。 今回やってみたワークについては最終盤のやり方を載せています。あくまで私達のチームで上手くいったやり方なので、ぜひ真似しながらアレンジしてみてください。

今後の FF Engineer's Principles

今の段階は ver 1.0 なので、運用してみて違うと思った部分に関しては都度直していくつもりです。 一回のリリースで完璧なものもできるわけではないですしね。

ぜひぜひ改めて6つの Principles を読んでみて、自分も共感できるなと思った方は一度お話しましょう!!よろしくおねがいします!!


明日は、ベーコンエピが大好きなエピニキこと、20卒内定者の川井くんが書いてくれるみたいです!お楽しみに〜