思うままにつづる

プログラマやエンジニアであれば、仕事でコードを書き、システムを実装することは多いと思います。特定の技術や知識を持っていることが、エンジニアとしての価値であり、そこを極めればスーパーエンジニアとなり、どんな複雑なシステムでも実装できるようになると考えている人も少なからずいるようです。

しかしながら、そうした部分以外にも大事なことがあります。実際に、得てして特定の技術や知識ばかりに目を向けている人ほど、同じような過ちを犯し、成長しないこともあるように思います。

今回はこうした、単純なプログラミング技術や知識ではなく、どんな技術を使って実装するときでも大事になることをまとめておきます。

エラーメッセージをよく読むべし

まず、卓越した技術や知識を持っているわけではない人の場合、たいてい実装をしているときにエラーに遭遇することはよくあります。そしてここで、この 「エラーメッセージをよく読む人」と「エラーメッセージを読まない人」がいます。ここが大きな分かれ目です。

かなり低レイヤーの開発をしていたりしない限り、最近のプログラミングなどで遭遇するエラーは、読めばなぜエラーが出ているのかを自然言語で書いています。そしてこのエラーメッセージをよく読まないと、「なぜエラーが発生しているのか？」そして「自分が何を間違ったのか？」ということを知ることができません。

「エラーメッセージを読まない人」がエラーを解決しようとしてよくやる手としては、以下があります。

とりあえず手当り次第コードを変えてみる
エラーをGoogleで調べて出てきた解決策を、理解せずにコピペしたり、試してみる

残念ながらこうしたやり方では、適切な解決になっていない可能性もあり、エンジニアとしての責務を果たしているとは言えません。

また、こうしたやり方をした上で人に聞くといったことをしていると、周りからは能力が低いエンジニアだと思われてしまいます。

エラーメッセージに遭遇したとき、エラーメッセージをよく読みましょう。エラーを理解できるのも、エンジニアのスキルです。

いきなり実装し始めるのではなく、開発する内容をより細かいタスクに分割し、見積もりをするべし

「実装してください」というと、いきなりコードを書き始める人がいます。もちろん表示される文言を変更するだけといったときはそれでも良いでしょう。しかし、多少時間がかかる開発をする際に、この対応は悪手です。

たいていの開発は、どのような手順があるかを洗い出し、どのくらいかかるか見積もる必要があります。こうすることで、複雑な開発を単純なタスクの組み合わせに落とし込み、何をする必要があるかの全体を初めて把握することができます。また、こうした把握をして初めてどの程度開発に時間がかかるかを予測することができます。

思いつきでコードを書き、あとから指摘されたら漏れている対応を行い、その結果、自分が宣言した見積もりから大幅にずれて開発をしている、といったやり方では、責任ある仕事は任せてもらえません。

一次情報を読むべし

最近は技術ブログによる解説なども多く、そこからコピペすればほとんどの問題が解決する、という人もいるかも知れません。しかし、ブログなどにかかれていないようなことはどうするのでしょうか？

開発をする際に行ってほしいのが、「一次情報を読む」ことです。一次情報とは、プログラミング言語やライブラリ、サービスなどの、公式のドキュメントやコードなどです。当たり前ですが、技術ブログなどは、その当時のことを記載しているだけで、他のバージョンでも使えるのかといったことはわかりません。また、本当に正しい解決方法なのかということもわかりません。

また、公式ドキュメントなどは英語であることも多く、英語が読めないので、はなから読まないという人もいます。しかし、これでは成長できません。最新情報を知るには、そうした情報を自分で読み取っていく必要があります。

もちろん、一次情報のみを利用し、技術ブログの情報を一切使うべきではないということではありません。ただし、それを鵜呑みにせず、一次情報と比較して問題ないのかといったことはしっかり確認するようにしましょう。

わからないことは自分で調べ、考えるべし

困るとすぐに人に聞く人がいます。確かに、スキルが高い人がいる場合、聞いたほうが早く解決することもあります。しかし、そればかりではなんのためにその人はエンジニアをしているのでしょうか？

スキルが不足していても、「ここまでは理解できた」「ここまでは調べ、考えてみた」ということをしっかり整理して行うべきです。そして「なぜ、このタイミングで人に聞いたのか」ということも説明できるべきです。

残念ながら、一部こうしたことが一切できていない人がいます。記載されているそのままのことについて「ここってわかる？」と聞くと、「わかりません」といったことであれば、まずは自分でそうしたわからないところを調べる癖をつけていかなければ、人に聞いてその場しのぎで満足していくだけになり、成長しません。スキルアップするには、自分で調べ、考える必要があります。

人に聞くのが悪いことではありませんが、理解していないことをそのままに調べもせず人に聞くのは、エンジニアとして成長しない人だと思われてしまいます。

まとめ

エンジニアとして、実装するときにどうするべきかということを書いてみました。できる人ならほとんどの人がやっていることかもしれませんが、意外とできていない人もいるのではないでしょうか？

できていないかも、という人は、エンジニアとして成長したいのであれば、ぜひこうした特定の技術だけでない、開発への向き合い方の部分にも目を向けてみましょう。

エビデンス、ファクト、KPI、KGI、PDCA、CRMなどビジネスでは当たり前とされる用語はかなり多い。

個人的には使うのは良いと思う。
スローガンにもなりうるし、共通言語として使えば長々と伝えるより明確である場合もある。

しかしこれらの言葉を使うときに相手に伝えることを考えているだろうか。
自らの希望を伝える、楽をして伝えるために使う、さらには呪文のように唱えるだけになっていないだろうか？

「PDCAサイクル」は目指すべき状態であり、個別の問題に対する指摘ツールではない

最近ビジネスでは当たり前とされるフレームワークとして、PDCAがある（PDCA自体については今回言及しない）。
よく「PDCAを回すように」「PDCAサイクルがうまく回っていないのでは？」「PDCAができていないのでは？」といった形で使われることも多い。

さて、この言葉を聞いたときに部下や同僚は『具体的に何をすべきか？』が浮かぶだろうか。

もちろん今から何かを始めるときや継続していることの中で意識すべきものとして伝えるのには非常に良い。ただ、何らか問題があるときにそもそも全部できていないのか、一部できていないのか、相手に伝わるだろうか。

聞いた側が考えるべきというのであればそれでも良いが、直してほしいことがあるなら、お互いのために曖昧さを残さない伝え方をすべきだろう。

「MICEでない」、と言われたときの曖昧さ

MICE（ミーシー）というのは、「漏れなく、重複なく」を意味する略語である。

Mutually（互いに）
Exclusive（重複なく）
Collectively（全体として）
Exhaustive（漏れがない）

さて、とある情報をまとめて共有したときに「MICEになっていないので、MICEにしてほしい」と言われたとしよう。これは「漏れがあった」ことを指しているのか、「重複している」ことを指しているのか、その両方なのかぱっとわからない。

MICEは、目指すべき状態ではあるものの、複数の条件を指しているので、課題指摘の際には曖昧さが残る表現でもあるといえる。

「このあたりに〇〇に漏れがあるようなので、追加してほしい」「〇〇と△△は重複している、他にも重複があるので整理してほしい」と伝えるほうが何を問題視しているか明確であるといえる。そのうえで「MICEを意識して取りまとめてほしい」と追加で伝えればよい。

問題の指摘と意識すべきことは別なので、そこを分けて伝えるのが良いだろう。

おわりに

簡単に例を挙げて今回取り上げた問題点を指摘した。

覚えたばかりで、良いと思っている考え方に紐づく横文字・略語ほど、深い考えなしに口にしてしまう事が多い。ただし、それが相手にどう伝わるのか、具体的なアクションにつながるのかということは考えるべきである。

自分自身でも気をつけるべき点は多く、改めて意識すべきこととして記した。