創業期から全員でつくるPlatform Engineering — スピードと持続性を両立する文化の作り方
セッション概要
スタートアップ創業期は、プロダクト開発の速度を優先するあまり、基盤づくりや運用設計を後回しにしがちです。しかしその選択は、成長フェーズで大きな負債となって跳ね返ります。本セッションでは、「創業期から全員でPlatform Engineeringに取り組む」という一つの解を提示します。PdMやデザイナも巻き込みながら、理想から考える"引き算思考"で基盤を形にしていくアプローチや、独自のADR(Any Decision Record)活用など、少人数チームだからこそ可能なやり方を紹介。創業期における速度と持続性の両立について持ち帰れるヒントがあれば幸いです。
AI要約
プラットフォームエンジニアリングは、リソースに余裕のある大企業だけのものではありません。このセッションでは、創業2年目の企業が実践してきた「全員で取り組むプラットフォームエンジニアリ ング」の具体的な事例が紹介されています。
登壇者は、プラットフォームエンジニアリングを「ツールの提供」ではなく「開発者が本質的な作業に集中できるプロセスの構築」として再定義し、限られたリソースでも実現可能なアプローチを示します。引き算思考による意思決定の効率化、ADR(Any Decision Record)を活用した知見の資産化、そして「困った時の巻物」と呼ばれる課題解決の仕組みなど、チーム全体で持続可能な開発環境を作り上げてきた実践が語られます。
特に印象的なのは、PDM・デザイナーを含む全員が参加する週次の課題解決時間や、AIを活用したドキュメント文化の定着など、スタートアップならではの機動力を活かした取り組みです。複数領域にまたがるプロダクトを展開 しながら、いかにして開発生産性を維持してきたのか。その具体的なプロセスと文化作りのヒントが詰まった一本となっています。
文字起こし
はいこんにちはよろしくお願いします
よろしくお願いします
ありがとうございます
ちょうどね3時のおやつの時間ということで
眠くなる時間かなと思うので
ゆるく聞いてもらえればよいかなと思っております
皆さんクレープ食べましたか
めっちゃ美味しかったのでぜひ行ってみてください
ついでに通り道にうちのブースがあるんでね
寄っていて話を聞いていってもらえると嬉しいかなと思ってます
本日はスタートアップこそ全員でプラットフォームエンジニアリングやってみたらいいんじゃないかなというテーマでお話をさせていただきます
ドレスコード株式会社というところでエンジニアをやっている津田と申します
はじめに軽く自己紹介させてください
まず経歴なんですけれどもざっくり大きい会社とスタートアップを行ったり来たりして
今ここに立っているという状況でございます
過去共通基盤触ってたりCICDの面倒見たり
あるいはSREとかSETみたいな非機能要件系を中心に見ていたというところもあってですね
今の業務をもっぱらワークフローだったりの共通基盤をメインに見ていたりとか
あるいはプロダクトセキュリティとかCICDといった非機能要件系を中心に見ております
上のブースでも販売されてたんですけども
チームトポロジーでいうところのストリームアラインドというよりは
プラットフォームチームとして動くことが多いのかなというふうに感じております
技術的な興味でいうとですね
最近はイベントソーシング推しでですね
割と業務でも採用することが多くなってきたかなというところでございます
趣味ってほどでもないんですけれども
去年子供が生まれてからというものですね
過処分時間のほとんどは子供に費やしているというような状況ですね
まさに嫌々気真っ只中でこの3連休ですね
ほとんど大多まま過ごしていたので
未だに左腕筋肉痛が治らないという感じで登壇しております
本題に入る前にちょっと会社の紹介をさせてください
我々ドレスコード株式会社と言うんですけれども
これアンケートに協力いただきたいんですけど
弊社のこと知ってるよっていう方ってどれぐらいいらっしゃいますか
もしよければ教師いただければ
思ったよりいますね
ありがとうございます
とはいえほとんど知らないかなというところで
名前だけでも覚えて帰ってもらえると良いのかなと思っております
我々ドレスコードという会社はですね
ちょうど去年に設立してですね
だいたい半年前に成立する正式な創業を迎えた
まだ2年目に達成した日約校の会社でございます
一応数字で示しているんですけども
資金到達を実施していたりとか
すでに100社を超えるお客様がついていたりとか
非常に一定期待をいただけておる会社なのかなというふうに思っております
メンバーもこの時点でですね
22名おりまして
PDMデザイナー含めて約半分以上が開発に携わると
そういうような組織で今動いてます
非常にユニークなメンバーばっかりですね
楽しい環境かなと思うので
興味がある方がいたらぜひお話をしましょうというところです
弊社がどういうことをやっているのかという話なんですけれども
キーワードとしてはコンパウンド戦略というのを採用してますという話と
ワークフォース領域から事業を展開していきますという2つのキーワードでやっています
ざっくり言うとですね
最初から複数領域にまたがるプロダクトを
1つのプロダクトのように作りますというのが1点目
2点目はその中でもワークフォース領域
つまり人が入社してから退社するまでの一連の流れをサポートするところから
作っていますという話でございます
プロダクトが解決しようとしている課題の領域なんですけれども
我々は業務上の摩擦問題と呼んでるんですけれども
そういうバックオフィスの抱える問題っていうのを解消すべく
日々我々は開発をしているというところでございます
面白いことに我々は日本だけじゃなくて
主に東南アジアを中心として海外での事業展開もすでに行っております
視野に入れるというよりはもうすでに挑戦が始まっているという点で
非常にユニークなんじゃないかなと思っています
インドネシアとかタイベトナムあたりから事業展開始めておりまして
実際に顧客も数十社海外だけでついているような
そういう状況でございます
プロダクトのコードには実際インドネシア語とかベトナム語といった
翻訳のファイルっていうのがすでに転がっているような状況でございまして
そんな中で開発をしているという感じでございます
先ほどワークフォース領域で摩擦問題の解消っていうのを目指しているというふうに述べたんですけれども
要は使っているツールが別だと都度連携をしなきゃいけなくて
部門間で業務が分断されちゃうよねみたいな
なのでそれをまるっと解消するようなそういうプロダクトを作っていこうかなというふうに思っています
部門間の摩擦をなくすために我々が提供しようとしている領域プロダクト群
ざっとこんぐらい見えてます
すでに解像度高く物事見えておりまして
この中から優先度をつけて開発を日々し続けているという状況でございます
コンパウンドたらしめる領域プラットフォームケイパビリティと我々が呼んでるんですけれども
今日話すプラットフォームエンジニアリングとはあんまり関係がなくてですね
私もこのプラットフォームケイパビリティのところで中心に開発をしているというような感じでございます
本日サブタイトルにスピードと持続性の両立というふうに書いてあるんですけれども
実際我々のプロダクト開発のスピード感を示すために
この見えてる中でリリースしたプロダクト群ハイライトしてみると
こんな感じになってます
上司数の領域をカバーするITフォースを中心に機能を強化しておりまして
そこに連動する形で人事ローム領域をカバーするHRフォースも
対応する業務を広げていっているという状況でございます
また直近ではですねGAフォース総務領域のプロダクトなんですけれども
そこにも手を入れておりまして
これ特に私が個人的に非常に面白いなと思ってるんですけど
車両管理ですね
これ海外で引き合いが強いらしいんですけども
車両だけじゃなくて船舶とか航空機も含めて管理するようなプロダクトっていうのが
一定出来上がってきているというのが非常にユニークかなと思っております
ここにはないんですけど
もう一つの領域
LIフォースというものがありまして
そこの4領域含めて大体20プロダクトのリリースがすでに完了しているというような状況でございます
ということで会社紹介お付き合いいただきましてありがとうございました
改めてスタートアップこと全員でプラットフォームエンジニアリングやっていきましょうという話をさせてください
そもそもなんですけど
プラットフォームエンジニアリングってスタートアップに必要なんですかねっていうところから
考えてみようかなと思ってます
ぶっちゃけ自分も最初はこのプラットフォームエンジニアリングって聞いたときに
リソースに余裕のある会社とか大企業メガベンチャーみたいなのがやる取り組みだよねという気持ちは正直ありましたよと
開発者が抱える課題を解消するツールを提供する
そういう取り組みだよねというふうに捉えてました
もしかしたらそういう方少なくないんじゃないかなというふうに感じております
これ架空のスタートアップの特徴ですね
架空なんですけれど架空で妄想なんですけど
リソースは常に逼迫してるかあるいはむしろ不足してるんだろうなとか
あるいは走りながら考えていてどんどん市場にチャレンジしていくんだろうなとか
あるいはドキュメント整えるよりもとにかく前へ進んでいくんだろうなとか
POC用途で実装したものがそのままプロダクション環境で使われてしまうんだろうなとか
そういう妄想ができそうだなと思ってます
内々尽くしなんで削ぎ落として目の前の課題を解消していきましょうと
そういうふうな進め方をしてるんじゃないかなと思ってます
これが引き起こすことが何かというとですね
これも妄想なんですけれども
リソースが逼迫してるんでインフラはコンソールからとりあえず手で作っちゃおうとか
あるいはシェルスクリプトで構築した環境をそのまま使っちゃおうとか
それによって引き継ぎだったり保守に苦労しそうだなとか
あるいはドキュメントがなかったりPOCで作ってしまったものがそのまま動き出した結果
なんでそういう構成なんだっけとかどういう意図なんだっけみたいな
そういうのが失われていってしまうんだろうなとか
あるいはできる人ほどたくさんアウトプットをしてしまうがゆえに
その人しかわからないことが増えてしまって
その人が疲弊しちゃいそうだなとか
なんかそういう妄想っていうのができるかなと思ってます
そういう妄想してるとプラットフォームエンジニアリングって
スタートアップで可能なんでしたっけってなっちゃいそうだなと思ってます
実際ツールの提供っていう風に捉えちゃうと難しいのかなという風に思っております
実際私もこの会社で趣味と称してですね
空いてる時間使っていわゆるプラットフォームアザプロダクトみたいなものを作ろうとしたんですね
AIの時代なんでV0とかクロードコードとかを活用して
コントロールプレーンみたいなものを作ってみたんですけれども
やってるうちにこれメンテナンスとか運用誰がやんだろうとか
コストどうするとかセキュリティどうなってんだっけみたいな
なんかそういうところを思い始めちゃって結局途中でやめちゃってるんですね
そういう感じでスタートアップで最初からツールを提供するのは難しいのかなと思ってます
そもそもプラットフォームエンジニアリングの定義ってどうなってるんでしたっけっていうところを見てみると
CNCFの用語集においてはこういうふうに書かれてますよっていうのを引用してみてます
要点をつまむとですね
開発者を支援するツールとプロセスを構築する技術っていうのと
それによって開発者が行動を書くという本質にフォーカスをすると書かれてるんですね
注目すべきは解決する課題って何っていうと
開発者が行動を書く時間を増やそうっていうところですね
そのためにツールとプロセスを用いるっていうことですね
なんで開発者が本質的な作業に集中できるようにチームが抱える課題を解決するプロセス
これにフォーカスをするとスタートアップでも十分プラットフォームエンジニアリングできそうじゃないかなというふうに思っております
我々も今回スポンサードするにあたってこういうのを学んだ結果
我々の取り組みって振り返ってみるとプラットフォームエンジニアリングの一部だったんだなと
そういうふうに思ってですねこのテーマでお話をさせていただこうと思った次第でございます
今回は3つ我々2年目迎えたスタートアップが1年間取り組んできた
開発に集中するために行った仕掛け
課題をためない仕掛けみたいなものについてお話をさせていただきます
ざっくり概要をお話しするとですね
理想から逆算した引き算指向これによって選択と集中をして
意思決定を効率化したよというのが1点目でございます
2点目がですねADRを活用してドキュメント化を進めますと
意思決定を資産として再活用できるようにしましたというものになってます
3点目が困った時の巻物というものを用意して課題を蓄積してチーム全体で問題解決を図るように文化を作りましたというこの3点でございます
1つ目の事例なんですけども引き算指向によって意思決定を効率化したよという話なんですけれども
弊社は後発で動き始めた若い会社ですと
つまりラストムーバーアドバンテージとして先行事例から非常に学びやすい状況にあるというふうに言えるのかなと思ってます
かつちょうどAIが本格的に実用に耐え始めたそういうタイミングで創業を行っているので
この2つの恩恵を大きく受けることができるのそういう状況で動き始められたというのが1個ありますと
様々な領域で知見が蓄積されていてかつその知見をAIの支援を受けて効率的に吸収できる
この2つの掛け合わせによって理想を見据えながら今必要なもののみにフォーカスをしてて
車輪の再発明を避けたり落とし穴とかアンチパターンみたいなものを回避するように動けたのかなと思ってます
さらに臨読会定期的に開催しています
ベストプラクティスの発掘をチーム全体として行ってます
臨読する対象本に限らず前の記事とか聞いたの記事とか広く臨読対象を選定しつつ
みんなが感想議論を書き溜めていって個々人の経験に基づく実践地みたいなものと
収集した知見を融合することができてきたのかなと思ってます
これらをノートブックエレモンを活用して特定の話題について解説をする動画記事を集めていって
得られた知見をまた臨読をして議論して
ベストプラクティスやアンチパターンの収集っていうのを行うように取り組んできておりました
臨読会は実際こんな感じでフォーマットを用意して
個々人の感想とか経験こんなことあったよみたいなことを書き溜めていって
読み終わった後に議論をしてその議論の結果を残すようにしています
これが半年で大体40回ぐらい開催できているので
非常にワークしてるのかなというふうに感じております
この意識的に引き算思考をすることによって得られた効果が
ここに書いてある通りかなと思ってます
引き算思考によってアンチパターンある程度回避できてきたんじゃないかなと思っています
ベストプラクティスとか巨人の肩に乗るみたいなことを言いますけども
できてきてるんじゃないかなというふうに感じております
初期からインフラはコード化されていて
そのコードもディレクトリー戦略的に構造化されていたし
CICDきちんと整っていたし
オブザーバビリティも初期リリースとほぼ同時に導入できていたし
プロダクトセキュリティにもある程度時間コスト割いて
対応することができていると
100点とは言えないまでも7割8割ぐらいは
取れてきてるんじゃないかなというふうに
個人的には感じておるところでございます
後で話をするんですけども
このADRもかなり初期から導入できておりまして
実装初期の意図っていうのが
今でも参照できるような形で残っていますと
これらによって時間がない中でも
最短で駆け抜けつつ
持続性を犠牲にしない仕掛けができてきたのかなというふうに思っております
2点目はADRで意思決定をきちんと資産にしようという話でございます
ADR一般的にはアーキテクチャーディシジョンレコードですけども
我々にとってのADRはアーキテクチャーに限らず
エニーディシジョンレコードということで
何でも文書化しようというそういう文化でやっております
ADR自体の必要性とかADR自体っていうのは
既に浸透してきてるのかなと思っているので
割愛するんですけれども
ざっくり言うとアーキテクチャーに関する決定を
背景などとともにドキュメントに残そうという取り組みですよね
特に進化の早いスタートアップだと
朝礼母会当たり前みたいな
実装自体を動くドキュメントとして捉えたとしても
実装の意図までは汲み取りづらいんじゃないかなというところで
ADRが非常にワークするというものと理解をしております
我々もこのADR引き算的に考えていて
早い段階で取り入れて意図をまとめるようにしておりました
ただこれアーキテクチャーに限ってしまうと
デザイナーPDMが手を出しづらい領域になってくる
っていうのがあるのと
あとは形式的すぎると書くためのハードルが高くなっていったりとか
レビューなどの運用の負荷が高すぎてしまうかなという問題も
あるかなと思っています
なので我々はチームのコンテキストとして
共有した方が良さそうな決定事項
全ての決定事項を文書として
一箇所に集約する形式っていうのを取りました
これによって逆に雑多に書けるようになったんで
書くためのハードルが下がったのと
あとはまたLLMがちょうど進化していく時期だったっていうのもあって
それらを活用して読み書きのハードルっていうのを
ガサッと下げられるようになりましたというところでございます
あとはここに書いてないんですけども
書いて当たり前だよねみたいな空気を醸成するということで
文化として定着してきているなというところも感じておるところでございます
実際のイメージなんですけれども
こんな感じでNotionに全部集約するような形を取っています
フォーマットも一応あるんですけども
特に縛らず自由に書きたい人が書きたいように書くという形式を取っています
誰かがADRを書くとスラックに通知が来て
それを読めるようになっているし
ADRにした方が良さそうだよねこれみたいな取り組みがあれば
スタンプを押してチャンネルに飛んでくるので
それを見て書くというような運用が一定程度できているのかなと思っています
これによって得られた効果はここもザザッと書いています
特に大きいかなと思っているのは
オンボーディング時にコンテキストを共有する
あるいは保管するためのツールができたというのが
非常に大きいかなというふうに感じています
新規参画者の方は大きくメンタルモデルにギャップがある状態かなと思っているので
とにかく情報を集めるための手段として
Notionに集約してNotion AIを活用して
作成したADRから知見を得られるようになったというのが
非常に大きかったんじゃないかなと思っています
あとは私もそうなんですけども
人に聞くよりも自分で問題解決をしたいタイプにとっては
とりあえずここ見ればいいかなという場所が整っているというのが
非常に安心できるというところも大きいかなと思っています
人の時間を奪わないという点もそうなんですけれども
返事を待たなくていいというのが特にありがたいかなと思っています
我々コンパウンド戦略採用しているので
割と自分のチーム以外のことも知っておきたいんですよね
プロダクト同士が連動し合うような作り方をしているので
自チームだけに閉じてしまうとうまく回らなくなる可能性が少しだけあると
なので緩やかに知ることができると
そういう意味でもADRを読むというのは効果を発揮できているんじゃないかなと思っています
これは文化として育ってきた証かなとも思うんですけども
空気ができていてそれをADRにしようぜという提案を多所からしやすいし
それを受け取りやすいと
そこにADRを書く時間を割くというのがチームから許容されているよね
っていう空気感ができているっていうのも大きいかなと思っています
ということで2つ目
Any Decision Recordによって意思決定の試算化をしましたと
それによってプラットフォームエンジニアリング実現できているんじゃないかな
という話をさせていただきました
Any Decision Recordについては
弊社の河村が別の場で発表した資料があるので
こちらもぜひご一読いただければなと思っています
3点目なんですけども
PDMデザイナーも巻き込んで
困った時の巻物と呼ばれるものを作って運用していますという話でございます
ざっくりプロダクトチーム一丸となって
課題を解決する時間を確保しているよという話かなと思っています
参加者はPDMデザイナー開発者が
任意の困りごとを書き溜める場所を作っていてですね
誰でも困りごとや議論したいものがあったら
放り込めるような状態にしています
これを毎週1時間ほど確保して
ため込まれた困りごとっていうのをみんなで解決するという
そういう時間をとっております
これによっていわゆるみんな薄々気づいてるけど放置していて
後々大きい課題になるみたいなところの問題を
ため込まないようにできているのかなと思っています
あとは困りごとに限らず理想について議論することで
同じ方向を向いて仕事ができるようになっているのかなと思っています
もちろん議論するだけじゃなくて
ネクストアクションまでしっかり洗い出して
この場で進捗を確認して解決までサポートできるように
という仕掛けをしております
こちらもノーションに蓄積をしています
すっごい小さい話で言うとAIが書いた文章をコピペするときに
どうするんだっけみたいな個別具体的な小さい相談とかから
ビューテーブルどうやってやっていこうかねみたいな戦略レベルの話
理想を議論するようなものまでこの場でこの時間で全員が認知して
取り組めるようにしているというところでございます
得られた効果としてはですねみんなが課題を認識できる場がある
というのが非常に大きいんじゃないかなと思っています
大なり小なり課題があることを捉えられた時点で議論に挙げられる
さらにそれを解決まで持っていけるという場があるというのが
心理的な安心感にもつながっていますし
非常に開発生産性を下げない仕組みとして機能しているのかなと思っています
これも引き算思考とつながっちゃうんですけど
課題の傾向をつかんだ時点でみんなで手を打ち始められるので
遠回りせずにあるいは先回りして課題を解消できるんじゃないかなというのがあります
一例なんですけども例えばエンタープライズレベルの案件の受注が見えてくるとですね
パフォーマンスセキュリティといった非機能要件
より一層力を注げないとねという会話ができるようになっています
ということでまとめですね
おそらく遠からず皆様も実践されていることかなというふうには思っているんですけども
設立2年目を迎えたスタートアップにおけるプラットフォームエンジニアリングの実例として
3つほど紹介させていただきました
ツールの提供という観点で見ると我々はまだ何もなせてないんですけれども
プロセスを整えて本来の目的である開発者の生産性を下げないようにするという点で
3点ほど紹介させていただいたところでございます
改めてなんですけれども特にスタートアップにおいてはですね
ベストプラクティス事例などから引き算的に考えていくことができるし大事かなと思っています
またAIをどんどん活用して失われがちな意図を資産として残していくというのは
特にスタートアップ人の入れ替わりが激しかったりするのかなと思っているんですけども
レバレッジが効かせられるのかなと思っています
最後にスタートアップしかできないこととして
全員がチームの課題に一丸となって取り組む時間を割くというのも
課題を肥大化させないという点には非常に効果が大きいかなと思っています
ということでスタートアップこそ全員でプラットフォームエンジニアリングを
意識的に取り組んでみましょうというお話をさせていただきました
ご清聴ありがとうございました
我々も世に残せるものは積極的に残すべく技術ブログなんかもやっているので
よろしければフォローしてください
事業取り組みが面白そうだなと思っていただけた方がいたら
出たところにブースがあるのでぜひお話をしましょうというところで
私の発表を終わらせていただきます
ありがとうございました
非常に興味深い講演ありがとうございました
それではこれよりQ&Aセッションに移ります
こちらのQRコードから質問がある方はぜひ入力をお願いします
皆さん今多分入力しているところだと思うので
一点私の方から少し気になったことを質問させていただきます
ADRを書くハードルを下げたということで
素晴らしい文化作りだなと思ったんですが
逆にそのフォーマットを完全になくしたことによって
ドキュメントは見つかるけど書いてほしい情報は書いてなかったという事例があったのか
それともそれを防ぐ対策とかがあるのかぜひ教えていただきたいです
ありがとうございます
一応ADRを書いてある読む時間っていうのを一定程度確保するタイミングがあって
そのタイミングでこの情報欲しいんだよねっていうレビューみたいなことはできるようになっていますし
運用に乗っているかというとちょっと怪しいんですけれども
個人で読んだ時にこれどういうことっていうのを気になってコメントをするっていうのは
できているのかなというふうに思っています
ありがとうございます
それではスライドの方に質問が届いております
デリバーへの到着をレシーバーでは考慮しない作りですか
レシーバー側サービスがデリバー側の状態を見るユースをどう解決しているか知りたいですという質問ですがいかがでしょうか
何に対する質問かちょっと分からなくてこれどうしようかな
何を回答すればいいんだろう
デリバーレシーバーちょっと初耳ですかね
そうですね私の方でもセッションのどこに回答するかが
あまり想像ついていないですがスキップされますか
そうですねちょっと回答できなさそうだなと思うのですいませんかスキップさせてください
では次の質問に参ります
ADR化の実施有無による生産性の効果は定量的に測定できていますかという質問です
定量的には測定できていなくてっていうのも開発した初期からADRを書くような文化が定着
文化というか書くようにはしていたので無の状態をまだ観測してないんですね
そういう意味でいうと有無の効果っていうのは測定できていない
定量的に測定する仕掛けっていうのもまだ全然用意はできていない状態でございます
はいありがとうございます
続々と質問届いておりますので次の質問に
ADRはノーションに集約されているとのことですがコーディング用のAIエージェントがそのコンテキストを読み取るための工夫は何かされていますか
ありがとうございます
今まさしくこれ結構取り組んでいるところでですね
ちょうどノーションのMCPサーバーを導入してカーソルから読み込めないかなっていうのを実験しているところでございます
なので今はしてないんですけれどもこの後ノーションに蓄積しているデータベースから取ってこれるようにするというところがあるかなと思っています
ありがとうございます
続いての質問です
今振り返ってみて特にこれは避けられてよかったというアーキテクチャ上のアンチパターンはありましたか
難しいですねなんかあったかな
割とベストプラクティスに乗って作るっていうようなやり方をしてたので
明確にアーキテクチャで言った時のアンチパターンみたいなのを踏んでないなっていうのはあって
踏んでない避けてはいるんですけどなんかあるかな
アンチパターンっていうのか分かんないんですけども
REST APIで動く本体の部分とあとイベント駆動で動く部分っていうのを今分離していて
これは非常に個人的には良かったのかなと思っていますと
イベント駆動で動く部分のコード自体がすごく独立して実装できるようになっているので
これがREST APIの本体の部分から影響を受けないっていう意味では非常に良かったのかなというふうに感じているところでございます
はいありがとうございます
続いての質問です
巻物などで上がった非機能要件に取り込む時間はどのように確保していますかという質問です
ありがとうございます
意識的に時間を確保しているという感じではなくてですね
それぞれのプロフェッショナリティに任せているというとすごくブラックシューがするんですけど
そういう感じでやっています
ありがとうございます
次の質問に参ります
ガンガン開発しなきゃという雰囲気の中でプロセスに意識を向けられているというのは
メンバーそれぞれがもともとそういった考え方をしていたのかなと思いますが
誰かが巻き込んでいった側面などありましたか
あればどのようにやっていたのかを知りたいです
そうですね
割と最初の方からこういう困った時の巻物が用意されていたりとか
ADLを書くみたいな感じで
自発的に出てきた感じがすごくしていて
回す人は固定でいたりはするんですけれども
全員がそれなりにプロセスに目を向けるというか
こういう時間って大事だよねみたいな
共通認識があったのかなというふうに考えています
ありがとうございます
次の質問は
今後どのタイミングでツールによる共通化を考えるか
今の段階でイメージありますかという質問です
そうですね
そろそろツールが欲しくなってくるんじゃないかなという感覚があって
年明けぐらいには多分コントロールプレーンみたいなものを用意しないと
おそらくテナントを管理するっていう面で
開発者の手を引っ張るようなことが起こるんじゃないかなというふうに予測をしております
ありがとうございます
では今出ている質問で最後の2つとしたいと思います
非機能要件に対する取り組みに投資するのはスタートアップ企業としては難しい面もあると思いますが
投資する意思決定をする上でボトルネックとなるものなどはありましたか
一番ボトルネックっていうとすごく角が立つんですけど
経営層と会話をするっていうのが結構難しいところかなと思ってます
経営層にお金を出してもらうため
お金あるいは工数を出してもらうための説得コストみたいなやつは
一定程度かかってきたんじゃないかなというふうに感じてます
はいありがとうございます
最後は面白い質問です
臨読会で一番盛り上がったトピックスを教えていただきたいです
ありがとうございます
結構いろいろ読んできたんですけど
チームトポロジーの本をみんなで読むっていうのは
結構いろんな意見が出てきたかなと感じてました
ノートブックLMにいろんな記事
いろんな人の読んでみた記事とかまとめてみたりとか
海外の記事とかまとめたりとかしながら読んでいったんですけども
非常にいろんな意見が出ていたような記憶があります
はいありがとうございます
それでは残りのお時間も少なくなってまいりましたので
以上でセッションの方を終了したいと思います
皆様改めて盛大な拍手をお願いいたします
拍手