00:04
8月25日木曜日、時刻は朝9時を回りました。
本日はですね、きのう京都だったんですけど、
今日は新大阪のホテルに泊まっております。
はい、で、今日はですね、
おはようございます。
では本日の朝活を始めていきたいと思います。
で、今日はタイトルのある通りですけど、
ちょっと今までと趣向を変えまして、
カミナシ社という会社があって、そこの執行役員になられた
トリさんという方ですかね、
の記事があってですね、
僕の知り合いというか、別のイベントで
お会いさせていただいた方が、
その人事とか、いわゆる人事ニアの方ですね。
人事ニアなんだけど、
人事の方に転校された方がいらっしゃって、
その方がちょっと前に転職をされたんですね。
で、その転職をしたんですけど、
転職先がカミナシ社だったんですよね。
僕全然名前も存じ上げてなくてですね、
その方が転職して初めて知ったんですけど、
ちょっと注目してたっていうのもあって、
カミナシ社のノードブログが出てたので、
やっぱり読みたいなと思って、
今日はそこで読んでいこうと思っておりました。
もし時間が余ったら、別の記事ですね、
シッピングトゥープロダクションという記事があるので、
KさんとSpiceさんという方とTakuanさんですね。
おはようございます。
ご参加いただきありがとうございます。
ちょっとタイトルある記事をダラダラと読んでいく感じで、
今日はほぼほぼ多分テクノロジー的な話じゃなくて、
割とポエムだったり抽象的な話だったり、
本当は会社経営の話のノードブログだと思うので、
その辺を読んでいきたいなと思っています。
では行きましょう。
雷社に入社してから早いもので3ヶ月プラスアルファが経ちましたが、
さすがのアーリーステージなスタートアップという感じです。
前職では想像しなかったようなスピード感で、
激動イベントがポコポコ発生し、
つい先日書いた入社エントリーがすでに届いたこのように感じます。
この記事自体は2022年、
今年の7月1日ですね。
ほぼ2ヶ月前という感じです。
というわけで本日、2022年7月1日付で、
雷の執行役員CTOに就任しました。
本記事では改めて雷という会社やサービス、
それらを支えるエンジニアリング組織の会社ともに就任を立てての
今後への思いをしたためようと思います。
1つ目は、セクション1としてまずCTO就任の経緯です。
これまで公約にしていなかったのですが、
もともと雷からの入社オファーは
CTO候補というタイトルをもらっていました。
僕はこれまでCTOという役割を経験したことがないため、
働いてみて、僕も会社もお互いに期待に応えられそうだったら
CTOに就任することにしましょうという流れのイメージです。
今日まで明言できていなかったのは
CTO候補として入社します、なんて書いておいて、
実際には僕の力不足でCTO就任とはなりませんでした。
03:00
なんてことになったら、あまりにも骨髪化しすぎるからなのですが、
最終的に無事、
CEO&COOの両名からも認めてもらい、
僕ももっと紙無しの成功にコミットしていきたいと思いから
この度就任と会員になりました。
続いて、紙無しというサービスです。
まずは私たち紙無しが提供するサービスについて
簡単に紹介します。
社名と同名、サースである紙無し
紙無しというか、今更ですけど
アクセントは紙無しなのか紙無しなのかわからないので
前者でとりあえず今日は行きます。
紙無し社が2020年6月にリリースし、
その後PMFの実感とシリーズA調達を
社にもたらしたA to Bプロダクトになります。
日常業務の中心がコンピューターではない、
現場仕事に携わるかノンデスクワーカーたちが
自らの手で現場のデジタル化を
進めていくためのサービスで、
現場による現場のためのDXを支えるサースとも言えます。
現時点で最も導入実績が多い
食品製造をはじめとしたホテルや小売、
飲食、運輸など、日本中のあらゆる現場において
紙による非効率的な業務を現場主導で
デジタル化していることに講義しています。
そんな紙無しは前提のスクリーンショットの通り
IOSネイティブアプリケーションと
ブラウザベースのSPAクライアントも提供していて
それぞれタイプスクリプトとかリアクト
もしくはリアクトネイティブといった技術を
使って作られています。
デザインもいかにも業務アプリなんですけど
わりとモダンな感じのデザインになっていて
こんなダッシュボードだと使いたいかなと思うかもしれないですね。
またサーバーサイドのRESTful APIや
Batch処理はGoで書かれており
それらはAWS FargateやAWS Auroraといったコンポーネントを
利用する形でAWSクラウド上に展開しています。
一応記事内にも
AWSのインフラ構成図
アーキテクチャ図がキャプチャとして
貼られているのでもし興味がある方は見てみてください。
そんな雷を支えるシステムですが
ありがたいことは2021年からここに至るまでの
1年強でユーザーが1日あたりに雷で生み出す記録データ
は当時の10倍を超える量にまで成長し
開発当初のシステム設計や実装がそごわないシーンが
出てきました。これある意味でいいですよね。
開発当初の僕らが開発側が描いていたものとか
実装というのが実際の現実にそごわないシーンが
出てきたってことはそれだけ使われたってこともあるし
規模が大きくなってきたりデータ量が増えてきたってことが
その証明になるのでこれはいい話ですね。
もちろん対応はしなきゃいけないしどんどん変更したり
システムを改良していかなきゃいけないんですけど
まずここに来たっていうのが1つの証明になりましたね。
成長しているっていう意味で。
とても素晴らしいなと感じます。
プロダクトを作り始めたとき僕はまだ雷には在籍してませんが
当時の雷社はピボット直後で
06:00
会社のラウエーが短かったっていうこともあり
ここまで大きな伸びを想定しきるための時間や心の余裕が
なかったであろうことは想像なかたくありません。
ピボット直後だったらそれは確かに僕も想像できないですね。
なのに10倍を超えるようになったっていうのは
本当に大変な動力が裏にたくさんあったと思うんですけど
それでもここまで伸びたっていうのはさすがの一言だなって感じです。
というわけでサービスとデジタル
ビジネスを今後も力強く継続的に成長させていけるよう
まずはここに真摯に向き合うことにしました。
で続いてサービスとビジネスを
今後も力強く成長させていくためにというところですね。
今年の年末、2022年12月末までに
中長期的な価値を犠牲にしなくとも
スプリントの6割を純粋な機能開発に当てられるチームになる
ということをゴールに
5月下旬から技術的な負債の返済を
プロジェクト化して取り組み始めました。
技術的負債とは何かについて
この記事で改めて論じることはしませんが
今回の記事というか、鳥井さんという方の
技術的負債というのは3つあって
1つ、設計や実装の当時に最適解と考えていたものが
2つ、時間の経過とともに最適ではなくなった結果
3つ、その最適と現状との間に生まれる差分である
というふうにご本人は考えられているということでしょう。
プロジェクトの第1弾は
5月下旬から6月末、まさにこの記事を書いている
今日ですね、4月1日ですね。
までの5週間でエンジニアリングの生産性や
直接的な価値につながっていなかった複雑なパッケージ行動であったり
行動の整理というのを続けました。
お客様の業務を止めてしまうクリティカルな不具合の修正や
問い合わせへの対応を除き、原則として全ての機能追加と
不具合修正に関する業務を停止して取り組みました。
これすごいですね。
なかなかスタートアップの中でこの意思決定をできるという
なかなか勇気がいることだと思いますね。
追加機能と不具合修正というのを
不具合修正を止めてまで取り組むというのは結構
ビジネス的には難しい判断で、本当はしたいんですよね。
やっぱり大きくなるとか規模感を大きくするためには
絶対にリファクタリングと設計見直しというのが
絶対に出てくるはずなんですよ。
お金を生んでいるし、すでにランニングしている
アプリとかシステムであるので、お客さんの対応が
出てくるという話なので、不具合を止めてまでやるというのは
結構勇気がいるんですよ。
ビジネス的にはかなり危険なアクションだと思うんですけど
その代わりこれができて、かつ乗り越えることができたら
飛躍することも視野に入ってくるので
本当これはすごいというか
なかなか経営判断として難しいことを
意思決定したなというふうには感じますね。
やっぱりスタートアップはあれですけど
とにかく作ってリリースをして
まずユーザーを獲得するところかというところから入るので
設計だったり構造だったり行動整理というのは
二の次でトゥーデルだったり
リフィックスミーみたいなコメントが並べられるんですけど
09:00
走り始めると手を加えるというのは結構勇気がいるので
そこに対して大きくなればなるほど
それがどんどん不採として詰め重なっていくので
今のうちに解決をするという意思決定をしたというのは
なかなか英断だなと思いますね。
ではちょっと戻ります。
本題からそれるので注釈扱いにしますが
本来技術的不採というのは継続的に返済されていくべきものです。
これも一緒ですね。僕も。
プロジェクト化しなければならないほどに不採をため込んでしまうことが
特にSaaSのような継続的進化を前提とする
ビジネスモデルを取る企業にとっては
これはエンジニアリングだけではなく
誰しもが共通認識として持つべきものです。
この考え方に理解をした上で僕を信じて
不採・返済のプロジェクト化を受け入れてくれた
上梨の経営人やビジネスチームには本当に感謝します。
本当にいい言葉だなと思いますね。
そんな6月末まで進めてきた返済プロジェクト
第1弾は非常に順調に完了し
その先の行動に手を入れていくハードルを
一気に下げられたという実感があります。
ここですよね。しっかり手を加えて設計とか見直しをしたので
次はスケールしたりとかブラッシュアップしたりとか
気の継いがするがどんどんハードルが下がるんですよね。
これが本当にデカいと思います。
後でかかる失うコストをいかに削れるかというところが
勝負なのでこれが素晴らしいなと思いました。
また既存メンバーだけではなく今後入社予定の
ソフトウェアエンジニアたちにとってもコードベースの
認知コストが下がることでこれまで以上に短い期間で
オンボーディングが完了できるという期待に胸が劣っています。
これも確かにありますね。
新しく入ったメンバーとかプロジェクトに参画するメンバーの
認知コストが下がってオンボーディングの期間が
短くなるという負荷価値もあるんですね。
これは考えてなかったな。
自社サービスとか自社プロダクトを僕は
過去に経験したことが一度もないので
この視点は確かにいいと思いました。
ただし現時点では重要な技術的不採用を全て
返済し切ったわけでもありません。
今後はスプリントの一部を通常業務に戻しつつも
優先順位が高い不採用を継続的に片付けいくための
時間を一定程度確保する形で2020年末までの計画となっています。
例えば現状の機能要件や使用が想定できなかった部分を
整えたりエンタープライズな顧客の増加によって
これまで以上に重要度が増してきた非機能要件に
力を入れたりあるいはインフラや運用に至るまで
行き切れせずに安定して継続的な機能開発していける
&運用改善や新たな技術的不採用の返済に
継続的に取り組んでいけるチームになることを
目指し力強く取り組んでいきます。
本当に素晴らしいしか言いようがない。
ちゃんとチームビルディングのところまで入れて
いろんなことを意思決定されているというのは
これだけで割とこのチームに入りたいと思う
エンジニア多いと思うんですよね。
このブログめちゃめちゃ素晴らしいな。
参考にさせていただきます。
12:01
続いて、雷が目指すエンジニアリング組織の形という
セクションに行きましょう。
次は少し話を変えて雷が目指していくエンジニアリング
組織の形について紹介します。
上級やサイズの異なる企業にとってはこれらが当てはまらない
もしくはもっといい形があるかもしれません。
全てはオーナーシップというところから入ります。
経験上、優れたサービスを作るチームには
そのサービスに対する強いオーナーシップが明確に存在します。
そのサービスを良くしていくのは自分たちなんだという
認識と自覚、責任感なしには
優れたサービスを作ることが難しいとも言えます。
余談ですが継続的な改善を前提としたプロダクトを
外注で作る難易度が高いと言われがちなのには
発注者と受託者の間でのオーナーシップの所在が
不明瞭になりやすいところにもその理由があると
僕は考えています。
まさにおっしゃる通りです。
意外と言語化されないことが多いです。
ではどのようにしてオーナーシップの所在を明確にし
かつそれが一時的なものではなく継続的な可能なものにするか
というところです。
開発チーム自身がシステムを運用するというところに
入ります。紙なしではシステム運用の責任は開発チームに
帰属するべきものであるというふうに定義をしています。
この定義はなかなか勇気が要りますね。
これができるからこそオーナーシップがちゃんと
全員に浸透するとなるので
なかなかこの定義は強いですね。
自社プロダクトというのは大きいかもしれないですね。
システム運用を開発チーム外に丸投げする体制
というのは採用しません。
これは僕のエンジニアリングにおける信念の一つでもありますが
開発者がコードを書いたら終わり、運用は誰かがやってくれるという
マインドセットでは変質の高いコードやサービスは生まれません。
あるいは生まれることもあるかもしれませんが
そんな超人が世の中にはたくさんいるわけではないと考えています。
これはちょっと耳の痛い
発言でした。私みたいに
クライアントワークの企業というのは
目の前にしているお客さんのシステムを作るので
今のコードを見て次のプロダクトは全然別のプロダクトで
また一から設計し直すというのがあるので
ついつい運用の視点に至らなかったり
運用の視点をそもそもさせてくれないというのがあるので
品質の高いコードやサービスが生まれませんというのは
一理あるなというのをちょっと僕は感じているので
とても手厳しいお子様だという感じがしました。
とはいっても意外とそういう意識は
生まれますけどね。ただ
サービスに対して品質の高さというところを目指すというのは
現実として我々クライアントワークの会社は
そもそもできないというのがやっぱり大きすぎるかなというのが
感じます。ただ一方で自社プロダクトをやっているような会社さんであれば
逆にこれがないというのは本当におっしゃる通り
これは完全同意なのでここは結構大事なことだなと思いました。
はい戻ります。続いて品質の高い
低いですね。品質の低いコードを書いたことで
自らがページングされるあるいはそのようなコードに起因して
15:00
困っているお客様と真摯に向き合うことで
初めて製品の品質に対してオーナーシップを持てるようになります。
加えて短い期間で組織と解散を
組織と解散を繰り返すような短期プロジェクト自体の
チーム体制もシステム運用に対するオーナーシップが
行方不明になりやすいことから現時点ではおそらく選択しないと
言えます。安定したシステム運用は
SaaSの重要な機能の一つであり社内以外に
関係なく誰かに投げていいものではありません。
続いてSRE、QA
プラットフォームの類を安易にチーム化しないというところですね。
これらの安易なチーム化によって
結果として開発者に
自分たちではない誰かがやってくれるという風に
考えさせてしまうような組織設定を取ることも
現在のカミナシにおいて必要なオーナーシップを損なわれかない
誤った選択だという風に考えています。システムデザイン
信頼性、品質、セキュリティ、インフラストラクチャ
そのどれもが本来開発者自身が
オーナーシップを発揮すべきこと柄です。
講義ではこのセクションの内容も前のセクションと同様の意図を
持っていると言えるでしょう。
カミナシとは状況やサイズ、優先順位が異なる組織においては
これらのチーム化が必要不可欠と言えるケースが
数多く存在するであることはもちろん理解しています。
また仮にチームがそれぞれ独立していたとしても
よく設計されたチーム化インタフェース、責任分解点によって
きちんとオーナーシップが維持された成熟した組織も
少なくはないというような実例を過去に見てきました。
ただし今のカミナシの状況においてはそのような分化された
チーム体制である強い必然がないこと
加えてオーナーシップを維持したままそれらを実現するのは
あまりにも高いコストであると考えていることから
思考停止のチーム化を避けようとしています。
これはカミナシにはSREという役割に定義される
ミッションそのものが不要であるとか
サービス特性や中長期の視点を無視して
インフラ管理が不要な外部サービスを使えばいいとか
そういったニュアンスではないです。
ここで伝えたいことは優れたサービスを提供するためには
これらの重要なファンクションが全て開発チームに内包され
外部チームに依存することなくサービス提供のために
自律的に動ける状態こそが理想であるということです。
これらは内包すべきファンクションを
開発チームの外に切り出してしまい
あっちのチームがやるはずという不の依存状態を作ってしまうと
デリバリー速度の低下を招くだけでなく
チーム間の不毛な責任押し付け合いにもつながりません。
そしてひとたび組織がこういう状態に陥ってしまうと
それをあるべき形とマインドセットに戻すのに多大なコストが
発生するというのは多くのソフトウェアエンジニアによく知るところかと思います。
ではこの辺りにスペシャリストを持つ人材を
単にチームに配置すれば十分かというと
それだけでも意味はありません。
仮にその時点でスペシャリティを持ち合わせていないチームメンバーであっても
将来的に自らもその領域において貢献できるよう
チーム内の互いの成長を促し組みというのがやはり必要です。
チーム内の外注というのも防ぎ
チーム全体のオーナー執行を高く維持することで
チームにファンクションを内包させる本当の価値が発揮される状態
18:02
というのをカミナシは目指しています。
続いてカミナシと
カミナシエンジニアリングの強み
最後に優れたプロダクトを作るためには
絶対に欠かすことのできないと僕が信じている
カミナシとカミナシエンジニアリングの強みを紹介してしまいます。
ユーザーの声に耳を傾ける
これは昨今のプロダクト開発においては当たり前のことに聞こえるかもしれません。
でも実のところその実践はとても難しいことです。
自分も含め我々ソフトウェアエンジニアは
問題解決の手段であるはずの
技術そのものに無意識のうちに傾倒しがちで
ともすればユーザーのことを置き去りにした
内向きなモチベーションで仕事に臨んでしまうことに
身に覚えがあるはずです。
カミナシには価値のある良いプロダクトを現場のユーザーに届けたい
という強い思いを持ったソフトエンジニアが数多くいます。
彼らはユーザーの現場に自らも向き
お客様のペインに直接耳を傾ける重要さを知っています。
カミナシ社員があるべき姿を言語化したバリューの一つである
現場ドリブンという言葉にまさにこの姿が投影されています。
実際現場ドリブンで今キャプチャーが貼ってあるんですけど
実際のお客さんの工場に行って
みんなちゃんとそういう服を着て
どういうところがペインなポイントなんですかというところを
ヒアリングしているキャプチャーが貼られているんですけど
本当にちゃんと現場に足を運ぶんですね。
これは素晴らしいことだと思います。
この1年で大幅にユーザーが増えたことで
全てのユーザーと会話をすることは当然ながら
物理的に難しくなってきました。
しかしプロダクトマネジメントやカスタマーサクセスといったチームとも協力しながら
常にユーザーペインのダイレクトな理解に努めることを
重視する姿勢というのは変わりません。
エンジニアリングやプロダクト組織に限らず
会社全体が自ら現場のペインを理解することの重要さを知り
掲げているというのは間違いなく
カミナシの財産であり強さの原石の一つです。
これをCTOが語るというのは
本当に熱くて僕はちょっと嬉しいなって感じました。
なんか僕のことじゃないんですけどね。
最後、余談の話に行きましょう。
個人的な話ですね。
ここからは僕個人のポエムです。
これまでの仕事の中で各社のCTO職に当たる方々と
会話をする機会は幸運なことにたくさんありました。
しかし自分自身がCTO職を務めるのは今回が初めてで
右も左もわからない中
様々な組織側に対して日々試作を巡らせ試行錯誤を繰り返しています。
僕はもともと仕事の結果や発生する出来事を
多席にするタイプではないと自認しているし
日頃からそれを気をつけているつもりなのではありますが
経営者となると本当に多席はできません。
するしないですね。ではなくできない。
なるほど、これが経営者の難しさや大変さ
そして面白さの一つの中と心がゾクゾクしています。
するしないじゃなくてできない。
仮に売上が伸びなくてもチャーンがついたとしても
なかなかエンジニアリングの生産性が変わらなかったとしても
21:02
人材採用がうまくいかなかったとしても
それはどれをとっても社内の誰かのせいではなく
経営の責任になります。
とはいえ僕は現時点では
CTOやマネジメントとしての経験が豊富ではありません。
カミナシに入社してからのたった数ヶ月の間に
何度も失敗しながら、学びながら、助けられながら
CTOとして成長し、それを通してカミナシやその先にいる
ユーザーに還元できるよう努力しています。
そして今から何年後なのかまだクリアな青写真は描けていませんが
いつかカミナシを日本で有数の
世界に誇れるテックカンパイにしたいという思いがあります。
そしてそこに立ちはだかるであろう
たくさんの未知の壁を乗り越えていくために
有数の仲間にカミナシに来てほしいと思っています。
長文を最後まで読んでいただきありがとうございました。
以上本ブログでした。
あとは一応F&Qがあって
それぞれについての質問がある回答しますけど
その辺はまた読んでいただければなと思います。
ずっと読むことを先のままにしていたんですけど
とても素晴らしいノートでしたね。
こんな文章は僕は書けないので
シャドーを感じました。
いわゆる羨ましいってことなんですけど
皆さんもどう感じられたでしょうか。
以上カミナシの志向役員の
CTOに就任しましたというブログでした。
カミナシ社の鳥さんという方ですね。
あとでこの記事のリンクも
Twitterで流しますのでもし興味があれば見てみてください。
といって昨日この記事を見ましたっていう
記事のリンクを送ってない気がすごくしたので
大変申し訳ないです。
この後絶対に流します。
残り時間あと5分なんですけど
どうしようかな。終わってもいいし
次としては最高なんですけど
次読もうかなと思っている記事が決まっていて
シッピング・デプロダクションという本番への
リリースというかデプロイというか
日本語にすると違和感しかないので
結構長いのでここから何日かに渡って読もうと思っています。
多分そういうCICDとか
デプロイ周りのところの話だと思うんですけど
その辺を話すってことはいわゆるチームとか
開発以外の話が絶対入ってくるので
割と学びになるんじゃないかと思いながら
ざっくりと適当に選んだやつなんですね。
これ読もうかどうしようかなんですけど
来ていただいているのでせっかく入っていこうと思います。
多分冒頭部分でもしかしたら終わっちゃうかもしれないですけど
では行きたいかなと思います。
シッピング・デプロダクションですね。
翻訳が遅いですね。
本番環境への出荷
やっぱり日本語違和感あるな。
高速かつ信頼性の高い方法で行動本番環境に
シッピング・出荷する方法というのは
エンジニアやエンジニアリーダーが教育すべき課題になります。
24:02
迅速かつ頻繁な出荷と優れた品質の
両立が可能なチームや企業というのは
どちらの制約にも苦しむ競合他社に対して大きな優位性を持ちます。
この記事では以下を取り上げています。
1つ目、出荷から生産までの量極端なプロセス
2つ目、様々なタイプの企業における
典型的なプロセス
3つ目、責任をもって生産・出荷するための原則とツール
4つ目、追加の検証レイヤーと高度なツール
5つ目、より早く進めるために
現実的なリスクを犯すこと
5つ目はちょっと危険なタイトルだと思いますけど
分からなくないという感じです。
この記事の拡張版というのは
The Programmatic Engineer Newsletterに掲載されたものになります。
この記事もちゃんとリンクがあるので
興味ある方は後で記事から追ってみてください。
まだ購読されていない方はこちらから無料でご登録ください。
サブスクライブナウというボタンが配置されていました。
今のが冒頭だったので
結構短かったですね。
じゃあ早速
1個目のところに入っていきたいと思います。
ただ1個目がすでにいくつかの項目に分割されているので
中途半端になる気はしますが
いけるだけいってみましょうかね。
1つ目
The Extreme of Shipping to Production
本番関係の出荷の両極端
コードを出荷する場合
コードがユーザーに届くまでの道のりの両極端を理解するのが良いでしょう。
下の表は徹底的な方法と
YOLOというような方法書を示しています。
さすがにこの記事の
キャプチャーというのを
音読すると説明が長くなるので割愛します。
僕しか見ていないんですけど。
YOLO出荷というのがあって
YOLOというのはYou Only Live Onceの略だそうです。
この頭文字を取っています。
これは多くのプロトタイプやサイドプロジェクト
もしくはα版やβ版のような不安定な製品に
採用されている手法です。
場合によっては緊急の変更や
変更を本番に反映される方法としても使われます。
Hotfixの反映にも使われる方法っぽいですね。
アイディアは簡単で本番環境で変更を行い
それがうまくいくかどうかを確認します。
本番環境で変更を行いますね。
YOLO出荷の例としては以下のようなものがあります。
本番サーバーにSSH接続をして
ファイルに変更を加えてファイルを保存してサーバーを再起動すると
変更がうまくいったかどうかを確認するみたいな方法とか
もしくはソースコードに変更を加えて
コードレビューなしで変更を強制適用して
サービスの新しいデプロイメントをプッシュするとか
というような方法ですね。
27:00
もしくは本番データベースにログオンして
データの問題を修正する本番クエリを実行
例として問題のあるレコードを修正するとかですね。
問題が修正されたことを期待すると。
割と危険すぎますね。
今提示した3つの方法全部危険だなと思いました。
YOLO出荷とは本番環境への変更を
出荷するという点では非常に早い方法です。
しかしこのタイプの出荷にはセーフティーネットがないため
生産ラインに新たな問題を持ち込む可能性が最も高くなります。
実稼働ユーザーがほとんどいない製品では
実稼働環境にバグを持ち込むことによって
ダメージは小さくアプローチは正当化はされます。
YOLOリリースはよくあることです。
サイドプロジェクトだったりその顧客のいない
初期段階のスタートアップ企業だったり
エンジニアの質が低い半中堅企業だったり
インシデントの処理方法が確立されていない場所で
緊急のインシデントを解決する場合です。
ソフトウェア製品が成長しより多くの顧客が
それに依存するようになると
特別な検証を受ける必要があります。
もう一つの極端な例としてバグをゼロに近づけることに
執着しているチームがあるとします。
QAチームみたいなところです。
最初のアプローチでしたのはYOLOシッピングでした。
You Only Live Once
というところです。
今ので一つ目でした。
二つ目があって二つ目読んだら次のセクションに入れるんですけど
時間が来てしまったのと二つ目も意外と長いので
めちゃめちゃ中途半端なんですけど
今日は一旦ここで区切らせていただきたいと思います。
明日もまたこのシッピングというプロダクション記事を
続き読んでいきたいと思いますし
一応今日の内容をざらっと明日また軽く復習してから
本番に入ると思います。
今日の朝活は以上にしたいと思います。
今日もたくさんの方にいただきありがとうございました。
木曜日ですね。あと二日仕事したらお休みなので
今日も頑張っていけたらなと思います。
では終了します。お疲れ様でした。
