Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

これから自習・ OJT をはじめる自チームの新人のため、問題解決に関する情報をまとめた

f:id:tbpg:20150514224634j:plain

概要

これから自習・ OJT をはじめる自チームの新人のため、問題解決に関する情報をまとめました

経緯

新人来襲

(๑•ั็ω•็ั๑)๓

プログラマの新人 が、私のチームに プログラマとして移動してくることになりそう です。
部署移動は確定していませんが、 彼はすでに先行して自習を始めているので、
彼の学習をレールに乗せるため に問題解決に関する簡単なまとめを作ることにしました。

実践的学習

基本的には 自学メイン で行ってもらい、必要なことは 業務中に彼のレベルにあわせたタスクを
割り当てることで実践から学び取ってもらう
予定です。
分からないことはメンターに質問してもらい、その場限りの解法としてではなく、
考え方として身につけてもらいます

ここでいうタスクは、研修のためのタスクではなく実際に 業務上必要となる実践的なタスク を割り当てます。
Pragmatic Study ですね。

下地作り

プログラマということもあり、ノーヒントで放置してしまうと 五里霧 になってしまうことが危惧されます。
そこで、 問題解決に関する考え方だけ先に教えておく ことで、
学習を加速させ、一つ一つの業務・技術・指導の意味を理解し、考える習慣を身につけてもらうことが狙いです。

問題解決

問題解決とは?

問題を発見し、解決策を練り、実行に移し、解決すること です。
システム開発に関わるひとつひとつの仕事は基本的に問題解決です。
システム開発に限った話ではないでしょうが、便宜上。)

与えられた設計書にそって作業的にプログラミングだけを
行っているケースもあるとは思いますが、
私のチームのメンバーに期待されるのは 「作業」ではなく「問題解決」 です。

※あくまで私のチームの話なので、現実で「作業」を行っている人を ディスる意図はありません

問題解決に必要なスキル

問題解決には以下のようなスキルが必要になります。

  • 問題を分割し、もっとも単純な単位に落とし込む
  • 論理的に物事を考える
  • 必要な情報を収集する
  • 仮説を立てる
  • 実行に移す
  • 結果を分析する

具体例

時系列で具体的な業務内容を例に説明します。

書籍販売 Web サービスプロジェクト

あなたの会社は書籍販売 Web サービスの開発を行っています。
Ruby on Rails 製のシステムで、サービス名は Kohmoto( コウモト ) です。
登場人物は 先輩の羽生さん と、 後輩で新人の橋本君 です。
橋本君のあだ名はハッシーです。
見た目は怖そうですが、根が明るく悪ノリに定評があります。
ふざけた態度とは裏腹に地頭はよさそうです。

現在、 ある書籍のレビュー欄が炎上 して収まりません。
サービス全体に大変な負荷がかかっていますし、サービスへの印象も悪くなってきています。
諸事情により、すぐにパフォーマンスを向上させることはできそうもありません。
そこで、 レビュー欄の有効無効を設定可能にする機能を追加することで、暫定対応する ことになりました。

※ユーザーのブロック機能とかあると思いますが、今回はこのストーリーで。

羽生先輩からの指示

羽生「橋本君、コウモトの レビュー欄に有効無効を設定する機能を追加して
羽生「詳細は Trello の 'コウモトの『炎上芸』封殺機能を追加' というカードに書いてあるよ」

f:id:tbpg:20150514224647p:plain

橋本「おいーっす、パイセン。かしこまりー」

ポイント

一般的に新人の場合、問題の抽出業務は担当せずに、
先輩が解決すべき問題を抽出して個別のタスクに落とし込んだ後に
タスクを割り当てられることが多いと思います。

明確化

橋本「パイセン!パイセン!」
羽生「なんだい?」
橋本「‘コウモト封殺' いつまでにやればいいっスカ?
羽生「来週末までだね。カードに追記しておいて」
橋本「うっス!追加するっス!」

f:id:tbpg:20150514224654p:plain

橋本「パイセン!パイセン!パイセン!パイセン!」
羽生「なんだい?(パイセン、多いな・・・)」
橋本「 なんで『炎上芸』封殺機能を追加するんすか?
羽生「いい質問だね。 (池上彰風に) ドヤッ! ( ・`ω・´) 」
羽生「ある書籍のレビュー欄が炎上して、サービスに負荷をかけているんだよ」
羽生「あと、サービス自体の心象も悪くなってしまっている」
橋本「イートゥ、ナットゥー!」
羽生「え?」
橋本「イートゥ、ナットゥー、Eat Natto、 食う納豆、納豆食う、なっとく・・・っス」
羽生「LTGM!」

LGTM
from lgtm.in

ポイント

橋本君は、 不明点を確認し、期日と問題の背景を理解しました
橋本君の良い点は、 タスクの背景にも気を配っているところ です。
タスクの目的を理解しないと、ただの作業になりかねません。
目的を理解していれば、場合によっては より良い解決案や改善を提案する ことも可能になります。

問題を解決するには問題が 明確になっている必要 があります。
ここで、タスクの説明を受ける際などには以下のことを注意する必要があります。

  • 目的を確認する
  • 優先度・期日を確認する
  • 不明点を確認する

当たり前の内容ですが、実際の 現場を見渡すとこれがきちんとできない人は意外と多い です。
新人であれば尚更です。
稀に非常に能力の高い新人の場合は、皆まで言わずとも把握してしまうこともありますが、
そういうケースは例外的です。

また、もともとタスク管理ツールにこれらが書き込まれている場合は確認不要です。
逆に自分が確認した内容は、あとで参照できるようにタスク管理ツールにも追記しておくとよいです。

これらの確認により、 問題を明確化 します。

細分化・調査

(      ゚д゚     )
      ↓
( ゚д゚ )゚д゚ )゚д゚ )゚д゚ )゚д゚ )

橋本「じゃ、モリモリッとやるっスかね」
橋本「・・・どうやって実現すればいいっスかね?」
橋本「分からないことを整理するっス!」

ものすごい形相で頭をかきむしりながら考え始めるハッシー

橋本 「うーん、まずは DB に炎上有無を判断するフラグを追加する」
橋本 「炎上有無の判断は システムでやるのか、手動でやるのか? あとでパイセンに聞くっスね」
橋本 「で、仕様はさておき、 DB に炎上有無を判断するフラグを追加する
橋本 「DB を管理してるのって誰っスかね?これも後で聞くっス」

羽生 .oO( こいつ頭の中丸聞こえだな。まぁ、分かりやすくていいな。 )

橋本 「さらに DB に保存した炎上フラグを元に、 レビュー機能の有効無効を切り替える
橋本 「Ruby on Rails は研修でおおまかに覚えたっスけど、有効無効の切り替え方法が分からないっス」
橋本 「分からないことがあれば ググれカス 。これ、 我が家の家訓 っス」

┌──────────────────┬──┐
│フォーム 有効無効 切り替え     │検索│
└──────────────────┴──┘

バンバンバン
バンバンバンバン゙ン バンバン
(∩`・ω・)バンバンバンバン
_/_ミつ/ ̄ ̄ ̄/
  \/___/ ̄

橋本 「見つからないっス」
橋本「フラグの設定方法の仕様、DB管理者の所在、レビュー機能の有効無効機能の実装方法」
橋本「この三巨頭をパイセンに根掘り葉掘りヒアリングッー( エドはるみのポーズ )、するっスね」

羽生 .oO( ぷっ ) ※笑いをこらえる羽生先輩

ポイント

レビュー欄の有効無効を切り替える機能 という比較的大きな粒度のタスクの実現方法を
細分化し、一つ一つに関して実現方法を考え・調査しています。
理解しやすい 小さな単位にタスクを分割することは良い手法 です。

作業中に発生した 不明点を整理し、ヒアリングする準備をしている点 も良いです。

以下略

尻切れトンボっぽいですが、具体例はここまで。

学習初期におすすめの書籍

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法