ロジックが思いつかないので、思いつく能力の養い方

Question

できるプログラマの方々はある機能を実現させるために処理の流れをすぐと言わなくとも、最終的には自力で思いつくと思ってるのですが、

自分はなかなか思いつかず、先輩に怒られます。

どういう勉強をすれば思いつくようになりますか？

Answer 1

『Aを実現したい』という感覚から脱却すればいいです。
・Aを実現するためには、BとCとDをやる必要がある。
・Bは自前で実装せねばならない。Bを実現するためにはEとFをやる必要がある。
EとFは言語で用意されている命令で実装可能である。

最終的なAを求める時、物事をブレイクダウンして考えなければ実装なんてできませんよ。

それさえ出来れば、コードが汚かろうが、実現できるでしょう。
それが出来た上で、パターンなどが活用されます。
まずはメソッドを細分化してみる、次にクラスを使いだす、更に汎化する、そういった行動は、
上記が十分にできているからこそ実装できます。

Comments

[karain]

細かく分けてから考えるということですね。なるほどです！

Answer 2

プログラミングと方向性の違う話になります。すみません。
脳の処理方法には「同時処理優位」と「継次処理優位」というのがあるらしいです。
リンク
前者は全体をイメージして細部を詰め込んでいくことが得意のようです。
後者は細部を組み立てていって全体を作るということが得意のようです。
個人差があり、両方のバランスよく出来る人も少なくないとようです。
「ある機能を実現させるために処理の流れをすぐと言わなくとも、最終的には自力で思いつく。」
というのはどちらかというと前者の考え方のように思います。

私はどちらかというと前者なので、入門段階ですが作りたい物があると、おおまかに「こういう処理があればいいなきっと用意されてるはずだ！」とか
「ああいう関数が欲しいな・・・探してなかったら自作を考えようかな」・・・でも実際は似てるけど少し違って、そこで躓いて、壁にぶつかって・・・
という感じです。

もしshutaka785719さんが後者でも悲観することはないようです。
海外のエンジニアは後者が多いのかも？
要は少ない工数で良質なコードを書ければいいので、自分に合った効率的なやり方を確立すればいいと思います。他の方も書かれているパターンに基づくやりかたは良いと思います。
明後日の方向を向いた回答で申し訳ありませんが、なにかのヒントになれば幸いです。

Answer 3

どの程度の処理の話かわかりませんが「その機能を実現するまでのステップ」をとにかく細かく細分化して考えていくと、どこが理解できていないのかがわかるかと思います。
「思いつかない」は、どこかに「理解できていない」ポイントがあるはずです。

いきなりコードを見る・書くではなくまずは、日本語で書き出して考えてみるのがおすすめです。

たとえば、
ボタン押す→処理中画面にかわる→これとこれのデータをDBからもってくる→こう集計する→画面にこのように出力する

のように細かく考えていくと、結果として「DBからもってくる」のが分からないのか、「どう集計すべきか」がわからないのか、「画面にどう出力するか」が分からないのかが見えてくるとおもいます。
さらに細分化すれば、DBへの接続方法がわからないのか、SQLをどう書いたらよいのか分からないのか、が見えてきます。

そこまで細分化できている状態で、ピンポイントで先輩に質問すれば、あまり怒られないかと。
もし、細分化ができないようなら、そもそも「実現したい機能」自体が理解できていないのかもしれません。

そういう低いレベルの話じゃなかったら無視してください。。。

Answer 4

1.なるべく単純なものに分解する
2.基本的なロジックはパターン化されているので、パターンを知識として持っておく
3.絵や物を使って現実なもので整理してみる
4.数学的な公式を知っておく（覚えている必要は無いけど、公式集などの本を一冊持っておく）
5.素人に口で説明してみる。説明していると不思議と自分の中で整理されて解決する。

思いつくまま、自分がやっている事を書いてみました。順不同です

Comments

[karain]

公式ですか？この部分がどう活用されていくのかあまりわかりませんでした。

[Guu]

数学的知識（公式など）は2つのメリットを感じます。
一つは、最適解を得るための方法のヒントが得られる場面に出くわすことがあります。
ピンチ的な時ほど先人の知恵が役に立ちます。

もうひとつは、ジャンルにより恩恵の是非は有るかとは思います。私は昔、ある研究機関でシミュレーションププログラムだの、測定機からのデータ収集プログラムだのを作っていました。
その時、忘却している数学的知識を必要とすることが多かったです。
シミュレーションでは微積、データ収集では関数、対数、畳込み演算など。

たぶん他にも色々活用は有ると思います。
もともとコンピュータはミサイルの弾道計算用に開発されたといういきさつ上、主な仕事は計算なので、数学とは無縁ではありません。

ただ知識がなくとも済む分野は存在すると思います。shutaka785719さんの分野はそういう分野なのかもしれません。

[karain]

なるほど、ありがとうございます。購入を検討してみます

Answer 5

私は今も昔もロジックを考えるのが得意ではありません。ただ、他人からそこそこ高く評価されるようにはなりました。
自分なりに出来るだけ工夫をした例を書いてみます。何かの参考になるかもしれません。

• 知識を丸暗記するより、漠然と把握したら他の事に手を付けていいです。

私は昔、上司からデザインパターンを丸暗記するように言われましたが、当時はあんまし役に立ちませんでした。それをどのように活用すればいいか解らなかったし、活用すべきタイミングがなかなか目の前に現われてくれなかったのです。なので、何となく覚えておいて問題にぶち当たった時に思い出してみようと割り切る事にしました。
私の選択に、上司は不満気でしたが、他の勉強や仕事が忙しいので無視しました。今でもその判断は正しかったと思っています。

• 情報を細分化したり分析するテクニックは自分なりに探しておいた方がよいと思います。

私は試行錯誤の結果、freemindでマインドマップ風に分解する事にしました。他人から見ると支離滅裂のようなのですが。
これも、他人の意見に影響されすぎるのは良くないです。見た目よりも自分の頭を整理出来る方が優先なので、他人の意見より自分の感覚を信じたほうがいいです。最終的にドキュメントにまとめる時には綺麗に書いたほうがいいけれど。

• 自分の道を作りましょう。

素直な方だと色んな意見に惑わされてしまう事があると思います。でも根拠に疑問があるなら、他人に従うより自分の選択を信じましょう。やってみて、問題があれば直せばいいのです。それも経験です。
危険なのは、むやみに他人の意見を聞いてしまう事です。他人は決して責任を取ってはくれません。そして貴方がかかえる問題に貴方よりも真面目に取り組む事はほとんどありません。

Answer 6

いろんな人の考え方を知ること、既存のアルゴリズムや実装方法を知ることだと思います。

これを実現する方法のひとつは、他の方の回答にもあるように、ソースコードを読むことです。
なぜこうなっているのかを自分で考えたり、書いた人に聞いたりして、実装例を知り理解することで、自分の中でカタログが作られます。
そして、それを頭の中に入れるだけでなく、実際に手を動かして練習しておくことです。
練習で書いたコードを上級者に見てもらい、意見を聞くのも良いでしょう。

実践は、大抵の場合、こういう積み重ねの応用、組み合わせです。
それ以上のものを求められるのは、さらにレベルアップしてからだと思います。

Answer 7

鍛錬の方法として昔からよく言うのは「人の書いたソースを読む」ことでしょうか。

人のソースを読むのは慣れないうちは非常に難しい場合があります。
これはその人がどういう考えに基づいて処理を書いているか察することがすぐにできないからなんですね。逆に言えば書いている人の考えを推察することができれば、次からそれを自分のものにすることもできます。

これは数をこなすこともある程度は必要ですが、
どちらかと言うと深く考察することが必要ですので、例えば同じ案件を担当している方（同僚でも先輩でも）が書かれたコードを眺めて、どうしてこういう処理にしたのかわからなければご自身から聞きにいかれるなどするというのはいかがでしょうか。もし苦労して書いた箇所なら、その方も楽しそうに話してくれると思いますよ（もちろん話しかけるタイミングは考えてくださいねｗ）

もし同僚などで、気兼ねなく話せる方がいるなら、お互いに書いたプログラムのコードレビューをしてみるのも手ですし、いっそ空いた時間にペアプロしてみるのも良いかもしれません。

Guuさんも書かれていますが、基本的にプログラミングは慣れてくると「パターン」の組み合わせであると気がつきます。問題が何か分析し終えた時点で、これはこの「パターン」で溶けるなと瞬時に頭の引き出しから取ってこれるというわけです。人のソースを読んだり話たりするのも、結局はこの「パターン」を知り、引き出しにいれる作業と言えます。

それに関連付けて言うと、ソフトウェア界隈では「デザインパターン」と読んでいますが、有名なロジックは命名され、確立されているものがたくさんありますので、それらの本やドキュメントに目を通されるのも良いと思います。
http://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2)

またサーチやソートなどの定番的な「アルゴリズム」も引き出しに入れておくと、別の箇所で応用が効いたりする場合がありますので、こちらもひと通りお勉強されると良いかと思います。

Comments

[karain]

話しかけるタイミングを間違えたから怒られているというのはあるかもですねw
デザインパターンですか、ぐぐってみます

Answer 8

もしかしたら、過去の私の質問の回答が参考になるかもしれません。
ループ処理内の分岐処理のアルゴリズムを組むのが苦手

Answer 9

あえて否定的な話ばかり書きます。
他のコメントされている方の内容を否定するものではないのですが、気分を害されたら申し訳ありません。

まず、ひたすら他人のコードを読む、これは実はあまり意味が無いです。
他人のコードを読んで「なるほど」、と思えるくらいの能力があるなら、既にある程度ロジック組み立て技術が身についています。
ロジックが悪いコードを読みまくる方が弊害が大きいですし、良いか悪いかを判断できるくらいなら最初からお悩みになっていないでしょう。

ひたすらコードを書く、これもあまり意味がないです。
一次方程式を解くのに四則演算の練習ばかりしても意味が無いです。

では何をすれば良いか、正直に申し上げて、効率的な学習方法は、人それぞれ異なります。
なので、私の書き込みを含めて、あまり参考になりません。

結局、先輩に怒られながらも、先輩にヒントをもらって、経験を地道に積んでいくしかないのです。
先輩もそうして育ってきたのですし、先輩には後輩を育てる義務があるのです。

そんな悠長な･･･と思われるかも知れませんが、1つだけポジティブな意見を書いておきます。
ロジックを組み立てる能力というのは、加速度的に上昇していきます。
まずは1年我慢して先輩に怒られ続けて下さい。
そして、1年後に1年前の自分を思い出して下さい。
その時、自分も成長したなあと感じたなら、1年後はその2倍以上成長しているはずです。

ただ、コード品質が悪いという理由で先輩が”怒る”というのは、あまり感心できる先輩ではないですね。
怒られる要因は学習すべきですが、怒られたという行為については、軽く受け流すくらいの気持ちでいるのが、今は一番の実践方法です。

Comments

[karain]

結局は経験なのですね。うーん。

Answer 10

そうですね。。。

１．目的は何か？を考える。
２．目的を果たすためにはどういう処理を作ればいいか？を大まかに区切って考える。
３．そのためにどんな材料が使えるか？を調べる。
４．材料の組み合わせだけで分割した処理を実現できなければ、使える材料の組み合わせのパターンを考えて、実現できそうな手段を想像する。
５．小さい処理を実装。
６．組み合わせて目的を果たせる所まで作りこむ。
７．全体を見なおして余分な所を削ったりコメントが必要そうなら追記したり。

という時と、

１．最終形をイメージする。
２．手持ちの材料で何ができるか考える。
３．頭のなかで処理手順を順序を追って考えながら、考えた内容を塩のままプログラムに書き出す。
４．最終形にとりあえずたどり着いたら、全体を見なおして整理。

の２パターンの組み合わせでしょうか。私の場合。
既存の便利に使える材料の組み合わせでやる時は上のパターン、手持ちの材料が乏しい上に何を求められているのかよくわからない時は下のパターンに自然となっているような。

私は、実際のプログラムは期待される出力と与えられる入力からその間で何をすればいいか？をイメージしながら考えます。

Answer 11

人のこと言えないけど、とりあえず経験値をあげることだと思います。
人のプログラムをたくさん読んでいいところはパクる、悪いところは戒めにする。
いろんなプログラムを書きまくる。そして常に良い悪いを考えていい方法を考える。ただ答えがなかなかでない。

Answer 12

問題自体を完璧に理解し、あきらめずに情報を集め、図や表を書いて具体的なイメージにし、移動時間や寝る前なども考え続けること。頭から煙が出そうなくらいに考える。そうすると、自分の中の「無意識」が勝手に考え始めます。その状態になったら、便座に腰かけたときとか、シャワーからお湯を出したときなどのように、ふとした時にアイデアが舞い降りることがあります。

人に聞くのも良いですが、難しい問題は相談相手にとっても難しいので、あくまでヒントをもらう程度の期待値で。

Answer 13

まず、コードを書きましょう。
完全なものが出来上がる必要はないです。
最終的にはDBから持って来なければならないとしても、まずはハードコーディングでもいいです
要件の1%でもまず書くことから始めます。

1%がちゃんと作れてることを確認したらどんどん機能を付け足していきます。
この時忘れずにリファクタリングしましょう。

要は一度に考えなければならないこと、作らなければならないものを出来るだけ小さくします。

最初のうちは時間がかかるかもしれませんが、だんだん一度に大きなものが作れるようになって来ます。

テスト駆動開発の考え方に近いので、気になったなら調べてみるといいと思います。

ちなみに書き始めるときは、作ろうとしている機能の一番外側(UIとか)から作り始めると余計な実装をしなくて済みます。

Answer 14

プログラムに限った話ではありませんが、何かを実現したいと考える時に一番大事なのは「終わり(完成形)から考える」ということです。
いきなり細かい部分から考えては完成まで途方も無いステップを踏まなければならず、普通の人なら途中で投げ出してしまうでしょう。

Aを実現するためにはBとCを組み合わせる必要がある
→Bを実現するためにはDとEとF、Cを実現するためにはGとHを組み合わせる必要がある
→Dを実現するためにはIとJを・・・(以下略)
、というようにトップダウン型で考えるのが基本です。
そうするとどこかの段階で、既にプログラム言語そのものや、動作環境のAPIの組み合わせで実現できるレベルまで細分化されます。

そして各部品が正常に機能していれば内部を知る必要もない(使い方だけ分かれば良い)わけですから、このような手順を踏んで設計すれば複数人で開発することも容易になります。

元々関数型言語やオブジェクト指向型言語もこのような思想に基いているはずです。
「完成形から考える」「階層を分ける」という2点を意識してみてください。