自分の中の考えをまとめるシリーズの続き。前回まではこんなの
今日は開発チームの信頼を得るために僕が考えていること。これで信頼編は最後！
いつもどおり相手の立場で考えるところから。とはいっても僕はエンジニアなので。自分のことを考えればいいのかな。
エンジニアは良いものを作りたい。お金が儲かるってのはもちろん良いんだけど、もちょっと奥の方に、誰かに喜んでもらえたら嬉しいとかがあるかなーと思う。とにかく良いものを作りたい。
でも、実際の仕事でそんな気持ちをそのまま出せるかというと。そういうもんでもなくて。それは何故だろう？と考えてみたんだけど。理不尽なことが多いからかな。と思った。
開発チームって工程的には下流にいて、だから、理不尽なことを押し付けられやすい。
スケジュールがどう考えても実現不可能なのに「どうして遅れてるんですか？毎日残業して土日に出てでも達成してください」とか。要件が膨らんでるのにそれを全部開発チームに吸収させようとしたりとか。意味の分からない仕様書を渡されて「この通りに実装してください」と言われて、仕様バグかな？と思うことを指摘したら「あなたはそんなことを考えなくていいんです」と言われ、なのに仕様バグがあったら「どうして指摘してくれないのですか？」とか。テストの時間がないから削れと言われて、それでバグが見つかったら「どうしてバグがでたんですか？」とか。
枚挙にいとまがないですが。要するに。いわゆる上流の人たちのミスを一身に押し付けられちゃうわけですね。知らんがな！ですよね。ってことで自分を守るために線を引きます。僕は仕様書に書いてある通りに実装します。この仕様書では実装できません。テストの時間を短くしろというのはリーダーからの指示です、のエビデンス残しておく。とか。
てことで。
エンジニアは良いものを作りたいという気持ちを持っているけど理不尽な状況が殻に閉じこもらせてしまう。ですかね。
そんなエンジニアと信頼関係を築くために僕が考えてるのかなと思うのは、上から下まで任せるんだけど責任はみんなで共有しよう。より良いものを作るために環境を整えるしプロジェクトの中で成長していいんだよ。かな。
上から下まで任せる
上流のミスを開発チームがかぶんなきゃいけないから理不尽なんよね。自分のミスを自分でカバーするならしゃーない！じゃ、タスクを渡すのではなくてビジネスゴールを伝えるからあとよろ。あ、そのスケジュールも自分で決めてね！
チームに任せつつ、マネージャ編でも言ったけどリスクの見極めとかスケジュールの遅延のハンドリングとかはDevLeadが外から見てやっとく感じ。
スケジュールを自分で決められるなら、めっちゃバッファとか入れられるんちゃうん？て思うかもなんだけど。遅延の説明とか、バッファの調整とか、その辺僕に任せといて、ベストを尽くして下しあ！って言ってたら。なんか毎回チャレンジングなスケジュールで面白い。
責任はみんなで共有
殻ができるのは責任の境界なのかなと感じている。チケットを誰かにアサインしてしまうと。「これはわたしのチケット」「それはあなたのチケット」とチケットの境界で殻ができちゃって。おいしくない。
チームで仕事をするならチーム内に殻を作って欲しくない。
OK。僕はチームに依頼をするので。その依頼に対してチームとして結果を出してください。個人の進捗に興味がないです。あなたがそのチケットを予定通りに今日終わらせることと、あなたの隣の人が昨日終わらせる予定だったチケットを今もやっているけどそれを一緒に終わらせるのと「チーム全体で見て」どちらが良いかをメンバー全員で話し合って決めてください。それと、残業は基本的にはしないで欲しいんだけど、するなら全員でしてください。
チームの単位で責任を考えると、1人で抱え込むことが減るし、まぁ1人だったら守りに入っちゃうようなところも、全員だったら前進できたりする。
ここでまた出てくるのが、人じゃなくてサービスと向き合う。「どうしてこうしなかったんだ？」って責めるのなにそれおいしいの？振り返りのためのネタ出しなら許す。「あのときこうしなかったのがまずかったから次はどうしていったらいいかな？」と未来の話をしよう。
人に向き合って、過去を責めてもしかたがない。責めるなら自分を責めとけ。そうじゃなくてサービスの明日のために何をしていくべきかを見なきゃだろう。
※これはDevLeadとDevTeamの間の話ね。その外側の大人の世界では色々あるね。
環境を整える
エンジニアって。不精よね。できるだけ楽をしたい。手作業嫌だ。とか。そういう人がエンジニアに向いてるんだと思うんけど。そんなエンジニアたちのために、開発の集中力を妨げるものをちょっとでも自分が吸収して環境を整えてあげる。
誰か１人出てれば大丈夫な会議には自分だけが出るようにするとかして不要な会議を減らすし、プロジェクト管理のために必要な数字集めはできるだけエンジニアが楽をできるようにチケットに関連付けて集めたりするし、他部署調整や問い合わせの一次受けは自分がするし。とか。
そんな風に、エンジニアが開発に集中できるようにして、開発周りの雑務は自分が引き受けるようにしている。
成長していい
あるプロジェクトをやるのに、メンバーにその開発スキルがないとする。そのときに「私はあなたの技術に対してお金を払っているので、それは家で勉強してきてください」というのは、分からなくもない。けど多分それではうまくいかない。*1
今、僕は「業務で必要な技術で足りないものがあれば業務中に身につけてください」としている。JUnitの書き方とかそのレベルから。さらに「チーム全体で1ヶ月後により良い開発ができるように全員がサポートしあってください」としている。目の前のタスクを誰か出来る人がサクッと終わらせるよりも、そのサクッを別の人と一緒にやって、その人もサクッできるようになるとチームとして良いよねというお話。
家で勉強する習慣のある人は、業務以外のことを勉強して視野を広げてくれたらいいと思う。
また、成長に関しては、本人任せにせずに、サポートしてあげるというのも必要なんだなと思っている。頑張ってね！というのは簡単だけど。それよりも、みんなで成長していける仕組みを用意してあげれば、効率がいい。その点で、自分は2週間に一度、チーム全員で振り返りを行って、良かったことと挑戦したいことを話あっている。検査と適応というやつね。
まとめ
エンジニアは良いものを作りたいという気持ちを持っているけど理不尽な状況が殻に閉じこもらせてしまうので。上から下まで任せるんだけど責任はみんなで共有しよう。より良いものを作るために環境を整えるしプロジェクトの中で成長していいんだよ。
自分がエンジニアなので。自分がこんな環境で働きたい！と思うものを用意すればいいので。これは簡単だったかなー。てか、僕がこういうチームで働きたいと思っているチーム作りをして、でもだからそのチームの中に入れていないジレンマ！DevLeadもいいけどこんなチームのエンジニアもやりたいなー。
あ、あともう一つ。開発スキルがある、というのはチームの信頼を得るうえで重要かな。
*1:アウトプットに対してお金を払っている会社ならうまくいくかもと思う
