熱意だけでは続かない。有志の開発チームを3年続けてわかったこと

前回、私たちが社内で続けている自主開発の取り組み——「サブプロジェクト」について、その狙いと考え方を書きました。

今日はその続きとして、実際にどう運営しているのかを、できるだけ具体的にお伝えします。

「会社で使えるツールを作りたい！」
「このスキルを身に着けたい！」

サブプロジェクトには、こんな熱い気持ちを持って参加してくださるメンバーが多数おります。
しかし、本業を持つメンバーが、業務時間外に開発を続けていくとなると、必ず続けるための仕組みが必要になります。

今回はその辺りについて書こうと思います。

「熱量」を細く長く灯すには

有志の熱量は、放置すると消えてしまいます。
これは精神論ではありません。

私たちのメンバーは、それぞれお客様先で責任のある仕事をしています。
リリース前の山場もあれば、トラブル対応で深夜まで走る週もあります。
そんな時期に「自主開発も頑張ろう」と言うのは無理がありますし、会社としてもそれは強制したくありません。

そして一度離れると、なんとなく戻りにくいです。
進捗は分からなくなっているし、抜けていた後ろめたさもある。
これは、サークル活動など多くの社内活動が辿る道です。

だから私たちは、熱意を前提にしない設計を選びました。
忙しい時期が来ることを最初から織り込んで、それでも続けられる形にしたいと思っています。

ポリシー「無理しない」

サブプロジェクトには、チーム共通の5つのポリシーがあります。

• 自主性
• 無理しない
• 時間コントロール
• アウトプット
• チームでやっていく

会社の取り組みで「無理しない」を掲げるのは、少し奇妙に映るかもしれません。
けれどこれは、「抜けてもいい」と先に宣言しておくということです。

宣言されていなければ、忙しくて参加できない週があったとき、人は後ろめたさを感じます。
その後ろめたさが積み重なると、いつの間にか戻れなくなります。

先に「無理しないのがルールです」と言ってあれば、休むことは『違反』ではなくなります。
休める方が長く続くのは、仕事も同じですね。

参加の条件は定量的に

一方で「いつでも休んでいい」だけでは、活動そのものが形骸化します。

そこで、参加のラインを数字で決めました。

• 週に10〜50行程度のコードが書けること（コード以外の作業も、これに準ずる作業量として扱います）
• 月に1回以上、定例に参加できること

これを満たせない期間は、いったん離脱扱いになります。
ただし、毎月行われる社内公募にて再応募はいつでもできます。

定量的なラインを決めたのには理由があります。
アウトプットのみを基準にすることで、「ここ考えてたけど形にできていない」などの、”言い訳ができる状態”を無くすためです。
自分で抜けるというのは億劫ですが、機械的に弾かれるのは意外に楽だったりします。

そしてこの数字は、週に10行と意図的に低く設定しています。
AI駆動開発が前提なので、状況確認がてらSlackを見て少し手を動かせば一瞬で届くアウトプット量です。
続けるための最低ラインであって、頑張りを測る指標ではありません。

離脱を責めず、いつでも戻れる状態にすることで、本来の目的である技術研鑽にのみ目が向くようにしたいと思っています。

定例は「情報共有の場」

各チームは、週に1回、平日の夜にオンラインで集まります。

ここで一つ、はっきりさせていることがあります。この定例は、進捗を確認する場ではありません。

位置づけているのは、共有・疑問解消・レクチャーの場です。

• 今週こんなのを試したら、こうなった
• ここで詰まっているんですが、誰か分かりますか？

などなど。

「どれだけ進んだか」を報告する時間にしてしまうと、進んでいない人が出席しづらくなります。
それでは、いちばん助けが必要な人が参加しなくなり、フェードアウトに繋がります。

そして当然、定例に参加できない週があってもかまいません。
事前にひとこと伝えておけば、それで十分です。

最初の打ち合わせで「要件定義」を始めない

新しいチームを立ち上げるとき、初回のミーティングでやることは決まっています。

方向性の確認、環境の準備、ルールの共有。
「何を作るか」は、あえて決めません。

これは3つのチームを立ち上げる中で辿り着いた型です。

初回で要件を決め切ろうとすると、たいてい声の大きい人の案に決まります。
そして要件定義者が中心のプロジェクトになり、他のメンバーは「作業者」になってしまいます。

だから初回は場を整えるだけにして、「要件定義」は全員の宿題として持ち帰ります。
次に集まるときには、それぞれが自分の考えを持ってくる。

そこから議論が始まれば、全員が要件定義者になれます。

Contribution Point の導入

最近始めた取り組みとして、貢献度を点数で可視化する仕組みがあります。
それが「Contribution Point」です。

設計ドキュメントを書く、設計判断を記録に残す、課題を起票する、実装する、レビューなど...
記録に残る活動それぞれに、点数を付けていきます。

これを入れた狙いは、コードを書く以外の貢献を埋もれさせないことです。

開発チームでは、どうしても「たくさんコードを書いた人」が目立ちます。
けれど実際にプロダクトを前に進めているのは、それだけではありません。
設計を整理した人、レビューで問題を見つけた人、議論を記録に残した人——こうした見えにくい貢献は、しっかり評価したいです。
更に言えば、AI駆動開発において人間が価値を発揮するのは、開発以外の作業だと思っています。

点数化することで、外的動機となることも勿論狙っています。
しかもこの点数は、他メンバーが「助かった～！」と思った量に比例してメンバー同士で付与し合います。

「あなたの仕事いいね、ありがとう！」と伝えるための仕組みになれば良いなと思っています。

まとめ

自主開発の取り組みは、始めるより続けるほうがずっと難しいと思っています。

私たちがやってきたのは、特別なことではありません。
休めるようにする。戻れるようにする。ハードルを低いところに置く。この辺りです。

そしてこの仕組みは、永遠のβ版として随時改善していきます。
実際、参加の条件も定例の進め方も、3年のあいだに何度も形を変えてきました。

前回はサブプロジェクトにおける考え方を、今回は長く続けるための仕組みを書きました。
もし「こういう場所で手を動かしてみたい」と感じていただけたなら、ぜひ面談にてお話させてください。

あなたが無理なく研鑽を続けられる場所を用意して、お待ちしています！