00:06
はい、7月20日ですね。 水曜日、地獄朝九時を回りました。
本日の東京は現在晴れておりますが、途中からまた曇りのち、雨だそうですね。
はい、おはようございます。kkeethここ。 福原です。では本日も朝活を始めていきたいと思います。
はい、というわけで前回から、前々回からですかね、引き続き2日間連続で、えっと
ソフトウェアエンジニアリング ザソフトパーツっていう記事を読んでいるという感じですね。
はい、では今日もその続きを読んでいきたいと思います。 今日も多分、今日は確実に終わらないでしょうね。
はい、で、また明日終わればいいなというところのスピード感で読んでいこうと思っております。
はい、では前回の続きですね。 前回はデザインドックスのところですね。
やはり設計省の周りのところだと思いますけど、 その続きで今日はコミュニケーションから入っていきたいかなと思います。
では、行きましょう。コミュニケーションですね。
謙虚に明確にコミュニケーションを取り、相手を尊重する、親切にすることにコストはかかりませんが、そのインパクトは測り知れません。
良いコミュニケーションにはエネルギーと思いやりが必要だという人もいるかもしれません。 思いやりのためのエネルギーがもっとあってもいいと思います。
コミュニケーションは効果的、生産的、効率的なソフトウェアエンジニアになるために必要なソフトスキルやヒューマンスキルの重要な部分です。
誤ったコミュニケーションは誤った機能、互換性のない行動、または不愉快なチームの動きに繋がる可能性があります。
コミュニケーションは人々がより要件を理解し、問題がエスカレートするのを防ぐのに役立ちますと。
世間ではソフトウェアエンジニアは一日中行動を書いている人だと思われているかもしれません。 しかし自分たちの作ったものが誰かの役に立つようにするには、
チーム内の他のメンバーやビジネスユーザーの期待と自分の努力を同期させなければなりません。
そのため、コラボレーションとコミュニケーションは私たちの仕事の重要な柱となります。
ジュニアデベロッパーは他のチームメンバーやテストエンジニア、チームリーダーとコミュニケーションを取り、アイデアを共有したり問題解決のための選択肢を話し合ったりするのが主な仕事です。
キャリアを重ねるにつれ、仕事を効率的に進めるために必要なコミュニケーションの量は増えていきます。
メールであったり会議、人前で話す回数も増えます。
ビジネスリーダー、マネージャー、ステーコフォルダー、チームメンバーとコミュニケーションを取らなければならないのです。
専門性が高いほど他者から理解されにくいというリスクも高まりますというところでした。
一旦コミュニケーションのセクションでしたけども、まあまあなんかその通りだなと思いますし、
そうですね、キャリアが積まれていったりとかポジションが上がっていったり、リーダーだったりマネージャーだったり、
もしかしたらエグゼクで行ったりとか、行ってしまうとどんどんコミュニケーションする量とか回数は増えていきますし、
いわゆる手を動かすっていう仕事は逆に言うと減っていきますよね。
その中でも専門性が高ければ高いほど他者から理解されにくいところがあるので、
03:03
その専門性が高い人たちとコミュニケーションができるエンジニアっていうのはかなり希少価値が高いし、
バリューもしっかり発揮できるなっていうところで、自分のキャリア形成としてはいいのかなと思ったりします。
もちろんコードをバリバリずっと書き続けるっていうのもいいと思いますけど、
どっちにしろ仕事をする上では結局チームで動いていきますので、絶対コミュニケーションは外せないんですよね。
なので尖ったスキルを持っていることもすごく大事であるし、
そこは自分の市場価値を上げるには本当に必要だと思うんですけど、
やっぱりコミュニケーションスキルはそれと同等感、もしくはそれ以上に大事なスキルだったり能力だったりするのかなと思いましたね。
はい、というところで読んでいったら参加者がいただきましたね。
はい、Kさんとケンジさんですね。おはようございます。
今日もタイトルあるソフトエンジニアネグザソフトパーっていう記事の続きを読んでいっている感じですね。
いわゆるグーグルのシニアエンジニアの人ですかね。
グーグルで10年間エンジニアとして頑張ってきた人が方々のソフトスキルについて自分の10年間の知見をまとめた記事ですね。
はい、今日はその3日目です。3日目なんですけど今日も多分終わらないと思います。
それぐらいボリューミーで長いんですけど、すごく知見に富んだ記事ですのでぜひ読んでいただければと思います。
はい、では続いていきましょう。今のがコミュニケーションだったのでそのコミュニケーションの続きですね。
カスタマイズコミュニケーションです。
そのままカスタマイズされたコミュニケーションですけど、
これ何かというと聴取に適した言語、概念、詳細レベルを使用しましょうと言っています。
とある問題とか状況をどの程度理解しているかにかかわらず、他者と議論をする際には相手が自分に関連することをすぐに把握できるように言葉を調整する必要があります。
ビジネスバーさんと話すときはあなたのしていることがビジネスに与える影響について話しましょう。
専門用語を使いすぎないようにしましょう。
技術管理者と話すときは技術的な影響や課題を伝えます。
意思決定者と話すときは利用可能なオプションとその意味やリスクについて説明し、オプションがどのように機能するかの詳細については触れないようにしましょう。
データその更新を行う場合は他にどのようなことが起こったか、またその更新がプロジェクトの目標にどのように関連しているかを認識しましょう。
同じ原則が電子メールを書くときやより多くの人にプレゼンテーションするときにももちろん当てはまります。
メッセージを受け取る人たちに関連することを書きましょう。
プレゼンテーションの際には自分のアイディアを守る必要があるかもしれません。
質問との回答は資料深く行いましょう。
膝を打つような回答というのは通常コミュニケーションに悪影響を及ぼしますと言っています。
コミュニケーションの基本的なところですよね。
僕が何、我々が何を伝えたいかというよりも受け取り手が何を聞きたいのかとかどういうことを目的としているかというところを結構意識するといいと思いますし、
また受け取り手の人たちと僕たちのもちろん知っていること知らないことというのは結構バラバラだったり一致することはなかなか難しいと思うので、
06:03
なるべく分かりやすい言葉を使いましょう。
僕らエンジニアというのは特に専門職と言われたりするのもあるので、専門用語をバリバリ使うかもしれないけど、僕らの使っている専門用語が伝わるとは限りませんから。
例えば僕も結構営業と話すことが多いんですけども、
もちろん営業だと同じ会社にいて同じIT業界にいてもやはり伝わらない単語とか技術の名前とか概念とかっていうのはやっぱり全然ありますので、
そういうところを専門用語じゃないワードでうまいこと置き換えられるのが結構大事なことだなと思ったりもしましたね。
細かいんですけどこれ一つで全然話が変わってきたりするしスピード感も違うので、この訓練はしててもいいのかなと思いましたし、Googleでも同じこと起きてるんだろうなと思いました。
またGoogleまで行ってしまうとやっぱり世界的なエンジニアをかき集めて仕事をしているので、そもそも国とか文化や時間も全然違うので、
そういう背景もあって本当にちゃんと相手に僕の、我々の話したいところが伝えたい位置が伝わっているのかっていうのを確認するっていうのはすごく鍛えられてるんだろうなと思いました。
日本人で言うとやっぱり都市語大きいですけど、日本は横に習いが強く空気を読むところがすごく長けているので、
あんまり説明をしなくても伝わるだろうみたいな勝手な思い込みもあったりしたりするので、そういうところを改めて問題提起するのが結構いいなと思いました。
はい、じゃあ続いて、Being kind and considerate、親切にすること、思いやりを持つことっていうところの章です。
いきましょう。親切であることは超能力です。またそれを行使しましょうと言ってます。面白いですね。超能力まで行っちゃうんですね。
はい、スーパーパワーって言ってます。
はい、穏やかで親切で役に立つことは誰かを切り捨てることよりもあなたを遠くに連れて行くことができます。
チーム内の人に親切にすることはチームを強く成功させることにもつながります。チーム外の人々にも親切にしましょう。
都市機内の全ての機能、人事だったり総務財務とかマーケティングなどに対して同等の経緯を持って接しましょう。
直接的に彼らを助けることができなくても彼らの仕事を理解し共感することはいつでもできます。
他の人がうまくいった時や商談を受けた時には祝福をしたり感謝したりしましょう。
他人は伝説します。あなたが親切にした人は将来援助の要請があった時に応えてくれる可能性が高くなりますと。
まあ、総務ですね。素晴らしい仕事をしている人には惜しみなく声をかけましょう。改善が必要な場合にフィードバックを与えることは重要ですが、
物事がうまくいっている場合にポジティブなフィードバックを与えることも重要です。
こうすることでチームは自分たちが成果を受けていること、そして評価されることを知ることができますというところでした。
カスタマイズコミュニケーションというか、さっきのコミュニケーションがさらに発展ではないですけど、そんなところかなと思いましたね。
いいフィードバックをするというところもすごく大事ですし、ちゃんとお互いのリスペクトを持って接していくというところも重要だというところですね。
特に経緯って難しいですよね。特に総務とかいわゆるバックオフィス系の方々って、
やっぱりバックにいるだけあって、普段お仕事をしていると、とにかく意識しなかったりとか、
09:06
もっと言うと存在を忘れてしまう可能性があったりして、ちゃんと反省はしなきゃいけないと思います。
でもそういう方たちがいて、自分たちが思う存分やりたい仕事をバリバリできているというのは正直あるので、やっぱり日々感謝していかなきゃいけないなとはつくづく思いましたね。
でもまたそういうバックオフィスの方々って、逆に言うと給料を上げづらいという課題もあったりして、
なんかやっぱり自動化したりとか、AIでやれるんじゃないかというところもあったりするので、
評価を本当にされにくいポジションでもあったりするので、しっかり感謝を述べて、本当にあたたちのことがこの会社にとって大事ですよというのを伝えていくことも本当に重要だなと思ったりしました。
もちろんその総務とか日立だけではなくて、同じチームメンバーとかでも同じことだと思います。
はい、じゃあ続いていきましょう。
The Power of No っていうセクションですね。
No ということのパワーですね、力ですね。
はい、行きます。
No ということはオーバーコミットよりももちろん優れていますよと言っています。
はい、我々の多くはより多くの仕事が関係するところで、No というのが意外と得意ではありませんと。
Google の中の人にも同じようなことが起きるってことはどこでも起きるんでしょうね。
はい、それは No という選択肢があることに気づいていないか、もしくはチャレンジすることを楽しんでいるかのどちらかだと、だからですと言ってますね。
はい、まあ確かにね、No って言うとチャレンジする場が削られますから、それは確かに言いづらいかもしれない。
はい、しかしオーバーコミットメントは遅れにつながるので、まあ責任は重大ですと。
相手に何がすでに進行中であるかを伝え、どれくらい時間かかるのかを妥当な見積もりを提示することは、敬意の念の表れだと言っています。
そうすることで、相手は他の人に頼むか、タイムラインを延長するかといった選択肢を検討することができます。
経営人は、製品の品質に大きな影響を与えることが分かっている場合、記録的な速さで何かを納金するようにとは言わないでしょう。
もしあなたがシニアマネジャーならば、チームに悪いアイディアを断れるように力を与えてくださいと、まあいう権限を与えてくださいと言うんですかね。
はい、あとシティニア開発者、あるいは生産性の高い人っていうのは、No というのが結構得意な方が多いなっていうことをおっしゃってますね。
人は、あなたが避ける以上の問題を要求してきます。
優しく、しっかりきっぱりと断って、他の場所へ移民していきましょう。
もしくは、自分の時間をもっと彼らのために割くことができないか、上司と相談するように頼むと良いでしょうと言っています。
No と言うか、別にNoと言わないのであれば、その他の仕事にNoを言って、あなたの仕事に時間を割けるように相談をするみたいなことですね。
すべての人を満足させることはもちろんできません。YesとNoを言うときには最新の注意を払いましょう。
リーダーが何でもNoと言うのと、対局にあるのが何でもYesと言って、明確な境界線を設定しないことですと。
はい、Yesの方もそうですね。何でもかんでもYesって言うのは良くないですねってことですし、
安受けをして困るのはやっぱり自分だけではなくて、その頼んだ方のことは困ったりしますよね、遅延したら困りますし、
12:02
そこが困るってことは、最終的に要はビジネス的に困るので会社が困ることになるので、しっかりYes、Noの線引きをするのがすごく大事なことだと思います。
はい、現在のリソースで合理的に実行できる範囲以上のものを引き受けると、あなたやあなたのチーム、引いては顧客に迷惑をかけることになりますと。
このことはリーダーにとって特に重要です。なぜなら、他のメンバーはどのような場合にYesと言うべきか、あるいは優しく背中を押すべきかの基準をあなたに求めるからですと言っています。
本当に至極当然なことなんですけど、やっぱりビジネス視点を考えると、YesとNoをしっかり線引きしていくというところの重要性を語られている感じですね。
続きまして、アクセプタンス&リスペクトですね。受け入れること、需要することと尊重することですね。
分からないことを認め、後輩にも素直に助けを求めましょうと言っています。
分からないことがあったら認めてもいい。先輩だからともかく分からないことがあると恥ずかしいとか、よくないなみたいな風潮とか、固定観念みたいなのがあるかもしれないですけど、分からないことは分からないので認めていいという話ですね。
ソフトウェアで最も重要なスキルの一つは、答えを見つけそこから学ぶことができることです。
シニアリーダーとして、プロジェクトの技術的なニュアンスについては、周りの後輩の方がよく知っているかもしれないことを受け入れることを学びましょうと。
そうですね。とにかく最新ツールとかだとそういうことはよく起こりがちかなと僕も思っていますし、経験しているなという感じがあります。
やっぱり現場の開発とかを離れていくと、どんどん最新ツールというののアンテナを張っているとはいえ、そのスピード感とかキャッチアップの深度とかは全然後輩の方が深かったりしますので、
そういうところに頼るのは結構いい話かなとちょっと思いました。
彼らはあなたの正直さと学習への関心に敬意を払い、あなたはより良い状況を把握し、それに付加価値を与えることができるようになります。
ジュニアエンジニアとして先輩の快適さに応じてオープンやあるいは密にコミュニケーションとか技術的な概念を説明すべきだよというと言ってますね。
はい、というところでした。
はい、というところですね。
アクセプタンスとリスペクトでしたね。
はい、というところです。
たぶんわからないことを素直に出しても別に周りはあなたのことを悪いと評価することはまずないでしょうというのを正直僕は思ったりしましたね。
昔僕はそういうふうに思われたりするので、ひたすらしっかりキャッチアップしなきゃいけないなというのと、
何も知らないところに対して申し訳ないというか悪い概念、気持ちが普通にあったんですけど、
最近はそれを割と抜けましたね。
むしろ全然後輩に頭を下げて教えてっていうふうに言ったりしてます。
結果的にそれで、後輩がどれくらい若手の子が技術についてキャッチアップをしてる子なのかなとか、
この子は結構深く学んでるなとか、いろんなエラーバターンを知ってるなとか、いろんなやっぱりタイプが分かれたりするんですけど、
それの把握もできたりするので、全然教えてっていうのが割と効果は高いのかなと思ったりはしてましたね。
はい、続きまして、インフォメーションシェアリングですね。
15:00
はい、情報の共有ですね。
知識じゃなくて情報って言ってるところがミソな気がしてます。
なんとなくね。
はい、じゃあ読みます。
ミーティングや質疑応答を通じて適切な質問をし、知識を交換し、チームに情報を提供しましょうと言っているので、知識も情報に含まれてますね。
ミーティングを運営するときは自分だけが話していてはいけません。
ミーティングは他の人がアイディアを共有し、率直なフィードバックを提供するチャンスだと言っています。
若手エンジニアはあまり多くの質問をするのをためらうかもしれません。
あなたが先輩ならその背景を説明することで適切な質問をするように促すことができます。
質問を受けるときはスポンサーにその話題を出してくれてよかったと伝えてくださいと言っています。
ここでも感謝を伝えたいとか、そういうフィードバックをしてあげるというのは良いことだと思いますし、
ただやっぱりなかなか新卒の方とか若手の子だと、やっぱりそもそも発言するそのものに対して心理的なハードルを感じる子も結構多いと思うので、
こっちから結構ファシリテーションして促してあげるとか、勇気を出してピックアップして何か意見ないですかとか感想ないみたいなところを聞いてあげるのもいいかもしれないですね。
もちろんなければないって言っていいよみたいなのを伝えてあげると発言するハードルが下がるかもしれないですけど、
意外となさししてみるとボロボロ話し始める子って意外といたりするので、僕は結構なさししていくのはいいなと思いましたね。
気軽に話していいよとか、気軽に相談していいよって結構伝えるんですけど、割と伝えても話しくれる子って少ないんですよね、なかなか。
特にリモートで仕事してると特にそうかもしれないです。
皆さんそもそも喋ろうとするけど、マイクもカメラをミュートにしてって、本当にただただモニターに喋ってるみたいな時もあったりすると思うので、
しっかり促してあげるというのは結構大事かもしれないですね。
そういうチャンスをこちらが作ってあげるっていうところがすごく重要かなと僕は最近思ったりしました。
はい、ちょっと余談でしたね。
では続いていきましょう。
フレキシビリティですね。
柔軟性というところです。
自分の意見をしっかり主張しながらも、それを否定する新たな証拠が出るたびに、しっかり見直しをしましょうと言っています。
他の意見に耳を傾けることはコミュニケーションにおいて重要な要素です。
なぜなら問題に対する解決策は一つ限らないからです。
自分の意見に駆使するのではなく、他の選択肢に耳を傾け、評価しましょうと。
もしかしたらあなたが見落としていた傾向とか側面が相手から提示されている可能性もあります。
ポール・サファーという方ですね。
ポール・サファーの強い意見は弱く持つという原則があるそうですね。
ストロングオピニオンズ・ウィークリー・ヘルドってところですね。
しかもそのに対する記事があるので、これは情報ツイートしようかなと思います。
ポール・サファーの強い意見を持つという原則は、自分の意見を強く守る一方でそれに反対する新たな証拠を手に入れるために見直すことを説いていますと言っていますね。
これはアイディアや意見を出した人を考慮しない科学的根拠に基づく方法ですと言っています。
はい、これも結構大事なことですね。
自分の意見を一回自分の中でも疑ってみるというか、何か意見を言われた時にもそこをしっかり見直すというところですね。
18:04
そういう柔軟性を持ちましょうと言っています。
はい、いいですね。
確かにゴールに対するプロセスとかアプローチというのはもちろん一つではないなど、それは当たり前の話なので、
いろんなアプローチかというのはそれを一回聞いてみたりとか受け入れてみる。
もしくはそっちの方がいいねというふうに評価してあげることも全然大事なことだと思いましたね。
はい、続いてメンテナリング・レコードですね。
記録の維持と言っています。
略されていますけど、維持、記録と言うと難しいですね。
はい、ちょっと読んでいきましょうか。
非公式な会議の後に有効的なメールを送ることで、
議論中の重要なポイントや約束ごとを再確認することができますと言っています。
まあメールじゃなくてチャットでもいいと思いますけど。
はい、でもこれも結構重要ですよね。
話した後に改めてチャットを送ったりすることで、
重要ポイントや約束ごとの再確認、再認識ができるというのは結構よくある話だなと思ったりしますね。
はい、あとは会議の後のロスタイムじゃないですけど、
終わった後の雑談の中で意外と本質的な話とか意外と出てきたり、
いい意見出てきたりしたりするので面白いなと思いますね。
一個だけちょっと予断をすると、
インタビュアーの方の本を一回読んだことがあるんですけど、
そのインタビュアーの方にもやっぱり先輩後輩の関係があって、
まず入社した時とかにそのインタビューの仕事のポジションに就いた人が先輩から言われたことがあるんですけど、
そのインタビューする現場にいた時に、
カメラは終わった後もずっと回し続けろって言ったらしいんですよね。
その終わった後にカメラとか公には言えないようなところの話にすごく重要なポイントとかミソがいっぱい含まれたりして、
そういうことをインタビュアーの方って結構語ってくれるっていうので、
本当にカメラを止めるときはインタビュアーの方が帰るときまでカメラを回せって言われてるっていう指導を受けてたっていう話を読んでて、
めちゃめちゃ面白いし興味深いなと思いました。
人前でちょっと言いづらいとか、言いたいけど言えないよね社会的な理由でみたいなところでネタを持ってるって結構人に結構多いらしいので、
今ちょっと読んでてその話を思い出したっていう感じでした。
はい、つまり余談です。
なのでエンジニア勉強会の終わった後の懇親会ってのも結構重要だし、僕は結構懇親会こそ本場だなとちょっと思ったらしいですね。
はい、なので登壇者の方に懇親会こそ話しに行くっていうのを結構勇気出してやってみると割と学びとか得られるもの多いのかなと思ったりしてます。
はい、じゃあ本記事に戻りますね。
口頭でのコミュニケーションだけでは、物事を忘れてしまったり間違って記憶してしまっていることもあります。
すべての出来事を記録し、関連する議論に署名を得ることでこのリスクを排除することができます。
また、自分または他の人がタスクを手伝うことに同意した場合、上司を含む全員が同じ考えを持っていることを確認するために電子メールで期限を確認しますと。
このような予定外な仕事を記録しておくことは評価に関する議論の際にも役立ちますよと。
はい、まあしっかり小敵を取るというのは確認を取るというと、あと石橋を叩くみたいなところですね、この辺は。
21:04
はい、これも本当に重要ですよね。
言った言わないとかそういう程度の低いレベルの話だけではなくてですね。
本質的にちゃんと意思決定の合意を取れたよねというところの合意を取るというのはすごく大事だなと思ったりしました。
やっぱり口頭だけだと怖くなったりしますからね。
はい。
では続いていきましょう。
グッドフェイスですね。
このフェイスっていうのは顔の方のフェイスじゃなくて、対応とかの方ですかね。
いきましょう。
黙っているべき時を知り、その場の力学を観察するというところですね。
ある決定が理解できない、あるいは技術的ビジネス的な理由で意味をなさないというような状況があるかもしれません。
これは複数のチームでのディスカッションで起こり得ることです。
誠実に参加し、人々が公的に悪意を持つようなこと、リスクを犯さないことを前提としてくださいと。
あなたが全体像を把握していない可能性もありますし、相手が異なる優先順位を持っている可能性もあります。
最終的な決定に対して怒ったり不満を持ったりすることなく質問したり、自分の意見を述べたりしてください。
はい、怒ったり不満を持ったりするというのは感情の話なので、人間の感情はやっぱり抑えることはできないですね。
浮かんでしまったものは仕方ないんですけど、それを出すかどうかとか、どう扱うかというのは別の話なので、
僕は持ったりすることなくというのは結構無理だと思っていますね。
ただ、それをどう扱うかというのは結構重要かもしれません。
それを出すんだとしても、そのまま感情のまま喋るんじゃなくて、理論的に喋る中に含めていけばいいんじゃないかと思います。
正直に言うと、この意見に対して私は受け入れられないというか、ちょっと納得ができませんみたいなふうな言い方をすれば、
角は少し立つかもしれないですけど、深くその感情を呼んで喋るよりは、より建設的な意見ができると思ったりするので。
はい、これは結構大事かなと思いました。
ただ、自分自身が考えていることがそもそも間違っている可能性もありますし、
自分が全体像を把握できていなくて、一点だけ自分のいわゆる地雷に踏んでしまったような意見とか、
話の包みになってしまったせいで、そこにやっぱりフォーカスをしてしまう可能性ももちろんあるので、
一回この場というところの全体像を把握するというのが結構重要だというところですね。
はい、という感じでした。
続きまして、シニオリティー、シニアリティーかな?
ちょっと新しい発音をちょっとわかんないですけど、いわゆる年功序列というワードですね。
まさかこのGoogleの人が書く記事の中に年功序列というワードが出てくるのはちょっと予想外でしたね。
あんまりそういうところを意識しない方だと僕は勝手に思っていたので、
ちょっと反省はしていますけど、ちょっと読んでいきましょう。
私たちは自分の役割や能力においてキャリアを成長させたいと願っています。
技術的な上級職に興味がある人もいれば、リーダーや管理職を目指す人もいます。
どちらの場合でも年功序列の上位に位置する人々が示す重要な特徴というのがあります。
このようなキャリアを歩む中で、あなたの成長を導いてくれるメンバーがいるかもしれません。
ここでは上級職になるための資質を身につけるための私のアプローチを紹介しますというところで、
24:02
これはカテゴリーでした。
今回これでカテゴリー3つ目になりますね。
過去2つカテゴリー出てきたんですけど、これで3つ目ですね。
今回からその年功序列的なところのカテゴリーのソフトスキルというのを紹介していくということでした。
では入っていきましょう。
だんだん残り時間が短くなってきたので、どっかでちょっと区切りを入れようと思います。
難しいですね。どこで区切ろうかな。
今回は結構長いので。
いけるところまでいきますね。
1つ目ですけども、シニュアリティー&ストラテジック・スインキングですね。
年功序列と戦略的思考というやつですね。
不確実性がある中で意思決定や行動を怠ってはいけませんと言っています。
何も決断しないよりはどんな決断でもした方がいいということはよくあることです。
少なくともあなたがどのような方向に傾いているのか周囲に知らせることはできます。
リーダーとして私たちはチームが私たちに期待しているにもかかわらず、
そうでない意思決定について十分な時間をかけて検討しないこともしばしばありますと。
自信を持って決断するために必要な詳細についてできる限り
完全なイメージを構築することは可能ですし、創出的だと思っています。
時間に追われている場合などとか特にそうですね。
常にそれが可能とは限りませんと言っています。
限られた情報の中でどのように意思決定を行うかについて積極的に自分自身を向上させることがとても有効だよと言っています。
言わないよりはもちろん言った方がいいし、
自分はこういう考え方ですよというのを伝えることは結構いいことだと思います。
もちろん時間が迫ってきたりするので、その議論をぐちゃぐちゃにしたりとか、
いわゆる場を混沌とさせることになる可能性ももちろんあるので、
一概に全部出せばいいというわけではないし、
そのままの観察の能力を使っていくのもいいと思いますけど、
本当にそれぞれの意見を出さないといけないときっていうのはしっかりあると思うので、
そのときには自分の考えを述べていくのが結構重要かなと思います。
難しいですね。何も決断しないで寝かせるところが重要なときもあるんですけど、
往々にして一回意思決定を出してみて、
そこのフィードバックをもらってまた次に改善するという、
PDCAサイクルの方に回す方が早かったりすることも多いなとも思っているので、
えいやで一回意思決定をしていくのも全然いいと思いますが、
リーダーがメンバーとかの意見とか考えとかを十分に検討しないまま意思決定を、
リーダーだけの意思決定をする可能性も全然出るわけではないので、
そこに関してはしっかりNOというか、反論ではないですけど、
ちゃんと考えてねっていうのを伝えていくっていうところも重要かなと思いましたね。
それが誠実な仕事なんだろうなと思ったりもしました。
戻りますね。
リーダーとは視野を広げて、戦略的に考え、周囲に道筋を示す人だというふうにおっしゃっています。
戦略的に考え、計画し、その考えをより大きな範囲に適用する能力は、
経験とともに成長するのが理想的だと言っています。
27:02
個人貢献者、個人のコントリビューターであれば、
与えられたタスクや担当する機能に集中することができます。
しかし、いわゆるポジションが上がってきたり、出世という言葉が出てきますけど、
自分の仕事が及ぼす影響というのは、特定のタスクやプロジェクトに留まりません。
いわゆるスコープが広がっていくということですね。
選択肢を検討する際、メリットと制約の観点から、より大きな視野で物事を見ることができるようになるのです。
また、ソフトスキルの応用範囲も広がります。
例えば、以前はチームのために意思決定をしたり、チーム内の他のエンジニアに声をかけたりしていたとしても、
自分の選択やコミュニケーションが成長するにつれて、
複数のチームに影響を与えるようになるのです。
もちろんそうですが、
シニアになればなるほど、そういうことを求められたりする可能性も高いので、
そういう方々の経験値というのは、若手の方にはなかなかないスキルだったり、
経験値だったり、能力だったりするので、そこの差分は大きいのかなと思いますし、
先輩は先輩だけの価値というのはあるんだよなというのを
大意識してもいいのかもしれないですね。
もちろん現場力というところでは、若手の方が絶対に高いと思いますし、
しかたないと思います。かけた時間が違うので。
はい、というところでした。続いて、Reading by Exampleですね。
多分時間的にこれを読んだら終わる可能性が高いなと思います。
模範を示して指導をしましょうと言っています。Reading by Exampleですね。
えー、何だと?
チームに釣りを教えると言っていますね。Teach your team to fishと言っています。
チームに釣りを教えます。常に問題を解決してあげるのではなくて、
解決できるスキルを身につけられるように優しく導くのです。
よくある画像のやつですね。お腹が空いている人に対して、
魚を与えるのではなくて、釣りの方法を教えてあげるというところですね。
その場しのぎでお腹が空いても、その人がまたお腹が空いたらまた
同じ問題が発生しますけど、釣りを教えてあげることで、その人は
自分で自分の餌を取ることができるので、同じ問題は発生しなくなるという話ですね。
一つの例として、解決しあげるのではなくて、解決できるスキルを身につけてあげる。
教えてあげるというところが、未来に対しての価値だというところの
例え話があるんですけど、これを出しているのかなと思いました。
エンジニアリングのリーダーというのは力を与えます。
状況になればなるほど、自分のおもちゃを手放して
コーチし、委任し、チームが成功できるようにすることが有効です。
これが効果を高める方法です。これは答えを与えることよりも、
良い質問をすることで可能になります。
質問をしてあげることで、そのスキルを見つけてあげましょうというところですね。
これは共感が高いんですけど、
とても難しいスキルなんですよね。これができる人が
人こそ良いリーダーだと思いました。
いわゆる導くことができる人ですね。
あなたは困難な問題を評価するときに模範を示してリードし、
誰かが解決策を提示したときに適切な質問をするのです。
30:02
チーム内外の調整、交渉、合意形成に責任を負います。
自分の仕事だけでなく、チーム全体の成果を高めることに貢献します。
シニアエンジニアになると、新しいスキルを身につけたり、現場の実態を把握するために
コーディングをすることもありますが、それは仕事の内容に含まれません。
むしろアーキテクチャー図に結果がないか、行動に抜けがないかを確認する人になります。
自分の判断が技術的価値やビジネス的価値をどのようにもたらすか、
根拠や理由を持って説明できることが必要になってきますよ、と言っています。
シニアエンジニアというのは、ソフトウェアシステムと人間のシステム、
またはチームのアーキテクチャーに長けている必要があります。
多様なエンジニアグループを率き、タスクを任せ、行動の品質、パフォーマンス、
シンプルさに気を配れるよう指導できる。
必要なときにフィードバックを与え、必要なときに弁護することができる。
同時に自分自身、自分の仕事を困難な問題を解決する能力を売り込み、
組織内での知名度を上げることもできるはずです。
全体としてはチーム内の人や経営人との人間関係を管理する必要もありますよね、と言っていました。
ここはちょっと難しいスキルというか、視野が高いところだなと思ったらしましたけど、
でも本当に共感はすごく高くて、この辺ができるようになればいいと思いますが、
こんなスーパーなエンジニアになるには、いわゆるシニアエンジニアになるには、
時間と能力が必要だというところで、しっかり経験していく中で育っていくのが必要かなと思います。
というところで、30分過ぎたので、一旦今日のところはこれで以上にしたいと思います。
おそらく明日頑張ったらこの記事読み終われる気がするので、
明日また緩く読んでいきたいと思いますので、ご参加いただけたらどうかありがたいなと思っております。
では、一週間の中日ですね。
今日折り返しのところなんですけど、今日も一日頑張っていけたらなと思います。
また明日ものんびりやっていきますので、参加いただけたらいいです。
では、本日も頑張っていきましょう。お疲れ様でした。
ご視聴ありがとうございました。
