00:01
エンジニア視点でライフハックするためのラジオ ハックしていただきます。
はい、みなさんこんにちは。TRY-CATCH FM第44回を始めていきます。
お願いしまーす。
お願いしまーす。
なんかね、最近も体の検査をしようと思って。
ちょっと気になるところがあった場合は、色々病院探しに行ってるんですよ。
はい。いいことですね。
なんか、そんな重症っていうかめっちゃ気になるってわけじゃないんだけど、
なんか寝てるときにすっげー体だるい。だるくなってるときがあって。
あー、疲れ取れないみたいな。
なんかね、手足がめっちゃ重いというか、なんか血が巡ってないみたいな。
やばそう。
やっぱりミトキ症候群かと思って。
あー。
あれじゃないですか。
炭素足りてないからってこと?その重さみたいな。
あのかな?わかんないけど。
まぁ、とりあえず言ってみて。
YouTubeで色々見たら、誰だったかな?
ボディービルダーみたいな人が、銀座の無呼吸症候群を見てくれてるクリニックを紹介してて。
ホームページ見て行ってみるかと思って。
行ってきたんですよ、この間。
結果としてはね、全然無呼吸じゃなかったというか。
そうなんだ。
3日くらい、まず最初に行くのね。
そしたら、寝てる時の血中酸素濃度を計測する機械をレンタルさせてくれるのね。
手首にバンドつけて、そのバンドから紐がピョって出て、それを指先にクリップみたいな形でくっつけるみたいな。
へー、それで酸素濃度を測れるんだ。
それで、とりあえず3回サンプルを撮る。
3日分、3回ネタ分を撮るんですよ。
それをその機械で集計した。
そこにデータが溜まってるから、また3日後くらいに病院に行って解析してもらうみたいな。
で、その終身から起床までの血中酸素濃度の推移とか心拍数の推移みたいなのを測ってくれるというか、可視化してくれて、
ここで下がってますねとか、でも全体として問題ないですねみたいな診断をしてくれて、すごい良かった。
何が良かったって、まず無呼吸症候群じゃないっていうのが判明したっていうことと、
03:05
ドレンのチェーンス自体が保険適用で1500円くらいでできるんだよね。
へー、安いね。
そうそうそうそう。
だから無呼吸症候群って肥満体質で結構酒飲む人とかありやすいらしいんだけど、
俺結構性反対。
そうだよね。太ってもないし酒も飲まないし。
性反対なんだけど、ちょっとその不安は解消されたし、
もし仮に無呼吸症候群とかだったら、
本当無呼吸症候群の人って血抽出濃度が寝てるときに70%とかまで落ちるんだって。
へー。
70%ってどれくらいやばいかっていうと、
普段息を止めて自分でね、でも限界ですっていうところまで止めてだいたい80%中頃か80前半くらいらしいのね。
へー、ガチ無呼吸じゃん。
そうそう。それより普段に息を止めてるっていうのは無呼吸症候群らしくて、
それをやると本当に心臓とか脳とかに負担がかかって、
いろんな病気にもなりやすいみたいな話もあって、
ちょっと気になってる人は絶対やったほうがいいですよってちょっとお勧めできるかなと思った。
そうね、お手軽だし安いしね。
うんうんうん。
そうそうそう。
血抽酸素濃度ってそんな簡単に測れるんだなーと思って。
ね。
あれらしいよ。でも前のポッドキャスターで紹介したさ、
俺が今ウェアラブルバンドとして使ってる、
ミーバンドだっけ?
ミーバンドの新しいやつが多分7月かなに出るんだけど、
それも血抽酸素濃度を測れるようになってるらしい。
あーそう、なんかそのクリップとかのレベルでできて、
集計もどうせ計算するだけだからさ、
ウェアラブルでできるかできなくても将来的にはレンタルキット送られてきて、
3日測って送り返すみたいなの普通に普及しそうだなと思ってたんだけど、
もうできてるのね。
アップルウォッチもシリーズ6かな?
一番新しいやつだともうできてるらしいですね。
おーやっぱその辺はみんな気になってるんですねってことは。
そうだね。
まあでもアップルウォッチシリーズ6だったら、
結構値段するよな。
お手軽にやりたいと思ったら、
銀座クリニックっていうところに行ってもらうか、
06:00
ミーバンドとか買って自分でちょっと見てみるとかやったらいいんじゃないですかね。
ちゃんと調べたいかどうかとかで、
ちゃんと調べたいなら絶対医療機関がいいけど、
一応目安だけ見るかっていうんだったらね、
ミーバンドでちょっと測ってみてっていうのもあるかもね。
俺は寝てる最中下がっても90前半くらいだったから、
基本問題ないですみたいなことを言われたね。
そんな感じです。
あれでもじゃあミヤチの寝てる時のだるさは解決してなくない?
まあ確かに。
最近はそんなないんだよね。
気圧とかの問題なのか季節的なものかな。
気圧あるかな、ストレスとかもあるだろうね。
最近引っ越して住居環境変わったから慣れるまで。
あと仕事のストレスもちょっとは少なくなってきたから、
まあまあそれなのかもしれないもしかすると。
ちょっと様子見て、また悪いようだったら次の診断をしたいなってここで話してください。
了解です。じゃあ本題いきますか。
本題なんだけど、今までいくつかプロジェクトに携わってきたと思うんだけど、
上手くいってないプロジェクトとか上手くいってるプロジェクトって結構それぞれ大きく違ったと思ってて、
どんな原因があったというか、どんな原因が多かったかなっていうのをちょっと話したいなと思ってるんだよね。
大事ですね。
なんだろう、ちょっと僕の方から考えさせてもらうと、
計画と遂行の話、それぞれであると思ってて、
計画そもそも上手く立てれてない、この辺考えてなかったがいっぱいあるパターンはまず論外で、
後からコース増えてくるからダメなんで失敗しやすいっていうのがあって、
あと途中から計画変わっちゃう系。
場合によって柔軟に変わるとか大事なんだけど、
お客さんを抑えれてないとかそういう意味で、
お客さんがこれもつけたいなって言ったのを抑えきれなくて増えちゃうみたいなパターンの力関係だと、
後で炎上するパターンが多いなっていう気がしてる。
割とそれはもう明らかやろって言われるのは分かるんだけど、割とあるんですよ、そういうプロジェクトがあって。
残念ながらね。
あとは遂行の方の話だと、
単純にコミュニケーションがうまくいってない、
コミュニケーションが必要な分だけできてないっていうのがあるかなっていう、
それぞれの個性とかスキルとかで、
必要なコミュニケーションの量ってそれなりに違うと思うんだけど、
09:03
やたらとコミュニケーションにコストをかけすぎちゃうところとか、
逆にめっちゃ慣れてる人くらいのコミュニケーションしか取らないけど、
実は新人が多かったりしてちょっと後からミスってたことがたくさん出てくるとか、
そういうコミュニケーションの量をミスってるところっていうのは結構失敗しがちかなっていうのと、
コミュニケーションの量をミスってしまうんだろうな、さらに深掘って。
そうだね、そこはね、最初にが特にだけど、
あと定期的に確認をしてなさそうっていうのがある。
今このコミュニケーションで足りてて、
ちゃんと物事が問題なく進んでるのかっていうのも確認がそもそもできてないから、
後から発覚しちゃうんだと思うんだよね。
確認できてれば途中で少なかった多かったって変えればいいだけなんで、
単純にそのコミュニケーションの量が足りてる足りてないっていうのを、
何かの根拠を持って都度感知してないからっていうのは感じますね。
新人が多いところだったら本当にうまく仕事できてるかっていうのをたまにちょっと話をしてみてとか、
成果物の確認とかしてみてとかをちゃんとやってないと明らかにまずいしね。
SDAの今のプロジェクトってそういう新職確認のミーティングってどれくらいの頻度でやってる?
今はちょっと色々詰めててバタバタしてるから、
もうミーティングが無限にやってる感じなので言えないですね。
それは別の話でもあるんだけど、
今のところもちょっと絡む話で、
結構うちの会社自体がかなり多い話なんだけど、
計画を遂行する話と、計画を立てる話にもあるんだけど、
またコミュニケーションコストとかもあるんだけど、
無視して人月神話で物事を進めようとするっていうのがすごくある。
人増やせばその分、
先継的に早く終わるやろうみたいな。
そんなわけあるかいみたいな。
人2人にしたら2倍早く終わるわけねえだろうみたいな。
そういうやつと、
コストが安いからって言って、
本当に単純作業じゃない作業までコストが安いからって言って、
安い人に任せようとして、
よく現場の人がそれを伝えたり修正したりするのをサービス残業でやってるみたいなのが、
割とうちの多くのプロジェクトの実態だったりするので、
そういうところはやっぱり失敗するなっていうのがあるね。
12:01
だから割と、
まとめると、
計画として、
もうレター出ないようにしようねっていうのと、
お客さんをちゃんと制御できるように、誤解を恐れずに言うなら制御できるようにしようねっていう話と、
ちゃんと必要な分のコミュニケーションを取ろうね。
仕事が上手く進まるだけのコミュニケーションを取ろうねっていう話と、
人欠神話はやめようねっていう話。
人欠神話は確かにそうだな。そこは俺もそうだなと思うね。
何だろうな。もちろん、
追加コースが必要だから、
人を入れるっていうのは確かになしな選択肢ではないと思うんだけど、
スケジュールに間に合わない、この開発スピードだとスケジュールに間に合わないから、
入れましょうってなってるプロジェクトって大体失敗してるプロジェクトだと思う。
そこから、例えば開発者なら環境のセットアップとか出てくるし、
大体失敗してるプロジェクトってそこら辺の環境設定のドキュメントとかないから、
元々いた人のコースが裂かれて、さらに身動き取れなくなるとか、
全然あるあるだなっていう気がするし、
だからやっぱり、チームがうまく動いてるかどうかっていうことが、
まず一つの指標だと思うな。
そうだね。
何て言うんだろうな。
結構入れ替わりが激しいと、オンボーディングのコストがかかるから、
うまく前に進めないっていうのもあるし、
だから、ある程度、あうんの呼吸でできる人たちが、
それなりにスピード感を持って、プロジェクトをぐりぐり前に進めていけるっていうのが、
大事かなと思いますね。
そうだね。うまくいってるところは割とそういうところな気がするよね。
なんかそうね、
結構プロジェクトメンバー間で腹を割って、
やばいです、これ進んでないですとかね、ちょっと言いづらいとね、
やっぱこういう今月のコストなのに出た進捗というか、
15:02
うまくできてないことが伝わりにくいっていうのもあると思うしね。
あとは、
ステークホルダーの多さとかかな。
確かにね、いろいろ決定…なんだろう。
ご要求をする先というかが多いと、ぶんぶん滞るよね。
なんか一個決めるにしても、あの人にも一応意見聞いといてとか、
そういう人が出てくると、
いやあの人またミーティング調整するのめんどくさいなとかってなって、
本当はこうした方がいいんだけどなっていうやつが抑え込まれるとか。
そういうのあるから、ステークホルダーを少なくするって難しいっちゃ難しいんだけど、
ある程度、もうそれやっちゃおうって言える人が、
すぐそばにいるとか。
そうだね。
もうスラックで、これこれでやっちゃいますけどいいですかってやって、
もうスタンプでなんかいいねみたいなの来て、
もうそれ実行できるみたいな感じが理想であるかなっていう気がするね。
そうね、なんか直接話せるお客さんとはそうしてるけど、
最終的にその人の上司からの承認がないと決められなくてとかってなると、
どんどん遅くなってくるもんね。
まあ思うのはそこら辺ですね。
あとね、もしかするとこれあんまり今回のテーマと関係ないかもしれないけど、
この間ツイッターで見て確かにそうだなと思ったツイートがあって、
なんだったかな、ロードマップって書くじゃないですか。
SIRとかでプロジェクト中とかしたら半年、1年、数年とかロードマップ書いたりするじゃん。
そこのロードマップに機能を載せるなみたいなツイート確かあって、
で、機能じゃなくて実現したいUXみたいなのを書いた方がいいよみたいなことが書いてあったのかな確か。
記憶による記憶をちょっとたどると。
なるほど、それは要するに?
要するに機能で書いちゃうと手段が固定されちゃうから、
例えば半年後にこれをやりますって言ってた手段が固定されちゃうと、
そこまでにもうすでに完了したことでちょっと色々事情が変わったりするじゃん。
18:05
だからちょっと別のアプローチでやらないといけないんだけど、
もう機能をコミットしちゃってるから、やりづらくなってくるというか、
調整が必要になってくるみたいな。
やっぱりこれのアプローチだと難しいんでっていう調整が必要になってくるから、
実現したUXベースでコミットしておいた方が色々柔軟に動きますよみたいなことだったんかなと理解してる。
確かに。なんか気軽に見直させてくれるところならいいけど、
それが契約の納品物とかになってると簡単に変えられなかったりするし、
お客さんの上層部がこれ作るんじゃないのとか言い出すと面倒。
面倒って言うとあれなんだけど面倒になるので。
やっぱりこういうことをしますで、今の案としてはこういう可能性はありますが、
どこかに書いておいてもいいかもしれないけど、
やりたいのはこれですが、手段は見てっていうのが確かに良さそうね。
そうそう。自分の過去とか振り返ってみても、
そういうロードマップのプロジェクトでやってた記憶あるなぁと思ってしまったね。
大体そうだよね。
コツダは今結構プロジェクトハードモードなんだっけ?
まあまあ、割と忙しくやっておりますね。
俺もね、いろんな原因があると思うんですけどね。
上流フェーズでどうだったか、本当にうまく決めきれてたのかとか、
抜けてたことはなかったのかみたいな話もあるし、
人に物を任せる時の任せ方のコミュニケーションがうまくできてたかみたいな話もあるし、
そもそも任せる相手も間違えてなかったかみたいな話もあるしとか、
いろいろとあるので。
そうですね。
人と人がやることなので、コミュニケーション問題が結構大きかったりしますね。
これあくまでクライアントワークの話になっちゃうけど、
自分たちのチームが優秀でも、お客さん問題で炎上してしまうプロジェクトってあるじゃない?
それはあるよね。
どうしてもそちらにならないのかな。
新設の研修でプロジェクトマネジメントの研修とかしてもらって、
なんでこんなにプロジェクトマネジメント方法が充実してるのに炎上するんですか?
っていう質問をしたら、この回答が返ってきたことがあって。
21:02
お客さんっていう全くの外部要因でスケジュールがいきなりずれることがあるとか。
そこでちゃんとQCDあたりでバランスとって、誤解を恐れずに丸め込めるなら、
自分の努力である程度回避が可能なのかもしれないけど。
仮にその人を丸め込んだとしても、さらにその人の上の人たちが爆弾投げてくる時があるじゃない?
そういうケースって往々にしてあるじゃん。
だから、急に半年リリース早めろみたいなのが上から降ってきたとして、
半年早めるとどんなことが起きちゃいますよとか、
もしそのヤバいことが起きない範囲で半年早めたいんだったらここまでしかできませんよっていうのを、
その担当者の人と一緒に上の人を説得するにはどうしたらいいだろうねっていうのが一緒にできるプロジェクトは、
まだ少し回避の余地がありそうな感じは今まで見ててあるけどね。
なんかさ、俺がCostaと一緒に働いてた時に流行ったメテオフォール型開発っていう。
そういうネタあったね。
まあこの上層部みたいな人がいきなりこう。
そうね、あれ。
すべてを崩壊させみたいな。
神は一生懸命これを再建する。
あれなんか、受託っていうよりもあれはあれで、なんか事業型の事業会社の上質が食らってるようなイメージも無きにしような。
まあ確かにSIRだけじゃないかもね。
その役員レベルの人が一気にこう計画を変えてくるみたいなね。
そう感じがちょっとあったけど、まあSIRも他人事ではないから。
その説得の時に、またそのQCDOの関係でここ削ってみたいになるんだけど、
結局、考数をある程度若干炎上しながらさ、まだ先の方にある考数を全部きれいに出せてるプロジェクトなんてまあないわけね。
まあね、確かに。
ってなると、じゃあその考数の偽りをしてさ、優先事例とかつけてさ、スコープ削減してさ、とか期間伸ばす考証してさ、とかやってる間にね、どんどんどんどんそこに考数かかって結局もっと伸びるんだよね。
まあその時間って作りたいよな。
それに1、2週間かかって結果うーんみたいなところはある。
まあだからそれで数ヶ月稼げるとか、昨日が2割作らずにリリースすることになりましたとかくらい減らせるんだったらいいんだけど、それで1ヶ月しか伸びませんでしたとかだと大して楽にならないんだよね。
24:08
なるほど。
そこで無駄にしてるからさ、無駄にって言うからだけど。
確かに。
まあそういうのはまあちょっと仕方ない部分はあるけど、まあまあまあ手法によっては多少多すぎるかもしれないけどね、まあそれはもう神の命令として打てるしかない時もある。
神の前では無力な時もある。
まあなんかそれでも、それはそれで楽しめるような仕事をするか、なんかなんだろう、それが2Cだったら、市場の理不尽に対応するんだったらまだ許せるとか、その自分が許せるメテオホールがあるところに行った方が幸せかもしれないね。
確かに確かに。
薬院がもうメテオホールは許せんとか、お客様のメテオホールは許せんとかだったら別の会社行った方が幸せかもしれないとか。
そういうのはあるよね。許せるメテオホールが降ってくるところか、メテオホールが降らないところに行きましょうですね。
了解です。じゃあこんな感じで終わりますか。
はい。
ありがとうございました。
ありがとうございました。
ありがとうございました。
ありがとうございました。
またね。
