99: 問題は早めに起こそう

Published on
December 21, 2022

概要

※注意 犬の鳴き声やおもちゃで遊ぶ音が入ってるので音量注意して効いてください。聞きづらくてごめんなさい。

文字起こし

powered by whisper.cpp

はいみなさんこんばんはカドッペFM第99回の配信です このポップキャスト番組は僕ソフトエアンジアのカドッペが日々仕事をする中で感じたり気づいたり考えたりしたことをゆるーくお話しするような番組です はい 今日は第99回ということでもう少しで第100回3桁なんですけど 再開したのは89回ぐらいからなので 再開してもうすぐ10回目か なんとなく 続けることができています 聞いてくださっている方もですね ほんのちょっとですけど少しずつ増えたりもしていて 聞いてくださっている方ありがとうございます 今日はさっきちょっと コンビニで売ってるチンする天ぷらそばみたいなやつを 食ったんで 口がなんかこうご飯食べた直後で なんだろう あんま喋りやすくないんですけど ちょっとお風呂に入る前に少し話してみようかなと思います 今日お話しするのはですね 問題はなるべく早く起こそうみたいな話をしようと思います ちょっと待ってください犬が鳴いてるんですけどちょっと喧嘩をやめてください 見切るんですけど大丈夫かな 喧嘩やめてください はいえっとですねあの問題をなるべく早く起こそうという話なんですけど 問題なんて起きない方が良くないっていう風に思うかもしれないですけども 起きないなんてことはなくて どんだけ問題を起こさないように仕事をしていても何かしら問題は起きるもんですし あるいは問題は起きているのに見えてないとか気づいてないふりをしているだけみたいなケースもあって なので早く起こそうというよりは早く目に見える形で具現化させよう起きている状態にしようというようなことですね 例えばですねソフトウェア開発の7つの無駄っていうのはあるんですけど 僕の好きなリーン開発の本質っていう本にすごく書かれてるんで興味のある方読んでいただきたいんですが そのうちの無駄の一つにですね欠陥の無駄っていうのがあるんですね 欠陥の無駄これ何かっていうとソフトウェアの欠陥不具合ですね これが見つかるタイミングが遅くなればなるほど解決も難しくなるし問題も複雑になってるよみたいなそういう話です なので問題をなるべく早く見つけて早い段階で見つけて早い段階で対応しましょうっていうことなんですけどする方がいいですよねってことですね 例えばソフトウェアがあって何かしらそこに対してある機能を追加しようとするときにまず最初何から始めるかというとアイデアを考えるわけですね アイデアが要件仕様になって開発実装してコードになってテストしてデプロイしてユーザーさんに届くみたいなこういうパイプラインがあると思うんですけども 今言った中でも6フレーズぐらいありましたよねアイデアからユーザーさんに届くまで それでもその中でもなるべく早いタイミングで問題について気づけておくことが重要だよねと そうすることで無駄が減ってバリューストリームがすごく滞りなくて流れるようになるって話なんですけども ユーザーさんの前に出てから見つかった具合ってもう想像通りすごく面倒くさいですよね コミュニケーションお宅さんとのユーザーさんとのコミュニケーションも必要になるし もうデプロイしてしまっているので他の機能との影響とか関係とかも考えながら直していく必要がある なんですけど例えば使用の段階要件の段階でバグというかバグの元になるものが消せていたら あるいは開発の段階でテストとか自動テストによって問題に顕著できてたら それはそれでその一回リリースしてから機能をリリースしてから問題が見つかった時よりも 簡単にスムーズに問題が解消できるわけです という感じである一連のソフトウェア開発の活動を 一つなぎのバリューストリーム複数の活動を一直線につなげて 最終的に何かを優先届ける価値を届けるというふうに捉えると その早い段階で問題を見つけることがすごく大事だよっていうことですね ツイッターでちょっと前に人あるつぶやきを見かけたんですけども 何かっていうと問題が早期に発生する顕在化する環境とか コミュニケーションとか組織を作れるといいよねみたいなツイートがあったんですね お知り合いの方のツイートなんですけども そういうさっき言った欠陥の無駄の話と問題が早期に見つかるような環境組織 コミュニケーションに似ているというか すごい近しい部分にある考え方だなと思っていて 僕すごくやっちゃいがちなんですけど なんかねなんでも大丈夫大丈夫って思っちゃうんですよね 大丈夫大丈夫って周りの人に言っちゃうんですよ 結構大変な仕事とか あのなんかめんどくさい仕事とかあるんですけど でも自分はそのそれが何であれ 自分のモチベーションがどうであれ それが会社にとってやるべきなのであれば パワーが続く限りはやります やれるよっていう感じのタイプなんですけど それによってどんどん一人でいろんな仕事を巻き込んで 吸い取ってで自分がこう大丈夫 大丈夫ってやっていっちゃうわけですね まあそれがそのすごくどんどん大きくなって ブラックホールみたいに自分自身がなって いろんなタスクを吸い込んでいっちゃうっていう性質みたいなのがあるんですけど 癖ですかね これは結構その問題が早期に現れる 起こせる起こすためのすごい妨害要因になってるなって思ったんですね めっちゃあのくちゃくちゃ言ってますかね 犬がおもちゃで遊んでるんでちょっと待ってください ちょっと取り上げてしまって犬がちょっとホントしちゃったんですけど あのそうですね何を言ってたかな 大丈夫ですよって言っちゃうのって 本当にそう思ってるケースもあるし その相手に心配させたくないというか いいように見られたいっていうケースもあると思うんですけど そういったものが無意識のうちに その問題が具現化するタイミングを遅らせてるっていうことが すごくあるなと思っていて なんだろうな 多分これはよわからないですけど 僕自身はもう大丈夫大丈夫っていうふうに言っちゃう傾向が 明確にあると思っていて 僕自身がなので他の人もそういう傾向を持ってる人いるんじゃないかなと 想像するんですけど あえて問題を起こしまくる問題をなるべく早く起こしまくる行動とか 発言とかアウトプットがすごく意識的に やらなきゃいけないなって思ったんですよね 今日これ自分がタスクやり過ぎてるんじゃないか それによって問題がチームにとって問題になってないんであれば 一回いきなり手放してみるとか なんだろう 騒いでみるとか もう無理大変きついやめようやだみたいな そういう感じでもいいんで そうやってあえて問題を引き起こすような行動していけるといいのかなと思います 環境面もそうですね 例えば定期的に行う キャップとみたいなやつもしっかりやってれば そういう問題をあぶり出すいい機会になると思いますね なあなでやってるとそこまでシビアな問題出てこないと思うんですけど 本当にシビアにやってれば問題を提起できる いろんな人がチームにいる いろんな人が問題を提起できるいい場所だなと思います あとはなるべく前倒すとかですかね いろんなスケジュールを 安全を期して 慎重に慎重に確認いろんなものを確認して よしこれで大丈夫だ 出そうっていう風な 例えばソフトウェア開発の開発プロセスですね やってるとすごいコストかかりますね もちろんで何だろう 過剰にチェックをして過剰に品質担保しようとして 結果的にそのなんだろうな その段その時点でいいクオリティが出るかもしれないんですけども まあスピードが遅すぎるよね リードタイムが長すぎるねって話だったりとか チームにとってそのサイクル 1サイクルで学べるべきはずだったものが 学べなかったとか そういった副作用もあると思うんですね リスクできるだけ最大限とって過剰な準備というか 過剰なテストというか そういったものをせずに どんどんどんどん多分動くだろうっていう感じで 出していくことによって これぐらいのスピードでコーナー曲がったらブレーキ ブレーキというか曲がりきれなくてクラッシュするんだなとか そういったもの問題がこうチームの共通認識になって じゃあそこに対して打ち手を考えよう じゃあ次から同じスピードで曲がれるようになるね みたいな感じで学習のスピードと成長のスピードがどんどん上がっていくんじゃないか みたいな感じで問題をなるべく早く引き起こそうという気持ちで 僕は今日いっぱいです なんかそのワンオンミーティングかもしれないし なんかとある皆で集まるミーティングの発言でもそうですし なんかドキュメント書くとか そういった個人の活動で行える部分もあると思いますし チームの文化というか開発プロセスだったりとか 仕組みで環境自体を問題が早く起きるような そういったものに作ることができると思うんで とりあえずいくつか具体的なやりたいことのイメージはあるんですけど 目指していきたいちょっとやってみたい方向性っていうのは少し今日わかった気がしたので いい収穫があったなと個人的に思います そんな感じですね はいじゃあ今日もここまで聞いてくださった方ありがとうございました では次回も聞いていただける方はよろしくお願いします それではまた