TopCoderの各コンテストについて適当な紹介

ProgrammingCompetition TopCoder
自分はSRMしか参加したことがないけど、TopCoderのコンテストにはいろいろと部門がある。
アルゴリズム部門以外のTopCoderのコンテストが全然わからなかったので簡単に調べてみた。
とても読みにくいので注意。

Copilot Opportunities（共同開発機会）

TopCoderのコンテストを利用してあるプロジェクトを遂行したい顧客のために、企業と共同で一連の開発工程を運営する、というお仕事。
顧客との対話や他のコンテストの実施、成果物の納入など、TopCoderのソフトウェアコンテスト運営の重要な役割を担っている。
 
最初にプロジェクトの基本戦略や、コンテストの開催ロードマップなどを最初にWord・Excelで提出し、選別のためのコンテストを行う。
その後、コンテストをパスした人たち（コパイロットと呼ばれる）によって他のソフトウェア開発コンテストが実施される。

上記のようにこのコンテストはとても重要なものなので、参加するには以下の条件を満たしている必要がある。

  • 過去1年間に3種目以上のコンテスト（SRMとMarathon Matchesは除く）に参加し、スクリーニングレビューをパスしている
  • 少なくとも1つの部門で緑色コーダー以上である
  • 過去1年間にレビュアーになったことがあり、レビュアー権限を剥奪されていない
  • 過去6か月間にコパイロット権限を剥奪されたことがない

Design（設計）

  • Studio（スタジオ）
    • デザイナー向けのコンテスト。
    • ワイヤーフレーム作成やアイコン作成などいろいろな部門があるけど、ここでは詳しく解説しない。
  • Conceptualization（概念化）
    • 出資者と共同してプロジェクトの設計を行うコンテスト。多くの場合、コパイロットが決定したすぐ後に行われる。
    • デザイン（ストーリーボードやワイヤーフレーム）の原型を作ったり、ビジネス要件を定義・記述した文書を作ったりする。
    • Conceptualizationコンテストは1つのプロジェクトに対して複数回行われることが多い。
    • 最終的な成果物の例がWikiページの下のほうにあるですよ。
  • Specification（仕様化）
    • 要件を基に、具体的なプロジェクトの仕様（要求仕様）を書くコンテスト。
    • 仕様はUMLによる図（主にユースケース図とアクティビティ図）を含めた文書で書く。
  • Architecture（アーキテクチャ）
  • Component Design（コンポーネント設計）
    • 与えられた仕様やアーキテクチャのもとで、ユースケース図・クラス図・シーケンス図とコンポーネント仕様文書を書くコンテスト。
    • 内部設計に相当する？　Architectureコンテストとの違いがよくわかってない。
    • ここで具体的なライブラリを決めたり、テストケースも作ることもあるみたい。

Development（開発）

  • Component Development（コンポーネント開発）
  • Assembly（組立）
    • よくわからない。部品から実際に動くアプリを作るコンテスト？　試作版が完成されているアプリケーションに機能追加するコンテスト？
    • とりあえずアセンブリ言語は関係ない。
    • 英語の解説でも"Assembly competitions are hard to define."と言ってる…。
  • Test Suites（テストスイート）
    • 自動化されたテストケースを作るコンテスト。
    • 見つかったバグは、前段階のコンテストの勝利者に修正を依頼される。
    • テストケースは、JUnitとか、NUnitとか、Seleniumとかで作っているようだ。
  • Reporting
    • 謎。説明がないし今まで一度もコンテストが開かれてない。

UI Development（UI開発）

QA and Maintenance（品質保証と保守）

  • Test Scenarios（テストシナリオ）
    • テストケースを作るコンテスト。
    • DevelopmentのTest Suitesとほぼ同じコンテストで、開催されるときのプロジェクトの工程が異なる。
  • Bug Race

Algorithm（アルゴリズム）

  • Single Round Matches(SRM)
    • アルゴリズムに関する短時間の定期コンテスト。
    • TopCoderのコンテストの中で最も参加者が多い。
  • Marathon Match
    • アルゴリズムに関する長時間の定期コンテスト。

High School

高校生向けのコンテスト。アルゴリズム問題。

The Digital Run

その月で部門別で一番DRポイントを稼いだ人に賞金をあげますよという話。
DRポイントはソフトウェア開発コンテストで参加してスクリーニングをパスすると、成績に応じてもらえる。
 


ソフトウェア開発コンテストの大まかな流れ

個々のコンテストによっては違う部分も多いけど、ほぼ次のような流れで共通している。
  1. 登録（Registeration）
    • 自分が参加したいコンテストのページへ行き、参加登録をする。
    • 参加登録をすると、そのコンテスト専用のフォーラムにアクセスできるようになる。そこで、登録前では得られない追加情報を入手できる。
  2. 投稿（Submission）
    • 作るべきものを作って、投稿する。
    • 必要があれば、専用フォーラムで質問をすることもできる。コンテストによっては、専用フォーラムでの対話が作業の中核になるものもある。
  3. 評価（Review）
    • 投稿期間が終わったら、自分の作成物をコンテストのレビュアーに評価・採点してもらう。
    • もし自分の評価点が不当に低いと感じたら、専用フォーラムでスコアの修正を要求することができる。最終的なスコアは修正要求を吟味した後に決まる。
  4. サポート（Support）
    • もしコンテストで勝利したら（最も高いスコアを得たら）、このフェーズに入る。
    • 一定期間（多くの場合30日間）、自分の制作物で見つかった不具合を修正したり、続く開発工程でのコンテスト参加者からの質問に答えたりする。
    • 期限後はバグが見つかっても修正する必要はないが、修正したら追加の報酬金を得られることもある。


その他まとまりのないこと

  • ものすごい勢いで色々な作業がマニュアル化されている。すげー
  • そのせいか、ソフトウェア開発コンテストがガチガチのウォーターフォールモデルになっていて、LL言語によるプロジェクトがPHP除いて圧倒的に少ない。
    • 過去2年間くらいのコンテストを流し見てみたけど、その中にRuby案件とPerl案件は一つも見つからなかった。これは意外。
    • Pythonを使っている案件は一つだけ見つけたけど…すごく…Jythonです…。
  • ソフトウェア開発コンテストは、SRMに比べて1コンテスト当たりのサブミッター（コンテスト参加者のうち制作物を投稿した人）が少ない。
    • 開発工程のコンテストでは、サブミッターが1人しかいないことも割と頻繁にある。これとかこれとかこれとか。
      • Assemblyは半数近くがサブミッター1人な印象
      • サブミッター0人も、あるよ。（ただしそのようなコンテストは履歴からは見えない）
    • なので、「コンテスト」というよりは「コンテストを利用したアウトソーシング」といった方が正確だと感じた。
  • フォーラムやサポートでの対話が発生するので、ある程度の英語力は必須だと思う。
    • 設計部門のコンテストだとガシガシ文章書かないといけないから、ある程度では済まないだろうけど。
    • 開発部門なら、英文書くのはコードのドキュメンテーションと、成果物の変更リスト、フォーラム上の会話くらい。
    • 成果物に書くことは部門ごとにテンプレがあるから、それに倣えば深く考えなくてもよさそう。もちろん、テンプレはきっちり読まないといけない。
    • フォーラムでの会話は、他のフォーラムの書き込みを参考にすれば大丈夫…か？　参加したことがないので自信がない。
  • SRMと比べてとても敷居が高いけど、その分野の知識があるのなら気軽に参加していいと思う。参加費は無料ですし。

 

主に参考にしたページ（英語）