プロコンにOSSを使ってはいけないのか？ #procon32
はじめに
先日開かれた高専プロコンにて「ふろこん」というプロダクトを発表されたところ 「私は怒っています」 「ライブラリを使って楽をしている」 などの指摘を審査員より受けたというツイートに関連して、 SNSで 「OSSを使うのがNGとか分かって無さ過ぎる」 とか 「審査員はフロントエンドが分かってない」 というコメントが多数有りました。逆に 「あの発表内容はミスリーディングであり適切ではない」 等のコメントも一部ありました。私自身はどちらかと言うと件の審査員の方に同意する部分もありますので、その考えに至る背景や私なりの発表の改善点をまとめてみました。あくまで、こういう考え方もあるよ、と参考までに。
重要
- 発表された方々を誹謗中傷する意図は一切ありません
- ふつうに面白い着眼点で良いもの作ったなー、と思っています
- 審査員の言い方には問題がありハラスメントは常にダメ、ゼッタイ。例えコメントの趣旨には一部同意するところがあってもそれはそれ
TL;DR
- プロダクト自体は面白そうだし良く作られてる
- ただし、発表内容からは設定した課題の直接的な解法がOSSを利用しただけに見える
- 工夫したところにフォーカス出来るように課題設定や発表方法を改善する余地はある
- 研究発表と製品開発では評価ポイントが違う
- モラハラ、ダメ、ゼッタイ
たしかにあの発表には課題があった
まず彼らの成果物を貶める気は全くないですが、発表内容には少し課題というか改善点があります。それは自分たちの工夫を分かり難くしている事です。
単純に発表経験の不足によるものだと思いますが最終的に作った 「ふろこん」というプロダクトの説明をしてしまっており、自分たちの工夫した部分/実装部分にフォーカスできていません。これは自社製品の売込みとかだと全く問題無いのですが、研究発表の類だと大きな問題になります。
以下は「ふろこん」の発表および質疑応答です。まずはこちらを視てみましょう。
さて、皆さんはどう感じましたか？
プロコンにおけるOSSの利用有無が問題ではない
この件に関して、審査員のコメントからSNS上では 「コード量が多くなきゃダメ」 とか 「OSS使っちゃダメ」 とかおかしい！ という指摘が多くありました。
実際にこの審査員の方はそう取れることを言っていたし、発表された学生のかたもそう受け取って返答をしていたように思えます。ただ、たぶんそれは少し解釈が違います。恐らく質問の趣旨はコード量全体を言いたいのではなく 「課題に対して解決方法を作りこんでいるか？」 でしょう。OSS云々も本来は重要な部分ではありません。
こちらは発表の冒頭にある課題と解決案です。
こちらを見る限りだと 「アルゴリズム学習において古典的な紙のフローチャートは理解が難しい」 という課題に対して 「より適切にモデリング出来るブロックプログラミングのWeb IDE開発」 という解決方法だと思います。
とすると 「ブロックプログラミング」 の処理系やビジュアルエディタがコア機能になると感じるのでそこに対しての自分たちの工夫/実装が足りないのでは無いか？ という指摘です。別にバックエンドにOSSであるMySQLを使っていたり、ORMがPrismaだったりとかそういう話では無いのです。もっと言えば外部APIとか使ってても全く問題ありません。あくまでテーマがこれなら 期待値は対象ソリューションの実装ないしは既存ライブラリの改造 になるのでその部分が見えない、という話。コードが少ない方が良いコード とかとの話とはちょっと文脈が違うのが元々の指摘したかったことだろうな、と。
彼らが本当に作っていたも
じゃあ、彼らが単にサンプルコードをコピペだけして何もしてないかと言うともちろん違うでしょう。
彼らはちゃんとインテグレーション部分をしっかりと作っています。
ログイン機能やプロジェクト管理機能を始めとしてWebアプリケーションとして成立するために必要な多くの部分などコア機能以外の周辺機能をしっかり作りこんでいます。BlocklyとPyodideを連携させる部分や別ユーザと同期させる機能などもちゃんと作っています。またTypeScriptの利用はもちろんPrismaとか使ったりコアじゃないところも技術的にも色々チャレンジしてますね。イマドキのフロントエンドって感じで良いですね。
こういった周辺機能が無いとそもそもアプリとして機能しませんからね。コアとなる機能/コンポーネントではないから不要という分けでもないのです。実際の製品開発でもどうAPIや既存ライブラリを組み合わせて作っていくか？ というのはとても重要なことですよね。
課題設定とその解法
ただ、今回のポイントはコンテストであり研究発表に近い領域であったことです。この場合、課題設定とその解法---どのように解決したのか？ という点は非常に重要です。
課題設定自体はある意味何でも良いのですが、それは解決されている必要があります。そして、そこに独自性というか新規性が必要です。オリジナリティと言い換えても良いですね。今回の発表ではその部分が見えづらかったと思います。コアじゃないところをフォーカスして作っていたならそこが解法になる課題を設定するべきでした。
このあたりは研究発表の類と実際の製品開発やアイデアコンテスト/ビジネスコンテストなどでもまた観点の違う部分です。後者は別に1行たりとも独自性が無くても良いですし。
私は他の発表や過去の発表を見ていないのではっきりとは分かりませんが以下の募集要項を見ると独自性が大きな評価ポイントですし、適切な課題とそれを解決する独自の開発が求められるのは自然な気がします。
第32 回プログラミングコンテスト・自由部門では，参加者の自由な発想で開発された独創的なコンピュータソフトウェア作品を募集します
ref: 募集要項
もっとも大学などの研究発表では無く 「プログラミングコンテスト」 なのだから独自性だけではなく実装方法やメンテナンス性、システム構成なども評価されるべきだし、実際そういった感じの事も書いてあるので、もっとその部分を強調した発表の方が彼らがフォーカスした事がわかりやすかったかな、と。コアはOSS使ってるので。
研究発表と製品開発
ちなみに先ほど大学等での研究発表と言いましたが、もしそういった場での発表であれば私は今回の「ふろこん」にはあまり高い評価は付けないでしょう。アイデアが面白く、良く作りこまれていても、肝心のコア機能が借り物だからです。そこに新規性はありません。私が学生だった頃になるべく心がけてたし後輩の指導でも言ってたけど研究だとログイン機能とかプロジェクト管理とか便利なUIとかアプリとして当然必要な機能を実装しても評価されません。そこに苦労しても仕方ないのです。無くて良い。重要なのはどのように未解決だった課題を解決したのか？ です。プロダクトとしての作りこみは本質的にはどうでも良い。PoCとかMVPみたいな話ですね。
一方で、これが実際の製品開発やビジネスコンテストではそういった周辺部分の作りこみも当然重要です。むしろコア機能なんて借り物で良いのです。安く手早く開発や管理出来る事が重要で儲かる(＝ビジネス的に有利な差分がある)ならば完全に既存製品をそのまま使っても良いわけです。その点 「ふろこん」は既にログインとかビジュアルエディタとWebベースのREPLの統合など色々作りこまれてて良いな、と感じます。 製品にするための第一歩が踏み出されていますね。このようにコア機能よりもUIとかUXとかそういったことが重要になることも多いですよね？ もちろんコア機能が借り物だと他社と差分にならない事もあるので仕事ではインテグレーションだけをしろ、と言う意味ではないのですが。
このように研究発表と実際の製品開発では同じ「モノを作る」といっても評価されるポイントが違います。このあたりが 「OSSやAPIのインテグレーションで開発するのが普通だ。評価者は重要なのはドメイン設計だと分かってない」派 と 「（肝心のコア機能をOSSにして）自分たちの独自性が無いのはダメだ」派のコメントの乖離だと思います。本コンテストがどういうノリなのかを適切に把握してないですが独自性は求められてるようだし、少なくとも件の審査員はその視点でコメントしたのでしょう。研究発表やコンテストでインテグレーションやUI/UXが無価値と言う意味ではなく、それならそういう課題設定が必要、ということです。
発表の改善案
さて、では彼らは発表内容を詐称して審査を通り抜けようとした不誠実で狡賢い学生たちでしょうか？ そうかもしれません。ただ私は違うと思います。
実際のところ彼らはライブラリを使用していることを全く隠していませんし、ビジュアルプログラミングの部分にBlocklyを、Webでの実行のためにPyodideを使ってる点などをきちんと説明しています。非難される謂れはないと考えるのも当然でしょう。OSSの成果と彼らの成果を分離されてないと感じるのは読解力の問題ですね。私含めて。
しかしながら今回デモの印象やそしてプロコンという性質から 「発表内容=自分たちの工夫の部分」 と取られるのも致し方ありません。そこがほとんどライブラリの説明であり、彼ら自身の工夫の部分がわかりません。これは成果の盗用と誤解されやすいし、なにより一番伝えるべき自分たちの工夫を話せてないのでもったないないですね。
例えば各ライブラリの説明はもっとアッサリ終わらせて自分たちの工夫したインテグレーションの部分を強調して説明すると誤解が減ったのではないかと思います。聞き手は何にを加えたのかが知りたいのです。もしかしたらコンテスト趣旨とは外れるのかもですが、場合によっては製品選定やUIコンセプトとかインテグレーションの注意点などを強調しても良かったと思います。
BlocklyやPyodideと言った「ふろこん」というプロダクトに置ける重要なパーツをしっかり説明しないと、聞き手が混乱すると思うかもしれませんが、そういったものの詳細は質疑応答で十分です。今回の発表形式で出来たかは分かりませんがAppendixとかにして質問されたら参照しながら回答する方法もあります。どれだけ製品として重要な部分でも自分たちの本当に説明したい事に関係ない所は内容がブレるので省くのが吉です。
あるいは課題設定を 「それぞれに使えるライブラリはあるが統合製品が存在しない」 とか 「Blockly単独では○○な課題があるからPyodideと組み合わせるなどで補完した」 とか周辺機能やインテグレーション自体を課題として設定する方がよいでしょう。Blockly/Pyodideの重要性が課題解決において相対的に低くなるので。
それはそれとして審査員のコメントは良くない
正直に言えばこのプレゼン内容だけを見れば、件の審査員の方のコメント自体には賛成なのですが、普通に言い方が良くないです。ハラスメントとして不要に相手を傷つけますし、学生本人にも伝わって無いです。加えてハラスメントの部分のみが話題になってしまっています。
良し悪しはさておきとして辛辣さ？という意味ではあのくらいの否定は普通に学会発表とか会社でもあります。発表や研究テーマ全否定とかあるある。ただ、辛口コメントと非難やモラハラは違うのです。感情的に自身がなってると後者に寄ってしまいがちだと思うので、してしまわない用に普段から気を付ける必要がありますね。特に学生や若手相手だと指導の意味合いもあるからなおさら丁寧であるべき。
このツイートで言われてるような言い回しがさらっと出来る用に意識しないとですねー。
あと、質疑応答で（彼らからすると）良く分からない指摘をしかも感情的に言われてるのにちゃんと怒りながらも丁寧に回答されててえらいですよね。
まとめ
今回の件は、モラハラの部分は議論の余地が無いから置いとくとして、やはり課題設定とその実装や発表の仕方には改善の余地があったと思います。
今回のような発表内容が適切な時もありますが、課題に適した実装方法を選択あるいは実施した内容に適した課題設定をしないとOSSや外部APIを自分の成果だと喧伝してると誤解されてしまいます。実際に研究発表みたいな場で話す事が今後なくても、こういう考え方もあるんだ、的に思ってもらえると良いなー。
もちろん今まさに学ばれてる学生さんなのだから、不足があるのは当然です。発表の経験を何度かつめばすぐに身に付くと思います。作られてたプロダクトもしっかりしたものだし優秀な方々だと思うから、今回の事でめげずに頑張って欲しいです。
それではHappy Hacking！
Discussion
自分は、歳は食ってますが、たいして大成もせず定年を迎えそうな、某メーカーの技術者です。この件で、彼らがこういう発表になった気持ちも理解できるので、貴殿同様にその人の気持ちを推し量ってではありますが、コメントしたいと思います。
彼らの解決案は、「IDEの開発」であり、どういう形でも、これができれば、目的(課題)は達成されるのです。自動車のない時代に、「遠い距離を短い時間で移動する」という目的に対して、そこらへんにあるものを組み合わせたら、自動車ができてしまった(と自分達は思っている)、と言い換えればいいと思います。IDE(自動車)ができてしまえばいいのです。成果物そのものが「独創性」を持つので、それのみの発表であっても、コンテストの趣旨にも反してません。
で、IDEは自分達の構想通りにできました。実際には、単に組み合わせたのではなく、それなりに工夫をしているのかもしれませんが、それを意識しない(自分では当たり前のことをやっていると感じながら開発を進める)ことは若手の技術者ならありがちなことだと思います。自分も、上司などに「あなたなりになんか工夫や苦労したでしょ。成果物だけでなくそこを評価したいので教えて」と言われて考えて考えて気付くことがほとんどです。
そうなると、発表では、成果物と、その部品の紹介にならざるを得ませんし、多くの若手の技術者がこういう発表をしてしまっても不思議に思いませんし、貴殿の言う学会発表でもないので、問題ない発表であるとも思います。
まあ、なんら出世もせずに定年を迎えそうな技術者の端くれの戯言でした。読んでいただきありがとうございました。
コメントありがとうございます。
まず、私の書き方が悪くて誤解させてる部分があったのかもなので、念のため書きますが「彼らの発表がダメだ」とか「暴言を言われるだけの非がある」とか言いたいのではなく「せっかくだし研究発表系と製品開発系でフォーカスの仕方に違いがあるのを知って欲しい」とか「今のままでも良いけど100点じゃなくて120点にする方法もあるよ」くらいのスタンスです。おっしゃられてる通り学生さんだし学びのチャンス。ついでにSNS等でこの件を気にしてる人たちの整理になれば、と。なので、彼らを不快にさせると見受けられる部分があったなら、まず謝ります。私の文章力の問題ですね。
それはそれとして書かれてる事はおっしゃるとおりだろうなー、と思います。
彼らがそのように考えたであろう事も自然だし、ああ言う発表をあの場でした事が悪いとも思いません。
アピールするべきことにフォーカスできず全体を話してぼやけたり趣旨と最終的に乖離（したようにみえる）発表をしてしまったことは私も何度もあります。この手の発表に慣れてないとあるあるですね。
コンテストであれば審査員は審査するのだから「あなたなりになんか工夫や苦労」こそを知りたいけど、それが言えてない。だから、若いからこそ今後のために「こういう考え方もあるんだよー」と知って欲しくて今回の記事としてまとめてみました。
だいぶ前の話題ですが、たまたまたどり着いたので、若干見解が異なるかな？という部分について簡単に記しておきます。
これは、彼らが主要な機能として上げているフローチャートの部分ではなく、そもそもフローチャートの部分は出来ていないと彼ら自身が述べています。
参考：
他にも、審査員の言動について否定的な立場から技術的に確認をした何人かの人も、これはフローチャートの部分を本質的に作ろうとしているものではない、という事をコメントしており、その辺りは根本的に彼らがプレゼンで掲げていた題目とずれるアプローチであったように思いました。