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

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

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

プログラマはもっと些細な事に疑問をもっていい

プログラマ

皆子供の頃「なんで〜?」「どうして〜?」と先生や親を困らせていたのに、大人になると疑問に思う事をやめてしまいます。なんででしょうね
f:id:treeapps:20160214005029p:plain
simplearchitect.hatenablog.com

こちらの記事を読みました。簡単に概要だけお話すると、「日本人は他人に聞く事に関して重く考えすぎだろオラーン!!!」という記事(コナミカン です。

この記事を見て私はこう思いました。

他人に聞く以前に、「何故?」と疑問にすら思わない人が増えているのではないか?疑問にすら思わないから、他人に聞いてみたり質問したりするきっかけがないのではないか?

と。

例えばプログラマといえば環境構築は避けて通れませんね。

環境設定の例を挙げると、gradleはbuild.gradleでプロジェクトに親子関係を持たせる事ができます。そこで「なんでその設定で親子関係が持たせられるの?」「build.gradleは具体的にどこにどういう設定をして親子設定したの?」と疑問に思う人と、思わない人がいました。

疑問に思った人の意見

  • ちゃんと挙動を確認しておきたい
  • 単純に好奇心
  • 自分の目で確認しないと信用ならない
  • 知っておいて損は無い

疑問に思わなかった人の意見

  • ツールのやる事なんて知らなくていい
  • 自分そういうの詳しくないんで
  • そういう事を意識していたらそれを使う意味ない
  • 訳が解らないから

ざっくりこんな感じでした。

疑問に思わない人の意見は尤もな意見です。しかし、裏で何が行われるか知っているけど、それを意識しないのと、何も知らないし考えもしないのは違いますね。

完全に把握する必要はないのですが、ほんの少しでも知っておいた方がいいですね。そうしないと、「こんな事しらなくていい」→「それを知るきっかけが訪れない」→「一生知る機会が生まれない」と繋がってしまうかもしれません。

他人に言われるがままで疑問に思わない

凄く極端な例ですが、昔こんな方がいました。

  • 環境構築は完全に手順任せで手順をコピペするだけのマシーンと化している。
  • デプロイ等の作業は、メモ帳にメモっているコマンドをコピペするだけ。エラーが起きても無関心。
  • 何か質問ありますか?と聞いて質問してきた試しがない。
  • 知識の源泉が、その職場でやっている事だけに限定されてしまい、外の世界を知らない。

この方は、日々の開発の中で、「このロジック、なんでこういう回りくどい事してるんだろう?何か特別な意味があるのかな?」とか、「この設定でなんでこうなるの?」など、ほとんど何も疑問に思わない人でした。完全に手順・指示に沿って、ロボットのごとく作業するだけでした。その作業内容も、基本他のロジックのコピペで、そのロジックが中で何をしているのかを考えもしないようでした。
www.bunkei-programmer.net

例えばこの方はこんなミスをしていました。あるITに微妙に心得のある風のクライアントから、日付のフォーマットをハイフン区切りにしたいので「YYYY-MM-DD」にして下さいと依頼を受け、その方はこんなコードを書きました。(クライアントはハイフンにしたいだけで、ちょっと頑張ってYYYY-MM-DDと書いてみたが、間違いだった事に気づいていない)

// ↓これが修正前のコード
// SimpleDateFormat sdf = new SimpleDateFormat("yyyy/MM/dd");
// ↓これが修正後のコード
SimpleDateFormat sdf = new SimpleDateFormat("YYYY-MM-DD");
Date date = sdf.parse(createDate);

普通に考えれば、よほど特殊な事情が無ければ「YYYY-MM-DD」は明らかに間違いで、「yyyy-MM-dd」が正解だと解ります。しかし彼はクライアントの言われるがまま設定し、見事バグとして起票されてしまいました。何故YYYY-MM-DDにしたの?と聞いてみると「言われた通りにやりました」と返答されました。確かにその通りなのですけどね。。。しかしここで「明らかにおかしくないかこれ?」と疑問に思わない点が、危険だなあと思いました。

たとえクライアントに言われた事であろうと、常に「ん?これ本当にあってる?」と考えたり、「これ言われた通りに反映するとヤバイよな・・?」と考える事は重要だと思うのです。言われるがまま作業をするだけだと、全く何も疑問に思わず、何か新しい事を知ったり知識を深めるきっかけがつかみにくいと思います。

疑問に思わない事を続けた末路

更に極端な例ですが、こんな感じに日々の作業で何かを疑問に思う事が無いタイプの方は、「他人に完璧にセットアップして貰った環境の上で、ビジネスロジックを書く事しかできない。しかもそのビジネスロジックは他の処理をコピペするだけ、という状況に陥っていました。他人が敷いてくれたレールの上を、他人が作った電車をコピーして走らせる事しかできない、というわけです。

そう、ビジネスロジックしか書けない症候群に陥ってしまっているのです。

そんな感じでできる範囲があまりにも狭く、何年経っても局所的な作業しかできないため、徐々にその人に仕事を振りにくくなっていくという事が起きてしまいました。

局所的な知識しか無いと設計の幅が狭まる

ビジネスロジック以外に考えられる事ができないと、設計の幅が致命的に狭くなる事があります。

ロジックで頑張ろうとせず、インフラ側で対応した方が効率が良くメンテナンスフリーにできたりするのに、知識が無いが故にそういう発想に至らない。ビルド・デプロイを工夫すればそんなロジック不要になるのに、知識が無いが故にそういう発想に至らない。発想が「ビジネスロジック」という狭い範囲に閉じてしまうが故、より効率の良い設計ができない場合があります。

そしてそういう状況に陥っている事を本人は気づく事ができません。そんな世界がある事を知らないからです。そしてそれを知るきっかけが生み出せないでいます。

もっと疑問に思って欲しい

プログラマはもっと日々行っている事を疑問に思ってもいいと思います。

「なんでそういうプロジェクト名にしたの?」「この設定すると何が起きるの?」「このファイルなんでここに置いてるの?」など、些細な事すら疑問に思って欲しいと私は思っています。ほぼ全ての事にはそうしている理由があるので、疑問に思う事ができれば、それを知るきっかけが生まれます。そこで疑問に思わなければ、一生それを知るきっかけが無いかもしれません。

「些細な事を質問するなんて恥ずかしい」と思っているなら大間違いです。「些細な事を知ろうともしない事が恥ずかしい」のです


これは、社内だけでなく、社外の話にも言えます。「クライアントはなんでいつもこんな非効率な事やろうとしてるんだろう?何か理由があるのか?」「クライアントがこんな事を言うのは、向こうに何か事情があるのだろうか?」など、相手側の行動に対して疑問に思うと、相手側が抱えている問題を解決するきっかけが生まれる事もあります。

雑感

私の個人的な意見ですが、知識が増えるきっかけは大抵「疑問に思う」事から始まっていると思っています。

例えばネットでIT系のニュースを日々見ていて、「お?この記事に書いてあるライブラリなんだ?凄そう」と疑問や興味を持ち、実際それを使ってみたり勉強してみたりする事に繋がります。そしてそこで出てくる専門用語や技術が解らず、初めて「他人に聞いてみよう」「気になるから自分で調べてみるか!」という行動を起こすのではないでしょうか。

そうやって少しづつ知識を増やすきっかけを増やさないと、「え?それを知らずにその作業してたの!?嘘でしょ・・・」と言われる人間になってしまう可能性があります。そうなってしまうとgithub等の外部から自分の知らない未知の知識を取り入れる事もできないので、自分の知識源が自分の周りの非常に狭い範囲に限定されるリスクもあります。そうなってしまうと、将来がちょっと怖くなりますね。。


今回は非常に極端な例を挙げましたが、疑問に思わない人、は本当に増えてきていると感じています。最近はIDE・フレームワークが何でもかんでも自動でやってくれるので、余計に考えなくてよくなってきているのですよね。高機能になればなるほど利用者は考える事をやめてしまいがちなので、思考停止しないよう常に疑問に思う事を意識し、裏で何が行われているのか、今やっている事は正しいのか、を意識していきたいですね。


ちなみに冒頭の記事の「気軽に聞けない事」に関して私の意見を言うと、「ガンガン質問していいけど、同じ質問するのは最大3回くらいにして欲しい」です。同じ質問を何回もされると、流石に「覚える気ねーな・・・」と思ってしまうので、嫌な感じがしますね。質問をする事自体は凄く良いことだと思います。然るべき人に聞けばググるより速く回答が貰える可能性があるし、回答する側にとっても、他人に説明するという練習をするきっかけにもなります。

最近ではもう本当に疑問に思って質問してくれる人が減ってきているので、バシバシ質問して欲しいですね。