00:09
みなさんこんにちは、TRY-CATCH FMです。このポッドキャットは、それぞれの企業で働くソフトエンジニアとプロダクトマネージャーの2人が、
テック、キャリア、ライフスタイルなどをテーマに、雑談形式でお送りする番組です。では、やっていきましょう。
はい、よろしくお願いします。
はい。
来年からか、来年の頭から新入社が始まるじゃないですか。
まだ何も準備してない。
12月の前半だっけ、どこかまでに設定をすると、1月の新入社のスタートを切れる、みたいな感じらしい。
ああ、そういうことね。一応、レッドラインがあるんだ。
結局、システム範囲の話だから、多分、証券会社による。
SBIは12月のそこそこのタイミングだったような気がするんだよな。僕はSBI証券使ってるので。
なるほど。
枠がめっちゃ増えるじゃないですか。
そうね。
それを最速で埋めるんだっけ、どうなんだっけって話がまず1個あると思うんだよね。
年間360万までいけて、最大枠の1800万まで、最短5年で埋められますと。
はい。
そんなに当時に今の自由意識使うんか。見動き取りづらくなって、今を楽しめなくなるのでは、みたいな話はちょっと感じる。
それはある。それはある。
まず大前提、いくらぐらいのスピードでいくかっていうところと、積み立てと成長枠が両方つくじゃないですか。
今まででいう積み立て型とニーサができるみたいなね。
あれを何かキャピタルゲイン狙いでいくのか、手堅くいくのかみたいな話が、ニーサって免税だからどっちの方がどっち向きだよねみたいな話とかってあるじゃない。
反応するかなっていうのがね、ちょっと悩ましいんですよ。
いや本当ね、今日まさにやらなきゃなーと思ってたんだよね。
基本的な考え方というか、
僕らって全世界株なりS&Pなり999なりの良さそうなところに積み立て投資をしてきてて、そいつは右肩上がりになっていくはずだと思っているところがあるわけじゃないですか。
何だったら、できるだけ早いタイミングで最速全枠埋めたらその後右肩上がっていくんだから、それがいいよねっていう話がないではない。
それで5年間で最速で埋め続ける。何なら過激派の人は1月の一番最初にボーナスアップみたいな感じで使って、
350万ぐらい全部埋めて、残りは月2万ずつぐらいの積み立ての手をなすみたいな設定ができるらしくて、
それをやるって言ってる人もいたことがあるぐらいなんだけど、実際誰もわかんないんだよね、いつ上がるか下がるかって。
だから理論上最速で埋めるのが基地はわかんなくはないんだけど、そこで下手っこいって大損をしないために定期的に積み立てをしてたんじゃなかったのかっていう話がうつらあって。
そうだね。
だし、日本の影響力がどのぐらいかわかんないけどさ、
例えばこれでそれなりに価格が日本人に人気の何かS&Pの投資の金額が上下するレベルだったとしたらさ、
そのタイミングでお金持ちの人は一瞬で威嚇しようとしないかなとか、
ちょっと思うんだよね。
投資、よし始めるぞって人がかもらえるガチなことを考えると、そのタイミングでみんなと一緒にやったら、
そのタイミングで売り抜けたりする人とかの影響に損はせんだろうかみたいな、
いろんなことをぐるぐる考え始めて、どうすんだろうなみたいな。
ねー。
あーそうか。
いくら埋めるかは結局自分の余剰との相談になると思うから、
そうだね。
それとして、キャピタルゲイン的なでっかい枠狙う?
それとも堅実に上がってはいくだろうけど、配当とか何々で手堅いのにいく?
いやー手堅い。
それと言うと手堅いパターンでしょ。
そうかそうだよな。
うーん、うーん、そうだね。
結局積み立て的なやつに振り切れるんだったら、
全部ETFに積んじゃっていいとは思うんだけど、
はい。
まあ、総益通算できないっていうのがあるから、あんまり負けると辛いっていうのはありつつ、
でっかく買った時にさ、
税金に持っていかれなくていいっていうドリームな部分があるから、
あ、そういうこと?
あ、そうだね。
あれ、総益通算できないってどういうことなんだっけ?
もともと、まず税金を、株の利益で税金を取られる話を兄さん抜きで考えた場合は、
買った分の20%を取られるみたいな感じで、
だけど、前の年に100万負けて今年150万勝ちましたってなった時に、
ちゃんと確定申告とかしてたら、
総益通算されて、結局プラス50万買ったよね、になるから、
50万の20%しか取られないってなるんだけど、
兄さんだと、別に結局税は取られないんだけど、
100万負けて150万買ったけど、
負けた分も買った分もなしになるからいいのであって、
結局、兄さん無しで株をやってたことに比べて、
どっちが得かみたいな話で考えると、
大穴狙ってでっかく買った場合は、
税金がなくて嬉しいなの割合が高くなるような、
ちょっとしたブリーム的な部分があるような、
っていうくらいの話。
だけど、そういうのをずっと考えまくるのも大変だから、
ひたすら積み立てをやるとか、
自分が信じてる企業が1個見つかったら、
そいつには振って、あとは全部積み立てとかにして、
そいつは宝くじだと思って、
信じて待つみたいなのは楽しいかもしれない。
そうか。
いやー、俺それもやんない気するなー。
やっぱもう普通に、
当心択1本でいくかもな、やっぱり。
正直、応援したいものとか、
これは来るって来るだろうから置いときたいみたいな、
やりたいでやるのがいいと思うんだよね。
そうだね。
やりたいがなかったら、
絶対思えばいいの、本当に。
積み立てたらいいと思うんだよ。
寝かした方がいいです。
っていう感じなので、
新ニーサやろうと思ってる方は、
スタートダッシュのために12月のそこそこのタイミングで
やってほしいということをお勧めします。
はい。
あざます、あざます。
技術的不細の定義と組織設計の関係
じゃあ、本題ですね。
はい、本題なんですが、
技術的不細の話なんですよ、ざっくり言うと。
技術的不細ってよく言われてる、
いろんなところで話がなされると思うし、
これも技術的不細の何たらかんたらみたいな、
イベントじゃないな、
それ系のプレゼンを集めた回みたいなやつの
多分スピーカーデックを
今日共有しようっていう話なんだけど、
タイトルとしては、
ソフトウェアの内部品質に生じる様々な問題は、
組織設計にその原因があることも多いっていう話。
じゃあ、技術的不細に限らずっていう話?
でも中身は割と技術的不細の話って感じかな。
本当だ。
これは松本重幸さんっていう人が書いてくれたやつで、
どこのとは書いてないのかな。
あるソフトウェアプロジェクトを開発する組織の
エンジニアリングマネージャーの方が、
B2Cの会社の方が書いてくれたやつで、
技術的不細についての定義みたいな、
今回扱うのはこういうやつだよ。
今回問題だと思っている技術的不細はこういうやつだよ
っていうのをまず最初に言って、
それは結構こういう組織で起こるよね。
だから組織が原因になっていることがあるよねっていう話と、
あとは結論としては結局やっぱり経営者の人と
そこをちゃんと認識として共有して、
ちゃんと説明できるようにして、
なんとかしていこうでは結局そうなんだけど、
それの原因の部分は組織設計のところにあることもあるから、
そういう認識はした方がいいかもねっていうような話だと僕は読み取った。
なるほどね。
全体感としては多分よくある技術的不細の話、
それを経営者と共有しようという話なんだけど、
ちょっと組織のところにフォーカスを当てた話を見ていきたいなと。
結構ね、今まさにあるとかね、結構共感性のある、
ああいうような気がする。
なるほど。
技術的不細の例と見える機能と見えない機能
まず技術的不細、今回話している技術的不細っていうのは、
例えば4ヶ月で完成するはずっていう見積もりをしたプロジェクトで、
でもこれは美術的な要件で、3ヶ月でなんとかさなきゃっていうことになって、
1ヶ月早く出す、結構よくある話だと思うんだよね。
やりますね。
つまり1ヶ月分何かしらの詰めをやって、
不細を追っているケースが多いはずなんだよね。
人が徹夜したとかだったらまたちょっと技術的不細はないかもしれないけど。
そうだね。
だいたいそれって見える機能と見えない機能があるはずで、
UI的な部分とバックエンド的な部分。
UI的な。
基本的には見えない部分を犠牲にしているはず。
段階的リリースとかをやってるんじゃなければそうなはずで、
そこで返さないといけない不細が基本的にはあるんだけど、
じゃあそれってどういうものがあって、
技術的負債の要因としての組織設計
それはどのぐらい早く効いてくるんだっけみたいな話。
まずどういうものがあるっていう話は何の軸かっていうと、
認識してるかどうかがまず1個の軸。
これは技術的不細なんだぞ。
自分らは不細を抱えてるんだぞと思ってやったものなのかどうかっていうところ。
それを開発チームが認識してるってこと?
そう、開発チームが。
だから気づかずに急いでやったけど、
本当の現実ほど問題がないと思っちゃってる部分っていうのは、
無自覚なものし、
ちゃんと何があってるか分かってってのは意図的なものっていうのがまず1個の軸で、
もう1個無謀なものとちゃんと考えてやったものっていうやつ。
だからこれはもうどうなるか責任持てんわみたいなレベルのものは、
意図的なんだけど無謀なやつ。
意図的なんだけど慎重って言ってる無謀じゃないやつは、
リリースを優先するんだけど、
結果こういう不細を抱えてこういうふうに返していこうと思ってるみたいなものが、
意図的で慎重なものだから、
これは別に計画的だしいいよね、別に。
今回話題にするのは、
自覚してなかったらどうしようもないんで、
意図的でかつ無謀なやつ。
設計に削る時間なんてないし、
結果にも責任ももたやまへんっていうやつを対象にしますと。
これが何で起きるんだっけみたいな話とか。
あとはこれを、
どのぐらいから影響が出ると思ってる。
リリース急ぐからって言ってるけど、
それを犠牲にしたら、
いつから影響出るんだっけ。
このリリースは大丈夫。
次のリリースまで大丈夫なのか。
みたいな全体、
今後の長期目線での速度って、
いつから落ちるんだっけっていうのの誤解があるよねっていう話は、
他のところでもよくされてる話かなと思うんだけど、
その辺も絡めて感じたね。
ここまでで気になるとこある?
大丈夫かな。
ちょこちょこ主体者が誰かっていうのが大事かな。
そうだね、確かに。
主語省略しがちだな。
今はビジネス要件とかを受けてっていうことではあるけど、
今は開発者側が意図的にやった、
でも責任持てんわっていうような無謀なものに関して話をしてます。
それぞれの良さ悪さの話とか、
さっきの意図してるかどうかみたいな話の説明も結構あるんだけど、
そこの原因についてかな。
どっちかというと無資格なものも含めて無謀な方の、
返せるかどうかの保証なんてできないものについてのお話なんだけど、
これいっぱいあるんだよな。
原因ちょっと一回列挙するか。
お願いします。
共有リソースプール。
これは人を共有しちゃってる話。
不連続のチーム。
非オーナーシップ性。
保守運用の分離。
品質保証の一極集中。
引きすぎた固定化。
ドミン知識の過疎値。
無力な多項管理形。
いっぱいあるんだけど。
難しい言葉が並んでるけど。
結構似てる内容とかもあるし、
ちょっと気になるところを掘りながら、
まず共有リソースプールから。
これね、結構覚えがあると思うんじゃないかなと思うんだけど、
マネージャーの下に、
エンジニアリング部門、チームとか、
部門の中にマネージャーがいて、
その下にいっぱいエンジニアがいますと。
いっぱいいるから、
あなたとあなたは100%で、
あなたは50%ここに入って、
他の50%はこっちに使ってねみたいなことを、
ちょこちょこやっていると、
人もリソースが100%使えなかったりして、
集中しきれなかったりするし、
それがスキルが合っているかどうか、
みたいなところって、
結局その人のスケジュールが空いてるから入れる、
みたいなことが多いから、
必ずしもスキルがバッチリ合っているとも限らない、
みたいな話になるので、
共有リソースでやると、
ベストなメンバーにはしづらいよね、
っていう話が一つと、
チーム構成による技術的負債の影響
そこで50%になる人ってどんな人かっていうと、
優秀な人なんだよね、
どっちかっていうと、
あなた、こういうところまで気を配れるとか、
このレベルの設計ができる人って、
あなたしかいないから、
あなたこれとこれとこれ入って、
みたいになる、
みたいなので、
結局そこでばらけて、
あまりベストなチームは作れないよね、
っていう、
理想論っちゃ理想論なんだけど、
そういうのを無くそうっていうのは、
でも現実としてそれ辛さが起きるよね、
っていう。
これをめっちゃわかる。
俺もなんか、
IBMの時とかはさ、
プロジェクト駆け持ちしがちじゃないですか、
SIとか。
ですね。
で、なんか、
このプロジェクトは5%で入ってください、
とか言われるんですけど、
5%って何やねん。
5%ってやばいよね。
短かったかしら。
そうそうそうそう。
だからなんか1個ミーティング、
1個ミーティング出て、
ちょっと、
個問的な感じだよね。
それってやばくないですか、
みたいなちょっとリスクを指摘するみたいな、
それくらいな、
あれだけど、
やっぱマルチタスクというか、
そのスイッチの切り替えコストがかかるから、
それはこれは非常にわかります。
そうなんだよね。
なんかアップデート情報が来た、
使ってるサードパーティーのアップデート情報とかを見て、
保守の部分、
それがうちのプロダクトに影響があるかどうかだけど、
パワーで見てください、
みたいなことを言われたことがあって。
しびるよ、
時間としてはどうかもしれんけどね。
そういうのでね。
プラス、
今みたいなチームの編成をするとさ、
即席チームなんだよね、
基本的に。
だからチームワーク問題も発生する、
みたいな、
結構いろんな問題があるっていうので、
ちょっとそれで、
じゃあそれをやった結果どうなるか、
どういう不採、
なんで不採が生まれるのかっていうと、
即席チームだからその信頼関係の話とか、
お互いどのくらいできる人かわかんないみたいな、
話もあって、
だから、
かつそのベストマッチしてない人も入るから、
誰かしらちょっとまずい設計とか実装を埋め込む可能性が高いけど、
それを確実に、
なんかこう、
弾けるかっていうと、
そうでもないよね。
ということで、
混入がしやすい。
良くないものの混入がしやすい。
結構その、
なんだろうな、
メンバーがどういうことをやってるのかっていうのは、
あんま見えない状態でやってるから、
設計に一貫性が出ないというか、
いうのがあるかもしれないですね。
そうですよね。
どうするのが理想であるって話で言うと、
ちゃんと固定チーム制にして、
チームごとでアサインするとか、
そういうことをしようね。
エンジニア一人一人はリソースとして見るのやめようね、
みたいな話が言われて、
ここでは言われてて、
で、そこから次の不連続なチームはやめようみたいな話につながっていく。
保守運用の分離と技術的負債の関係
だから、
プロジェクト、
あるプロダクトに対するプロジェクトが1個終了しました。
前にいた人もちょっとだけ残ってるけど、
新たなチームで、
次のそれの拡張機能とかを作りますみたいになったときに、
チーム解散するんじゃねえよみたいな話ね。
そこでいろんなことが起きて、
最悪っすね、本当に。
これはもうみんな直感的だから、
そんなに話さなくてもいいかなっていうレベルだと思うし、
ここから、
もう一個ちょっと飛ばさっきの中で飛ぶんだけど、
保守運用の分離みたいな話。
で、ここのチームがまたさっきみやちが言った通り変わって、
同じことが起きるよねみたいな話。
知識スキルが抜け落ちますっていう話になるので、
やめましょうって話と、
非オーナーシップっていうやつが、
一人一人の単位でオーナーシップ、
このコンポーネントは共有なんだけど、
この人が一番わかるよねみたいなのをやりすぎると、
そこで俗人化しちゃって、
みたいなことが起きるので、
チーム単位とかで持とうね、
みたいな話があるかな。
ただね、ちょっとこれ、
昔マイクロソフトだったかな、
技術的負債に関する組織設計
どっかで出てた研究みたいなやつで、
これもチーム単位でやればいい話かもしれないんだけど、
めっちゃそこにコミットしてる、
8割ぐらいその人がコミットしてますみたいな部分、
コンポーネントとかに関して、
バグが一番出づらいのはどのぐらい、
その一人の人が、
エキスパートが見てるかみたいなやつで、
結構ちゃんと一人の人がエキスパートとして持って、
その人がレビューとかでもちゃんと監視してる方が
起きないよねみたいな、
いろんな人がガチャガチャと少しずつやる、
起きちゃうよねみたいな研究もあったりしたので、
人じゃなくてチームでそれをやろうね、
みたいな話だと思うんだけど、
あんまり俗人化しすぎないようにした方がいいし、
そうじゃないとさっき言った、
人が変わったりすると一気にスキルとか知識が抜け落ちちゃうから、
それ防ぐ方法が基本路線だね、
大体が基本その路線、
スキルと知識がどっかで抜け落ちるっていうタイミングをなくそうね、
みたいな話が結構多いんじゃないかな、
っていうことが書いてあるかな、
あとは品質の一極集中っていうので、
これテストの話だね、
開発チームが開発する、
開発チームがUHMとかがテストする、
開発チームは頑張って開発するし、
機嫌もあるから急ぐんだけど、
特に時間に追われたときって、
時間ギリギリまで何とか設計と実装、
これとこれとこれの機能諦めたから、
せめてこれとこれはやらなきゃってギリギリまでやるよね、
実装とか、
ってなるとテストコードあんま書かないってなって、
テストチームの最後のテストのところだけが取り出になって、
すごいその後どう保守すんねんみたいなものが発生する、
だから基本的にはあれだよね、
手とないコードができるような体制があるっていう話でね、
それは結構体制によるものでもあるから、
そこの体制を整えることで、
テストチームとかテストフェーズだけっていう、
品質の保証の仕方はなくせるんではみたいな話。
理解です。
っていうくらいかな、
あともうだいたいね、
個人属人化しまくんのやめようねーの話と、
あとこれはPDMとかでもみなちも思うことなんじゃないかなと思うんだけど、
企画チームとか顧客分析とかめっちゃやって、
そこでその知見とかいろいろ蓄えられて、
こういう風にしようって決まってるんだけど、
それの仕様だけが怪しいように降りてきちゃうと、
何でそれをやるのかが伝わらなくて、
ここでも結局知識とスキルの欠落が落ちるよね、
発生するよねっていう話で、
そこも落とし穴なので、
そういう欠落する場所をできるだけ減らそうということで、
これ難しいとは思ったけど、
分析チームと企画とかその辺のところは一緒に、
できるだけ共通部分をどこかで持ってやろうね。
エンジニアにユーザーインタビューに参加してもらうこと、
なかなか難しいから、
やっぱりプロジェクトマネージャーがそこはちゃんと吸い上げて、
ちゃんと開発チームにもフィードバックしていくっていう仕組みが必要なのかな。
伝える力と受け取る力が求められるからな、
エッセンスをちゃんと伝達するっていうのがね。
難しい話だけどその辺が一番大事かな。
あとはちょっとマネージャーがすごく強いパワーで管理しすぎると、
組織として難しいよねみたいな話とかが出てくるんだけど、
その辺はそりゃそうやろって話なので。
だいたい今話したのが組織的になくせそうなというか、
組織が原因になりそうな不才、技術的不才の話。
マネージャーによる強力な管理
大体のところはスキルと知識がどこで抜け落ちちゃうんだっけ、
のところに回帰するかなっていう感じだよね。
確かに技術的不才の返却の部分だと、
評価制度でやるかみたいな視点で結構考えられがちだけど、
どっちかっていうとそういう組織をどう作っていくかみたいなところ、
あまり議論されてないので結構有意義なスライドなんじゃないかなと思いました。
特にIT、昔ながらの製造業とかよりも、
どっちかっていうとITとかの方に効く話かなって思うのは、
転職が激しいところって個人にするとやばいことになるから、
できるだけチームでやろうってなんだよね。
っていうので、やっぱり僕らはよりこういうのを意識して
やっていくほうがいいんじゃないかなと思いました。
ありがとうございます。
じゃあ終わりましょうか。
こんな感じで週2回のペースで配信しているので、
もし面白いと思っていただけたら、
Twitterのフォロー、Podcastのレビューなどぜひお願いします。
今回も聞いていただきありがとうございました。
ありがとうございました。
