Miraiプログラミングの文法は覚えたけど、いざ自分で何か作ろうとすると手が止まる。どうやって考えればいいの？
Zetto今回はプログラミングの考え方を磨く具体的な方法を解説するよ！
現場で使える本質的な思考法を身につけよう。
現役エンジニアのZettoです。実務でプログラミングの考え方を磨き続けてきました。現在はフリーランスエンジニアとして、複数の開発案件を任されるレベルになりました。
【保有資格】Java Gold / その他Web資格7種
結論として、プログラミングの考え方は誰でも後天的に鍛えられます。
この記事をお読みいただければ、プログラミングで迷わなくなる思考法と、現場で通用する考え方の磨き方がわかります。
ぜひ参考にしてみてください！
プログラミングの考え方｜切り替えるべき思考
まずはプログラミング初心者が陥りがちな思考パターンと、その切り替え方を解説します。
プログラミングは暗記ではなく「論理構築」へ切り替えよ
プログラミングは学校の勉強みたいに構文を丸暗記しても、プログラムは書けるようになりません。
プログラミングで必要なのは「論理構築」の力でして、問題を分解して順序立てて解決する力です。
僕自身、最初は「文法を全部覚えればプログラム書けるようになるだろう」と思っていました。でも、実際にアプリを作ろうとすると、何から手をつけていいかわからなかったんですよね。
学校の勉強の成功体験が、逆にプログラミングでは足を引っ張ることがあります。
Zetto暗記から論理構築へ、頭の使い方を切り替えることが最初のステップです。
コードを書く前に「日本語」で考えよ
いきなりコードを書き始めると、だいたい詰まります。
これは僕が実務で何度も経験したことですが、優秀なエンジニアほどコードを書く前に「日本語で」考えるんですよね。
例えば、ログイン機能を作るとき、こんな感じです。
- 「ユーザーがメールアドレスとパスワードを入力する」
- 「データベースに登録されているか確認する」
- 「一致したらログイン成功」
- 「一致しなかったらエラーメッセージを表示」
このように日本語で整理してからコードに落とし込むと、迷わず書けるようになります。
Zettoプログラミング言語の前に、まず日本語で考える。これができるだけで、コードの質が劇的に変わりますよ。
全プログラム共通の「3つの処理」で思考をシンプルにする
プログラムって、実はたった3つの処理の組み合わせでできています。
- 順次処理：上から順番に実行
- 分岐処理：条件によって処理を変える(if文)
- 反復処理：同じ処理を繰り返す(for文、while文)
これだけです。複雑に見えるプログラムも、この3つの組み合わせなんですよね。
例えば、自動販売機のプログラムを考えてみましょう。
- 順次：お金を投入する → 商品を選ぶ
- 分岐：投入金額が商品価格以上なら購入可能・足りなければエラー
- 反復：在庫がある限り販売を続ける
という具合です。
Zettoプログラミングが難しく見えるのは、この3つの処理が複雑に組み合わさっているからです。逆に言えば、3つの処理さえ理解すれば、どんなプログラムも理解できるんですよね。
1言語を一点突破し、基礎の型を徹底的に固める
初心者にありがちなのが、あれこれ手を出してしまうことです。
「PythonもJavaもRubyも全部やらなきゃ」みたいな感じです。これは完全に間違いで、僕も最初はこれで失敗しました。
色々手を出してもどの言語も中途半端になって、何もできない状態になるんですよね。重要なのは、1言語を極めること。そうすれば、他の言語の習得がめちゃくちゃ早くなります。プログラミングの考え方は言語が変わってもだいたい共通だからです。
1言語を深く学ぶメリット
- プログラミングの考え方が身につく
- エラー解決力が鍛えられる
- ポートフォリオが作れる
- 転職活動で自信を持って話せる
僕の場合はJavaに絞って学習しました。その結果、実務経験1年半でJavaのフリーランスエンジニアとして案件を取ることができました。そして他のTypeScriptなどの言語の習得も割とスムーズにできるようになったんですよね。
Zetto最初の1言語でプログラミングの「型」を徹底的に固めることが、結果的に一番の近道になります。僕も最初はJava一本で勝負して、それが正解でした。
完璧主義を捨て、まず「動くコード」を優先する思考
完璧主義は、プログラミング学習の敵です。
僕もそうだったんですが、最初から完璧なコードを書こうとすると、手が止まるんですよね。
完了を優先する思考法
- まず動くコードを書く：汚くてもOK
- 動作確認する：期待通りに動くか確認
- リファクタリングする：コードを綺麗にする
- レビューを受ける：先輩にチェックしてもらう
最初から100点を目指すのではなく、60点のコードを書いて、それを80点、90点と改善していく。この思考法ができるようになってから、僕のコーディングスピードは劇的に上がりました。
Zettoまず完了させ、それから改善する。この思考法が、プログラミング上達の最短ルートです。
最速で上達するエンジニアの思考プロセス【4つの実行ステップ】
ここからは、現場で使える具体的なプログラミング思考プロセスを解説します。
【ステップ1】マクロ(全体)からミクロ(詳細)へ落とし込む設計思考
プログラミングで一番大事なのは、全体から詳細へ落とし込む思考です。
これは設計思考とも呼ばれますが、いきなり細かいコードを書くのではなく、まず全体像を把握することが重要です。
マクロからミクロへの思考プロセス
- 全体の機能を洗い出す：「ログイン機能」「投稿機能」「編集機能」
- 各機能を大まかに分解する：「データ取得」「バリデーション」「保存」
- さらに細かく分解する：「入力チェック」「DB接続」「エラーハンドリング」
- コードに落とし込む：具体的な実装
例えば、Twitterのような投稿アプリを作るとします。
- 悪い例：いきなり「投稿ボタンのデザインどうしよう」から始める。
- 良い例：「ユーザー管理」「投稿管理」「タイムライン表示」という大枠から考える。
Zettoまず全体を俯瞰して、それから詳細に落とし込む。この思考プロセスが、大切ですね。
【ステップ2】入力と出力を定義し、手順を小さなタスクへ細分化する
プログラムは「入力」と「出力」で考えると、めちゃくちゃシンプルになります。
入力と出力で考える例
- 入力：ユーザーがメールアドレスとパスワードを入力
- 処理：データベースと照合
- 出力：ログイン成功 or エラーメッセージ
このように、入力と出力を先に決めてから、中間の処理を考えるんですよね。
さらに、処理を小さなタスクに細分化します。
ログイン処理を細分化する例
- 入力値のバリデーション(空欄チェック、形式チェック)
- データベース接続
- ユーザー情報の検索
- パスワードの照合
- セッションの生成
- リダイレクト処理
こうやって細分化すると、1つ1つのタスクが明確になるので、実装しやすくなります。
Zettoプログラミングで詰まる人の多くは、タスクが大きすぎるんですよね。小さく分解すれば、どんな複雑な機能も実装できるようになります。
【ステップ3】100点より、まずは「完了」を優先せよ
前述した通り、完璧主義は捨てましょう。「まず動くものを作る」ことの重要性です。
もちろん、とりあえず完了させただけの質の低いバグだらけの成果物では意味がありません。
しかし、実務では常に納期があります。完璧を求めすぎると納期に間に合わなくなります。
だからこそ、まずは実装を完了させることが重要です。そして可能な限り実装の段階でバグを潰し、リファクタリングをして保守性を高めてからテストに移行していく。
これがプログラミングで正確性とスピードを両立させる思考法です。
【ステップ4】なぜ動いたか？を言語化し、他人に説明する訓練を繰り返す
コードが動いたら、「なぜ動いたか」を言語化することが超重要です。要するに、セルフレビューをしましょうということ。
これをやらないと、同じようなエラーが出たときに、また詰まってしまうんですよね。あと上司に不意にコードの意味を聞かれた時、すぐに答えられないと「適当に実装しているのか」と思われ、評価が下がる可能性があります。
言語化の訓練方法
- コードを1行ずつ日本語で説明する
- なぜこの書き方をしたのか理由を考える
- 別の書き方があるか考える
- 誰かに説明するつもりで声に出す
例えば、こんな感じです。
users = User.objects.filter(age__gte=20)言語化する例
- 「Userモデルから、年齢が20歳以上のユーザーを取得している」
- 「なぜfilterを使ったか?：条件に合うデータだけを取得したいから」
- 「別の書き方は?：全件取得してからPythonでフィルタリングする方法もあるが、DBで絞る方が効率的」
このように言語化すると、自分の理解度が明確になります。
もちろん最初はうまく言語化できないです。コードを読んでいくと、意味のわからない箇所が出てきてつまずきます。しかし、そこをなるべく飛ばさず1つ1つ根気よく調べていきます。
Zettoプログラミングは、説明できて初めて、本当に理解したと言えるんですよね。僕も最初は説明できませんでしたが、セルフレビュー繰り返ししていたらめちゃくちゃ説明できるようになっていきました。
現場で差がつくプログラミングの思考整理術
実務レベルになると、ロジック構築の質が問われます。
保守性を意識したコード設計と影響範囲の調査
現場のコードって、正直言うとめちゃくちゃな命名や汚いコードも多いです。
初心者がやりがちなのが、既存の悪いコードをそのまま真似してしまうことです。足並みをそろえると言う意味では、なるべく既存に合わせるのがいいですが、明らかに不適切なコードまで真似する必要はないです。
保守性を意識したコード設計
- 変数名は具体的に書く
- 1つの関数で1つの役割
- 意味のあるコメントを必要な箇所にいれる
- 現場のコーディング規約の通り実装する
また、コードを書く前に、影響範囲を考えることも重要です。
これは実務で絶対に必要なスキルで、影響範囲を考えずにコードを書くと、既存の機能を壊してしまうんですよね。
影響範囲調査のステップ
- 変更する関数がどこから呼ばれているか調べる
- その関数を使っている機能をリストアップする
- テストケースを洗い出す
・正常系：期待通りの動作
・異常系：エラーが出るケース
・境界値：最大値、最小値
Zetto現場のコードは全て正解とは限らないんですよね。常に「これが最適な書き方なのか？」と考える姿勢が、エンジニアとして成長するコツです。
誰が見てもわかる「命名」を徹底
誰が見てもわかる「命名」を徹底することが大事です。
悪い命名の例
- getData()：何のデータ?
- check()：何をチェック?
- tmp：一時的な何?
良い命名の例
- getUserProfile():ユーザープロフィールを取得
- validateEmail():メールアドレスの形式をチェック
- unverifiedUsers:未認証ユーザーのリスト
命名で意識すること
- 動詞+名詞で命名する：getUser、createOrder
- 省略しない：userではなくuserData
- 誤解されない名前にする：flagではなくisActive
Zettoコードは書く時間より読む時間の方が圧倒的に長いです。だからこそ、誰が見ても一瞬でわかる命名を心がけることが、プロの仕事なんですよね。
エラーやバグで詰まった時のデバッグ術
エラーが出たとき、感情的にならないことが一番大事です。
冷静にデバッグする方法
- エラーメッセージを最後まで読む：何が原因か書いてある
- デバッガーで変数の中身を確認する：期待通りの値が入っているか
- ログを出力する：console.log()、print()で変数を確認
- 1行ずつコメントアウトして、どこでエラーが出るか特定する
僕が実務で心がけているのは、「事実」だけを見ることです。
事実ベースで考える例
- 感情：「このコード、絶対正しいはずなのに!」
- 事実：「変数userがundefinedになっている」
- 対策：「なぜundefinedなのか調べよう」
また、バグが出たとき、「自分のコードが原因」と考えることが重要です。
バグの原因を探す優先順位
- 直近で自分が変更したコード(90%ここが原因)
- 最近マージされた他人のコード
- 外部ライブラリやフレームワークのバグ(1%未満)
Zettoエラーは敵じゃなくて、「ここが間違ってるよ」と教えてくれるメッセージです。感情を捨てて、事実だけを見る。これができると、デバッグが楽しくなりますよ。
プログラミングの考え方に関するよくある質問(FAQ)
最後に、よくある質問に答えます。
Q1:論理的思考(ロジカルシンキング)は後天的に鍛えられますか?
結論、鍛えられます。
論理的思考は才能じゃなくて、スキルです。僕も最初は論理的思考が苦手でしたが、訓練で確実に身につきました。
論理的思考を鍛える方法
- プログラミングを継続する
- 日常生活で論理的に考える癖をつける
- 本を読む
- 誰かに説明する
特に効果的なのは、「なぜ?」を5回繰り返すことです。
- なぜエラーが出た?→変数がnullだから
- なぜnullになった?→データベースから取得できなかったから
- なぜ取得できなかった?→クエリが間違っていたから
- なぜクエリが間違っていた?→条件式の書き方を間違えたから
- なぜ書き方を間違えた?→ドキュメントを読まなかったから
Zetto論理的思考は筋トレと同じです。毎日少しずつ鍛えれば、確実に身につきます。僕も3ヶ月くらいで変化を実感しました。
Q2:自力で考えるのと質問する比率は?
これは悩ましい問題ですよね。僕の経験から言うと、「15分ルール」がおすすめです。
- 15分自分で調べる：Google検索、ドキュメントを読む
- 15分で解決しなければ質問する：時間を無駄にしない
ただし、状況によって変えるのも大事です。
すぐ質問していい場合
- 本番環境に影響が出そうなとき
- 締め切りが近いとき
- セキュリティに関わるとき
じっくり自分で考えるべき場合
- 学習目的のとき
- 時間に余裕があるとき
- 同じようなエラーを何度も起こしているとき
Zetto自力で考えることは大事ですが、時間を無駄にしないことも大事です。バランスが重要ですね。
考え方の「型」を掴めばプログラミングの景色は変わる
プログラミングの考え方について、かなり踏み込んで解説しました。
重要ポイントをまとめます。
- 言語化：コードを書く前に日本語で考える
- 細分化：大きなタスクを小さく分解する
- 一点突破：1言語に絞って深く学ぶ
この3つを意識するだけで、プログラミングの考え方は劇的に変わります。
最後に、これからやるべきことを提案します。
- 優秀なエンジニアのコードを読む：GitHubでOSSを読む
- 技術ブログを読む：考え方を学ぶ
- 毎日コードを書く：継続が一番大事
- 質問する環境を作る：コミュニティやメンターを見つける
特に効果的なのは、「なぜこの書き方をしたのか」を考えながらコードを読むことです。優秀なエンジニアの思考を盗むんですよね。そして、それを自分のものにする。
僕も最初は、先輩エンジニアのコードを読んで、「なぜこう書いたんだろう」と考える時間を作っていました。そうすることで、自分のスキルが確実に向上しました。
この記事で紹介した思考法を、ぜひ実践してみてくださいね。プログラミングの景色が変わるはずです。
Miraiなるほど~！考え方の「型」があるんだね。
これを意識してコード書いてみる！
Zettoその調子！考え方が変われば、コードの質も変わるよ！