プログラミングコンテストで良い結果を出すために重要な(プログラム以外の)3つのこと

  • 10
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

12月4日より約2週間の期間で「Salesforceハックチャレンジ2014」を開催していましたが、昨日、痛恨の一日遅れという失態を犯しながら 無事に入賞者の発表が終了しました。
賞金の支払いなどや各エントリチームへの細かな評価フィードバックは来週となりますが、まずは10日間という長い期間のハックチャレンジに参加してくれた皆様お疲れ様でした。

私もこのハッカソンの運営及び審査チームの一員として関わらせていただきました。アプリケーションを審査するにあたり一番重要なのは「プログラミングスキル」と、「アプリのアイデア」、そして「アプリケーションの品質」なのは言うまでもありませんが、僅差の場合などでプログラミング能力以外の基本要素の部分で入賞の明暗が分かれるケースがありました。

今回はその「プログラミング以外の部分で重要な事」を3つにまとめましたので共有したいと思います。

プログラミングコンテストで重要な(プログラム以外の)3つのこと

1. 主催者側のニーズを読む

皆さんは自分のプログラミング作品をコンテストに入賞させるのに行っていることは何でしょうか?美しいコードのモジュラー化?モダンなフレームワークやビルドツールの有効活用でしょうか?もちろんそれらは言うまでもなく超重要です。
しかしそれと同じぐらい重要なのは、まず最初に「 そのチャレンジの趣旨がどういうもので、何が期待されているかを理解する」事です。

別に自分のテクノロジに対する信念を曲げてまで主催者側に媚び売れって話ではありません。
プログラミングコンテストもある種スタートアップ企業のそれと同じで、市場 (この場合はハッキングイベント)の動向を読んで開発を行うことが重要です。

プロダクトの品質が悪く市場に受け入れ入れられなかった事の言い訳に使ってる可能性もアリますが、「スタートアップが失敗する理由の第一位は"市場が無かったから"」というレポートがあるくらい、かなり多くの人がこの部分を見誤っているようです。

例えばSalesforceのハックチャレンジは、(Herokuは別ですが、あくまでSalesforceという冠がついてる場合は)本質的にB2B向けのアプリ開発プラットフォームであり、AppExchangeのようなマーケットプライスを保持する性格上、将来的にビジネスとして成長する要素があったり、既存の顧客に対して新しい気付きを与えるような斬新な切り口などの点は、大きなプラス要素となります。

今回のSalesforceハックチャレンジ2014には、審査基準にも「ビジネスでの有効性」が明記されているので、よりその要素を明確に押し出していた格好となります。
shinsa.png

もちろんプログラミングチャレンジですので、例えば米国のSalesforce $1 Million Hackathon 2014のWinnerであるOmniKeyboardのように、新しいテクノロジの使用や斬新なアイデアに突出している事も重要なのは間違いないです。
がしかしこのOmniKeyboardは「Salesforceのメイン製品である営業支援 というシチュエーションの課題である モバイルからの入力の煩雑さを軽減する」という大きなビジネス要素があったから選ばれた点は見逃せません。

いずれにしても、主催者側の傾向をつかむことが重要です。

2. 簡潔かつ明確に、かつ視覚に訴える説明をする

いざ"これだ!!"というアプリケーションのネタが決まり、実際に開発に行った後に重要なのが、そのアプリケーションが

  • どんなモノで
  • 誰のどんな問題を解決し
  • どんな技術要素を使っていて
  • どういう見た目なのか

を簡潔かつ視覚に訴える説明することです。開発している人はずっとアイデアを練ってるので、その課題に対する感度が高くなってますが、審査員はそうでない場合もおおいにあります。

例えば訪問介護ソリューションと聞いて、パッと医療データの持ち出しや情報共有が頭に浮かぶ人もいれば、全く馴染みのない人も居るわけです。これは審査員も同じです。他業種の自分の嫁/夫に説明するぐらいの気持ちで、わかりやすく伝えましょう。

「ひと目見てもらえば、このアプリケーションの用途と凄さはすぐに伝わるよ」

と考える方。実際はわかりやすい説明が無いと ひと目も見られない可能性があります

プログラミングチャレンジにおいて、審査のプロセスはおそらく各社さまざまです。
例えば今回のウチのハッキングチャレンジでは、テクノロジに強い審査員も居れば、ビジネスアイデアを中心に審査する審査員もいました。

全てのアプリケーションを全審査員がレビューする形式だったので、説明下手だけど高品質なアプリが埋もれてしまうケースは比較的少なかったと思っています。
が、これが規模が大きくなれば、1次審査は分担して行い上位3エントリーのみ全員で見るとか、そういった運用も十分あり得ます。

その場合、 説明ベタな良いアプリ x ビジネスアイデアを中心に見る審査員 が当たると、そのアプリは陽の目を見ること無く落選する可能性が高まります

なので、説明もプログラミングと同じぐらいに重要なのです。

今回のハッキングチャレンジでも12の入賞チームのうち、実に11チームが紹介ビデオを作成しています。(こちらで推奨したというのもありますが)

最優秀賞を取ったAITAの画面を見ると、上記要素が詰め込まれているのがわかります。
コードはプライベートリポジトリなのですが、Readme.mdにも詳細な説明があり、技術、ビジネスアイデア、あらゆるタイプの人間に「おっ」と思わせる構成になっていました。

Aita.png

3. ビルド手順を明記し、デモ環境を用意する

いざ説明も付けて、これで完璧と思っているところに最後の落とし穴です。
再現可能なビルド手順を用意し、かつデモ環境やデモアカウントを用意しましょう。
ビルドに必要な前提条件(npm, maven,gem, ant, middleman, bower,cordovaなどなど)も必ず明記しておきましょう。

これも前出の審査員の個人差というものが有りますが、どんなにテクノロジに強い審査員でも、全てのフレームワークやビルド環境に精通はしていません。Gruntは強いけどgulpはあまり使ってないとか、rails分かってはいるがmiddlemanはまだ触ったこと無い、あるわけです。

となると、「bower installなんて脊髄反射でやれよ」「config.rbあるんだからmiddlemanだろJK」とか思うかもしれないことが伝わらないケースもあるのです。

もちろん各分野のエキスパートを審査員として配備出来ない運営の問題が原因だろという正論もありますが、所詮審査員も普通の人間です。苦手な所とかあります。なのでグッと抑えて正しいビルド手順を抜け漏れ無く明記してあげて下さい。

皆さんは過去数多のフレームワークに触り、チュートリアルを動かしたりしたことがあると思いますが、手順通りやってるのに動かなかった時のあの残念感は、審査員も同じなのです。

また、必ず開発機とは別の環境で試して動くことを確認します。これは本当にミスが多い項目でした。
開発環境ではPATHが通ってるから動いてるけど、実は入れないと駄目なライブラリ等をドキュメントに記載し忘れたり、そもそもGitrepoにあげ忘れたり、(Salesforceの場合は名前空間など)特殊な環境変数がコードにハードコードされてしまって実は別環境だと動かない等、審査員はエラーの内容を追っていかなければビルド出来ません。

今回のハックチャレンジでは、ビルド出来なかったり手順が無いものに関しては、コードをレビューしつつ別途デモアカウントを提供してもらうか、気合でビルドするまで試しましたが、エントリ数が多いハックチャレンジ等は、ビルドが出来ない時点で"アウト"とされてしまうケースもあるかと思います。

入賞を果たしたLotteryVoteのReadme.me。デモアカウント、ビルド方法が明記されています。
Lotty.png

当然の話ですが、プロラミングチャレンジなので、ビルドも重要なのです。

まとめ

つまり

・審査基準を理解して、合致した内容で作成
・簡潔かつ視覚に訴える説明を用意
・ビルド環境とデモ環境を整備しておく

をやれば良い結果を得られる確率は上がると思います。
Salesforceでは今後もプログラミングチャレンジ系の企画は実施していきたいと思っていますが、この基本原則はどのプラットフォーム、どの企業が主催するハッキングチャレンジにも言えることだと思いますので、ご自身の作品を提出する前に参考にして頂けると幸いです。

というわけで、Salesforceにあまり直接関係ない内容になってしまいましたが、Salesforce1 Advent Calendarの20日目のエントリでした。

(まぁでも結局一番重要なのはアプリの凄さですからね。頑張っていいもの作りましょう!!)

この投稿は Salesforce1 Advent Calendar 201420日目の記事です。