プロコンの件に関する個人的な考えの整理
さざんかぬふ目的・モチベーション
界隈（とは？）が結構審査員に否定的な意見ばかりで、まあ検討した上で否定的なのはいいんだけど、なんか感情的にただただ否定してるみたいな意見が多くて生産的ではないなと思った。そこで、どういった観点であの発言が出てくるかということを考えたい。
私の意見
- 言い方は割と問題があるとみなされるものだとおもう（ただし、アカデミックな世界では一般によく見かけるレベルのものではあると思うので、それが本当に悪いかというと私にはなんともいえない...ただ、もっと良い言い方があるであろうという事には同意する）
- 主張の本質的な内容について、枝葉末節のみを取り上げられているように感じる
- あの短い時間ではおそらく説明を十分にできていないので、もっときちんと説明があった方がいい（既にある？）
論点
- 一般論として、プロコンの観点によって審査員の発言は許容も否定もされる
- 例えば、精緻なコードを書く技術を評価する大会であったなら、精緻なコードを書くことが評価されるべき
- この評価観点については「プログラムソースも評価対象とする」としか書いてないのでわからない
- そもそも、フローチャートとコードを一対一に対応させるという発想は独創的か？
- 割と誰でも思いつく
- それが教育に用いられるという発想は独創的か？
- 割と誰でも思いつく
- ただし、誰もが知るような形で十分に実現されているかはわからない
- それが教育において効果を持つという主張は真か？
- 例えば、プロのプログラマがコードを書くとき、常にそのような事が頭にあるのか？
- コーディングにおいて実用的なのか？実用的でないとすれば、本当にその方法で教えることに価値があるのか？
- 算数の授業において、1+2=3という計算をどこまで"わかりやすく"説明すべきか、みたいな事に通じるところがある。
- サービスの発表において、本当にサービスの魅力を伝えるわかりやすい事例を検討したのか？
- blocklyのサンプルとして掲載されているコードをそのまま使うことが教育上良いことなのか？
- このサービスにおけるサンプルとして考えるべき事例を本当に検討したのか？
- （この辺が適当だと、PoC未満という印象を与えてしまう）
- フローチャートとコードの対応を取るにあたり、細かいエラーハンドリングやバグフィックスをしているのか？
- 実用上、十分に意味のあるコードをあのサービスの中で表現できるのか？
- （この辺が適当だと、PoC未満という印象を与えてしまう）
事実としては、本人たちは完成版ではないという事を認めているし、サンプルをそのまま取ってきたという事自体も事実として認めている。（その裏にどれぐらい検討があったかとかはわからないが）
私個人の"邪推"としては、コードを見る限りでのサービスの完成度がPoC未満になっていて、それで審査員が否定的になったんじゃないかなと思うんだけど、そのコードの質の低さを端的にコード量みたいなことで表現してしまって、それが変な方向で取られてしまっているように思う。
すごく雑な事を言えば、既存のものをいくつか適当に組み合わせるのは誰でもできることで、正直独創性はなく、それをサービスとして実現するレベルまでブラッシュアップすることにこそ意味があるという考え方はある。そのような観点で評価をした時に、審査員の発言が生まれてしまった可能性はある。
ここに書いたのはあくまでも可能性でしかないが、そういった事も踏まえて議論してほしいなとおもう...
さざんかぬふ書くのを忘れていたけど、単なる一般論として、同じ課題の対応を行う場合、私はコード量が短い方が良いと思っている。ので、本当に単純なコード量みたいなことでいえば、短いほうがいいに決まっているぐらいの気持ち。
でも、ここで言っているのはそんな事ではなくて、先人が苦労したものを雑に組み合わせてシステムを作ることもできるが、それは結局色々と雑で"工学的"なやり方ではない。普通の工学の世界って、きちんとした設計のものを正しくつくるという事が重要で、PoCやPoC未満のものが評価されるとは限らない。
高専という環境は、工学的なことを評価するような環境であるはずだし、（おそらくそういった意味での）実現可能性を評価するという事は明記されている。
あのアイデア、（多くの人が割と自然に思いつくものであったとしても）着想としてよかったから実際にあの場で発表できたとは思うんだけど、その実現のためには、本当にフローチャートを示すことの意味・価値を示したりとか、それを作ることによってバグが無い状態にすることとか、工学的な意味でしないといけない事が沢山あって、それを出来ていないことを言葉足らずに表現した結果が「blocklyのコードを見たか」なんだと思う。
blocklyのコードをきちんと読み込んでいれば、それと同じぐらいのエラーハンドルが必要になるよね、という事が自然にわかるだろ、みたいなね。
サービスを作るというのは、サービスとして最低限満たすべき水準を満たす必要があって、PoCよりはもっと高い水準にしないといけないと思うんだけど、PoCにすらなっていないものだった、あの場で発表したのは青写真にすぎなかった、みたいな事に対する怒りが、審査員のコメントなんじゃないかなと思う。
参加者の方にも色々事情があったのかもしれないから、あんまり頭ごなしに出来てないという事が良いかというと難しいけど、真摯に審査した結果のコメントであれば、まあ言い方もうちょっとあるだろうと思ったとしてももっと違う受け入れ方があってしかるべきと思う。
でも、そういう真意みたいな事をあまり汲み取ろうとしない人が多いように見えてしまって、私は単純にそれがかなしい。
さざんかぬふと、昨日の時点で書いてはいたんだけど、もう一回聞き直すと、こりゃあ参加者がだめだろ...
※以下、検討のために文字起こしして引用します。問題あればご指摘ください。※
審査員「ちょっとねえ、僕はちょっと怒ってます。はい。あのみなさんこれ気付いてないのかもしんないんだけど、このBlocklyのサイトを見ていただけばわかるんですけど、これBlocklyそのまんまです。」
参加者「はい、そうですね、現状はそうなっています。」
審査員「ですよね、あなたたち何を作ったんですか？」
参加者「ええと、フローチャートですね。」
審査員「いや、あなたたちが作った部分はなんなんですか。っていう。これほとんどBlocklyのサンプルプログラムそのものですよね。」
参加者「あ、いえ、ええと、このブロックのこの部分があると思うんですけども」（はい）「これは確かにBlocklyです。」（ですよね）「で、私達は本来の目的として、えーフローチャート」（はい）「に、えー...最後のフィードバックの部分ですね」（はい）「えー...ここですね、BlocklyのSVGレンダラーをカスタマイズして、もう少しリアル、リアルなフローチャート風に近づける、といのが私達の本来やりたかったことなんですけど、ここは技術的に難しく、期間内には間に合うことができませんでした。しかし、ここのPythonのコードの生成の部分は、えーWebasmあーあのPyodideというCPythonをWebassemblyにコンパイルしたものを使っておりますし、ここの、えーステップ実行も、そうですね、わり...かなり...サンプルに...そうですねサンプルにはないです。で、メンバーの招待ですとか、ここのリアルタイムの共同編集は、プロジェクトごとに、えーとWebsocketでプロジェクトIDをキャッシュえーとサーバー側でキャッシュして、プロジェクトごとできちんと、えー、えー、このブロックの差分を反映させるようになっていますので、これもサンプルにありませんし、それらのコードは私達で実装してきております。」
審査員「まあでもこPythonのコードをジェネレートするのもBlocklyでやってるわけですよね。これの表示もBlocklyでやってるわけですよね。」（そうです、はい）「で実行に関しては、そのまた別のライブラリなんですよね。でまあいわゆる共同編集の部分しか作ってない、っていう事になり、でいいんですかねえ？」
（お願いします）
参加者「えーと、あ、いいですか。」（はい）「ええと２点気になる部分があって、まあ一つはええと事実なんですけど、あーこのふろこんというアプリケーションは、えーnuxtを使って構築された、ええとWebアプリケーションです。で、えっと、まあ、なので、こういったフロント部分のコンポーネントや、このタブの切替、いまって画面見えてますか、ええとタブの切替とかっていうのは、まあ自分たちで実装した機能になっていて、で、これはバックエンドにえー、えっとExpressというフレームワークを使った、えーWebアプリケーションが動いております。で、そこらへんはもちろん自分たちで作りましたし、ええと、まあ、ステップ実行なども、まあええとPyodideというのはただ実行できるというだけで、であと、Blocklyが出力するPythonのコードも、いまここに表示されているのが全てなんですけど、これだけでは不十分なんですね。なので、えっと出力されたソースコードに、自分で手を加えて、Pyodideの方でうまくステップ実行がされるようにしたり、というところは、えっと手を加えております。あと、メンバーとかの機能も、ええと、バックエンドの方で実装されています。
であともう１点なんですけど、まあ、えっと、最近の開発ではまあOSSをこのように利用して、えっとソフトウェアを作るというのはまあよくある事なので、えーまあ、他のプロジェクトももちろんそういうことをやっていると思いますし、まあ我々がこうやってBlocklyを使っているというのも、Blocklyをそのまま転用してなんか楽をしているというような風には、ええと、認識しておりません。以上です。」
審査員「僕はそうは思わないですね。（※別のメンバー※私もその認識でいます）申し訳ないですけど、僕はこれを見た感じではもうBlocklyそのものであって、自分でコードを書いているとは、僕はみなさないですね。申し訳ないですけど。はい。」
参加者「そうですね、ええと、GitHub、ソースコードをええと提出していると思いますので、GitHubでええとソースコードを見て」
審査員「はい、それも見ました。見ましたけども、コードの量は非常に少ない、あの、ジェネ、nuxtとかでジェネレートされた部分もほぼそのままでしたし、Blocklyの部分、Blocklyのコード量見ました？（あ、はい）何行ぐらいあります？Blockly。」
参加者「いや...Blocklyのコード...あれは、えっと、コード量が少ないことは、実はいいことで、あれ、様々なコンポーネントで、よりオブジェクト指向を意識して、抽象化を部分を行いながら、一つ一つのファイルの実装量が少なくなるように、むしろそういう風に意識して実装しているのと、Websocketの部分は、AWSのLambdaというふうに、実装しております。Lambdaの、というところで実装しておりますので、ええと、そこの部分のソースコードはそちらにありますし、えーそこで、えーBlocklyをそのまま見えたというそのそち、あの印象は、そういった印象を持ってもらうのは、それは人それぞれなのでいいことだとは思うんですけど、そこで私達が楽をしたという風に捉えられるのは、私達の認識外ですし、そういった発言は撤回していただきたいです。」
（ここで打ち切り）
以下は事実
- フローチャートの部分（ふろこんの最も本質的な部分）はそもそも期間に間に合っておらず、参加者としてもその部分に関してはBlocklyのサンプルそのままを出している
- 審査員は「楽をしている」とかそんな事は（少なくともこの場では）言ってない
- （ただし、参加者の言葉に対してそう思わないと言っているため、楽をしているというような主張と誤解されうる）
- 参加者の最後のコメントも、「楽をしている」ということの審査員からの言及はないのに、勝手に述べている。
- ジェネレートしたコードが悪いとか、そういう事はいっていない。ジェネレートしたコードそのもの、手が加わっていないという事を指摘している。
- 審査員は、「目的を達成するためにコード量が少なくあるべき」という事を否定してはいないが、参加者が誤解して論をすり替えている。
- 審査員は、ライブラリを使用することを否定してはいない。
これ、態度とかは動画の印象があるかもしれないですけど、文字のやり取りとして見て、どうですか？
審査員は、Blocklyそのものであるという事しか言ってないのに、それについて誤解しているのは参加者の方のように私には思われますが。
さざんかぬふ審査員「ですよね、あなたたち何を作ったんですか？」
参加者「ええと、フローチャートですね。」
まず、これが回答になってない。というのは、フローチャート期間内に間に合わなかったと言ってるので、つまり、結局（独自の）フローチャートは作ってないと言っている。回答として破綻している。
で、このBlocklyを使ったフローチャートの部分（Pythonコードを除き）に関しては、審査員も参加者も、Blocklyそのものであると一致しているので、主たる機能の実装が間に合ってないというのが致命的な問題としてある。
実際には、サービスとして提供をしようと思うと、単にライブラリを入れるだけではなくて、そのライブラリの間のインターフェイスの調整をしたりとか、アプリケーションとして最適な出力方法を検討調整したりという事が発生する。それがアプリケーションのオリジナリティであり、価値である。
今回提出されたソースコードは、単純なライブラリの組み合わせの域を脱しているかの判定が難しいもので、（ソースコードをジェネレートすることが悪いわけではないが）ジェネレートしたものを多くそのまま使っていたり、サンプルコードもほぼそのまま使っていたり、ということがあった。
本当はそうした部分について参加者が回答すべきであったのだが、審査員の意図を汲みかねて、審査員が主張した事とは関係のない論点を提示されていると思ってそれについて反論をしている。
さざんかぬふ改めてソースコードの検証も行われましたが、以下のような見解に私も同意しますね（審査員の言動がどうか、みたいな事については見解が少し違いますが）