「明日からGitは使えなくなります」

って言われたら、どうしますか？

もう世界中が阿鼻叫喚だと思います。
（Subversionがある？　シッ、空気読みなさい！）

上記はマーケティングのアンケートでよく使われる質問例（PMF）ですが、冗談じゃなくGitの持つエンジニアへの影響力は世界的なものだと思います。
そのくらいパワフルなGitですが、非エンジニアの方からしたら「ナニソレ？」ってのが実情です。

もったいない。

プログラムを書かない人には必要ないでしょ、なんて意見もあると思いますが、でも本当にそうでしょうか？Gitを使いこなしている人は、プログラム以外の場所でもGitを利用しています。
共同編集できることとか、バージョン管理できることとか。
これらを活かして様々なファイルを管理して、世の中のクラウドサービスでは有料にして実現できること表面的に自前で代用してたりしてアッパレ！！なんて実用例があります。

それだけ有意義なGitですが、結局非エンジニアの人にとってはラーニングコストがでかい。
コミットとかマージとか、ブランチとか、普段の生活ではイメージしにくい言葉の連続です。

Gitを非エンジニアも使うようになると、有意義なだけじゃなくてエンジニアのストレスも多少減るんじゃないかなーなんて思っていたときに以下の記事を見つけました。

なるほど。これは良い。

そしてラッキーなことに、自分はオノログというWeb小説専門のレビューサイトを運営しています。ある程度、ネット小説を書く人たちとのつながりもある。

これはワンチャン、面白い制作ができるのでは？

ということで、Gitを利用したデスクトップ用のテキストエディタを開発しました。
その名も 「KANZUMEエディタ」 。

前置きが長くなりましたが、今回の記事は「デスクトップアプリ個人開発の過程と学び」の共有と宣伝（コレ大事）になります。

利用したのは主にelectron,typescript,React,SQLiteです。

そして重要なことですが、開発者はプロのエンジニアではなくプログラミング独学者です。

個人開発こそ設計命

自分はプログラミングを独学している人間なので、仕事上での設計とか１ミリも知りません。
でも今回、設計がどれほど大事なのか血反吐を吐くほど痛感しました。

むしろ企画・設計・実装・テスト・マーケティングとすべてに触れたからこそ、比較できるものではありませんが仕事で感じる以上に、近距離でメリットを感じられた気がします。

というのも、最初はぼんやりと「こんなの作りたい」「ターゲットはこんな人」とマーケティング的なコンセプトと設計だけ決めて、技術的な設計は特になにもせずに手を動かし始めました。

そして結果は「三歩進んで二歩下がる」みたいな無駄を生産ばかりする開発。

必要な機能は書き出していましたが、詳細を詰めていなかったので、あとから出てきた機能を追加するとライブラリが食い合ったりして駄目じゃん！となったり、クラスやデータの設定が変わったので最初に書いたコードが全部無駄になったりと、非効率のかたまりでした。

さすがにこれはヤバイ。。。と震えて、初めてフロー図をみっちり書きました。こんな感じのを何枚も書きました。きれいなフローチャートではないですが、それでも頭の中は遥かに整理されます。

いままでは大まかな操作の流れが分かれば良いっしょ、と適当な感じでしたが、もうシュミレーションで全部の機能が再現できるまで書ききりました。

正直、フロー図を書くだけでかなりの時間をとられるので、わかりきったことを書くの勿体ないなぁなんて思っていましたが、トータルで見たら圧倒的に効率的です。

無駄にコードを消して書き直す回数が極端に減りました。

最初からこれしてれば。。。

技術選定はsandboxを使い倒せ

上記に付随してですが、今回エディターなのでリッチテキストエディタのライブラリを選定する必要がありました。
様々な要素を検討して、最初に導入したのはEditorJSというライブラリです。

実装も簡単なので、トントン拍子だったのですが、実際に使ってみて驚愕の事実が。。。

EditorJSはブロック式（Notionみたいなやつ）のエディタなのですが、ブロックの途中から途中までの文字選択ができないのです！
ブロックをまたぐコピーセレクトをしようとすると自動的にブロックまるごとをセレクトしやがるのです！字書きにとって、これは致命的。
Notionやnoteなどのブロック式エディタでこんな問題に直面したことはなかったので、まさかできないなんて思っても見ませんでした。技術選定で参考にした記事では、そんな重箱の隅に言及しているものもありませんでしたし、、、

sandboxはなんとなくイメージを掴むためや、実装の参考に利用していましたが、技術選定の時からテスト代わりに様々に使っていれば、最初から分かっていたことでした。公式ドキュメントを読むことも大事ですが、それと同じくらい実装例でテストすることが大事だと知りました。

実際、そこでヤバイ！！と思ってドラッグ&ドロップ機能のライブラリをもう一度精査しました。

こちらは想定外のことは起こらなかったのですが、運が良かっただけで、最初に実行すべきでした。

ChatGPTを過労死させろ

今回、大活躍したのはChatGPTです。上記のような非効率な開発過程でしたが、それでも公開までにかかった時間は三ヶ月。前回、制作したオノログというサイトは半年近い時間がかかったことを思うと圧倒的な差があります。

具体的な使い方などについては、また別記事にしたいと思いますが、本当にChatGPTは優秀です。

でも、だからこそ気をつけないといけないことも。

先の設計に通じる部分ですが、間違った方向で開発していても、それなりの回答を出してきます。
だからChatGPTを使わない方が効率良かったな……なんて場面も数え切れないほどありました。

それでも間違いなく、ChatGPTは神ツールです。プログラミングに関しては色々なAIが登場してきていますが、未だに頭ひとつ抜けている、というのが自分の実感です。

特に活躍の大きかったところを挙げると

エラーの発見
公式ドキュメントの翻訳と要約
変数・関数名の命名

です。

これだけで、大体どんな使い方かはピンとくると思うので、この記事ではここまでで。
とにかく、ChatGPTには農奴制も真っ青なブラック環境で働いてもらいました。感謝です。

ポモドーロ・テクニックって、超優秀

プログラミングと関係ない話になりますが、今回、開発をやり切れた理由のひとつはこれです。
しかも、よくある「ただ25分測って、5分休憩する」だけのポモドーロ・テクニックとは違います。

考案者であるフランチェスコ・シリロが提唱する、まさに厳格なポモドーロ・テクニック。

25分ごとに目標を決め、振り返りもする。

これをすると、25分でどれだけのことができたのか、できていないのかが視覚化されます。
「テキストの名前変更フォームを完成する！」と決めて、成否がまるわかりになります。

なんとなくコードを書いた量を見て、機能は実装できてないけど、よくやったぜ俺！（ニッコリ

みたいな幻想をぶち壊して、ゴミ箱に投げ捨ててくれます。

あまりにも素晴らしすぎたので、次は厳格なポモドーロタイマー作ろうかな、と思ってるほどです。まぁ、まずはエディタの修正だけど。

と、これが今回の開発のなかの大きな学びでしょうか。

以前に個人開発をしていたときは、インプットの量が半端なく無我夢中の状態だったのですが、今回は全体を俯瞰して反省できるくらいには余裕があった気がします。

まぁ、これもポモドーロのおかげかな？

開発したKANZUMEエディタはGithubで公開しています。速度優先・実行優先の開発だったのできちゃないコードですが一応全部公開済みです。

良ければ覗いて使ってみてください。

長文失礼しました！