00:03
はい、3月17日金曜日ですね。 時刻は朝9時7分になりました。
本日はちょっと久しぶりに日本語の記事をちょっと読もうと思ってますので、僕のですね、読みたい記事リストのなんかトゥードゥリストがあるんですけど、そこにずーっと溜まってたやつが1個ありましてですね、
完全に見落としたので、それをちょっと今日は紹介していこうかなと思います。
はい、おはようございまーす。ひめめのきーすことくがはらです。ではでは、本日も朝活を始めていきたいと思います。
タイトルにあります通りですけど、「良いテックリード悪いテックリード」っていうブログですね。
このブログ、2018年の2月なのでだいぶ前のブログなんですけど、この辺の話って多分そんなには大きく変わらないだろうなっていうのも思いつつ読んでいこうかなと思ってます。
このブログの筆者の方はですね、ご存知か分かるんですけど、ゼロから始めるプロダクトマネジメントっていう書籍を発売されている、
ブログになりますね。これを今日読んでいこうと思います。
この記事は、グッドテックリード、バッドテックリードっていう記事があるんですけど、これの翻訳ですと。
一応著者の許可を得て翻訳をしましたってことだそうですね。
はい、じゃあ早速入っていきたいと思いますが、プテノドさんとリズさんですね。お参加いただきありがとうございます。
今からこうタラタラ読んでいこうと思うので、耳の友として聞いていただければと思います。
では行きましょう。この記事は、フォースクエアの技術的リーダーシップを簡潔に説明したガイドになります。
ベン・ホロウィッツの良いプロダクトマネージャー、悪いプロダクトマネージャーからインスピレーションを得ていますと。
そんな記事も確かにありましたね。これもついでに明日読んでいこうかな。はいってことです。
じゃあ今日行きますけど、まずチームワークからです。
良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだというふうに考えています。
面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにします。
チームの技術的能力を拡大し、システムの重要な知識が俗人化しないように努めます。
悪いテックリードは注目の集まる仕事で自分の成果を示すことを好みます。
その成果は部分最適にとどまり、開発チームのアウトプットを増やすにはエンジニアのニーズを増やすしかないという状況から脱することができません。
なんかちょっとスクラムマスターに近いような感覚ですね。
それのテックな部分になっているのが良いテックリードでしょうね。
悪いテックリードは本当個人主義って感じなんですね。
そういう方も全然まだまだいるんでしょうね。
この記事が2018年ですけど、多分今もいるんでしょうねと思いますね。
続いて技術的ビジョンです。
テクニカルビジョンですけど、
良いテックリードは技術の方向性について俯瞰したビジョンを持ち、それをチームが正しく理解できるように努めます。
良いテックリードは他のチームメンバーに権限を委ね、主要な事項に関してはメンバー自身の意思決定を促します。
良いテックリードはチームメンバーは賢く信頼にたると信じて、プロジェクトの重要な部分の取り扱いをチームメンバーに委ねます。
逆に悪いテックリードは説明責任を果たしたり、方針を言語化して伝えることを嫌がり、自分の決定にただ従うように命令します。
彼らは組織で共有すべき知識を抱え込んでしまいます。
03:02
ドキュメントを作って知見を広め、自分と同じくらい効率的に仕事を進められる人数を増やすというような活動をしないというのが悪いテックリードです。
徹底的に自分にベクトルが向いているのが悪いテックリードです。
絶対にドキュメントを作ったり、知見を共有して、メンバーのパフォーマンスや効率を上げた方が仕事としてはすごく成果も出るし良いと思うんですけどね。
そういう教育をしたというところも一つの成果になると思います。
これは一概にこの人が悪いというか、会社がそういう評価制度になっていなかったという背景もあるんじゃないかなと思ったりしますね。
組織で解決をするということもあると思います。
これはあれですよね。
外部要因というのも正直あるんじゃないかなという気はしましたけど、
それでも個人の資質としてチームのことをちゃんと見れているのかというのが結構重要だと思いますよね。
続いて次はディスカッション&ディベートですね。議論の話です。
良いテックリードというのは聞く耳を持ち議論を促します。
チームの議論が紛糾して収集がつかないときは問題を解決するための考え方とかフレーマークというのを示して、
チーム自身が会に到達できるように助けます。
過去の議論を蒸し返すようなことはせず、チームの出した結論の方が自分のアイデアより優れていると思ったときはそれを認めて受け入れます。
悪いテックリードは結論がなかなか出ない議論をそのまま放置してチームのセンサー性も損ないます。
あるいはそれはもう議論済みで結論が出ているといって議論を途中で遮ってしまいます。
悪いテックリードはチームが正しい結論に到達することよりも自分が議論に勝つことを重要視します。
なるほどですね。
なんかサーバントリーダーっていう言葉がありますけど、あれに近いのかな。
良いテックリードっていうのは。
のようなふうに聞こえましたね。
そういう要素を持っているっていうのが良いテックリードなんでしょうね。
悪いテックリードは一貫して自分のことが中心な世界観を作りたいんだろうなって感じですね。
続きまして、次はプロジェクトマネジメントですね。
良いテックリードっていうのは先を見越して行動します。
彼らは技術課題の解決が予定通り進捗していることを確認します。
良いテックリードはチームと一緒に見積もりを行い中間マイルストーンを立てます。
懸念事項をあらかじめ明らかにしたり、問題を実際に起こる前に言及します。
技術的な障害を特定してチームで問題解決に当たられるようにします。
全体を見て同じタスクを重複して行うようにし、逆に注力できていない部分を見つけ出してリソースをきちんと振り分けられるようにします。
ここなんか言うとテックリードっていうか完全にプロジェクトマネージャーみたいな感じしますね。
悪いテックリードっていうのは問題が起こってから対処します。
彼らは権限を移情するが、その後進捗に問題がないかっていうのを確認してフォローしようとはしません。
中間ゴールを設定しないし、ちゃんと良い結果が生まれるかどうかっていうのは気にせず。
複雑なエンドツーエンドのテストを行う直前まで何もしない。
興味深いものだが、さして重要でない仕事に時間を浪費することをチームに許してしまう。
結構放置してしまうということですね。
一応それを揶揄したような一枚の画像も貼られているので、興味ある人はこの後この記事自体もリンク共有しますので見てみてください。
悪いテックリードは問題は解決済みだという。悪いテックリードは手柄を自分のものにしようとする。
06:05
良いテックリードはディスカッションを流したり、チームの能力を順に務めるという。
今まで言ってきたことを一枚の画像にペッと貼った感じですね。
はい、じゃあ続いて現実主義の話ですね。
良いテックリードというのは現実主義で正しいことを行うことと仕事を片付けることのバランスを心得ています。
時には近道を通ろうとするが、それは怠惰だからではないです。
最低限必要な仕組みをローンチするために全体の進捗の妨げになっている問題を回避したり、
一時的に棚上げすることをチームに推奨することもあります。
良いテックリードにとって細部はとても重要であります。
コードの品質、コードレビュー、そしてテスト。
こうしたことを製品を予定通り出荷するのと同じくらい重要だというふうに考えています。
逆に悪いテックリードは短期的な視点で時間を短縮しようとして、
技術的不採を蓄積し、後からその分の付を払うことになります。
彼らはその場しのぎで良い状況と完璧を競なければならない状況の区別というのがもうつかないということですね。
つかないというか普通に区別しないんじゃないですかね。
そういうアクションをしない人なんだと思いますね。
そういう意味での現実主義という評価だったんですね。
なるほどでした。
続いてコミュニケーションですね。
良いテックリードというのは自分の役割がコードを書く以上のものだということを知っています。
効果的なコミュニケーションが自分の仕事に必要可決であり、
チームがより効率的に働けるようにすることに自分の時間を割くことが求められているということを理解しています。
チームで働く上でコミュニケーションの重複というのは発生してしまうものだし、
チーム全体の生産性を上げるために個人的な生産性を多少犠牲にするのはやむを得ないことだというふうに思っています。
これは難しいですね。バランスがありますけど。
でも必要になったら犠牲にするのは仕方ないということですよね。
悪いテックリードというのは自分自身がコードを書くことが最も生産性が高いことを考え、
コミュニケーションすることは集中の妨げになると考えます。
チームの生産性を最適化することではなく、自分の仕事を最適化することというのを重視し、
チームを引っ張らなければならないことをフラストレーションに感じます。
ここまで来るともうテックリードしなければいいじゃないですかね。
あとプレイングマネージャーとかプレイングリーダーって自分がボトルネックになってしまうことが往々にあり得るので、
実は書かないほうがいいと思ったりしますけどね。
書きたいんだろう全然書いていいと思いますけど、権限と役割とスコープをちゃんと絞らないと
あなたがチームの生産性を下げる可能性はもちろんあり得ると思うので、
この辺はしっかりバランスを考えてメンバーの割り振りとかを考えなきゃいけないなと思いますね。
これもチームで解決する問題だともちろん思うので、
最初に体制を組んだ時とかに役割分担をしっかり決めておくのはいいかもしれないですね。
都度都度ブラッシュアップするのはもちろんいいと思いますけど、
この辺は最初のチームビルディングって結構肝だなと思いますので、
でも悪いテックリードはこういうことしないでしょうねっていう話でした。
はい、じゃあ続いて。
次はプロダクトとの関係だそうですね。
良いテックリードっていうのはプロジェクトマネージャーやデザイナーとプロダクトがどうあるべきかについて会話します。
同意できない意思決定に反論することはいともないけど、
09:00
プロダクトのゴールを達成できるよう落とし所を意識しています。
良いテックリードっていうのは技術的な制約に対して独創的な回避策を見つけ、
より技術的な要求が緩いプロダクトの構成を代替案として提示し、
プロダクトマネージャーやデザイナーが技術的な課題を理解してトレードを受け入れられるように手助けをします。
悪いテックリードっていうのはプロダクトの意思決定に無関心で、
プロダクトについてオーナーシップを持とうとしません。
技術的な制約があればそれは不可能だと言って拒否し、
代替案を提示したり理由を説明したりしようとはしない。
ここまでくるといわゆる脳死ですよね。
考えることすら拒否をしているので。
そんな人をテックリードにしちゃダメでしょって思ったりします。
なんか組織的な評価になってしまう気がしますけど。
とりあえず資質としては悪いテックリードの資質はそういうことなんだろうなって感じですね。
プロダクトについて無関心なテックリードって嫌だな。
続きまして柔軟性ですね。
ちょっと短いですね。
良いテックリードっていうのは仕様の変化に対して柔軟で、
突発的な出来事にも穏やかに対応します。
彼らは変化を予期し変化に対応できるように設計をします。
逆に悪いテックリードは仕様変更にも苛立ちます。
あるいは仕様の変更が発生しそうにないところまで
汎用的な設計をしようとします。
必要なところまで汎用的にする必要は確かにないですからね。
いわゆる関数とかコンポーネントとかの共通化の話に近いと思いますね。
必要じゃないのに全部を共通化するっていうのは確かに労力無駄ですからね。
とか思ったりしますけど。
でも仕様変更は、いや、苛立つときは苛立つと思いますけどね。
これは一概に、悪いテックリードは仕様変更に苛立つっていう
断言するのはちょっと違う気もしますね。
傾向はもちろんあると思います。
でも仕様変更はあるでしょう。
普通に考えていったら僕は思いますけどね。
やっぱり最初に要件定義しますけど、
お客さんもそうですし僕ら開発側もそうですけど、
全部を見えているわけはないですからね。
後から見えてこなかったり、そういえばこういうのどうだったっけっていうのを
やっぱり動いていく中ではっきりしたり決まってくることもあると思うので、
その時に多少の変更は絶対生まれるものと思います。
前事前道の神じゃないので僕らは。
全てを予測したり見えていることはまずないからね。
なので前提として仕様変更があるっていう風に立脚しないと
そもそもいかんのじゃないかなと思ったりしますね。
続きまして、次ラストですね。
ちょっと短いですけど今日。
早いですね。
ラストは性格、パーソナリティですね。
良いテックリードっていうのは寛大ですけど、
自己主張は結構はっきりしてますと。
悪いテックリードは対立的な態度で攻撃的だと。
良いテックリードは技術的な能力や経験によって自然と尊敬というのを勝ち得ていきます。
逆に悪いテックリードは与えられた肩書きや権威によって尊敬が得られるものと思っています。
良いテックリードは常により良くする方法を探しますが、
悪いテックリードは他人からフィードバックを受ける時には防衛的になります。
良いテックリードは謙虚であり、自分以外のチームメンバーが確信を持てるように後押しをしますが、
12:03
悪いテックリードは傲慢であり、チームメンバーに自分のテックリードより劣ると認識させることに喜びを感じる。
もうリードやめてくださいって感じですね。
はい、っていうのが正確でした。
以上、ざっと読んできましたけど。
ちょっと早いですね。まだ14分くらいなので。
せっかくなんで、良いプロダクトマネージャー、悪いプロダクトマネージャーも読んでみようかなと思ったんですけど、
リンクをクリックすると404が入ってきたので、
すみませんけど今日はだいぶ早いですけど、朝方これで終了したいと思います。
いかがだったでしょうかね。
良いテックリード、悪いテックリードって書いてますけど、テックリードというか、すでにリーダーの話だと思いますね。
でもありますし、この辺の逆に言うと観点を持っていれば、エンジニアとして持っていれば、
もう十分あなたはリードとして名乗ってもいいよってことの調査にもなるなと思いますし、
この辺ができるようになってくると、リーダーとしてしっかりバリュー出せてますよっていう調査でもあるのかなと思ったりしましたね。
でもとても良い指標だと思うので、これは次回の意味も込めて、
改めて定期的に読み返したいと思いました。
僕、これ悪いテックリードの方、今の自分当てはまるなって思うこといくつかあって、
ちょっと読みながら耳が痛いというか、反省しなきゃいけないなって感じちゃいました。
というので、これは定期的に読み返そうと思います。
じゃあ短いですけど、朝方以上にしたいと思います。
日曜日ですね。締めというところでしっかり締めて、
土日ゆっくりいきたいと思いますので、今日も頑張っていきましょう。
今日は前川さんとリズさん、ネグさん、プテアノドンさんとタマヌギさんですね。
ご参加いただきありがとうございました。
明日も緩くやってきますので、興味があれば聞いてみてください。
それでは終了したいと思います。お疲れ様でした。
