こんにちは、らくからちゃです。
普段、Togglというツールを使って作業実績の収集を行っております。
Web上からも、実績情報が整理出来てなかなかいい感じです。先日、作業実績のメンテナンスを行うために、サイトにアクセスし、ぶらっと開発ブログを覗いてみたら、なかなか良い記事を見つけました。
記事のタイトルは『より良いプログラマーになるために学んだ７つのこと』となっており、プログラマーに向けた内容の記事です。特に突飛なことや斬新なことが書いてあるわけではありませんが、プログラマーだけでなく他の業種でも役に立ちそうな内容でした。
ちょうど新入社員が働き始める時期ですし、補足（蛇足）もつけながらご紹介したいと思います。（翻訳はGoogle先生におまかせしました）
1.問題ではなく、解決策を伝えよう
最初のアドバイスは - 積極的になることです。
ほとんどのソフトウェアは、問題が起きる時、何が起こっているかを教えようとします。ヘルプを尋ねる前にまず問題を理解してください。画面を読み、ログを読んだり、スタックトレースを確認し、Googleにエラーメッセージを貼り付けたり、デバッガを使って祈ったりしてください。
もちろん、あなたはまだ必要な技術的スキルを持っていないので、おそらくいくつかの問題はあなただけで解決するには大きすぎます。もしくはあなたの上司だけが決定できる事項を含んでいるからです。
あなたが問題を説明するときに、可能な解決策の概要を示し、次に話を伝えるひとには、より簡単にしてください。
ここでは積極的な活動のためのスペースがあります。問題を説明しているときに、可能な解決策の概要を説明することによって、次の人の作業を簡単にすることができます。
仕事とは、常にトラブルとの連続です。当然、最初はどうすればいいのかなんて分かる訳ありません。そんなときには仲間や上司をたよれば良いと思いますが、ただ
『こんな問題がおきました。どうすれば良いのでしょうか？』
ではなく
『こんな問題があるのですが、A案とB案のどちらが良いでしょうか？』
と尋ねられるように努力しましょう。
問題に接した時に、まず真っ先に行うべきは『問題の切り分け』です。例えば、あなたのパソコンから資料が印刷できないとします。そんなときには何をすべきなのか。
- 全てのソフトから印刷が出来ないのか？（問題はソフト？ハード？）
- あなた以外のパソコンからは印刷出来るのか？（問題はあなたのパソコン？）
- 別のプリンターからは印刷出来るのか？（問題はプリンタ？）
などなどです。情報が一番入手し易いのは、現場にいるあなたです。状況を整理すれば、いくつか解決策が見えてくる可能性があります。その上で『プリンタが壊れてしまったようです。別のものがあるので暫く大丈夫ですが、買い換えるか他の部署から持ってくる必要があります。どうしましょう？』と言えれば、随分と手間が減りますね。
2.『これでもか』というくらいに確認しよう
執拗にテストをすること。おそらく最も重要なことです。
それはコードベースに追加したもの何か他のものを壊すことなく動作することを保証するためできる唯一の努力です。
私の個人的なガイドラインは、テストを必要とするには小さすぎる変更はないということです。コードの一部が変更された場合、そのコードが汚染されているかのように見えるはずです。それを掃除する唯一の方法は、それをもう一度全面的にテストすることです。ああ、それには依存関係も含まれています。
より良いのは、テストを他の人に依頼することです。Togglでは、ワークフローのひとつとしてコードレビューが用意されています。ここでは、お互いのコードを本番環境に移す前にそれを読み、テストします。私たちの品質保証のためには不可欠な作業です。
それはまた素晴らしい副作用を持っています - 新しい開発者の参加を容易にすることです。より経験豊富な開発者にコードベースの特徴を説明し、会社のスタイルに合わせてコードを改善する方法を提案します。
プログラミングの世界では、ちょっとした変更が、システム全体に悪影響を与えることは少なくありません。これはなにも、ITシステムだけの話ではなく、会社で決まっているルールに関してもいえます。
例えば業者から連絡が入り、必要な機材の納入が30分ほど遅れそうだと言われたとしましょう。まあ30分くらいなら・・・と思いきや、その後ろに作業開始を待っていた人全員が待機することになり、会社全体では何時間ものロスが生じてしまった。なんてこともよくあります。
特に打ち合わせの日程など、時間に関する変更は、影響範囲が考えているよりも広くなることが多いため、注意が必要です。
3.自分の記憶を頼りにするな
もしプログラムに関する知識の文書化が行われていない場合、自分から行いましょう。 「文書化する」とはMicrosoft Word上の広範で退屈な文書を書くことを意味するものではありません。物事を分かりやすく、説明的で簡潔にすることを意味します。
（中略）
あなたのコードをコンピュータで読めるようにするのは簡単ですが、難しいのは人間にとってコードを読めるようにすることです。
しかし、それはいろいろな形で成果を上げています。コードを維持するのがより楽しく、バグを見つけるのが簡単で、新しい開発者の入門がスムーズです。それは誰にとっても時間を節約します。あなたは文法的なプログラミングに完全に移行する必要はありませんが、自然言語をコードよりも読むのはずっと簡単です。
ああ、ハックをする必要がある場合（ハックをしないでください）、あなたが作成したモンスターを説明するコメントを追加するには、法律で義務付けられています（または少なくともそうでなければなりません）。
人間の記憶は必ず失われます。あとからまた同じようにやろうとしただけなのに、すっかり前のことで何が何やら分からないことはよくあります。
それを避けるために必要なことは、記憶ではなく記録を残すことです。
個人的に重要だなあと思うのは、事細かに『何をしたのか』を記録するよりも、『何故そうしたのか』をきちんと残すことです。それが無ければ、手間暇をかけて記録を残し、それを見たところで、同じことをやるべきなのかどうかがさっぱりわかりません。
特に『何をしたのか』より『何故したのか』は記憶が薄れやすい上に、無視される例が多いような気がします。今日のちょっとした手間が、明日の大きな手間を減らすことがあることを意識しましょう。
4.スーパーマンになろうとしないで
私がプログラマとしてキャリアをスタートさせたとき、私は何時間も働くことは涼しいと思っていました。
私は週末をスキップし、それが通常のことであるかのように全員を引っ張りました。私は学び、物を作ることに熱心だったので、初めは楽しいと感じていました。
私が遅れたプロジェクトを逐次救うのが自分の責任だと思ったので、私がそれをやり始めたときに問題が始まりました。そのサイクルを壊すには長い時間といくつかの仕事が必要でした。
そのような仕事をしている従業員がいる会社はかなり良い取引だと思う人もいますが、これは大きな問題になる可能性があります。自社にヒーローがいる場合、プロジェクトは過小評価され続けるでしょう。また、避けられない怒り（またはあまりにも多くのピザによる早すぎる死）が来るとき、会社は間違いなくねじ込まれる。
クレイジーなスケジュールを持つことに関するもう1つの問題は、忙しさの罠に巻き込まれてしまうことです。あなたは非常に忙しいと思うでしょうが、あなたの生産性は実際には本当に低いです。
私よりもずっと賢い人はこう言いました。「あなたがあなたの人生を優先させなければ、他の誰がするんです？」
仕事をしていると『あのひと本当になんでも出来るな』と思うスーパーマンのような人を目にすることもあります。
勿論、そういう人に憧れて、自己研鑽を積んでいくのもよいでしょう。
ただ仕事を上手く進めるために一番大切なことは『あなたが居なくとも仕事が回る』ことです。『あの人にしか出来ないよ』と言われるようなスーパーマンになってしまってはいけません。もしそうなってしまうと、あなたが仕事のボトルネックになってしまいます。そして、より知恵を絞ることが難しくなってしまいます。
そうならないためには常日頃から、『自分しか分からないこと・出来ないこと』を生み出さないように、連携をとったり資料を残したりすることが大切です。
5.価値を産まないこだわりは捨てよう
私は、脳の特定の部分に脳卒中があり、仕事に取り掛かる時間を知る能力を失った男性についての神経学の本の記事を読みました。
うん、変だ。
時にその決定は確かに論理を超えています。でも、すでに動作しているモジュールのリファクタリングを停止する時期はいつですか？抽象化が現実の世界にどれくらい近い必要がありますか？
これらの質問に答えるための正確で正式な方法は、文脈に依存するのでありません。
これに対処するための私の方法は、最小の努力の原則と、私が「罪悪感に基づく開発」と呼ぶものの両方に基づいています。締め切りが厳しい場合は、他の人がそれを見たときに私をあまりにも恥ずかしくしない、最も速い解決策を選ぶでしょう。私がそれを正しく行う時間があれば、私は誇りに思うまで自分のコードを磨きますが、私がその特定の仕事にも座っている可能性があると感じるとすぐに止まります。
あなたの賃金はコードを書くために支払われていません。人々の問題を解決するために支払われているのです。
見つけるのに役立つものは、コードを書くのではなく、実際の人々の現実世界の問題を解決するために支払われていないことを常に心に留めておくことです。
神は細部に宿る。なんていい方をすることもありますが、良い仕事をするひとは、事細かなところにもこだわります。特にプログラムを書いていると、きっともっとこうしたほうが良いはず。ということはいくらでも出てきます。
確かに、細部まで丁寧につくられたプログラムは、改修の必要があるときも少ない作業で効率的に行うことができますし、見ていても書いていても気持ちが良いものです。
でも問題は、時間にもお金にも限りがあることです。
あなたは、仕事をするためにお給料を払われているわけではない。誰かを幸せにするためにお給料を払われています。
丁寧な仕事をするために掛けられたコストは、それを上回る利益をもたらすこともあります。それはそれで重要なのですが、仕事の完成を首を長くして待っているお客さんに、迅速に作品を渡すのも重要な価値であることを忘れてはいけません。
6.車輪の再発明はするな
ライブラリやフレームワークを書くのは楽しいことです。ただ、おそらくあなた自身で作成する必要はないでしょう。他の誰かがすでにあなたのためにそれらを書いてくれています。
コードが成熟するのは、何回テストされ、バグを修正するためにリファクタリングされたのかということです。一から作った時の品質は、よく知られているライブラリとはかけ離れます。ですので、あなたが何かをコーディングする前に、まずGoogleで数秒を費やし、それがすでに存在しないことを確認してください。
これは、あなたが使っているライブラリの中で何が起こっているのかを知るべきではないということを意味するものではありません。
他の誰がそれを使用しているか、ソフトウェアライセンスは何か、作成者が更新する頻度をチェックすることは良い考えです。そして、オープンソースのものを好むのは、少なくとも何かがうまくいかなくなった場合、あなたはフードの下で覗き見をすることができ、あるいは自分で問題を解決することもできるからです。
既にある仕組みを一から作り直すことを『車輪の再発明』なんて言うことがあります。車輪の再発明は何故いけないのか？単純にコストが掛かるからだけではありません。
他の人が考え、利用されている仕組みには、あなたが思いつかないような状況にも対応できる仕組みが盛り込まれています。例えば、あなたが一から自動車を設計するとして、シートベルトやABSの必要性を思いつけるでしょうか？
また、既に多くの人に使われている仕組みは、多くの人に仕組みが理解されている分、より受け入れられやすいという利点もあります。
巨人の方には、積極的に乗っていきましょう。
7.仕組みは背景から理解しよう
ツールごとに、解決しようとしてる問題があります。
ハンマーは、誰かが鋭い物体で硬い表面を穿孔する簡単な方法を望んでいたために考案されました。同じハンマーを使って木を伐採することもできますが、その作業のための適切なツールではないので、あなたはばかだと思います。ソフトウェアと同じです。
あなたのプロジェクトにクールなライブラリを追加する前に、あなたのチームがそれが何をしているのか、その存在の背後にある動機は何か、その限界は何なのかを知ることが重要です。
ドキュメントを読むこととは別に、どういった概念で作られたものであるのかは、その使い方を理解することための良い方法です。また、ベストプラクティス、コーナーケース、およびツールを使用するときの一般的な経験をWebで検索することです。
すこし注意を払うことで、雨が降っているときに木（またはあなたのコンピュータ）を叩くのを止めることができます。
世の中には、色んな人の考えた仕組みがあります。それらを使う場合、それぞれの特性や特徴をしっかりと理解した上で使いましょう。
状況によって、どの仕組みを使えば良いのかは変わってきます。『何が出来るのか？』だけ考えているとより良い方法を見失うこともあります。どの仕組みを使うべきなのか？を考えるための一番の近道は『どういう背景から生まれたのだろうか？』に意識を払うことです。
その仕組の備えている思想背景が分かれば、仕組みを隅から隅まで網羅するよりもよっぽど短い時間で、『出来ること』『出来ないこと』『出来るけどもっと良いこと』がなんとなく予想がつくようになります。（それは人事に問い合わせるのか、経理に問い合わせるのか、とかね）
楽しくお仕事しようぜ！
本当は、記事の訳文だけで十分素晴らしい内容なのですが、他のお仕事の方にも伝えたかったので、今までやってきたお仕事を振り返りながら適当な補足を加えてみました。
原文は、英語で書かれていますが、Google翻訳にでも投げつけてやれば、それなりに良い精度で訳文（きっとこの記事とほぼ同じ文章が読めるでしょう）が還ってきます、是非！
職場に入れば、これくらいのことは先輩が教えてくれるかもしれませんが、当たりハズレがあるかもしれませんので、こんな本を読んでみるのも良いかもしれませんね！
ではでは、今日はこのへんで。
