i Cubed Mini ShipIt! を開催しました！
サーバーサイド担当のMisaki-i3です。
アイキューブドシステムズの製品開発運用本部では、不定期に社内ハッカソンを開催しています。
『i Cubed Mini ShipIt!』というイベント名称はAtlassianのShipItをリスペクトしたものです。
2018年秋に第1回を開催し、2019年夏に第2回、2019年冬に第3回が行われました。
2020年以降はCOVID-19の流行により開催を断念。
そして2023年夏、2年半振りとなる i Cubed Mini ShipIt! が実現しました。
第4回の会場となったのは、今年春に生まれ変わったばかりのミーナ天神、その最上階にあるレンタルオフィス『The Company』です。
天神地下街直結で、弊社福岡オフィスからも歩いて数分の好立地。同じフロアにカフェのテナントも入っており、ランチ懇親会ではそちらのフードメニューが並びました。
早速、イベントの内容の話に移りましょう。
今回は、これまでの3回とは大きく異なる特徴がいくつかありました。
- 前回まではほとんどが数年以上の経験者であったのに対し、今回は開発歴1〜2年のメンバーが大幅に増えている
- 総勢35名(うち5名はオンライン)という過去最多の参加者数であった
- 前回までは個人参加が基本だったが、今回は運営によって分けられたチームでの参加だった
- 発表準備を含む作業時間が過去最短の4時間だった
前回からの3年近い期間に開発部の規模も大きくなっており、前回にはいなかったメンバーが多くいます。彼らのほとんどはハッカソンへの参加自体もはじめてのこと。
運営にとっても参加者にとっても手探りの部分が多いイベントとなりました。
結果からいって、期待した効果が概ね発揮された1日になったと思います。
作業中の雰囲気やランチ懇親会の和やかさからは、イベントが多くの参加者に心地よい刺激と前向きな反省を与えたことを感じられました。
かくいう私は開発歴1〜2年メンバーの一人で、初参加という立場だったのですが、いくつもの興味深い経験ができました。
社内ハッカソンの成功を求めて
多くのIT企業が社内ハッカソンを組織の成長の手段として評価しており、有名企業の技術ブログを探せば多くの関連記事を見つけられます。
その一方で、短時間で成果物を生み出すという前提にハードルの高さを感じて躊躇している組織もあるのではないでしょうか。
例えば、参加前日までの私はこのような不安を抱いていました。
- 一定の経験を持つエンジニア以外は、「予想通り、何もできなかったね。分かっていた通り、もっと勉強しなきゃね」で終わってしまわないか？
- 一日限りの「楽しかった」、「気分転換になった」で終わってしまわないか？
この不安は的中しませんでした。ただし、それはイベントの方針や運用方式が適切に選択されていたおかげだと感じます。
この記事では、社内ハッカソンだからこそ得られる経験や求められる意義、個人参加とチーム参加の違いなどを探り、組織のためのハッカソンの成功の鍵を見つけたいと思います。
本イベントをふりかえるにあたって、イベントの運営メンバーや前回までの i Cubed Mini ShipIt! を経験しているメンバーに取材を行いました。
若手の立場である私のふりかえりを併せ、様々な視点から分析できるよい機会でした。
本イベントの進行順序もご紹介しますので、社内ハッカソンの開催方法が分からないという方のお役に立てると思います。
i Cubed Mini ShipIt! 進行詳細
今回は予め課題決定までを済ませておき、開催当日は実作業から開始しました。
| フェーズ | 第4回 i Cubed Mini ShipIt! での内容 |
|---|---|
| 課題候補作成 | ・社内から改善したい業務や作りたいツールの案を募り、課題候補とする ・今回は業務改善やプロダクトの改良に繋がる課題に限った ・0→1ではない課題も候補に上がった(自社プロダクトのボトルネック改善等) |
| チーム分け | ・社員番号順のメンバーを8チームに剰余で振り分け(1,9,17,24番目がチームA) ・チーム内のメンバーのキャリアを偏らせず、スキルや担当分野はランダムになることを期待 |
| 課題決定 | ・課題候補の中から各チームでどの課題を選択するか当日までに決定する ・必要であれば課題の当事者にヒアリングを行う |
| 実作業 | ・決定した課題に取り組む ・作業時間は4時間 (i Cubed Mini ShipIt! としては史上最短) |
| 懇親会 | ・ランチ懇親会 |
| 成果物発表 | ・成果物の発表 ・各チーム5分 |
| 投票・総括 | ・参加者全員による投票を行い、順位を決定 ・運営の代表がイベントの総括を行った |
もちろんこれは一例であり、課題の決定を当日の作業に含む方式や、実作業の途中で中間発表を挟む方式など、開催意図に合わせて様々なアレンジが考えられます。
実作業の時間が4時間という設定は、参加者が「短すぎる」と感じる時間でした。この点に関する参加者からのフィードバックは後ほど紹介しますので、ご参考になさってください。
過去の開催では、第1回が14時間(2日間)、第2回が6時間、第3回が7.5時間の設定でした。
i Cubed Mini ShipIt! で運営が意図したこと、期待したこと
イベントの開催やスケジュール設定に関して運営の意図を伺いました。
ハッカソンという形式に共通することだけでなく、マネジメントの観点で参加者の様子から何を受け取ろうとしていたのかも聞けました。
なぜハッカソンなのか
- 多様な能力と自己決定力が問われる
- 解決したい課題の選択、要件定義から実装、プレゼン準備まで
- 時間以外の制限が無さすぎる中で、全てを自律的に進行しようとする能力
- 自然と高い集中力を発揮できる
- 時間にゆとりがない状況
- 不完全でも発表の時が来てしまう強い締め切り感
- 定められた時間内でゴールへ辿り着くための計画力と対応力があらわになる
- 時間配分をどのように決定していくか
- 締め切りの延長ができない中、エラーやトラブルにどう対処するか
(フルリモート中は開催が無かったが)オフライン開催にこだわりがある？
- そもそも、2020年時点では数十名規模のオンラインミーティングという発想もなければ、ツールもなかった……
- 作業場所をともにすることで一体感を得られる
- 他の人・チームの様子が目に入ること、聞こえてくること
- 競争心やプレッシャーが、モチベーションと集中力に寄与
- 各々の成果物という目標をともにすることから、明確な共同体の意識を覚える
- 普段は仕事内容もスケジュールも異なっており、オフラインイベントほど意識しにくい
- 懇親会ができる
オンライン参加は十分に可能であることを補足しておきます。オンライン開催のハッカソンも存在します。
今回のイベントでも、成果物に対する投票ではオンラインのチームが最も得票しました。
一方で、会場側の空気は感じにくく、お祭り感は少なかったとの声がオンライン参加者からありました。
チームメンバーの割り振りの意図
- 役割を考慮したチームでないから発生する挑戦とキャッチアップ
- 各人が『いつもの役割』に収まることなく、チームに不足している役割を見つけてキャッチアップしていく
- 普段なら触れようとも考えない領域にチャレンジできる機会
- 普段接点の少ないエンジニア同士が協力する体験の機会に
- 互いのスキル交換
- 経験の多いエンジニアと経験の浅いエンジニアの相互刺激
- 新しい個性の発見
- 誰がオーナーシップを持つのか？
- 共同作業の中でどのような振る舞いを見せるか？
(個人参加とチーム参加の違いについては次章で扱います！)
イベントや参加者に何を期待していた？
- メンバーの自主性・個性の発見
- どのように成果物に貢献しようとしたか > 良い成果物ができたか
- 役割を果たすため工夫や努力を試みたか > 役割を果たせたか
- メンバー同士のコミュニケーションと相互理解の促進
- 普段の業務や自学の日々で担当領域に定まりがちな視野を、ハッカソンの参加によってストレッチしてもらう
以上のように、様々な角度から組織力の分析や教育のための期待が込められていました。
ハッカソンの独特なルールと競技性が、普段の業務や勉強会とは異なる観点を与えていることも分かります。
これは私の感想になりますが、このようにまとめてみて初めて、ハッカソンの難しさとやりがいは「時間制限があること」ではなく「時間以外の制限がないこと」にあるのだと気付かされました。
チーム参加ならではの特徴・優位性
私は個人参加を経験したことがないので、前回までの i Cubed Mini ShipIt! に参加した経験のあるメンバーにも取材を行いました。指導者寄りの視点も多く伺えています！ 特に、若手社員に参加した意義を感じてもらいたいという配慮はどのメンバーにも共通しておりました。教育の観点は項を分けてご紹介しています。
個人参加とチーム参加の対比
- 個人では、頭の中の不完全な設計から直接実装に入ることができた
チームでは、実装の前に設計を共有する必要があった- 時間の制限もあり、素早く適切にアイデアや設計を共有し合う努力が重要
- 認識が共有できたことを確認するフェーズを経て、ようやく実装に入れる
- 個人では、設計・実装・発表準備まで独力でやりきらなければならない
チームでは、自分の不得意分野に関してはチームメンバーに任せたりサポートを頼んだりできる- もちろん、不得意分野を強いられる経験も面白いものである
- 個人では、一人の知識や先入観の範囲を出ることが難しい
チームでは、自分の思いもよらないこと、考慮できていないことにメンバーが気付いてくれた - 個人では、自身のスキルと興味のままに技術的な挑戦を取り入れられた
チームでは、課題解決の方法をチームが遂行できる複雑度に調整することに重きが置かれた- 技術的な挑戦の優先度を下げ、作業時間に見合うまで要件を間引いていった
- 個人では、競技性や技術的な挑戦の楽しみが大きかった
チームでは、アイデアを出し合い協調する楽しさが大きかった- コミュニケーション・協力・教育に意義を求められる
- 個人では、みな黙々と作業に集中していて静かだった
チームでは、会話が盛んで終始賑やかな雰囲気だった- 他チームが近すぎると自チームの議論の障害になることも
チーム参加と教育
- 若手社員の教育になるようなテーマ、体験をさせられた
- プロジェクトの進行を経験できる
- 要件定義を、他メンバーの補助付きで担当してもらう
- 教育を念頭においた進行の工夫を行った
- 研修段階の新入社員にも楽しいと思ってもらうため、配属予定の分野に絡む課題を選択した
- モデル設計を進める様子や考え方を共有する
- 中堅層以上のエンジニアも課題の進行から多くの反省点や改善点を見出せた
- 若手層のエンジニアも、自分より日の浅いエンジニアのサポートを意識させられた
経験の長いメンバーが自然と教育を意識した行動を取ったのは確かですが、終始経験の浅いメンバーの面倒を見つつ成長を促す……とはいきません。今回は作業時間が極めて短時間であったこともあり、経験者もかつてない切迫感を覚えていたそうです。
「当日に思いつきで発した提案が成果物の完成度を落としちゃった」と反省するベテランもいました。
冷静にチームをリードしているように見えた中堅・ベテラン層も、しっかり慌てていたのだなと親近感が湧きました！
ハッカソンの緊張感や焦燥感はキャリアを問わないようです。キャリアによる熱量の格差が生まれないことは強い魅力ですね。
反省と今後
i Cubed Mini ShipIt! には、改善されるべき点もありました。最後の章に進む前に、しっかりふりかえっておこうと思います。
適切な時間制限
参加者への取材で特に聞かれたのが、時間の短さに起因する問題です。
短時間であるおかげで普段とは質の異なる集中力が発揮でき、時間への挑戦を強く意識できる面はあるものの、今回はそれを差し引いても無視できない不完全燃焼感があるようでした。
- 成果物の完成に到達できず、フラストレーションが残った
- エンジニアとして、最低ラインであっても『完成』と言える成果物を用意したい気持ちが強い
- 前回までは時間があったので、一人でもある程度やりきることを目指せた
- 課題の解決方法の選択や課題そのものがインパクトの弱い内容に留まってしまう
- 時間内にできそうなシンプルな課題やコストの低い課題解決方法を選択する
- 大きそうな課題もあるが、そもそも実装まで辿り着くことを期待されていない
- 最低限の要件を満たすことも危うく感じられ、挑戦の要素を取り入れることには踏み出せなかった
- あるチームでは、同時進行で2通りの課題解決方法を実践することに挑戦したが、とても間に合わなかった
参加者がそれぞれのベストを尽くしたであろうことは各チームの発表から感じられましたが、動く成果物を用意できたチームが僅かであったことは事実です。
だから次はもっと時間を取りましょう――で終わってはもったいないので、他にできる工夫がないか探ってみます。
短い作業時間でも課題を達成してもらうための工夫
例えば、経験の浅いメンバーが多いという条件が明らかなとき、課題候補の収集フェーズからある程度運営が手を加えることはできなかったでしょうか。
運営や経験のあるメンバーを中心に課題を精査して厳選したり、要件の調整をしたり、大きく漠然とした課題の分割をしたりします。
各チームが課題を選択する際の判断材料を増やせますし、漠然としていたために早々に検討対象から外されてしまうような課題にも光が当たり、よりチームに合った課題の選択を実現できるかもしれません。
あるいは、各チームが課題を選択してから当日までの期間に、チーム内での共通認識の作成を推奨するのも良いかもしれません。
課題の認識・成果物の最低ライン・課題に関するアイデアを共有してもらえば、当日は共通認識という土台に支えられ、スムーズに要件や挑戦要素の絞り込みに入れます。
設計を急ぐ経験者についていくだけで必死だった若手も、土台があれば話に遅れにくくなります。そうなると、思いついた工夫やひらめきを表明しやすくなることも期待できそうです。
私が思いついたのはこの2つです。きっと複数人で知恵を絞れば、短時間開催のデメリットを劇的に解消するような工夫も生まれうるでしょう。
そのような工夫を生み出すにも、ハッカソンの運営、あるいは参加の経験は欠かせないと思います。
経験とフィードバックを受け止め、次に活かせる資産に昇華することができれば、少なくともその点において『成功』を得られたと言ってよいはずです。
イベントの企画・準備
「もうちょっと事前準備をしっかりしておけばよかった〜！」とは、運営チームの一人の談です。
いち参加者の私としては、イベントはごくごくスムーズに進行しているように見えたし、トラブルもほとんどなかった(※わずかにはあった)と感じていたので、反省点として一番に挙げられたのが事前準備であったのは意外でした。
具体的に、何を「しっかり」しておけなかったのでしょう。
- ハッカソンの必要条件を満たすだけの企画に留まった
- 会場選定の際に候補会場の下見を行えなかった
- ひとつひとつの決定を急がねばならず、検討を深められなかった
イベントにより高い価値を与えたり、様々なリスクを最小化するための準備のことのようです。
実は本イベントは数週間前に開催が決定したものであったため、開催準備も前回までより少ない時間で進められたそうです。
プラスアルファの企画を用意するには、時間の不足が過ぎたのでしょう。
企画に関しては、単に「楽しい企画を足したかった」というものではなく、価値の最大化のためにできる企画がないかを十分に検討したかったというニュアンスです。
価値ある要素を足したからといって、そのイベント全体の価値が足し算で高まるわけではないので注意が必要です。
角度を変えれば、開催条件を絞りさえすれば手早く用意できたとも言えます。
手早さには過去3回の開催経験がものをいったことでしょう。
イベントの進め方だけでなく、イベントの準備の進め方も、前回までの様式を踏襲するだけでいいのです。チーム制という新様式の用意に時間を割くことができます。
様々な会場を利用したことがあれば、下見を省ける候補になるでしょうし、過去の会場選定時の資料が存在するだけでも0から探すより効率的なのは明らかです。
社内ハッカソンに限らず、様々なイベントの開催実績を積み重ねていけば、急に時間を与えられても「このスケジュールならあれができるかも」と当たりをつけて、余裕を持って開催準備に取り掛かれるでしょう。
過去の開催経験は、それだけで資産になるようです。
社内ハッカソンの成功の鍵
ここまで、様々な角度から社内ハッカソンをふりかえってきました。
i Cubed Mini ShipIt! への参加、ブログ執筆のための取材、ブログの執筆を通して、「成功の鍵はこれだ！」と断言できるものが見つかりました。
「ふりかえりが大事！！」
イベントによって私たちが得た経験や成長に、私たちは気付けていない可能性があります！
私が今回の経験の価値を心から実感できたのは、イベントの当日ではなく、ブログ執筆のための取材中でした。
作業直後に行われた懇親会での雑談も、イベントの締めの総括もふりかえりの役割を担っていましたし、取材前にもハッカソンの意義や役割を調べて知識を深めたつもりでいました。
しかし、それらから価値を思い知るには、少し没入度が足りなかったのでしょう。
『取材』という、イベントのふりかえりをメインテーマにした時間を取ることが必要だったと考えます。
同じ場にいた者同士で経験を共有し、考察を交換しあったとき、私は「これは私が経験したことだ！」と実感や重みを感じることができたのです。
ここだけ見ると、少々間抜けな感想……ですが、似たような経験のあるエンジニアはいるのではないでしょうか？
また、時間を取ったのが開催直後でなかったことも、ふりかえりの密度の高さに良い影響を与えていそうです。
確信はないものの、通常業務のリズムに帰って記憶も新鮮でなくなってきた頃が、冷静に分析するのに適している時期かもしれません。
改めて――。
組織が経験のないイベント開催に二の足を踏む主な理由は「うちのチームでも効果があるの？」という点かと思います。
私にはそれに答えられるだけの経験がありませんが、少なくとも「効果があるかどうかを確かめた経験」は組織の資産になると考えています。
もしイベントの中で効果を感じられなくても、参加者に達成感や満足感を与えられなくても、必ず反省点は得られるはずです。
それは組織の弱点を示唆する重要な情報である可能性もあります。
社内ハッカソンの成功の要件を1つに絞るなら、得られた反省を手がかりにして、組織に必要な改善や挑戦を発見することだと私は考えます。
成功の鍵は適切なふりかえりの実施です。
もし当日に失敗の空気が漂ったら……想像するだけでおそろしいですが、それはむしろ、たくさんの改善と挑戦が見つかる、大成功の予兆なのです。
We Are Hiring!
挑戦を楽しもう！
