運動会エンジニアの気遣い

第2回に引き続き、第3回 未来の山口の運動会とスポーツハッカソンにテクニカルスタッフとして参加してきた。

運動会エンジニアを名乗ったことはないけれど、2回連続で呼ばれたらもうそういうことでいいだろう。自分で言うのもなんだが評判も良さそうだし。

僕は運動会エンジニアです。

運動会エンジニアとは？

運動会ツールや、それを使った運動会種目、あるいは運動会そのものをつくったりつくるのをサポートしたりするひと。
（ここでの運動会は、主に未来の運動会を意味する）

運動会種目に使われる可能性のあるツールの使用方法や起こりうる危険について熟知していて、そのツールを使って種目を作りたいデベロップレイヤーの発想を具現化する手伝いをする。
ときに一緒に発想し、試行錯誤し、課題を解決する。

例えば「振るとカウントアップするこのツールを、攻めと守りが切り替わったら2倍の速さでカウントダウンするように変更したい」とか「このセンサーをおでこにつけて走りたいので無線化したい」とか「床でボールがバウンドするたびに、床面のセーフゾーンが削れていくような映像を出したいんですができますか？」みたいな要望に対応したり考え直してもらったりする。（内容はフィクションです）

下記にて、僕が思う運動会エンジニアに必要な、またはあった方が良い視点や能力について列挙する。

ちなみに僕がプログラマなので、運動会エンジニアは前提としてプログラマであるように読める記述があるかもしれませんが、木工でもファシリテーターでも記録係でも運動会エンジニアに分類されうる場合はあると思います。

「とりあえず作」らない

デベロップレイヤーからの要望に全て対応していては時間が足りない。試してみなきゃわからない面白さというのは確かにあるが、スポーツハッカソンでは時間は試行錯誤のための貴重な資源。
ひとたび何かに時間を使う判断をしてしまうと、それが終わるまで他の要望への対応を待たせることになってしまう。体はひとつしかない。
「作らなくてもわかることだった」「作ったが何も得られなかった」は最悪。避けたい。作るべきタイミングを見極め、資源を浪費しないために念頭に置いておくべきことがいくつかある。

1. 人力でできることは人力でやる
例えば「このボタンを5回叩いたら勝ち」みたいなルールが面白いかどうか検証したいとき、ボタンを叩いた回数をカウントするプログラムや、5回に達したらカウントをやめるプログラムなどを実装してから検証するより、人がカウントする方が圧倒的に早い。

プログラムでやろうとすると「やっぱり10回にしてみよう」「ボタンを叩くんじゃなくて足踏みにしてみよう」みたいなルールの試行錯誤をしたい場合にいちいち時間を取られる。
試行錯誤を10回やるとして、1回の修正に平均10秒かかるとしたら100秒使う。これが人力での試行錯誤だとほぼゼロになる。

いくら柔軟に作っても「とりあえず人力でやってみよう」より早くは絶対にならない。

2. 要望の曖昧さを潰してから作る
相談を受ける際、相談する側が要望を正確に表現できていない場合も多い。
「それ言われた通りに作るとこうなっちゃいますけど、これであってます？」とか「多分やりたいことってこっちですよね？」とか「このセンサー複数個使います？その場合は区別する必要あります？」とか聞く。人によっては「この人自分が手動かしたくないからいちゃもんつけて諦めさせようとしてるんじゃ？」って思われかねないくらい聞いてる。（実際そう思われたらいけないので言い方には気をつける）

曖昧さを残したまま作ってしまうと、再度修正がきて時間が無駄になる。自分の時間もだが、デベロップレイヤーも、遊んでみて考えて要望を再度まとめて・・・という決して短くない時間を無意味に消費する。
最悪の場合は誰もその曖昧さに気づかないままハッカソンが進行し、取り返しのつかないタイミングで表面化する。避けたい。

要望に曖昧さがあるのはデベロップレイヤーの自己責任で片付けて良い話ではない。言われたものをそのまま作ることが運動会エンジニアの仕事ではない。

3. 思いついた提案はする
例えば「重いものを持ち上げる種目で、選手の肘に曲げセンサーをつけて力のかかり具合を可視化したい」みたいに要望がある程度具体的な場合に、もし元の要望をもっと理想に近い形で実現できる別の道が思いつく場合は提案する。
例えば「筋電センサーの方が、表面化していない力も捉えられますよ」とか「床に圧力センサーを置いとくと、情報の性格はちょっと変わっちゃうけど着脱の手間がなくなりますよ」とか。

多くのデベロップレイヤーたちは運動会エンジニアよりもその場にあるツールや運動会の運営について深く知らない。

顧客が本当に必要だったものの話ではないが、言われたものをそのまま作ることが運動会エンジニアの仕事ではない。

とにかく早く作って見せる

作るものが見えたら、できるだけ早く作って見せる。細かい値の調整とか見た目の稚拙さとかは後回しで良い。デベロップレイの時間は限られている。試行錯誤には回数と精度が必要。例えるなら「グリーンに乗るけどホールインワンにはならなくて良い」精度で見せる。この段階での目的は「アリかナシかを判断できる」こと。

というか、前述の1.2.3.をくぐり抜けたものはそれ以上何も考えずに作ってもグリーンには乗るので、ここで意識したいのは作り込まないことぐらい。
その種目に関しては、運動会エンジニアよりもデベロップレイヤーの方がより長い時間、より真剣に考えている。作り込むのはデベロップレイヤーに任せるか一緒にやるかする。

エンジニアの思い込みで作り込んでしまうと、そんなつもりはなくてもこれが完成系だと思われかねない。
少しくらい違和感を持ってもらった方が「もっとこうしたい！」の発想が生まれやすい。

作ったものが使われなくても腐らない

とはいえ、意外と面白くなかったり予想外の発展を見せたりで、書いたプログラムが全棄てになることはある。そういうときは躊躇なく棄てる。デベロップレイの時間は限られている。試行錯誤には回数と精度が必要。後ろを振り返っている時間はない。

デベロップレイヤーたちが、せっかく作ってもらったし使わないのは申し訳ないな・・・となるのは本当に本当に最悪なので、マジで躊躇なく平気な顔で棄ててすぐ次の話へ進む。自分から方向転換の提案をするのもアリ。

逆に言うと、棄てることを躊躇してしまうほどの時間をかけて作らない。

来そうな要望を予測しておく

ハッカソン中にどんな要望がくるか、前日までに予想されるものについてはやるやらないの判断も含めて先に対応を準備しておくのが理想だが、現実にはそんな時間はなかったり、技術がなかったりする。

しかし当日であれば、各チームがどんな流れから今のアイデアに至っているか、会場で人気のあるツールは何か、など情報はたくさんあり、要望が来たときに（だよね！それやりたいよね！）と思うことはよくある。

せっかく思いつくんなら、空いている時間に先回りして作っておくと良い。
- よりデベロップレイに時間を使えるようになる
- 作ってみなければわからない落とし穴に先に気づける
- デベロップレイヤーの自信になる
- めちゃくちゃ尊敬される
と、いいことばっかりだし、何か違う要望が来てしまっても手を止めれば良いだけ。完成しなくても問題ないし、使われなくても問題ない。

そのために、空き時間があれば各チームの進捗をみて回ったり、一緒に遊んでみたり、自分ならどんな種目に仕上げるかをイメージしたりして過ごす。

「面白さ」を「わかりやすさ」でドライブする

ここでいう種目の面白さとは、選手及び観戦者がその種目のどこに魅力を感じるかという点。

運動会エンジニアが作るのは種目の「面白さ」ではなく「わかりやすさ」。例えば「先に地団駄を100回踏んだ方が勝ちの種目」が地味だからといって、かめはめ波とギャリック砲のぶつかり合いみたいな映像を作っちゃダメで、たぶんディスプレイなり床面プロジェクションなりで選手の近くに数を表示するだけで十分。
踏むごとに音を鳴らすとか、100回達成した瞬間にちょっとした演出を加えるとかはやっても良さそう。

大事なのは、観戦者の視点に立ったときに
- その要素があっても選手に目が行くかどうか
- その要素がなくても楽しめるか
- その要素があることで選手が何を考えているかがより想像できるか
という点。

無責任になる

繰り返すが、種目の面白さを作るのはあくまでデベロップレイヤーたち。運動会エンジニアは、その面白さを選手や観戦者にわかりやすく伝える役割を担う。
言い換えれば、その種目は運動会エンジニアがいなくても面白くなくてはいけない。
「なーんかひと味足りなくて面白くないんだよなー」みたいな相談がきても、エンジニア的な手法でなんとかしなきゃと動いてしまうと結局上滑りするので、ほっとく。任せる。

運動会エンジニアとしてはほっとくが、スペースマンシップに則り、ゲームデザイナーやいちデベロップレイヤーとして面白さを作ったり提案したりするのは全然あり。これはやってる。

-----

たぶんまだまだたくさんあるはずなので思いついたら追記していくショゾン

-----

いろいろと偉そうに書きましたが、僕がこれほど自分のやるべきことにフォーカスして考えて実践できるのは、ひとえにYCAMや外部招致のスタッフの細やかな気配りや機転、愛の深さ、YCAMの設備環境の良さ、運動会協会のコンセプトメイキング、デベロップレイヤーたちの真摯さがあってのことだということは最後に申し添えておきます。
僕も環境になりたい。

-----

この記事では主にデベロップレイの場での気遣いや心構えについて書いてるけど、運動会当日や運動会ツールを作るにあたってのエンジニア目線での心構えについてもそのうち書きたい。