U22プロコンに落ちたので反省会します

U-22 プログラミングコンテストに応募し、事前審査で落ちました。

応募開始当日、7/1 21:00に応募しました。IDが1だったので、おそらく最速応募だったのではないかと思っています。

2019に応募し事前審査で落ち、2020は応募せず、今年はそこそこ自信があっただけに残念です。今回は反省会です。

提出したもの

今年の1月頃から開発を行っていた、React製サービスです。TAGetherといいます。ソースコード公開しているので、starとかお願いします（小声）。

簡単に言うと、テスト対策問題を作ってクラスの人と共有できるようなサービスです。

誰かが「カテゴリ」というまとまりで問題集を作成すると、他の人はそれを解くことができます。カテゴリの全問題に解答した後は、正答率などと一緒に間違えた問題が一覧表示されたり、間違えた問題は履歴から解き直しができたりします。

そして、名前にもある通り、カテゴリには複数のタグを登録できます。タグによる検索はもちろん、同じタグが付けられているカテゴリの問題をまとめて、一度に解くことも出来ます。

元はクラス内で、英単語アプリ用のcsvを作って配布していたのがきっかけです。作成したcsvはGoogle Driveで共有していたのですが、誤字があった際、既にダウンロードしていた人に伝えるのが非常に面倒でした。ということで、せっかくなら英語に囚われない問題共有サービスを開発しようと思い、開発をはじめました。

ちなみにこれはどうでもいいのですが、やはりサービスの性質上テスト期間に使われることが多く、必然的にバグ報告などもテスト期間に多く寄せられました。致命的でなければ別にテスト後に回しても良かったのですが、やっぱり実装したい欲を抑えられず、勉強がおろそかになってしまったのは反省すべきところだと思いました。

ツイートを読み込み中...

2019年の応募について

2019年も勉強関連です。MarkStudyというOpenSiv3D製のWindowsソフトを開発しました。

学習特化をうたうマークアップエディタで、太字・色付けといった基本的な装飾に加え、単語に重要度を設定して、それぞれ強調したり、非表示にして穴埋めテストに使ったりすることができます。

この作品は初めからコンテストに応募することを目的として開発をはじめました。7月頃から具体的に開発スケジュールを考えてその通りに取り組みました。

ほぼ計画通りに開発できたのは良かったのですが、時間が短いのもあってか、不十分な完成度で満足していました。というのも、エディタであるにも関わらず、コピーや範囲選択など、基本中の基本が実装できていなかったのです。落選後のフィードバックでもそれが指摘され、今回同様に事前審査で落ちてしまいました。

ツイートを読み込み中...

自分で考えた、良かった点

とりあえず、「同じクラスの人にしか使ってもらわない」ということで、ターゲットをしっかり絞っていたのは良かったかもしれないです。「同じクラスの人が開発している」ということで、フィードバックのハードルも低かったらしく、機能要望フォームからたくさんの改善要望を送っていただき、それによって様々な改善を施すことが出来ました。同じクラスの人たちには本当に感謝しております。

さて、記憶にある限りでは、開発中には以下の内容に気を配っていたと思います。といっても、あんまりないですね・・・しかも、気をつけて当然のことばかり・・・

開発前に真剣に技術選定をした

開発開始しようとしていた頃、誰かのLTか何かで「技術選定はしっかりしておくべきだった」という旨の発言を聞いたことが印象に残っていたので、いろいろなサービスを探して比較し、最適だと思えたものを選びました。ちゃんと後で見返せるように言語化して保存しています。

とはいえ真剣も何もなく、Reactが初めてすぎて途中でメリットもよくわかってないままNextになったり、いつのまにかバックエンドのログイン機能を実装しようとおもって複数サービスを列挙して考えていたのに結局LocalStorageになったりめちゃくちゃですが、それでも「技術選定をしよう」と思った時点でえらいとおもいます。

？

自分で使った

自分がテスト勉強をする際、実際にこのサービスを使いました。この機能がないと不便！と思った機能を（一部テスト期間中に）実装できました。自分が使いやすいと思えるサービスでなければ、まず他人も使いやすいとは思わないとよく言われていますが、その通りだな～と感じました。

スマートフォンからの利用を考えたデザイン

クラス内に公開したところ、ほとんどの人がスマートフォン（それもiPhone）からアクセスしている印象を受けました。これは作る前からわかっていたことなので、例えばパソコンでクリックする箇所は、スマホで見た時に指で押しやすいサイズにするなど、ちょっとしたことに気を配っていました。

色のコントラスト

暗い背景に暗い文字色、みたいなことが無いように気をつけました。微妙なときはChromeのインスペクターから確認しました。

自分で考えた欠点

落ちる前から思っていたことも、落ちた後に考えたこともとりあえず書いてみました。こう考えると結構色々ありますね・・・

目を引く長所が一切ない

これが最も致命的である欠点だと思います。新しくサービスを建てる際は、たいてい類似サービスを列挙し、長所短所を踏まえて開発を行っていくほうが良いと思っていました。

しかし、今回はそれをしませんでした。結果というわけでもないかも知れませんが、このサービスはただ勉強が出来るというだけの味気ないサービスになってしまった気がします。

名前に「TAG」と付けているにも関わらず、タグ関連の機能はかなり最近のアップデートまで無いに等しいレベルの要素だった上、現在も名前に入るほど強力な機能なのかは自分でもよくわかってないです。

問題形式が不十分すぎる

2番目に致命的だと思っています。これに関しては前回応募時同様、自身の怠慢が故の欠点です。
穴埋めしかない（4択問題などが面倒）、完全一致しか正解にならない・・・これは言い訳ですが、実装したいものはたくさん考えているものの、既存の問題との互換性を保つのが面倒すぎるのでなかなかやろうと思えないという現状です。
もう少し「テスト対策問題を作る上でどのような機能があれば良いか？」を考えておけばよかったです。

これに関しては、最近Twitterに流れてきたサービスから得た反省点です。自分のサービスより優れたデザイン、使いやすそうな問題編集画面があってつよそうでした。若干自信がなくなりましたが、そのサービスはどうやら個人向けだったようで、ギリギリ自分のサービスのアイデンティティーが保たれていて持ちこたえました。

スマートフォンでの操作感の悪さ

気をつけたつもりではありますが、やはりフィードバックには定期的に寄せられていました。画面の小ささが故にいくつか妥協した点（例えば、カテゴリの説明欄をなるべく小さくし、名前とボタンを最優先表示するようにした）があるのですが、そこに不満が寄せられることも多かったです。

特に、文字を入力する際にキーボードによって画面が占有されることを完全に忘れており、現在も明確な対応を思いついていません。もっと早く気づいていれば、そもそものレイアウトからスマートフォン向けに設計できたかも知れません。

これに関しては、ただ妥協するのではなく、スマホ限定でもう少しスペースを確保できるデザインを考える（例えば開閉式にしたり）など、別の方面から考えるべきだったと思いました。また、もう少しスマホから自分のサービスを使うべきだったと思っています。

全体的な（UI含め）デザインの悪さ

色がお世辞にも綺麗とは言えない、ボタンサイズが不適切などです。

全体的に「青系統のダークテーマ」を意識していたのですが、色付けの法則は特に決めていなかったため、バラバラな印象があったかもしれないです。

また、かなり問題編集画面が複雑になっています。特に問題入れ替えが非常に面倒です。ここは可能な範囲で改善したいです。

ソースコードが雑

明らかに巨大すぎるクラスが一つのファイル（front/src/pages/create.tsxのことです　500行あるし似たような関数が大量にあってめちゃくちゃ分かりづらいです）にまとめて書かれています。リファクタリング不足です・・・。
正直できたらとっくにやってるよ感が否めないですが、どうにかやりたいです。だれかたすけてください。

その他

トップに戻れるわけでもない邪魔なヘッダーを画面上部に固定する意味はあったのでしょうか・・・

それから、冒頭の方で「自信があった」と述べましたが、そもそもこの自信は同じクラスの人にたくさんフィードバックを送っていただき、それが「このサービスは良いものだ（より良い方向へと向かっているはずだ）」という根拠のない自信につながっていたのかなと思います。いろいろな人に便利と言われるのはもちろん嬉しかったですが、それに慢心していたのが今回の結果を誘発したのかも知れません。事実、落ちてから冷静に考えるとこんなに欠点が思い浮かんでいるので。

まとめ（次回へ向けて）

技術選定はかなり大切であると実感しました。致命的に不足していたとまでは思いませんが、もう少しサービスの存在意義とそれによるユースケースを考えておくべきでした。デザインに関してはbootstrapのようなCSSフレームワークを採用すれば良くなるかも知れません。

2019年と比べて、開発期間が長かったのは良かったと思います。前回も今回も妥協した点があったので、開発中も冷静に自分の作品を俯瞰し、欠点は可能な限り見つけて潰せるのが理想です。

負け惜しみ

そもそもフィードバックほしかったので・・・賞取れなくても別に・・・このサービスがより良い方向へと向かうのなら・・・いいですけど・・・

あと、落ちたノリで不満を言うのはあんまり良くない気がしますが言わせてください。せっかくdocker-composeでほぼプラットフォームに依存しないであろう環境構築が出来るようにしてあるのに、サービスのURLを求められたのは少し不満でした。
というのも、このコンテストでは、提出が求められているものの一つとして「実行形式ファイル」が記載されていました。今回開発したものはWebサービスであるため、実行形式ファイルの提出は出来ません。この旨を問い合わせたところ、「WebサービスであればそのサービスへのURL、それが不可能である場合は仮想マシンのイメージなどを提出してください」という返答を頂きました。

しかし、そもそも基本的にクラス内で使ってもらおうと思って作成したものなので、外部からの悪意あるアクセスを防ぐため、ベーシック認証などをかけてクラス内に公開しているのです。
さすがにそれを公開するわけには行かず、かといって仮想マシンなんてものはありません。結果、わざわざもう一つ、U22提出専用のサービスを立ち上げ、それを送信したわけです。

できればdocker-composeで勘弁してほしかったな～と思いました。まあこれでうまく動かなかったら終わりなので、このほうが安全と言われれば否定はできません。

さて。

このサービス、何か変更が加えられた際、バックエンドから設定ファイルに記入されたDiscord WebHookにその詳細を送る機能が付いています。
例えば、誰かが「hoge」という名前で新しいタグを作ると、「新規タグが作成されました：hoge」みたいな感じのメッセージが送信されるわけです。

もちろん、提出用のサービスにもWebHookを設定していました。「U22監視用」というチャンネルを自分のサーバーに作成し、ちゃんとサービスが動作していたか確かめようと思っていたのです。

事前審査終了および結果発表のメールが届いて、そういえばメッセージが来なかったな、せっかくサービス作ったのに意味なかったのか？と思って提出したURLを確認すると・・・

502 Bad Gateway

え？

ツイートを読み込み中...

ツイートを読み込み中...

ログを見ると、9/13からサービスが落ちていたようです。2週間前なのでわかりませんが、WebHookの件もあって、選考以前から問題が発生していたのかもしれないです。

ツイートを読み込み中...

これでフィードバックに「作品を確認できませんでした」みたいなことが送られたら泣こうと思います。というかそれだとフィードバックさえ送られてこない気がしますが・・・2019年に送られただけなので、フィードバックそのものが全員に送信されているのかどうかわからないです。

反省おわり

以上、応募したサービスの内容と、自分の考える欠点、負け惜しみでした。

たくさんの欠点や負け惜しみも言いましたが、この作品を開発するにあたって非常にたくさんの知識を得ることが出来たのもまた事実です。
やっぱり知識をつけるには手を動かして何かを作るべきだと再確認しました。今は特に作りたいものがなく虚無な人生を送っているので、何か新しいことに挑戦したり、ブログにアウトプットしたり出来たらいいなと思います。やっぱりそのほうが楽しいので。

もしフィードバックが来た場合、それに伴ってまた反省を追記できたら良いなと思います。

追記

そういえば、完全にクラス内で使われることしか想定していなかったので、エラー処理を全く考慮してませんでした（MySQLのエラーをフロントエンドに垂れ流してた気がするので、非常にまずい）

曲がりなりにも誰でも使えるOSSとして公開しているものなのにこの現状、ありえないですね・・・近々改善しようと思います。とはいえ落ちたのもあってモチベがないので、いつ修正するかは未定です。