# チャプター 1 トモとマサとせんちゃんのボイコード ボイシーエンジニアの声と出会えるチャンネルボイコード このチャンネルではボイシーエンジニアの日々の活動をお届けしています 言えたじゃないですか 言えましたね よかった なんか言えるかちょっと自信はないんですけど なんとなくで覚えてるんですけど まぁなんかちょっと間違ってないかなみたいな 気になって 今日は技術ワードトークで アジャイル アジャイル 話していきたいと思います イェーイ イェーイ アジャイルあれですよね ちょうど僕が入社した直後ぐらいに アジャイルの本をリンク外でやってたなーっていう クリーンアジャイル あ、そうです クリーンアジャイルを読んだなっていう感じですけど なんか最近めっちゃ個人的に思ってたんですけど なんか今なんかこう ボイシーの開発って結構一人で 開発していくみたいな感じが主流になってて なんかこう 開発の体制というか なんかどうしたらいいんだっけみたいなのは なんか最近ちょうど他の 他社のエンジニアの方とかとも なんか話してたんですけど なんか今の時代ってアジャイル的な 何か手遣えたりするのかなって ちょっと僕が勝手に 気になることを聞いちゃいますけど なんかどういう考えでいますか どういう考え 別に原理原則はそんな大きく変わらないのかなと 考えている派です 結局なんか早く作って早く出すっていう あとコミュニケーション取りながら みたいなところと あとはテスト 技術的な話のところ そんなに変わらないかなとは思ってはいますが 進め方みたいなところは変わるのかなとは思ったりはしてますね 結構なんかプランニングでがっちり これをやろうみたいな決めてやるみたいな感じだと思うんですけど なんか前やってたプロジェクトのところとかだと 僕がやってたところとかだと なんかアジャイルの一定プランニングしきったところを無視して ちょっとスケジュール的にヤバそうだったっていうのもあるんですけど 無視して先のところ拾って そこはただ先のところはイメージついてるところもあったんで AIにもぶん投げてやってもらうみたいな感じで 自分のリソースはあんまり使わずやるみたいなことは 進めたりとかがあったんで なんかそういう風に変わってきたりとかはあったりするのかなとか ぼんやり考えたりって感じですかね なるほどなるほど なんか完全に順番ミスったなって今反省しました なんかもちろんアジャイルの話を先にすればよかったので そのものの話をすればいいなと思った いつものやつですね 何も考えてなかったです なんか僕はあんまりなんか 当時輪読会したときは そもそもアジャイルで開発するみたいなところを そんなに自分自身経験してないまま とりあえず読んだみたいな感じで 今もう一回読んだら多分違うんだろうなみたいな 自分ごととして理解できるんだろうなみたいな感じだったんですけど アジャイルはどうですか 今の話ちょっと引き継ぐと あれは教科書読んで 地雷を踏んで もう一回読み直して ループで上手くなるものだなって そうですよね 最初に読んだときは僕の中では ふんわりこんな感じなのかなっていうのを こういう考え方がありますっていうのを ちょっと頭の片隅に入れるぐらいで 正直終わっちゃったみたいなところがあるんで 実践の中でやっていく中で 多分困ったことがあって また読み直すと違うのかなみたいなのは 確かにありそうですね アジャイルの取り組み自体は VCだと結構あれでしたっけ 長いんですか 割と最近なんですかそれでいうと どれくらいやってたら長いのかもよく分からない 何かどうかは板置いておいて どれくらいやってますか 3、4年ぐらいですかね なんかやろうと思ったきっかけみたいなのとかってあったんですか えっときっかけ アジャイルを標榜しだしたのは 5年前ぐらいだと思うんですけど アジャイルをやってる感が出てきたのは 2、3年前からですね なるほど 標榜し始めたのは何でですか それは僕入社前なんですけど 当時はバックエンドエンジニアのグループとか IOSエンジニアのグループみたいなのが主体で動いていて かなりどっちだ縦割り横割り どっちか分からない どっちか分からないんですけど そういう作り方をしていたんで 多分うまくいかなかったんでしょうね なるほどそうか チームごとでというか技術スタックで分けられてたから うまくちょっとそこ連携できなかったりとか あったんじゃないでしょうか プロダクトに向けなかったとか なのかな なるほどそうかそうか そこから標榜し始めてから徐々に浸透するまでって どういうプロセスがあったんですか 最初はやってみる感じなんですけど 教科書読まないんですよねやっぱ それはそう はいつまんだ情報 いろんな落ちている情報の組み合わせをそれぞれが持っていて それで試してあんまりうまく回っていなかったのでは なるほど 初感 確かに アジャイルが何かはこのまま喋らずにいくんですか 全然喋っていただいて大丈夫です 適当なタイミングで アジャイルとはって言えるほど怖い これ言うの怖いからあれなんですけど よく対比されるのはウォーターフォール 最初に計画をして 次に設計して 次にコードを書いて 次に動作確認をしてリリースするっていう 年単位のプロジェクトとかを順番でやっていく 序盤要件定義とかちゃんと言った方が良かったかもしれないけど 雰囲気で今言いましたけど からそれを 違うなアジャイルってなんだ細かいスパンに切って 1週間から4週間ぐらいの単位に切って 常に計画をしながら そうですねウォーターフォールって基本前工程が終わったら 後ろに行くというか次に行くみたいな感じで そこからまた戻ってみたいなのをしないイメージはありますね だから一回計画経ったら終わってるでしょみたいな そういう感じなのかなと思ってました 設計フェーズの終わりは 設計フェーズが終わったと宣言した時なんですよ ウォーターフォール的には 終わったと宣言した時難しいですね 最初の計画段階で 設計に3ヶ月かかるって見積もってたら 3ヶ月経って その時が来てしまったら終わり なるほどなるほど ということにする みたいな運用がよくある失敗としてありがち みたいな話はありますね 確かになんか 細かくやった方がなんか開発しやすいんだろうなみたいなところは 確かに実感的にもありますね ウォーターフォールがダメでアジャイルがいいみたいな話ではなくて なんかうちとかみたいな小さい会社やってたら それアジャイルの方がなじむでしょうって感じがするんですけど なんか超巨大な日本中で使われるシステムみたいなやつが アジャイルに行われてしまうとっていう アジャイルでもいいんですけど ワンパワーがめっちゃいるとか 作業員が1000人くらいいますみたいな規模感で アジャイルができるかよく分からない 基本アジャイルの思想としては会議というか イベントには全員参加しようみたいな 100人体制ですから100人集まるのは無理だよねっていう感じですよね ウォーターフォールの方が都合がいいっていうのはありそうですよね なるほどなるほど # チャプター 2 弊社のアジャイルの編成の話をしますか? いいですね 僕は途中からしか知らないかもしれないですけど 僕が入社した時ぐらいが2021年の年末なんですけど さっきの職能別のチームを解体しましょうぐらいのタイミングで うちって2月からキーが始まるじゃないですか その次の2月で機能開発向け? リスナー向けチームとパーソナリティ向けチームってその時だったかな? もうちょっと後だったかな? 忘れたんですけど そういうユーザーさんに向いたチームみたいなのができて アジャイル風味なものをやろうとしていました なるほど 確かに僕も昔のiOSDCの発表でチーム体制の発表とかあって こういうVoicyではこういう体制でやってますみたいなのがあったんですけど 入社した時全然違くてびっくりしました そんなのあったんですか? ありました そこから? そこから1年半ぐらいは同じ感じでやってたんじゃないですかね たぶん23年ぐらいまで 23年夏ぐらい? 本当かな? うろ覚えですけど1年ぐらいは誤差が多分あると思うんですけど そこから? 僕が入ったのが24年の1月なんですけど その時ユースケースの本読んでたから そうですねそこでユースケースの本始め じゃあもうちょっと後か?ちゃんとやってるのは2024年からか クリアジャイル読んだのはたぶん2024年じゃないですかねたぶん え? 2年ぐらい雰囲気でやってたってこと 教科書読み始めたのが高校2年ぐらいって感じで になっちゃうね そうですね僕が入社した後だったと思うんで 結構最近でした でもだいぶ浸透じゃないですけど あれはもう教科書ですみたいな感じで話してるから みんな読んでくれるっていうのはありますよね リンドク会も2回やりましたしね あ!2回やってるんですねなるほど 友さんが入ってやったのが2回目です 2回目かなるほど 確かに社内で開発してても クリアジャイルに出てくる用語がポンポン飛び立っているような感じはしたんで 入社した時 これがスタンダードになってるんだろうなっていううちでは そんなのありましたね 結構初めて読んだ時は驚きじゃないですかね 驚きじゃないですけど学びがすごく多かったなっていうイメージがあった気がしますね どんな学びが でも僕くらい言ったんですけど UTPPと混ざってるような感じで 繋がってるんであれなんですけど 反対テストな考え方使い方ですね放題は 今言ったUTPP 結構混ざっていて クリアジャイルと そのあと XPの本僕個人的に読んでて エクストリームプログラミング とあとさっき言ってたUTPP ユニットテスティングプリンシパーズプラクティスイベントのパターン いつも順番わからない その名前なんだ とあとそのちょっと後に読んだアジャイルエスティメイティングアンドプラニング その話とかも結構混ざっていて どれがどこからとかは あまり聞けない 今喋ろうと思ったのが テストが書けないならコードが悪い設計が悪いっていう話をしておくんですけど でもこれUTPPだった気がするな 確かに そこまで踏み込むとそっちだね 確かに あれも了承だったな あれすごいよかった あれでバックエンドのアーキテクチャがガラッと変わったんだ そうなんですね 確かに 今の構造になってるのはあの本のきっかけなんで なんかもうちょっと脱線しちゃいますけど なんでそのテストの本でアーキテクチャがゴロっと変わるって感じなんですか テストを書くにはアーキテクチャが綺麗じゃないと書けない なるほどなるほど じゃあそういう時代があったということか 今もたくさんあるじゃないですか 確かにそうか 昔のコードは 比較的新しめだけどちょっと前のコードとかあとテストないとか全然あると思うんで 確かにな そっからもうテストないとはありえないよねみたいな感じになってきてると思うんで ここら辺はすごい転換点だったんじゃないかなと思いますね 確かにな テストそもそもあんまりなんで書くんだっけみたいなところとかは 僕もあんましよくわかっていないみたいな感じだったんで 確かにテスト書こうと思ったら ある程度依存性注入とかをできるような形にしておかないとみたいなとこありますもんね そうですね 外から入れられないとテストできないところがある 当時のクリーンアジャイル読んで なんかお!みたいなのあったりしましたか? マナティック的な そうですね 結構記憶が1年ぐらい前なんで怪しいですけど なんか見積もりの仕方とか なんかベロシティ使ってとかそこら辺の考え方とかは 今まで雰囲気っていうか完全に1週間ぐらいでできると思いますみたいな 1週間みたいな感じだったんで そこら辺をチームでやろうと思った時に どうやって管理していくのがいいんだっけなっていうところとかを 定量的にかつチーム内でちゃんと足並み揃えてみたいなところとか 進め方の部分は結構参考になったなっていうか こういう考え方でやっていくといいんだみたいなのが勉強になったりとか あとはやっぱりさっきの開発の うちの開発だとやっぱり細かく小っちゃいものを 短いスパンでどんどん出していくみたいな発想とか そういうのがあったりとか うちの開発だとやっぱり細かく小っちゃいものを 短いスパンでどんどん出していくみたいな発想とかも 意外とそこら辺当たり前のことかもしれないですけど もうちょっと大きく 僕とかだと短く最短で出すっていうよりかは 1個のまとまったものをちゃんと出すみたいなところをやりがちだったりとか こっちをやった方がいいよねっていうのを あんまり期限とかスピード感とかそういうのを考えずに 結構やるべきだから時間かけてやりますみたいな発想とかも 意外とまだあったんで そういうところがちょっと考え方が変わったなっていう感じでしたね 個人的にはJobanに書いてあった一番大事なものは何ですか? 期限です っていう一文があって面白かった あれ?この本かな? 違う本かな? あったっけな? あったもん あったあった あったんですよ 計画をしない手法じゃないよっていうのが 改めてちゃんと書いてあったのが良かった アジャイルエアプの人たちの先入観って 早く作って早く出せばいいんでしょうって 急いで早く作って ちゃんとやらないものなんでしょうっていうのがあるんで すごい隔たりありますよね その感覚 設計を 設計が後から変わるっていう現実を ちゃんと受け入れてるというか その上で計画をちゃんと細かくやっていくっていうのですよみたいなところ 行き当たりばっかりではないというか 早くするっていうところの解像度を上げるじゃないですけど ちゃんと書かれてたって 汚いコードは末からく遅いっていうのは一文としてあった気がしますね あったかもしれない それはめっちゃ覚えてますね あともう一冊あったな関連本 アジャイルテスティングを読みましたね これはQAエンジニアの人たちがアジャイル環境に適応するために必要なことっていうのがあって ここでひしきりに書かれてたのが ストーリーの完了条件をテストにしようっていう これもすごい 確かに すごい刺さりましたね 途中から内容がすごく重たくなっていったというような気がしてますね 記憶面 ちょっと古い本今となっては 出てくるテストツールとかが古かったりして 今はこれじゃないよねみたいな あったりはしたんですけど # チャプター 3 一時期、アジャイルを学んだ後、UTPPPを読んでいたぐらいから すごいテストについてみんなで学ぼうぜ、みたいな雰囲気がありましたよね。 あったね。 風潮が。 凛とくもすごい、それの放送。 あれ?どっちが?順番があれなんですけど、 多分クリーンアジャイルを最初に読んだのは絶対最初で、 その後にユニットテストのUTPPPを読んだのかな。 その後にアジャイルテスティングを読んで、 アジャイルテスティングを書いた著者の方がもう一冊書いたりしてるんで。 MORE? MOREか。MOREアジャイルテスティングか。 あともう一つ、パーティンファウラーのシグネチャーのシリーズの なんだっけな、UNIX?あれ?なんだっけな。 あ、はいはい。 結構分厚い。 分厚いやつね。 名前が出てこない。 Xテスト?あれ?違うかな。なんだったっけな。 Xユニットテストパターン。 Xユニットテストか。 それも読む?みたいな。 読まなかった。 読まなかった。 みたいな感じで。 結構やっぱ考え方がそこですごい、 自分自身もですけど、多分組織としても変わったんだろうなっていう。 そこからすごいいろんな広め方じゃないですけど、 宣伝じゃない、不協活動みたいなのをしたりしてましたもんね。 へー、そんな時期はあったんですね。 単体テストよりクリーンアジャイルの方が先だった。間違えた。 クリーンアジャイルじゃなくてアジャイルテスティングの方が昔だった。 そうなんだ。そっちの方が先に読んでたのか。 えー、僕の2024年の振り返りノートに。 えー、そっちの方が先だったのか。後のイメージでしたね。 どっちが先と言われてもよくわかんない。 まあ、確かに。 UTPPP読んですごい満足したのかな、みんな。 もういいか、みたいな。 その後DDDの方に読んでるからね。確かにDDD読みましたね。 あれ?あ、そうなのか。 ブルーブックっていう、エリック・エヴァンスの原点の方の方。 あれもあんま重かったですよね。 途中最後読めちゃったな。 そんなに? その後読んだ、多分せんちゃん読んでると思うんですけど、 ドメイン駆動設計をはじめよう、すごいいい本でしたよね。 ラーニングドメイントループンデザイン? すごいよかったですよね。 なんかでもあれですよね、アジャイルもそうでしたけど、 最終何のために開発するんだっけは、 どの技術書とかでも結構大事なことが多いですよね。 ユーザーに価値を届けることが一番大事だよな、みたいなところとかは、 プログラムを書くことだけが仕事ではないですよ、みたいなのが結構大事だなって思いました。 今週はこんなところで、 次はどの声と繋がりますか? 引き続きボイスでお楽しみください。