プログラミングが速い人って日常的に何をされているんでしょうか？

Question

お世話になっております。

具体的なプログラミングの質問ではないのですが、昨日「こういう出力を期待しているけどこういう出力になる」と質問をしたら数分で自前のロジックを組んで的確に回答される方がいらっしゃることに驚きました。この質問でいうと、一時間くらい考えて「forループ中にそのループする配列をループ内でpopしたらダメなんじゃないか」という仮説にたどり着いたのですが、原因を探す遅さを嘆いています。

私自身文系出身で作業効率化のためにゆるゆるとPythonを書いていて、最近ロジックを組むのが面白くなりつつあるのですが、なぜそんなに速いんだろう？とふと疑問に思いました。ちなみに基本情報の資格を持っていないくらいのペーペーです。

そこで思ったのですが、teratailで知識ではなくロジック関連の質問で即答されるような方は普段はどういうことをされているんでしょうか？

もちろんいろんな要素が絡み合っている問題であり、かつ、短絡的だとは思うのですが、理由を何個か考えてみました。

①身もふたもないですが単純にプログラミング適性があって頭がいい
②競技プログラミングにどっぷりはまっている
③フローチャートを毎回簡単にでも書いている
④「いかにして問題をとくか」や「プログラマの数学」のような書籍を愛読している
⑤codeIQやpaizaのようなプログラミングの問題をたくさん解いている
⑥デバッグのやり方が確立しているのでPDCAを回すのが速い
⑦アルゴリズムを熟知している
⑧常に抽象的にモデリングすることを考えている

プログラミングを組むのが速くなったと思ったことのある方、速いと言われる方、日常的に何をされていましたか？

以上よろしくお願いいたします。

Answer 1

こんにちは。

小さなプログラム作成の速さであれば、解いた問題の数のように感じます。考えて解くにはそれなりに時間がかかりますが、覚えているプログラムが多ければ、それをベースに作れるので短時間で作れます。
もちろん、頭の回転がむちゃくちゃ速い人はいますので、そのような人は地頭で勝負できるのかも知れません。（頭の回転の早い人、うらやまです。）

しかし、現実の場面のプログラムは小さなプログラムの集まりではありません。ご存知かもしれませんが、開発工数は規模の指数関数で増えていきます。
（指数関数は要するにねずみ算です。最初はゆっくりですが、ある点を超えると急激に増えます。）

そして、ビジネスの場面においては、大きなプログラムの開発力がものを言います。
これには⑥～⑧が大きく効くのではないかと思います。

⑥デバッグのやり方が確立しているのでPDCAを回すのが速い

モグラ叩きデバッグ（闇雲に修正してみる）より、シーケンシャルなデバッグ（思いついた順で１つ１つ潰していく）の方が速いですし、シーケンシャルなデバッグより、２分探索なデバッグ（「全体を２つに分けてどちらにバグがあるか判断→残りを２つに分けて判断」を繰り返す）の方が速いです。
これらのテクニックを適切に使いこなせる人はデバッグを効率的に行えます。

⑦アルゴリズムを熟知している

多くのアルゴリズムが引き出しに入っていると、全体設計の際により適切なアルゴリズムを選択できます。
性能を取るべき場面、開発工数を取るべき場面、信頼性を取るべき場面などなど、状況に応じて選択するアルゴリズムも変わってくると思います。

ついでに、どんなライブラリが存在するのかの知識も有用と思います。

⑧常に抽象的にモデリングすることを考えている

全体をモデル化して見渡して設計すれば全体設計が外れにくいですね。
全体設計を外すと、手戻りが激しいので開発期間が大きく増大してしまいます。

---

経験的には、大きなプログラム開発についてはタイピング速度や小プログラム開発の速度より、上記スキルのほうが効果的なように感じます。

Comments

[mofu_mofu]

思わぬ回答だったり第一位の方から回答をいただけました。みなさま非常に貴重なご意見をありがとうございました

「プログラミングが速い人は何をしているのか」という質問に対して以下のような回答をいただきました。

- そもそもプログラミングを楽しいと思えること
- 過去の経験を無駄にせずにトライアンドエラーを繰り返す。
- 調べてなんとか動く、ではなくきちんと理解して次はパッと書けるようにする
- 条件が許せば、すぐに人に聞くのではなく自分で悩みに悩んで自力で解決する
- 二分探索のデバッグできると速い
- 問題を分割して順序だてて組み立てることに慣れている
- 自分に合った練習
- 他の人でもメンテナンスしやすいという観点からコード書く。そのために良いコードをよく読む
- 常日頃からコードを書くと経験や知識がついてデバッグが速くなる　＝　コードを書くのが速くなる
- 適正の問題は最低限はあるがそれ以上に引き出しの多さ、自分で考えたり他人のコードを読んだりする努力
- teratailに入り浸る
- 経験と定石などの知識　＋　teratailなどのサイトに自分の考えやコードを公開して添削or他の方の意見を真似する
- 期待した入力と出力を満たすには典型例を知っているとか一次ドキュメントを熟読するとか
- 要件を満たせる設計するにはアルゴリズムとデータ構造を知ること

コードをたくさん読んでたくさん書いて練習して失敗したことを次に生かす。考え抜いてみる。
意見やコードを他人に見てもらう。teratailなどに入り浸る。
というような意見をいただきました。個人的にはteratailに回答者としても入り浸るのというコメントはなるほどなあと思いました。

BAに関しましては甲乙を付ける質問ではないとは思いますが、開発工数の法則に則って解説していただいたChironianさんの回答がとてもわかりやすかったのでBAとさせていただきます。ありがとうございました。

Answer 2

あるレベルまでは適性の問題(出来ない人は幾ら考えても出来ない)だと思いますが、それ以上は、引き出しをたくさん持っている（過去にたくさんプログラムを考えるあるいは読むをして、それを記憶して、さらに思い出す力が強い）ということではないでしょうか。自分で考えるだけでなく読むのも良いです。
経験を積むのは努力でカバーできますが、それを素早く思い出せないなら元も子もない。

Answer 3

トラブル対応から得られる学習効果という観点から一言・・・

昨日「こういう出力を期待しているけどこういう出力になる」と質問をしたら数分で自前のロジックを組んで的確に回答される方がいらっしゃることに驚きました。

数分で答が得られてしまうと学習効果が少ないということがあるかもしれんせんね。

自分で徹底的に調べまくって、1 ～ 2 日ハマって、自己解決したといういうケースと比べると、学習効果には大きな差があるのではないでしょうか。

前者の場合はすぐ忘れてしまうかもしれませんが、後者の場合は痛い目にあって努力した分覚えている期間が長い（引き出しか多くなる)と自分は思います。

上のループの中でのコレクションの操作をして失敗したというのは自分も痛い目にあったことがあります。調べまくって悩みまくったことをよく覚えています。

最近はネット上に情報があふれていますので、調べて解決のために必要な情報を得るのも容易になっていて、自己解決できるケースは多いのではないでしょうか。

ググって調べるにもスキル（キーワードの選択、英語のサイトも含める、正しい情報を見つける等々）が必要ですが、自分で調べて解決するという努力をするとそのスキルも上がってくるはずです。そのスキルの向上も重要だと思います。

業務上での問題など時間的・工数的に無理ということでなければ、できるだけ自分で調べて解決するという方向で考えてはいかがでしょう。

Answer 4

プログラミングのスピードって言葉の定義にもよりますけど、

「こういう出力を期待しているけどこういう出力になる」と質問をしたら数分で自前のロジック

てことを言っているのであれば、回数の問題です。これは「作業」です。
典型的な input と output の間を埋める方法を知っているか、知らないかだけの話なので、典型例を知ることがスピードにつながります。
一次ドキュメントをよく読む。っていうのも含んでいい気もします。
こちらは、熟練者になれば、思考の速度で書き上げることができる人もいるらしいですｗ

で、プログラミングのスピードっていうのが、要件を満たすプログラムを作る。ってことなのであれば、これは「要件の整理」と「設計」が素早くできるかどうかってことです。

設計ができれば、プログラムを要素単位に分解して、知識の範囲内で組み立てるっていう前述の「作業」に落とし込むことが出来ます。拘束される時間は、こちらの方が長いので、スピードアップをはかるのであれば、こちらを鍛える必要があります。

「要件の整理」と「設計」をする事は、「データの持ち方（構造）」と「ロジック」を学ぶことで、スピードアップを実現することが可能です。
これも典型例をどの程度知っているか？ってことに左右されるので、訓練することで早くなります。

小さなプログラムでも、「要件」が何であるか？どのような「データの持ち方」をしそれを「どのようなロジック」で処理するか。を意識するようになると、スピードはかなりあげることができると思います。

Answer 5

経験と知識にもとづく引き出しの数だと思いますね。私の場合は、質問者さんと同じように些細なことでつまづいて小一時間なやんだこと何度もあります。それから、私の場合は、書籍などを通じて定石を身につけるようにしています。

それをもとに回答してみています。こういうサイトは点数が入るなどの競技性があるので、それを目当てに回答することもありますが、そのほかのメリットとしては次の３つがあります。

1. 間違っていたらツッコミが即座に入るので、自分の知識を修正する。
2. あっていれば自信につながる。
3. 他の回答者さんのいいところは盗んで真似をする。

実は、回答するにあたって一番難しいのは、質問者さんが知りたい、やりたいことを読み解くことだったりします。それもまた経験ですね。

Answer 6

過去の経験を無駄にしない人か、超天才かのどちかではないでしょうか。
大半の人はおそらく前者でしょう。
誰でも初めて作るような処理・アルゴリズムは時間がかかるし、トライアンドエラーの繰り返しです。

Answer 7

「経験がものを言う」のではないでしょうか。
たくさんプログラムを作って、たくさんトラブルに遭遇して、それらの問題を解決して、そうしていくうちに「こういうときにはこうすれば良い」という直観的な判断が身に付いていきます。数をこなせばそのバリエーションも増えていきますし、そのバリエーションが新たなアイディアの源となります。

①身もふたもないですが単純にプログラミング適性があって頭がいい

頭が良いかどうかは別として、「プログラミングが楽しい」と思えることが最大の適正ですね。そして、そう思えるようになるかどうかが大きな分かれ目となります。問題（バグ）の解決すら楽しいと思えるようなら最高ですね。方法論は後から付いてきます。継続は力なり。そのための原動力です。
まぁ、実務におけるプログラミングでは、納期やコストの兼ね合いから楽しんでばかりはいられないのですけどね。

Answer 8

常日頃からプログラムを書いているからその分色々な場面でのデバッグに強い。
成功法だけを知ってる人より失敗法を知ってる人の方が強い。
何故ならばプログラムはプログラムを書いてる時間より書いたプログラムのバグを潰しながら作業することが多いからです。

Answer 9

・デバッグの経験はあったほうがいいですね。不要なソースをみつけたりとか、いろんな視点が持てます。
仕様がおりて、実際に組む前に聞けることも多いと思います。

・他人のソースを見て、やっていることの解釈ができるようにする
teratailの様な所でも十分にその環境は備わっています。

・『調べてとりあえず実装できた』だけにせず、調べた事を自分の中に落とし込めるまで理解して、次に自分でパッと書けるようにしておく

3番目がいちばん重要な気がします。
あとは、それをパッと引き出せるか…。

Answer 10

足の速い選手は日頃何をされているんでしょうか？
練習だと思います。

才能と練習法を同列に並べていらっしゃいますが、一定レベルを越えるには複数の要素が必要でしょう。

自分の才能と目指すレベルによってすることは違うと思いますが、自分に合った練習は不可欠だと思います。

Answer 11

⑨teratailで他の回答者としのぎを削っている

これも選択肢に入ると思います。自分はかなり遅い方ですが(^ ^;

さらにどうでもいいことですが私は⑤に当てはまります。

Answer 12

日常的にここに入り浸って自分の好きなように解答を書いてみる、人の解答で良いところを見つけたら調べる、読む書く読む書く。そうする事で定石や良く引っかかる箇所が経験として身に付いてだんだん速くなってくる。

Answer 13

日頃から同様なバグに出会ってデバッグしているせいではないでしょうか…

---

結局動くコードを書いてしまうと成長を遅く感じます。
エラーにぶつかって悩みぬくことで理解が深まっていく気がします。

困っていない、満ち足りていることは敵です。
ですので、このようなトラブルがたくさん挙げられているサイトをのぞいて勉強します。

一人で引き起こせるバグの量には限界がありますので、他人の力を借ります。

---

例えば、
あるプログラミング言語に慣れてくると、これはこう書く、と「わかる」ようになります。
それではエラーは起きないし、もっと良い方法を探るためのエネルギーも生じにくいです。
そこで、このようなサイトでは、それは絶対にそのように書かない、と思っていた書き方をして困っている人を見つけるわけです。
なんでこの人はこう書こうとしたのかな、メリットはなにか、デメリットはなにか、とああでもないこうでもないことを考えるのです。
すると、横からこう書けばよいと、見たこともない書き方で問題を解決する回答が投稿されるのです。
それをふむふむと読んで、自分ならこう書くなあ、こう書けばこういうメリットがあるのではないかとなんとか差別化して別解を投稿します。
その結果慣れない書き方でバグを仕込み、ご指摘を受けることになるのです。
この過程でいろいろと考えることで学習します。

これを機に暇があったら回答してみてはいかがでしょう。
しばらくやってみると、パターンが見えてくるのかもしれません。
一番多いのはインストールできませんのたぐいですが…

Answer 14

問題を分割して順序だてて組み立てることに慣れているからじゃないですかね。
ピタゴラスイッチ的なあれです。

Answer 15

速く書くより、自分だけではなく他のメンバーにもメンテナンスし易い、出来ればメンテナンス・フリーを目指す。その為には良質なコードをよく読む。今はインタネットでいろいろ探せる便利な世の中。コードをいっぱい書く。