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

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

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

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

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

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

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

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

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

ポリシー「無理しない」

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

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

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

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

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

参加の条件は定量的に

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

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

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

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

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

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

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

定例は「情報共有の場」

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

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

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

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

などなど。

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

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

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

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

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

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

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

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

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

Contribution Point の導入

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

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

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

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

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

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

まとめ

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

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

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

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

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

とりわけ、お客様先に常駐して開発を担う働き方では、この「成長」というテーマに、少しだけ特有の難しさがつきまといます。今日はその難しさと、キャンバスエッジがそれにどう向き合っているのかを、正直にお話ししたいと思います。

常駐という働き方の、見えにくい落とし穴

客先常駐は、実務を通じて力がつく、とても良い働き方です。現場のリアルな課題に触れ、責任ある役割を任され、プロとして鍛えられていく。ここに疑いはありません。

ただ、一つだけ気をつけないといけないことがあります。それは、案件に最適化されればされるほど、スキルが「その現場の形」に固定化していく、という現象です。

長く同じ技術スタックに向き合えば、その領域には強くなります。一方で、新しい技術に触れる機会や、ゼロから何かを設計する経験は、意識しないと得にくくなっていく。気づいたときには、「その現場では通用するけれど、外に出ると少し戸惑う」という状態になりかねません。

「それはどんな仕事でも同じでは？」というご意見もありそうですが、ことIT業界においては、状況は更に深刻です。生成AIが登場したことで、スキル固定化のリスクは、以前とは比べものにならないほど大きくなりました。開発のやり方そのものが、数年単位ではなく数か月単位で塗り替えられていく時代です。昨日までの「正解」が、今日には「一つの選択肢」に変わっている。そんな変化のスピードの中では、現場の外で自分をアップデートし続ける仕組みを持っているかどうかが、エンジニアの数年後を大きく左右します。

だから、業務の外に開発の場「サブプロジェクト」をつくった

そこで私たちが始めたのが、社内の有志による自主開発の取り組み——通称「サブプロジェクト」です。

これは、通常業務とは切り離された、私たち自身のためのプロダクト開発の場です。少人数のチームを組み、実務に根ざしたテーマを自分たちで選び、企画から設計、実装、そしてリリースまでを、自分たちの手で進めていきます。

大事なのは、これが「研修ではない」ということです。用意された教材をこなすのではなく、答えのない課題に、本物のプロダクトとして向き合う。ここに、この取り組みのすべてが詰まっています。

私たちが大切にしている、3つのこと

サブプロジェクトを運営するうえで、私たちが意識的に守っていることが3つあります。

答えではなく、課題を渡す

チームに渡されるのは「解くべき課題」であって、「その解き方」ではありません。どんな技術を選び、どう設計し、何を捨てるか。その判断ごと、チームに委ねます。

もちろん、遠回りをすることもあります。うまくいかず、作り直すこともあります。けれど、その回り道こそが、指示された通りに作るだけでは決して身につかない「自分で決める力」を育てていきます。私たちが育てたいのは、手を動かせる人であると同時に、何を作るべきかを自分で考えられる人だからです。AIに代替されない「決断すること」と「責任を持つこと」ができる人材を、サブプロジェクトから輩出したいと思っています。

AIを「使う側」に回る

サブプロジェクトでは、生成AIを使った開発を前提にしています。AIに仕事を奪われることを心配するのではなく、AIを道具として使いこなし、生産性を何倍にも引き上げる——その感覚を、実際のプロダクト開発を通じて体に染み込ませていきます。

AIは、正しく使えば最高の相棒になります。ただし「正しく使う」には、エンジニア側に確かな設計力と判断力が必要です。AIが出した答えを鵜呑みにするのではなく、その良し悪しを見抜き、手綱を握る。この経験を早いうちに積めることが、これからのエンジニアにとって、何よりの財産になると考えています。

一人で作らない

サブプロジェクトは、必ずチームで進めます。役割を分担し、コードを互いにレビューし、プロジェクト自体の管理も自ら行いながら、プロダクトを作り上げます。

技術力は一人でも磨けますが、チームで良いものを作る力——相手の意図を汲む、自分の考えを言葉にする、健全に議論する——こうした力は、チームの中でしか育ちません。そして実際の現場、特に大規模なシステム開発プロジェクトで本当に価値を生むのは、多くの場合この後者の力です。

スキル以上に残るもの

こうした取り組みを約2年間続けてきて、気付いたことがあります。

参加したメンバーが手にするのは、新しい技術の知識だけではありません。0→1 の開発に携わった自信こそが、いちばん大きく残るのです。

その自信は、次の仕事でのエンジンになると考えています。難しい課題を前にしたときの、粘り強さになります。変化の速いこの時代を進んでいくための、社会人としての土台になります。

まとめ

今日の最先端が、明日には当たり前になる。そんなスピードで技術は変わり続けます。だからこそ私たちは、特定の技術に強い人を育てたいとは思っていません。

技術と一緒に変わり続けられる人を育てたい。

目の前の現場に閉じこもるのではなく、その外に成長の場所を持ち、自分の手で未来を選び取っていけるエンジニアと、一緒に歩んでいきたいと思っています。そして、キャンバスエッジはその環境をできる限り多く提供したいと考えています。

今回は、サブプロジェクトにまつわる思想について紹介する記事でした。次回は、実際のサブプロジェクトの運営状況や仕組みを紹介できればと思います。

もし、「自分もこんな場所で力を試してみたい」と感じたなら——ぜひ一度、エントリーフォームからご連絡ください。あなたが変わり続けていくその場所をご用意して、お待ちしております！