00:07
7月23日土曜日ですね。
時刻は朝9時を回りました。
9時で16分ですね。
ちょっと遅くなりましたけれども、
本日も朝活を始めていきたいと思います。
タイトルにある通りですね、ソフトエンジニアリングの記事をずっと読んでおりますね。
ソフトエンジニアリングというか、
ソフトスケールスの式記事を読んでおりますね。
Googleのシニアエンジニアの方が、
10年間お仕事をされている中で身につけたり、経験者でしたり、
というのをまとめた記事になっているというところですね。
その記事をずっと読んでいるんですけれども、
今日は8日目ですね。
まさか8日に分けて読んでいるんですけれども、
まだ読み終わっていないという、結構長大な記事なんですね。
とても知見と経験値と、かなりの資源と、
たくさんいい学びがあったので、
ぜひぜひみなさんも読んでみていただければなと思います。
はい、じゃあ今日もそのまま続きを読んでいきたいかなと思います。
今日はですね、昨日なんだっけ、
ワークライフバランスまで入った気がしますので、
今日はそこの続きを読んでいこうと思いますね。
というところで、
今日のワークライフバランスのチップスの中の一つ目はですね、
タイムマネジメントのところからですね、入っていきたいと思います。
ここ結構長いんですよね、やっぱり。
タイムマネジメントってやっぱり大事だなっていうか、
やはり人間が持っている一番の資産として、
無形資産だけど、資産というと残るものみたいな感じがしますけど、
大胆な資産、わからないですけど、
一番価値のあるものってやはり時間なんだなというふうに思わされているような感じですね。
はい、余談は終わっておきにやっていきましょう。
タイムマネジメントです。
タイムマネジメントです。
ディープワークのためにカレンダーを最適化しましょうと。
カレンダーに集中して深い仕事をするための時間を割り当てます。
私は何年も前からこの方法をとっており、
デザインや戦略のドキュメントを書いたり、
難しい技術的な問題に取り組んだりするときに、
非常に効果的だと信じています。
ディープワークとは気が散ることなく高い集中力を発揮し、
少しの時間でも多くの価値を生み出す仕事のことを言っています。
カレンダーニューポートのディープワークというのが
このトピックをよくカバーしていますよと言っていますね。
カレンダーニューポートディープワークというのがあるんですね。
これは僕が知らないものだったので。
注意力残量。
注意力残量というのが一応バルベットであるらしいですね。
というものがあって、
それは彼が語る長時間深く働くことがなぜ有益であるかという考え方だと言っていますね。
長時間深く働くことがなぜ有益か。
そりゃそうだよね。有益だと思いますけど。
人間の集中力って確か1.5時間しか続かないみたいなことを言った記憶がありますね。
03:02
どんなに頑張っても2時間くらい人間の集中力が続かないので、
その後に休息を取らないと、
そもそも脳のエネルギーが枯渇してしまうみたいな話を聞いたことがありますね。
はい。
ゴージさんとセラノードさんですね。
ご参加ありがとうございます。
今日もタイトルのある記事をダラダラと読んでいます。
多分今日で読み終わる予定なんですけど、
もしかしたら終わらない可能性もありますね。
やっぱりそれだけ長かったんで。
今はワークライフバランスの項のタイムマネジメントのところを読んでいますね。
という感じで続きを読んでいこうかなと思います。
あるタスクから別のタスクに頭を切り替えるたびに
注意力の残量というのがどんどんなくなって動けなくなってしまいますと言っていますね。
これでは本当に重要なことに必要な集中力を持って仕事をすることができませんと言っています。
ディープワークというのは一つのタスクに集中することで
限られた時間の中で最大限の算定を生み出すことができます。
ツイッターもチャットもメールも聞かせることはありません。
ディープワークというのは認知的に重いタスクのために確保するので
ぜひ試してみてくださいと言っています。
そのディープワークという名前の仕事の仕方をこの方はされているということで
とにかく重い時間しかも限られた時間にしっかり集中しなきゃいけないというもののディープワークと言って
それをやるためにいろんなものを排除しましょうと言っていますね。
また場所を変えることも重要だと言っていて
ディープワークが図ることもあるためには例えば特定の場所ですね
デスクであったり部屋であったり建物といろんなものの条件があると思うんですけど
それは特定の種類のタスクに関連づけるという罠に陥ることがありますけど
少し変化をつける、加えるだけで再活性化することもできたりしますよと言っています。
でもそれはあるかもしれないですね。
習慣化のテクニックで例えばこの場所に行くと自分は仕事モードになりますとか
ここに行くともうダラダラするオフモードになるみたいな
要は頭の認知をそうやって切り替えているっていう人ももちろんいるんで
一概にこの発言はそうなんだって思うことは僕はちょっと難しいと思いましたね。
すごく仕事部屋がちゃんとあってその仕事部屋に出たときは基本的にオフモードだっていうふうに切り替えをしています。
逆に言うとまさに今この部屋が仕事部屋なんですけど
この部屋に入るとだいたいやっぱりモード切り替えっていうのができたりしますので
まああると思うんですけど
でもそういうものを特定のタスクに関連づけるという罠に陥ることがあるというふうに言ってますね。
そういう人もいるんだなって感じで僕はちょっとそれがなかったなっていうのはあります。
それを少し変化を加えることで全然静化することもできたりしますよというふうに言ってますね。
ここからまたもうちょっと小さい細かなチップスがどんどん続いていく感じですね。
チップスなんですけど一つ目はアボイド
06:05
フラクチャリングイヤーワーキングアワーズですね。
ロード時間の分断を避けましょうと言ってます。
1時間の仕事が注意力3万のためにわずかな水分の塊に分断されてしまうとストレスになりますよと言ってます。
気が散る原因を特定してそれが自分であれ他人であれそれを解決しましょうと。
そうでなければあなたの賃金は生産的でなくなりますと言ってます。
いろんな外的要因で仕事が中断されたりその注意力を削られているみたいな状況があるんだったらそれを排除しましょうと言ってますね。
2つ目ですね。
ワーキングインエクセスイズンパートグッドワークリスティックですね。
過剰に働くことっていうのは良い仕事を買うの一部じゃないよと言ってます。
あなたは決して世の中の誰よりも一生懸命働くことはもちろんできませんと。
多くの企業は働き過ぎの社員を標準として持ち上げそれが優れた労働倫理を持つことと同じだというふうに誤って結論付けています。
成功は様々な要因から生まれるもので働き過ぎだけではありませんと言ってます。
これをGoogleのシニアエンジニアが、しかも10年間Googleで頑張った方がおっしゃるっていうのがかなり大きいと思いましたね。
逆に言うと、世界でも同じようなふうにたくさん頑張って長く働いている人っていうのがやっぱり持ち上げられたり評価されているっていう現実があるんだろうなっていうふうな裏の背景があると思いました。
結構日本だけの話かと思ったけど、全然海外でやっぱりあることなんだろうなっていう、少なくとも読み取れた感じですね。
ただ一方で、最近の日本人って実は働く時間が短いって結構海外でも言われて、そんなに統計データがたくさん出てきてるんですよね。
もちろん良くない企業とか、いわゆるブラック企業のところで働かれている方もたくさんいらっしゃって、
僕も昔、新卒の頃は当たり前に300時間とか月平均働いてたんですけど、そういう方を除いてしまって、
しっかりいわゆるホワイト企業であったりとか、有給もしっかり取ったりするような方々っていうところが、
日本の労働時間の平均値を下げていると思ってて、それを良い悪いっていうのはなかなか難しいし、
結果として日本の売上が下がってる、全体としての価値の創造が下がってるっていう話があるんだったら、
それはそれでまた頑張って働いた方がいいんじゃないのっていう見方ももちろんあるし、
でもやっぱり仕事が人生ではないよねっていう意見もあったりして、いろいろまちまちではあるんですけど。
でも日本はやっぱり世界と比較すると単純に労働時間の平均時間だけ話をすると、だいぶ日本って低いらしい。
休みすぎだって言われることもあったりしますけど。
ちょっと余談でした、すみません。
でも過剰に働くことが仕事株としてそれは良いことだっていうふうに言うのは一概に言えないよねって話をこの方がおっしゃってますね。
続いていきます。
はい。
次はコンスタントにtrying to outdo your standard is unrealistic。
09:00
はい。
常に自分の基準を超えようとするのは実は非現実的ですよって言ってますね。
はい。
私はこのことに何度も罪悪感を感じてきましたと。
冷静さを養い、狂ったような職場環境を避けたいのであれば十分な余裕を持つことですと。
マネージャーやリーダーとしてあなたのチームにこれにどうアプローチするか、あなたのリードを受けるかもしれません。
十分でOKということは良い抵抗になりますと言ってます。
はい。
なるほどですね。
なかなかこれもこれで難しいと思います。
狂ったような職場環境ってのはどういうのかちょっと具体的に聞いてみたい感はありますけど。
でもそういうところを避けたいとかそういう状況を変えたいならばまずは余裕を持つことって結構大事だなって僕もずっと思いました。
はい。
やっぱりシステムもそうですし人間の脳もそうなんですけど余裕とか余白がないと何か新しいこととか別のことを考えたりすることが全然できなくて、
目の前のことに雑集中するしかないみたいな状況になりかねないので余裕を持っておくことはすごく大事ですし、
特にリーダーとかマネージメントする方こそ余裕を持っていただきたいなと思いますね。
そういう方がやっぱり余裕がなくてずっと大変だっていうふうな見え方をするとやっぱりメンバーのもの、
一緒に働くメンバーとかのが割と不安になると思いますしね。
はい。
というところでやっぱり余裕っていろんなところでも大事だと思います。
余裕ないと多分家庭環境も正直影響出ちゃうんじゃないかなっていうふうなちょっと邪推もしたりしました。
はい。
余談が過ぎたので戻ります。
次ですね。
時間を有限であると。
より多くの時間を求めようとするのではなくて、
不要な仕事を排除するというところが大事ですねってことですね。
はい。
もうそれに尽きる。
はい。
多くのガイダンスが仕事の配置をより良くすることについて述べています。
本当の問題はそもそも多くのことを成し遂げようとしすぎていることと言っています。
限られた時間をどうにかしようとするのではなくて、
不必要で時間を浪費する仕事を徹底的に排除しましょうと言っています。
はい。
やっぱりその通りでしたね。
はい。
日本の場合だけでちょっと言うと結局は会議を減らせばいいんじゃないかと思ったりします。
会議の数を減らさないのであれば会議の時間を減らしましょうとかですね。
最初からちゃんとアジェンダを共有しておきましょうとか、
逆に参加する人もちゃんとアジェンダしっかり見てから参加しましょうと。
もっと言うと見てない人は参加しなくて結構だと思ったりしますけど個人的に。
はい。
とか。
本当にこの仕事が要るのかっていうのは結構大事で、
チケットとかタスクどんどん振られるんですけど、
そもそもこれはやる必要あるのかっていうところとか、
なぜこのチケットをやらなきゃいけないかっていうのをしっかり、
タスクを振られた側はその視点で見ていかなきゃいけないし、
振る側のほうもなぜこれをやるのかっていうのをちゃんとチケットに書いておくっていうのはすごく大事なことかもしれないですね。
はい。
結果として不要になることなんて全然ありますし。
僕らは結構システム開発者なんですけど、
システムの機能の大体80%ですね。
12:00
利用度の80%はそのシステムの2、3割の機能しか使われないっていうのはよくある話だったりするので、
統計とか研究データもあるらしいですね。
なので本当に必要なところに必要な労力と時間をかけるのは本当に大事なことだと思いますので、
せめて優先度はしっかり決めるというのは当たり前の話かもしれないですけどね。
やっていくのがいいのかなと思いました。
はい。
続いて限られた時間を有効に使うこと。
結構さっきと被るような気がしますが、
我々の多くは新しい話や更新とかアップデートを見逃すことを結構恐れています。
これが例えばTwitterであったりRedditだったりInstagramなどを1時間ごとにチェックすることに夢中になる理由の一つだよと言っています。
私もこの経験があります。
実際にはこれらの情報のほとんどはそれほど重要ではありません。
その代わり、そのニュースの要約標準に切り替えてみたり、チェックする頻度に制限を設けてみてください。
このテーマについては、Jason Friedという方がいらっしゃいます。
その詩のIt doesn't have to be crazy at workにも詳しい考察があります。
一応この記事もリンクが貼っていますので、そこを見てもらっていいんじゃないかという感じですね。
難しいですね、確かに。
僕も結構Twitterとかは、仕事中だとはいえ、ちゃんとチェックしたりしますね。
更新を見たりとかしていて。
1時間ごとにチェックしているかというと、もっと頻度が多い気がしていて、よくないなというのが分かっています。
一方で会社の顔としての動きもやっぱりしなきゃいけないなともあるし、
広報的なところの話もあったりするので、
本当は仕事のTwitterをどんどんした方がいいと思ったりしているのって難しいですけどね。
役割として、そういう広報とかの面の仕事をしている人がいるのであれば別にそれは良いと思うんですけど、
そうじゃない人がTwitterとかReddit、Instagramなどをしょっちゅうチェックしたりするってことは、
あまり良くないことじゃないなというふうに思っていますね。
あとは情報ってジャンクフードと同様で、
やっぱり良くない情報もたくさんあるし、
でもTwitterとかで特にそういうどうでもいい情報とか、
面白いんだけどその一家制のものだったり、
いわゆるジャンクフード的な情報もたくさん流れてくるので、
食べるのは結構ですけど、ジャンクフードばっかり食べると、
いわゆるくだらない情報ばっかり仕入れていると、
やっぱり自分の時間も浪費になったり、インプットとしては全然良くないので、
僕はそういう捉え方をしてTwitterを見るように最近はしていますね。
続いていきましょう。
続いて、NOと言えるようになること。
NOとはNOのNOですね。
NOと言えるようになること、また辞めるべき時を知ること、
仕事の合間に休憩を入れるなど、
積極的に自分を疲弊から救うことが一番ですよと言っています。
時間管理とワークライフバランスの維持というのは、
あらゆるレベルのエンジニアにとって非常に重要です。
定期的に残業をすると、
萌えつき症候群やストレスにつながる可能性があります。
去年の俺です。
15:01
ストレスは他の身体的・精神的な健康障害を起こす可能性があります。
問題を解決してから休業したいと思うかもしれませんが、
時間が経つにつれてそれが習慣になる可能性があります。
今の俺です。
自分自身とチームの両方に休憩・休日・休暇を奨励しましょう。
はい。
ちょっと言いたいお言葉です。
あなたの健康と家族はとても重要です。
シニア・エンジニアとしてこのことを自覚し、
チームの他のメンバーに優れた模範を示すことができれば、
全体的な健康や幸福を伴っていきます。
一方、疲労困廃して萌えつきると、
職場に毒気が漂うことになります。
ということで、チームもそうですし、家族もそうですし、
とにかく悪影響ばかりだなという話ですね。
はい。
本当にこれは僕は悪い癖で、
チケットが終わっていなかったりとか問題が
あとちょっとで解決できるようになったら、
全然残業すぐすぐしちゃいますし、
やっぱりそれがまさに習慣になってしまっていますね。
これは分かっているし、自分ができていないことなので、
自戒を込めて言うと、
就業時間が過ぎたらエリアでやっぱり終わるというのは結構大事ですね。
その終わる間に終わって次の仕事まで、
実は最初の方は結構モヤモヤしたりとか、
いや終わってないんだけどなというストレスになるかもしれないですけど、
結果、そっちの方がいいとは僕はもう言いますね。
やっぱりしっかり8時間という、
労働時間の定義があるのであれば8時間だけ働くというので、
そこをしないと脳がまだまだやれるじゃんというので、
おたらだな仕事をするというような逆に認識をしてしまいがちで、
8時間で集中をするということができなくなるというのも
多いにあり得るので、
もちろん終わらせるということはすごく大事なことなんですけど、
終わらせるからこそ、
終わらせるために普段の労働時間の生産性というのが
下がる可能性も多いにあるので、
終わらなかったというのをしっかり自分の中で咀嚼受け入れて、
じゃあ次回終わらせるためにどうしようかという
ネクストステップの話ができるようになってくるので、
しっかり時間内に終わらせることを集中する。
終わらなかったらなんで終わらなかったという振り返りをするのは結構いいことだし、
次回はどういうネクストアクションをトライするかという振り返りをするのが
全然いいのかなと思いますね。
これは完全に僕のための振り返りというか、
次回のお言葉だったような気がします。
では続いていきましょう。
一応30分過ぎたんですけど、
今日は僕が9時15、6分にスタートしたので、
終わりは今日45、6分にしようかなと思っています。
では続いていきましょう。
問題に対する理解が深まれば、見積もりも更新をしましょうと言っていますね。
はいはいはい、なるほど。
あなたの仕事の顧客や利害関係者というのは、
プロジェクトやタスクをいつまでに提供できるのか、
このコストは見合うものなのかを知りたがるものです。
これは全く妥当なことです。
時には納期に合わせたい場合もありますし、
18:01
他の場所に依存関係があってエンジニアリング作業をサポートするために
計画が必要な場合もあります。
ソフトウェアの納期というのは、
正確に予期されることが難しいことで知られています。
見積もりに基づく納期というのは、
プロジェクトが特定の段階にあるときのみに与えられるべきですよと言っています。
うんうんうん。
時間がゲガするとチームの問題解決能力に関する情報が得られるので、
見積もりは更新されるはずですと。
インフォームド見積もりみたいな話もあるらしいですね。
インフォームドな見積もりっていう。
まあまあそういう言葉があるんですね、海外の言葉。
日本ではあまり聞いたことない言葉な気がしますけど。
最初の見積もりっていうのは、いわゆるサイジングですね。
っていうのは最も信頼性が低いことが多いんですけど、
これは出発点である時間の経過ともに改善されていきますと。
製品の要件やUX依存関係というのが不明確な場合は、
最初のサイジングにはより保守的な見積もりが有効です。
私はこのような見積もりをPMと共同で行って、
全員が同じ考えで見積もりを改良することで、
この成功を定めることができますと言っています。
まあやっぱり最初の概算見積もりは結構限界がありますよね。
僕も仕事でよくよく契約前とか、
最初の商談レベルのところでお客さんに、
ざっくりこんな感じなんですけど、どれぐらいの予算でやればいいですか、
みたいなこと言われるんですけど、
その予算取りをするための見積もりがしたいので、
本当は情報が欲しいんですけど、そんなに決まってなかったりとか、
お客の方でもまだまだ方針練ったりしてる。
ただでもこういうことをやりたいっていうのは確定してるみたいな話もあったりするので、
結構概算見積もりしますけど、難しいなと思いました。
文字通りサイジングなんだろうなと思いました。
大体全体のボリューム感これぐらいだろうなっていう見積もりでした。
その後にしっかり見積もりの精度を上げるとか、
細かく細かく具体的なもの、
青写真からもうちょっと設計書レベルまで落とし込めたりしたときに、
見積もりがどんどん変わっていくので、
それをちゃんとお客さんと共同できるかとか、
もしくは事業会社でもステークホルダーだったりとか、
チームメンバーのその辺のアップデートをちゃんとして、
見積もりとか納期っていうのをちゃんと見直しましょうっていうのが、
合意できているんであればこれは本当にいい話だと思いますけど、
とにかくやっぱり最初の方のエリアでお金を決めて納期も決めたら、
基本的にはそのまま方針打ち出してしまうとか、
経営方針的にもじゃあここを目処にこのシステムをどんどん打ち出して、
そこからいろんなものを改善したいとか、
ビジネス加速させたいっていう要件もあるので、
これ結構難しい話だと思いますね。
もはや未来予知に近い感覚が僕らはあるんですけど、
未来予知でシステム開発してビジネスを進めるのは結構危険だと思うので、
まず最初に最初のこの見積もりあくまで見積もりではなくて、
未来予知ですよっていうところから、
あとでちゃんと見積もりをしましょうねっていう合意を取るのが結構大事なのかなと思いました。
続いていきます。
ソフトウェアの見積もりで厄介なのは、
その最初のラフな見積もりが最初のドラフトではなくて、
記録された計画として固まってしまうことです。
21:00
はい、やっぱり同じこと言ってましたね。
クリティカルパスのチームがそれを採用しても、
見積もりの調整をエンジニアリングによる一時的なものとみなすと、
情報に基づいた見積もりのステップの話ですね。
N分の1ですね。
と比較してこれが問題になることがあります。
プロジェクトに誤差異が出たら詳細を把握することですと。
これは何が要件に対応するのかをより深く理解することで、
3ヶ月の見積もりが2ヶ月もしくは4ヶ月になることを意味するかもしれません。
可能であれば見積もりがスケジュールを動かすのではなく、
スケジュールが見積もりを動かすようにしたいものですと言っています。
これいい視点ですね、確かに。
見積もりがスケジュールを動かすのではない。
でも結構見積もりがスケジュールを動かしちゃうのが現場なんだよなと思ったりしますけど。
でもスケジュールが見積もりを動かすようにしたいものっていうのも結構いい話だと思いますね。
私のチームでは動かせない期限、例えばカンファレンスとかがある場合もありますが、
見積もりがその期限をオーバーシュートしても多くの場合、問題は実はないよと言っています。
メッセージングの変更、例えばプレビューであったり、
もしくはフレーミングですね、近い将来のフレーミングであったりとか、
将来の納期などっていうのは常にリーダーシップと話し合うことができるオプションだよと言っています。
もちろんこれがいつも簡単なことではないことは承知していますし、
スケジュールが引っ張られる場合、仕事を必要なものと必要でないものに分け、
そしてこれらに合わせて将来のスプリントを移動させると。
そういうことをしつつ、必要なものが期限に合うかどうかを見直すことができるのであると言っています。
アジャイル的な仕事の仕方かなというところですね。
やっぱりウォーターホール的にガンってやるのはGoogleの方でもしんどいっていうか、
そういうことは難しいねっていうのもあるんだなと思いました。
そもそも僕ら多分ウォーターホールやったことあるってみんなおっしゃいますけど、
できたことがあるっていう事例を僕は聞いたことが一回もないんですよね。
だいたいウォーターホールでやってますっていう話は聞くけど、
ウォーターホールでできた、成功したっていう話を、
本当にできた人ってすげえなと思いますけど逆に言うと。
僕はできたことは一度もないですし、
ウォーターホールできない理由はやっぱり後から出てきた要求であったりとか、
後から見えてきたことっていうところで話がこじれてきたり、
もう前提条件変わったっていうので、
そもそも見積もりし直さないといけないじゃんって話がよくあったりするので。
やっぱり最初のうちに要件定義のレベルから、
全部を未来予知できることは不可能だよねってことなんですけど、
なのでしっかり見積もりや精度をどんどんどんどんスケジュールとの話し合いの中で、
変わっていく見直しをしていくことがやっぱり大事だよねっていう話でしたね。
それが本当にできればなーっていう遠い目をしたい感じがありますが。
続いていきましょう。
それでもスケジュールが難しい場合、厳しい場合っていうのは、
このプロジェクトにエンジニアを追加できないか、
もしくはスコープを大幅に縮小しても納期に間に合わせることができないか、
など様々な質問をすることができます。
これはよくある話ですね。
プロジェクトのキャンセルってなった時には、
24:01
解ではあっても正しい判断だと言っています。
どうしてもやばいというか、
これはやっぱり振り返りじゃなくて向き直りをしなきゃいけないんじゃないかっていうところで、
一旦今のプロジェクトを閉じるっていうところですよね。
これは正直に言うと不快かもしれないし、
コストをかけた結果、利益が出ないかもしれないですけど、
正しい判断だというふうに言っていますね。
もしかしたらそれによって、
生まれるお金よりも出ていくお金が増えたりする可能性もあるので、
そこを先に見てリスクヘッジとして閉じるっていうのも結構大きい結果だと思いますね。
これは嫌なことなんですけど、
プロジェクトをキャンセルすることがチームや組織にとって、
長期的に最も健在な判断になることもあります。
2、特にプロジェクトを立ち上げる前にキャンセルした場合、
このプロジェクトに関わるスタッフが維持できなくなって、
最終的に非推奨となる可能性があります。
ちなみに私はKilled by Googleっていう記事があって、
それを読みましたと。
この記事はまたツイートしますね。
あとでツイートします。
プロジェクトがキャンセルされるような状況をできる限り少なくすることを目指しましょうと。
最近数年掛かりのプロジェクトをキャンセルして大変な思いもずっとしました。
どのような場合に起こり得るのでしょうか、そういうことは。
新しいプロジェクトへの投資について、ある時点では正しい決断を下すことができます。
その時点では星が一列に並んでいる。
星っていうのは多分マスト要件とかなんですかね。
星が一列に並んだっていうのに、
例えば市場的合成だったり、組織の賛同であったり、スタッフの確保だったり。
はいはい、そういうものですね。
必然に理にかなったものであるかもしれません。
しかし1年後には市場とかリーダーシップ、プロジェクトの重要性など、
様々なことが変化している可能性の方が高いですよと言ってますね。
プロジェクトを開始時に設定した前提というのが、プロジェクト期間中も継続して正しいかどうかを定期的にチェックすることがやっぱり重要ですということですね。
振り返りをしっかりしましょうというのと、振り返る中でやっぱり変化しているものに受け入れて、
受け入れては認めて、ブラッシュアップというか改善するとか更新もするというところですよね。
その前提が正しい確信が持てるのであればあるほど、
プロジェクトの立ち上げに成功してサポートを受け続けることができる可能性が高まります。
キャンセルには様々な理由がありますが、
特に立ち上げを期待して投資してきた生身の人間というか、生身の感情を持っていることが挙げられますと。
感情もある中でキャンセルになったというのも仕方ないとは思いますけどね、個人的には。
もちろんビジネスなんで感情をできるだけ排除して合理的な判断とか、
お金とか時間とかっていうところからの意思決定をすることが重要だとは思うんですけど、
やはり僕らも名前なんでね。
リーダーとしてキャンセルされたプロジェクトから立ち上げに成功した他のプロジェクトへと人々を導くことは複雑ではあるけど、
人々を心理的安全とか信頼とか幸福の場所に戻すためにはやはり重要だというふうに言っています。
これできるリーダーは本当にすごいと思います。
27:01
でも経営者はしなきゃいけないんでしょうねというのはありますけど。
顧客側ではユーザーの信頼とあなたの長期的な決断がどのような影響を与えるかというのを結構意識してみてくださいということでした。
もうちょっとだけ読みますかね。
45分が近づいてきているので。
もうちょっとだけ読みます。
今日読み切れるかと思ったんですけど、やはり読み切れないのであとちょっとだけ読んで終わりにしようかなと思います。
区切りが悪かったりするので。
明日はこれの最後残ったところを若干読みますけども、結構短いのでまた別の記事を読んでいこうかなと思います。
では最後のところを読んでいきましょう。
最後ですね。
技術的な塞いについてというところですね。
1オンスの予防は1ポンドの治療に値する。
なるほど。
お金の単位ですね。
日本でいうと円の予防は万の治療に値するとかそういう話かな。
タイタス・ウィンターズ氏っていう方がいらっしゃるらしいですけど、
その氏は技術的な塞いというのを現在ある行動やシステムとあればと、あればいいと思うものとの差だよというふうに定義をしています。
現在ある行動やシステムとあればいいなと思うものとの差だというのが技術的塞いだというふうに言っています。
ある種の塞いが他の塞いよりも大きな影響を及ぼすと述べています。
ある種の塞いというのは早期に発見できなかったミスとか見落としによるもの、もしくは事後的に判明したこと、後からの知恵によるもの、そして技術システムの状況が変化したコンテキストによるものですと言っていますね。
技術的塞いに一貫して優先的に取り込むということは時に難しいものですと言っています。
この種の作業に対するチームの関心を維持し、強制経費評価でそれに報えることも実に重要です。
しかし問題が長期に渡って積み重なってくると治療のコストが非常に高くなる可能性があります。
汚染と同じように技術的塞いを防ぐことは何年もかけて後になってから可能するよりも安上がりの戦略ですと言っています。
はい、まあそうだよねっていうのは十分承知しているし何度も経験しています。
やっぱり技術的塞いは細かく細く、こまめに改善していくし、解消していくのが絶対に良いと思います。
よくある話ですけど、to doとかfix meとかコードを書く上でいろんな事情を書きますけど、
それを一気にダンと後で解決しましょうといった結果、解決しないままリリースするなんてよくある話なんで。
リリースしてしまって、ユーザーも使っているしお金も生み出されているので、
余計にそのto doとかfix meを直すとに対するハードルが爆上がりするので、
直すんだったらスパッとそのまま直したほうがいいし、
桐和田さんはリアルタイムでリファクタリングとブラッシュアップをできるエンジニアというのが優秀なエンジニアという一つの見方をしていましたね。
それだけではもちろん言っていないですけど、その辺はすごく共感を覚えます。
なので、どのような不採とか汚染があるんだったら小さく小さく少しずつ緩和していくというのが一番いいなと思いますね。
30:03
問題が起きたときが一番コストが低いですからね。
では不採が蓄積されないのはどうしたらいいんでしょうかというところですね。
テクニカルリードというのはスプリントにおいて新機能の開発に加え、
プリンアップと不採の編載に定期的に時間を割くべきです。
レビュアーは短期的な速さを追求するあまり、
かえって後々の問題につながる可能性があることを認識する必要があります。
マネージャーやディレクターというのは既存のプロジェクトと重複する新規プロジェクトを承認する際には
トレードオフの関係にあると確信できない限りは注意が必要です。
例として既存のシステムの不採を処理することと新しいものを構築することの間にそれだけの価値がない場合とかですね。
もうそもそも不採じゃないか。
その上でプロジェクトの健全性をモニタリングすることが非常に重要です。
モニタリングすることが本当に大事だと思います。
プロジェクトの健全性をどうやって指標として可視化するかは別の議論もあるかもしれませんが、
できるのであればそれを絶対にしたほうがいいなと思いました。
時間をオーバーしましたが、
すごい中途半端な発言がいきなりですが、
今日の朝方はここで区切らせていただければなと思います。
明日は残りを読んでいきたいと思いますが、
最後にもうちょっとだけ読んで結論を読んで終了という感じですね。
長々とこのソフトエンジニアリングのソフトスキルの話をずっとしてきましたけれども、
今日はよりタイムマネジメントということで、
実践的な話が結構近いのかなというふうには感じました。
というところで、また明日もよろしければお呼びいただければ嬉しいなと思います。
明日はなるべく寝坊しないように頑張っておきます。
ご参加いただいた多くの方々、大変にありがとうございました。
明日も一緒に学べたらよいなと思っていますので、よろしくお願いします。
今日も土曜日にゆっくりと休日をお過ごしいただければなと思います。
では朝方以上にしたいと思います。お疲れ様でした。
