0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初部下をもった上司初心者が教育で気をつけたこと

0
Posted at

3行

  • 心理的安全性を確保する
  • 直接答えは教えず、解決方法を考えさせる
  • LLMに依存させない

導入

おはようございます。
窓を開けて風を受けながら日向ぼっこするのが最近の楽しみ。デブです。
春はいい。

さて本編ですが約一年半ほど前、人生初の部下ができ、その部下は立派になって先日私の下から巣立っていきました。
業界未経験ではありましたが頭も素行も良い方だったので特に苦労をかけられたとかは一切なく、なんだったら「上司として舐められてはいけない」ということで体裁を保つことの方がよっぽど苦労しました。いや本当に。
あとは優秀な若者がスポイルされることだけは絶対に避けなければならないので、どうにかこうにか無い知恵を絞ってあれやこれやと頑張りました。

というわけで私の「上司として体裁を保つために気をつけたこと」と「新人教育に際して工夫した点」をつらつらと垂れ流します。

コミュニケーション

心理的安全性の確保

複数人が関わる仕事において一番大事なこと、それは報連相だと私は考えています。
それについていつぞやの記事において、私は以下の主張をしました。

本来は上司側が「気軽に『報告・連絡・相談』出来る環境や雰囲気を作る」べきです。
包含的にはなりますがよく言われる言い方をすると「心理的安全性を高めるべき」というところですかね。

心理的安全性についてググるとあちこちで色々な説明がありますが、私は「生産的な会話がいつでも出来ること。好悪などの感情が業務上におけるコミュニケーションの阻害とならないこと」と解釈しています。
よしんばお互いに「こいつ苦手なんだよなあ」と思っていたとしても、それがコミュニケーションの阻害とならず、いつでも業務上必要な会話が出来る状態であればさほど問題はないと思っています。
あとは「気まずくてお話しづらい」みたいな状況もなくしたいです。

そんな感じなのでとにかく「何かあったら報告してもらう」下地をつくるために「心理的安全性を高める」という方向性で工夫をしました。

話しかけやすい雰囲気を作る

報告してもらうためには会話は必須ですので、まずその敷居を下げるために以下のことを意識しました。

  • 雑談を交える
  • ある程度(ポジティブな方向で)自己開示を行う

フルリモートの現場だったので通話をするたび、冒頭あるいは相談終わりに近況を話したりしてました。
「どこにお出かけした」「アマゾンのセールで何を買った」「最近買ったアレが便利だった」「久しぶりに音ゲーしたら腕が爆発した」「うちのわんちゃんねこちゃんがどうたら」
だの他愛もない内容です。
また話の流れで過去にプライベートや業務でこんな失敗をした、それをどうやってリカバリーした/してもらったなどの話もよくしました。
こうすることで会話の敷居を下げ、いつでも公私問わずいろんな話が出来る雰囲気を作ろうと試みました。
結果として、しばらくすると部下の方からも自発的に「私も最近~」などの話してくれるようになり、ある程度は仲良くなれたかなと自惚れています。

まあ一番の要因はお互い共通のゲームにドハマリしていた、ということですが。

業務について何かあったとき、部下の口から考えを聞くこと

話しかけやすくして入口は広げました。
次は「ちゃんとあなたの意見を聞きますよ」という姿勢を見せる工夫です。
どんなにお話が出来ても「仕事は俺の言うことだけ聞いておけばいい」というスタンスでは意味がありません。

業務については何だかんだ言っても所詮は未経験なので、最初は雑務レベルのものしか頼めません。
それすらもまあまあ苦労するのですが、普段から「何かあったらいつでも相談していいからね」と言っていたのも功を奏して何かにつまづいたときにはすぐに頼ってくれました。
その際に軌道修正やら指摘やらをするときに「これ、どういう判断でこの方法にしたの?」という質問を投げることを意識してやっていました
ついでに「怒ってるとかではなく、ちゃんと意図聞いておいた方がアドバイスしやすいから」ということも一緒に伝えておきます。
まあこれ心理的云々以前に「自分の考えを言語化させる」「ちゃんと根拠をもって行動させる」みたいな基本的教育ではありますがね。

「目の前のことだけでなく、ちゃんと意図を聞いてくれる」=>「しっかりと部下の話を聞く」という雰囲気を作るための工夫です。
ちゃんと話を聞こうとしない奴に深いことを話そうとは思えないですからね。

ミスや失敗は笑って流し、改善策を提案する

人が他人に話したくないこと、その筆頭は自分の失敗やらミスやらでしょう。
でも業務において真っ先に報告して欲しいのってこういうことなんですよね。
リカバリーやダメージコントロールは早ければ早いほど良いので。

なので当たり前と言えば当たり前なのですがミスについてはよほどのことがない限り「まあよくあること」として、「どう対処するか」「次からどう防ぐか」ということに主眼をおいて話していました

具体的なことを言うとあるときに「なんかこれ動かないんですけどどう調べてもよく分からなくて……」という相談をされた際に秒でタイポに気付いて
「部下さん、ここなんて書いてます?」
「えーと、あっ」
「(大笑い)まあよくあることなんで、次からはコピペしましょうか」
という感じですね。

またまあまあアレなミスや認識の齟齬があってそもそもの方向性が違ってた、みたいなときも、
「(リカバリー策を話し合ったあとに)この段階で気づいて修正出来てよかったです。次からはお互い◯◯しましょう」
というパターンも何度かありました。

こんな感じで何かあったときにも報告してもらえるように「起きてしまったことは仕方ないから未来のことを考えよう」というスタンスでいました。
ある意味一番大事な気はしますが、逆に工夫したというわけではなく考えてみたらこうだったよな、って感じです。
ミスしない人間なんていないんですし、私自身これまで何度もお尻拭いてもらってますからね。

色々言いましたが、結果的に私みたいな笑えないレベルのミスをしなかった、という言い方の方が適切です。

技術者としての教育

自身の作業能力を自覚させる

現在の現場は基本的にはお客さんから何らかの目的をもらい、それについてコネコネしたり実装したりする業務です。
私一人であればスケジュールは立てやすく、というかぶっちゃけ私一人でやった方が早いですし楽ですが、そういうわけにもいきません。
部下とタスクを分け合う必要が出てきますが、最初は部下がどれだけの知識や処理能力を持っているか分からないので指示が出しづらいです。

そこで担当させるタスクを段階別に分割して小タスクとして切り出し、いつまでにその小タスクが出来るかの期限を部下自身に決めさせました
作業の見積もり力を鍛えさせるためにやっていたのですが、案の定最初の方はまあまあオーバーします。
「上手くいったらこれくらいで終わる」という感覚で時間を申告していたので単純に思ったより進まない、予期せぬところで躓いたなどよくある理由です。ついでにお互いの確認不足でそもそもの要件を勘違いしていたので作り直しということも。
何度か繰り返していると余裕を持った時間の申告だったり、躓きそうなところを事前に質問するなどオーバーすることが少なくなってきたので少しずつタスクの分解度を粗くしていって数ヵ月経つ頃には安心してタスクを任せられるようになりました。

なおデッドラインが近く間に合うか怪しい、あるいは無理という場面もありました。
その場合は裏で私の方で同じ作業をやってお客さんに提出して、その後はそれを参考にしてもう少し煮詰めさせたりしてちゃんと遂行させました。

指導方法

指導、と言っても業務などの最中に発生した疑問や問題をどう解決させたか、という方が正しいですかね。
ともあれ上記で振ったタスクをこなす際に問題が浮き彫りになったり、どうしたら良いか分からない部分が出てきます。
そのときにどう対応したかと言うと、

「調べろ」

要約するとこの一言です。
とはいえ流石に突き放しているわけではなく、見えている箇所から少しずつ、

「ここどういうことだと思う?」
「分かんないなら調べる」
「調べたこと踏まえた上で、もう一回聞くけどここどういうことだと思う?」
「じゃあどうすれば良いと思う?」
「本当?ここ見てみ」or「じゃあそれを実現するには?」
「はい調べる」

といった感じで私自身が行う解決方法をなぞらせるようにヒントを与えて問題に向き合ってもらってました。

理屈を理解させる

そういった感じでやらせていると、例えばコードを書くようなタスクで「これどこ参考にした?」案件がたまに発生します。
間違っている、というわけではなく「現時点でこの方法を自力で思いついたとは考えにくい」みたいな感じです。
このときに私が「じゃあここ詳細に説明して」と言うと「えっとぉ……」みたいな場面があったわけです。

当たり前ですが「動けばいい」というものではないので、その場ですぐ調べさせてちゃんと説明出来るようにさせていました。

あとはちょっと古かったり(私の考える)ベストプラクティスではないなと思うこともあったので、その際にはアドバイスという体で教えてました。
まあ勿論よくよく調べると私の勉強不足だったりする場合もあったわけですが、それはそれで私の勉強になったのでヨシ!()

一次ソース絶対主義

上述の通り、部下自身に調べさせることをメインにタスクをやらせていましたがその際には「必ず一次ソース、サービスであれば公式ページ、ライブラリであれば公式リファレンスを確認しろ」と言い続け、「で、これはどこに書いてる?」という確認をくどいほどやってきました。
また、資料作成の際にも一次ソースを引用元として記載させたり、私の方からもフィードバックや説明時に一次ソースを画面共有しながら話したりしていました。

一次ソースの重要さはここでは割愛しますが、この辺りは意識して染み込ませていました。
勿論二次ソースというか第三者の記事なんかも参考になるんですが、ちゃんと基礎を固めようとしたらやはり一次ソースは欠かせません。

動作確認と環境差異の考慮

実装において一次ソースと同じくらい大事なのは動作確認です。
これは当たり前と言えば当たり前なのですが「動作確認は必ずしろ」と口酸っぱく言い続けてました。
同時に「異なる環境になったらもう一度動作確認しろ」もセットです。

動作確認の重要性についても割愛しますが、経験が浅い頃は「書かれたとおりにやれば大丈夫っしょ」と高を括って動作確認がおざなりになるものです。実際面倒ですし。
また同様に「あっちで動いたしこっちでも動くっしょ」と以下略。

大抵の場合は「たまたまその環境ではその設定でやれただけ」であることが多いので必ず動作確認はすべきと説いていました。
案の定「あっちでは動くがこっちでは上手く行かない」が多発したので部下も身をもって経験してくれたと思います。

アウトプット

っていう感じのことをやらせたうえで、度々アウトプットさせてました。
具体的には業務上どうしても待ちの時間が発生するのでそのときに課題を与えて取り組ませ、フィードバックと修正を繰り返す。このプロセス及びそのなかでの気づきなどを記事として起こさせていました。

まあ狙いはいくつかありますが、最大の目的は転職時のポートフォリオ。
次点でライティング能力を養うため、という辺りです。
ある程度は添削も出来るので添削もしました。まあ文章に正解なんかないのでアレですが本人的にはある程度納得してたっぽいので多分良かったと思う。うん、多分。

実際の転職で役に立ったかは分かりませんが、ないよりは良かったものと信じたいですね。

LLMとの向き合い方

さて話は大きく変わりますが、ここ数年でIT業界ではブレイクスルーあるいはパラダイムシフトと呼ぶべき環境の激変が起きています。こと下流においてはそれは顕著です。
皆様ご存知生成AI、そのなかでもLLMの台頭と目覚ましい進化です。

個人的には生成AI全般について「便利は便利だが現代人類の承認欲求や怠惰、悪意が大きすぎて危険過ぎる。出てくるのが数千年遅かった」と皮肉めいた感想を抱くくらいにはどちらかと言うと人類に対してアンチ寄りです。
お気持ち表明はこの辺にしておくとして、誰がどう思おうと今後技術者としてLLMと関わらないという選択肢はありえません

セキュリティガッチガチの監獄スタンドアロンめいた環境など使えない現場はありますが、工学系など物理的技術の専門性が高く替えの効きづらい希少人材でない限りLLMに触れない理由はないでしょう。(アメリカ基準で言う本物の【エンジニア】くらい)

そこで私としては一息で言うなら「LLMに頼るな。LLMはただの道具の一つ。LLMがなくても仕事が出来るようになれ」というスタンスで、それを元にLLMの使い方を示しました。

具体的には、

  • 鵜呑みにするな
    • 特に知識系や数字に関しては半分嘘でもう半分は作り話くらいに思え
    • 必ず一次ソースないし複数ソースで確証を取れ(所謂こたつ記事は除外)
    • 検索ワードの当たりをつける程度の温度感で使え
  • コード系は必ず動作確認をしろ
    • そして必ずリファレンス等を確認して、どういう挙動を起こすか説明出来るようにしろ

という辺りです。
詳しく書くとそれだけで記事に出来ちゃうので割愛しますが、原理的に出力物は文章として成立する確率が高いという程度のものであって内容が正しいものとは限りません。
文脈を読む力は強いのでコーディングとは相性がいいんですけど。

まあ部下はあまりLLMに頼らないで地力を伸ばそうとしていました。
それはそれで個人的には大変好ましく思いますが、便利なのは間違いないので「使うならこういう使い方の方がいいと思うよ」という感じでアドバイスはしましたけども。

「使えない状況になっても問題ない」とは「扱う能力がなくても問題ない」ということではないですからね。
頼ってもいいが依存はするな、って感じですかね。

その他

偉いと思ったことはすぐに口に出す

最後に他者への評価の話をします。
意識してやったことなのですが、「〇〇さんの〇〇なとこすごいですよね」という褒め言葉は意識して言うようにしていました。
美点を口に出して自分達も見習いたいね、という感じです。

普段の私は内心で「かっこええ」と思うだけで、だんまりです。
そういったことを意識的に口に出すことで「いい部分を見習ってね」というアドバイス、というべきかお願いというべきか、まあその辺りの狙いになります。

また同じように部下がこちらの想定を上回った対処をした、あるいは結果を出したときには「偉い!」と口に出して褒めてました。
その際には「何が出来たから偉い」というわけではなく「自発的に改善に取り組んだこと」を中心に褒めてました。

陰口をいうときにはフォローを必ず入れる

褒めることもあれば貶すこともあります。
小さな不満もあれば生理的に無理なことまでグラデーションはありつつも良くない感情を持つことは当たり前です。人間だもの。
そりゃ人の悪口陰口は他人に言わない方がいいわけですが、悲しいかな人間は共通敵がいると結束が強まるものです。
いなけりゃいないで内部に敵を作り始めるし

けどもやはりそこは社会人っぽく振る舞おうとしているオタク
子供みたいに【素敵な言葉】とか【素敵な言葉】とかは言えないので、

  • 良い悪いではなく価値観の違い
  • 私は気に入らないけど、あの人にはあの人の言い分や理由があるはず
  • 見方を変えればこういう擁護も出来る

と言った「これってわたしの感想ですからね?」っていうスタンスです。
あとは冗談めかして心の中の京都人を出してみたり、兎にも角にもただ悪口だけで終わらせないように意識しました。
まあ悪口しか出てこない状況もそれなりにありましたが

おわりに

と言った感じで初めての部下に対して色々考えて工夫して接しました。
対人能力は全く自信がなく、何度も失敗してきましたのでなかなか不安でした。
目標としては「こんな上司嫌だ」と思われなければ成功、くらいでしたが結果としてはそれよりは上手くいったかなと思います。

とはいえあくまで「たまたま気の合う人が部下として来てくれた」だけなのでこれで「おれは良い上司」と驕らないように気を引き締めなければなりません。

少し前から入れ替わりで新しい部下が来てくれましたが、前の部下にやった良かったことが新しい部下にとっても良いこととは限らないのでまた初心に戻って考えつつ、本人とも方針をすり合わせながら一緒にやってます。
雰囲気は悪くないとは思いますがどうですかね……。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?