MBSラジオより先日公開された「トラなび」アプリ。
このブログを読みに来る方の中にはご存じの方も多いと思いますが、これは第二回MBSハッカソンから生まれたアプリです。
絵にかいたもちに終わらず実際にこうして世の中に出せたということは大変に意義のあることだと思っているので、ハッカソンからリリースまでの経緯などをこのブログに記しておきます。
書いているのはわたくし、技術担当の宇都宮です。
ｗｉｔｈＴｉｇｅｒｓ ＭＢＳベースボールパーク公式アプリ MBSトラなびhttp://www.mbs1179.com/toranavi/
ハッカソンって？私の定義
この技術屋のブログを読みにくるような方で、まずそもそもハッカソンについて知らない方はいないと思っています。しかしながら、ネットなどで発信されてる方々の意見を読むと、人によって「ハッカソン」という言葉のとらえ方が違うと思われる部分もたくさんありますので、私が考えているハッカソンとは何かをまず表明しておきます。
「いや、おれの知ってるハッカソンとは違う」とひっかかる部分もたくさんあると思いますが、全て私が体験して見聞きしたこと、つまり私の半径5メートル程度の観測範囲内での世界で決定された定義ですので、「お前がそう思うんならそうなんだろう、お前の中では」と思いながら読み進めていただければ助かります。
ご存じハッカソンとはハックとマラソンをかけた造語ですが、もともとは次世代の若手を研修する教育的なプログラムの意味合いが強いものでした。
製品化へのフローを模擬体験させることで、物作りへの技術力やチームワークなどをいっぺんに学べるための研修プログラムという印象が最初のころは強かったのです。私がハッカソンという言葉を初めて聞いたのは、2010年になってからあたりだと記憶していますが、この時点では「すでにクライアントワークをやっている自分らには関係ないものだな」と考えていました。
そこに、私のハッカソン感をくつがえす、すごいイベントが開催されました。
スーパーハッカソンというものです。
このスーパーハッカソン、以後スッパソンと略称しますが、スッパソンのすごかったところはいくつかあります。
ひとつは、スッパソンでは実際に製品化をめざしたこと。正確には実際に製品化を見据えたプロトタイプとそのプレゼンを求めたことです。
それまでのハッカソンは製品化についてはほとんど模擬体験にとどまっている状態で、そういう意味ではオープンな新人研修の域を出ていませんでした。それに対してスーパーハッカソンでは実際に製品化できるクオリティを要求したため、ぐっとガチな感じが増してきました。
ふたつめは、賞金を用意して勝負性を高めたこと。
もともとのハッカソンでは、いちおうやってる程度の意味しかなかった順位付けを、スッパソンでは「商品とかケチなこといわんから、カネだカネ。優勝者は賞金総取り！」を掲げたため、ぐっとガチな感じが増してきました。
みっつめは、開催期間に1週間という期間を設けたこと。
それまでのハッカソンは、一泊二日という設定が多く、これが研修プログラムっぽさの原因となっていたのですが、スッパソンでは開発期間に1週間を設定しました。この期間設定がプロトタイプまでを作る期間としてとても絶妙で、ぐっとガチな感じが増してきました。
どれも今でこそ当たり前の仕様ですが、スッパソンでは「おまえら賞金と開発期間やるから、どれだけガチなもの作れるかやってみい。できるやろ？」という挑戦状をわれわれに叩きつけてきたのでした。
これ以降、私の中ではスッパソンとそれ以外という区別しかなく、スッパソン以外の中ではスッパソンヴァリアントとそれ以外としか区別していない、それくらいスッパソンは影響力の大きいものでした。
スッパソンがすごかったのは、それまでのハッカソンだけでなく作品コンテストそのものの流れもかえてしまったことです。
それまでの作品コンテストでは実験的な作品が作りやすく、「確かに面白いけど、誰がつかうねんこれ」といった作品を作ってしまいやすかったのですが、スッパソンでは「実際に製品化を目指す」ことに競技性をもたせたので、より実践的な作品を作ることに成功したのです。
ただ夢物語みたいなプロダクトだけでは勝てず、かといって製品化を目指しただけも勝てない、この絶妙な作品の置き方が、スッパソンをおもしろくした最大の要因でした。
そう、ながながとスッパソンの説明をしましたが、「実際に製品化を目指す」ということが私にとっていかに大事だったか、読者にこれを知ってもらいたかったのでした。
補足というか蛇足
前章で「確かに面白いけど、誰がつかうねんこれ」というキーワードが出ましたが、私はこれをネガティブなものと考えていません。
そういった技術や表現の研鑽の積み重ねの先に、ユーザーやクライアントにとって素晴らしいインターフェースや体験を生み出せるのだと信じているので、「面白いけど誰がつかうねん」の失敗と成功をたくさん繰り返しながら新陳代謝していくことは必要だからです。
急に誰かが思いついたような「ぼくのかんがえたさいきょうのUI/UX」は、世に出るまでにたくさんの検証が必要ですが、そのための受け皿として作品コンテスト文化はとても素晴らしいものだと私は考えています。
スッパソンは、その新陳代謝を異様なくらい速めたのです。
MBSハッカソン
MBSハッカソンがどういった催しだったかについては、以前に記事を書いてありますのでそちらをご参照ください。
第二回MBSハッカソンもミラクルな楽しさだった
晴れて製品化も果たしたことですので、今回はMBSハッカソンでのうちのチームの戦略などを書いてみます。
まずハッカソンに参加して、うちのチームが重要視した至上命題は、「ハッカソンを楽しむ」です。
「勝ちたい」とか「優勝したい」とか「賞金50万円ほしい」とかの目的は、全て「ハッカソンを楽しむ」の下位に属していて、「勝つことでハッカソンを楽しむ目的を果たせるなら勝ちたい」であり「優勝することでハッカソンを楽しむ目的を果たせるなら優勝したい」でした。
なので、「ラクをした結果、楽しめると思うんならラクすればいいし、楽しむために苦しむなら苦しむのもいい」です。ブラックですね。
この「ハッカソンを楽しむ」を至上命題と掲げた上で、今回うちのチームがとった戦略はこちら。
「プレゼン大事。プレゼン命」
そのための方法はこちら。
「プレゼンのリハーサル大事。プレゼンのリハーサル命」
100人の聴衆を1分退屈させることは、ひとりの人間を100分退屈させることに等しいです。
放送局が最も嫌うこの「退屈」。まずこれを徹底的に避けました。
具体的な方法は、プレゼンのリハーサルをビデオに撮って、見直すことです。
本番プレゼンには8分の時間を与えられていたので、自分達のプレゼンをビデオでみて、8分間の視聴に耐えられるものになるまでクオリティを高める努力を繰り返しました。
言葉にすると簡単ですが、何でもいいので自分で8分間の発表を撮ってみて、それを見返してみてください。
8分間、視聴に耐えられなければやり直しで、いろいろプレゼンを工夫しながら8分間の視聴に耐えられるまでになったらそれがスタートラインです。
そこから、最後は少し感動を及ぼすような、もうちょっと聞きたい！と思わせるような、そんなビデオになるまで工夫をくり返します。
ふだん、仕事としてウェブ制作でやっていることを、プレゼンに応用しました。
リハーサルが大事なのは、それだけではありません。
私は、MBSハッカソンに2回参加しているのですが第一回目は「音声認識によってコントロールされる血のり」がうまく動作しなかったために技術点で後れをとり受賞を逃しました。
あれは、技術屋にとっては「うまく動作しなかったのではなく、完璧に動作したからこそあの場で血のりが出なかった」結果なのですが、発表の場ではその言い訳は通用しません。
どういうことか少し説明します。
プレゼンの流れとして、
Aパート→Bパート
というパートで実演を行いました。
それぞれAパートもBパートも完璧に動作させるために、時間いっぱいまで開発とテストをくり返しました。
そのため、通しのリハーサルをする時間が取れず、Bパートで動作させるための機能がAパートの時点で「確実に動作してしまったため」Bパートでは動作し終わった後のためうまく機能していないという失敗をしました。
いわゆる「単体テストでは完璧だったのに結合テストでバグが出た」状態に近いですね。
ただ少し違うのが、実際に製品化を目指して開発したので、プレゼンの動作そのものが想定外だったことでした。
つまり、技術者としてはあれはあれで完璧であり、プレゼンの動作こそがイレギュラーだったと言い訳をしたいところではあります。
ただし、ハッカソンではそういう言い訳は通用しません。
われわれにできることは、与えられた1週間をどうつかって、与えられた8分にどういう印象をもってもらうか。のみです。
なので、第一回目に経験した失敗を踏まえて、第二回目では徹底的にプレゼンのリハーサルを意識して開発しました。ハッカソンに次はありません。
実際に製品としてすぐにでも世に出せる状態を保たせつつ、プレゼンでも動作させるために、システムにはかなり冗長性をもたせました。
最悪の場合、ネットワークに繋がらなくてもスタンドアロンで動作させるようにしています。
そのためにもリハーサルを重ねるのは必要でした。
プレゼンモードというイレギュラーな動作を確認するため以外にも、プレゼンの流れが秒単位で把握できていたら、最悪の場合はスタンドアロンモードとしてあらかじめ指定されたタイムラインに沿って動作するように仕込めるからです。
そこまでする必要があるの？という声もありますが、必要です。
なぜなら、実際にもしパフュームのライブステージやテレビの生放送の仕事を任されたとき、いざとなったら「ネットワークがエラーで動きません」が通用しないからです。
そして、ハッカソンの聴衆は、パフュームではなく私たちの発表を見にきてくれています。
見にきてくれた人に、「パフュームほどではないにしろ、宇都宮さんたちの発表はおもしろかった！」と思ってもらいたいからです。
蛇足ですが、パフュームのライブステージと書きましたが、もちろんそんな予定はいっさいありません。
しかしながら、その可能性を潰して仕事をすることは、自分の未来の可能性を自ら潰していくことに等しいです。
せっかく咲いた遅咲きの花、ただでさえ40男の伸びしろは厳しいのに、もっといろんな仕事がしてみたいです。
製品化までの流れ
ハッカソン作品の製品化がなぜ難しいのかというと、開催側の責任と負担が大きいからです。
開発側ではなくて、開催側です。字面も似ているので区別しにくいですが、MBS側の負担がとても大きいのです。
トラなびの製品としての説明はあとに書きますが、実際にサービスとして運用していこうとすると、「とりあえずやってみるか」では済まない部分がたくさん出てきます。これはひとつの事業なのです。
MBSさんは、この、「とりあえずやってみるか」の熱量がすごかったことが、製品化の鍵でした。
「とりあえずやってみるか！！！！！！！！！！」くらいありました。びっくりマーク１０個ぶんくらいです。
「なんとしてもハッカソン作品を世に出したい！！！！！できるところからとりあえずやってみるか！！！！！！！！！！」という気持ちが、ものすごく伝わってきました。それも一人からではなく、たくさんの社員さんから。
ハッカソン以降、MBSさんから「あれを実際に製品化したい」という打診はいただいていたのですが、1月あたりから実現させるための社内調整などを行って、実際にGO!が出たのが2月上旬、そして2月中旬下旬を開発期間にあてて、タイガースの開幕戦に間に合わせるために3月上旬にはiOSのアプリの審査を出す、というスケジュールで動きました。
社内調整に関しては、もちろん全ての方の協力無くしては実現は不可能でしたが、特に福本さんという方が精力的に動いてくださって、不可能を可能にしました。
ハッカソン作品製品化史というものがあるなら、後世に語り継がれるべき奮闘を果たしました。福本さん本一冊書けるんちゃうかな。だれかテック系メディアの方々、福本さんにインタヴュー記事いかがですか？
開発
この章は少し技術的な説明多めになります。よくわからない場合と書いてる技術レベルが低すぎて笑える場合、読み飛ばし推奨です。トラなびとはどういうもの？までぐぐっとスクロール。
読み飛ばすのが苦手な方も、読んでる風を装って目をすべらせておけばOKです。
独学でMVC開発手法などを勉強してもう10年以上になりますが、今回のは特にMVCの手法がうまくいった開発でした。
アプリ側は、まず製品モードとプレゼンモードとネットワークスタンドアロンモードの3つにモデルを抽象化しました。
ここが特にうまくいったので、製品化にむけては製品モードのモデルを少し手直しすることで、あとはビューのアセットを変更するだけでじゅうぶんに納品品質に耐えるものになりました。
トラなびのように、ビジュアル部分がアプリの動作性に密接に関わってくるような場合、今まではMVCの切り分けがものすごく大変でした。
例えば物体のX座標Y座標はモデルが保持するべきか。スクリーンサイズは明らかにモデルの性質が強いのに、ビューと切り分けにくい、特に今回は物理演算のエンジンをどう切り分けるか、など独学で習得するのに時間的な限界があり、今まで失敗続きでしたが、今回はかなり自分なりに切り分け方のルールが明瞭になりました。
まず、限りなくビューに近いモデルの存在というものを認めました。
自分の言葉では、こんな感じです。
「ビュー層」
「ビューに近いモデル層」
「ビジネスロジックに近いモデル層」
「コントローラー層」
大事にしたのは、「ビューに近いモデル層」をビューともビジネスロジックとも切り離したことです。
今まではここがどっちかに曖昧になって失敗していました。
そして、今までもどうしても「モデルのふるまいを知らなければいけないビュー層」と「ビューのふるまいを知らなければいけないモデル層」が存在してしまっていたのですが、今回は「どうしてもビューとモデルのふるまいを知らなければいけないものはメディエイターに逃がす」ことを徹底したので、これが成功しました。
とくに今回、物理演算をインターフェースとして使用しているので、このふるまいをどう切り分けるかが課題でした。
結果的には、
ビュー層
スクリーンサイズモデル層
スクリーン座標モデル層
物理演算モデル層
その他のビジネスロジックモデル層
に完全に切り分けて、物理演算管理下にあるオブジェクトには全てIDを割り振り、ビューとモデルはそれぞれ変更があった場合IDを持ち回って通知することにしました。
ビューとモデルをまたぐ通知は全てメディエイターが受け持って、ビューとモデルはお互いを知らないままメディエイターだけがそれぞれの通知のやりとりを伝える役割に徹しています。
答えを書いてしまうと簡単ですが、ゼロからここまで再発明するのにとても時間がかかりました。
ここを完全に切り分けられたことによって、物理演算のタイミングやサーバーからのデーター更新のタイミング、ビュー側の演出のカットインなどのタイミングを自由に入れる事ができるようになりました。
サーバーサイドは、AmazonAWSを使用しました。
特にアプリにバックエンドで情報を配信しているのはS3をつかっていて、これが「止まることを絶対にゆるされない」放送局ならではのサービスに貢献しています。
AWSについて今さら特別語ることはないですが、絶対に止まらないサーバーを私のような個人が担保することは今までは難しかったのに、テレビ局に納品出来るサービスを実現させるための堅牢なサーバーを安価に調達できるようになったのはクラウド技術さまさまです。
実はハッカソン直後、まだMBSさんから製品化の話が出る前からAmazon社に直々にお声がけいただいて、うちみたいなところにぜひともAWSを使ってほしいからということでAWSについての勉強も始めていたのでした。
これがものすごくいいタイミングになりました。
私がはじめてAWSに触れたのは、もう１０年ちかくも前のE2サービス発表当時でした。
当時E2を触ってみた感想としましては、クラウドリソースの恩恵などは感じつつも、サーバーの保守運用は結局自分でやる必要があり、自分にはあまり必要無いものだと判断して社内ツールの開発にちょっと使ってみる程度から、いままではAWSについてはあまり重要視していませんでした。
どうしても私一人しか技術者がいないような自営業の場合はサーバーの保守運用に開発の手をとられてしまうからです。
セキュリティパッチひとつあてるだけでも、検証サーバーを立ててミラーリングして検証した後、本番サーバーにも適用しなくてはいけなくて、それも一手間違えただけでもデーター紛失やサービス停止の危険性があるので、サーバーの運用までを自営業で請け負うのはリスクがありすぎるのです。
実際にトラなび開発のGOがかかる前に、懸念事項としてサーバーの保守運用をどうするかという問題点が浮上しました。
MBSさんとしては、サーバーの保守運用という非常にセンシティブな問題を、外部のわたしたちにまるなげして良いものかどうか（このへんの問題意識にも、MBSさんのもつハッカソン出場者を大切にする気持ちが表れていると感じました）、かといってサーバーを社内で持つとしてその保守運用などの内部調整をどうするかなど、問題点はたくさんあるからです。
そこを全て解決できたのは、今回使用したAWS S3をメインに持ってきて管理画面からアプリのバックエンドまで全てをサーバーレスで運用する手法をとったからでした。
今さら私が言うことでもないですが、ハッカソン作品の製品化事業化にむけて、サーバーサイドのクラウド技術は絶対になくてはならないものだと思います。
あと特筆すべき点として、フロントエンドからサーバーサイドまでを全てECMAScript群で開発しています。
アプリはAdobe AIRを使用してiOSからAndroidまでを同時開発しています。iOSのリリースが遅れているのは、単にApple審査のタイムラグだけです（もちろん、これが一番厄介なのですが）。
サーバーサイドは、AWS SDKを使うことで管理画面さえもJavaScriptのみで動作します。
これの何がすごいかというと、管理画面はサーバーを立てなくてもhtmlファイルをブラウザさで開けばそのまま動作することです。ただのファイルのやりとりだけで、デザイナーも実際に動作する画面でデザインできますし、いざとなれば実際の運営もhtmlファイルをブラウザで開けばできてしまいます。
管理サーバーを立てなくていいので、サーバーの乗っ取りを心配する必要がありません。万が一、管理画面ファイルが外部に漏れたとしても、AWS側で接続もとIPアドレスの制限さえかけておけば、充分な実用に耐えうるセキュリティが確保できます。
私はクラスベースの開発が好きなので、素のJavaScriptでは弱い点をCoffeeScriptを使うことで補いました。
テレビの仕事に限らずですが、どうしても仕様変更の多い開発現場になりますので、サーバーサイドからクライアントサイドまでを一貫してECMAScript系で行えたことは、お互いのデーター処理の流れやクラス構造も似通わせることができて、とてもいいアドバンテージとなりました。
あと、完全サーバーレス運用は、開発サーバーと本番サーバーの環境の違いを気にしなくていい点も有利になります。
サーバーごとの差異を吸収する開発ができるのが理想ですが、実際にはいろんなレイヤーで問題が多く、さまざまな原因で「開発サーバーでは動いたのに本番サーバーでは動かない」状態に怯えることになります。
サーバーレスだとそれがないのは大きいです。
もちろん、こんどはブラウザごとの差異やクロスドメインポリシーなどの問題も出てきますが、そしてこれがまたなかなかに厄介なのですが、そのリスクを踏んででもサーバーレスで運用できることは恩恵が大きいと言えます。
トラなびとはどういうもの？
この記事執筆時点（2016/04/04）ですでにAndroidはリリース済み、iOSは審査中ですので、どういったアプリなのかは実際に使っていただいて、おのおので感想をもってもらうとして、このアプリの性質について説明します。
まず、テレビのハッカソンに参加した直後という時点まで話しをさかのぼります。
われわれは、アイデアにある制限を加えました。
それは「スマホをサブディスプレイ化させない」ということと「双方向性にしない」「視聴者参加型にしない」「大いなる抽選をしない」ということです。
これらは全て、自分達に課した制限であり、他の人のアイデアを否定するものではありません。
われわれは、アイデアを膨らます手法をとらずにアイデアを絞っていく手法をとっただけです。
ひとつづつ説明していきます。
「双方向性にしない」「視聴者参加型にしない」
これらは、テレビ放送がはじまったときからテレビ局が挑戦し続けていることで、単にわれわれが画期的なアイデアが思い浮かぶ力量がないから捨ててしまった部分です。
実際にITとの融合ではここを期待されていると思うだけに、自分達の残念な点であります。
「大いなる抽選をしない」
これは、ITでできることが、抽選の応募がしやすくなった程度のアイデアだともったいないと思ったことと、私がくじ運が悪くてこういう抽選のたぐいに当たったことがないので抽選が嫌いという、抽選に対する個人的なヒガミが入っています。
「スマホをサブディスプレイ化させない」
アイデアの段階ではスマホを使うか使わないかも決まっていなかったのですが、もしスマホを使うとしたら、テレビ番組は視聴者にテレビを見て欲しいわけだから、そこを夢中にさせるためにはよそ見をさせてはダメだろうと考えたことがきっかけでした。
そして実際にできたのが、トラなびなのですが、これがどういったアプリなのかというと、「立ち上げておくだけで、タイガースの試合情報がリアルタイムで勝手に＜落ちてくる＞アプリ」です。
このアイデアはうちのチームの宮地君のものなのですが、これが非常によくできていて、とくにユーザーに何かを強いることが少ないことが一番の特徴です。
そう、放送局は、「作っては配信、作っては配信」のルーチンに非常に優れた存在であり、これを高いレベルでこなせる集団は放送局をおいて他にないのです。
ラジオでは音声を配信して、テレビでは映像を配信しています。ではITでは何を配信すればいいでしょう。
文字放送？面白みが足りません。
映像？オンデマンド事業は体力勝負と利権がらみでハッカソン向きではありません。
放送局が、ITで配信しておもしろいものは「ユーザーが実際に触れるインタラクティブ（要素をもつ）コンテンツ」です。
加えて、日々の放送業務で激務に埋もれているスタッフに、新たな配信業務を課すことになるので徹底した配信の簡素化にもITは貢献できます。
こうして、放送局が持つ強みを活かせる形で、なおかつ導入コストを極力低くおさえる形で、トラなびのアイデアがみごとにマッチしました。
おもしろみ
手前味噌ですが、このトラなびアプリは流行ると思います。なぜなら運営が優れているからです。
私はアプリを作るまでが担当ですが、まごころこめて作ったこのアプリがいいものに育つかどうかは全て運営次第のところが大いにあります。その運営をするMBSさんの持つ「面白いものを配信する」という目的意識が、あたりまえに高いのです。
これはおべんちゃらやヨイショではなく、本当に「どうやったら面白くなるか」「タイガースファンにどうやったら喜んでもらえるか」だけを考えているのです。しか考えてないといってもいいくらい。
この精神は、上から下まで一貫していると感じました。
トラなび実現にあたって、社内調整をおこなっていた福本さんですが、最終的に役員会に「こういう事業を立ち上げます」と直々にプレゼンにまで行っています。
そのときトラなびの説明を聞いた社長の一言。
「どういう情報を出せば、面白くなるかがカギやな」
しびれます。
実際の現場でも、「こうやったほうが面白いですかね」「こうしたほうが面白いからこうやっとけ」の言葉が飛び交います。MBSさんの行動原理は「面白いか」「わかりやすいか」「喜んでもらえるかどうか」だけで成り立っていると思えるほど、上から指示を飛ばす声を聞いても下から指示を仰ぐ声を聞いてもほとんどがそのことばかりを意識して動いているように感じました。
もちろん、激務である放送制作の現場が、そんな綺麗なことばかりではないこともよくわかっていますが、だからこそ行動原理が一貫していることのすばらしさを実感しました。
タイガースの試合を放送するスタッフが、タイガースファンのためだけに配信するタイガースの生の試合情報。これが面白くないわけがありません。まさにタイガースファンのためにあるアプリです。
ゴールラインは立った瞬間から次のスタートラインになる
これまでも仕事を通して何度も経験したことですが、あらためて感じました。ゴールした瞬間からまた新たなるスタートラインに立てた気がします。
今までは、ハッカソン作品を実際に世に出すことを目的としていましたが、実際に世に出て、いまのところ非常に好評いただいており、このコンテンツをいまから素晴らしいものに育てるかどうか、また新しいスタートラインに立ったのです。
まだまだ挑戦は続きます。
参加して終わりではなく、最後まで完成させる。
私をここまで引き上げてくれたのは、とくに福本さんのおかげでした。
私と同い年なのに、風貌からもにじみでるアニキ肌な頼れる雰囲気を感じさせる、とにかく並々ならぬバイタリティを備えた人です。
ハックとマラソンをかけたこの催し、完走した先には次なる挑戦の景色が見えました。
正直に言って、この作品のどこがいいのかわからん、といういう人もいるでしょう。
私はそれでいいと思います。自分を卑下するわけではありません。
このくらいの程度というか規模の作品でも、事業化にむけてはとても大変な苦労がありました。
それは主に開発者である私ではなく、開催者であるMBSさんのほうに。MBSの多くの方の尽力をいただきました。
それくらい、ハッカソン作品を実際に製品化までするのは難しいのであることを、理解しました。
その難しいことを、MBSさんは実現しました。
「これくらいの程度のものでも製品化できるんだったら、オレもいっちょやってみようかな」と思われて、それが原動力になってもっとすごいものが世に生み出されることを私は期待します。
もちろん、「いい作品だな、いいサービスだな、いいアプリだな」と愛してくれる人がたくさんできることを願っています。そのために全力を尽くしましたし、これからも続きます。
私は、ハッカソンのいち参加者に過ぎないので、ハッカソンの未来がどうこうというところまでは考えが及びません。
ハッカソンが面白ければ参加するし、他のコンテストやイベントが面白ければそっちに参加します。面白くなければ参加しませんし明日ハッカソンが無くなっても何も困りません。
ハッカソンにちょっと距離を置く書き方をしましたが、そんな自分だからこそ、みえてくるハッカソンのよさというものもあります。
いち参加者として、いっしょになって競技した人達とのあいだで生まれた仲間意識は独特のものがあり、それがとても心地いいです。
ハッカソンで印象的なエピソードは数多くありますが、印象の強かったもののひとつに、こんなエピソードがあります。
第一回目のMBSハッカソンの優勝チームのある方が、その年は事業でトラブルに巻き込まれて人間不信に陥り、気持ちもふさぎ込んでいたなかでの参加だったが、優勝していろんな人に声をかけてもらってなんとか立ち直れた、という話を聞いたときに、初対面の方ですがまるで自分のことのように私もうれしくなったことがあります。
今回の事業化を成功例として残すことができれば、そんなハッカソン文化を盛り上げようとしている人達の足しに少しでもなれたらうれしいです。
最後になりましたが、ハッカソンを通じてこのアプリができるまで、忙しかった自分達にかわって子供の世話をしてくれた義父母にたいへんお世話になりました。
義父母の協力なくしてこのアプリの製品化はありえませんでした。
トラなびは、孫をかわいいと思うおじいちゃんおばあちゃんの愛情でできています。
世に出たばかりのアプリですが、そんなトラなびを今後もより多くの人にかわいがってもらえるように、育てていきたいと思います。