kippエンジニアリングチームの作り方

こんにちは。CTOの冨田です。 これまでのブログ記事では利用技術についてお話しました。 今回はこれまでの記事、あるいは今後の記事でkippに興味をお持ちいただける方がいることを期待して、エンジニアリングチームの作り方をお伝えします。 まずkippエンジニアリングチームの実情とその背景にある考え方を述べ、それから考え方を実現するための取り組みを説明します。 他の会社でチームビルディングをされている方の参考にもなれば嬉しいです。

チームの構成

エンジニアリングチームは正社員、個人の業務委託の方々、業務委託の外部会社の方々で構成されています。 正社員は冨田を含め3名で、開発から運用まで全体をまんべんなく担当します。 社内外からの要望を聞き、本番環境をモニタリングして改善していくことがメインミッションです。

個人の業務委託の方々がさらに4名おり、こちらはScalaで実装された中核システムの開発を専門的に行います。 Scala技術者ですぐに正社員採用できる方は少ないですが、業務委託であればお願いできる方がいらっしゃいます。 技術に対する高い専門性を生かし、ハイペースでアイディアを実装に変えていく役割をお願いしています。

外部の会社の方々は社内で手のまわらない専門知識を要する分野をお手伝いいただいています。 現時点ではスマートフォンアプリケーション開発やインフラ構築のサポート、オンコールの一次請けをお願いしています。 会社で直接採用しにくい分野、人数が必要な分野で実績のあるチームのサポートを得ることが目的です。

本記事でお話するエンジニアリングチームは外部会社の方を除いた、正社員と個人の業務委託の方々のチームです。

チームコンセプト

エンジニアリングチームが目指している状態は次のようなものです。

• 責任が明確である
• コミュニケーションが明確である
• 自由である

責任が明確であるとは、個人に期待される職責が明文化されていて、理解されている状態です。 例としてオンコール制度を見てみましょう。 正社員はローテーションでオンコール担当になります。 オンコール担当中は電話を受けられるようにしておいて、インシデントが発生したらドキュメントを確認しつつ解決にあたります。

kippが大事にしているのはこのような責任を文書化し、全員に理解してもらうことです。 「オンコールを担当してください」とだけ言われても何をしたらいいかわかりませんね。 周囲の振舞から見よう見まねでキャッチアップすると時間がかかりますし、「あいつはやるべきことをやらない」など軋轢が生じかねません。 人によってやりかたが違って作業が矛盾し、トラブルになることもあります。 「ここに書いてあることをお願いします」と差し出せる文書を維持するよう努力しています。 べき・べからずに留まらず、具体的な手順、よくある問題なども載せ、手引きになるよう充実させています。

コミュニケーションが明確であるとは、相手の前提知識や暗黙の了解を当てにせず、一箇所を読めば主張が分かる状態です。 この価値が特に重要なのはタスクを依頼する時です。 概念の呼び名がまちまちだったり、タスクの説明に書いていない前提があると実装者は要求を正しく理解できません。 間違った理解にもとづいて作業した結果、実装を大幅に書き直さなければいけないという悲劇が何度もありました。 要求の文書やタスクの説明もレビューし、齟齬や言及不足、考慮不足を最も早い段階で直しています。

相談するときも何をしようとしていて、どのような方針を立てたかが明快だとすみやかに回答できます。 背景知識やプロダクトの状況、依頼者の思いから、適切な名詞、動詞の利用まで、内容のすべての層に注意を行きわたらせるようにしています。 さらにシステムの仕組みやプロダクトコンセプトをまとめた資料を作り、共通言語のプリセットとしています。 この資料はGoogle Driveに保存されているので、伝達内容のわからない部分はDriveで調べられます。

このやりかたはコミュニケーションが「硬い」ものになり、気軽な発話を阻害する面があります。 しっかり書こうと思って一人で長時間悩んでしまっては時間がもったいないですね。 そこでSlackのチャットは気軽な相談をする場として、思ったことを何でも、どこでも書けます。 社内外の最新状況をさっと書き出すヘッドライン的な場として効果を発揮しています。

それでもどれくらいのことまで書いていいか不安だったり、人のいるところで発言するのは恥ずかしかったりします。 そこで一部のメンバーはtimesチャンネル（個人の名前のついたチャンネル）を作っています。 timesではより発言の敷居が下るので、やってること、思ってること、気になったことが集まりやすくなります。 ちょっとしたぼやきからリファクタリングやルールの改善が生まれることもよくあります。 Slackを柔らかな空間に保つため、反対に依頼や合意はSlackで終わりにせず、文書にして残します。

コミュニケーションが明確であることの効果は意思伝達がしやすいに留まりません。 依頼の例では、依頼の文書が自己完結してコンパクトであることで、そこだけ読めば最近の議論、ビジネス動向などを理解していなくても作業できます。 フルタイムではない業務委託の方が週末だけ作業する場合でもタスクとコードを読めば実装を進められます。 すなわち属人化を防ぐとともに協力していただける方を増やしやすくなります。 新しく実装される部分が方針を理解して作られているのでチグハグになりにくいです。 次の実装がやりやすく、その次も、と長い期間を通して効率を維持できます。

最後の自由とは、責任の裏返しです。 責任とコミュニケーションが明確だとやるべきことが明確になります。 反対に、それ以外はやらなくていいとわかります。 他チームはやや状況が違いますが、エンジニアリングチームは正社員でも休みを自由に調整できます。 オンコール担当の時は連絡のつくようにするというルールがありますが、それ以外はどこにいてもかまいません。 真っ昼間からゲーセンに行くのも、唐突に箱根の温泉に浸かるのも、北海道で夏を満喫するのも自由です。 昼まで寝ている人も早朝から作業する人もいます。 土日に休みたい人も土日は仕事したい人もいます。 エンジニアリングチームはメンバーの自由意志を最大限許容することで多様な個性を認めようとしています。

あくまで職場での自由なので、恣意的な制限がついていることを気にとめておく必要があります。 たとえばテキストコミュニケーションをしない自由はありません。 なかにはテキストより口頭、対面の会話が得意な人もいます。 口頭のコミュニケーションを中心に構築されたチームがテキストコミュニケーションに劣らないことも知っています。 しかしチームはテキストコミュニケーションを中心に構築され、それを好むメンバーが集まっています。 全員の合意で方針を変えることはありますが、主張がかならず通るものではありません。 採用でもその時点のやり方に馴染むか確認する必要があります。

自由とはだらけている、いいかげんであるとは真逆の状態です。 オンコールやタスクを処理することは明確な責任です。 周囲との関係を保つなど、会社の一員として果たすべき義務もあります。 おたがいに責任を果たすという信頼があるから、それ以外の部分で一切の束縛をする必要がないのです。 自分を律する面でも社内外から信頼されつづける面でも、自由でありつづけることは非常に困難です。 週5日出勤して、その場でいわれたとおりにするほうがよっぽど楽でしょう。 後で怠けるために自動化を頑張るプログラマと、自由を得るために成果を出すチームはどこか類似を感じます。 エンジニアリングチームはこれからも自由であるために努力を続けます。

チームの維持

少しヒートアップしてしまいました。 地に足をつけて、以上のチームコンセプトを実現するための具体的な手段をお話します。 まずコンセプトの実装として、チーム維持のためにやっていることを説明します。 維持とは、チームをよい状態に保ち、業務しやすく改善していくことです。 それからチームメンバーを増やすための採用に触れます。

チームの維持に重要なのは意見を聞いて改善することです。 チームコンセプトの実現には様々なアプローチがあります。 長い時間の果てコンセプト自体がメンバーの希望と相反してくる恐れもあります。 今のやり方が適切か確認する場が必要です。

メンバーやビジネス状況や世相に対応するポイントとして、ふたつのミーティングを持っています。 ひとつは各チームリーダーが集まり、ビジネス状況をもとにエンジニアリングの方針とスケジュールを議論する場です。 隔週で行っています。 もうひとつはエンジニアリングチーム内での月1回の1on1です。 これらの場で細かいタスクの話から心情の話、大方針まで直接議論し、アップデートの原動力としています。

メンバーを不要に拘束しないよう、ミーティングは最低限にすることを心がけています。 議題がないのになんとなく集まる、大人数で集まって発言するのはごく数人というミーティングは無駄が多いです。 同期的なミーティングはその時間だけでなく前後の時間の自由も奪います。 この前提の上で最低限これらのミーティングはやるべきと考え、スタイルを見直しつつ行っています。

ビデオチャットでの1on1を開始したのは比較的最近で、今年の前半だったと記憶しています。 それまでは「なにかあったら言ってください」のスタイルで、意見を言う権利はありましたが機会はありませんでした。 「なにかあったら」のスタイルで意見を言える人もいますが言えない人も多いです。 わかったときには既に禍根となってしまっていたこともありました。

定期的な機会をつくることで相互理解が深まることを期待し設けました。 全体会議など人数の多い場にしてしまうとどうしても長くいるメンバー、今ホットな領域を担当しているメンバーに発言が集中します。 一対一の場にすることで気楽に話せると期待しています。 実際に私が見えていなかった課題を指摘してもらえています。 ひとつひとつは小さな問題でも、頻繁に同期することで大きな改善につながると信じています。

直接の改善からは少しずれますが、ときおり全体アイスブレイクを実施しています。 リモートワークが主体でミーティングの回数が少ないので他のメンバーと話す機会がほとんどありません。 自己紹介やレクリエーションを取り入れ、時間を一緒に過ごすことをテーマにしています。

チーム維持のためにもうひとつ重視しているのは文書化です。 完璧には程遠いものの、文書の品質を維持しつづける強い意志を持っています。 高速にシステムを改善しつづけるには良いコードと良い文書が両輪となります。 コミュニケーションをスムーズにするにも、責任を明確にするにも文書が基本の武器になります。

私自身とても忘れっぽいので、なんでも書いておかないと忘れてしまいます。 また何度も同じことを説明するのが嫌でもあります。 何度も聞かれるのはウェルカムですが、毎回説明するのが面倒です。 やったこと、考えたこと、伝えたいことはなんでもメモして、繰り返し参照されるものをたびたび更新しています。 よいドキュメントを作るぞと意気込んでとりかかると道半ばで挫折してしまいます。 とりあえずその時の用に足りるものをつくってすこしずつ手直ししていく感覚は内製ツールに似ていますね。

チームコンセプトのみっつめの要素、自由のための取り組みは難しいです。 これをしていれば自由になります、などという黄金律はありません。 思考停止は自分で自分を拘束している点で最大の不自由です。

私が気をかけているのは自分自身が満足して働ける環境であるか反省することと、メンバーにあなたは自由だと伝えることです。 人は他人の感情がわかりません。 リモートワークであればなおさらです。 自分については自分自身で反省し改善のきっかけを探せます。 しかし他のメンバーを見ていても不自由に感じているかわかりません。 それどころか、本人は仕方のないものと受容してしまっている恐れがあります。 「あなたは自由です」と伝えることで、こういう働き方はどうかな、これちょっと嫌だなと思いつくことが少しでも増えるのではないでしょうか。

しない自由と同じだけする自由にも注意を払っています。 例えばリモートワークの自由と同時に出社の自由があります。 オフィスはアクセスのよい大手町のFINOLABに入っています。 フリーコーヒーもあり快適に作業できる環境です。 しかし現在は外出するだけでも健康リスクがある状態なので自由を制限し、出社を必要最低限にするようお願いしています。

採用の考え方

会社の発展にともなってチームを拡大していくためには採用が必須です。 構成の部分で述べたとおり、正社員と業務委託はメインミッションが違います。 業務委託は補助ということは一切なく、どちらも同じウェイトで、違う価値観で採用しています。 ここでは正社員と業務委託に分けて採用のときに見ているポイントを紹介します。

正社員に求めるのは広範な知識と長期間にわたってシステムを改善する熱意です。 コンピュータサイエンスの基礎知識に加え、とくにkippの業務分野で重要なネットワーク、セキュリティ、RDBMS、パフォーマンス改善の知識が必要です。 じつはScalaが書けるかどうかは重視していません。 コンピュータサイエンスの知識にはプログラミング言語の仕組みや型理論、バーチャルマシンの理解も含まれます。 知識があれば文法を覚えるだけですぐにScalaを書けますから、ジョインしてから本を読めばよいです。 実際、kipp勤務以前にScalaの経験がなかったメンバーの方が多いです。

システムを改善する熱意はできるだけ長期間携わってほしい意図を反映したものです。 熱意というと大袈裟ですね。 なげやりにコードを積み重ねるのではなく、作業しやすい環境を維持する気持ちを持っていてほしいです。 具体的には使いづらい部分をリファクタリングしたりツールを作ることを期待しています。

業務委託の方々には反対に即戦力として働けることを求めます。 Scalaの業務経験がなくても、ライブラリも含めて一通り理解していて独力でコードを書ける必要があります。 タスクの説明とコードを読んで自力で業務を進めていくため、一定の問題解決能力も求められます。

性格や人物像の面では共通して責任感があり、実直であることを求めています。 金融システムの性質上、必ず踏まねばならない手順がいろんな面であります。 間違いや問題が発生した場合の報告手順も定められています。 手順をないがしろにしたり、間違いをもみ消すようなことがあると会社の存続に関わりうるので注意しています。 事業内容はBtoBtoCの性質が強いので、関係パートナーとの信頼を育むため確実に作業を完遂するのも重要な資質です。

よりよいチームに向けて

今回はkippエンジニアリングチームをいろんな側面から紹介しました。 スタートアップ企業は事業も手探りですがチーム構築も手探りでした。 チームビルディングや運用については様々な情報が発信されていますが、5人程度の小さいチームについて述べているものは少ないようです。 人数が少ないと一人一人の個性による振れ幅が大きすぎて、なにも画一的なことが言えないからでしょう。

この記事の内容もそっくりそのままやって上手くいくものでは決してありません。 むしろかなり特殊な事例でしょう。 すこしでもお読みになった方の参考になる部分があれば幸いです。

自分自身、人と話したり仲良くなるのは苦手です。 かなり苦手です。 しかし苦手だからこそよりよくしたいと思い、なあなあにせず改善の意志を持ちつづけられていると感じます。 ここで書いたことは通過点であり、毎月毎年変わっていくでしょう。 組織が良くなっていけるもっとも幸せな契機は新しいメンバーが加わることです。 このような組織で一緒に働いてみたいと思った方はぜひpeople@kipp-corp.comまでご連絡ください。