読者です 読者をやめる 読者になる 読者になる

文系プログラマによるTIPSブログ

文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。

伸びないプログラマに見られる4つの傾向

仕事

新卒の方や派遣の方達のコードを沢山見てきて、思った事があります。
それは、

伸びない・スキルアップしない人は大体同じ過ちを犯している

ことです。

私も未熟なので本記事では棚上げしますが、具体例と共に解決策を考えていきましょう。

※ 本トピックは自分の事を棚に上げた、炎上必至のトピックです。何を偉そうな事言ってんだ!と思った方はそっ閉じでお願いします。

1、思考がボトムアップになっている

具体例

まずは具体的な例を挙げましょう。

(新 ´Д`)「ここで落ちるんです〜、教えて下さい〜」
(私 ´_ゝ`)「落ちるって?今日の運勢が落ちちゃった?」
(新; ´Д`)「 いえ、NullPointerExceptionが起きるんです」
(私 ´_ゝ`)「へーそう」
>(新 ´Д`)「この変数に値が入らなくて・・・」
(私 ´_ゝ`)「このメソッドのif文絶対に通らないけど」
>(新 ´Д`)「え!?マジスカ直します!あざす!」

・・・1時間後・・・

>(新 ´Д`)「やっぱりダメです〜」
(私 ´_ゝ`)「そもそも何をしようとしてるの?」
>(新 ´Д`)「この画面のここにこの値を表示したいんです」
(私 ´_ゝ`)「ああ、それだとそもそもやり方間違えてるからこれだとダメだよ」
>(新; ´Д`)「ウッ・・・」
(私 ´_ゝ`)「まずこーして、あーして・・・」


はい。本当によくあるダメな例です。

このやりとりでは具体的なソースコードの話から始まり、最後にそもそもやりたい事を話していますね。これは最悪な例です。大体このパターンで話してくる場合、根っこの部分、つまり一番最初の切り口の時点で間違っている事がほとんどです。

話す順序が逆なのです

いきなりソースの話を始め、最後にようやくそもそもやりたい事を話すという、ボトムアップ思考になってしまっているのです。
ボトムアップ思考は最後にようやく本題に入り誤りに気づくのに対し、
トップダウン思考は誤った時点で気づくという違いがあります。

No. ボトムアップな思考 トップダウンな思考
1 ヌルポが起きるよ。 こういう事がしたいです。
2 ソースのこの部分がおかしい。 こうやってみました。
3 直してみたけどやっぱりおかしい。 こういうエラーが起きました。
4 そもそもやり方が完全に間違っているのでNo1〜3は無駄な事が解った。 どう直せばいいですか?

例えば↑この場合、ボトムアップ思考ではNo4にいくまで誤りに気づけません
一方トップダウン思考の場合はNo2の時点で誤りに気づけます

当たり前な事に見えますが、新卒の方や要領の悪い人は本当にボトムアップ思考が多く、余計な事を沢山話してしまう事が多く、余計に時間を費やしている場合が多いです。もしトップダウン思考なら、2〜3分で誤りに気づけたのに、ボトムアップ思考が故、1時間試してみダメで聞きに来て、よくよく聞いてみるとそもそもやり方がおかしく、費やした1時間は無駄に終わるというケースは本当に多い。

対応策

こうなってしまうのは、コーディングが好きなので、どうしても先に具体的なコードの話をしたがり、ボトムアップ思考に陥ってしまうのではないか、と私は考えています。

対応策は、横着しないで、何がしたくて、どうやったら、何が起きたか、を順序立てて話す事が最短ルートに繋がると思います。話の最後に本題をようやく話しだすような事が無いように心がけます。

2,寄り道が好きですぐ本題から外れる

具体例

まずは具体例を挙げます。

(私 ´_ゝ`)「次ここ実装して貰うから、このソース軽く読んでおいてね」
>(新 ´Д`)「はい!!さて、では早速コード追っていきます!」
(私 ´_ゝ`)「ガンバレ」
>(新 ´Д`)「ん?このメソッド何だ???」
>(新 ´Д`)「潜ってみよう。お、更に別のメソッド呼んでるなあ。」
>(新 ´Д`)「おー、ここに行き着くのか!全然意味解らないけど!!」
>(新 ´Д`)「んー!?これ何してるのか解らないなぁ。」

・・・1時間後・・・

>(新; ´Д`)「スミマセン、ここ何をしてるか教えて下さい。」
(私 ´_ゝ`)「お?今そこ全然関係無いでしょ?」
(私 ´_ゝ`)「っていうかソースコード1行しか読めてないじゃん。」
>(新; ´Д`)「スミマセン、このメソッド見たらハマっちゃって・・・」
(私 ´_ゝ`)「今そこを読まなくていいよ。コメントに書いた通りの結果が返ると考えて、先進んで」
>(新; ´Д`)「ハイ・・・」

・・・1時間後・・・

>(新; ´Д`)「スミマセン、ここ何をしてるか教えて下さい。」
(私; ´_ゝ`)「だから潜らなくていいってば・・・結局2行しか読めてないんかい」
>(新; ´Д`)「ウッ・・・」


これもよく見るケースです。

潜らなくていいメソッドを潜り、結局そのメソッドが何をしてるかを調べだし、本題から外れるケースです。ボトムアップ思考と似通っていますね。

ボトムアップ思考 トップダウン思考
1行目にあるメソッドを潜る。 対象のクラスをざっと見る。メソッドを潜らない。
その先にあるメソッドを潜る。 全部見終わって、何をしているかの概要が把握できた。
更にその先にあるメソッドを潜る。 気になるメソッドを個別に少し潜る。
よく解らない・・・ なんか複雑な事してるメソッドだ。これは調べないで後で聞こう。
ここで時間切れ。結局1行目しか読めなかった・・ ここで時間切れ。全部読めた。細かい部分は都度読み込もう。

はい。ボトムアップ思考ではすぐにボトムに潜ってしまい、トップの部分は1行しか読めませんでしたとさ。一方トップダウン思考では、トップ部分は把握し、ボトムに行くにつれ不明部分が出てくる。が、読み込むのに時間かかりそうだから、自分で調べずに聞いた方が速いと判断し、読み込むのは今は諦めましたとさ。

本題のソースコードから外れてしまい、結局概要が掴めずに時間切れという最悪のケースですね。
まずはトップのソースをしっかり読み込み概要を掴む。概要が把握できたら個別にメソッドを潜って見る。こうする事で少なくとも「概要は掴めた」という成果が残ります。ついでに個別のメソッドも少し読み込む事ができ、深追いしない事でサクサク概要が把握できました。

対応策

  • 本題のソースのみを見て概要を把握する。
  • 読み終わったら個別メソッドを追って詳細を少しづつ理解する。
  • 追うのに時間がかかりそうな部分は潔く諦め、後で聞く。

3,コピペマニア

コピペが大好きな人は相当高い確率で品質の低いコードを書いている気がします。

具体例1

では早速具体例を見て行きましょう。

(私 ´_ゝ`)「この画面実装してね。あの画面と似てるから、あのソースを参考にね。」
>(新 ´Д`)「はい!!」

・・・ now coding・・・

>(新 ´Д`)「お、ここってあの画面と同じじゃね?ソースコピーっと。」
>(新 ´Д`)「よく見たら大分部同じじゃん。全部コピってから部分的に修正しよっと。」

・・・ now coding・・・

>(新 ´Д`)「できました!!(ドヤァ」
(私 ´_ゝ`)「(ん?何かあの画面とコード全く同じじゃね?嫌な予感・・)」
(私 ´_ゝ`)「あー、あの参考の画面でバグが起票されてるけど、そっちは大丈夫なん?」
>(新;´Д`)「エッ・・・」
>(新;´Д`)「多分バグってます・・・」
(私;´_ゝ`)「つまり既存バグをこっちの画面にも輸入した訳ね」
>(新;´Д`)「スミマセン・・・」
(私 ´_ゝ`)「そもそもこの処理理解してコピってる?」
>(新;´Д`)「いえ、合ってそうだからコピーしました!」
(私;´_ゝ`)「アッハイ・・・」


これもよくあるケースです。
意味を理解せずコピペし、既存バグを他の画面に撒き散らすというテロ行為です。

ここで困るのは、既存のソースをコピった方が品質が保たれるし、コードの書き方も合わせられるし、速く実装できるじゃないですか!!と言う場合です。まあ言っている事は合ってるんですが、それでは既存バグを撒き散らす可能性があるし、何よりソースを把握しないで先へ進んでしまうから、いつまで経っても理解が進まない、という弊害があります。

具体例2

他にも、たった2文字のコマンドですらコピペしようとするコピペが大好きな人がいます。

(私 ´_ゝ`)「このサーバにsshして、このディレクトリのファイル一覧表示してみて」
>(新 ´Д`)「えっと・・・あ、lsだっけ???」
>(新 ´Д`)「よし、メモ帳に残しておいたlsコマンドをコピペっと。よし!表示できた!」
(私;´_ゝ`)「・・・・・」


ビックリです。1文字でも2文字でも、コピペしないと気が済まないようです。
iとlを間違えたらエラーが起きちゃうじゃないですか!!と言われた事もあります。

対応策

コピペの弊害を具体的に指摘するとよいです。

  • コピペをする事で あなたはそのコマンド・コードが何をしているかを理解する事は永遠に無い。
  • コピペをする事で、あなたは手打ちでコマンドを叩ける日は永遠に来ない。
  • あなたはストックしておいたコピペメモに書いてない事が起きた時、何もできずに途方に暮れる。
  • 以上の事から、あなたがスキルアップする事は無い。無駄な時間を過ごす事になる。

4,手順マニア

続いて登場、手順マニアです。
早速具体例を見ていきます。

具体例

(私 ´_ゝ`)「よし、このバッチを実行してデータを更新してみて」
>(新 ´Д`)「はい!えっと実行手順は・・・wikiに書いてあるな」
>(新 ´Д`)「あれ、エラーになった。」
>(新 ´Д`)「これ実行したらエラーになっちゃったんですけど・・」
(私 ´_ゝ`)「あ、sudoで実行してね」
>(新 ´Д`)「了解です!wikiメンテしておくか。」

(私 ´_ゝ`)「よし、じゃあ次はデプロイしてみようか」
(私 ´_ゝ`)「jenkinsのデプロイジョブじゃなくて手動でバッチ実行してデプロイしてみて」
>(新 ´Д`)「はい!」
>(新 ´Д`)「あれ、エラーだ。またエラーが起きました。」
(私 ´_ゝ`)「あ、そこはsudoで実行してね」
>(新 ´Д`)「了解です!wikiメンテしておくか。」
>(新 ´Д`)「結構手順がザックリしか書いてないんだなあ。よし!自分が細かくメンテする!」

・・・now maintenance・・・・

>(新 ´Д`)「wikiメンテしておきました!!」
(私 ´_ゝ`)「アリガトゴザマス。どれどれ・・・うお!凄いテキストの量・・・」
(私;´_ゝ`)「(おいおい、こんな事まで書くのか。まあいいけどメンテできんなこれ)」

(私 ´_ゝ`)「じゃあ今日はステージング環境デプロイしてみよっか」
>(新 ´Д`)「はい!デプロイ手順もバッチです!!!」
(私;´_ゝ`)「お、おk。(手順ってコマンド2回叩いて終わりなんだけど・・・嫌な予感がする)」
>(新 ´Д`)「よし、このコマンドを実行っと。あ、エラーだ!!」
>(新;´Д`)「どどどどうしよう!!こんな事手順に書いてなかった!!直せない!!」


はい。こういうケースって結構ありますね。
たった2行のコマンドを叩くのに100行のテキストに手順をまとめて実行する愚行
手順をまとめる事は悪い事ではありません。しかし

  • 手順に頼りすぎてしまい、今何をしているのかを考えなくなり、淡々と機械的にコマンドを打つだけになる。
  • 手順外の事が起きた場合、パニックを起こす。
  • デプロイをするという目的を忘れ、手順をまとめる事が目的となっていまう。
  • 手順をメンテするのに1日かかる。手順の変更にとんでもなく弱い。

というような弊害があります。

対応策

どこまで手順を書くかはメンテナンスとのトレードオフになるので、書き過ぎず、書かな過ぎないようにするくらいが丁度いいかと思います。くれぐれも手順をまとめる事が目的にならないようにしましょう。目的はデプロイする事ですからね。

手順マニアはコピペマニアと高い関連性があります。
手順を大量にメモしておき、いざデプロイする時にメモ帳からコピペしてバッチを実行していく。自分の頭で何も考えておらず、今実行しているバッチが何をしているかを把握しておらず、そのバッチがエラーを吐いても対応できない。何を調べていいか解らない。手順に無い事が起きるとパニックを起こして止まってしまう。

これに対応するには、

  • 手順のコマンドの実行の仕方より、コマンドが何をするものかを把握する。
  • 手順を信じ過ぎず、自分の頭で本当に正しいかを考える。
  • 手順外の事が起きた場合は一般的な方法でエラーの原因を探る。

ことでしょうか。
このコマンドはsudoを付ける必要があるのか。付けるのは何故なのか、等を自分の頭で考えてみるとよいです。これはこういう理屈でこうしている。ならここはこうするのは当然の流れか、なるほど!と考えられると、手順の最適化や高速化にまで手を伸ばす事ができるでしょう。手順を機械的に実行する事に注力する人は正直不要です。そんなものはjenkinsにやらせます。あなたは手順が実行できる事よりも、手順のコマンドが何をしているかを理解していく必要があるのです。

自分の頭で何故ここでこのコマンドを叩くのかを理解できるようになると、手順がほとんど無いのに手順のコマンドより最適で高速に実行でき、想定外の事象にも対応できるようになっていきます。

※ 手順が不要というトピックではありません。

雑感

この中でも最も致命的なのはコピペマニアかと思います。
コピペが好きな人は本当にスキルアップしません。
1年経っても同じコマンドをコピペして実行しています。
想定外の事象に大してあまりにも弱すぎます。

自分の頭で考えるようになると、ボトムアップ思考が何故問題なのか、コピペマニアが何故問題なのか、手順マニアが何故問題なのか、等に気づく事ができ、速く答えに辿り着くことができるのではないかと私は思っています。

以上、treeの棚上げトピックでした。

モチベーションで仕事はできない (ベスト新書)

モチベーションで仕事はできない (ベスト新書)

仕事ができる人できない人 ―「あの人はできる!」と納得させる20のルール

仕事ができる人できない人 ―「あの人はできる!」と納得させる20のルール