「カミナシ 教育」と「カミナシ 従業員」チームの組織文化を作っていく – カミナシ エンジニアブログ

こんにちは。「カミナシ 教育」と「カミナシ 従業員」という2つのプロダクトのマネージャを担当しております daipresents です。最近は息子が少年野球チームに入った影響で、土日が野球でつぶれたかわりに、炎天下でもグラウンドで6時間すごせるようになりました。ありがとう野球。

採用活動をしていると、「組織」や「文化」の質問をされます。やっぱり、自分が働くかもしれない環境について、誰もが気になるもの。

今回のブログでは、マネージャとしてがっつり入りこんでいる「カミナシ 教育」と、リリースに立ち会った「カミナシ 従業員」のサービスチーム（スクラムチームのようなもの）の範囲で、僕自身が考えている「組織」や「文化」のことを、自分の頭の整理しながらまとめてみようと思います。

調べてみると、カミナシの社員は年に3,600回以上現場訪問しているようです。セールスやプロダクトマネージャはもちろんながら、エンジニアも現場に足を運びます。

僕のチームメンバーだと、週の半分を現場訪問で過ごしているエンジニアもいます。彼の場合、リサーチャやPMと新機能を企画・検討しており、実際に動くプロトタイプを作成し、お客さまに見せながら改善を探る動きをしています。

僕のチームは新しいサービスなので、技術的課題やチームの問題について、些細な問題はありますが、大きな問題にはまだなっていないと感じています。よって、我々がかかえる現状、最大の課題は、「お客さまの課題を解くこと」です。

そのために現場訪問が必要になってきます。

カミナシのバリューには「現場ドリブン」というものがありますが、現場に行くだけが現場ドリブンではありません。エンジニアの場合は、現場に行って、デリバリして、成果を出すことが求められます。

CTOのトリさんが築いてきた組織文化です。「なんでこうしたいんですか？」と聞いたときに「この形のときがいちばん良かった経験があるから」とおっしゃっていました。

自分もこの意見にはとても共感するものがあり、アジャイルコーチの仕事をしているときは「自律的な職能横断組織ができれば、アジャイル開発はほとんど成功する」と思いこんでいる人間です。

ただ、言うは易く行うは難しで、こういうチームを創るためには何をすればいいのか？ これがマネージャとしての課題、永遠のテーマと言えるのかもしれません。

ただ、「ムズいよね」と言うだけでは何も進まないので、いくつかのチャレンジ・試行錯誤をはじめています。

ひとつめは、マネージャは上下関係ではなく、パートナー関係であると日々伝えています。

役職がついても「おめでとうございます！」と言われないのがカミナシの文化でもあります。もし上下関係のようなものを感じたときは、自分から「違いますよ」と伝えるようにしています。

ふたつめは、サービスチームの仕事に対して、僕がマネージャとして意思決定をしていません。

経験を話したり、選択肢を広げるための質問をしたりはしますが、選ぶのはサービスチームです。よって、現状、僕が指示することといえば「勤怠入れてね」、「目標設定書いてね」ぐらいのものです。これができるのは、今のメンバーがシニアレベル、もしくは、それ相当の判断をチームとして自律して行えるからだと思います。

みっつめは、言われたことをやるのではなく、やるべきことを考えられるように、相談者の意見を聞くことです。

「どうすればいいですか？」と聞くのではなく「AとBを考えて、〜だからBがいいと思いますがどう思いますか？」と話してくれるようにお願いしています。壁打ち相手にはなりますが、結果的に意見を求めるようにしています。

これもCTOのトリさんが作ってきた組織文化のひとつです。詳しくは以下の記事が参考になると思います。

記事： カミナシと、質とスピード – MVP にこだわり、アジリティを獲得する

カミナシではアジャイルコーチの仕事をしていませんが、カミナシ以外の顧客相手にアジャイルコーチの仕事をしていると、ほとんどの場合、スピードと質の問題・課題に直面します。

この問題や課題を乗り越えるためには、技術や時間だけではなく、先の記事のような強い意志が必要になってきます。これがすでにあるのは、カミナシの強みと言えるのかもしれません。

実際にサービスチームの働き方を見てみると、びっくりするぐらいITスタートアップぽくなくなっています。

1. 朝礼
2. 週次定例
3. 月1オフサイト
4. あとは必要なタイミングで

サービスチームで定例とかひさしぶりすぎる。ただ、これには狙いがあって

1. 朝礼では、昨日やったこと〜とかではなく、現場訪問したレポートの共有など、みんなに話しておくべきことを語ろう
2. 週次定例では、新機能の共有会や、今の我々の状態をまとめ、サービスチーム外のチームに最新の情報を伝えられるようになろう
3. オフサイトではチームビルディングも兼ねて、F2Fで話すべきことを話そう

と、それぞれのやりかたに意思を持って挑んでいます。

本当はスクラム導入したほうが楽なんですが、そうじゃない方法でもうまくいく方法はたくさんあると思います。

カミナシのエンジニアは、大きくバックエンド、フロントエンドとわかれています。ただ、バックエンドだけ、フロントエンドだけを担当するメンバーはおらず、僕のチームでもフロントからバックエンドまで、ディスカバリからデリバリーまで、フルサイクルで活躍しています。

誰もがスキルに軸を持っているので、それを太くする人もいれば、別の軸を作ろうとする人もいます。僕のチームだと・・・

1. バックエンド軸があるけど、インフラ軸を身につけるために、プロダクトのインフラ面を担当しているエンジニア
2. フロントエンド軸があるので、それを活かして新機能のディスカバリに参加し、顧客先にプロトタイプを持ち込んで改善を繰り返しているエンジニア
3. エンジニアリングマネージャだったけど、もっと技術の軸を太くすればマネージャとしての深みが増えると考えて、フルサイクルの軸を太くしようとしているエンジニア

のように、それぞれのスキルが重なり合い、いいかんじで全体をカバーする体制ができてきました。

しかしながら、自分の軸とは違う部分にチャレンジするのは大変です。しかも、作業効率は間違いなく悪くなります。ここはチームでサポートする形になっており、バックエンドが苦手な方には、バックエンドの仕事をするときにバックエンド軸のひとをペアとしてつける・・・といった対応をとっています。これはこれで効率が悪いともいえますが、将来的に大きなリターンが期待できるので積極的に投資しています。

ここまではカミナシの文化や、CTOのトリさんが創り上げてきた開発組織文化が下地になっています。ここからは、僕がカミナシに入ってから考えてきた、試行錯誤している内容になります。

昨今のAIの進化はすばらしいもので、マネージャという仕事ですら、「AIの力をお借りしなければもう元の世界には戻れないよ！」 という状態になってきました。

これはエンジニアメンバーも同じで、「ソフトウェアを創る」という行為自体が変わりつつある実感があります。

AIによって生産性が高まるのはうれしいことですが、効率化でうまれた時間をまた生産性に使ってしまうと疲れます。ずっと生産し続けるのはしんどい。

また、ソフトウェア開発はとてもクリエイティブな作業なので、作れば作るほどよい結果になるとはかぎりません

アジャイル宣言の背後にある原則には「アジャイル･プロセスは持続可能な開発を促進します」とあります。生産し続けることが持続可能な開発なのかわからないので、「生産から生産」ではなく、「生産から生まれた時間を質に投資する」形をメンバーには勧めています。

「生産から生まれた時間を質に投資する」にも関連しますが、ムダな時間をあえて作るようにもしています。

たとえば、ちょっと時間があったらリモートでも雑談してみたり、やってきたアウトプットをふりかえってブログに書いたり、話したいことがあれば勉強会で発表してきてもいいと思います。アートが好きなメンバーは、美術館めぐりで新しいアイデアを得ていたりします。

コスパが求められる時代ではありますが、こういったムダかもしれない時間を有効に使い、自分自身に投資し、結果的に仕事の質に還元されるといいなーと思っています。

組織に人数が増えてくると「うわー、他チームからこんな依頼されたけど、やるのは大変そうだなぁ」と思うことがたびたびでてきます。

僕のいる部署は新サービス開発がメインで、スピードと変化への対応が求められるため、こういった「めんどうだな」と思うようなことも、積極的に拾っていくことをメンバーに求めています。

火中の栗を拾うのは大変ですが、我々のような部署ができなければ、組織全体ができなくなる危険性があります。

メンバーには積極的にこの能力（火中の栗ビリティと呼んでいます）をあげてもらおうと思っています。

組織文化は少しずつ変わっていく部分と、大きく変わっていく部分があるように思います。

先にも書きましたが、僕の部署は新規事業が多く、スピードと変化が本当に求められる環境です。

今後も、土台となる文化を維持・メンテナンスしながら、変化を恐れないチームや環境づくりを目指していきたいと思います。