Murga

個人的に言いたいコト・主張・気持ち。

教える側も教わる側も押さえておきたい心構えとかの引用

成功する人は、教わり方が違う。

成功する人は、教わり方が違う。

上手な教わり方の秘訣

上手な教わり方の秘訣

  • 作者: 小高正芳,福田達夫,秋田豊,佐々木幸治,鈴木香織,青島利久
  • 出版社/メーカー: 三恵社
  • 発売日: 2016/04/11
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

自分もエンジニアとして働き始めて5年目とかになるので、それなりに周りや新人を目にする機会はあって、「なんでこんなことになっちゃうんだ」とか「コイツ今までどうやって生きてきたんだろう」とか思うことがある。それと同時に、「そういうヤツもいると分かっておきながら、どうして自分はうまくそいつをコントロールできないんだろう」とか反省することもある。

そんなワケで、「新人はできたら自分からこういう風になってね」という願いと、「そうは言っても無理だろうから、上司はこうしていこうね」という対策を、様々な記事から要点を引用してまとめてみる。


心構えや力不足を指摘しても、人は成長しない。
具体的な行動に注目してそれを習慣化させる。

「悩む」と「考える」を分けていく

マインドは伝わらない。アクションは伝わる。気持ちとか努力とか心構えを指導しても効果は出ない。そんなことをするくらいだったら「意味が分かるようになるまで黙ってコレを続けろ」と行動を指示した方がまだマシ。

「悩む」と「考える」の違いは特に重要。


自分の中での技術的な当たり前は相手にとっての当たり前ではない。

トラブルシューティングの方法は喜んで教えましょう、教えましょう。

「自分でやった方が早い病」に陥らないようにしましょう。

仕事を振る時、「到達点 (= 目標であり、成果物の定義や粒度)」は正確に伝えるが、そこに到達するための具体的な方法はあまり指示しない方が良い。


コードを深追いする深さが、プログラマの成長限界をどこにしてしまうかという基本的なパラメータではないか

体系的知識を身につける

プログラミングの基礎から勉強中の人は、自分が書くことに精一杯だが、本当は「正しく読む力」が大事で、コードリーディングの数をこなさないといけない。

個人的な好奇心や興味をベースに勉強や仕事をすると、知識や能力に偏りが出て、基礎が出来ていない人間になっていくので、体系的に知識を身に着けようとする姿勢は大事。OJT の場合、悪い「現場主義」になりがちなので、「現場ルール」と「世間一般的な知識」を区別して教え、できれば書籍などを紹介して一般的な知識も吸収させるようにしたい。


  • 言い訳を口に出さない
  • 逃げ道は、心の奥底にしまっておくもので、普段から考えない
  • 当事者意識を持つ
  • 保守性を重視する
  • 「そもそも」から考える癖をつける
  • 作っている本人が「なぜこう書いたのか?」を説明できない部分があってはいけない
  • 作業の前にTODOリストを作れ
  • 自分の案件だけすれば良いという訳ではなく、チーム全体で成果を出す
  • ただ厳しく接するだけではなく、「自分はできるんだ」という成功体験を味わわせる

README.rst を書く

  • まず最初に何がしたいのか、どんなことをしたいのかを書く
  • 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく
  • そして README.rst に擬似コードを書き始める

「ぼく内気なんで、うまく話せないんです」じゃねえ。報告も仕事なんだよ、言い訳してんなら死ね。

はじめのうちは1h〜1.5h毎に上長に進捗を報告しよう

これ必須。「今何をしています」「さっきからコレを順調に続けてます」は何も問題がなくても定期的に言う。「困ったことが出てきました」は5分調べて分からなかったらまず共有する。


この仕事をしていてよく思うのですが、たとえ些細なことでも絶対的な正解なんてのは存在しないです。
あるのはその時に選べる選択肢と、その選択肢を選んだときのメリット/デメリットです。 さらに言えば、そのメリットとデメリットも状況によって大きく変わりますし、正確に予測することは先輩社員でも困難です。

学校の勉強のように「正解を教える」ということは先輩社員にもできないのです。

ググっても絶対出てこない問題(社内特有のルールやシステムなど)についての質問は大歓迎です。
調べても時間の無駄になることはわかっているので、これは社内特有のものだと判断したらすぐに聞いてください。
特有なのかどうかが判断できない場合もやっぱり聞いてください。一般的な内容だった場合は「ググってね」で終わるだけなので。

日々、少しでも多くの情報を頭に入れ、それを自分の頭で解釈し、実験し、失敗し、試行錯誤をしながら、仕事をする上での最適な判断を下す力を鍛えるのが良いと思っています。
「この場合はこれが正解」ではなく、「こんな状況でこういう前提があって今こちらにはこんなカードがあるから、今とるべき行動はこれだろう、そうするとこんな結果が予測できるので、そうなったら今度はこうしよう」という考え方です。
おそらくこの考え方は机に向かって生真面目に本を読んで内容を覚えるだけでは身につきません。仕事やブログ等で考えを伝えて議論することで、他の人の思考回路を盗んでくる努力も必要です。

唯一の答えを暗記することが勉強だと思ってきた新人さん方は、会社は学校じゃない、学校で求められたことは要らない、というパラダイム・シフトを早めにして欲しい。

個人的には、同期と連れションに行く習慣はなくした方が良いと思う。仲良しグループじゃないから。


  • どうでもいいことほど、早くやる
  • ビジネス的な言い回しをちゃんと使う

ビジネス的な言い回しは本当に重要。いつまでもビジネス文書、ビジネスメールが書けそうにない人材は上司も昇進させられない。

コレに関しても、社内ルール・現場ルールも数多くあるし、唯一の正解があるものでもないので、沢山の知識を日々吸収していって、TPO にあわせて都度最適なカードを選ぶしかないこと。


  • ドキュメントを必要最低限整備する
  • エラーログと常に向き合う
  • 技術を知ったつもりにならない
  • アウトプットをクセ付ける
  • 誰のために、何のために働いているかを考える、分かろうとする
  • なぜ/どうしてを考える

いきなりコードを書き始めるのは止めましょう。絶対に書き直す事になります。時間がもったいない。
仕様をまとめましょう。

Taskを細かく分解+時間の見積もり

不確定要素を把握する力


格言・名言の類は、自分を鼓舞するためには有用だが、他人に押し付けて「お前もこうしろ」という使い方をするのは効果が出ない。

みんなに知ってもらいたいと思うけど、自分から知りたくて知ろうとした人でない限り、こうしたありがたいお言葉は残念ながらその人には響かない。

ご自身のためになれば、と。

問題に遭遇した時、自分一人でやること、質問する前にやること

問題解決――あらゆる課題を突破する ビジネスパーソン必須の仕事術

問題解決――あらゆる課題を突破する ビジネスパーソン必須の仕事術

新人さん向け。エラーメッセージやバグに遭遇して、どうしたらいいか分からない時、まず自分一人でやるべきことと、先輩上司に質問する際にやっておく必要があることをまとめておく。コレができないといつまでも迷惑な存在のまま燻るので、一刻も早く身に付けたい。

問題に対して一人でやること

まずはエラーメッセージをきちんと読む・英語でも読む

エラーメッセージに遭遇したら、まずエラーメッセージをきちんと読もう。エラーメッセージが英語だろうと、まずは自分で読むこと。「英語が読めない」なんて小学生までしか言えないセリフなので、死ぬ気で勉強して読めるようになれ。

よくあるのが、エラーメッセージを読みながら自分の勝手な推測が混じってしまい、意味を誤解してしまうこと。あまり自分の頭の中でストーリーを広げず、目の前に表示されているメッセージ・事実だけを拾い集めること。

英語が分からない人はついつい機械翻訳に放り投げるだけで何か分かった気になることが多いが、今のところ機械翻訳の精度はまだイマイチで、プログラミングの文脈を理解して翻訳してくれはしないので、翻訳ツールなどは分からない単語や熟語の意味を調べる程度に留めること。翻訳した文章は原文ではないので、何の価値もない。鵜呑みにしないこと

問題・原因を切り分ける

例えば「PC に USB 接続した端末が認識されない」時に、どこに問題があるのか、色々なポイントが推測できる。

  • 接続しようとしている端末のソフトウェアに問題があり、USB を認識していない
  • 接続しようとしている端末の端子が接点不良を起こしていたりする
  • 接続に使用しているケーブルが故障している
  • 接続に仕様しているケーブルが端末もしくは PC と相性が悪く、認識してもらえていない
  • 接続する PC の端子が接点不良を起こしていたりする
  • 接続する PC のドライバやソフトウェア、OS に問題があり、接続されている端末を認識できない

つまりコレだけ原因となりうる要素があるワケで、これらの問題を切り分けないと、何が問題なのか理解したことにはならない。

  • 同じ端末・同じケーブルで、別の PC に挿すと認識する → PC に問題がある可能性が高い
    • 端末やケーブルには問題がないことが明らかにできる。これを推測だけで正常なものと決めつけないこと。必ず実際に試すまでは勝手に答えを出さない。
    • PC の端子が悪いのか、ドライバが悪いのかはまだ分からない。分からない部分も正確に区別して認識しておく。勝手に問題箇所を特定しようとしない。
  • 同じ PC の別の USB 端子に挿すと認識する → PC の特定の端子に問題がある
    • この場合もまだ、単なる接点不良だけでなく、USB 2.0 端子に USB 3.0 のケーブルを挿していることで誤認識していたりする可能性もなくはない。
  • 同じ PC のどの端子も認識しない
    • まずハードウェア的な問題がないか確認するため、端子を掃除したり、別のケーブルを使って試してみたりする。
    • ハードウェアに問題がないことを (ある程度でも) 明らかにしたら、ソフトウェアの問題を疑い、ドライバをアップデートしたりしてみる。

例えばこうした試行錯誤を行い、原因箇所を切り分ける必要がある。

同様のことはコーディング時のエラーにもいえる。あるメソッドを使ったことで計算結果がズレている、と勝手に思い込んでいたが、よくよく調べたら違う箇所が原因になっていた、といったことはよくある。プログラミングの場合は「Print デバッグ」など原始的な方法を使っても良いので、「この行までは正常」「この行の処理でおかしくなる」といった原因箇所をきちんと切り分けよう。できれば、同じ問題が発生する最小構成のコードを別途作ってみたりしても良いかも知れない。

エラーメッセージでググる

まず自分の手元で発生した問題が何を訴えているのか理解したら、その文言をそのまま Google 検索窓に入れてググろう。

プログラム関係のたいていの悩みは、過去に他の誰かが悩んでいて、すでに解決してます。

そうすると、大抵は GitHub Issues や StackOverflow の質問ページなどがヒットする。

特定のメッセージがない事象のググり方

特にエラーメッセージが出ないけど、なぜかこのライブラリが思った動作をしていない、といった場合は、検索キーワードを自分で考える。そのポイントは、筆者の視点で文言を考えること。

  • ライブラリの概要を説明してくれている記事であれば、「○○とは」といった単語で執筆するだろうから、「○○とは」というキーワードで検索してみる。
  • 問題の解決策を解説してくれている記事なら、「○○が動かない場合の原因と対処法」などという記事タイトルにすることが多いと思われるので、「○○ 動かない」「○○ 異常終了 原因」といったキーワードを組み合わせてみる。

検索結果がイマイチ広すぎる場合は、「言語名 キーワード」とか「ライブラリ名 キーワード」といった形で AND 検索する。JavaScript の forEach に関する問題を調べたいのに、PHP の話が混じったりするなら、「JavaScript forEach -PHP」のように、除外検索を利用する。

まずは日本語で調べても良いが、分野によってはイマイチ日本語の文献が出てこない場合もある。そういう時は英語で検索する

何かが動かない時は「not working」、何かが不正な状態なら「invalid」、設定を書いたのに無視されていそうな時は「ignore」など、その状況を表す、よく使われる英語表現を交えて検索すると良いだろう。

ググり方に関しては、以下のような知識も事前に入れておくと良いだろう。

検索結果の最初の10件は全部読む

キーワードで検索したら、検索結果の最初の10件は何も考えずに全て別タブで開き、全てを熟読する、というのを習慣づけて欲しい。

「英語のページだから読みたくない」なんて論外。自分で解決できるスキルもないのに、「タイトルからするとあんまり関係なさそう?」なんて勝手な判断で検索結果を除外しないこと。

開いて全部きちんと読んでみてから、明らかに違うページは無視すれば良い。

文献を読む際は、そのページでターゲットとしているライブラリのバージョンや OS などの環境が、自分と同じかどうか確認すること。Mac 環境でのみ有効な対処法を Windows で試していたり、古いバージョンの文献で今となっては解決策にならない情報など、珠玉混在していることを念頭に置いて、いきなり鵜呑みにしないようにすること。その記事と自分の環境との差異を押さえておこう。

  • 読み飛ばさない
  • メモする

漏らさず読みながら、情報を整理していくのを忘れずに。

見つけた対処法はいきなり試さない

検索して何か対処法っぽいコードやコマンドが見つかっても、いきなり打ち込んで試さないこと。自分の環境に適さない誤った解決策だった場合、さらに余計な問題を生むことにもなりかねない。

解決策っぽい情報は、まずは検索結果の10件を読み終わるまで、メモ帳にでもキープしておく。全て読み終わったら、一番効果がありそうな手順から順に試してみる。その際、試した内容が間違っていた時に、元に戻せるようにしておくこと。元に戻せないような手順は試さないでおき、先輩上司に質問した方が良い。

公式サイトを読む

ググってそれっぽい答えが出てこなかった時も、出てきた時も、必ず公式サイトの API リファレンスやトラブルシューティングなどに目を通すことを忘れずに。

「機転を利かせる」とか、「応用して別の問題を解決する」とかいう能力は、インプット量が多くないとできない。まずはインプット量を増やそう。

それでもダメなら質問する準備を始める

こうした「発生事象 (エラーメッセージ) の内容把握」や「解決策の検索」は、5〜10分程度で終わるはずだし、終わらせる。それ以上は足りない自分の頭で考えても時間の無駄だ。それに、単に直接的な解法をググるだけでは解決できないような問題であることが多いので、総合的な知識力が乏しい人間には解決は難しいだろう。

新人エンジニアがこの記事の内容を意識しすぎてしまうと、自分で頑張りすぎて締め切りに間に合わないということもあり得えます。
そのため、新人エンジニアが自分で悩みすぎていないかを確認することも重要です。

そこで先輩や上司に質問しに行くワケだが、「何かエラーが出て〜、よく分かんないんですけど〜」なんて質問の仕方をした時にはカカト落としモンだ。相手が事象を把握し、解決策を導き出せるよう必要な情報をまとめて簡潔に共有するための準備をしよう。

人間ついつい「このぐらいは言わなくてもわかるでしょ」と話を省いてしまいがちですが、それは相手と文脈を共有できてることが前提です。
残念ながら、これからあなたが質問しようとしている相手はあなたと文脈を共有していませんので、しっかり整理して説明する必要があります。

先輩上司に質問する前にやること

質問する内容を整理する

これはつまり、「質問された側が答えを考えるために必要なこと」の裏返しである。何を提供すれば求める情報が返ってきそうか考えよう。

  • 目的 : 実現したいこと・期待値
    • まず「○○を△△にしたい」という目的を再度明らかにすること。
    • よくあるのが、その目的を果たすためには遭遇しているエラーや問題に向き合わなくても良い場合がある、ということ。例えば「while 文のループ処理を実装したらエラーが出た」という時に、「こういうエラーメッセージが出て、なんとかしたいんですけど…」と云われるが、よくよく実装しないといけない内容を聞いてみたら「そもそもループ必要なくね?」なんてことがあったりする。自分の現状が当初の目的からズレていないか、立ち位置をよくよく確認しよう。本当にその問題を解決する必要があるのか?
  • 何をして、どうなっているのか
    • 目的に対し、自分がしたことは何で、その結果どんなエラーメッセージが出たのか、ここを正確に伝える。
    • 「コード書いてみたんですけど何かエラーが出て」なんて発言からは何の情報も読み取れないのだ。「○○にするために Hoge ライブラリの fuga() メソッドを使ったんですけど、Invalid Type Exception というメッセージが出て、スタックトレースによると180行目の処理にエラーがある、と表示されています。でも原因が特定できないのです」と、必要な情報を正確に話さないといけない。「なんか」なんて絶対言うな。
    • 「こうしたいのだけど、こうなってしまう」とか、期待値との対比で説明する。
  • どんな対策を講じてみたか
    • その問題に対して自分が試したアプローチを共有する。この場合も、中途半端に話さず、試した内容を正確に伝えきる。
    • 書いたコードを見せて説明するのもいいが、それらは全て自分の口で説明できる状態にしておくこと。コードを見せたりするのはあくまで補足資料という位置づけ。自分が主体的に物事を把握して説明できる状態でないと、解決策を聞いても動けない。

これらをまとめたら、初めて席を立ち、先輩上司に質問しよう。

なお、先輩上司に質問する時は、以下のことに注意する。

  • メモ帳を持っていく。
    • こんな問題も解決できないヤツが、メモを取る用意もないまま質問しに行って、答えを暗記して自席に戻れるワケがない。メモできる道具を必ず用意しろ。
    • メモは体言止めや単語だけで書かずに、「○○を△△にする」と必ず文章で書く。体言止めや単語だけで書いたメモは、後で読み返した時に意味が分からなくなっていて、自分で勘違いしたりしやすい。間違えやすい事柄は最初から間違いが起きにくいやり方をとって回避すること。
  • 人の話を最後まで正確に聞く。
    • 「こうしたらどう?」という答えを聞き間違えたり、誤認識しないようにする。一発で理解したつもりになっても、本当に誤認識がないか、自分の言葉で言い直して確認する。
    • 「○○する、ということは、つまり fuga() メソッドの第2引数に false を設定する、ということでしょうか?」というように、相手が省略したり、抽象的に表現したものを、省略せず、具体的に言い直すことで、初めてお互いの認識に相違がないか確認できる。
  • これからやろうとすることを伝えてから自席に戻る。
    • 「○○を試してこういうエラーメッセージが出たら原因は××にある可能性が高い。もしコッチのエラーメッセージになるようなら、××ではなく△△を修正しないといけない」というように、いくつかの回答や手法を教えてもらった場合は特に。
    • 「では、初めに○○を試してみて、意図した結果が得られれば××を修正しようと思います。もしそれでダメだったら、次に△△を試してみようと思います。」「それでもうまくいかないときはまたご相談させてください」という風に、回答を聞いて自分がこれから起こそうとしているアクションを伝え直す。
    • 場合によっては「あ、ちょっと待って、いきなり△△の対処に移るのはマズいから…」とか、補足やフォローをもらえたりするし、認識誤りがないかの確認にもなる。
  • 試して上手くいった時は「○○の方法でうまくいきました」と一言報告する。
    • 上司としても「あれから詰まり続けていないか」が気がかりだし、スケジュール遅延に響いたら困るので、報告はこまめに。問題がない時も、問題がないことを報告する必要がある。

全般的に共通する心構え

以上、問題に遭遇した時にどのようにアプローチし、どのように人に頼れば良いかを話してきた。こうしたことは、言われなくても最初から出来る人か、どれだけ言われても一生できない人に二分されると思う。両者で決定的に違うのは、この一つの心構えがあるかないか、だと思う。

それはすなわち、見たものや聞いたものに自分の勝手な判断や推測を混ぜていないこと。事実と主観を明確に区別し、「自分はこう思うが、実際こうなっている」ということを常に正確に分析できているかどうかだ。

我の強いヤツや、あまりモノを知らない人間に限って、「自分はちゃんとやっているのに何故かこうなる」とか、「自分のコードに間違いはないはずなのに」とか言う。でも、99% はそいつ自身のやっていることが間違っているから問題が起こっている。

以下は立川談志の有名な言葉だが、エンジニアの問題解決に対する心構えとしても適用できるのではないかと思っている。

「よく覚えとけ。現実は正解なんだ。
時代が悪いの、世の中がおかしいと云ったところで仕方ない。
現実は事実だ。
そして現状を理解、分析してみろ。
そこにはきっと、何故そうなったかという原因があるんだ。
現状を認識して把握したら処理すりゃいいんだ。
その行動を起こせない奴を俺の基準で馬鹿と云う」

すなわち、「僕は悪くない」「合っているはずだ」などと言っても、エラーが出力されているなら、何かを変えて、その問題を解決しなきゃいけないのだ。

現状に対して自分の思いや主観は必要ない。正しく事実を事実として把握し、適切に処理することが求められる。

そのために意識しないといけないこと、エンジニアとしてやれないといけないことを語ってきた。ぜひともスムーズに、スマートに問題解決し、自分で自分の仕事を進めていけるように願っている。