フクロウラボでCTOを担当しております若杉と申します。
今回は、フクロウラボエンジニアチームの行動規範について、ご紹介しようと思います。
早速ですが、下記がエンジニアチームの行動規範になります。
１．常に成長し続けようと努力する。（仮）
２．情熱を持って楽しく仕事する。（仮）
３．協力して成果を出す。（仮）
４．観測可能な事象に基づいて思考する。（仮）
５．限られたリソースでもコミットする。（仮）
６．より高い視点で問題解決する。（仮）
（仮）となっているのは、意図する内容は変えないのですが、今後フクロウラボ独自のキャッチコピーにしようと考えているため（仮）としています。
エンジニアチームの行動規範の紹介
全6項目からなっています。それぞれが意図している内容を説明すると、下記になります。
１．常に成長し続けようと努力する。（仮）
- 切磋琢磨し、自学自習の精神を忘れない。
- 既存の枠組みにもとらわれず新しいことへの挑戦を積極的に行い、失敗を恐れない。
- 仮に失敗しても、そこから学びを得て、必ず変化し成長へつなげる。
- コードにこだわり、技術に興味を持ち、武器である技術力を磨く。
２．情熱を持って楽しく仕事する。（仮）
- 自分の仕事に意味を見出す。
- 情熱を持って世界により良い変化やインパクトを与えようというモチベーションで仕事する。
３．協力して成果を出す。（仮）
- 個人ではなし得ない成果を、チームで目指す。
- チームの目標、各メンバーの役割を明確にし、協力する。
- メンバー同士の考え方や意見を尊重し、高いクオリティで仕事をしてくれると信じ合う。
４．観測可能な事象に基づいて思考する。（仮）
- 事実と意見を区別する。
- 観測可能な事象に基づいて、仮説が立て、行動へつなげる。
５．限られたリソースでもコミットする。（仮）
- 自身の不完全さを受け入れる。
- 大きな問題は分割する事で、時間や様々な制約の中でもコミットする。
６．より高い視点で問題解決する。（仮）
- 高い視点で物事を捉えて、本質的な問題を見極めて解決する。
- 人がやる必要がない仕事の自動化やシステム化を進め、組織全体の生産性を上げる。
以下、このエンジニアチームの行動規範を決める過程をご紹介したいと思います。試行錯誤や失敗、そこからの学びも含め伝えられたら幸いです！
行動規範の策定までの道のり
ざっくり下記のような道のりをで歩んでいきました。
フェーズ１とフェーズ２の途中までは、エンジニア合宿で全員ワイワイしながら進めました。フェーズ２の言語化するというところとフェーズ３は、後ほど付箋の意図を汲み取りつつ若杉の方で行いました。フェーズ４はちょうど現在取り組んでいるところです。フェーズ５は、行動規範を作って終わりではなくメンテンナスを含めた運用まで考えて完成だと考えています。
※ちなみに、エンジニア合宿については、別の機会で改めてご紹介したいと思います。
フェーズ１：どんな価値観を持ってエンジニアリングに取り組むべきかをひたすら付箋に書き出す。
エンジニアとして「こんな価値観が必要だ！」というのを出し合いました。それぞれのメンバーが何を重視するのかお互いに認識でき、非常に有意義かつ楽しい時間でした！
基本的に、頭に思っていることをただ吐き出す、発散系のブレストは、特に難なく進められました。
フェーズ２：似ている価値観をまとめ、言語化する。
まず、同じ内容を意図してしている付箋（キーワード）をグループ化しました。そうすると、おおよそ、どんな価値観が重要なのかが見えてきます。
ここまでは、すんなり進められたのですが、それぞれまとめたもの毎にさらにわかり易い言葉に置き換えるというところで、なかなか進められなくなりました。
ホワイトボートにそれぞれアイデアを書き込んだり試行錯誤するが…
付箋のキーワードから集約して言葉を紡ぎ出したかったのですが、結局、また、発散的な流れになってしまい、どう進めていけばよいのかわからなくなっていきます。
結局、言語化/文章化する部分に関しては、後日、改めてミーティングしようということで妥協し、一旦、中断することにしました。
合宿と言えども、時間は限られているので、その時間内でアウトプットを出すためには妥協も必要だということを改めて実感しました。
フェーズ３：仮タイトルを付ける。
エンジニア合宿からの宿題として、“付箋群から行動規範としてワークするような文章を作成する”というのが残りました。こういった整理して仮案をつくる作業は、ミーティングなどで複数人の頭を使うより、誰か1人が集中して考えた方が良さそうだというのが前回の合宿での経験からの学びです。
そこで、エンジニア合宿での議論と付箋（キーワード）を元に、文章化を進めました。
ここからは完全に収束/集約フェーズで、キーワード群のそれぞれが意図している内容を想像し、最大公約数を言語化していきます。逆ピラミッドのイメージで徐々に抽象化を進めていきました。
たとえば、「成長」にまとめられたキーワード群をまとめる場合、下記のように抽象化していきました。
逆ピラミッドのイメージで徐々に抽象化
切磋琢磨,みんな成長できる,自分の良さを高める行動をしよう,常に改善、常に成長 問題を機会と捉える 何事にも貪欲であれ,できなくても前向きに（良い意味でバカになれ）,失敗を恐れない,挑戦し続ける,無いものは自分たちで作る,35歳定年説を乗り越える,I/Oがバランスよくできる,沢山の経験から大きな成功を得る 変化を抱擁せよ,勇気を持って変化する 自分の中の常識を疑え,既存を疑え
▼
・切磋琢磨し、自学自習の精神を忘れない。 ・既存の枠組みにもとらわれず新しいことへの挑戦を積極的に行い、失敗を恐れない。 ・仮に失敗しても、そこから学びを得て、必ず変化し成長へつなげる。 ・コードにこだわり、技術に興味を持ち、武器である技術力を磨く。
▼
常に成長し続けようと努力する。
という具合です。
同じ要領で、他のキーワード群も整理していきました。
各キーワード群からキャッチコピーまでの整理
この作業で考えた「キャッチコピー」と「意図する内容・説明」を行動規範として問題ないか内容のFIXをエンジニアチームのミーティングで行いました。
「内容・意図としては、問題ないがキャッチコピーをもっとフクロウラボ独自な言葉にしたいよね！」という意見があったので、この部分はまた変更予定で、（仮）としています。
コピーライティングはセンスが問われ、思いつきや発想次第なので、現在、各メンバーが思いついたキャッチコピーアイデアをスプレッドシートに溜めているところで、キャッチコピーが新しくなったらまたご紹介したいと思います。
行動規範のポスター化
社内への認知するために、デザイナーさんにポスターも作ってもらいました！
ちょっとかわいいデザインですが、かなりそれっぽくなりました！
まとめ
チームプレーが良い場合と個人プレーが良い場合
最初は楽観的に、「全てエンジニア合宿で決められるのでは？」と高を括っていたのですが、実際は、なかなかうまくはいきませんでした。ただ、そういった経験から、チームプレーが効率が良い場合と個人プレーが効率が良い場合が少しみえてきた気がします。
- チームプレー：アイデアを出す、情報を収集する、レビュー/チェック、ストレスフルな作業…
- 個人プレー：仮案/仮説/プロトタイプを作る、分類する法則を考える、まとめる/要約する…
個人的には上記のように、チームプレーと個人プレーを分けると効率が良い気がしています。この辺については今後も検証を重ねて程よいバランスを見つけていければと思っています。
オープンに作成していくこと
「行動規範を決めよう！」と考えた当初から、「トップダウンで決めてしまうと、カルチャーとして浸透しにくいのではないか」という疑問がありました。ですので、エンジニア合宿のような場で、チームを巻き込んで一緒に作っていきこうと思いました。実際、エンジニア合宿などを通して話し合ったことで、「この人は、こういう価値観を重視しているのか」というような、各メンバーの相互理解が深まるという副産物も得られました。結果、価値観を共有することでチームの一体感も生まれ、エンジニアチーム全体で作っていけたのは良かったと思います。
そして、改めて感じたのは、
・従業員が同じベクトルを向いて行動してもらうために…
・評価基準（あるべき姿）をつくるために…
など、会社の都合で行動規範の役割があると考えていましたが、みんなが心地よく仕事できるよう個々人のために存在させなければならないものだと感じました。
日々の泥臭い業務でも何かしらのこだわりを持って取り組めた方が、楽しく仕事を進められると思いますし、そういう風に毎日楽しくエンジニアリングができる環境を目指していければと思います！
/assets/images/4387760/original/efe3ba5d-4c9f-4873-b521-1738e80ecedc?1581036553)
コメントを残す