# 1人1プロジェクトを担当する、キャッチアップのコツ のんちゃんと たかまちぃと すぴーくんと ともの ボイコード Voicyエンジニアの声と出会えるチャンネルボイコード このチャンネルではVoicyエンジニアの日々の活動をお話ししています。 よろしくお願いします。 お願いします。 いつもね、最近は週末版しか喋ってなかったんですけど 久しぶりの通常回 僕それの存在初めて聞いて 歴史的経緯があるんですね 今日はですね、この4人は同じチームなんですよね データAIチームというチームで普段 毎日朝からおはようからお休みまで デイリーからレトロまで 日々色々やり取りをしておりますが 今日はこのデータAIチームで新しい取り組みというか 開発スタイルに挑戦したっていう 1ヶ月、2ヶ月とかかな その振り返りだったりしていきたいなと思っておりまして 全体の話をさらっとだけすると もともと私たちは1つの開発を3人とか 例えばiOS担当、Android担当、バックエンド担当みたいな感じで 3人で1個のプロダクトを作っていくみたいなスタイルだったんですけど 今プロダクトエンジニア時代、弱 弱まさに 1人で1つのプロダクトを開発して プロジェクトを同時に 3人いるんだったら3つのプロジェクトを同時に回していきましょうっていうスタイルに 変わったというよりも 1、2ヶ月前にこのチームから試してみましょうみたいな チャレンジの そんな1ヶ月でした ちょうどもう1ヶ月、2ヶ月ぐらい経って 改めてどういう学びがあったのかとか アウトカムどうなったのかとか 少し学びのところをいろいろ話していきたいなと思っておりますので よろしくお願いします 結構ラフにみんなに振っていこうかなと思っておりまして 最初に つまりもともとIOS IOSエンジニア、例えばトモさんだったら IOSしかやってなかったところから 急に1個のプロダクトを1人で全部やってください はい、今日からですみたいな 衝撃のスタートで もともと今いるキークとタカマティさんは 結構いろんな開発やってたと思うんだけど 特にトモさんはIOSエンジニアとして入って 基本IOS 今まで僕IOS以外ほぼ触ったことなかったので そういう意味ではマジで全然やったことない仕事を 突然やるみたいな そんな大きな変化がありました まず聞きたかったのは いきなり自分の専門外の領域を はい、お願いしますって言われた時に どうやって調べてたり どうやって開発を進めていったのかみたいなところを トモさんに聞きたくて そうですね いろいろなパターンはあるんですけど 基本とりあえず前準備で勉強はしました なるほど ちょっとやっぱバックエンドとかも あんまりよく分かってないなとか っていう領域が結構 特にバックエンドは バックエンドの開発やってくださいって 他の例えばWebフロントとか あとはAndroidとかと違って 領域がめちゃめちゃ広いんですよね 関連領域が多いから 必要な知識もめちゃめちゃ多くて 最初はとりあえず 何も分かんないのが嫌だったので データベースのところのSQLの勉強だったりとか あとは語言語 Voiceだとバックエンドを語で書いてるんで 語の勉強だったりとか あとはインフラ周りの幕場ネティスの勉強とか そこら辺はちまちまと できるタイミングでちょっとずつ 広く浅くやっていくみたいなのはやってましたね そうか 今回だと大体全部開発やりました? そうです 多分ほぼ全ての領域を触ったんじゃないかと思います そうか 取っ掛かりとしては トモさんは最初どうやって勉強していくんですか? 書籍買ったりとか動画見たりとか そういうのもあるんですけど でもそれでできる勉強って正直知れてるっちゃ知れてるんで それで全然できますとかっていう感じではなくて 最初のハードル下げるぐらいの そういうニュアンスでやってましたね 実際の業務としては とにかくAIを使うっていうのは もう避けられないというか 逆に今一人でプロジェクトを進めていくっていう体制も 多分AIがこれだけ進化したからやれるよね みたいな前提はあると思ってて なので基本調査のところから 実装方針の相談とかを 基本とにかくAIをいろいろ使ってみて 壁打ちしてその中身見て これってこうなのっていうのを相談しながら 進めていくっていうのが多かったかなと キー君も基本メインはウェブとバックエンド? そうですね 前までやってきたことはそうですね 初めてのアプリ開発を アプリ開発を やりましたね そうですね どうでした? 前々から興味はあったんですけど 面接 そうですね 実際アプリのライフサイクルというか アプリ固有の知識とかはない状態から いきなりやろうってなったので ちょっと大人になりましたけど でもそうですね AIに 僕は結構本とか読むの苦手なタイプで 結構リズムでガンガンやっていくタイプなので そこで僕がやったこととしては 一旦AI実装してみて それを質問責めにするっていう それで理解を深めるっていう ところをやってましたね 僕がやったこととしては あれだよね まず側を作って それを整えていくみたいな まずこういうのがアウトプットとして出ますよう チームに見せて そこから裏々となって ちゃんと自分で納得する っていうある程度までは やってました そうでしたね 思い出してきました この1、2ヶ月のことを 高畑さんでいうと 唯一フルスタックなので 何て言うんだろう もうずっとやってることを みんなやっと追いついてきたかみたいな そんな高い位置にいるわけじゃない 僕は特に専門領域ってのないので 名乗る言葉としては その他エンジニアという 言葉であるんですけど 今までの延長線上で ちょっとやれていた感じは ちょっとはありますね でも最初の取っ掛かりの ハードルの低さは 高畑さんは早そうですもんね キャッチアップの仕方とかも 友さんとキー君が言ってくれたことに 全ても含まれているので 同じような形で アプローチはしていったかなと思います 1日の時間の使い方とかって 今までと変わりました? 確かに僕は結構 iOSとAndroidを並行して 開発してますけど パソコンこんなに重くなるんだって 初めてでしたね 体験は 1個変えたのに 確認するのが結構 Webとワークによりは フィードバックサイクルが 長いというか フィルドの時間が 確かに そうだよね 新鮮というか そうなんだと思いました # 爆増するレビュー依頼、レビュいーとしての心構え キー君に関しては、リリースサイクルというものが ウェブだと基本を出そうと思ったら出せる Voicyは今週1回リリースを定期リリースとしてやってるんだけど コードフリーズがあって、ってことはここまでしか実装ができないです その感覚に慣れていくのも初めてだったよね これは今までアプリエンジニアはこういう気持ちだったのか コードフリーズのエンジニア 木曜日にコードフリーズということはあるね いろいろ逆算していくと あれ?実装期間2日しかないんだよ もうやばいじゃん 逆にトモさんウェブやって、まだいけるんですか? いつでもいけるっていう めっちゃいいなとは思ったんですけど 時間の使い方とは関係ないですけど リリースフローめっちゃ複雑で 2回くらいキー君に見てもらって大丈夫ですよね 一通り手順を確認するのは結構大変でしたね 時間の使い方みたいなところに関連するんですけど レビューとのやりとりとか 結構工夫されてたのが高本さんだったかなと思って めちゃくちゃ出しましたよね めちゃくちゃ出すのを事前予告してましたよね 結構複雑な実装とかやるときは 事前に握るじゃないですけど 一回意識合わせしてからの方が手戻りが少ないので そこは結構慎重に 同時にいろんなプロレスがレビュアに行ってしまうという状況ではあったので そこはレビュアの負荷を下げるという目的もあって 事前調整みたいなのは結構意識してやってたつもりです この開発方法のやり方だと レビュアへの負荷が課題になりそうだなと思って その辺工夫したこととかありますか? そんな僕は実はあまりないんですけど でもこの体制って本当に 今までってチーム内である程度レビュアを完結させてて だからそんなに影響を気にする必要はなかったんですけど 僕ら3倍やってるんで 3倍プロリクスを作られて週に それを誰かが見なきゃいけないっていう体制になるんで そこら辺は僕もそもそもこの試験的な試みの中で どれくらいプロリクス出しても大丈夫なんだっけみたいなのは 事前にエースチームに相談したりとかはして 大丈夫そうだねって話だったんで いつも気にしてるちょっとリュードというか 大きさだけある程度コントロールしながらやるとか あとはコメントとかつけるとかは結構意識的にやったかなと思って ここなんでこうしたの?みたいなのが突っ込まれそうだなっていうか 文脈がないと分かんないなって思うことは補足するみたいなのは意識してましたね そうですね レビューとか聞くのにこだわりとか工夫とかありました? 僕もここはこうですっていうコメントを2人はあったんですけど 結構難しかったところなんですけど プロリクスを結構小さく 気持ちとしてはレビューを依頼したかったんですけど 結構大きめになっちゃった そこがちょっと難しいなと思いました アプリ始めてだったっていうのはあるんですけど でもだんだん工夫していきました モバイルとウェブでPRの大きさもコツがある? 慣れてない領域でプロリクスを出すこと自体が そんなに簡単に調整できるわけじゃなくて 普段は自分が知ってるところだから これとこれは分ければいけるよねとかが どこを分けたらいいかっていう 考えをつくのにも結構時間がかかる 慣れてないと難しいなっていうのは しかもそうですよね AIがコードを作ってくれた上で出すから どこが何? なるほどありがとうございます 今回私たちはじめてプロジェクト計画書ベースで 開発をしてみましたね 結構この話はしたい これは結構話すことある プロジェクト計画書を一番最初に作って 進め方として一番最初に 試しに私の方でクロードで作らせて 必要な内容を 作ったものでここいらないねとか ここ必要だよねっていうのを 最初叩き大木君と一緒に作ったのかな それを他の二人の次の開発に 使えるようにすぐスキル化して ポチッと押したら生成されるようにして そっからですよね プロジェクト計画書 すごい使いこなしてるのが高松さんだったかなと思って どうでした? これは結構人によって味が出るっていうのはあったかな 味ありましたね わかるわかる 色々問題は僕はあったんですけど 個人的な思いとしては ファーストビューというか 一回画面を見た時に 情報量を少なくしたいというか 入ってくる情報量を簡潔なもので済ませたい スクロールはあんまりしたくないという気持ちがあったので 結構ページは階層構造で作るみたいなので そこは意識してやってたかなと思います そうですね 私が結構大変だなと思ったのは 情報の集約とかが このプロジェクト計画書ベース開発は 基本ここを見れば全部わかる状態になっている 最新情報がここにあるっていうものがすごく大事で その差分を拾うのとか あとなんだろう これは朝会で話した内容がまだ入ってない気がするとか 日々変わるのかな そうなんですよね 私はプロジェクト計画書スキル図と もう一個プロセス監督スキル図を作っていて それを結構工夫していったのはありましたね 情報を何か指示する クロードに指示するときに 必ず今の最新のプロジェクト計画書を読んでください 読んだ上で前回見たときからの差分を 分かるように色を付けてくださいみたいな感じにして 見ると高本さんここのUIを なるほどこの方針変えたのねとか ここ確かに朝会で出てた話だったけど 結局これってどっちになったんだっけとか これを実装しちゃってから 直す戻すとかってなると 手戻り大変だったと思うので ここを細かく確認できたのは良かったなと思いつつ 大変でしたね 情報が常に新しくないといけない 情報が多いじゃないですか 販売だから大変だよね そこも結構大変だなって スタートのとき発狂してましたよ 同じ日にスタートしたんですよ サンプロジェクト 入っているから まずこれの 大変でしたね キー君どうでした プロジェクト計画書ベースの開発 でもそうですね 今まで割ときちっと プロジェクト計画書を作った時よりは 自分が確認することをまとめたり ぐらいのものだったので プロジェクト計画書を作って 全部を見渡すっていうのが 大事だなって思ったのと 結構大変だなって思いました プロジェクトって 開発だけじゃないなっていう # プロジェクトってコードを書くだけじゃない そうですね、プロジェクトってコードを書くだけじゃない、エンジニアをやることはコードを書くだけじゃないっていうのは分かってましたけど プロジェクト計画書を見ることで、ここまで見渡さないとプロジェクトエンジニアと呼べないと プロジェクトエンジニアってね、全部でいますからね キー君が大変そうで私ともどうするってなったので覚えてるのは ジラのタスクとプロジェクト計画書に書いてある内容を結構被ってたんですよね 被っててどっちを更新していくみたいなので、どっちか途中からもう更新してなくなって でも合わせる作業が一回あった プロジェクト計画書は割と更新してて、後からクローブとかでそれとジラインを合わせるみたいな感じでやってました そうだよね、ここが自動で突合されるように仕組みにすれば結構楽かもしれないですね タスクが生成できるようにプロジェクト計画書をしっかり作るってのは開発においてもいいのかなって どんさんどうでしたこのスタイル 僕はですね、とても良かったなって思ってて 正直僕プロジェクト計画書を今週作ったんですけど、それだけが一番個人的には良かった 戦いの中でどんどん成長して 僕の中の答えというか、こっちの方がいいなみたいなのがいっぱいあって 僕プロジェクト計画書でちょっと辛いなって思ったのが、AIに生成されたドキュメントって読むの結構辛いなと思ってて 今までだったらチームで一つのプロジェクトである程度コンテキストが共有されている状態でみんな資料を読むことが多かったので ある程度文明を補って自分で理解できるっていうのが結構あったんですけど 今ってそれぞれ全然違うプロジェクトやってて 今までよりかは情報量が減っている状態でプロジェクト計画書をみんなに読んでもらわなきゃいけなくて それをAIに書いてもらったやつだと結構中身が頭に入ってこないなって自分は感じることが多くて 僕はある種逆行しているような感じがあるかもしれないですけど、手で書いています 全部じゃないんですけど 漢字の読んでほしい内容に関してはちゃんと自分である程度箇条書きとかで内容整理して それを最終的にAIに構成させてドキュメント化するみたいなところはちょっと意識していて やっぱドキュメントって愛だなっていう ドキュメントは愛! いいですね、生まれましたね やっぱり自分でやることとかを整理するっていうのは開発でも結構大事だと思っていて やるべきことが見えてきたり逆に今まで分かってないところが分かってきたり浮き彫りになったりするなみたいなのがあるんで そこら辺はAIを使うべきところと使わない方がいいところみたいなのは自分の中でちゃんと線引きしながら 最終的に効率よく作るってこととやっぱりドキュメントに関しては読んでもらうことが前提なんで いかに早く作れても読みにくかったら何の意味もないなと思ってるんで 逆に僕は意識してるのは読める分量を15分ぐらいで読めなかったら多分それは読んでもらえないなって思うんだから 読みやすいような情報とかも補填しながら書くってことを意識してやってました ありがとうございます あとはですね、私の話をしようかな 結構難しいポイントになったな プロセス監督って何ですか? 知らなかった、さっき出てましたけど 一番最初に山原、我々のボスから最初にこの体制にしますみたいな説明の時に 山原ちゃんは急にプロセス監督として動いてもらって プロセス監督? 新たな役職 それの定義もちゃんと教えてくれてたので それはやっていったんですけど 一番思ったのは身構えてたんですよ プロセス監督、何したらいいのかなとか やって2、3週間目ぐらいの時に これいつもやってることじゃんってなりました 立ち回りは確かに変わってはいないって 変わってはいない部分はあります QAってテストだけじゃなくて 全体のリリースまでの全部の流れとか 新職大丈夫?とか 本当にこれで目的にヒットできるんだっけ?とか なんでそもそもこれ作るんでしたっけ?とか そういうこと全部をやる時の 別に名前は何でもいいんだなと思った 一番大変だったのはやっぱり情報で 今まで私はとはいえ2つのチームを イネブリングチームとして見てたんですけど 2つのチームは1チーム1回作をしてるから 最大2だから あとタイミングってずれるので リリース、QAが忙しいタイミングって こう波があるので 最初と途中と最後と この要所がある中で 今回私たち結構小さめの開発を 一人一プロジェクトでやっていく時に 同時にスタートして 今高畑さんの案件はこうだから どっちまでいい?みたいな 次キークのところでは このペースでは何をする?みたいな すごい情報がとっちらかっちゃって あれを導入したんです アラート制度を導入したんですよ アラート制度 アラート制度を導入しました アラート制度というのは ちょっと説明を 1週間の中で だいたい木曜日にコードフリーズにしていて ってことは客さんすると いつまではコードをいじりますとか 例えば水曜日の朝の段階で ここまで終わってなかったら もうちょっとエスカレーションというか PDMの方に 来週リリースできないかもしれません って言わなきゃいけない っていう時に これを今までだったら 一人一プロジェクト 一人で1チームを見て 1個の開発をしていれば そんなに細かく追わなくても 幅感で分かるんで そろそろじゃあとかできるんですけど 4つに増えたので 仕組みとしてやばかったら 言い合うというか チェックをする 確認をするポイントを作るっていうのは あれはやってよかったなと思いました あんまりQAとしてやっていることは プロセス監督としてやってることと そんなに変わらなかったっていうのが すごい驚きでしたね結構 開発全体をみんなが見てるようになったのは やっぱそこら辺は大きな変化かな # アウトカム：1案件あたりは同等、スループットは約3倍 はい、ではここまでは感想とか奮闘みたいな話をしてきたと思うんですけど 実際このスタイルで開発をしてみて アウトカムとか数字に出ない変化とか 視座どう変わったかとかの話もしていきたいなと思っていて リリース数とか速度とかって体感どうでした? でもヤマゲンさんも言ってましたけど チームでやってたら僕がやってた案件は 僕が一人で終わった日にチームで終わってたよねって言ってたので その3プロジェクト並行したから3倍のアウトプット出たよねっていう話はしてました すごいね、だからシンプルに一人一個で同じ速度でリリースができてる感覚ありますよね確かに すごいな、だからアウトプット3倍になっている なんで3倍になったんだろうって不思議なんですけど 確かに、それなんでですかね チームだとみんなで情報を共有したり それも大事なんですけど そこの情報共有とかに時間かかったりとかもしたりとか 一人でやると調整は割と少ないかなって 自分で全部見なきゃいけないという責任はあるんですけど そういうとこもあったのかなとは思うんですけど あとはくまPさんが攻めてましたよね くまPさんが攻めましたよね 一つ歯車が崩れたらそれでも全てが終わるっていうぐらい 短期間ではあったので そこでマイエイムを使いながら どこまでやれるのかっていうチャレンジをしてみたいと思って 確かに個人ベースでのリリース数は今まで以上にアウトプットは上がったという体感はあるんですけど なかなかきつかったです 経営的な感想は だからこれを今回は高森さんは己を追い込むタイプじゃないですか それをもうちょっと持続可能な形にしながらであれば シンプルに3倍にするっていうのは効果がありそうというか アウトカムを埋めそうな感じ 埋めさせると思いますね トモさんはどうでした体感、品質、スピード スピードに関しては 一人でやるから当然時間がかかるでしょって思ったんですけど あんまり変わらないなっていう気がしていて むしろ1週間でアウトプットしなきゃいけないものが増やせた気はしていて もしかしたらこんなにあれ出せたんだみたいな感覚はあったんで スピードとかは特にこの体制になって チャレンジではあるんですけど だからといってスピード落とすのは違うでしょみたいな そういうところもあったのかなと思うんで むしろ上がったかなっていうのが正直な感想ですかね 品質のところも 一人でやってるんで多少ちょっと不安な部分はありつつも そこのところしっかりテストケース作ってレビューしてもらったり みたいなところとかである程度拾えてたところはあったんで 大きな不具合とかはチームでもなかったかなっていうところではあったんで そこら辺ある程度開発規模とかによっても多分違うと思うんですけど そこら辺はプロセス全体を見るところとかを工夫したりとかで 結構カバーできたところはあるかなと思うんで 結果やってめちゃめちゃ良かったんじゃないかなと思いました 横から見ていた私のすごくいい変化というか いいなと思ったのが この前に3人で開発してた機能あるじゃないですか その時ってちょっと開発の質も違ったとは思うんですけど 自分たちでできるところまで考えて 本当に分からなかったら聞きましょうっていうスタイルだったなと思って だからちょっと時間かかったところがあって 多分それを言った気がするんですよ もう最初から聞いちゃえばいいんじゃないですかって 確かにそこら辺難しい 今回自分の専門領域じゃないって思っているからか分からないんですけど すごい人に聞いてるなと思ってて これがすごく良かったんだと思ってて ある程度自分が専門として これを任されている この狭い範囲を任されているって思ったら やっぱり自分でやりたくなると思うんですけど 自分も聞きに行ってるなって思ったんですよ だから早かったんじゃないかな だって聞けないと間に合わないもん これは横から見てたから思いました 確かに 実装する前にあらかじめこういう感じでいいですかとか そういうコミュニケーションは前より多かったかもしれないですね 特に自分が自信がないからっていうのもありますけど そんな過ぎてもう助けてくださいみたいな 序盤にある方がいい 早めに相談できてるから 後からめちゃめちゃこれどうなるんだっけみたいなのは少なかったかもしれないですね しかもこれが溜まっていくとみんなの慣れ違いが 今は全然慣れてない状態で3倍ですけど これ慣れていったら多分3倍どころじゃないだろうなっていうのは ちょっと期待値あるなというか それがすごくいい変化というか いい学びだったなと思います 最後なんですけど 難しかったこと これやって なんだろうな すごい今私たちも感想を喋りながら すごいスムーズに超完璧に終わりました というよりはなかなか悩みながら見てやってたなと思ってて 難しかったところとか話していくと 私がすごい印象に残っていることで言うと チームとして開発をしていくっていう なんだろう 変わっていく形が変わっていくだろうなとは思いました レトロ 今私たちと スクラムのやり方を踏襲してちょっと 真似てやってはいるんですけど そういう中で デイリーとレトロとプランニングと とかをやってます 今までって3人で1個だったんで みんなで同じ振り返りをしてたし みんなで同じ進め方をしてたし そうしないといけなかったので 結構本質的な振り返りができてたなと思ってたんですよ 誰かが全部が自分ごとになってた 誰か1人が難しかった苦戦してたところに 自分ごとでめっちゃ入っていく 相談していく ただ今回のスタイルだと やってることよりは違うので なんか大変そうですよね確かに になっちゃうっていうのがありましたね これは結構チームで開発をすることを もう一回捉え直すというか 組み立て直す必要があるなっていうのは思ったけど 正解はまだわかんないなと思いました チームでやる意味薄れるまではいかないけど どうやって関わっていくかというか そこは難しいなって僕も思いました あとは3人に聞きたいのは やってみてこれ以上は厳しいかもとか難しいかもとか 前提もっとこの辺変えなきゃねとか 難しかったことあったらお聞きしたいです そうですね さっきも言ったんですけど プロジェクト全体を読み渡すっていうのプラス 自分の実装するところじゃなくて 仕様もこれでいいんだってとか ちゃんとそこから考えてやることは まだ足りてないなって思いました そうだよね # これからの開発の在り方は、1人1案件に近い形に寄っていく キー君と途中で大反省したのがさ 我々はこれを作ってくださいって言われて作ってるよね これはちょっとでもこの開発のやり方とは違うか そうですね、ちょっと文明が違うかもしれないですけど 結構そういう節はあった 仕様から考える、誰がどういう目的でどう使うか この数値を上げていきたいから こういう機能が必要だよね、みたいなものを もちろんそれは以前も PDMと一緒に考えたり 共有してもらったことに対して この方がいいかもね、みたいな話とかはしてたんですけど よりプロレスの全体を見守らないといけないから それを自分がしないと そもそもこれを実装して 意味あるんだっけ、みたいなところの責任を 自分がやってるから意味あると思ってて そこが大変だなと思って そういう話もチームでやってたらみんなで話せるけど 今も一応チームなのでみんなで話はするんだけど プロジェクトの始めとかも共有はしますけど でもやっぱり向き合ってるのずっと一人になっていくので それとAIが AIとずっと話してる 高本さんとかはありますか? 難しかったとか? アプローチの進め方が難しかったかなと思ってて 単純にこれまでやってた自分が見る範囲が もっと広がったって感じかなと思って バックエンドだったりとか いろんな領域を見つつ 仕様の部分を見たりとか PDMとやり取りしたりとか 自分起点で自分が関わる領域とか 見るべきと視野をどんどん広げていくっていうので 結局AIに指示を出しながら 自分に一気に負荷がかかってくる 疲れるって一言に僕の場合落ち着いてるんですけど 基本AI使ってるので 自分からAIに頼んでっていうので AIに仕事をしてもらってるんですけど AIからも動いてほしいなっていうのは この映画として思ったところで そうすると今までのチームみたいに 分表で自分が気づけない視点を他の人が持っていたりとか そこで他の人との議論の中で新しいことが そこでまた分かったりとかっていうのを AIを組み込むことによって 今まで通りの視野の広さもさらに担保しつつ もっと自分への負荷を減らしながら もっとアウトプットを出していけるって方向に アプローチをまた次変えていきたいなっていう 課題感を持ちました 何個も目を入れるみたいな どうやったら実現できるのかな そうですね いろいろとAIにもっと集中していかないといけないな という話をしておりましたね 定期的に それこそプロジェクトを プロセス監督みたいな レジェンドを一個置いておいて その人と話すみたいな その人と話しました ここ変わったんでってめっちゃ言っちゃった なんでここ変わったんだよ大丈夫 会話してる AとB 矛盾してますよって言われて Bどこから来たのみたいな 自分で書いてくるけど Bどこから来たんですかみたいな ここか直しますみたいな やり取りはめっちゃ便利でしたね 確かに レビューさせてますねうまく そうかも トムさんどうでした 難しかったことは やっぱり高畑さんの話とも通じる部分はあるんですけど コンテキストのスイッチ結構大きくて それは大変だったなっていうのはあって 開発だけで言っても 特に僕は触った場所が多かったっていうのもあって プラットフォームが 一個一個やることは同じはずなのに 実装の中身が全然違うみたいなので それぞれで考えなきゃいけない っていうところで スイッチするのが結構大変だなっていうか そういうところはあったのと あとは今回チームとして 一人一プロジェクトっていう体制で みんなで頑張ったってところはあると思うんですけど それができたのも結局 環境を整えてもらったおかげだなと僕は感じていて レビューのところを基本的にはコードオーナーが見てくれるみたいな感じで 一番詳しい人がちゃんと見てくれてるから 安心して開発できたよねとか 自分のアウトプットの質とかも ここを直したほうがいいんじゃないのとか っていう意見とかもらえて 結果的にクオリティも高かったのかなっていう 品質の面もあったかなと思うんで 逆にこれ全員が同じ 一人一プロジェクトを仮にやろうと思ったときに そこどうすんだっけみたいなところとかは まだまだ課題あるかなと思ってるんで そこら辺は厳しいというか難しいなというか これからいい方法を考えていきたいなというのを ちょっとやってて思いました これ人数増やしたらスケールすると思いますか? みんながこのスタイルで ある程度やっぱ決めないといけない まだそのデビューをどうするとかっていう問題が出てくるから そこの仕組み作りをうまくやるという課題はありそうかな じゃあ逆に前の体制に戻すんですか? は多分ノーだなって個人的には思って やっぱり体感としてこっちの方が全然早い 開発の在り方は多分こういう方向性で 一人一プロジェクトに近い形になっていくのかな っていうそんな感覚はありましたね これ他のチームもみんな一回やってほしいですよね それぞれうまみがありそう 良かったなってやって ありがとうございます 締め方を全然考えてなかった すごい私は学びになりました またちょっとね 一回の体制は見直すのかな またこのやり方をどこまでやるのかは 分かりませんが すごく学びはあったし 他の会社もこうなっていくのかな なってる会社も全然ありますね そっかそっか 私たちの学びとか発信が 他の会社さんでも ナレッジとかとして 伝わっていくといいなと思いました ありがとうございました ここまでお聞きいただきありがとうございました 次はどの声とつながりますか 引き続きボイシーでお楽しみください