背景
「コーディング作業に入ったお仕事」のリーダーになった時の経験。正確には「リーダー」という役職ではなかったけれども、役割的には指導的な立場だった。メンターというのかな? 新人部下と書いたけれども、正しくはプログラミングの基本を一応勉強した同期と一年下の後輩だった。その開発プロジェクトは、その後一か月位いでキャンセルされてしまったので、メンターを務めた期間もほんの僅かだった。
とはいえ、メンターとして指導をする機会に恵まれたことは確かで、その中で頭を悩ませた。自分なりに教育方法にも工夫した。その話を、記事にしてみる。
基本は PDCA とコミュニケーション
PDCAサイクルは、Plan (計画)・Do (実行)・Check (評価)・Act (改善) の頭文字を取ったもの。会社の研修では、報連相 (報告・連絡・相談) と共に教えられることが多い。
PDCA は仕事をする上で基本的な概念なのだけれども、職場で PDCA を実践している人を見たことがほとんどなかった。なので、まず PDCA を徹底させることを第一にした。
また、各段階においてコミュニケーションを多く取ることを心がけた。
TiDD
まず、プログラムの大まかな目的と設計を説明した。具体的には (ぼくが作ってた) UML 図のユースケース図とクラス図・アクティビティ図を見せた。で、全体像を掴んでもらったところで、任せる仕事の話に移った。
ここの機能をやって欲しい、と伝える。
そしたら、その機能を作るために必要な作業を挙げてゆく。これは一人任せにせず、一緒にやった。最初なので大まかな作業分割しか出来ないけれども、「プラン」を作る流れを掴んでもらうのが目的。
更に、チケット駆動開発 (TiDD) を覚えてもらった。ぼくは当時 Redmine を使っていたので、Redmine の操作方法を教えて、チケットを発行する方法を教えた。
分割した作業項目を、まずぼくがチケットに落としこんでゆく。彼にはその作業工程を見てもらう。次に彼にチケットを作ってもらい、その様子をぼくが見る。気を付けたのは、チケットの目的を教えることだった。つまり、一つ一つのチケットが「PDCA」の Plan に当たると伝えた。このプランに沿って作業 (Do) するのだと。
そのためにチケットの題名をどう書くべきかを教えた。後から読み返して、「作業のプラン」が分かるように書くよう気を付けた。例えば、「○○部の設計を行なう」といったコーディング以外のチケットも書かせたし、「コーディングを行なう」というチケット名は止めさせて、具体的に「DB と接続するコードを書く」とか「取り出したデータを確認するテスト・コードを書く」とかそういった具合。
一般に TiDD ではチケットの粒度を 1〜2 日で終わる程度としているが、ぼくの場合は一つのコミットに対して一つのチケットを作らせた。コミットも一機能につき一回として、その一機能も最小限の機能にした。従って、チケットの粒度は 1 日に 3〜10 ほどだったと思う。
何故、こんなに粒度を小さくしたかというと、新人はプラグラマーのプロではなかったから。プログラムする部署に配置されたからって、プログラムが必ずしも好きではなかった (一人目の場合)。プログラムは好きでも、努力が空回りしてスパゲッティーな長いコードを書いた (二人目の場合)。例外な人はいるけれども、ぼくの許についた人達は「例外な人」じゃあなかった。
一人目には沢山のチケットをこなしてもらい、その一つ一つをちゃんと褒めた。短いコーディングなので、ミスも少ない。必然、褒める回数が増える。「Good」でも「OK」でも、「いい感じに進んでるね」でも何でも良いので、褒めることを前提にチケットも作った。「出来て当然」という態度は絶対に取らない様にした。そういう態度は、プログラミングが好きになって、コーディング技術が上がってから取れば良いと思った。プログラミングを楽しいと思う様に願った。好きになれば、スキルは自然と伸びるから。
二人目は、チケットを守らせることに気を使った。せっかくチケットを細かく区切っても、彼は「それ以上」をやろうとしてしまう。その頑張りというか、前向きな姿勢は素晴らしいのだけど、コーディング技術が追いついていない。結果、手戻り作業が増える。コーディングのダメ出しが増える。これじゃあ、彼のやる気を削ぐばかりになってしまう。やる気はあるので、もったいない。だから、チケット 1 つの粒度を小さくして、チケットに書いてあること以外をやらせない様にした。時々、チケット以外のコードも書いていたけれども、戻す様に言ったこともある。最初は大変だったけど、最後の方は一機能一コミットでバグの少ないコーディングになっていたので良かったと安堵した。
最初のチケット作成は、ほぼ付きっきり。以降、新しい機能追加のたびに簡単なミーティングで「やるべきこと」を洗い出して、チケット作成は任せる様に少しずつシフトさせた。
なお、毎朝のミーティングで「今日、どのチケットをやるか」の確認だけは日課にした。一日の作業見積りが分かり易くなったし、(緊急会議などで時間が取れないトラブルでもない限り) チケットが終わらない場合は、そこにトラブルの元が潜んでいることが自然と分かったので、悪くない日課だった。時間は二、三分で切り上げる程度。
UML 図
プログラム・ロジックが難しくなったら、UML のアクティビティ図を描いてもらった。描いた図を見て二人で協議。ああでもない、こうでもない。ここの変数は要らない。このチェックどうしよう。こんなアイデアどうだろう。ロジックが難しくなればなるほど、アクティビティ図を複数回描き直してもらった。
アクティビティ図における「一つのアクティビティ」が「一つのチケット」にほぼ対応した。
コードの流れ、チケットの作成 (粒度・取りかかる順番) などが明解になるので、時間をかける価値はあった。
ペア・プログラミング
最初はプログラミングの流れも分かっていないので、ペア・プログラミングをやってみた。
初日にやったこと: チケットのステータスを「担当」にして、コーディングを行ない、コミット・ログを日本語で書いて、実際にコミットする。TiDD の流れと SCM の使い方、そしてコミット・ログの書き方に重点を置いた。
Redmine では、コミットが行なわれると自動的にそのチケットのステータスを「解決」にしてくれる。そして、チケットのコメント欄にコミット・ログが表示される。ぼくは、このコミット・ログの書き方が一番大変だと思う。何故、このコミットを行なったのか? どういう変更を行なったのか? 簡素に、しかし必要な情報は省かずに書く例を見せた。
最初の何日かは大変だった。ログを修正してもらう。自分でログを書く。ログを書いてもらう。ペア・プログラミングで、その繰り返し。完璧ばかりを求めても時間とやる気がなくなるので、最初は好ましくないログでも、そのままコミットさせた。次第に文章は良くなって行く。
ペア・プログラミングは初日以外にも行なった。タイミングは、コーディングが大変そうな時。チケットを見て、先にこのチケットは大変そうだと分かる時もある。その時は、朝のうちにこのチケットはペア・プログラミングでやろう、と声をかけた。あと、ブラリとこちらから声をかけて無駄話をする。その時、コーディングで躓いてないかさり気なく聞く。苦戦している様なら、ペア・プログラミングをやろうともちかけた。相手側からペア・プログラミングを持ちかけられた記憶はほとんどない。自分から言ってみないとダメみたい。
ペア・プログラミングすると、コーディング・スタイルの悪い所も指摘できるし、バグの温床も取り除きやすい。こういうのって、コミットされた後のコードに対して指摘・バグ取りすると、お互い気まずいので、ペア・プログラミングの機会は重宝する。あと、自分のやり方も学んでもらえるのも良い。特に変数の命名方法なんかは、自分でコードを書きながら説明すると、相手の頭に入りやすかった様に思う。
ただ一言。ペア・プログラミングはすごく疲れる。相手が成長しているのを感じられるから面白いけれども、一日に何時間もやれるもんじゃないね。
まとめ
新人プログラマーを教える立場に立ってやったことをまとめると、「PDCA サイクルを回すこと」に尽きる。その手段に TiDD (Redmine) を使った。TiDD の補助に UML 図とペア・プログラミングを活用した。潤滑油はコミュニケーション。
批判
ぼくのやり方に対して批判もあった。ぼく自身のプログラミング時間が大幅に削れている。教育に時間を割き過ぎている。せっぱつまった状況で、悠長に教育しているのはナンセンス。実際、ぼくのプロジェクトは「せっぱつまった状況」で消えてしまう。
自分の時間が削られた分は残業で何とかするとして、ぼくは、教育は重要だと思った。世の中には、指示する前に仕事を見つけて動く人もいる。指示を受けて、十全にこなす人もいる。課題を与えられて、成長する人もいる。叱られて、伸びる人もいる。でも、そうじゃない人もいる。批判した人達は、大量の課題や叱責を与えて伸ばそうとしていたけれども、それがダメで彼らはぼくの許に来た。彼らは、ちゃんと時間をかけなければ育たないと思ったし、せっぱつまった状況だから戦力が増えるように育ってもらわないといけないと思った。
ほんの一か月ちょっとだったけれども、彼らが、ぼくと一緒に仕事をして良かったと思ってくれてることを願う。
関連エントリー