#349 「一機能をリリースするまで」をフレームワーク化!!

2025/4/23 ·

  • このラジオはエンジニアの成長は楽しい学びからをもっとにエンジニアリングに関する学びをワイワイお届けするラジオとなっておりますアレーション苦調だね変えてみましたフラットに行く今日じゅんぺいからしゃべり始めているということはじゅんぺいが持ってきてくれたエピソードってことかいまさかいやまさかなんかいそうだろ持ってきましたありがたすぎるわ



  • 僕が持ってきたテーマですね1機能を作ってくださいって言われてリリースするまでどんなこと必要だっけ



  • っていう話をしていきたいなと思ってますで多分前にした話だと1機能をリリースするみたいな話で開発に多分フォーカスして話をしたような記憶があるんですよね開発実装タスクを終えるまでみたいな話だった気がしますね前までやってたのはそれをちょっともう少しスコープ広げて



  • えーともうこういうタスクこういう機能を作ってほしいんだけどって言われてでそれをもう実際自分で作り始めるまでにまず何が必要なんだっけとか整理したりしてえー



  • いろいろエラーログロギングの考えとか監視の観点とかそもそもスケジュールどう引いたらいいかとかいろんなタブ書との調整とかも含めてリリースまでの流れをちょっと整理したいなと思ってます僕自分のためにフレームワークみたいなのができたら結構助かるなっていう思いで普通にあと社会科勉強としてはい



  • なんか知りたいわ順平の周りどうなってんだろうとか確かに会社によって違いそうだもんね違うと思いますそんな観点あるんだとかそういう話していければなと思ってますはい全力で賑やかしていきますお願いします



  • なんでこれを聞けば多分皆さんもそういう位置機能の流れを全体をざっくり把握して仕事で活かせるんじゃないかなと思っておりますちなみにちょっと前提の確認なんですけど最初に依頼される内容はこの機能を新たに作って商用に適用したいみたいな話なのか



  • そうですねはいまさにそれで結構ふわっと投げられるタイプのやつ最初は多分そうだと思うんでもうなんか締め切りもなくというかそこから見積もってみたいな見積もってとかそういう話もその見積もりとかも僕が思うのはどのタイミングでやるのが適切なんだろうとかなるほど思ったりもするんでそういうところも話していきたいですねわかるわ



  • 難しいこの話するのは直近で僕が最近ちょっと開発やらせてもらってて久々それが3月中旬ぐらいから任せてもらってたんですよ2人でやってたんですけど最初の1週間ぐらいはでもそのやってた人が



  • 4月からちょっと別部署移動ってなってあれ?僕だけ?みたいになって3月中旬から分かってただろそれ絶対本当に一緒にやってたその人も移動のために引き継ぎの資料作りとかあるじゃないですかそっちにもうなってたんでほぼなんか俺が作るみたいな感じになってめっちゃいい仕事してるねすごい経験としていいねただこれ6つってなってたんでそうだね



  • っていうのでどう話していこうかって思った時にマジで考えなきゃいけないことってめっちゃあると思うんで一旦僕が考えたこと今やったことやっている流れをザッと共有したいと思ってますそういう共有した後にその中一個一個見ていってそのタイミング適切なのかとかこういう観点あるよねっていうのを言ってもらえればなと思っておりますはい承知しましたはいっていうのでまず上司からですね



  • こんな機能を作りたいんだねちょっとお願いしてもいいっていうふうなふわっと仕事を投げられましたイメージとしてはなんかもともとなんですかね僕AIチャットGPTみたいなアプリをお客様に提供してるんですがその中でプラスで1機能付け加えたいみたいなそういう機能を作ってほしい



  • っていうようなイメージですディープリサーチを追加しようみたいなそういう感じですそういうお願いをされた時にざっと僕が考えたいろいろやったこととしてはまず概要Googleスライドのところに僕はあるんですけど概要の中でも背景とか今回やりたいこと機能としてはこんな感じだよねUIとしてはこんな感じになるのかなっていうのをちょっとまとめましたうん



  • で次が長官構成図みたいなもんですね 構成図みたいなものはなんとなくざっくりです長官図?長官図?長官?長官 鳥が俯瞰してみるみたいなやつ?ああそうですそうです長官って言うんだ へえ言ってました僕は 長官として本当なんで構成図とはそんな変わんないですどのレイヤーの?僕がやったのは



  • アプリケーション全体の話ですねなんでAzureのクラウドサービス単位なのかもっとふわっとした話なのかクラウドサービス単位ですなるほどTFで構築した後でこのリソースはこのプライベートエンドポイント取ってここのリソースとつながってみたいなのをなんとなくざっくり最初はまだ詳しく書けないんでマジでそんなことできるようになったんだじゅんぺいっていう感動がすごいわ俺大元がやっぱあるんで作りやすいでもでもでもでも



  • 既存でもすでに構成図あって今回機能こういうの作るならこういうの必要だよねみたいなのを足していった感じですかね足していったり減らしていったりして今回のこの機能用のざっくり必要最低限のもの現段階のものみたいなのを長官として作って後に使用書とかにはきれいにしたものを構成図としてそれを載せられるかなって作りました次に提供条件ですねざっくり調べて



  • この機能って最低限こういう制約というかこうなっちゃうよみたいなどうしてもあると思うんですよ必要最低限この文字はどうしても出力させなきゃいけなくなっちゃいますよとか機能としての使用の明確化なのかな制限とか含め画像をアップロードするなら10MBですよみたいなとかはいそうですそうです



  • そういうのも10メガですしアップロードできるAIのモデルってそもそもこれなんで最低限このモデルがデプロイされてることが必要ですよみたいなのも最初はそんないっぱい出せないですけど最低限わかったことは出す条件で次それを調べていく中で多分気になることとか確認したいこといっぱい出てくると思うんですよそれを懸念事項確認事項として一応ざっと箇条書きで出しておく



  • 続いてこれはコストコストについてはプロジェクトでお客さんにいくらですっていう話ではなくてその前に開発としてこういうリソース使うんでこういういくらぐらいかかりそうです公式ドキュメントにそれは載ってると思うんで



  • 重量課金制なのか月単位のいくらなのかみたいなところをコストを整理しました見積もりするんだねこれは結構早めの段階で例えば他部署の企画の部署とかにインプットしておくっていうので早めにこれはコストは対応しましたねで次にリリースに向けてやらなきゃいけないことここの中に開発とかいっぱい色々あると思うんですけどリリースに向けてやらなければいけないことの整理で



  • 前提として僕が今やってるタイミングだと先行提供なのか正式リリースなのかっていう2個があって僕はちょっとここ整理しきれてなくてちょっとミスったなっていうところがあるんですけどここは考えなきゃいけないとこだったなっていうので反省で書いてます



  • その次にスケジュールの線引き今リリースに向けてやらなきゃいけないことを整理したんでやらなきゃいけないことでどのくらい日数かかるんだろうねっていうのをざっくり出してスケジュール線引きしてチームのリーダーとかに共有するみたいのを



  • 全体としてはざっくりやっていることですもうちょっと言ってた方がいいなと思うのがリリースに向けてやらなければいけないことこれの中身も結構あると思うのでこれをざっと言って一旦終わりにしますねやらなきゃいけないことまず開発



  • 次に開発できたらできたでその他の部署の人たちも触れるような環境開発だけじゃなくて企画とか営業というか構築部隊とかなんかそういう運用とかが触れるような環境を用意すること



  • であとは今回これは特殊かなと思うんですけど権限周りの調査クラウドのリソースを使うんでそのリソースって普通のユーザーの人見れていいんだっけとかそういう権限を制御する必要がちょっとありそうだったのでこれのリサーチであとはテストですねまあ



  • うちだと今回は特にE2Eテスト画面ポチポチのテストの使用書整備だとかテストコードは最悪書けなくていいんですけどどういうテストをするのかっていうのは必要で次に性能試験性能試験不可試験みたいなところですねで次がバグの管理開発した中でバグがいくつか出てくると思うんでそれを管理するシートみたいなのをちょっと作って



  • すぐ対応っていうのはむずいと思うのであとはアプリができたらできたで脆弱性の診断が必要続いて今度は使用書の整備ですねドキュメントこれは内部のもそうですしお客様向けのドキュメントの整備も含んでます次エラーハンドリング



  • エラーをこういうエラー出た時はこういう風な対応してくださいとかこれが出たらエスカレーション僕たちに投げて戻してくださいっていうこういう情報を取ってきて僕たちに投げてくださいっていうのを運用部隊に渡す用のドキュメントですかね運用手順書とか監視のなんかきますよねはいそうですねで今の監視のはちょっとまた別でその監視設計の話監視用の



  • そもそもどう監視するから始まりますし どこを監視するとしたら見るとか敷地何にするみたいなのドキュメント整備もそうですしアラートルールとかの構築手順みたいなのも必要なのでそれは運用部隊にまず相談するところから必要どうしましょうかってあと最後TFの構築ですね自動化で自動デプロイできるように



  • っていうのがリリースに向けてやらなければいけないことで整理したことでただこれが先行提供か正式リリースかによって不要なものや絶対必要なもの正式リリースだと全部絶対必要か先行提供だと最悪TFとかは構築できなくても手動構築で頑張ってね代わりに手順書を用意しますよとかっていう話で対応すればいいかなっていうところでざっとやったことやってることですちょっと多すぎてあれなんですけど



  • なるほどまず僕がリリースに向けて必要なものはそんな感じかなと思ったんですけどマジで立派に仕事するようになってて驚いてるよ俺はいやこれはもう本当そうですね僕もここまで全部1機能ざっくりスケジュール1000引いていいよっていうのもここは初めて任されたんで



  • すげー困ったんですよこの4月入ってからでもやりきったんだやりきったというかやりきりそうなのがやってるっていうかやれてるんだね他に参考にできるものとかやっぱあるんでなんとかやれてるんですけどそもそもこの時点でこういうのうちだと考えみたりしてるよとかもあったりしますなんかそうですね



  • ちなみにえっと依頼を受けてボリューム感としては1ヶ月半ぐらいで終わる作業っていうのでスケジュール引いてる感じのボリューム感でね2ヶ月くらい1ヶ月半ただそこすごくスケジュール今回僕ミスったなと思って1ヶ月で仕上げてほしそうな感じだったんですようん



  • 4月中旬リリースしたいって言われててでも4月末末までいかないですけど下旬にはなっちゃいそうそこの認識合わせとか結構ずれたなーっていうのはありますねなるほどね反省ですなんかこれはでも別にそれでいいからそういう依頼のされ方されてると思いますけどね



  • 順平の育成もあるんじゃないとは思います大枠の流れはだいたい一緒だけど質問があって監視の設計周りって監視チームとどういう役割分担をしてるんですか例えばメトリックスとか指揮地とかの相談するって言ってたじゃないですか監視チームにってことは実装するのは監視チーム



  • 実装は自分たちです開発チームでやります相談は何のための相談まず監視したいのかもそうですし監視するとしたらそれこそその敷地いくつにするとかっていうのを相談しますなるほどねナレッジというかノウハウをアドバイスしてもらうための相談ってことか



  • ちょっと違うアドバイスしてもらうためではないですね確かにそう言われると監視とは言えますが運用部隊がアラート発報したらまず確認してくれるんですよ確認してくれてさっきの中で言うとエラーハンドリングのドキュメントかそれを見て対応できそうなら対応してもらえますし無理そうなら必要な情報をお客さんからもらってもらってそれを開発に投げてもらうみたいな



  • 運用になるんですが なのでなんか質問の意図としてはですねなんか自分の進め方とちょっと違うかもって思ったところの1個がここなんですけど割となんか僕が今やってるんだとこれで行くんでって監視チームに言うんですよへーなるほどそうなぜなら監視チームはアラートが鳴った時に一時調査をしてアラートを投げてくれる人たちじゃないですかはい



  • でとはいえだからその条件ってアプリケーションの詳細を知らないと多分口出しづらいところだからこそなんか監視チーム側になんか相談言われてもなぁみたいなところあるのだろうなと思ってて確かにっていうのでちょっと質問してみてました



  • だからなんか多分役割分担が僕が思ってるのとちょっと違かったりするんだろうなと思ってうわーそれいいですねちょっとちゃんと確認しますそこは僕分かってないです情報共有を事前にするっていう意味だったのかもしれないしそこはじゃあ教えて後でって感じかな確かにアラートなってじゃあそれになったってことはアプリどうなってんのっていうのはこっち側が分かることですよねそうそうそうそうその指標を見るべきものなのかみたいなのって



  • ちょっと前の入門監視会とかやりましたけど結局見たいのはなんだっけアプリが動いてることだっけそれともリソースに余裕がある状態で動いてるのを見たいんだっけみたいなところによって設定するのと違くてそれは多分監視部隊はどうでもいいと言ったらあれですけど関心の外だと思うんで確かにありがとうございます確認しようと



  • あとは全体を見るとやっぱり順平はちゃんと仕事をしててびっくりしてるって何回も言うんですけど大枠の流れは大体一緒ですねちょっと違うなって思ったのは僕が今までやってきた仕事の中だとそういう話の発端は上司というか上司のロールの認識が違うだけかもしれないんですけどPOとかプロダクトマネージャーとか企画サイドの人からオーダーが来ることが多いなと思っててざっくりこういうことやりたいんだけどここまででリリースできないっていう相談のされ方をする



  • ことが多いと思ってます本当にその期間でいけるのかってデブ側は構えていけるって安易に言っちゃって後で地獄を見るととんでもないから本当にいけるのかってなりながら調査をするっていうんですかね順平の最初に言ってた要件整理提供条件タスク整理みたいなところをまるっとちょっと1週間くださいとかって言ってやっていくイメージで多分それは似たような感じですけど



  • 最初にスコープ言われるのはなんかありがちだから多分よくあるパターンはそっちな気がするなるほどそれゆえでもなんかこう言ったらあれですけど順平も多分今初めてやったって言ってたんでそういう人に任せてみようっていうところのリスクは多分マネジメント側で許容してるからこそ多分お願いしてると思うんで次に活かせばいいだけだと思いますねなるほどいいですねそう



  • そういうことかそれで言うと確かに企画から最初4月中旬いけますかって話では来てましたそれを開発側が今度はまだ僕に話が降りてきてない時ですね4月中旬ちょっとあれかもなんで一旦4月いっぱいまで見てくれませんかって話をしててそこの話全体の話が僕に伝わってきてて最悪4月いっぱいかって考えていってはっきりとスケジュールを



  • 出してなかったんですよそしたらいつの間にか話が割と4月中旬の感じで進んでいてすごくミスったなっていうスケジュールのコントロール別にしてたわけじゃないんだね少し洗い出しちゃったみたいな洗い出しちゃって途中でやばいしっかりはっきりさせなきゃっていうのが洗いました向こう側は何も言われなかったから普通に中旬でいけるのかなと思っちゃったみたいな感じか



  • しっかり出すべきだったっていうのがありましたねしかもあれですねそのどんぐらいでいけるのかっていうのの調査のためにまるっと1週間くださいみたいなのをカイさんはよく言ってたりする達人プログラマー的発想ですねこの前の格付けチェックにもあったようなそうですねでもねうるせえ今出せって言われる可能性ありますようるせえ無理だって言うしかないからね



  • なかなか言いづらいかもしれないですけどなるほどですねちょっと調べてみますねで終わってましたわなるほどありがとうございますであとはそうですね本当に大体こんなもんじゃんと思いながらもなんか試験系とかも全部自分たちだけで完結するんですよね付加試験とかも環境準備とかもどういうイメージなんだろう環境も今回ので言うともともとその企画例えば今回企画の人で言うと企画の人が触れる用の環境があるんですよ



  • 一般的なデブステージプロダクションのステージみたいな話そうですねステージ環境があってそこのステージ環境に同じように機能を1個載せるっていうようなイメージですねなるほどなるほどそれってこれはちょっと詳細に行き過ぎるかもしれないんですけどテラフォーム作った後に作る



  • これはそこは正直きっちり決まってなくてでも僕が今回やったので言うと早めに触ってもらった方がいいなっていう思いなんでテレフォーム作ってなくて手動で構築しましたなるほどねそういうケースもあるのは分かるからそれはそれでいいと思ってて僕がいつもやる流れだと商用へのリリースする作業のリハーサルのためにステージングに



  • 構築する必要があると思ってて3環境しかないと僕は3環境しかないところで仕事をしてるんでステージングに構築しつつ少量のリハーサルとして少量でリハーサルする本番を迎えて同じ手順でいけるねみたいなことをやってますね本当に早めに触ってほしいんだったらデブ環境を触ってもらうのかなちょっと汚いですけどそれは本当にチームによるし



  • こういうこともあるぐらいでリハーサルって意味でやるのはめっちゃ分かるなはいはいはいなるほど別にどっちでもいいと思いますよチームにやるそれってカイスさんのところってお客さんの環境に構築するのはカイスさんたちがやるうんそれで言えば僕のところで言うと構築部隊がやっぱいてそこは違うんですね構築手順渡してその人たちがTFで実際同じようにできるよねっていうのはやってもらってたりはしますねうんうんうん



  • なるほどなんでじゃあ物にもよると思うんですけどTFとかができた段階でやってみてそっから触ってもらう見た目もちょっとこうしてほしいとかあればそっから修正するアプリをそうね順番的には実装してデブとかで動かすアプリケーションの機能追加だったら



  • AWSじゃないなテラフォームのこと変わらないこともあると思うんですけど変わる場合かどうするかなでもちょっと追加するくらいだからそれこそテラフォームのリポジタル新しく立てるとかじゃないんだったら実装してデベロップ環境で試す段階の前にテラフォームのこと書いちゃうなローカルで動かす



  • テラフォーム書くデブ環境で動くね企画の人触ってみてちょよしよし今は動くねってなった後に性能試験とかやる段階でステージングに上げるかなデブエロップだとデブ環境だと性能試験正しくないことあるじゃないですかインフラ全然違うとかねデータ量違うとか仕事の流れはそんな感じですね



  • でもすごいねやっぱちゃんとしてるねちゃんとしてるわ多分住宅じゃないからそういうちゃんとしてるのやったことないかもしれない住宅じゃないから業種的に事業会社でもサービスレベルによってはやってそうですけどねそういうのをやってるとこに行ったことないかもしれない例えばやんないので言うと脆弱性診断とか



  • 監視チームとのやり取りとか基本運用全部自分たちでやってたからはいはいだからもう依頼が来たらあとはもう領域展開してスケジュールだけポンとそこに出してたからそういうので性能試験とか不可試験は普通にやってたそこまできっちりやってた性能もやってないね今更ですけどすいません性能試験と不可試験ってまず違います?似てると思う一緒だと思ってるな確認する観点がちょっと違うんじゃないですか一緒か?



  • 非機能要件どうなんでしょうねちょっとググりたくない負荷は比例はしそうだけどちょっとニュアンス違いそうな気はするけど結局試験観点ってこのぐらいの負荷かけた時に元々定義した項目を合格できるかじゃないですか例えばレスポンスタイムがどのぐらい以下のリクエストが何%以下みたいな



  • 調べ方をすると思っててこれでもちょっとそうですねあやふやにしがちというか俺もよくわかってないわ性能はレスポンスの速さとかのイメージあるな負荷は?捌ける量でも速い方がいっぱい捌けるから比例はしてそうっていうなるほど比例掃除比例ない方?性能試験は応答時間スループットリソースの使用率を評価するテストリソースの使用率はありそう



  • 一方負荷試験はシステムにどれだけ負荷かけれるかをテストすることですなるほどそういう意味だと負荷試験やったことないかもだってあれですよね最大どこまでいけるかを試験するのが負荷試験ってことですよねそうやったことない最大どこまでいけるかっていうよりはこれぐらい求められるから耐えられるかなみたいな俺の速さについていけるかなみたいな性能試験はこれぐらいやったとき



  • 耐えられるかなプラスレスポンスタイムとかリソース使用率見られるみたいな耐えられるかどうかってよりは効率よく動いてるかどうかみたいな不可試験の方が緩い緩いかどっちも秒間100リクエストっていうインプットが入るわけじゃないですかどっちもで性能試験と不可試験それぞれどういう見方をするんですか多分どっちが重いかっていうと人間で例えたら不可試験の方がきついと思う



  • どういう試験観点になりますか100リクエスト秒間1万にしましょう秒間1万にしたとして例えばこれから順平の耐久力を試すぞってなったら不可試験は限界までボコボコにすることだと思うだからやっぱり不可試験は要件のリクエスト数じゃなくてどこまでいけるか見るっていうことですよねだと思うただ限界を見極めるかどうかは決まってないと思う



  • どっちかっていうと今回求められるのはこれぐらいの量だから今回求められるレベルのボコボコにしたときにどうなるかを見るみたいな感じじゃないじゃあ耐えますよ僕今回は秒間1万リクエスト求められてます性能試験と不可試験で試験観点がどう異なりそうですかえっと



  • 多分不可試験で言うと秒間一番ボコボコそれはエラー率何倍以下ならOKみたいな観点ダウンしないかどうかなんじゃないかなサーバーがダウンしないかとかだと思う一方性能試験は例えば一発のパンチでもいいような気がするんだよねそれが何秒で返ってくるかみたいななるほどほんまか?な気がするけど観点の一個だけど確かに確かに



  • 多分1回では絶対テストしないけど教えて詳しい人聞いたの記事じゃねえわ順平の負荷テストは順平に対していっぱいパンチを食らわせて耐えられてるかどうかを見ると一方性のテストは順平をパンチしてみてどんくらい固いかを測定するみたいな



  • 同じ1万回ボコボコしたとしてもあとまだどんぐらいボコれそうかとかの数値とかも性能試験使用率で言うとそうだね性能試験の方が広そうではあるけど完全に負荷試験を全て包括してるわけではなさそう



  • イメージです今のところちょっと後で教えてほしいです僕が今見た記事だと性能試験は通常負荷で求められる性能が出るか負荷試験はたくさんかけた時に最大負荷か要件の中の年間のピーク時ここだからのピーク時プラス安全率かけるとかで見るのが負荷試験そういう意味だと負荷試験だな僕がやってるの僕がイメージしてたの



  • 確かに一般的にそっちの方がやりそう顧客が1万人いて1万リクエスト同時にあったら耐えられるかっていうよりは1万5000で安全に耐えられるかみたいなのを見たりするそういうイメージあるのありがとうございますちょっと整理できました恥をかかずに済んだよかったありがとうございますインターネット上に公開してるけどポッドキャストの恥は恥じゃないそう



  • 職場で大丈夫なら大丈夫学びの材料だっていうので話を戻すとなんだったかなそういえば勝手に性能試験不可試験って言ってましたけどなんだっけって話をしててリリースはじゃあ構築部隊がいるってことは一通りだからテラフォームのコードとあとコードソフトウェアのコードはい



  • 揃った時点で試験とか終わりましたの試験評価と項目表とか品質担保しましたよみたいな証とともに他の部署に渡すみたいなイメージなんですねそうですね今回においてなんですけどミスったなっていうのが先行提供と正式リリース今回先行提供だったんですよただもうちょっと言うと先行提供が何かっていうのが僕分かってないまま進めてたしなんなら開発としても特にこれっていうのがなかった



  • 先行提供って何かなりリリースみたいなのし一部のユーザーにだけ通うみたいなうちで言うとちょっと違うかもしれないですね会社側との定義がいろいろあるので僕たちが言ってる先行提供っていうのが機能としては本番環境と同様の性能とかを求めるただT4の構築とかは全然間に合わなくていいよっていう状態機能としてはお客さんは十分に使えるんですが内部としては



  • 構築が手動構築になるっていうなるほど思ってた先行と全然違った企業ごとだと思うんですけどそれって先行提供した後に正式はない可能性がある?いややります絶対やるんだユーザーから見たら別にどっちでもいいってこと?変わんないってことですね機能自体の性能じゃんへースピード重視するからちょっとインフラ周りちょっと嫌々気合でどうにかするぜっていう



  • でも最初先行提供が僕何かっていうのが分かってなかったし決まってなかったんでそもそも付加試験も必要なんかなとかちょっと思ったりしたんですけどそこの整理も遅れたなっていうのはすごい反省ですねもう一個質問いいですか今初めてやった作業だと思うんですけど周りの人とどう連携しながら進めてたんですか



  • 周りの人とはですね周りの人と言っているのはチーム内かなこの一連の流れを知っている人はチーム内にいるわけじゃないですかその人から多分適宜アドバイスをもらいながらというかフィードバックをもらいながら



  • やること固めていくのが多分流れとしてある気がしてるんですけど流れを知っているっていうのは同じようなことをやったことある人がいるはずってことですかこの機能についての流れを知っているはずの人がいる機能追加という会社によってリリースのフロー違うじゃないですかで順平がいる会社のリリースのフローをやったことがある人って意味ですね機能単位に似た機能というよりはなるほどそれで言うと



  • そういう人には特におさわってなくて会社単位でこういうのをやったことがあるタスクの諸々の資料を見て書き集めてこういう流れかなってやりましたそれでやれるのすごいね結構キャッチアップ力すごいというかマジ独り立ちしてるね俺だったら大甘いしたよよでももちろん聞いたりしたんですけどこれに関しては見やすい資料とかないですかね大きくは



  • 開発だけじゃなくて開発とか構築部隊とか企画部隊がみんなでミーティングしてるときに使ってる資料があるんですよねそこに割とまとまってはいたんですけど細かくはなってないですけどそれを



  • 全体の概要をざっと持ってきてそれをさらに細かく見ていって今回は何必要かなっていうので見てきましたねそれで現状大きな抜けはないってことなんだはずですそれをチームリーダーと結構才能だね共有してスラックベースで



  • こういうタスクが必要かなと思いました先行提供においてはこれが必要かなと思いました正式リリースだとこれが必要なんで今回はこれ対象外にしてますでそれぞれの今のバグ管理とか言いついてストーラーコース全部どれぐらいかかりそうですっていうのを振ってでまあGitHubのガントチャート日付ピーって線に見やすい感じのあれで引いてみて



  • だいたいこんな感じで4月下旬ぐらいになりそうですっていうのを共有して開発してるっていう段階ですね共有はどのタイミングでどうやってやってました?定例とか?デイリー?スケジュールとかについてはミーティングを設定したのとスラック文字ベースでも送ったって感じですねあと細かい部分に関しては通動とかデイリーでそのタイミングで話してますねなるほど



  • なんか個人的にはこの流れは順平の流れは一旦納得感あるし置いといてなんでこれができたんだっていうのはちょっと気になるそうなんか漏れがなさすぎて裏にLLMの存在を感じる社内フローあるからなんかその人を巻き込むだから上手いこと多分そのフィードバックをもらいやすいような状態を作りながら多分進めてたと思うんですよ



  • これはノウハウというかね仕事の流儀みたいなところですけどねそうですねそれで言うとやっぱりギター部のチケットをまず親タスクを僕は切ってるんですよ今回の機能この乗せたい機能開発っていうタスクを切っててその中で



  • やること書いていくじゃないですかチケットにそこでバーって箇条書きで出していってそれをさらにサブタスクとして切ってやってやらなきゃいけないことは全部バッて文字でちゃんと書いて冗長に見てもらったからですかねなるほど結構フィードバックもらってそこで調整したみたいなのが多いですかコスムで言うとどれだろういやなかったです事前にこれが必要漏れはなかったですねただ要不要のところで



  • これ必要なんですかねとかっていうやりとりは4つぐらい項目としてあったかなと思いますね今言った中でこの機能作ってリリースまでどうって言われた時にちゃんと順平は当たり前のことなんですけど全体を作るっていうところからやって具体化していく抽象的なものを作って具体化していくみたいなフローをちゃんとやってるんですけど



  • それはもう本能の赴くままにやった感じまあそうですね資料をとにかく見たっていうところですからね経験だね経験ですこれは准平が今までそういうことをちゃんとやってきたからいざやれって言われた時にできた感じですね確かにこれ中年試験なら合格してたそうですよね確かにこれは完全に中級エンジニアの動きしてますね違うから残念だけど試験をやってないから開催されてないからねはい



  • ありがとうございますいいですね周りの動きとかがどうやってるんだろうってのを知れて助かりました自分の話をあんまりできなかったのが大丈夫だったかなっていうのがありつつまだ順平の成長が垣間見えたので僕はよしです最初のアウトプットの段階ですでにそんなに問題なかったもんね走りましたじゃあ締めますかハッシュタグひまじんプログラマーでSNSのXフィードバック募集してますので本日のエピソードの感想とかありましたらお願いいたします



  • これは本当に感想見たいな突っ走りますあとは説明欄からGoogleフォームで番組の感想要望質問何でもお待ちしてますただ感想だけでもいいのでお気軽にお願いしますお願いしますリリースこけたくないですねそうねリリース昨日の代謝によるけどトラブルをでも構築部隊が別ならまだいいですねそうですねあとは構築部隊ガチャあるねはいはいはいもちろん会社によるんですけど



  • マジ俗人的だからそれ小八国大の人のちゃんとしてる度によって事実の難易度めっちゃ変わるあとは各種ポッドキャストプラットフォームのフォロー高評価お待ちしてますお願いしますそれではまた次回バイバイまだじゅんぺいの口から聞いてねー中級エンジニアになりたいってイエーイどうせこのままずっと初級エンジニアだと思ってた中級エンジニアなんてなれない



  • なりだーい!

0:00 36:53

#349 「一機能をリリースするまで」をフレームワーク化!!