sh3_2026_kw

SecHack365 2026年度 開発駆動コース 川合ゼミの説明

• (by K, 2026.04.21)

(1) こんな人を募集します！

• SecHack365 2026年度 開発駆動コース 川合ゼミ」では、こんな人を募集します。
  • 自分が普段使いするものを自作したいという人（自分ではないが自分に身近な人に使ってもらう予定があるならそれでもOK）
  • すでに開発に着手していて何らかの動作ができる（一部の機能しか動かないとかでも、もちろんOK）
• この2つの条件はどちらかを満たしていればいいのではなく、両方を満たす必要があります。

• 私がトレーナーとしてもっとも大切にしているのは、みんなが開発を楽しめることです。「SecHack365のせいで開発が嫌いになってしまった」というのを避けたいです。「前から好きだったけど、もっと好きになった。すごく楽しい」これを目指しています。
• だから無理強いすることはないですし、効率よく早く正解を学ばせることよりも楽しみながら試行錯誤して実感を伴って学んでもらうことを重視します。そもそも何が正解か、そんなに簡単に決められるものじゃないですよね。
• どうしてもうまくいかなくてギブアップしたら私に質問してもらって、私は最低限のヒントを与えてあとは自力で突破してもらう、これが私の理想とする方法です。多くの人は、本当にあとちょっとのところまで来ているものなのです。
  • 2024年度まではプログラミング言語の自作を優先してきましたが、2025年度以降はこれにこだわりません。作る作品は何でもよいです。

• 参考までに、私が今までどんなことをしてきたのかを書いておきます。
  • 1996年～ V98というエミュレータを開発
  • 2000年～ OSASKというPC向けの超軽量型の自作OSを開発
  • 2002年～ naskというx86用のアセンブラを開発
  • 2003年～ tek5というLZMAをベースにした可逆圧縮形式を開発
  • 2005年～ 書籍「30日でできる！OS自作入門」を執筆
  • 2010年～ blikeというC言語用のグラフィックライブラリを開発
  • 2013年～ OSECPU-VMという仮想マシンを開発（このバイトコードでプログラムを書くと驚異的に小さくなる）
  • 2019年～ kcl03というC言語用の基本ライブラリを開発
  • 2019年～ kcll00というC言語用のプログラミング言語開発支援ライブラリを開発
  • 2019年～ ES-BASICというスクリプト言語を開発 （詳しくはこちら→esbasic02a）
  • 2020年～ aclライブラリを開発
  • 2021年～ 「10日くらいでできる！プログラミング言語自作入門」を書く（詳しくはこちら→a21_txt01）
  • 2023年～ easy-CというC言語の改良版を発表 （詳しくはこちら→a23_ec002）
  • 2024年～ easy-Cで電子工作を動かす （詳しくはこちら→https://khfdpl.osask.jp/wiki/?OSC20241026 ）
  • 2025年～ uckという仮想マシンを作って OSECPU-VM で打ち立てた自分の記録を更新 （詳しくはこちら→https://khfdpl.osask.jp/wiki/?OSC20251025 ）
  • 2026年～ acl4というライブラリを作って自分自身の開発力を底上げ （詳しくはこちら→a4_i01）

• まとめるとこんな感じです。
  • エミュレータ自作、PC向けのOS自作、言語自作、圧縮、理想のCPU命令を考える、ライブラリや自作言語を作って自身の開発力を底上げ

• 解決したい課題がセキュリティに関係しなくても応募は可能です。どうやってセキュリティに関連付けるかを応募時点で考えておく必要はありません（それはSecHack365に参加してから一緒に考えましょう）。純粋に魅力的な内容を期待しています。セキュリティに関連した内容だと加点があるかというとそういうことはありません。それよりもあなた自身がこれを使ってこんなことをしたい、だから自分で作るんだという話が聞きたいです。

(2) 補足

• [Q-1] 私はプログラミング言語やOS開発ではない、もっと普通の開発をしたいと思っているのですが、そんな私にどんなアドバイスをしてくれますか？
  • [A-1] まず応援します。あなたの作品のいいところをたくさん見つけます。
  • あなたがもし「次にどんな方向性で開発しようかな」と悩んだら、いろいろヒアリングして、「じゃあ次は〇〇機能を追加したらいいと思うんだけどどうかな？」くらいのことはいいます。
  • どうやれば要領よく自分の作品をプレゼンできるか悩んだら、きっと良いアドバイスができると思います。
  • 私は基本的に必然的なことしか言いません（＝自分の考えを押し付ける気はない）。私がいなくても時間さえかければ同じ結論にはなるでしょう。私はあなたの中にあって、でもあなたが見落としているものを指摘して、ゴールに到達するまでの時間を1/3にするのです。
  • 当初は自分が使うために作っていたはずだったのに、なぜかあなたが自分の作品をあまり使っていないと教えてくれたら、「それはまずい」と指摘して、どうしたら普段使いする気になるかを一緒に考えます。使わない理由が大事です。そこをつぶすだけで一気によくなります。
  • （私自身も、かつて同じ悩みを抱えて、自分のセンスを大幅に改善しました。）
  • 賢すぎて、作る前にどうしたらいいかと考えすぎることってありますよね。そういう時に、「もうどっちでもいいから、一番短期間で作れそうな方法で作り始めてごらんよ、それで一気に色々見えてくるよ。これはダメだと思ったら、その時に別のやり方でやり直せばいいんだよ。一発で成功する必要なんてないんだから。」くらいのことはいいます。
  • 私は失敗を責めません。失敗してもそれで何かが分かって学びがあるなら、それは失敗じゃないんです。やってみなきゃわからないことはやるしかないんです。それで教訓を得ればいいんです。数回繰り返せば、相当な力が付きます。

• [Q-2] 毎週進捗がないと責められますか？
  • [A-2] 川合ゼミでは、週ごとの進捗報告を一切求めません。毎週1時間程度のzoomミーティングをしていますが、それすらも来るかどうかは各自の自由で、しかもそこでは仲良く雑談するだけで終わることもあります。みんなそれぞれ事情があると思うんです。できないときはやらなくていいんです。やる気が出なければやらなくてもいいんです。それでも楽しくお話しできたらいいじゃないですか。・・・私は気長に（というか最後まで）自発的にやる気になってくれるのを待てるタイプです（やってくれないからと不機嫌になることもなく、むしろ私のやりかたがまずかったのではないか、なんとも申し訳ない、と思うタイプです）。・・・だから「放っておかれるとどこまでもだらけてしまう」性格だったら、このゼミは合ってないかもしれません。
  • こんないい加減な方法で本当にうまくいくのか？って思うかもしれませんが、ええ、これで何年もやっていますが、うまくいってしまうのです（心配はごもっともです）。
  • もちろん自発的に自分の進捗報告がしたければ、報告してください。喜んで聞きますよ！
  • SecHack365事務局から出される課題については、もちろん締め切りを守ってもらいます。集合回にも必ず来てほしいです。そこは私のコントロール下ではないので、「気が向かなかったらやらなくてもいいよー」にはなりません。そこはよろしくお願いします。
  • 新型コロナやインフルエンザなどの感染症になってしまった場合、集合回に参加することができなくなります。これは非常にもったいないことです。ぜひこれを機に体調管理スキルを身に着けて、1年間健康で過ごしましょう！（体調管理ができないと、社会人になってからもかなり損をするので、学生のうちにマスターしておくことを強くお勧めします。）

• [Q-3] ChatGPTやそのほかの類似の技術を利用して、応募用紙を書いたりプログラムを書いたりしていいですか？
  • [A-3] 他のコースや他のゼミではダメかもしれませんが、川合ゼミではOKです。ただしChatGPTに文章を書かせて「私は〇〇ができます」と書いたら、本当に〇〇ができなければいけません。つまり書いた内容には責任を持ってください。「ChatGPTが勝手に書いただけだから僕は知りません」というのはダメです。プログラムについても、「ChatGPTに書かせたのでバグがあります、でも直せません」ではダメです。自分が書いたのと同じくらいに責任をとってください。それさえ約束できれば問題ありません。

• [Q-4] もう自分の作りたいものを作り始めているのですが、その続きを作る（改良をする）みたいなのでもいいでしょうか。
  • [A-4] それは技術力と熱意の証明だと思うので、大歓迎です！
  • むしろこれから作ろうと思っている人も、SecHack365での合格通知など待たずにどんどん作ってほしいです。応募前から作ってほしいくらいです。どこまでできたか教えてください。

• [Q-5] 川合ゼミでは、わからないことは何でもたくさん教えてもらえると思っていいでしょうか？
  • [A-5] プログラムの開発の仕方は、何から何まで川合が教えてくれる！という「おんぶにだっこ」な対応は期待しないでください。トレーナーからの指導がなくても、7割くらいは自分で調べて作れるスキルがあるのが前提です。
  • 「7割どころか、全部自力でできると思います！」の人も大歓迎です。私はさらにきっかけを与えて完成度を120%や200%にすることを目指します。

• [Q-6] グループでの応募はできないのはわかってますが、開発が進行していくにつれて他の合格者と一緒にやりたいって思うことがあるかもしれないですよね。その場合、その人とグループを組んで開発をすることはできますか？またその場合にその人のテーマに合わせたりすることもあり得ると思うのですが、それもOKですか。
  • [A-6] そういう状況になれば、OKできると思います。

• [Q-7] 実力を示すためにコンテストでの受賞歴があったほうがいいですか？
  • [A-7] 私は、コンテストでの受賞などをプラスには見ません（もちろんマイナスにもしませんが）。だから優勝したとか高得点を取ったなどのアピールは重要ではありません（もちろんそれでもアピールしたければしてもいいですが）。
  • そうじゃなくて、そこでどんなものをどうやって作ったのかをアピールしてください。・・・結局、コンテストなどの受賞歴は、私からすれば他人の評価でしかないのです。私は私の基準で評価したいので、他人にどう評価されたことがあるかは関係がないのです。

• [Q-8] 応募時に作りたいと思っていたものと、選考合格後に作りたいものが微妙に変わってしまったのですが大丈夫でしょうか？
  • [A-8] どうして作りたいものが変わったのか、その話は面白そうなのでぜひ熱く語ってもらいたいですが、その上で、たいていはOKできると思います。・・・一応書いておきますが、合格するためにもともと興味もないような開発テーマを書いてみても、それはほぼ一発で見抜かれて落とされますのでそんなセコイことは考えないでくださいね。
  • とまあそういうことですので、作りたいものが変わったらどうしよう、今後約1年間もこのテーマに縛られるとしたら慎重に書かないといけないかな、と身構える必要はありません。気楽にいきましょう！

• [Q-9] こちらのゼミでは、年齢情報を選考に利用しますか？
  • [A-9] はい、します。基本的に若い人には加点します。中学生と大学院生を同じ基準で比較するとかは（私には）ありえないです。ですから「自分はまだスキルが足りないかもしれないから・・・」って応募を先送りしてもいいことはないと思います（先送りすればするほど、年齢が増す分だけ不利になる）。とにかく今の自分は何が作りたくてどのくらいのことができるのか、書いてみてください！
  • なお事務局に確認したところ、選考時には事務局に回答した年齢情報が提供されないようなので、問2～問5のどこかに自分の年齢を書いてください（高校〇年生です、とかでも可）。書いてくれれば若い人への加点をします。

• [Q-10] 実はやってみたいテーマが複数あるのですが、どれを書いたらいいかよくわかりません。こういう時はどうしたらいいですか？
  • [A-10] そういうときはたぶん自分だけで考えていてもしょうがないので、ひとまず全部書いてしまいましょう。もし複数書いてあれば、その中で一番好ましいものをこちらで選んで、それで評価します。これで選考を通過した場合、最初の打ち合わせの時にはどれを選んだかお伝えできると思います。でもそれを強制するというわけではなく、もう一度希望も聞きますので、一緒に考えましょう！・・・ちなみに、心にもないことを（受かりたいからと）適当に書いてしまうと、それは見抜かれます。ですから小細工はしないで、素直に書くことをおすすめします。

• [Q-11] 川合ゼミでは、SecHack365で新たな分野に挑戦することは推奨しないということですか？経験者を優遇している感じがします。
  • [A-11] はい、そうです。新しい分野を調べながら学ぶことはSecHack365ではなくてもできることです。それをSecHack365内でやったらとてももったいないと思うのです。・・・SecHack365ではあなたの作品に対してアドバイスをもらう機会がたくさんあります。そのときに「まだ勉強しているところなので、今はデモできません」になると、とてももったいないのです。・・・ですからSecHack365に来る前に独学で勉強しておいて、その上でSecHack365に応募してほしいと思っているのです。・・・まあ、少しは未知の要素があってもいいとは思います。

• [Q-12] 書き方のコツはありますか？
  • [A-12] まず、どんな課題をどう解決したいのか説明してください。・・・[例]先日、おじいちゃんから〇〇だと言われて、それを解決したいと思って既存のツールを探して使ってみたけど、どうもしっくりこない。特に〇〇ができないところが不便だ。そんなの〇〇を使えば簡単にできそうなのに。だからそれを〇〇言語で作りたい。・・・あなたの身近な問題を、あなたの今のスキルの範囲で解決するような開発をしてほしいのです（少しくらいは背伸びしてもいいですが）。

• [Q-13] 他に強調することはありますか？
  • [A-13] あります。どうも一番大事なことがなかなか伝わっていないようです。このゼミでは「なぜその開発をあなたがするのか？」を重視します。・・・単なる社会的な課題であれば、そんなのプログラミングのうまい別の誰かが解決すればいいじゃないですか。あなたが開発する必然性なんてないのです。そういう開発のすべてがダメだとは言いませんが、川合ゼミはそういう人を優先して応援しようとは思っていないのです。しかし逆に、あなたの何らかの実体験から出発して、「先日こういうことを体験したので、今回こういう開発を是非やりたいと思います！」ってなったら、それはまさにあなたが作るべきという必然性になるのです。しびれますよ。
  • だから、まだ作りたいものが決まっていないので、なんかいいネタはないかなと探しています・・・っていうのは川合ゼミ向きじゃないです。川合ゼミのネタは探すものじゃないです。向こうからやってくるものなんです。もし新しい課題に巡り合いたいなら、何か新しいことにチャレンジしましょう。ちょっと旅行してみるなんてどうですか？新しい友達を作ってみたらどうですか？新しいアルバイトをやってみるのはどうですか？そうやって何かすれば、きっと何か気づきがあるでしょう。そうなったら、川合ゼミにGO！というわけです。

• [Q-14] 他のゼミ、他のコースと指導方針が似ているなーと思ったんですが、なぜですか？
  • [A-14] 各トレーナーがどうやって指導したらいいかなーと試行錯誤しているうちに、なんとなく同じようなところに落ち着いてしまったのかもしれません。
  • また私たちは「あのコースのあのやり方はうまいからぜひ真似してみよう」と言って真似することもあります。私たちは、できるかぎり最善の方法で指導したいと思っているのです。

• [Q-15] 自分で使うことを強調した応募条件になっていますが、川合は最初からそういう考え方の人だったのですか？
  • [A-15] いいえ。私もかつては自分が使うことをそれほどには意識していない開発者でした。
  • 私はかつてOSを自作していて、それを自分で使う日々を送っていたのですが、何年かしたあるとき、自分が最近は自作のOSをあまり使っていないことに気づきました。私は直感的にこれはとてもよくないと考えて、なぜ使わないのか、どうなればまた使うようになるのか、自問自答を繰り返して改良を始めました。それが自分の大きなスキルアップにつながったと感じています。
  • そもそも、何かいいものを作ればたくさんの人がダウンロードして使ってくれるだろう、という見通しはかなり甘いです。実際はほとんどダウンロードされませんし、ダウンロードしても1回使って終わりです。つまり実質ユーザ数0です。誰も使わないものを苦労して作って何になるでしょう。使われるものを作るべきです。使われるものを作れるようになるべきです。誰も使わないものをいくつ作ってもそれはむなしいです。
  • だから開発者自身が使いましょう。開発者は何らかの必要性を感じて作り始めたはずです。それなら開発者が使えばいいじゃないですか。これでユーザ数は少なくとも0ではなくなります。そして日常的に使い始めると、ここが不便だという気付きがどんどん出てきます。でも開発するのは自分なので、大変すぎる改良はあきらめて、「簡単にできて、不便を解消できそうなこと」をうまく選ぶようになります。こうしてバランスの良い開発ができるようになります。
  • あなたが便利そうに使っていると、他の人も関心を持ってくれます。「え、何それ？どこでダウンロードできるの？」みたいに。・・・逆のことも考えてみてください。開発者すら全然使わないようなものを、他人が使いたいなんて思うでしょうか。おすすめしたとして説得力があるでしょうか。・・・そういうことなんです。だから「自分が使う」っていうのはとても大事なことなのです、みんなが思っているよりも。
  • まずはたった一人でいいから、その人のニーズを完全に満たすべきです。不特定多数を想定してあれとこれとそれをつけておけば便利だろう、なんてまさに机上の空論で、何の意味もないのです。あっても使わない機能ばかり揃ったプログラムには魅力も価値もありません。

(3) 今までの川合ゼミの修了生

• 以下の通りです。どんな感じか参考になるかなと思ったので挙げておきます。
• 最初からすごい人もいましたし、SecHack365内で急成長した人もいました。リンク先には詳しい作品紹介があります。

  2018年度	14: プログラミングの見えない課題を可視化する-デバッグ支援ツールHIDE-	古川 菜摘 さん
  2018年度	24: 言語統一のためのTepu言語	竹内 和貴 さん
  2018年度	25: TOMMY~transform of memory~	三谷 日姫 さん
  2018年度	36: CPUに対するセキュリティ機能追加の提案	田村 来希 さん
  2018年度	37: IoT向け言語の開発	宇佐見 大希 さん	（表現駆動コースからの川合ゼミ参加）
  2019年度	D01: セキュアで楽に書けて速いプログラミング言語nek-ot	秋山 陸 さん
  2019年度	D02: Programming Language maxc	飯田 圭祐 さん
  2019年度	D03: コンピュータ技術を作り直すmemepu（仮	Eliot Courtney さん	[優秀修了]
  2019年度	D04: Unpep - Enhanced Golang Syntax	Jantakorn Passawee さん
  2020年度	D02: Tarto：マイコンをインタラクティブに制御できるプログラミング言語とWEB IDE	田中 健 さん
  2020年度	D03: 安全に書けるAltC++なプログラミング言語 Grid	辻本 宗一郎 さん
  2020年度	D04: 仕組みを理解しやすいシンプルなハニーポット Stepot	豊田 昂輝 さん
  2021年度	D05: プログラミング言語RSC~メモリ安全性があり他言語関数呼び出しが容易な言語~	平山 快 さん
  2021年度	D06: 音遊びプログラミング言語 Oto	古田 尚樹 さん
  2021年度	D07: mirlvm：セキュアで高速なコンパイラ基盤の開発	吉村 仁志 さん
  2022年度	D02: SysDC 〜設計を支援する言語〜	中神 悠太 さん	[優秀修了]
  2022年度	D06: Althea〜安全で安定したコードを簡単に書ける言語〜	八木橋 拓之 さん	[優秀修了]
  2023年度	16Dk: セキュリティをGUIで もっと分かりやすく！ Control Watcher	高島 翔瑛 さん
  2023年度	34Dk: タイムラインを活用したプログラムの動作を可視化する学習システムの開発	丸山 拓真 さん
  2024年度	12Dk: ゲーム開発者がチート対策を意識しなくていい言語 Naughtiness(ナギ)	奥野 凌汰 さん
  2024年度	24Dk: 競技プログラミング向けのプログラミング言語 Albat	鳥海 翔一 さん
  2024年度	27Dk: HaloML 新しい機械学習フレームワーク	中村 壮馬 さん

(4) 掛け持ちについて

• 私としては、他のことと掛け持ちしない人が好ましいと思っています。他のイベントにも積極的に参加しています、したいです、っていう人はきっと時間が足りなくなって、成果が中途半端になりやすいと思うのです。まあそれも人生なので仕方ない面はありますが、できればSecHack365に集中できそうな時期を選んで応募してくれたらうれしいです（まあ多少のことなら並行してやってもいいのですが・・・）。
• また大学などの研究テーマ（今やっているやつ）をそのまま持ってこられたりするのは少し困ります。なぜなら、どこからどこまでがSecHack365の成果なのかわかりにくくなるからです。趣味で前からコツコツやっていた、とかはOKです。それなら成果の区切りがあいまいになっても、大きな問題にはならないからです。同じ理由で、今年の未踏でやっているテーマをそのまま持ってきた、というのも困ります。未踏に限らず、他のイベントとの掛け持ちはすべて該当します。

• もしこれらの掛け持ち問題がありそうな人は、応募時に自己申告して、かくかくしかじかの理由でうまく切り分けられるので心配しないでくださいって教えてください。
  • まあでも、掛け持ちするくらいなら、そっちをメインで最後まで頑張るほうがいい結果になりそうな気はしますよ！「二兎を追う者は一兎をも得ず」っていうじゃないですかー。

(5) 作り方について（私がどういうアドバイスをするのかの典型例です）

• [1] たとえばコンパイラ言語を作りますという場合、字句解析・構文解析・意味解析・最適化・コード生成・・・みたいに分けて考えて、それを全部作ろうとします。そしてそれぞれの開発に1週間ずつ時間を割り当てて、全部で5週間かけて作ろうとして、でも途中で忙しくなったりバグで苦戦したりして、さらに5週間を要して、トータルで10週間、つまり2.5ヶ月してやっと動くものができました！・・・これはよくあります。というか半数以上はこのパターンです。
• 動くようになってみると、なんかいろいろと「想像していたのと違う」ところが出てきます。だから手直しが始まります。それぞれのブロックをていねいに作ってきたはずなのに、たくさん書き換えるわけです。これは無駄です。

• [2] そうではなくて、こう作りましょう。まず、a=2; b=3; c=a+b; これ以外の命令は来ない言語を考えます。字句解析はこの3パターンのどれが来たかを判定すればいいだけなのですから、超簡単です。初めてでも1時間でできるでしょう。慣れれば10分未満かもしれません。構文解析も簡単ですし、それ以降も全部簡単です。たぶん、3時間とかで全部できるはずです。想定されていない入力が来たらバグってしまうかもしれないけど、別にそんなのどうだっていいんです。なんせ最初のバージョン0なんですから。とにかく上から下まで一通り書いたことで、どこに難所があるのかもわかります。・・・先のことなんて今考えてもわかりません。だから全部やっつけのへぼい関数を作っていきましょう。将来的に「これじゃだめだ」ってなったらその時にクラスを再設計すればいいだけです。ろくな知識もないのにまともな設計をしようだなんて、10年早いんです（笑）。

• [3] その後、加算だけではなく四則演算に対応するとか、ifとかforとかも使えるようにするとか、そうやって機能を増やしていけばいいんです。「2.5ヶ月しないとピクリとも動かない」vs「3時間で代入と加算だけならできる」です。
• また機能を追加していく際には、「既存言語にあるような普通の機能」ではなくて「この言語だけが持つ新機能」を優先的に作るようにすると、さらに良いでしょう。普通の機能なんて、デモで見せられてもそれほどうれしくはないのです。誰でも想像できますからね。新機能こそ見せてもらわないとわからないのです。その新機能のデモをするために普通の機能も少し必要だってなったら、その部分だけ入れておけばいいでしょう。
• 私はそういう作り方をよくやるので、言語固有の面白い機能はすでにいくつかあるのに、なぜか基本演算は整数演算しかまだできてないとか、while以外のループ命令が入ってないとか、そんなのはよくあります。・・・そういう平凡な機能は、私が作らなくても誰でも作れるじゃないですか。そんなところを作るためにSecHack365期間の貴重な時間を使う必要なんてないと思うんです。必要になったらその時につけるくらいで十分です。

• [4] 別の方法もあります。すでに動いているオープンソースの言語をもらってきて、それを改造することで作っていくという方式です。改造しやすそうな言語を見つけられるのなら、それを使えばいいです。あなたが過去に作ったことがある言語があるなら、とりあえずそれを丸ごと持ってきてしまえばいいです。バージョン0を作るためなんですから、なんだっていいのです。・・・今どきの方法ならAI先生に適当に作ってもらってもいいかもしれません。バージョン0だから、なんだっていいのです。

• [5] こういうやり方はコンパイラ開発に限りません。ポイントはとにかく雑に小さく始めて、短期間で何らかの動作デモができるところまで作り切ることです。・・・私は2006年に「30日でできる！OS自作入門」という本を書いていて、そこには30日間の開発工程がありますが、「30日後に完成してやっと動かせる」のではなく、「仮に1日目でやめてしまったとしても、それなりには動く」ようになっています（もちろん大変に貧弱ではありますが）。

• [6] あなたの作品に何か短所があるとします。たとえば「〇〇がまだできない」とか。・・・短所は簡単に思いつくので指摘されやすいですし、開発者本人も気になることです。だから多くの人は、気になる指摘されやすい短所を優先的に直そうとします。
• でもこれはよくない戦略だと私は思います。・・・実は、できないことができるようになっても、作品の可能性は増えません。この短所がなければどうなるか？なんて誰でも簡単に想像できるからです。そこが改善されても、驚きや意外性はないのです。

• [7] そうではなくて、長所をさらに高めたり、新しい長所を付け加えたらどうでしょうか？・・・「ええ！そこまでできちゃうの？！」「そんなこともできるの？！」・・・想像を超えているので、ここをやるべきだなんて普通の人は指摘してくれません。でも、それこそあなたが次にやるべきことなんです。これができたら、作品の可能性は高まります。
• だから先に長所を伸ばしましょう。伸ばして伸ばして伸ばしきって、これ以上長所は伸ばせないってなってから、短所を埋めていきましょう。そういう順序がいいです。

• [8] この作り方をしないで、指摘された短所を「確かにそうだ、ここを直さなければ」ってやってばかりいると、開発者本人もだんだんつまらなくなってきます。自分のためにやりたいことをやっているのか、他人にまた指摘されないために言われたことをやっているのか、よくわからなくなってくるからだと思います。・・・「これができるようになったらみんなびっくりするだろうなあ」ってワクワクしながら作るのが一番楽しいじゃないですか。・・・開発が楽しくなくなってくれば、もちろんその先にどうなってしまうかは言うまでもありません。

• [9] 例外はあります。・・・その欠点を直すことで新しい応用ができるようになって、「想像を超える」効果が出せるなら、それはやるべきです。可能性が広がるからです。

• [10] あなたの作品の処理が重くて、ちょっと使いにくいなっていうのは非常によくあることです。だから高速化したいなって思うわけです。でもその高速化で50%速くなるとかの場合、そんな高速化は多分後回しにするべきです。速くなったらどうなのか？は想像できちゃうからです。・・・これが3倍とか10倍とか極端に高速化できるというのなら、それはもはや「使い方が変わる」かもしれないので、今やっていいと思います。そういうことです。

• [11] 一方で、あなたの作品の長所の一つが「高速性」なのだとしたら、話は別です。10%の高速化であっても優先的にやるべきです。だってそこまで速くできるなんて誰も想像できないからです。

• [12] 自分の作品を紹介するときに「〇〇機能を付けくわえたら〇〇の用途にも使えます」みたいに説明して、自分の作品の可能性を大きく見せようとする人がいます。・・・実際にあなたが近い将来にその機能を付けくわえて〇〇の用途で使う予定があるのなら、そのアピールはきっとプラスだと思いますが、「誰かがそういう拡張をやれば、そういう応用ができるかもしれない」程度の話だったら、言わないほうが（書かないほうが）ましです。
• その程度の可能性だったら、それこそ誰にでも何とでもいえるのです。どんなポンコツなプログラムでも、直せば世界最高のプログラムになるんです。でもそれが何だというのでしょう。当たり前すぎて情報量ゼロです。・・・あなたにはそういうつもりがないことはわかっていますが、しかしそういうふうに見えてしまうのです。

• [13] こういう主張が入ると、一気にそれまでの説明が薄っぺらくて嘘っぽくなります。だからそういうことを言う癖がもしあったら、それは我慢して言わないようにしたほうがいいと私は思います。・・・自分がやる予定のことだけを言えばいいのです。そうすれば薄っぺらくはなりません。

(6) ちなみに

• ちなみに、学習駆動コースも川合ゼミに似たテーマを扱っていますので、そちらも確認しておくと、後になって「ああ、それだったら学習駆動コースにしておけばよかった！」と後悔しないで済むと思います。

• SecHack365のホームページはこちらです。 → https://sechack365.nict.go.jp/