ちょっと前に以下の記事がバズってました。
https://qiita.com/kojimadev/items/06506d374f19493d7e72
当時はふーーんっと思っていましたが、新たな案件に入ったときでした。
そこではオンボーディングが出来ていませんでした。任せたい分野と概略となった機能、そして要件定義所もないざっくりとした要求を提示してもらって、あとは放置。
このままだと手探りのままで進めなきゃならない、でも仕方ないかスキルが足りていないんだから。そう思っていたところ、オンボーディングという考え方を思い出しました。
オンボーディングとは、チームに初めて参画した人に対してフォローアップを行うことをさします。エンジニアチームにおいては、チームの開発体制を共有したり、ドメイン知識を説明するためのキックオフを開催したり、ペアプロをしたりします。
また、一度の取り組みで終えることなく、一定の期間は手厚くフォローアップします。
いくら開発スキルの高い人でも、コーディング以外の部分についてはすぐに把握できません。オンボーディングによって、ドキュメントになっていない暗黙知や業務ドメインの知識について理解していきます。
「SESを受け入れ体制が出来ている」というセンテンスがあります。これを精密に表現すると、組織としてオンボーディング体制が出来ているということを指します。
それらが今回の環境ではなかった。請負契約によってベンダーに依頼することが主流だった中、新たに社内向けにと考えたそう。そういった経緯でアサインされたようです。
大変遺憾なことでしたが、がんばるしかないよという感じですね。
ただし、オンボーディングの不出来さは、組織にいる人の人間性とは分けておきましょう。このスキルが足りない人は、態度や言動、行動に現れてしまいます。そのため、私たちがオンボーディング不足な状況に直面したとき、相手の人間性の問題へと誤認してしまうことがあります。
しかしここでは観点をスイッチします。つまり、「オンボーディングに関する知識を身につけていない人が上司なので、今の放置気味のスタンスになっているのだ」と受け入れていきます（というか、そう思わないと、ストレス過ぎるので）