こんにちは。プロダクト開発部の 
id:tkdn です。本記事では先日チーム合同で行ったハッカソンと、その成果物デモをディレクターや顧客に近いマーケティングのメンバーの前で行い、フィードバックをもらうまでの話を紹介します。
ハッカソンをとおして個人で獲得できた学びもありましたしチームやほかのメンバーとの協働がよりよくなりました。
そして何よりスピード感のあるアウトプットに対してフィードバックをすぐもらうことの大切さを痛感したので、そんなことも踏まえながらお伝えできればと思います。
きっかけ
今回ハッカソンを実施するに至った経緯はいくつかあります。
- 2022 年度に成果物としたかったプロトタイプのデモアプリに着手できなかった
- 今のチームだけではパワーが足りないという感覚があり本年度から組織体制の変更を見込んでいた
- 以上の経緯も踏まえてマネージャーから Slack で以下のような提案があった
私は二つ返事でやりたいと伝えました。
担当プロダクトの負の部分から脱却するためにデモアプリで実証したいことはありましたし、守りのプロダクト開発が最近は多かったので個人としてもハッカソンに取りかかりたいという思いがありました。
どうやったか
ハッカソンは 5 営業日使って行いました。もちろん普段担当するプロダクトもあるので、アラートや問い合わせがあった場合は普段のプロダクトを優先するという約束です。とはいえ、5 営業日ハッカソンに全ブッパで OK を出してくれたマネージャーには感謝ですね。
私が普段活動を共にしているエンジニアは 2 名ですが、先にも触れたとおり、平時の運用やアラートを並行しながら「ガッと」やるにはパワーが不足してしまうという懸念がありました。そのため事業として関心のある領域は一緒だが普段は別で活動している、お隣チームのエンジニア 2 名（ブログ執筆でも登場している 
id:kudoa が在籍しています）を加え、計 4 名のエンジニア体制で取り組むことにしました。
またハッカソンでは 「何かを丁寧に教える場にせず自律的にやれることをどんどん見つけていってほしい」といったマネージャーの言葉を強く意識し、特に「丁寧に教える場にしない」ということを徹底しました。
ハッカソン参加メンバーの構成上、相対的にキャリアの長い自分自身がモブプロを主導したり（キャリアに開きがあるメンバー間のモブプロはティーチングになりがちです ※ 諸説ある）主体的に教えに行ったりするのはやめておこうと開始前から意識しています。
初日に最終日の勝利条件を決める
正直初日まで何かを準備するということはしませんでした。
私が Slack チャンネルと空のリポジトリ準備だけをして初日を迎えています。
初日にまずハッカソンで取り組んで作り上げたい成果物のイメージをマネージャーが説明しました。なぜそれが検証すべき機能たりえるのか、取り組むモチベーションは何なのか、ユーザーのターゲット層はどこなのか、それらのイメージを元にエンジニアが作り始めるにあたって前提となるアラインメントを行っていきます。
イメージの共有を終えて最後には「成果物のプロトタイプはフロントエンドのみで動作する Angular を使ったアプリケーションで、それを最終日にはデモできる状態にする」といった勝利条件をその場で決定しています。
最終日のゴールイメージ共有後、マネージャーと 4 名のエンジニアで今日の勝利条件を決めていきます。今日の ToDo ですね。
2 日目以降は私が毎朝デイリーで前日のタスク進捗と今日の勝利条件を確認する形で進行していきました。同期的に話す時間は朝のデイリーの時間だけで、あとは必要なタイミングで突発的に同期的に話す時間を作りました。
2 日目の仕切り直し
初日は勝利条件であるそれぞれの ToDo に取り組んでいき、アプリケーションがローカルである程度うごく様が見れるようになったタイミングで壁にぶち当たりました。
ゴールを達成するための How のひとつだった外部プラットフォーム（プラットフォーム A とします）の Web API が、我々が実現したいことにマッチしないとわかりました。
ただそれでも誰もうなだれるようなことはなかった気がします。
アイデアの段階では「こうすれば目的が達成できる思う」にすぎません。
— nishio hirokazu (@nishio) 2023年4月6日
プロトタイプを作ってみると思った通りになりません。これによって、そのアイデアの改善すべきところが見えるようになります。見えれば、さらに改善できます。
「思った通りにならない」は「失敗」なだけでなく、「前進」なのです
これはハッカソン開始前 Slack チャンネルに貼られたツイートですが、初日の段階でピボットできるなんて我々はけっこうやれているんじゃないか・良かったんじゃないか、といった空気が Slack のチャンネルにはありました。私もすぐさま別のプラットフォーム（プラットフォーム B とします）が提供する Web API の使い方を ChatGPT に聞いていました。
ハッカソン参加メンバーがその日のうちに代替となるようなプラットフォームを試したり、次のステップへ進むという動きを見せたりしていたのは、前向きで健全だなとも思いますし驚きでもありました。
メンバーの振る舞い
ハッカソンを通して特徴的だと感じたのは、参加メンバーの振る舞いが自主的でありながらさまざまなバリエーションがあったことです。各人の動きを相互に見る中で、お互いに任せたいタスクの種類が 2 日以降に固まっていたと感じます。
- Angular アプリケーションを率先してガリガリ進める
- アプリケーションのレールで実直に画面を作っていく
- 実現可能性が不明な問題の可否について調査をしつくす
- 必要だなを思われることを先回りして調べておく
平時活動をともにしているわけではないお隣のチームではありましたが、あまり接点を持たなかったにもかかわらず、短期間でお互いの特性を認知しあえたのはハッカソンだけに限らず平時にも役立てられる旨味でした。
そしてハッカソン中も、普段の担当プロダクトに来るお問い合わせやアラート対応もしていましたし、お隣のチームメンバーはライブラリアップデートのリリースまで済ませていました。そういったことも踏まえると、ハッカソンを始める前に「パワーが不足していた」と感じていたことさえも疑うべきだったのかもしれないと感じます。
年配者としてハッカソンを通じて感じたこと
ピボットした 2 日目の夕方頃にはコミットされていくコードを眺めて改善を考えるくらいには落ち着いた状態になっていました。
3 日目にはガリガリ画面を作ってブラッシュアップや改善をしながら機能を足していきました。やはり形ができていく喜びと実装している楽しさが相まるとテンションも高まります。
それと同時に、2 日目中盤あたりから自ら「ああしたい、こうしたい」を先に Miro で雑な画面設計を書いて共有を始めています。さらにその日のうちに手を伸ばせそうなことを ToDo として追加して参加メンバーにタスクとして取っていってもらうなど促しもしました。振り返って感じますが、スピードを落とさずにハッカソン合同チームを運営する工夫もできたなという実感もありました。
また普段はあまり言わない・書かないようにしているんですが、3 日目後半くらいからメンバーになぜこのコードの方がよいか・どうしてそちらを選んだのかなどを Slack で解説し、後続するコンポーネントにメンバーが反映できるくらいには余裕のある開発ぶりでした。
メンバー間のフィードバックでより良いものへブラッシュアップするということもできています。メンバーそれぞれが「ハッカソン初日に思っていたよりめちゃくちゃ良くなってうれしい」といった気持ちでデモに臨めたのは本当によかったですね。
5 日目途中でインフラチームに許諾のないままパブリックアクセス可能な S3 バケットを作ってしまいセキュリティ警告検出の連絡を受け平謝りするなどのヘマをしてしまいましたが、5 日目の夕方にデモする直前まで改善と機能追加を続けました（もちろん作成時点で検出されているのでバケットにファイルはありませんでした）。
成果物とフィードバック
成果物のデモには、普段のプロダクトチームのディレクターを含んだディレクション部から 2 名とマーケティング部から 1 名参加してもらいました。普段からユーザーのインサイトを得るためにユーザーインタビューの接点を持ってくださったり、学校訪問時に同席していろいろ教えていただいたりとお世話になっているメンバーばかりです。
デモは私の方で画面と機能説明をさせていただき、そのあといくつかフィードバックをいただきました。以下にいくつかフィードバックを紹介します。
- 現状の〇〇画面ではたとえば「数学、数 Ⅰ、平方根」と教科や単元を掘っていくと 3, 40 個くらい候補がリストアップされてしまう。ユーザーにどう選んでもらうかは大事なので生徒の判断材料になるものが何なのかは見出して今回のアウトプットをブラッシュアップできるとよい
- 単元が紐付いているのであれば学トレ（※ 本年度順次リリースされる学習トレーニング機能）での解答後に関連するリンクをつけるという小さな連携からスタートすることも可能そう
最初に画面を見せて「すごい！」と言ってもらえたのは素直にうれしかったです。何より単に「ハッカソンでアウトプットした」にとどまらず、フィードバック内容の吟味や今後について話す中で新しいアイデアや進め方のヒントがでてきたこと、また現実的に前に進められそうだという手応えをフィードバックの中から得られたことは、将来的なプロダクトの方針を見定めていくうえでも重要な対話になったと感じました。
まとめ
ハッカソン前に読んだ書籍だったのですが継続的デリバリーのソフトウェア工学という本の一節そして内容が、妙に今回のハッカソンとリンクします。
ソフトウェア開発は、基本的に学びと発見の分野なので、成功するためには学びのエキスパートにならなければならない。
ハッカソンという短期間のイテレーションで、実験的でかつ漸進的に実行し何よりフィードバックを受け経験主義的に積み重ねを繰り返していくことの重要性に気付かされました。また、そういった現代的なプロダクト開発の営みとしての「当たり前」を普段からできているかといった問いを投げかけられたように感じ、反省も多かったです。
今日はハッカソンとフィードバックをもらうことの重要性について書きました。
長い文章を最後までお読みいただきありがとうございます。
