【解決法】プログラミングのロジックが思いつかないときは？

単純化するとロジックは目的を実現するための選択と処理を正しい順番で考えれば出来上がります。

この記事ではエンジニアとして実際に様々なロジックを実装してきた私が初心者向けにロジックの組み方を丁寧に説明しています。

プログラミングのロジックが思いつかないということは、自分の頭でいろいろな処理や機能を組み合わせて使うことが出来ていない可能性も考えられます。

日本語に例えると言葉や表現法を知らないから、自分の想いがうまく伝えられない状態と同じです。

想いをうまく伝えたいなら、まずは相手やその場の状況を正しく把握して、適切な言葉で表現しないといけません。

プログラミングでは何のために何をすべきかという目的を正しく分析して、そのために使える基礎文法やアルゴリズム、類似処理を探して必要な処理を実装していけば、それがあなたのロジックになります。

ロジックはプログラムというツールを使ったパズルのようなものなので、最初はどうやったら目的が実現できるかアナログ的に考えると組みやすくなります。

ロジックを組むことはプログラミングのだいごみですから、いろいろなアルゴリズムを組み合わせて最適なロジックを組むことを楽しめるようになるといいです。

オリジナルのロジックで処理すると処理速度が遅くて大量のデータをさばくのに時間がかかりすぎるという問題が起こることがあります。

そんなときに役立つのがアルゴリズムです。高速処理できるアルゴリズムを取り入れてプログラムを最適化していってください。

知らないことはできないので普段からいろいろなロジックを学んで、実際に作ることで経験を積みスキルアップしておくことも大切です。

そのためにはアルゴリズムの本を学んでおくといいです。

アルゴリズムの本以外の言語学習などでは読むだけだと記憶に定着しずらいのでハンズオンや演習問題がついている本がおすすめです。

なぜかというと、人は試行錯誤でしか成長しないからです。

仮説検証してPDCAを回し続けることが有効な学習であり、自分を成長させるアクションだと理解して実践を続けるといいです。

オンラインで実践的に学ぶなら次のサービスが人気です。一部無料で使えるので気軽に試せます。
⇒ paizaラーニング

paiza は転職サービスもやっていてテストの点を評価対象とすることができるので、実績のない未経験者にはスキルをアピールしやすいサービスになっています。
⇒ 経験談：paiza 経由のスカウトで成功した中卒30歳実務未経験駆け出しがエンジニア

正解（本質的にやるべきこと）

ロジックは自分が成長して考えられるようになるか、あるいは適切なロジックを調べる力をつけることで組めるようにすべきものです。

これが本質なので、基本的には自己解決能力を高めることを目指して下さい。

とはいえ、すぐにそんな力がつく訳でもないので、調べたりいろいろなロジックに触れる経験を増やして対処すればいいです。

この記事ではそのポイントを説明しているので参考にしてください。

フルコミットで脳力覚醒

私たちの脳には脳科学でRAS（Reticular Activating System）と呼ばれる脳幹網様体賦活系（のうかんもうようたいふかつけい）という機能があります。

RASは自分の興味関心があるものを無意識的に脳がフィルタリングして教えてくれる機能です。

いいアイディアを出すのに役立ちます。

考えないといけないロジックに関することを考え続けると、脳はそれが大事なものだと判断して関連する情報を自動で選んで教えてくれるようになります。

残念ですが、無意識的な活動なので意識して自由に活性化させることは難しいです。

それでも瞑想や仮眠、睡眠などで活性化しやすくなります。またカフェインや適度な運動でも活性化しやすくなることが分かっています。

まだ検証できていませんが、実際にRASの活性化を狙うなら10分の休憩中にコーヒーやお茶を飲んでから瞑想してチャレンジしてみるのがいいのではないでしょうか。

小さなロジックではなく、もっと大きな設計や人生の悩みなどは朝起きたときなどにRASが活性化して思いつきやすいです。

ですから、悩みがあるときは夜寝前にある程度まで考えたら、眠ってしまって翌朝思いつくことに期待したほうがいい解決法が見つかりやすいです。

RASは役立ちますが、注意すべき点もあります。いくらRASが活性化しても必ずしも正解がえられる訳ではない点です。

自分の脳力や知識・経験を超えた天才的な発想が毎回出てくるのとは違うので、正しさや有効性は自分で冷静に判断してください。

逆に自分の脳力や知識が高まればRASの精度も上がっていきます。これには期待できるので自己成長を目指していきましょう。

問題点の切り分け

プログラミングの本質的な対処法としては、具体的にどこに問題があって、その原因や状況がどこにあり、どう対処すべきか分析すべきです。

これがプログラマーやエンジニア的な思考の基本です。これがうまく出来るようになればプログラマーやエンジニアの仲間入りできたと考えていいでしょう。

そもそもロジックを考えるときにまったく何も思いつかないということは少ないでしょう。

ある程度はではロジックが組めるがどこかにうまくいかない部分があるという状況になることが多いはずです。

仮にコードが100行あるとすれば、何行目まで期待通りの動きをしていて、何行目からおかしくなっているか特定します。

50行目から予想外の動きをしているとすれば、問題は50行目かここに関連する部分にあると予想できます。

これで正常な部分と異常な部分を区別することができました。これが問題の切り分けです。

近頃の言語やIDEはステップ実行といって１行ずつ処理を実行することができるものも増えているので、ステップ実行ができるときはこれを使って１行ずつ変数の内容などを確認してください。

ステップ実行ができないときは変数の内容を画面やファイルなどに出力すれば確認できます。

どこに問題があるか分からないときは二分検索法を使うと便利です。

参考 二分検索法 

これは100行のコードなら半分の51行目以降をコメントアウトして実行して試し、問題なければ残りの半分となる76行目以降をコメントアウトして実行していくようなやり方です。

これで何行目から何行目の間に問題があるはずだと予想することができるようになります。

問題点を切り分けることができたら、あとはどう対処すべきか考えればいいだけです。

問題の解決には問題解決法というスキームが役立ちます。単純化すると問題を網羅的に細分化し、優先順位をつけて効率的に対処していくやり方です。

あらゆる問題は基本的にこのスキームで対処できます。

参考 問題解決法とは 

ちなみに、まったく何も思いつかない人は、たぶん初心者なのだろうと思いますが、基礎力に不安があるので言語/フレームワーク/アルゴリズムなどの入門書を読むなどして先に基礎知識を増やすことをおすすめします。

ロジックにチャンレジするにはまだ少し早いというだけのことなので気にせず入門書を読み進めてください。

読み終わるころには前よりも多くの対処法が考えられるようになっているはずです。

課題の切り分け　必要な処理の細分化

問題点の切り分けに似ていますが、こちらは何をどう実装すべきかという課題を細分化して把握することです。

より細かく切り分けていくことで効率的な実装方法や問題点も分析することができます。

ロジックを考えるときは最初にやっておきたいのがこの課題の切り分けです。

目的の処理を実装するために必要なことをなるべく細かく列挙すればそれが詳細設計になります。

発散と収束　俯瞰と仰視

これが具体的に対処するときの基本的な考え方です。ロジック作成やプログラミング、開発全般で使えます。

試行錯誤のやり方を具体化したものでPDCAサイクルに近い形になっています。

元々の言葉の意味は、発散は外へ広がっていくこと、収束はあることに近付いて特定されていくことです。

俯瞰は下を見渡すことで、仰視は上を見上げることです。

これらを繰り返すことで意識の方向を変えてより客観的に物事が分析できるようになります。

人間関係で使うなら自分のほかに相手や第三者（複数人の意見や世論）、メタ次元の先生や賢者など（理想論や本質論）の立場を想定して、彼らならどう感じどう考えるかという視点を先に持っておくといいです。

[注意] 作れない/期限に間に合わない場合

仕事で「これはムリだ」、「間に合いそうにない」と分かったらすぐにリーダーやクライアントなどに相談しましょう。

頼む側からすると、初めから言ってほしいところですが、やったみないと分からないこともあるので仕方ありません。

実際に出来なかったり、間に合わなかったりすると大問題になります。それよりも先にダメだと言ってもらったほうが頼んだ人も助かります。

黙っていて最後に「出来ませんでした」と言われるのが一番ダメなパターンです。信用も失います。

これは仕事の一般ルールなので他の作業や体調不良で働けないときも同じです。

無理な状態になったしまった後ではどうしようもないので、そのことを説明して相談するのが大人の対処法です。

とりあえず AI に聞く

言葉を知らないとうまく情報を引き出せない Google 検索と違い、ChatGPT などの対話型AIはあいまいな表現でもその意味を理解して答えてくれます。

回答の精度が低く、間違ったことを堂々と答えてくることもあるので注意は必要ですが、何か知らないことをおおまかに理解するには便利です。

答えではなく考え方や参考意見を聞くイメージで使えば十分役立ちます。

さらにプログラムのコードまで教えてくれるのでエンジニアにとっては特に便利なものです。

対話型AIは基本的には文章を解釈して文章を返すプログラムなので、文章作りが得意です。

タイトル案やメール案も作れ、英語記事の要約を日本語で返すこともできるので、日常的な文章作成からプログラミング、技術情報のチェックまで幅広く活用できます。

Bing は AI のサポート機能を組み込んだ検索エンジン。これなら検索＋AIサポートの両方が使えて便利です。

今のところ対応ブラウザが Edge だけです。他のブラウザで「新しい Bing を試す」を選択するとWindowsでは Edge が起動するようになっているのでそのまま使えます。

情報と合わせてソースを教えてくれるので Perplexity に近いイメージです。

	回答精度	回答速度	文章量	コード生成	ソースURL	対応ブラウザ	登録/ログイン	補足
ChatGPT	そこそこ	たまに止まる が早め	長め	できる	なし	モダンブラウザ	必要
Perplexity	高め	ものによる が早め	簡潔	できる	あり	モダンブラウザ	不要	動作がやや不安定、リロードで対策
Gemini(旧Google Bard)	そこそこ	少し遅い	簡潔	できる	なし	モダンブラウザ	必要	賢く進化中
Bing	選択式	回答精度を 上げると遅い	簡潔	できる	あり	Edgeのみ	不要	無料GPT4で賢くなった

今回紹介した中だと Perplexity が精度が高く頭一つ抜け出たイメージです。これをメインで使うのがおすすめです。

ちなみに ChatGPT は課金すると賢くなるのですが、今回は無料版で評価しています。

Gemini も高性能化しつつあるのですが、他もよくなっていくでしょうから、最新情報をチェックしていったほうがいいです。

Bing AI（チャット）も内部で ChatGPT を使っていますが精度が「創造的に/バランスよく/厳密に」の3つから選べるようになっているので Bing のほうがよりよい回答をえやすくなっています。

他の AI の精度が低いとも言いきれませんが、間違うときは間違うのでいくつかの AI を併用したり、ソースを確認するといいでしょう。

ChatGPT は創作能力が高いので文章作成のサポートに向いています。AIにも得意、不得意があるので目的に応じて使い分けるといいです。

AI 活用のポイントはずばり質問の仕方にあります。2000文字などの長文で質問できるので、目的だけでなく、条件をたくさん追加することができます。

どの質問にどう答える仕様なのか理解を深めていくとよりよい答えを得られるようになります。

その他にはグチを言ったり、悩み相談などをして精神を安定させるために使うこともできます。

悩みや不満は文章化してアウトプットするだけでも客観視できるようになり和らぐので効果があります。

わからないことは全部 AI に聞く

わからないことがある状態でプログラミングを続けると危ないので簡単に説明できるくらいまでは理解しておいたほうがいいです。

検索してもいいですが、AIのほうが要点をまとめてくれるので速いです。

ですから、今後のAI時代は、まずAIに聞いてから、次に検索するという流れがスタンダードになっていくはずです。

時代を先どって先にAIに聞く習慣をつけるといいです。ソースURLを表示してくれる Perplexity なら検索する手間も減らせます。

自分で検索するのはソースURLを確認して納得できなかったときでいいでしょう。

AI が嘘をつく件

AIはハルシネーション(Hallucination)といって間違ったことを答えることがあります。

ネットのビッグデータを解析して学習しているので、元のデータに間違い多い場合などに判断を誤ってしまうのでしょう。

平然と嘘をつき訂正もしません。自分がよく知らない分野で質問するときは特に気を付ける必要があります。

正確なところは自分で調べて判断すべきです。今のところはそういうものだと心得ておくべきです。

対話型AIの使い方

単語や文章で質問します。英語で答えてきたときは「日本語で。」などと追加すると日本語にできます。

質問はプロンプトといって条件を大量に指定することができます。

目的の答えがえられるまで条件を追加・調整して論理的に回答を導いたほうがよりよい回答がえられます。

AI は何でも答えてくれるので、色々な方向から条件を増やして質問してみると意外な発想を知ることができます。

条件は何十個でも付けられるので大量に付けても大丈夫です。

GitHub Copilot に頼る

GitHub Copilot はかなり優秀なプログラミングのサポートAIです。必要なコードを予想して提案してくれます。

初学者より数段上の実力があり高速でタイプミスもしないので、未経験エンジニアの需要を脅かす存在になるとささやかれています。

もちろん間違うときは間違うのでチャットAIと同じく疑ってかかる必要はあります。

使う場合は、今のところ2ヵ月の無料期間があり、その後の利用料金は月10ドル、年100ドルかかります。

主要言語にはおおむね対応しているものの未対応の言語もあるので注意してください。

間違っていてもいいのでコーディングを始める

手を動かすと頭も動くので取り組みやすくなります。

写経する場合も同じですが、実際にコードを書いて動かしてみることで理解が深まり、記憶にも強く残るようになります。

たとえ間違っていても自分の書いたコードを自分の目で見ることや実行してみることで課題が見つかりやすくなるメリットもあります。

この項目から先はロジックをどのようにコーディングに生かすか試行錯誤しながら読み進めてみてくだい。

頭だけで考えるよりも頭が働いて目的に近付きやすくなります。

やるべきこととやったことをまとめる

作業や調査したことを整理しておくと論理的に分析できるようになります。

とくにうまくいかずに頭が混乱しているときは、紙などに書いてアウトプットしてみると現状や問題点が分かりやすくなります。

どこまで理解できて、何ができていないのか論理的に分析できれば、次に何を調べるべきか見当がつくはずです。

うまくいかないときは、問題の切り分けをするために30～60分に一度くらいはタスクを整理すべきです。

ロジックや目的を深掘り

ロジックを組めないということは、何か知らないことや理解していないことがあるはずです。

頼む人が間違えていて絶対に出来ない要求をしていることもあるので、それも含めて考え直すといいです。

分からなくても分からないなりに考えてひとつひとつを深掘りして分析していけば、どういう状態からどんな結果にすればいいのか具体的に考えられるようになります。

ロジックで何を実現すべきか考え直す

まずは単純化して５秒で説明できるくらいおおまかに考えます。そこに必要な条件を追加していきます。

紙に書いたり、言語化することで客観的に分析できるようになるのでおすすめです。

やるべきことが整理できたころには、分からないことや出来ないことなどの問題点も明らかになっているはずです。

次はそれらを解決するために調べたり、人に聞いたりするという解決行動を取ればいいだけです。

データの流れを追う

プログラムを単純化するとデータ処理と画面表示が主な処理と言えます。

入力データやDBのデータを選別して必要なものをDBやファイルに書き込んだり、画面に表示するのが目的です。

ですから、プログラムを理解したいならデータの流れを追うことが大切です。

ゴールからの逆算思考

ロジックを組んだ結果、どうなればいいのか先に考えて、その結果になるロジックを考えます。

逆転の発想を持つことで違うやり方を思いつきやすくなります。

言語化して詳細設計

自分でロジックを考えて実装するにはプログラミングの詳細設計を自分でする必要があります。

詳細設計では必要な処理を全てを言語化して説明できるようにしておくべきです。

言葉にできないと調べることも説明することもできないので言語化は大切なことです。よくわからないことを知るには ChatGPT などの AI が便利です。あいまいな質問でも答えを返してくれます。

現状や目的などからやるべきことの本質を理解して、必要な手順を考えて言語化していけば詳細設計が出来上がります。

ソースコードにやるべき処理を上から順番にコメントに書いてリストアップしていくと実装漏れも防げて便利です。

機能の実装では基本的にはいろいろなパターンを把握しておいて、組み合わせて使うことになります。

知識を増やすだけでなく、仮説検証を繰り返すイメージトレーニングや演習問題などで考える力も高めておくといいです。

コピペプログラマーを卒業する

とりあえずプログラムが動けば問題なさそうですが、処理の意味を理解できていないと応用が利きません。不具合が出たときや機能を改修するときに困ります。

速攻で動くものが作れるコピペスキルも便利ではあるものの、プログラミングスキルが上がりにくいという弱点があります。

コピペでもコードの全処理をエンジニアに言葉で説明できるレベルまで理解しておくといいです。これなら記憶にも残りやすくなりスキルアップできます。

言葉でうまく説明できない部分は自分の理解が浅いところです。スキルアップのチャンスなのでちゃんと調べて理解しておきましょう。

ロジックが思いつかない、分からない、組めないというのは基本的には知識や経験不足が原因なので普段からスキルアップにも力を入れておくといいです。

誰かのコードを参考にする

よほど特殊な処理でないかぎりは、すでに誰かが似たコードを書いている可能性が高いので、参考にしたほうが効率がいいです。

ある程度大きなプロジェクトなら似た処理をしているコードを探すと効率がいいです。すでにレビュー済のはずですから安心です。

AI は ChatGPT や Copilot のことです。素早く提案してくれるのがいいところですが、肝心な処理が抜けていたりもするので注意が必要です。

ネット検索や GitHub での検索は少しスキルが要りますが、うまくヒットすればいいコードが見つかる可能性があります。

他人のコードでも何も考えずにコピペするのではなく、コードの内容を理解して学んでいけロジックを考える参考になり、自分もスキルアップできます。

それぞれのコードが何のために何をしているのか言葉で説明できるレベルまで理解することを目指すといいです。

検索では逆引きや他の言語の似た処理も使えることがあります。困ったときはチェックしてみましょう。

スキルアップ目的ならコピペより写経

コピペだと記憶に残らないので、手打ちでコードを打ち込んだほうが記憶に定着しやすいです。

写経ならアウトプットになるのでコピペよりはスキルアップが期待できます。

人は失敗からしか学ばないと言われますが、失敗したほうが記憶に残り学習効果が高くなります。

初心者のうちは保管機能も使わずにコーディングするくらいがおすすめです。

詳細設計をしよう

課題の切り分けの項目でも説明していますが、要はなるべく細かく言語化してから実装すれば、何をすべきか、また問題点も分かってきます。

それを実装する前にするのが詳細設計です。

詳細設計が出来たら確認(レビュー)してもらおう

その詳細設計に不安があるときは、リーダー・先輩・同僚・先生などに確認してから実装に入ったほうが安全です。

1分くらいで説明できるように準備をしておいて「1分だけ相談させてください」と頼めば大抵の人は応じてくれるはずです。(3～5分でもいけるはず、休憩時間などを狙うと成功率が上がる)

人は誰かを助けてあげたいという潜在的な願望を持っていて断ることには少し抵抗を感じます。そもそも頼まれると断りにくいものです。

また人を頼った方がその人とも仲良くなりやすいの人間関係もよくなり一石二鳥です。

ロジックが何も思いつかないときは不十分な設計になるでしょうが、何もわからないと言うよりはマシです。

少しはやる気があることが伝われば相手が適切な設計をおしえてくれるかもしれません。

厳しい人だと「アルゴリズムを調べてからまた聞きに来い」と言われるかもしれませんが、そのときはどんなことを調べればいいのか教えてもらっておきましょう。

調べて設計を直してまた確認してもらえば設計が出来上がっていきます。なんだかんだと言われてもアドバイスしてくれるはずです。

詳細設計できない原因は主に知識不足

日本の詰め込み型、暗記教育が悪いのですが日本人はオリジナルなことを考える力が弱いです。

どうすべきかというと、アイディアの多くは他から流用してきたものの組み合わせで出来ているので使えそうなアイディアを探した方が早いです。

自分で考え出せるのは自分の知ってる範囲に限られるので初学者がいきなりすごいロジックを組むことはまずできません。

素直に良いアイディアをマネしましょう。プログラミングのアルゴリズム辞典やテクニック/ロジック集などを探せば使えそうなアディアが見つかるはずです。

そうしているうちにスキルがついてきたらオリジナルのもっと良いロジックを組んでいきましょう。

実際の仕事ではエンジニアは研究者ではないのでオリジナルのロジックを作ることは少ないです。

ロジック部分は設計にあたるので SE など上流工程を担当する人が行うからです。

例外としてゲーム系はオリジナリティも求められるので独自ロジックを組みたい人はゲーム系を目指すといいでしょう。

それ以外のスクールなどで勉強してきただけの人はゲーム系はさけたほうが無難です。

ゲーム系はゲーム系の専門学校で２年とかみっちり学んでも就職率が低い難関ですのでスキルに自信のない人にはそもそも向いていません。

ゲーム系は設計と実装をプログラマに全振りしてしまうようなところがあるのでスキルがあれば面白い仕事になります。

ですが、設計通りに作ることしかしたくない人には厳しい仕事になるでしょう。

似た処理のコードを調べる

研究職やゲームだとこの世にないオリジナルのロジックを組んだりしますが、ビジネスで使う処理で誰も組んだことのない完全にオリジナルなロジックを組むことはまずないです。

過去に似た処理をどこかの誰かが考えているはずです。同じプロジェクト内に似た処理があればそれを参考にすればいいです。

コーディングの質を安定させられるのでプロジェクト内のロジックを参考にすることは別に悪いことではありません。(※参考したロジックやコードの質が低くなければ)

ネットで探すなら英語で検索したほうが多くのサンプルが見つかるのでおすすめです。自動翻訳の精度も上がっているので DeepL などで翻訳すれば理解できるはずです。

誰も説明してないようなことを知らなくてもエンジニアにとっては別に恥ではないので、気にせず検索して参考にしていいです。

分からない部分をはっきりさせるのがポイント

詳細設計ができたら自分が知っている技術で実現できる処理なのか確認します。

よく分からない部分は、調べてやればできそうなレベルまで調べておくべきです。

どうしてもやり方が分からないことは、考え方が根本的に間違っていたり、全然知らない技術が必要かもしれません。

よく分からないことはやはり ChatGPT などの AI を使うと分かりやいので、調査対象を一段広げて調べ直したほうがいいです。

学習中でロジックが思いつかないときは、悩んでいてもどうせ思いつかないことが多いので15分くらいで切り上げて先生なりメンターさんなりに答えを聞くか、保留して次のことを学んだほうがいいです。

思いつかないのは時間の問題ではなく知識・経験の問題なので悩むことに長い時間をかけるのは効率が悪いです。

初学者とは立場が変わって就職後に仕事で全然できそうにない、あるいは技術的にできないことが分かったら依頼主に相談してその理由を説明しましょう。

できないことをできないと言うこともエンジニアの仕事です。

自分が悪いとは限りませんし、何も言わないでいると出来るはずのことが出来ないと判断され自分の評価を無駄に落とす恐れがあります。

できないことはできないとちゃんと伝えないといけまえせん。

できないこと実装をは中止したり、他のエンジニアに頼んだりとして対応しないといけないので、ならなるべく早く伝えるべきです。

頼む側としては期限ギリギリになって「やっぱりムリでした」と言われても困るので、「できるか分からない」、「自信がない」といった不安要素はなるべく早く伝えておくべきです。

コミュニケーション力を高め誤解を防ぐ

まずは相手を不快にさせないくらいのコミュニケーション力をスキルとして学んで、誠意をもって的確に受け答えできるようにしておけば十分です。

相手によっては傲慢だったり、敵対的でやりにくい人もいますが、それは相手の問題なのでとりあえずスルーしておくのがおすすめです。

自分はあくまで誠意をもって、社会人として相手を尊重しつつ、相手や周りの人たちから非難されないように振舞っておくのが無難です。

さて、肝心のロジックですが、自分も依頼主も実装法を誤解していることがあります。

よく分からないところや違和感のあるところは確認すべきです。

依頼主も確認や質問はちゃんとして欲しいと思っています。後から気付いたことでもいいのでしっかり確認していってください。

頼んだ人にとっても想定外の問題が出ることもあるので、そのときはまた確認してください。

ロジックを考える例

通勤をロジック化してみた

現実の通勤をロジック化してみると、何かを実行することと、そのために選択することが主な処理であることが分かります。

プログラミングのロジックは条件分岐と実行が主な内容なので主にこの二つを考えればいいことが分かります。

要は選択と実行の方法、その順番を考えるのがロジックだということです。必要な処理と順番を考えればロジックが出来上がります。

ECサイトにおすすめ商品のブロックを追加する例

こんな仕事があったときにロジックを考えてみます。ここで大切なのは詳細設計に必要なおすすめ商品の定義を決めることです。

おすすめと言われても何がおすすめなのかはクライアント次第なので、こういう要望はクライアントに確認してちゃんと要件定義しないといけません。

このあたりは実装するエンジニアが直接やることもあれば、SE や設計、交渉担当者がやることもあります。

この例では「売り上げ10位あたり」という要件を「6～1位」と定義して確認しています。

商品によっては新商品を優先したり、過去に1位になったものを毎回含めてほしいなど、いろいろな要望が出てくる可能性があります。

実際のECサイトならデザインの確認も必要になります。普通は商品名、値段、画像、キャッチコピーなど何をどこに何文字表示するかなども確認します。

詳細設計の細かい部分はクライアントやそれにあたる上司などに確認しないと分からないので設計が出来た段階で確認すべきです。

せっかく作った後に違うと言われても困るので確認は大切です。

何といってもクライアントの要望を実現するのがエンジニアの仕事ですから、自分勝手な実装をしていけません。

とはいえ、確認することで、手間のかかる面倒な処理を別の実装しやすい処理に変えてもらう交渉もできます。

データベースのテーブルやカラムを増やしてフラグでもつけないと実装できないような要望が来てしまうこともあるでしょう。

そんなときは、今のシステムでは無理だと素直に伝えて代替案を提案することもできます。

この例の要件を実装するために必要な時間がとれるなら、商品情報テーブルにおすすめフラグを追加し、クライアントが自分で設定できるようにしてあげれば使いやすくクライアントの満足度も高くなるでしょう。

後から「10位前後だと毎回だいたい同じ商品がでてくるからランダムの意味がない」とか言われて作り直すリスクもさけられます。

このようにロジックを考える必要があるときは詳細が未定で確認する必要が出てくる可能性があることを覚えておきましょう。

おすすめ３つの例の詳細設計

実際に実装前に考える処理をもう少し詳しく説明します。データ抽出はデータベースの処理で出来るので SQL で実装すればいいでしょう。

ソートや範囲を指定した乱数取得処理はどのデータベース(SQL)でも実装されているはずなので使えるはずです。

「おすすめを３つ表示して」と頼むのは簡単ですが、内部処理は思いのほか手間がかかります。

とはいえ、こういうロジックがサクッと組めるかどうかがエンジニアスキルの評価アップにつながるので向上心を持って取り組みましょう。

14件以下の場合を考える

どのカテゴリの商品も15個以上あるとは限らないので０～14個だったときのことも考えて処理しないといけません。

商品のレコードが14個以下の場合は、上限と下限を減らすのが自然でしょう。14件なら6～15を5～14に変えるとなります。

3件以下の場合を考える

おすすめに表示したいのは３つなので最低３つは商品データがないといけません。3件のときは全部表示され、2件以下のときは足りないという問題が起こります。

0件のときは多分非表示でしょうが、そのブロックに何も表示しない他に「おすすめがない」と表示することもできます。

これらら自分で勝手に決めて実装しないで上司やクライアントに確認してから実装しましょう。

ランダム抽出

レコードが0から15件以上までの処理をして抽出したレコードから3件取得すればいいでしょう。

多分問題ないでしょうが、万が一同じレコードが抽出される可能性があるときは、ぶらないように対処する必要があります。

かぶるかどうかは SQL の仕様を調べるか、レコード３件などの小さなテーブルを作って何回か SQL を発行してテストしてみれば分るでしょう。

SQL の乱数生成処理は重い（比較的時間のかかる）処理なのでレコードが数万件もある場合は何秒もかかってしまいボトルネックになりかねません。

SQL は対象レコードが1万件を超えると重くなる傾向があるのでレコード数を考慮して実装しましょう。

例えば10万件のレコードからランダム抽出する必要があるときは上司やクライアントに相談してデータベースの特性上処理が重くなりすぎるので違う方法に変えてほしいなどと相談すべきです。

対象レコードが取得済みの場合

別の部分で上位20位までの商品を表示しているような場合は、そこで取得したデータからランダム抽出することもできます。

SQL を発行する回数が減るのでこちらのほうがデータベースへの負荷が減りアクセスピーク時などの表示速度やシステムの安定性が少し上がります。

そのかわりに乱数生成処理やかぶらないように比較する処理は自分で実装しないといけません。

乱数を生成し、他の数値とかぶっていないか確認し、かぶっていたらやり直すという処理を3回ループさせればいいでしょう。

フィボナッチ数列のロジックを自作する例

フィボナッチ数列は、前の二つの項目を足した値が次の値になり、これが延々と続く数列です。

初期値は0と1でその後は、1, 2, 3, 5, 8, 13, 21, 34, 55… と続いていきます。

一般的には再起関数で簡単に表すことができる例になっていて、コードは次のようになります。

// JavaScriptでフィボナッチ数列を処理する関数
const fibo =  function( n ){
    return n < 2 ? n : fibo(n-1) + fibo(n-2);
}
for( let i = 0; i < 11; i += 1 ){
    console.log( i + ' : ' + fibo( i ));
}

ロジックを考える例として、これをフィボナッチ数列の定義通りに、再起関数を使わずにコーディングしてみます。

改めて要件として考えると、初期値は 0 と 1、前の二つの値を足したものが次の値になる、というものなので、これを満たすロジックを作成します。

// 再起関数を使わずにフィボナッチ関数を作ろう！
const fibo =  function( n ){
    let ary = [ 0, 1 ]; // 初期値は固定なので初期化時に設定
    if( n === 0 || n === 1 ) { // 0 と 1 のときは処理不要
        return ary[ n ];
    }
    let res = 0;
    for( let i = 0; i < n - 1; i++ ){
        ary[ i + 2 ] = ary[ i ] + ary[ i + 1 ]; // 前の二つの値を足して次に代入
        res = ary[ i + 2 ];
    }
    return res;
}
for( let i = 0; i < 11; i += 1 ){
    console.log( i + ' : ' + fibo( i ));
}

再起関数よりもコードは長くなりましたが、呼び出されるたびにコールスタックでメモリを使いつづける再起関数よりもメモリ効率がよいメリットがあります。

今回は文章をそのままロジックに落としたので、初期値の 0 と 1 を定義しています。

最適化するなら、引数で何番目かという数字を受け取るので、1以下のときはこれをそのまま返すだけで同じ処理が実現できます。

// 最初の5行の最適化
const fibo =  function( n ){
    if( n < 2 ) { // 2 未満 なら引数 n そのまま返せばよい
        return n;
    }
    let ary = [ 0, 1 ]; // これは計算に使うので、今回のコードでは省略できない

最初の再起関数のコードの n < 2 ? の部分が if( n < 2 ) という意味なので、JavaScriptや類似言語を知っている人は、最初からおかしいと気が付いたかもしれません。

気付いた人は勘がいいです。これからも勘を磨いていってください。

ちなみに、フィボナッチ数列の隣り合う値は黄金比の1.61…に収束し、植物パターンに現れ、経済成長モデルなどに利用されています。

ロジックを自分で考えていい場合

ロジックは自分で考えて実装するよう指示されたときは、いろいろやり方はあるけど好きに実装していいと考えていいです。

頼まれたときにいまくイメージできなかったり、よくわからないときは、その場ですぐに確認したほうが無難です。

それも含めて自分で考えてくれと言われるかもしれませんが、そのときロジックの詳細設計が言語化できた段階で簡単に確認したほうがいいです。

自分の考えをまとめるとともに相手に安心感を与えることができます。

相手によっては、自由に作っていいと言う割には細かい指示を出したがることもあります。

逆にそれが面倒で時間がかかるときは、自分で決めて先に実装してしまうなど、相手に合わせて工夫すればいいでしょう。

考え方の基本

エンジニア的には問題の切り分けが基本ですが、一般的な考え方の基本も役立つのでうまく活用していきましょう。

何でも考える習慣をつけておく

ロジックが思いつかないのは暗記教育などの影響で自分で考えることに慣れていないことが原因のひとつになっています。

考える力は考えるという経験を積むことでついていきます。

考える経験を積むには何についてでもとりあえずそれがいいかどうかなどと考える習慣を身に着けておくといいです。

プログラミング以外のことでもそれが何のか頭の中で定義して、正しいかどうか、もっといい考えはないか、そもそもどうあるべきかなどと考える習慣をつけておくとより論理的に思考できるようになっていきます。

思いつく力＝発想力を高める

ここでは考える抽象度を一段上げて発想力を高める方法を説明します。まず発想力は訓練で高めることができます。

一般的な発想力アップ法を応用してロジック発想力を高めておけば、いざロジックを考えないといけないときに役立ちます。

世紀の大発明となって普及したスマホもアイディアとしてみれば携帯電話にタッチパネルつけただけのものでした。

当時からどちらの技術もそれほど目新しいもではありませんでした。

ですが、それらを組み合わせて、さらに音楽も聴けるオシャレなデバイスとして大成功を収めたのがiPhoneです。

このようにアイディアとはすでにある考えの組み合わせで出来ています。考え方をたくさん知っておくことが発想力の土台になるので先に多く知っておくことが大切です。

アイディアを組み合わせて効率化や最適化する思考実験を続けていけば発想力が高まり、アイディア自体もよりよいものに変えていくことが出来ます。

いい組み合わせを見つけられれば、プログラミング界の大発明となる画期的なアイディアを生み出すことも出来るかもしれません。

ロジカルシンキング（論理的思考法）

簡単いう言うと、法則に従って矛盾なく正しく判断考えることがロジカルシンキングです。

対義語は感覚や直感的な思考です。根拠はよく分からないけど感覚的に決めてしまうことです。

プログラミングの世界は因果関係がはっきりした論理的な世界なのでロジカルシンキングが有効です。

エンジニアを目指すならだいたい出来ているはずですが、さらに意識的に理解しておくことで能力を高めることができます。

ロジカルシンキングの基本は体系的に理解し判断することです。そのためには関係性やカテゴライズ、グルーピング、多角的な視点などが重要です。

論理的思考法で特に大切なのがMECE（ミーシー）です。これは課題や問題をモレ・カブリなく分析するやり方です。

プログラミングのロジックでも必要なことをモレ・カブリなく分析できれば後はプロセスを実装していくだけです。

論理的思考が苦手な場合

論理的思考法は性格や人間性とは関係ない思考技術にすぎないので学んで習慣化すれば身に着きます。続けていけばスキルアップもできます。

普段は自分の感覚やインスピレーションを大事にしてもいいです。

ですが、プログラミングの世界は因果関係がはっきりしたロジカルな世界なので頭を切り替えてロジカルに対処すべきです。

仮説検証でPDCAを回す

論理的思考法も同じですが目的は仮説検証してPDCAサイクルを回し改善していくことです。

網羅的に分析して問題を切り分け、疑問を深掘りし、仮説を立て試していくのが一連の流れです。

仮説検証ができないと何も変わらないので、あくまで仮説検証と改善が目的だと理解しておいてください。

ソフトウェアのデザインパターンを学ぶ

この記事のテーマであるロジックは比較的小さなプログラミングを想定しているのでデザインパターンとは関連が弱いです。

ですが、サービスやシステム全体といったもっと大きな設計を考えるときに役立つのがソフトウェアのデザインパターンです。

デザインパターンを学べばこれまで研究されてきた設計や実装方針を学ぶことができます。

とはいえ、ロジックが思いつかないときに、すぐに役立つようなものではありません。

ですが、あなたが設計など一段高いレベルからプログラミング実装を見渡す立場になれば役に立てられるようになるはずです。

デザインパターンは直接使うというより、いろいろ実装していくなかで効率化を図るときに活用できる基本的な考え方です。

あなたの行動は間違っていた

結果論で考えると、うまくいってないとすればどこかに足りないことがあるはずです。

ですから、今までやってきた方法にはどこかに間違いや改善できる余地があると言えます。

時間をかけて頑張っているのにうまくいかないときはもっといいやり方がないか考えるべきです。

それまでさけてきた面倒なことのなかに突破口になることがあります。やったことがないことがあるなら試してみるのがおすすめです。

また、とことんまでやりきっていなかったことをやりきってみることも突破口になることがあります。

厳密には結果が出たり、成果が実感できるようになるまでにかかる時間や労力は取り組むことによって違うので注意してください。

たとえば英会話を身に着けるには3000時間かかると言われているので、英単語を100個や200個覚えたくらいでは全然足りません。

だからといって成果が出ていないと思う必要はありません。まだ十分な努力をしていないだけなので成果が出なくても当然だからです。

プログラミングのロジックを考える場合は、問題を細分化していけば対処する範囲を小さくできるので比較的短い時間で結果が確認できるはずです。

対処する範囲が広いと対処しにくいので問題を切り分けて結果が判断しやすい状態にしてから対処していくといいです。

不安な人へ

自分には向ていないし才能もないと思う

やりたくない気持ちを優先してしまうと何もできません。

そもそもロジックが思いつかない程度のことは向き不向きや才能が影響するようなハイレベルな次元の話ではないです。

関連する対処法を知ってるか知らないかという知識レベルの問題であることが多いはずです。

才能のある人や勘のいい人もいますが、まだそのレベルの話ではないのでスキルアップして対処していくべきです。

たいていの人は努力次第で一流になれるので、その先のトップの超一流になれるかどうかといった状態にならないと才能はあまり関係ありません。

自分に向いていないとか才能がないという考え方は、何かをあきらめる言い訳にされがちなので、いい訳になっていないかよく考えてください。

ロジックやエンジニア関連でうまくいかない原因の多くは、問題分析や現状認識が間違っているか、調べないといけないことをうまく調べられていないことにあります。

ちゃんとやるべきことをやったのか思い返してみて下さい。

エンジニアならある程度まで課題解決能力を高めればたいていのことは何とかできるようになります。

またスキルアップしていけば、仕事はどんどん楽になっていくので努力を続けてみてください。

人よりも実装や学習に時間がかかる

同じ実力の人が同じことをやれば同じくらい時間がかかるものです。

つまり、かかる時間の長さは実力に見合ったものであって、多少の差があってもとくに長いとか短いということは少ないです。

早くできる人はそれだけ経験を積んで知識や対処法を学び勘を磨いてきたので早くできるようになっただけです。

自分も努力してそのレベルまで実力を高めれば同じように早くできるようになるはずです。

時間的に早くできるかどうかは、個人の才能や人格よりも積み上げてきた経験的な実力による影響のほうが大きいです。

実力は高めることができるので、自分が望む実力がつくように計画的に努力していくといいです。

やる気が出ない

仕事でロジックを考えないといけないとすれば、仕事なのでやる気があろうがなかろうがやらなければいけません。

仕事のやるやらないをやる気を基準にして考えてはいけません。やりたくなくてもやるのが仕事です。

趣味のプログラミングならロジックが考えつかなくても、責任を取らされるような問題は起きないので一旦保留して後で考えるのでもいいです。

趣味ならやりやすいことから取り組めばいいでしょう。

エンジニアへの就職/転職を目指している人にとっては、未来の仕事になる訳ですから、仕事と同じようにやる気がなくても取り組めるようにしておいたほうがいいです。

とはいえ、その時点でのスキルや時間、体力、健康状況によって限界はあるので、一旦保留してもいいので学習を続けていくことが大切です。

問題を切り分け、仮説検証して学びを得ていければスキルアップできるので、いつか目的を達成することができるはずです。

自分にも出来ると信じてがんばってください。

よくある疑問

ロジックとアルゴリズムの違いは？

プログラミングの世界では、アルゴリズムは特定の問題に対する共通の解決手順のことを表します。

ロジックはアルゴリズムなどを使って具体的に問題を解決するために作る理論や手順のことです。

例えば、数字を昇順で並べかえるなら、使うアルゴリズムがソートアルゴリズムで、数値を変数に入れてソートし結果を出力するまでがロジックになります。

実際には多くのシステムではデータベースを使うので SQL でソート指定してデータベース内でソートしますが、自作で数値をソートするときは上記の例のようになります。

プログラミング用語のロジックとは？

プログラミングの世界でのロジックという言葉は、処理の内容・手順・実現方法などのことを表します。

特定の目的のために組まれた一連のまとまった処理を行う理論がロジックです。

一般社会では、単に理論や道筋、ルールなどのことを表します。
それに比べるとプログラミングの世界のほうがより具体性のある理論を表す言葉として使われています。

筋道の通った考え方を何と言う？

論理的思考（ロジカルシンキング）と言います。

より正しいルールに従って、より矛盾や飛躍が少ない妥当な筋道を客観的かつ論理的に考えることです。

問題の本質を理解したり、原因を切り分けるときなどに役立つエンジニア必須の思考法です。

エンジニアの仕事は常に論理的で、より効率的かつ妥当な判断の元に行っていくべきです。

まとめ

現状分析、言語化、レビュー(確認/相談)が大切です。

最悪、よく分からない部分が多くても、口頭でもいいのでレビューしてもらえれば、答えやヒントを教えてもらえるチャンスがあります。

人は自分を頼ってきた相手を冷たくあしらうことに抵抗を感じるのでレビューを頼めばきっといい結果になりやすいです。

相手も人間なのでお礼と賞賛(?)や敬意を表すことも忘れないようにしましょう。

職場で有能なエンジニアを見つけたら、レビューだけでなく自分に必要な学習法や業界の未来予想なども教えてもらえるかもしれないので仲良くなっておくといいです。

もうひとつ大切なのがセンスや勘です。センスや勘は生まれつきのものだと誤解されがちですが、実は成長の過程で身に着く経験的な精神活動です。

ロジックを組む経験、アルゴリズムの知識などを増やしていくことでエンジニアとしてのセンスも高まっていくので意識的に高めていきましょう。

実際に学ぶとなるとエンジニアの学習は何をどこまで学ぶべきかという判断が難しいです。

自分のキャリアプランを考え、どんな選択肢があるのかリストアップして優先順位をつけ実践していけば自分が望んだキャリアに近付いていけます。

自分の根本的な価値感や優先順位を考慮して実践していけば、よりよい人生に近付けていくこともできるでしょう。

ゲームプログラマーの体験談

私は元々ゲームプログラマーをしていたので、自分でロジックを考えるのは当たり前のことでした。

むしろ、実現できるかよくわからないプランナーやクライアントの要望をロジックを駆使して実現するのがゲームプログラマーの仕事でした。

ですから、駆け出しエンジニアのみなさんのなかにロジックが考えられないという悩みがあることは意外なことでした。

ロジックを考えなくてもエンジニアが務まるものなのかと疑問に思いました。

調べてみるとWebエンジニアなどは実装する処理はあまりオリジナリティのあるあるものではなく、だいたい決まったパターンがあり、それらを実装できるようにするのが主な仕事だと分かりました。

一般的なエンジニアはよくわからない要望を実現する機会は少なく、ゲームプログラマーのほうが例外なのだと分かりました。

ゲーム制作がオリジナリティが高い処理ばかり実装している訳でもないですが、私の場合はビジネス系に転向してからは、よくわからないものを作る力が生かされました。

まったく知りもしなかったソケット通信処理や、果てはDHCPパケットまでRFCの仕様を確認しながら自作するようになりました。（※追伸：これはさすがに断ってもよかった）

ビジネス系のエンジニアはよくわからない処理を作ることをかなり恐れていて、なかなか引き受けないという事情もあって私のところにはそんな仕事がやってくることがあったのです。

Webエンジニアなどで独自のロジックを作ることができると、私のようにビジネスチャンスが広がるので、ぜひこの機会にスキルアップしておくことをおすすめします。

それなりに苦労はしますが、エンジニアとしての自分の市場価値が高められます。

ちなみにロジックを組むのが苦手な人はゲーム系エンジニアを目指す場合は、独自のロジックがあまり必要とされない通信とかサーバー管理とかを目指した方が無難です。

[コラム] AIプログラミングの未来予想

AI は優秀ですが、意思を持たないのと融通が利かないことから、あくまで人が利用するツールという位置にあります。

GitHub Copilot でコーディングして、気になるところは 対話型AI で確認するというのが近い将来起こりそうなエンジニアリングの未来です。

AI などに頼らなくても自力で出来たほうがよさそうに思う人もいるかもしれません。

ですが、誰もが AI を使うようになってしまえば、使うことが常識となります。

自力コーディングは、移動で歩くことにこだわって自動車や電車を意地でも使わないような時代遅れの人になっていくかもしれません。

そのときは、いかにうまく AI に命令を出して最適な答えを早くださせるかというスキルが求められる時代になるでしょう。

ですから、少しさみしい気持ちもありますが、AI を早く使いこなせるようにしておくのもエンジニアの生存戦略としては賢い選択しと言えるでしょう。

さらにその先の未来には人がコーディングするとミスするリスクがあるからなるべく AI にさせる時代がくるのではないでしょうか？

そうなるとエンジニアの仕事はコーディングではなく設計や設定などに比重が置かれるようになるはずです。インフラ系の仕事も自動化されるようになるはずです。

AI が高性能化した未来ではエンジニアの役割は多少変わってきますが、専門職なので基本的には需要がなくなることはないので心配はいらないでしょう。

AI が進化してもエンジニアの仕事はなくならない

エンジニアは AI を使う側の立場なので AI が進化しても便利になるだけで、仕事がなくなるようなことはまず考えられません。

AI は論理的なことは得意ですが、それ以外のことや人間の矛盾した願望を叶えるには役不足だからです。

しいて言うなら、AI が使えずに時代に取り残されたエンジニアは消えていく恐れがあります。

AI の流れには早く乗っておいたほうがいいです。どう考えても AI が普及してメインストリームになる時代がやってきます。

この流れはもう止められないので変化に対応していくしかありません。

今さらネットやスマホのない生活に戻れないのと同じようなものです。

AI に命令される仕事

詳しくは「AI に仕事が奪われる職種」などで検索してください。

電話の自動応答システムのように自動化する仕組みさえ出来れば AI/ネット/機械でかなりの仕事が代用できるようになるとみられています。

人間でないとできない細かい作業などでも AI が管理者の役割を代行して人間に最適な指示を出すようになるでしょう。

スポーツではサッカーなどのチームスポーツで監督が AI 化されて選手に無線で指示を出すような日が来るかもしれません。

私の予想では今出ている AI 化されない仕事の予想はそれほど当たらないように思います。

営業やコンサル、教師、カウンセラーなどは AI 化できないと予想されていますが、AI と自動音声などにしたほうが優秀なものになる可能性が考えられます。

AI と争う者は破れ活用する者が勝者となる

AI は道具にすぎないので人が戦うべき相手ではありません。それ以前に AI の得意分野で人間が同じことをやって勝つの難しいです。

人が自動車より足が遅くても当たり前ですし、人が計算機よりも計算が遅く不正確でも別に恥ではありません。

同じように AI は便利に活用すべきツールだと考えるべきです。勝てればすごいですが、そもそも争う意味はないでしょう。

どこまで学べばいいかわからない未経験者の方へ

現役エンジニアでも目的がはっきりしていないと、どこまで学ぶべきか迷いが出てきます。

プログラミング未経験者ならなおさらでしょう。

そんなときは信頼できるメンターに相談できるといいのですが、知識・経験の乏しい未経験者がメンターの質を判断するのは難しいです。

いいメンターが見つかればいいですが、メンターを信用できないと学習効率が悪いです。

そこで知識・経験が平均的に蓄えられていて、さらに Youtube などで良心的で面白いイベントを行っているスクールも、意外とおすすめです。
⇒

私もWeb面談で相手の顔を見る機会が増えていますが、見た目や話し方からどんな人かある程度わかってしまいます。

誠実そうな人、体育会系の人、ガラの悪い人など、少し見ただけで予想できます。

RUNTECHはまずまず良心的なイメージなので、スクールの良しあしを判断する自信のない人なら、無料面談くらいは受けてみてもいいかと思います。

注意すべきは、スクールなどの学習サービスは、ビジネスなのでどうしても自社に有利なビジネストークも入ってくるので、そのあたりはうまく差し引いて考えることです。

私が35歳以下で本気でエンジニア転職を目指していたとしたら、RUNTECHあたりを選ぶだろうと思います。

それでも心配な人は、やはり自分の目で確かめるのがいいでしょう。

無料面談をやっているところが多いので、少し勇気を出して申し込んでしまえば、話を聞くのは簡単です。

逆にほぼリスクのない未経験者向けの無料面談を受ける勇気さえない人だと、行動力がなさすぎます。

独学・自走が基本となるエンジニアになるのは少し厳しいかもしれません。(多少のアドバイスは受けられますが)

何をやるにしても、やり始めないことには始まらないので、アクションファーストでPDCAを回して改善していかないと何もできません。