I/O BLOG;

最近、5年目にして同じグループに後輩ができた。社会人なりたての、新人さんなのでいろいろ教えている。教えるときに気をつけることを書いていく。他の人が、どんな風に後輩と仕事をしているかも、できれば知りたい。良ければコメントがほしい。

みんな初めはできない

なんでこれぐらいできないんだろうって思っちゃうけど、誰でも最初はできないもの。自分もそうだったし。長い目でみるのがよい。

抜かれる危険性

自分が頑張って教えてきた人と、ずっと一緒にやっていけるのかはわからない。別の仕事にとられるかもしれない。そうなると頑張って育ててきた意味がない。他のところで能力を発揮してくれるのであれば、意味はあるけど。それでも悲しい。悲しいがこれは仕方ない。それは考えずに進めたほうがいいだろう。

指示の曖昧さをなくす

新人さんには、曖昧な指示は良くない。先輩や上司の指示で良くないのは、クイズ形式なってしまうことだと思う。指示が曖昧すぎて、正解するまで答えを教えてくれないみたいなのは、やられるとつらい。多分、そういうのは指示する側の甘えだと思う。これぐらいわかってくれと投げやりになっているのかも。でも、そういうのが合う人もいるだろう。それは人をみて判断するけど、あんまりそういう人はいないと思う。

指示の細かさの調整

最初一度ぐらいはどの程度わかってるかわからないので、同僚に依頼するぐらいのラフさで出してみる。そのあと途中経過覗いたり、一回目のレビューの時の成果物の様子をみてどの程度まで指示が必要か判断する。

例えば、「ここの文言わかりにくいから直して」と言って、直してきたのがわかってない感じの内容だと、「ここの文言をこう直して」という風に考えなくてもできるレベルまで落としこんだ指示を出す。それの狙いはこう直すんだとわかってもらうことにある。それを繰り返していくとそのうちパターンが見えてくるようになるだろうと思っている。実践 -> 評価 -> 実践 -> 評価の繰り返しをしているつもり。あと、ポイントポイントではこれは、つまりこういうことだよっていうパターン自体も教える。能力が足りていなければ、本とか紹介する。

つまり、

実践させる
評価する
一般化したルールを伝達する

この３つを繰り返す。

仕事の手順を明確に伝える

仕事は以下みたいな方法でやってもらっている。

仕事を細かいタスク落としこむ
スケジューリングする
実行する
実績と予定を見比べて、スケジュールを修正する

進め方については、自分のやり方もあるだろうけど、基本的に

仕事の全容を把握
どれぐらいで終わるか予定を立てる
実行してみて、実績から予定を調整
実績は記録しておいて、次の見積もりの参考にする。

っていうルーチンができるようになるまでは指示を出したい。繰り返すと、ちょっとずつ精度が上がってくると思う。のでやってもらっている。だいたい初めのうちは見積もってたりよりも2,3倍おおくの時間がかかったりする。求められてる成果物の品質にたどり着く大変さとか、隠れタスクとか最初は読めないからね。

これは多分、これぐらいかかるよ。みたいなことはあんまり言わない。そこはできるようになってほしい部分なので、考えてもらう。実績が答えを出してくれる。

やりすぎ？

どこまで考えさせるのか、難しい。もしかしたらマイクロマネージメントしすぎかもしれない。それに、これは僕のエゴなのかもしれない。

だけども、大事なことは伝えていきたいとも思っている。葛藤がある。バランスをうまく取りたい。

報告はあんまりいらない

基本的に成果物は GitHub 上で管理してるから、とくに新人さんに「できたらみせて。」とか言わなくても、いつでも進捗とか方向性確認できてるので便利。( 生煮えプルリクエストしてもらってる ) 終わらないと持ってこないとかあるあるなので、そういうの防げる。

僕は在宅、新人さんは会社

課長は別にいるので、なにかあった時はそっち相談してもらう。 Slack と GitHub で淡々とやり取りして、仕事進められて快適。

レビューの細かさ

淡々と成果物をレビューする。レビューはあまり妥協していないので、やられている方はもしかしたら辛いかもしれない。定期的に今のやり方でつらくないか本人に確認している。その結果でレビューの細かさを調整する。辛い時にはつらいと言ってもらえる関係性を築いておく。

同じことを指摘する

なんどか同じ指摘をすることがある。つらいけど、頑張って同じように指摘してる。前も言ったでしょ的なことはあまり言わないようにしている。一度でできるようになったらすごい。でも面倒なので、一度指摘した時のコメントのURLを貼ったりもしている。

機械的に指摘したい

なるべく、自動的にチェックする仕組み(CIとか) を作りたい。機械的にできることは機械に任せたい。

できるようになるまでは、ちょっと窮屈だけどセルフチェックシートを作って、簡単な指摘は無いように、レビューのする前に自分でチェックしてからレビュー依頼かけてもらうようにもしてる。

ゲーミフィケーションしてもいいかもしれない。

なんでこの仕事が必要なのかきちんと説明する

最初のうちは、仕事をこなすことに夢中になってしまう。手段ばかりに気を取られて、目的を見失う。そうするとなんでこんな内容なんだろう？っていう成果物が出て来る。こうふうに直して、という指摘する手間がまた一つ増えてしまう。だから今やってる仕事がどういうことに繋がるのかわかったうえでやってもらう。目的は手段を最適化させる。

例えばドキュメントを書く仕事とか

例えばドキュメントを書く仕事なんかがあった場合、当たり前なんだけど、読んで欲しい人がいるからドキュメントを書いてる。だから、どんな人がどんな状況で読むのか想定しながら、ドキュメントを書く必要がある。それを忘れて、ただドキュメントを書くと、ちぐはぐな内容になる。

時系列がおかしかったり、必要な情報がなかったり。

たまに僕も目的を伝え忘れて反省する時がある。そこは丁寧にやっていきたい。

一度にたくさん教えない

なにか「こうだよ」って教えるときは、一度にあまりたくさん教えないようにしている。いっぺんにたくさん言われてもわからない。消化できたかなって思ったら新しいこと教える。

型を教える

書いてて気づいたのは、僕は型を教えているんだと思う。型をうまくできるようになったら、それを基本に自分なりに発展させてほしいと思う。

あとこの会社じゃなくても、他のところでも活躍できるようなことをなるべく教えたい。

仕事の型

実践して実績を集める -> パターン化する -> 展開する

というのが僕の考える仕事の型。まずは仕事を進める。たいだいの人はこの段階で終わってしまう。最初はこれだけでも精一杯だけど。次に実績をふりかってみて、パターンがないか確認する。パターンを見つけたら、ドキュメントにしたり発表したりして、他の人(未来の自分)が使えるように記録を残す。

パターンを見つけるところが大変だと思う。ここは頭の良さがかかっていると思う。あと実績をふりかえれるように記録を残しておくことも忘れない。だから Slack とか GitHub 使って、自然と記録を残せるようにしている。

先輩と後輩の認知コストのちがい

極端に優秀な後輩でもないかぎり、お互いの関係性上認知コストの違いがでてくる。
後輩が認知コストを多く払うことの方が多いと思う。
それは後輩の方が先輩の意見を理解する機会が多いということ。逆に先輩は後輩からの意見について必死になって頭をつかうことは少ない。
先輩からすると、それは楽で気持ちがいいことなんだけど、それに乗じて好き勝手にはやらない。あくまでも真摯に対応する。

教えることでのメリット

ここまで書いてきたど、自分のメンタルもいろいろある。

あまりにも自分がわかりきってることを人に教えることは時間の無駄のように思える。でも、なんとか自分にとってのメリットを絞り出したい。

ノウハウを言語化する練習

自分の頭の中にあるモノを言語化するのはなかなか難しい。人に理解できるモデルに直さないといけないから。一度モデルができあがると、いろんな場面ですぐに言語化できるで便利ではある。

ちゃんと教えるために勉強する

実際に教えようとすると、自分の曖昧さに気付く時がある。こういう時には勉強する動機になる。

やれる人を増やす

ノウハウを自分だけの知識に閉じ込めておくのは、スケールしない。一人でやれることは少ない。一人でできないことをやるために、会社はある。人に伝えて、やれる人を増やすのは大事なことだ。そうすると、もしかすると、自分のやりたいことができるようになるかもしれない。

周りの技術レベル

人に教えることは多くなったけど、教わることが減ってきた。自分が成長してしまったのか、周りのレベルに追いついてきたように感じる。昔ほど飛び抜けた人がいなくなってしまったようにも感じる。今の状態で成長効率がいいのか疑問に思い始めている。人に教えるために勉強する的なことを書いたけど、それよりもできる人と働いた方が効率いい気がする。

今期の総会を持って、JavaKüche の副会長の役目を無事終え、普通の役員に戻りました。

最近では、体の調子があまり良くなく、コミュニティ活動も休みがちになっています。
そこで、より副会長というポジションを最大限に利用できる人が務めた方がいいと思い、辞任することにしました。
次の副会長は新垣さんにお願いすることになりました。よろしくお願いします。

2年間

就任しましたという記事がちょうど2年前らしいので、2年間ぐらいは副会長を務めていたみたいです。

10年続けるための代謝と下支え

JavaKüche というコミュニティは設立から10年経っています。
有志が集まって運営するコミュニティとしては、長く続いてる方だと思います。
長く続ける秘訣は運営陣の代謝が、ポイントだと思ってます。

代謝によるモチベーション維持

コミュニティでは、その中心人物のモチベーションが、活動の内容に大きく影響します。
それはつまり、その人のモチベーションがなくなれば、コミュニティの活動も自然と止まってしまうことになります。
それなので JavaKüche はより若い人へ、代替わりをしながら進んできました。現会長は三代目になります。
人が変わる度に新たなモチベーションが生まれ、ここまで継続してこれたのだと思います。

前世代の下支え

前任の方が次の運営陣のために、顧問や 事務局 という立場で残るような体制をとっています。
バックグラウンドがしっかりしていることで、運営陣が安心して活動することが出来るようになっています。

僕のやること

次の代謝をするために、本格的に後継者探しを始めようと思います。コミュニティ運営の魅力を伝えながら、意欲のある人を探していきたいと思います。
また次の人のために、コミュニティ周辺の整備をしたいと思っています。例えば、これまでのコミュニティ活動のノウハウを集約してドキュメントにまとめるなどです。

JavaKüche の今後

今期から、年間スポンサーを獲得しました。それによって、今後出来ることの幅が広がっていくと思います。
どうか今後とも、沖縄のプログラマコミュニティ JavaKüche をよろしくお願いします。

まとめ

コミュニティはいいぞ。