はじめに
こんにちは、LAPRAS株式会社のことねです。
2025-09-18、新企画の**「LAPRAS OSS BOOST」**がお披露目となりました。
この企画はユーザー参加型で1クリックにつき100円をLAPRASがまとめて対象のOSS（初回はDjango）に寄付をするというもので、ユーザーの負担ゼロでOSSを金銭的に支援できる取り組みとして実施しています。初回はLAPRASでも個人でもお世話になっているDjangoをピックしましたが、特にDjangoを使っていないと応援してもいけないというわけでもありません。ぜひ気軽にご参加ください。
LAPRAS OSS BOOSTの紹介画像
この機能を実現するまでの過程で、それまでただ「つくる人」としてしかチームに関われていなかった状態からキャズムを超えて自ら「チームメンバー」になっていきました。わずか10日間という期間の間になにがあったのか？本記事では機能開発の過程と「壁」を超えるという観点から学んだことを赤裸々につづっていきます。
学んだことTL;DR
「壁」はだいたい自分が作っている
企画の概要
今年（2025年）の3月にLAPRASは「第1回LAPRAS（勝手に）エンジニア国民投票キャンペーンという企画を実施しました。
国民投票キャンペーンの紹介画像
「第1回」とある通り、シリーズとして企画されたものでしたがVim/Emacsのように都合よくプロレスができるお題の選定が難しいなど諸々の理由によりなかなか第2回を開催できずにいました。国民投票企画のメインのヒキはエディタ愛を存分に披露していただくことでしたが、それと同時に「得票数の多かったプロジェクトにLAPRASが寄付を行う」こともセットになっていました。この企画から着想を得て、LAPRAS OSS BOOSTは国民投票企画から「対決」的な要素を取り除いて「寄付」の側面にフォーカスした企画として出発しました。
きっかけ
なぜOSSなのか、なぜ寄付なのかについてはリリース時に私がXで連投した通りですのでそちらも掲載しておきます。要約すると 「アウトプットすることを応援するなら、そのプロセスだけではなくアウトプット自体も応援しよう」 に集約されます。現代ソフトウェア開発においてOSSを一切使用しないということは不可能と言い切れてしまいそうなほどにOSSに依存しきっています。DjangoやVue.jsのようにWebアプリケーションを作る時に使うライブラリやフレームワークはOSSですし、Linuxのようにソフトウェアプロダクトをデリバリーするために使われるOSSもあれば、gitのように開発プロセスに密接に組み込まれたOSSもあります。
そんな想いをスクラムフェス三河にスタッフとして参加した際にCTOと一緒に天ぷらを食べながら吐露したら「やってみましょうよ」と背中を押していただきました。この時に 突破した最初の壁が「企画の壁」 でした。施策を企画して実行に移す、これはその権限を持つプロダクトマネージャーやプロダクトオーナーにのみ許された権利であると思い込んで勝手に壁を作っていたのです。
9/7~9/9 アイデアからプロトタイプへ
プロトタイプを作り切るまでの過程はこの上なくスムーズでした。作ろうとしている機能はシンプルだったので
- 基本的な仕様を決める（データの持ち方、ビジネスロジックなど）
- 画面の置き場所を決める
- フロントを仮組みして動作イメージを固める
- 裏側の仕組みを作る
- 繋げて動くものを完成させる
というスタンダードな開発フローで進めることができました。何より今はAIに出力作業を移譲できるのでとりあえずClaude Codeに作らせている間に考えて、出てきたものと考えていたことの差分を照らし合わせてブラッシュアップして、というプロセスを何度か反復したら原型はほぼ出来上がっていました。AIが作ってきたものを捨ててもよいという前提で試行錯誤ができるとフットワークが軽くなる（人間に依頼していたら捨てる判断もコストを伴う）ので今だからこそできたことだなあとふりかえってみて思います。反省点としては「作ること」にフォーカスをしすぎたのでADRを残しておらず体調不良で一日ダウンしてしまった際にチームメンバーに負担をかけてしまったことが挙げられます。
9/10~9/16 プロトタイプからプロダクトへ
動くものができてチームにお披露目ところで一つ致命的なミスを犯しました。それは予想以上に色々なフィードバックを受けて守りに入ってしまったことです。私の中では「これはそんなに大した機能ではない」と思い込んでいたので、軽い手直しを加えてそのままリリース→検証のフェーズに入れるだろうと高をくくっていた部分があり、「デザインをも洗練したほうが良さそう」や「体験をブラッシュアップする必要がありそう」といった具体的なフィードバックにかなり強く反発してしまいました。もともと「デザインに時間を割きすぎるとリリースまでのリードタイムが想定を超えてしまう」という不安と焦りがあり、その心模様が態度に出てしまいチームに多大な迷惑をかけてしまいました。
そんな状況にもチームは適応しあれよあれよと言う間にデザインが出来上がり（デザインもコーディングも超一流なメンバーがいたからこそ）、体調不良で倒れてしまってもレビュープロセスが進み（超越した観察力とキャッチアップ力を備えたメンバーがいたからこそ）、9/16にはリリースレディな状態に（PdMたちが開発リソースを回せるように調整してくれたからこそ）なっていました。この一週間で「なるほど、これがスクラムか」とチームから身を持って教わりました。それまで私はなんとなく「無闇にメンバーに頼ってはいけない」という 「心の壁」を作っていた のですが、実際にはそんなものはなかったのです。
9/17 リリース
ソフトウェアとして必要なものが一通り整ったところで、最終リリースに向けたステージング環境での動作チェックや各種ビジュアル・告知文面の作成依頼を出していました。今日中にリリース告知をしたいが、関係者の稼働タイミングの都合で間に合うかどうかわからない。そんな状況で私はひたすら「待って」いました。そんな様子を見てかメンバーの一人が 「やっちゃえ（意訳）」 と声をかけてくれました。そう、ここに至っても私は 「業務領域」という「壁」を作っていたことに気が付きました。記事や告知文などは専門家に任せたほうが良い結果が出るという言い訳を盾にして「待ちの姿勢」に入っていたのです。
叱咤激励を受け「絶対に今日、リリースする」という気合であらかじめ作文しておいた内容をもとに告知用記事を執筆、SNS発信の準備を整え9/17日中に無事リリースすることが叶いました。記事執筆時点ですでに100名を超える方にDjangoをBOOSTしていただいており開発者冥利に尽きます。ありがたいことによりよくするためのフィードバック等もいただいているので期間中もブラッシュアップを続けていきます。
「壁」はだいたい自分が作っている
今まで社内システム開発やサービスの高速化など施策を開始から完了まで走り切ることはこなしてきましたが、実際にユーザーに知らせるところまでを含めて機能を届けたのは今回が初めてでした。ふりかえってみると壁だと感じているものはだいたい自分が想像しているだけだということがわかりましたし、その原因が 「専門の領域外に対する自信のなさ」 であることも今回わかってよかったポイントでした。「良い企画である」という自信がないから「誰かが賛同してくれる」まで動けない。「助けてくれる」という自信がないから「協力を仰ぐ」ことができない。「専門外でもうまくやれる」というという自信がないから「専門家に任せっきり」になってしまう。とはいえもちろん自分にできることの限界はあるので、質を度外視して「ここまでできてればここからは任せろ」と思わず手を出したくなってしまうようなアウトプットをし続けることが大事なのかもしれないなと今となっては思う次第です。
壊そうと思わなければ「壁」は壊れない
そうは言ってもそもそも「壁」があることを認識できていないことがほとんどですし、今後は私自身が自分の前にある「壁」に自覚的になり、周囲の人達の「壁」を壊せるように支援できるよう振る舞いたいです。「そうは言っても自分には権限が」と諦めがちですが、案外勝手にやってみるとどうにかなるものです。最終的にキャズムを超えられるかどうかは様々な要因に影響されますし、リスクやコストは十分に検討する必要はありますが、やるべきと思ったならやり切る覚悟を決めてやってみると良いことが起きるかもしれません。
チームメンバーに「なる」ということ
ケースバイケースではあると思うのですが、既成チームに加わる場合は「自分の都合」を覆い隠してやり過ごすよりも早い段階で自己開示をしつつチーム（≒既存メンバー）の都合と自分の都合をアウフヘーベンする機会を作るのは有効そうです。そうは言っても（性格もあるとは思いますが）「自分の都合」を開示することに抵抗感が生じやすいのも事実ですし一定そういった部分を引き出す仕組みやロールがあるといいような気もします（スクラムマスターとかアジャイルコーチとか）。いずれにせよ最終的には「心からチームを信頼できる」状況を作ることと「チームに心から信頼される」状況を作ることの鶏と卵になりがちで、個人として取りうる選択肢は「失敗のリスクを飲み込んでチームに信頼されるように努力する」しかないのだとは思います。そして往々にして早め早めにリスクをとったほうが傷が浅いことが多いので、早めにそういう動きができるといいのかもなあとも思いました。
Discussion