今触っているコード、最後に実行したのはいつですか？

私は30分前、その前は50分前です。

コードを弄り続けていて、もう数日以上実行していないあなたへ。
ぜひこの記事を読んでいってください。

⭐はじめに

趣味でも仕事でもゲーム・アプリを作っている、Riniaといいます。

この記事は、私の経験則をもとに書かれています。
自身の悪い癖と格闘し続けて2年半の末、ようやく改善にたどり着いたため、その内容を文章化しました。つまり、みなさんへの報告であると同時に、私自身への言い聞かせでもあります。

同じ悩みを持つ方にとって、少しでも今を見直す機会になれば嬉しいです！

⭐この記事を読んでほしい対象

• 趣味レベルのアプリを、個人で開発している人
• よく思考を巡らせながらコーディングをすることが多い人
• もう何日もコードを実行せずに編集し続けている状態が続いている人

⭐伝えたいこと

趣味での個人アプリ開発において、陥りがちな 「宙に浮いた思考だけが先走り、開発のゴールまでの道筋が見えない」状況を私なりに対策できた ので、その内容を伝えられればいいなと思います。

💭こんな経験、ありませんか？

アプリ開発において、こういう経験はないでしょうか。

😰「振り返ればいつだってリファクタリングしてる。」
――― 設計の勉強中です！

😜「gitに大量の変更を一括でcommitしてしまったけど、個人開発だからいいや。」
――― 気付けばほとんどのファイルがmodified

😤「今は外から見えない部分を作っているけど、これが終わったら見える部分を一気に作るんだ！」
――― この作業は後で報われる！

これらのケース、私は全部心当たりがあります。このとき何が起きているかというと、

• 実装のモデリングを、脳内だけで過剰に行っている状態

になってしまっています。そのコードは、まさに机上の空論なわけで、このようなコーディングを私は

🚨「机上の空論コーディング」🚨

と呼んでいます。

この状態は、私だけでなく、私の周りでもよく陥っている方を見かけます。

（私の例）開発の初期段階ですが、実行せずにいきなり抽象的なことばかり考えています。

🖋「机上の空論コーディング」の例

まずは、このエピソードをご覧ください。

🚲「モデル層」とは？

アプリの中でも、特に抽象的な処理を行う部分。「ドメイン領域」に似ている。

例えば、ゲームのプレイヤーだったらこのような感じ。プレイヤーの持つ「状態」と「振る舞い」のみを記述する。

// プレイヤーのモデル
public class Player {
    public int X { get; private set; } // X座標の位置
    public int Y { get; private set; } // Y座標の位置
    public int HP { get; private set; } // 体力

    // 移動する
    public void Move(int x, int y) {
        X = X + x;
	Y = Y + y;
    }

    // ダメージを与える
    public void Damage(int damage) {
        HP = HP - damage;
	if (HP < 0) {
	    HP = 0;
	}
    }
    
    // 即死させる
    public void Kill() {
        // Damage(HP); としてしまうと、ダメージ軽減等が発動した際に即死できないため、
        // 強制的に0にする
        HP = 0;  
    }
}

「モデル層」は抽象的なため、「画面表示」「プレイヤー入力」「通信」などの現実的な部分と切り離さなければいけない。

（ここで言う「モデル」は「概念モデル」のこと。これは、「現実のものを必要な要素だけ抜き取って単純化したもの」という意味。）

プログラミング歴3年のあなたは今、新しくボードゲームを開発し始めました。

😃「仕様書も書き終わったし、いよいよコードを書くぞー！」

🙄「ボードゲームだから、ゲームロジックが依存の中心にあって、UIはその外側になるな……」

😎「ってことで、まずはゲームのモデル層から作っていこう！ 駒と、ボードと、それからプレイヤーと……」

――― 数時間が経過

😥「ここの依存関係がこうだから……」

――― 数日が経過

🤔「いや、これはイベントソーシングを使って過去の状態を遡れるようにした方が便利か……」

――― さらに数日が経過

😒「ここはこの方がいいんじゃないか？いや、まずは今考えてることを書き出さないと……」

――― そして数日、数週間、数か月と過ぎていった……

🤗「今ね、ゲーム作ってるんだ！」

😲「へぇ～すっごい！どんなの作ってるか見せてよ！」

😓「えっと……ちょっとまだ自分以外が見て分かる段階じゃないんだよね……」
😒「（まだモデル層を作る段階だし……）」

この先は想像にお任せします。これ本当は私の実話なんですよ。

このシナリオでのあなたは、モデル層から先に作ろうとした結果、思考の赴くままに抽象的なコードを書き続けました。 いわゆる 🚨「机上の空論コーディング」 🚨です。

このような場合、コードを脳内だけで実行し、実際に実行しない状態が数日、下手すると数か月続きます。

（私の例）このフォルダ群は、全部編集中（赤色）になっています。大規模リファクタリングと称して、この状態がずっと数か月続いていたりしました。

🖋「机上の空論コーディング」に陥らない例

一方、こういうシナリオもあります。

プログラミングを始めたばかりのあなたは今、新しくボードゲームを開発し始めました。

😋「えっと、まずは駒を表示できるようにしたいな……。 ひとまず画像を指定して表示っと……」

😆「きた！じゃあ次は、クリックして駒を選択できるようにしてと……」

🙂「選択ができたから、今度はもう一回クリックしたときに駒を置けるようにして……」

😗「動いた！けど、このままじゃボードの外に置けちゃうから、そこを直して……」

――― 数日が経過

🤗「今ね、ゲーム作ってるんだ！」
😲「へぇ～すっごい！どんなの作ってるか見せてよ！」
😎「いいよ！まだ深いところまで作りこめてないんだけど、ひとまず遊んでみて！」

😆「おお！楽しい！ここに○○みたいなルールを追加したら面白そう！」
🥰「確かに！次試してみよっと！ありがとう！」

非常に楽しそうです。初心を思い出します。実はこっちもほぼ私の実話です。

どうでしょうか。
私が伝えたい🚨「机上の空論コーディング」🚨というのが伝わりましたでしょうか。

それでは次に、なぜこうなってしまうのか、原因を考えていきましょう。

💦「机上の空論コーディング」をしてしまう理由

目標が細分化できてない。 これに尽きます。

まずはゲームのモデル層から作っていこう！ 駒と、ボードと、それからプレイヤーと……

「モデル層を作る」「リファクタリングをする」などというのは、目標が大きすぎます。 そのため、今できることの選択肢が膨大になってしまい、目の前にある気になることに飛びついてしまいます。

つまり、目標を細分化できればいいわけですが、実際やろうとすると上手くいかないことが多かったです。

😥上手くいかなかった例

• gitにおけるcommitの粒度を小さくする。
  あまりの開発テンポの悪さに耐えられなくなり、gitを使わなくなってしまった。
• ToDoリストにタスクをリストアップする。
  次第にリストアップした内容と都合が合わなくなってしまい、結局無視してしまった。
• テスト駆動開発をする。
  開発のテンポが悪い上に、そもそもテストコードを書くことに目的が逸れてしまった。

そこで、私が現在進行形で上手くいっている目標の設定方法を紹介します。

💦目標の設定方法

アプリ開発を進めたいならば、目標は
「アプリを動かす際のワンシーンを、実際に目の前で再現すること」
にすると良いです。

まずは駒を表示できるようにしたいな……。
次は、クリックして駒を選択できるようにしてと……

なぜなら、想定するシナリオを1つ1つ実現していけば、いつかは完成するからです。

💦「動けばいい」の意味

こういうことを聞くと、私みたいな人は
「動けばいいだけだと、コードの質が落ちそう…… 変更や修正に強くできないし……」
と思って余計に逆張りします。

しかし、動かすこと以外意識するな！とは言っていません。あくまで、今たどり着くべき目標を、明確で現実的なものにすることが大事というだけです。

コードの品質は、目標を達成する過程で上げていけば良いのです。

💦なぜ「実際に動かすこと」が大事なのか

「じゃあ、目標を細かく設定すれば、実際に動かさなくてもいいのでは？」というと、そうもいきません。

私がなぜここまで「実際に動かすこと」を強調するのかというと、

• 経験上、実際に動かす過程でいろいろ不都合が判明する

からです。
例えば、モデル層を先に完成させ、UI層や外部ツールを使用する部分を後から作り始めたとき、

😥「外部ツールの仕様が思ってたのと違った…… 大規模な変換メソッドを用意しないと……」
――― 外部ツールの調査不足や思い込み

😥「UX的にこうした方がユーザーに親切かもしれない……でもこのモデルを使うには大規模な実装を挟まないと……」
――― 実際にユーザー体験をしないと分からないことの判明

😥「ん？結局モデル層のこのメソッド、実際に叩く時どうするつもりなんだ？」
――― APIとして叩かないと分からないことの判明

みたいなことが十中八九起こります。

アプリ開発の初期段階で、これらを想定するのは相当難しいです。大体思い通りにはいきません。
こういった理由で、モデル層のみを先に作るのはオススメしません。実際に動かしながら作りましょう。

🤬「モデル層を強固に作っておけば、どんな環境でも問題ないんだ！」

夢の見過ぎです。現実を見てください。 そう、そこのあなたですよ、2年前の私。

✨「机上の空論コーディング」をなくすには

先ほど、目標には 「アプリを動かす際のワンシーンを、実際に目の前で再現すること」 を設定したほうが良いと話しました。

しかし、目標を設定すること自体が難しいため、このままでは結局また好きなようにコードを書き始めてしまう恐れがあります。

そこで、私なりに 「こうすると上手くいったよ！」 という方法を2つ紹介しておきます。

✨①定期的にコード全体を実行する習慣をつける。

「実際に目の前で動かす」という目標設定が難しいならば、逆に「実際に目の前で動かす」ことを習慣にすると楽です。

一定時間以上コードを実行していないときに「やべっ」と思うようにしておくだけでも、全然違います。

私個人の目安として、【2時間以上】コードを実行せずに書き続けていたら危険信号です！ 今すぐ「今何してるんだっけ？」と自分に問いかけましょう。

✨②「今のツッコミどころはどこか？」を意識する。

具体例で示したこのシーン。

もう一回クリックしたときに駒を置けるようにして……
動いた！けど、このままじゃボードの外に置けちゃうから、そこを直して……

このように、「今このアプリを誰かに見てもらったとき、まず突っ込まれそうなのはどこか？」という見方をすると、次にしなければいけないことが見つかりやすいです。

💔「机上の空論コーディング」をしていることに気付いたら？

私は🚨「机上の空論コーディング」🚨をしてしまっていることに気付いた場合、

• その部分のコードを破棄する

ようにしています。

途中まで作ったものを作り直そうとするのは、今までの労力が無駄になってしまうため良くない

という意見は多いですが、この場合は特殊だと思います。

なぜなら、このセクションで書いた通り、改めて開発を進めたとき「机上の空論コード」は不都合を引き起こすからです。
コードに思い入れはあると思いますが、後々「ああ、不要だったな」と思うことが多かったです。

---

ここまでは、🚨「机上の空論コーディング」🚨の対策について話してきました。本記事で主に伝えたい内容は、以上となります。 要点だけ見に来たよ〜という方はまとめへどうぞ。

ここからは、🚨「机上の空論コーディング」🚨の実態について、解釈を深めていきます。興味がある方は、ぜひ見ていってください。 共感できるかもしれません。

---

👓「机上の空論コーディング」が起こりやすい状況

私の経験をもとに、こんな時に起こりがち！というシーンを並べていきます。恐らく、同じ経験がある方には共感していただけるのではないでしょうか。

そうでない方も、このような状況下では注意した方がいいかもしれません。

👓①プログラミングに慣れた後

プログラミングに慣れると、一気に大量のコードを書いても意図した通りに動くことが多くなると思います。
このように、より大規模な実装を脳内で展開することができてしまうため、実行を伴わなずにひたすらコーディングすることが出来てしまい、🚨「机上の空論コーディング」🚨をしてしまいます。

また、プログラミングを始めたての頃と比べると、書くコードも、書いているときに考えていることも現在はかなり変わってきたのではないでしょうか。
新たに知識や経験を得たことにより、「この方法は良くない」「こういうパターンが好ましい」と思考が巡り、様々なことが気になってしまい🚨「机上の空論コーディング」🚨をしてしまいます。

「私は初心者とは違うんだ！」という逆張りも、私には心当たりがあります……

👓②開発人数が1人・締め切りがない

趣味の個人開発では、自分の都合だけを考えればよく、また誰にも開発状況を共有する必要がありません。
そのため、自分の脳内だけで完結し、好き勝手出来るため🚨「机上の空論コーディング」🚨をしてしまいます。

締切がない場合はもっと怖いです。時間が無限にあるため、あなたが書いたコードに自己満足するか、道をそれていることに自分で気付くまで、ゴールのない迷宮をさまようことになります。

👓③あなたの性格

あなたが神経質だったり完璧主義だったりすると、細かいところが気になって目的を逸れてしまうことがあります。
また、普段から考え事に慣れていたりすると、抽象的な思考が捗って、地に足が付いてない状態になったりします。

💫机上の空論コーディングの悪影響

共感する方にとっては（私を含めて）耳に痛いと思いますが、改めて整理してみます。

💫開発に進展がなくなる。

アプリを動かすためではなく、自分が満足するためにコードを書いているため、開発には進展が現れません。
そのままモチベーションが低下し、プロジェクトが自然消滅してしまうケースもあります。

💫情報の共有ができなくなる。

脳内で過剰に思考を走らせてしまっているため、情報のアウトプットができません。
これにより、以下のようなケースで困ることになります。

• 「今、なにをしているの？」と聞かれても詳細に経緯を説明できない。
• 「初心者が、小さくても動いてる作品を見せて応援してもらってる」様子を見て、嫉妬する。
• 自分の仕事を他のプログラマに引継ぐことができない。

（私は、「よく考えて書いたコードは、それを読む人も同じ思考を辿らなければいけない」ということを常に忘れないようにしています……）

✅まとめ

この記事の要点を整理すると、このようになります。

✅ 実行を伴わず、脳内で過度に考え続けてコーディングをする人がいる。 この行為を「机上の空論コーディング」と呼んでいる。

✅ 「机上の空論コーディング」をしてしまう理由は、目標が細分化できてないから。

✅ 目標を細分化するには、「アプリを動かす際のワンシーンを、実際に目の前で再現すること」を目標に設定すると良い。

✅ ただ、目標設定をすることは意外と難しいので、代わりにこの2つを意識すると楽。
① 定期的にコード全体を実行する習慣をつける。 2時間以上開いたら危険信号。
② 「今のツッコミどころはどこか？」 を意識する。

🔷最後に

ここまで話した内容が、少しでも共感していただけて、少しでも参考になったなら嬉しいです。

この内容は、私が現在までの個人開発で得た学びの総まとめであり、私自身もこの内容を忘れないように活動していこうと思います。

また、私はこの先、就職によって今までとは全く違った環境で活動することになります。そうなった場合に、今までとどこが違くてどう変えていく必要があるのか、試行錯誤をこれからも絶えず重ねていこうと思います！