00:04
7月22日金曜日、地獄浅久寺を回りました。
今日はあいにくの曇りですね。
はい、おはようございます。
いめめめのkeethごとくわはらです。
では本日の朝活を始めていきたいと思います。
はい、ということで、前回から引き続き、
Soft Engineering-The Soft Partsですね、
あのタイトルの記事をダラダラと読んでいく3回目になりますと、ところです。
前回から読んでいたんですけど、この記事は本当に素晴らしい記事でですね、
いわゆるエンジニアのソフトスケールと呼ばれているものなんですけど、
それについての知見というか、経験値をまとめられた、
Googleのエンジニアの方、シニアエンジニアの方が書かれた記事なんですけど、
ほとんど共感を覚えることばっかりだったり、
本当その通りだなと思うこともたくさんあったりとか、
考え方マインドセットというところもちょいちょい要素として出てくるんですけど、
めちゃくちゃ参考になるし、真似したいなと思うところもいくつか出てきているので、
ぜひこれは全ソフトエンジニアに読んでみてほしいなというような、
そういうおすすめをしたいというのもあって読んでいる感じですね。
はい、ということでした。
前回で4分の3まで行ったのかな?
3分は多分読んだと思いますけど、
5丸読んだので、あと1回、1回か2回ぐらい読めればいいのかなと思っています。
前回でどこまで行ったんだっけかな。
コミュニケーションのところは終わりまして、
シニアリティのところまで入った記憶はありますね。
シニアエンジニアっていうポジションに対しての良いところとか、
上手いことの付き合い方みたいなところですかね。
そのところは読んだ記憶があります。
で、その中で、どこまでだっけな。
リーディング・バイグ・ザンプルはなんとなく読んだ記憶があって、
スケール・エフェクティブネスがちょっと怪しいなというところですね。
実は読んだかもしれないですけど。
次の章のメンタリング、実は入ったのかな。
入ってない気がちょっとおかしているので、
なんとなくスケール・エフェクティブネスから行こうかなと思います。
多分そこまでしか読めていない気がしているので。
シニアリティ&ストラテジック・センキングですよね。
シニアリティと戦略的なところですね。
思考戦略のところまでは確か読んだ記憶がありますね。
じゃあ行きましょう。
スケール・エフェクティブネスというところからですね。
じゃあ翻訳します。
昨日、余談ですけど、取締役会があって、
そこでいろいろいい話が聞けたり、
弊社の歴史をちょっと振り返ることができたので、
めちゃめちゃ面白かったんですよね。
という余談をして。
03:00
じゃあ行きましょう。
効果を拡大するというところですね。
世界最高のエンジニアリングの偉業というのは、
個人ではなくエンジニアチームによって達成されています。
ですから、もしあなたがより多くのことを成し遂げようとしているのであれば、
あるいは会社でより上級になる準備ができていることを示すのであれば、
コラボレーションとメンターシップを通じて、
自分の能力を倍増させましょうと。
それが自分自身だけでなく、
チームの他のメンバーにどのような価値をもたらすかを
実証してみてくださいと。
私はGoogleエンジニアでシニアエンジニアの道を進んでいるように感じましたが、
自分自身をスケールアップさせるには、
私から私たちに考え方をシフトしなければならないことに気づきました。
他の人と協力し、学んだことを共有し、
周りの人のスキルや専門性を引き上げることに集中することで、
私たちはとても多くのことを成し遂げられるようになりました。
ここ大事ですよね、このポイント。
さらっと述べてますけど、
こんな簡単に私たちに自分自身の考え方をシフトできるかというと、
そんな簡単じゃないんですよね。
本当に難しいと思いますし、
エネルギーもいると思うし、時間もかかると思います。
しかしこれができた人というのは確かに、
スケールでできているようなことを本当に感じますので、
できたらいいのかなと思います。
その方が正しいとか、それが絶対にいい道だというわけではないです。
本人自身の意思もありまして、自分の思考制度もあったりするので、
もしも新エンジニアの道を歩んでいきたいのであれば、
そういうことをしていくのがいいのかなと思いました。
続いて、個人として仕事を始めたばかりの頃は、
自分が率いる専用のチームを持つことはできないかもしれませんが、
同じような考えを持つ人たちを見つけて協力し、
おそらく自分の目標と同じように一緒に仕事をすれば、
一人でできることよりもずっと多くのことを成し遂げられるはずです。
しかし同じような考えの人たち、目標が一致している人たちを見つけて、
協力をすれば一人でやるよりもずっと多くのことを成し遂げられるでしょうと言っています。
ここは有名な言葉にありますよね。
早く行きたければ一人で行け、遠くへ行きたければみんなで行けというところですね。
という名言があって、僕は本当にこの言葉が好きで、
まさにその後者の方ですね。
遠くへ行きたければのところだと思います。
この観点としては。
結構近いのかなと思いました。
続きまして、次がシニアリティのラストですね。
インポスターシンドロームというやつですね。
インポスターシンドロームそのまま書きましょう。
答えを浮かすこと、答えを知らないこと、指導を求めることは別問題ないと受け入れることで、
インポスター症候群というのを克服することができます。
これも大事なことですよね。
一回自分のことを認めるとか受け入れるということですよね。
これはシニアリティというか、いわゆるソフトスキルというところに集約できるっちゃできるんですけど、
エンジニアとか関係なしですなと思いました。
一般の人たち全員にも同じことを通じるなと思いましたね。
06:01
別にミスしてしまうことも全然人なんであり得ますし、
もちろん仕組みで解決したりとかミスしないことが一番ではありますけど、
してしまうのは仕方ないと思います。
答えを知らないことっていうのもそれはそうですよね。
全てのことを知っている人はできないですし。
また指導を求めることっていうのを問題ないと受け入れるのが大事だと言ってますね。
別に指導を受けることも全然いいんじゃないかと思いますね。
自分が知らないことはたくさんあると思いますし。
特に最近の若い子、若手の子からどんどん吸収したりとか、
いろんなことを学ぶっていうのはすごくいいことだと思ってますので。
若手の子は僕らが生きていない時代を生きているので、
見ているものとか感じているものとかも全然違うことはあると思うので、
僕らと観点とか物の見え方も違ったりすることが結構多いので、
逆に若手の子から学べることってすごく多いんですよね。
それを指導という言葉で表すとちょっと違うニュアンスに聞こえるかもしれないので、
そこはぜひ読み替えてくださいって感じですけど。
他者から教わるものがあるっていうのは全然問題ないと僕は思いますので、
その謙虚な姿勢を持ち続けるのは大事だなと思います。
すいません、余談でしたので戻ります。
私たちの誰もがある特定の役割や仕事に対して不十分だと感じることがあるはずです。
インポスター商工群っていうのは正真正銘、非常に一般的なものですと。
それは明らかに成功している人にさえ影響を与える可能性はもちろんありますと。
他の人があなたにアドバイスを求めて見上げているときでさえ、
あなたはインポスターのように、いわゆる偽物というか偽善者までいかないですかね、
偽物のように感じるかもしれませんと。
この商工群が治ることはできないかもしれないですけど、
好奇心を持ち新しいことを学ぶようあなたは投資してくれるでしょうと言っています。
なるほど。この商工群との付き合い方というのをうまいこと補い付ければいいのかなというところですね。
はい。難しいですけど、でも謙虚な姿勢というのが本当に一番かなと思いましたね。
はい。では以上でシニアリティのところは終わりで、続きましてメンタリングですね。
メンタリングはすごく大事なソフトスキルですからね。
はい。じゃあメンタリングいきます。
今日東京は雨なんですかね。
僕今日も外出するんですけどね。
はい。じゃあいきましょう。メンター、指導者とはですね。
指導者というアクスなどの悩ましいところはありますけどね。
はい。いきましょう。ではメンタリングアザーズというセクションからですね。
誰かをメンタリングするということですね。
メンティーが全く間違った場所に行き着くのではなく、
自分がやってみることで習得できるようにタイムリーな情報を与えてガードレールになりましょうと言っています。
早速いいお話から入ってんだと思いましたね。
キャリアの中でメンターやメンティーの役割を果たすことは様々な場面で見られるでしょうと。
メンターとは正式なプロセスである必要はありません。
他の人を指導する機会を探しても良いですし、非公式に指導を受けることも可能ですと。
09:02
他の人を指導することであなた自身も人間力を身につけることができます。
以下はメンタリングをする際に考えておくべき、覚えておくべき重要なポイントですと言っています。
メンターとは規制の解決策を与えるのではなく、自分自身で答えを発見できるように導くことです。
もうなんて言うか、コーチングに近い感じしますね。
メンティーに問題解決のための実験をさせること、リスクと利益を評価するのは彼らが最も良い立場にあります。
ただし答えを見つけるために必要なツールを与えてあげてください。
技術的な問題であれば試すべきアイディアや選択肢を提案しますが、実際の作業は彼らに任せてください。
彼らが考えていることを共有し耳を傾け質問し対話するようにしましょう。
自分で解決できない場合は、自分ならどうするか、なぜそのパターンを選んだのかを説明します。
結果を分析する方法、問題をデバッグする方法を教えます。
問題を診断し解決策を試し、実行しデバッグする際の思考プロセスを共有します。
答えだけではなく問題解決のテクニックを共有しましょうと言っています。
答えだけを教えると、結局その課題に対してだけは分かったことが理解できたと思いますが、
なぜそれがそういうふうな答えになって取り付いたのかというプロセスの話は全然しないので、
やっぱりプロセスこそ第一だったりするんですよね。
逆に言うとそのプロセスさえ身に付けることができれば、答えには勝手にたどり着いてくれるので、
その答えだけを教えるというのとは違うのかなと思ったりしましたね。
一方でその問題というか課題によっては、答えだけを教えて、
その途中のプロセスは皆さんで好きにプロセスを考えてくださいという教育方法もあったりするので、
一概に答えを教えることが悪いという意味ではないですけどね。
コージさんですね。おはようございます。ご参加いただきありがとうございます。
タイトルのある記事をダラダラと読んでまして、今はメンタリングの章に入った感じですね。
いわゆるソフトスキルについての技術記事をずっとダラダラ読んでいたところです。
モニタリングのところで、違うメンタリングのところで、
今そうですね。メンターがメンティに対してどういう態度とかアクセスというか、
対応をとればいいかみたいなところを読んでいて、あくまで答えを教えるのではなくて、
ゴールに導くための良い対応を投げ続けていくというところですね。
そういうガードレールになってあげましょうみたいなのがメンターのやるべきことだというふうな話をされていました。
というところですね。
では続いていきましょう。
オーガニゼーションワイドメンタリングですね。
ちょっと視座の大きいというか視野の高いところに行きますね。
組織的なメンタリングというところです。
メンターシップが新入エンジニアの役割の一部であることを確認するのは、
誰かが他のチーム、ポジションまたは組織に移動したときに重要なドメイン知識を保持することにも役立ちますと。
12:04
組織なので確かにチームメンバーの移動であったりとか、
コンバージョンはやっぱりありますからね。
仮にあなたが誰かのメンタリングに真摯に取り組み、それがあなたの職務の一部であったとしましょうと。
この場合、自分のスケジュールにメンタリング活動のための時間を確保する必要はあります。
そうすることで適切な指導を行うことができ、メンティーの人生に変化をもたすことができるのです。
また、組織によってはキャリアアップのラダーと各ステップの要件に基づいて、
メンターとメンティーの話し合いのプロセスを定めている場合もあります。
そういうことが最初からできている組織というのは本当に素晴らしいなと思いますね。
メンターメンティーの関係ではなくて、いわゆるワンオワンというものもあったりするので、
それを読んでも全然いいと思いますし、それがちゃんと職務の一部であったりとか、
そういうプロセスとかスケジューリングがされているというのはいい話だなと思うので。
はい。
たぶんメンターとメンティーは名前を変えればいろんな役割とかポジションやり方はあると思って、
でも僕はこれ絶対に必要だというふうに思っていて、やっぱり人間ですので、
導いてくれる人とか、やっぱりまだまだわからないことってたくさんあったりするので、
そういうために道しるべになってくれるような人がいるのは結構大事かなと思いましたね。
ただやっぱり道しるべになる側の人は、道を示してあげるだけで、
歩み方は本人に歩ませるのが絶対にいいと思います。
手を引いてあげるのではなくて、道はこうだよとか、こういう道もあるよとか、
その道だと危ないよっていうのを適切に導いてあげることだけをして、
後の歩きとか学びとかっていうのが本人っていうのが一番なやり方だと思いますね。
さらっと言ってすごく難しいんですけど、これ言って。
僕も何回か今までやってきましたけど、本当に大変だなと思いましたし、
ついつい答えをすぐに教えちゃいたくなるのでね。
でもやっぱり大事なのはプロセスなので、
プロセスをどうやって本人が考えることができるかっていう場を提供するのが
一番のメンターかなと思いましたね。
じゃあ続いて、次はメンターじゃなくてメンティーですね。
メンティーズロールっていうところです。
メンターはアドバイスをくれますが、自分のキャリアと成長を管理するために、
どんなアドバイスでも率先して行動できるのは自分だけ、
つまりメンティーだけだよっていうところです。
例えばあなたが組織で成長したいと考えている若手エンジニアだとしましょうと、
その場合あなたへのアドバイスはただ一つです。
成長の階段を登るのを助けてくれる強力なメンターを見つけることですと。
キャリアを積んでいくと、コーチやメンター、
あるいは尊敬する同僚に出会うことは全然あります。
彼らは自分のスキルを伸ばすためのアドバイスをしてくれますけど、
それを行動に移せるのはやはりあなた自身なのですと。
アドバイスを吸収する際には、技術に関する包括的な声に注意する必要もあります。
あるプロジェクトでうまくいったことが、別のプロジェクトでうまくいかなかったことは全然ありますし、
今後はあり得ますよと言っていますね。
はい、というところでした。
なのでメンティも結局謙虚な姿勢っていうのが結構大事なのかなっていうふうに僕は解釈しましたね。
15:02
はい、というところですね。
しっかりアドバイスをしてくれる強力なメンターを探すの、
これも本当に大事ですよね。
メンターがいないと全然成長が変わってきますから。
はい。
またアドバイスを吸収する際も、いわゆる一面だけを見るのではなくて、
広い視野で見に行くっていうのが大事ですし、それを活かすにもいろんな視点があるので、
そういうところをやっぱりメンターに相談をするのが全然いいんじゃないかなと思います。
はい、以上でメンタリングは終わりますね。
結構短かったですね。
はい。
じゃあ続いてのカテゴリーはエフェクティブチームですね。
はい、効果的なチームですかね。
ところに入っていきましょう。
では一発目ですね。
一つ目はビルディング・トラストです。
信頼関係の構築ってところですね。
はい。
だんだんソフトスキルって言うけど、いわゆるメンタルとか精神的なところとかに近い話がどんどん入ってきたなっていうのがありますね。
では行きましょう。
信頼っていうのは共通の目標に向かうチームメンバーを団結させることができますけど、
官僚主義だとチームメンバーを分断してしまいますよって言ってますね。
はい。
なるほど。
信頼は大事だけど、やり方として官僚主義だとあんまり意味ないよってことですね。
エンジニアが集まり偏見のないブレストを行うことで、新しいアイデアや異なる視点が生まれ、イノベーションを推進することができます。
これが高い効率性とか生産性の高いチームの実現につながるんですと。
しかしチームメンバー間の効果的なコラボレーションというのはチームメンバー間のコミュニケーションと関係値が健全になる場合にのみ可能です。
ここでは効果的なチームを作り維持しその一員となるためのいくつかのポイントを紹介していきますと言ってます。
信頼関係の構築っていうのはチームビルディングの最も重要な要素です。
階層を超えたチームメンバー間の信頼関係っていうのは物事を迅速に成し遂げ、チームが効果的に機能するために必要でありますと。
チームメンバーはプロジェクトの健全性を確認するためにレビューやテストなど様々なソフトエンジニアリングのプロセスを施行することがあります。
しかしこれらのプロセスっていうのは信頼関係がなければ退屈で完了的なものになってしまいますと。
例えばあるエンジニアを信用して、信頼して行動を任せれば行動レビューの際に応答を言われることもすったくなるでしょうと。
なるほどです。
ではそんな感じのいくつかのアドバイスの一つ一つを読んでいこうと思います。
1つ目がUnderstanding the Business Modelの理解です。
いわゆる変更ですね。
アップデートとかチェンジですね。
のビジネスインパクトというのを理解しましょうと。
新しい要件セットを受け取ったときその背後にある動機っていうのを理解することですね。
条件定義の文章とかドキュメントの目的であったりとかビジネス目標のセクションに目を通さないようにしましょうと。
18:00
目を通さないようにしましょうと。
ビジネスモデルと要件の関係性を理解するために質問をしましょうと。
既存のコードベースやSME、サブジェクトまたはエクスパーツですねと話すことで、
ドメインとアーキテクチャに関する洞察を得ることができます。
ドキュメントを参照し、機能やユースペースをシステムプロセスやデータフローにマッピングしましょうと。
条件定義ドキュメントの目的とビジネス目標のセクションに目を通さないようにしましょう。
通さないんだ。変わったアドバイスだな。
多くのソフトウェアエンジニアは技術的な課題を解決することが好きです。
ビジネス面を理解し、費用対効果の高い解決策を打ち立てるようになると、よりやり合いを感じることができます。
ユーザーや顧客もあなたと同じように仕事をし、1日や1週間を過ごそうとしている人たちであることを忘れないでください。
彼らの生活を今以上に苦しくしないようにしましょうと言っています。
はい、これなんか翻訳ミスな気がしますね。
はい、理解することが大事だと思いますし、その辺を理解もしくは解釈して、
そこにどう技術的な態度とか方面から貢献できるかっていうところに頭を使って、
実際にアイディアを出して、どんどん解決策を打ち出せるようになると、どんどんやりがいを感じますし、
ユーザーにとっても、顧客に、チームメンバーにとってもより良いことになるんじゃないかなと思います。
エンジニアはやっぱりとにかくエンジニアリングをしたいっていう人の方が圧倒的に多くてですね。
ただ一方でビジネスの話でいくと、エンジニアリングがもしかしたら使わなくてよいみたいな場もあったりしますし、
その方がみんなにとってウィーンな可能性もあったりするので、
エンジニアリングをすることだけに注力するっていうのは、
エンジニアリングっていう選択肢を取るときに大いにパワーを発揮するんですけど、
そもそもエンジニアリングをどういうところで使うのかとか、本当に使う必要あるかとか、
またどのようなエンジニアリングが必要なのかみたいなところの意思決定ができる層に目を向けられるとか、
そこの西座を立てるようになると、よりエンジニアとしての幅とかスキルっていうのがどんどん向上していくのかなと思ったりします。
僕は結構その辺は昔指導を食らったこともありますし、
いろんな若手の子にも一つの観点として伝えたりはしますね。
やはりまずエンジニアである前に仕事としてやるんであれば、僕らはビジネスマンなんですよね。
ビジネスマンとしてどう貢献するかとか、一番のバリーは何だろうかっていうところを理解した、
意識をした上でエンジニアとしてどう貢献するかっていうのを考えることがすごく重要だよみたいなことを結構伝えたりしてますね。
伝えることは安くてできてるかっていうと、僕もいまだにずっと考え続けてますし、
この辺は一緒に考えていきたいというのも今ありますね。
若手の子がどういうふうに感じるかっていうその意見を参考に自分の考え方とか、
価値観っていうのはブラッシュアップもしたいなって思ったりはしてますので。
はい、というところでした。
時間がなくなってきたので、あと1、2個読んだら終わりかなと思いますね。
続いて、インクリースユア・インパクトです。
影響力を高めましょうとですね。
ビジネスとソフトウェアの方式に対する洞察力と鋭い洞察力。
21:03
ソフトウェアの方式に対する洞察力と鋭い洞察力。
なんか面白いな。
あなたの仕事に影響力を高めますと。
ビジネスとプロダクトを360度見渡すことができれば、チームやプロジェクトに積極的に貢献できるようになります。
営業やマーケティングの考え方を理解すれば、正しい判断を下し、インパクトのある仕事ができるようになります。
ほんとおっしゃる通りだと思いますね。
チームの成功への貢献度が高まれば、仕事がより良くできるようになりますと。
チームの成功への貢献度が高まれば、仕事のやりがいも給与も向上します。
チーム、プロジェクト、ビジネスにとって適切なことを行い、監督されることなく、
自立して働き、全体の効率を高めることができる、セルフスターターとしてのあなたの能力を先輩たちは認めてくれるでしょうと言っています。
はい、もうなんかそのまんますぎて、はいって感じでしたね。
この観点もすごく大事なんですよね。
要はビジネス視点っていうところが本当に重要ですし、そこから動けるエンジニアっていうのは、
なると技術力も高い人も評価を受けるかもしれないですけど、
それと同等かそれ以上にやっぱり会社としてはこのエンジニアに本当にいてほしいなとか、
仕事を託したいなって思うんですよね。
思っちゃうんですよね、やっぱり。
物事を進めてくれるエンジニアっていうのは本当に希少価値が高いなと思ってるので、
またみんなにそういう風になってくれたらすごく嬉しいなと思ったり、もったりなじまったりです。
はい。
言うはやっぱり言うはやすし、まず自分がまず先に率先して行わなければいけないなと、正直思ったりしますので、
言った限りはやっぱりやっていかなきゃなっていう覚悟を決めなきゃいけないなと思いますね。
今までやってないかっていうと別にやってきたつもりではあるんですけど、
今後もしっかりそこは継続していきたいなと思いました。
じゃあ次行きましょう。
ワークライフバランスですね。
はい。
技術力、ヒューマンファクター、ドメインナレッジを習得した人であれば、
ソフトエンジニアとしてのスキルは必ずと言っていいほど求められるものです。
チームや組織の人々はあなたに相談するでしょう。
エンジニアとしての仕事に加えてあなたはコラボレーション型の犠牲者になってしまうでしょう。
マドホックな要求があなたの時間を奪い、あなたが情熱を注いでいることを止めてしまうかもしれませんと言ってますね。
はい。
これは本当に陥りがちだというか、
僕みたいにいわゆる、私はもう完全な社畜気質なんで、
仕事が最優先には行動を取ってしまったりするんですけど、
やっぱり人生、あなたの人生なのであなたがどう描いていくかっていうところは重要視した方がいいと思います。
その上でチームとか組織に自分がやりたいこととかっていうのをしっかり相談しつつ、
物事を決めていくし、自分のやることを決めていくのがいいと思います。
もちろん若い頃はいろんなこととか、
頼まないことをどんどん片っ端からこなしていって、
アドホックな要求もあるかもしれないですけど、
自分の経験値とかキャリアの幅を広げていくためにチャレンジをするっていうのは別にいいかもしれないですけど、
逆にそれを通例をし続けたせいで、
どんどんどんどんこの人には頼んでもいいじゃんみたいな認識を他の人にもたられる可能性もありますし、
そういう癖がついてしまう可能性もあるので、
24:03
ここは結構タイトルにあるというワークライフバランスをしっかり考えた上での仕事の取り方とか、
技術とかドメインナレッジの習得の仕方っていうのを考えればいいんじゃないかなと思ったりしました。
というところで30分になりましたので、
今日はこの辺で以上にしたいなと思います。
頑張ったら明日読み切れるかなとは思うんですけど、
今ザーッとスクロールしてるんですけど、
たぶん無理な気がするんで、
5日目に突入しそうな気がしました。
というところで今日の朝活はこちらで以上にしたいと思います。
ココジさんご参加いただきありがとうございました。
また金曜日ですね。
2週間の終わりですけど、
今日も頑張っていけたらなと思います。
それでは朝活終了します。
お疲れ様でした。
