ITと哲学と

IT系エンジニアによる技術と哲学のお話。

会社でハッカソンをやってみた 進め方編 1

前回のきっかけ編の続きです。

ハッカソンをどう進めるか？を考える

ハッカソン自体の進め方についても色々と考えることがある。

何に時間を使うか？

全体に大きく影響する要素として、何に時間を使うか？という観点がある。

例えばGVCの言っているようなデザインスプリントを見てみると、5日間のうち、3日間は何を作るか？に時間を使い、1日でモノを作って、1日で検証をする。 通常のモノづくりでは、「どう作るか？」よりも「作ったモノが解くべき課題はどれか？」という問題の方が100倍くらい大事だと僕は思っているので、このくらいの割合には納得感がある。

逆に、作ったものが解くべき課題をあらかじめこちらから指定して、それをどう作るか？に集中させる方法もある。 こうすることで、何を作るかに時間を割く必要がなくなり、どう作るか？という技術的な課題にのみ参加者をフォーカスさせることができる。

ここでも目的とやらないことによって実施内容が変わる。

今回はイノベーション起こして云々と言ったものはスコープ外なので、何を作るか？については重視しない進め方にすることとした。とはいえ一方で、自主性というキーワードがあるので、こちらから解くべき課題を指定するような進め方も片手落ちになる。

そこで今回は、半日で作るべきものを決め(これをアイディアソンと呼ぶことにした)、残った時間でそれを組み上げるという時間の使い方にすることにした。 また、経験から学習しそれを身につけるための振り返りと、ある種のプレッシャーとして働くことを期待した発表会を最終日の半日に入れ込むことにした。さらに発表会を盛り上げるために発案者の上司の独断と偏見で優秀チームを選んでもらい、表彰するような建てつけとした。お祭りのような感じで盛り上がる会にしたい。

さらにさらに、経験から学びを得て今後の業務に活かしてもらうことを目指してチームごとの振り返りの時間も確保することにした。

アイディアソンをどう進めるか？

では半日のアイディアソンをどう進めたらいいのだろうか。 想定するターゲットはどうするべきか。

限られた時間の中で、ターゲットに絞って価値を提供するためには、ある程度すでに理解が進んでいるターゲットである必要があると考える。全く普段考えていないようなターゲットだと、相手を理解するところから始めなければならず、時間がかかってしまう。

ということで今回は、我々が普段の開発でターゲットとしている「情シスさん」を設定することにした。

アイディアソンの目的

決まった時間でチャレンジすべき問題を決めきる。ターゲットは情シスさん。

実施方法概要

ターゲットにヒアリングをして困りごとを引き出す。 解決策を考えて、ターゲットに当ててみてフィードバックを得て、ブラッシュアップして結論を出す。

ゴール時に達成したい状況

「〇〇という問題を、△△を利用し××することで解決する」という形で結論を出す。ハッカソンでは上記を実装していく。

具体的な進め方について

具体的な進め方については運営チームでプレ実施を行い、時間的に・仕組み的に無理がないか確認しておくと良い。実際に実施してもらう人たちの気持ちもわかるだろう。今回記載している内容は、プレ実施を行なった結果、あんまり良くなかったねとなり、実際に本番では大きく組み替えた。ここら辺の詳しい話は次回。

1.課題「〇〇」候補の収集　0.5H

ターゲットにヒアリングして解決すべき課題の候補を収取する。 普段の仕事で感じる課題について話してもらう。 話の中から出てくる問題点を「どうしたら◇◇◇できるか？」と言う形で付箋にメモしまくる※。

※ ここら辺はデザインスプリントから拝借している。

ヒアリングが終わったら付箋を壁に貼り付けて、チーム内でお互い共有し、得られたモノの共通認識を作る。

2.サービス「△△」候補の収集 0.5H

世の中で利用可能なサービスを可能なかぎりいっぱい集めてもらう。 これはチームごとではなく、全チームで最終的に共有するのがポイント。

チーム単位で見ると課題候補に近しいものばかり集めることが懸念されるが、それらを集めることでいい感じにばらけることが予想できる。

3.結論案「〇〇という問題を、△△を利用し××することで解決する」を作成 2.0H

1と2を組み合わせて、結論案をチームごとに作る。 組み合わせで考えることによって思わぬ発見やアイディアが生まれる可能性を作り出す。

いくつか結論案を作る。

4.結論案をターゲットに説明し、フィードバックを得る 0.5H

再びターゲットにヒアリングしてフィードバックをもらう。 1発の思いつきで正しい結論に至るわけがないので、ターゲットからフィードバックをもらう。

5.フィードバックを元に、結論案をブラッシュアップし、結論を得る 0.5H

フィードバックを元に、各チームで話し合って、結論を得る。

このように作られた結論「〇〇という問題を、△△を利用し××することで解決する」をハッカソンの中で開発する。

前述の通りこの方法は、プレ実施時点であまりうまく行かなかった。 問題は「お客様の声を聞きすぎてしまい、自分たちがワクワクするものづくりができない」という点だ。 ここら辺の詳しい内容は次回の記事で書くと思う。