InnerSourceの歌を作ったら社内で俺の作ったレポジトリにPull Requestが飛んできた話
という話をまとめました。
今までふりかえりのうたを作ってきた
アジャイルを推進する自社の認知度向上と、業務の合間で作ったふりかえりツール「anycommu」の露出を目的に、アジャイルコミュニティでふりかえりの歌を作り続けてきました。
- 2022/11 Fun Done Learnのうた
- 2024/1 象死んだ魚嘔吐のうた
- 2024/3 焼肉レトロスペクティブのうた
基本的にコミュニティの人に笑ってもらいたい、緩やかな気持ちになってもらいたい、それを通して自分たちのことを知ってほしいというのがモチベーションでした。
一方でただただふざけているわけではありません。その昔、以前いた企業やチームにて私はカイゼン施策を議論するふりかえりを行なっていて、苦しい思いをした経験を抱えていました。
私は今の会社にて、「Fun Done Learn」や「象、死んだ魚、嘔吐」など感情を共有するふりかえりを通して、対話を通してお互いのことを知ること、そしてチームで会話することでそれぞれがリフレーミングをしていくことの重要性を学んできました。（もちろん時と場合によるんですよ、良い手法は…この話は別の場所で）
「InnerSourceの価値基準をうたにしたい」
そんな中RSGT2024でGitHub Japanの服部さんと初めてお会いしました。服部さんは、自分のセッション「Changing Teams with Music」を聴きにきてくれていました。お会いした際に、私たちが作ったこのツールを社内で組織に依存せず共有して育てていくにはどうしたら良いか？InnerSourceがヒントになるはず、これを会社の中で広げていきたい、という相談をさせていただいていました。
そんな中、服部さんからInner Source Gatheringイベント立ち上げにあたり、初心者でもわかりやすいコンテンツを作りたい、そのためのステップとして歌を作るという話を持ちかけていただきました。
InnerSourceの価値基準を考える会
そして生まれたのが「InnerSourceの価値基準を考える会」でした。
これまでに3回開催され、InnerSource Gathering 運営メンバーを中心に歌詞のアイデアだしを重ねてきました。InnerSourceの良い点を伺えば伺うほど、企業の組織のサイロや、車輪の再発明といったPain pointを解消したい、そして組織間の課題解決の希望としてInnerSourceがあるという風に私は感じていました。
そこで楽曲のテーマとして、悪をやっつける「戦隊モノ」を作ることを提案しました。InnerSourceを世の中に広げたい、知ってもらいたい層はあらゆる年齢ではありますが、メインのペルソナはプロジェクト/プロダクトにおいてリーダーポジションを担い始める20-40代に知ってもらいたいと考えました。そこで戦隊モノは戦隊モノでもシンセサイザーを多用し始めた90年代のサウンドを追求しようという方向性を提示しました。2回実施された価値基準を考える会の言葉を散りばめた仮の歌詞とそれに基づいて作った楽曲をまず作成しました。
作ったメロディに対して運営メンバーとブラッシュアップを重ね、できた音楽がこちらです。
KAGの社員部活動「音KAG部」にて編曲、歌入れ、イラスト作成、動画を作成しました。
◦Vo:小笠原、作曲:piyo中島
◦Arr&Gt:髙谷、key:在間
動画:大坪、ロゴ、イラスト:岸田
そして、これが最終的に出来上がった歌詞でした。
（インナーソースマン台詞）
オレはオレの書いたコードのメンテナー
のうのうと生きていたら俺は企業のサイロに閉じ込められてしまった
このままでは来年の新入社員もサイロに閉じ込められてしまう
共創未来 インナーソースマン！！
オレの作ったレポジトリ
みんな使ったらいいのに
色々言われるの嫌だから誰にも言わずに置いとこう
だけど隣のチームが同じものをつくる予定らしい
これじゃまるで車輪の再発明（思い切って社内に公開してみよう）
README.md 分かりやすくしたら
「何のコードかがよく分かった」
CONTRIBUTING.md ちゃんと用意したら
「コードに触れても良いと知った」
Starがもらえた！ Issueが来た！
PR(プルリク）もらえた！
助ける助かる 開かれたドア
Feedbackがうれしい
（みんなで作って 進化させていこう）
この歌の提供は
InnerSource Commons コミュニティと
KDDIアジャイル開発センターの提供でお送りしました社内で歌詞を作った話をしたら、自分のレポジトリにPull Requestが飛んできた
歌詞を作った後、Slackの分報にて私はInnerSourceの価値基準について感じたことを書き込みました。すると、別のチームのエンジニアが私のリポジトリにPull Requestを送ってくれました。
私も忘れていたのですが、社内には私の作ったとあるレポジトリがあり、そこそこの社員が使ってるものがありました。軽微な不具合を皆我慢して使っていたのですが、それをその社員は改修してくれたのです。
私は嬉しさのあまり、PRをマージした後SlackにPRを投げた人への感謝と不具合が解消された経緯を報告しました。すると、多くの社員が喜んでくれました。中でも印象的だったのが「このレポジトリを作ったのはpiyonakajimaさんだったんですね」というフィードバックでした。自分としては自分が作ったプロダクトなので当たり前なのですが、思っている以上に誰がどのレポジトリを作ったのかは伝わっていなかったのです。これも、CONTRIBUTING.mdをはじめとしたオープン性やInnerSourceにおける透明性が欠けていたからこそ起きたフィードバックだったと感じています。
曲作りから学んだこと
歌詞はコミカルに表現しつつ、InnerSourceの第一歩を始めるために必要なものは何なのか？を運営メンバーの皆様の実体験から言葉に起こしていきました。
私がこの中で最も大切だと感じたのは、「フィードバックをもらう嬉しさ」です。Pull Requestは勿論、リポジトリのプロダクトを使ってもらうだけでもいい、Starが貰えたり、困っていることにIssueが貰えることそのものが嬉しい。会社としての利益やビジネスがあるのは勿論のこととして、このフィードバックが原動力である、ということを学びました。
そのフィードバックをもらうための最初の一歩、それは「思い切って（自分が）社内に公開する」ということでした。但し、ただただ公開するだけではフィードバックをもらうのは難しいのです。そのために必要なのがどんなコードなのかが記載された「README.md」、そしてコードに触れて貢献してもらうやり方を記載した「CONTRIBUTING.md」です。これらのテンプレートはInnerSourceCommonsのパターンとして公開されています。
InnerSourceへの旅はまだ始まったばかり
私達もInnerSourceへの挑戦を始めたばかりです。ただ、ここに組織間のコラボレーションの大きなヒントがあると私は信じています。
PR:人材募集中
KDDIアジャイル開発センターでは、ソフトウェアエンジニア、デザイナー、スクラムマスター、プロダクトオーナーリード、などを絶賛募集中です。ご興味がある方がいたら是非お声掛けください。
さらに、私が所属するKDDI DIGITAL GATEでは週５勤務可能なソフトウェアエンジニアの業務委託の方も募集しています。 社内外でDXを起こすべく、新しいプロダクトの価値検証を行なっている組織です。モブプロに抵抗のない方、新しい技術に触れるのが好きな方で、もしご興味があればお声掛けいただけると幸いです。
この記事が気に入ったらサポートをしてみませんか？