00:06
9月25日日曜日、時刻は朝9時。ちょっと12分もありました。
えー、台風いくかっていう感じですかね。めちゃめちゃ今日は晴れています。
東京はですね。はい、おはようございます。
ユメミのkeethこと桑原です。
では本日も朝活を始めていきたいかなと思います。
本日はですね、前々回にNext.jsの更新ブログ、12.3ですね。
の公式のブログが出たので、それを読んでたんですね。
その後、その時に最後に記事のリンクを貼ってあったその続きに、
LayoutsRFCっていうものですね。
以前この朝活でも読んだと思いますけど、そのLayoutsRFCの更新がなされていたので、
その更新文を読んでいこうかなというふうに思っていたはいたんですけど、
ちょっとですね、なんて言いますか。
更新が、あくまでアップデートですので、もともとの記事の前半からですね、
読んでないとやっぱり理解しづらいなっていうのと、もともとのブログ自体もですね、
図がいっぱいたくさん出てきたりとか、画像での説明が多かったので、
やっぱりこの朝活で読んでても、多分皆さんふんふんって感じになったと思われます。
ちょっと理解できなかったっていうような感じの内容だったんですよね。
多分ご自身で読んでいただく分には全然理解できると思うんですよ。
ただやっぱ朝活で画像のところの説明を口頭でバーっと説明しても、
コードだったりディレクトリ構成だったりっていうのをやっぱり口で説明しても、
やっぱり認知負荷が高いので無理だったなというのがあります。
で、なんかそれ辺を全部把握した上でそのアップデートを読まないと、
ちょっと理解が難しいなというところもあったので、読みたかったんですけど、
レイアウトRFCについては活際というか、
この朝活ではもう取り上げないようにしようかなと思いました。
自分の方でまた読んで、いろいろ感想なり何なりをツイートするかもしれないですけどね。
はい、というわけで、今日何読むかちょっと悩んだんですけど、
またちょっと俯瞰的なお話というか、
直接技術の話じゃないんですけど、技術者には関わる話として、
今日はThe False Tradeoff Between Quality and Speedっていうところですね。
の記事を読んでいこうかなと思います。
よくある記事の一つですね。
品質とスピードのトレードオフですけど、
この方は品質とスピードって関しての誤ったトレードオフっていうタイトルがあったので、
どういう結論にいくのかって僕まだ読んでないので、
それを今日ちょっと読んでいこうかなと思います。
おそらくトレードオフじゃなくて、
どっちも同時に考えなきゃいけないよねっていうところが多分結論になると思うんですけど、
一応読んでみようかなと思います。
はい、では行きましょう。
品質とスピードの誤ったトレードオフです。
成長するソフトエンジニアリングチームが直面する主なリスクの一つは、
チームの生産性の低下です。
生産性の低下は多くのコミュニケーション経路を介したコミュニケーションの必要性の増加であったり、
ビジネスと顧客のリスクを対象化するために従うべき追加プロセスなど、
03:00
いくつかの要因によってもたらされます。
私が常に観察しているのは、
たとえ最高のチームであっても、
ある時点で新しい機能の構築に以前よりも段階的に時間がかかるほど、
ソフトウェアの内部品質が悪化し、
チームがスピードに苦戦するようになるということになります。
一つ画像のリンクが貼られていますね。
これはグラフです。
横軸タイムで縦軸が品質かな?機能数かな?
The fate of every software projectと言って、
全てのソフトウェアプロジェクトの運命だと言っています。
2つのグラフが貼られていますね。
これは二次曲線ですね。
1つはDev Team Velocityですね。
開発チームの速度、スピードですね。
Velocityというところです。
もう1個はNumber of Features Requestで、
機能開発に必要な機能の数がどんどん増えていくという話ですね。
2つのグラフがあって、
前者の方ですね。
Dev Team Velocityというのは、
いわゆる対数関数、ログ関数みたいな感じで、
時間が伸びれば伸びるほど、あまり上に伸びていかないと。
逆にNumber of Features Requestなので、
必要な機能数ですね。
必要な機能数というのは、
時間が経てば経つほど上がっていくというところですね。
結局最初に要件定義とかしておいて、
ここまで作りましょうって言ってたんですけど、
後から後からやっぱり開発してたりとか、
物事を進んでいくと、
クライアントだったり、ステーコーホルダーの方々の
見えてなかったところ、考慮しきれていなかった部分が
どんどん見えてきたり、
運用ってこういうのが必要だよねっていうのは、
後から発覚することがたくさんあるんですよね。
というのがあって、どんどん機能が増えていくというところです。
Dev Team Velocityというのが最初は、
上にいくんですね、グラフ的には。
高いんですけど、
だんだん時間が経てば経つほど、
やっぱりVelocityは下がっていくので、
下がると言ってもグラフ的には上がってるんですけど、
上にはいかなくて、
だんだん横ばいになっていくんですね。
どっかで必要な機能数というのが、
Dev Team Velocityを上回ってしまう。
その輪回転があるっていう話ですね、今の。
そのグラフを示されていました。
ちょっと口頭で難しかったかもしれないですけど、
一応言ってみました。
見ていただくとそこで分かると思います。
これねっていう感じですね。
戻ります。
チーム全体が高品質のソフトウェアを作るという考えに賛同し、
経営陣から支配されている、
失礼、支持されている状況でも、
このようなことが起こっているっていうのを
私は見てきました。
チーム全体も賛同してるし、
ステークホルダーだったり経営陣もサポートとか
支持しているんですけど、
結局この状況が起きてきてしまうと。
しかしある時点で彼らは苦戦し始めるんです。
この記事ではなぜこのようなことが起こるのか、
それを防ぐために技術リーダーや管理者は何ができるのか、
そして合理的な代替案はどこにあるのかというか、
どのようなものなのかっていうのを
深く掘り下げたいなと思っております。
06:01
はい、了解です。
じゃあ行きましょう。
セクション1。
What is quality?
品質とは何ぞやというところですね。
品質について語るとき、
その言葉が複数の意味を持つことがあるため、
何を意味するのか明確に理解すること、
もしくは明確化することが重要です。
例えばこんな簡単な質問を考えてみましょう。
次のうちより高品質な車はどれでしょうか?
いくつかの画像が貼られていますね。
1つ目はフェラーリSF90 STRADALEですね。
っていう車のそうです。
僕ちょっとあんまりフェラーリ詳しくないんですけど。
っていうのが1つ目です。
フェラーリSF90 STRADALEってやつですね。
続いてフォルクスワーゲンですね。
続いての画像はフォルクスワーゲンです。
フォルクスワーゲンゴルフってやつですね。
っていう車です。
この2つの画像が貼られていて、
どっちの方がクオリティ高いですか?
みたいなところをおっしゃってますけども。
品質の定義がなくして、
この質問に答えることは結構困難でしょう。
品質について語る時によくある間違いの1つに、
品質と機能の可用性というのを取り違えていることがあります。
フェラーリSF90はフォルクスワーゲンゴルフよりも
多くの機能を持っているかもしれませんし、
多くの機能でより良いパフォーマンスを持っているかもしれませんが、
これを品質が高いと解釈すべきではありません。
ソフトウェア開発における品質の定義は数多くありますが、
このブログでは以下の定義にこだわります。
ここでは以下のようなソフトウェアを高品質のソフトウェアと定義します。
4つありますね。
1つは正しいというところです。
ソフトウェアが想定していることを正確に実行し、
テストによって検証できること。
2つ目にセキュア、安全であることですね。
悪意のある利用から保護されていること。
3つ目、メンテナンスビリティですね。
保守性です。
ソフトウェアの変更と運用が容易であること。
ラスト4つ目ですね。
It does the right thing for the user.
ユーザーにとって良い影響を与えることですね。
この4つが本記事で、
この筆者のことが定義する高品質なソフトウェアということになります。
それを踏まえた上で、次に進んでいってみましょう。
フェラーリとフォルクスワーキングを出したというのは、
別にそういう対はないし、
好みがあれかというわけでもないと思います。
とにかく、車って高ければ高いほど品質が高そうなイメージはあるし、
ブランドという認知バイアスがかかっている可能性があるので、
フォルクスワーキングもフェラーリも、
どっちもブランド力としては世界有数の企業ですので、
対差はないと思います。
だからこそ、どっちが品質高い車ですかって言われても、
それは分からないよねって感じですね。
はい、じゃあ続いていきましょう。
ホワイダース・クオリティ・デトロイヤー8オーバータイムですね。
なぜ時間が経つと品質が劣化するんですか?というところを、
09:02
次に語られています。
エンジニアリングチームに高度ベースの品質が悪化した理由を尋ねると、
最も一般的になりや次のようなものです。
合計7個も挙げられていますね。
1つ、締め切りが厳しいのでショートカットをする必要があったということですね。
高度の品質じゃなくてとにかくデプロイを早くしようということですね。
2つ目は、小さな機能でほんの数人のユーザーにしか使われないみたいなところですね。
3つ目、品質問題に対処する時間は後で確保する。
と言ってやらないやつですね。
4つ目、新しい製品、プロダクトなどでユーザーに気に入ってもらえるかどうか
まだ分からないよって言ってます。
そういう意味で確かに品質っていうところが担保できていない。
これはでも確かにありそうな話ですね。
5つ目、その分機能を追加できる。
追加はできるのは別にいいんじゃないですかね。
追加できるけど、追加したところでそれが品質高いかというのは別の話ですね。
続いて、ビジネスクリティカルな機能をたくさん作る必要があります。
ビジネスクリティカルな機能ね。
やっぱり品質の基準というか目線によって全然違いますね。
続いて、ラスト7個目ですね。
利害関係者は納期を短縮するために品質を落としても構わないと考えている。
これはエンジニアとか開発現場でよくある話ですね。
でもここでもやっぱり何を品質と定義するかっていう話がまだ言及されていないので
この辺が気になるところですね。
以上7個の理由でした。
これらの理由は全てスピードという次元では品質と引き換えにより早い納品、
同じ時間でより多くの機能を提供することが可能であるという
根本的な仮定を示しているように思われます。
まあそうね。
ソフトウェアの開発では私たちは常にトレードフの関係にあり
全ての決定にはプラスとマイナスが伴います。
多くの場合プラス面しかない選択肢はなく
プラス面と引き換えにどのマイナス面を強要するかという選択がなされます。
これもそうですね。
しかし品質とスピードについて語るときこれは誤ったトレードフであり
その理由を理解することがチームが高品質のソフトウェアを提供することを
可能にする鍵であると私は考えています。
一般的にチームによっては品質と引き換えにスピードを得ることが可能だと考えています。
マーチンファウラーはこれをトレード可能な品質仮説として定義しています。
そういう記事のリンクが貼られてますね。
トレーダブルクオリティハイポセシス
別の記事のリンクが貼られているので興味ある方は見てみてください。
どういう風に定義しているかというと
品質は取引可能であり、より低い品質を強制することで
コスト、スコープまたはスピードといった他の次元で利益を得ることができます。
しかしなぜ人々はこれが真実だと考えるのだろうかと言っています。
なるほど。
マーチンファウラーはトレードオフみたいな考え方で書いているんですね。
12:03
もう一回読みます。
品質は取引可能であり、より低い品質を強制することで
コスト、スコープまたはスピードといった他の次元で利益を得ることができる。
マーチンファウラーはトレードオフだねという考えに立脚して定義をしているということです。
今回の筆者の方はこれに対して異を唱えるというか疑問を呈しているということですね。
なんでこれが真実だというふうに皆さんは信じているのかなというところでした。
続いていきましょう。
この仮説の前提というのはソフトウェアの内部構造はユーザーが直接観察できないので
システムの内部品質を下げることでエンジニアリング能力を獲得し
それを製品への機能追加に投資することで開発速度を上げられるというものですね。
エンジニアリング能力というかぶっちゃけただのリソースじゃないかと思ったりしますけど。
しかしこの考え方は2つの大きな問題を起こします。
まず品質とスピードを引き換えにした場合スピードは向上するどころか
実は低下してしまいますよというのがまず1つ目だと言っています。
これもよくある話ですよね。
続いていきましょう。
現在のサービス開発の世界では製品というのは長期的なサービスとして構築され
ユーザーのニーズに合わせて進化し続けます。
その結果ほとんどの製品開発作業は既存のコードベースと既存の製品というコンテキストで行われます。
このことは2つの重要な季節をもたらします。
まず新しいコードを書くよりも既存のコードベースの修正に多くの時間を費やすと
ソフトウェアの開発、構築速度に大きく影響するのは変更のコストになりますよと言っていますね。
得てして既存のコードベースの修正することの方が時間がかかることってありがちですよね。
もちろん必ずしも新しく全部書き直す方が早いというわけではないですけど
往々にして既存のコードベースの方が技術的不採だったり
負の遺産化してしまっているコードもよくあるので
それの修正の方が時間がかかるんじゃないかというのはよく聞く話だと思いました。
つまりソフトウェアが期待通りに動作することを保証しながら
新しい要件を実装することがいかに簡単、難しいかということですよね。
ここの観点が重要です。
変更のコストを下げることはソフトウェアの構築速度に大きな影響を与えます。
品質が低いと将来の変更に係るコストが増加し
その結果新機能の開発にかかる時間が長くなります。
これはどんどんどんどん時間が経てば経つほど
追加される機能の数が増えていけば増えていくほど
余計にこれは増していきます。
なのでどんどんどんどん未来にかかるコストが増大していくという感じです。
本当その通りなんですけど
今目の前のリリースに集中したいという方が多いと思うんですけど
長期的に長くこのサービスやプロダクトを発展させたいというのであれば
最初に一番コストと時間をかけるのがいいと僕は思いますけどね。
結果論だしそれは正論かもしれないですけど
エティシティで現場はそうじゃないよっていうのはよくある話で
15:00
難しいですねここがプロジェクトの難しさではありますけど
次にいきましょう
次に品質が低いと開発チームが新機能に集中するために
利用できる帯域っていうのが減少しますと
バグやその他の操作上の問題によってユーザーの仕事っていうのが妨げられ
開発チームのエネルギーのほとんどが問題への対処に費やされ
チームは製品の改善に集中することができなくなりますよと
これもまあそうですよね
帯域っていうふうに書いてましたけどキャパシティですね要は
エンジンやりもキャパシティの限界があるよっていう話でした
次にいきましょう
製品開発における低品質の累積的な影響というのは
長期的には高品質のソフトウェアよりも低品質のソフトウェアを開発する方が
徐々にコストが高くなるということも意味しますよと言っています
このことはマーチン・ファウラー氏のデザインスタミナヒポセシスですか
また別の記事があるんですね
というところで非常に正確に説明されています
マーチンは設計について言及していますが
私の考えではこの仮説は品質にまたはまりますと言っています
その仮説のところ
翻訳してみましょう
翻訳しました
無設計の問題点というのは設計に力を入れないことで
コードベースが劣化し修正が難しくなり生産性が低下することです
LINEの勾配ということですね
良い設計というのはその生産性をより一定に保つので
ある時点設計の見返りの線から設計なしのプロジェクトの累積的機能を追い越し
より良い結果を出し続けることができますと言っています
この今の説明ですけど
もう一個その下に画像があるんですね
その画像というのがグラフなんですけど
そのグラフをマーチン・ファウラーは見ながら説明をしているという感じでした
冒頭のグラフと一緒ですね
に似ているやつですね
横軸が時間タイムですね
縦軸がコミュラティブ・ファンクショナリティですね
いわゆる機能と言ってもっといいかもしれないです
2つのグラフがあってノーデザインとグッドデザインですね
良い設計と設計なしのやつですね
どっかでグラフが逆転して
やっぱり良い設計の方が時間が経てば経つほど
エンジニアのクオリティも上がっていくし
ベロシティも上がっていくし
開発機能もどんどん増えていくと
ノーデザインの方は時間が経てば経つほど
ログ関数みたいにどんどん横ばいになっていって
あんまりベロシティが出ないし
どんどん時間がかかっていくということを言っています
これはご経験で皆さんも共感するところが多いと思いますが
戻ります
低品質がチームのスピードを上げるポイントはありますが
そのポイントは製品のライフサイクルの中で
人々が期待するよりもずっと早い時期に起こります
数ヶ月じゃなくてしかも数週間で起きると言っています
ほとんどの場合そしてプロジェクトのライフサイクルのほとんどの段階において
低品質のソフトウェアを作ることは
高品質のソフトウェアを作ることよりも
結果的には遅いんですよと思います
第2に品質とスピードを引き換えにすると
自己強化ループというのが発生し
18:01
ますます品質が低下します
自己強化ループ
セルフリーンフォーシングループという風に言っています
もし品質が原因で新しい機能を追加できず
ユーザーに何の利益ももたらさないのであれば
新しい機能を追加し続けることよりも
他のことを優先させるべきでしょうかという疑問を出します
この考え方が定着すると
チーム全体が底辺の競争に巻き込まれます
誰もチームの中で最も遅い開発者と思われたくないので
さらに品質を高めて
さらにスピードを落とすという
トレード負の関係に陥ってしまう
完全に負のループですねこれは
そういう意味で自己強化ループという風に
世界ではそういう風な言い方をするんです
品質を高めてスピードを落とすという
トレード負の関係に陥ってしまう
そうですね
新機能の開発がやっぱり一貫ストップして
今の現状の課題だったり
その原因の改善というところに
どんどんみんなが注力するようになってしまう
全員が全員はもちろんそうしなきゃいけないですし
機械損失レベルの話だったらもちろん
それは注力しなきゃいけないとは思いますけど
そうじゃないんであれば
1名ないし2名も新機能の開発の方に着手しつつ
改善の方もやっていくという
同時で走らせられるのが本当はいいんだろうな
と思ったりしますね
ここはでも結構難しいかもしれないです
プロジェクトの状況とかマネージャーによって
どういう戦略でいくのかという話は
結構変わってくると思いますけど
とはいえ品質の改善というところばっかりに注力をして
結局スピードを下げてしまうという
トレード負の方に陥ってしまうというのが
良くないなという話をしていましたね
続いていきましょう
The Alternative Focus on Sustained Velocity
大体やんな話ですね
持続的な速度に焦点を当てましょう
というふうにおっしゃってます
すみません
今日の朝勝ですけど
30分を超えたんですけど
いつも通りというか
昨日と同じように
ちょっと僕が寝坊してしまったので
このままちょっと時間がオーバーしてしまいます
ごめんなさい
また今日もPHPカンファレンスがあるので
そっちを聞かれる方もいらっしゃると思うし
僕も終わったらそっちに移ろうと思ってますので
なるべく早めに終わらせるように頑張りたいと思います
じゃあいきましょう
大体なんですね
ソフトウェア開発において
スピードが重要であることはもちろん明らかです
一般的にスピードの速いチームというのは
品質に対してより多くのイテレーションを行うことができ
顧客のニーズと製品がどのように
そのニーズを満たしているかどうかについての
チームの理解というのを深めることはできます
またより速いチームというのは市場が許す限り
先発者先駆者としての優位性というのを
享受することもできます
まあそうですよね
速いとそこが作れるというのは
それがかなり大きいですね
自分のポジション取りができるというのは
かなり大きいと思いますね
かつ早ければ早いほど
その製品に対しての
イテレーションサイクルが速くなるので
どんどん理解とクオリティを
上げることができるという
本当にスピードが
もたらすものがかなり大きいと思います
はい
で、サステインレベロシティですね
まあ持続的な速度というところですけど
21:00
サステインレベロシティというのは
ソフトウェア開発のチームの
現在と将来の速度を測定するものです
私はある作業を評価するとき
あるいは技術設計を評価するときに
いかに早く構築できるか
だけに注目するのではなく
その作業が現在と未来のチームの
ベロシティにどのような影響を
与えるのかにも注目します
あーこれいいリーダーですね
もしその作業によって
チームの速度が遅くなるのであれば
リリースを許可すべきではありません
チームがサステインレベロシティの
考え方を採用するには
テクニカルリーダーとして
実施できることが
いくつかありますよ
と言っています
はい
サステインレベロシティっていう風に
この方何度もおっしゃってますけど
えーと
なんかどっかの記事のリンクが
あるわけではなくて
この方自身の言葉なのかな
ちょっと分かんないですけど
気になりましたね
はい
でそのいくつかの
えーと
手法がありますよ
一個一個いきましょう
一つ目ですね
オーナーシップの文化を
構築しましょう
っていう風にまず言ってます
なるほどそっから入るの
はい
開発チームっていうのは
自分たちがソフトウェアの品質を
管理していると感じる必要があります
またプロジェクトの実行方法や
製品の定義について決定する権限が
与えられていることも重要ですと
もし利害関係者がプロジェクトの内容と
構築機関の両方を決定することを
許可されたら
チームは成功するための
体制を整えられず
品質が低下してしまいますと
はーなるほどですね
なるほど
この点については
少し異論があるかもしれません
まあそう
僕もそう思ってた
というのも
チームがどのくらいの時間が
かかることを定義すること
許可されていたら
何も出荷できなくなると
思われるかもしれません
あーでもそうですね
エンジニアとかディベロッパーだけでいくと
ベストのクオリティに
どんどん走り始めてしまって
結局リリースが
全然先に伸ばしになってしまう可能性が
大いにあるようでし
その権限を与えてしまったら
そうなってしまう可能性はあるなと思いました
しかし直感に反して
仕事の質にこだわる
プロのエンジニアチームを雇い
彼らに適切な文脈と情報を提供すれば
彼らはビジネスに役立つ
高品質のソリューションを
定義できるようになるはずですと言ってます
逆なんだね
逆にオーナーシップを
どんどん与えていくと
もちろんシステム最優先の
エンジニアの方もいらっしゃると思って
このクオリティじゃなきゃ
やっぱりプロとして仕事したくないというか
恥ずかしいから出したくないという方も
たまにいますと
僕も経験したことあるんで
そういうエンジニアも確かにいたんですけど
やっぱり使われてなんぼですからね
僕らっていうのは
プロダクトっていうのは
っていうところで
ある程度のスピード感を出したりというか
期限を決めたりというのは
もちろんあると思うんですけど
そういうところのオーナーシップを
あえてエンジニアに渡していく
ビジネス観点の
オーナーシップを与えていくっていうのが
むしろ
良いソリューションっていうのが
定義されるようになるっていう風に
この方はおっしゃってますね
なるほどでした
これは逆転の発想だけど
意外とありかもしれないですね
続いていきましょう
インシストオンハイスタンダードということですね
構成順っていうものにこだわりましょうと言ってます
全てのソフトウェアシステムにおいて
品質というのは不可欠です
24:01
私たちの世界では
プロトタイプが高級的なソリューションになる傾向が強いので
実運用に配備される全てのコードが
高い品質であることを
保証する必要があります
これらはあなたが標準を設定すべき領域の
一部でありますと
いくつかの
箇条書きになってますね
ソフトウェアがユーザーに与える影響を表す指標と
事態を悪化させていることを示す指標
っていうのをまず用意しましょうと
続いて
生産拠点に出荷される全ての変更について
ピアコードレビューっていうのを行い
大規模な設計については
デザインレビューを行いましょう
と言ってます
これも大事ですね
続いてセキュリティレビューを
迅速に行うためのプロセスも導入しましょう
と言ってます
セキュリティレビュー
レビューがそもそもできるかどうかっていうところが
大事かもしれないですけど
少なくともセキュリティに関する
チェックっていうかレビューっていうのを
体制を組むことは大事ですね
もし自社でできないんだったら
他社に全然依頼するのもいいと思います
続いて
ユニットテスト
統合テスト
エンドツーエンドテスト
パフォーマンステストっていうのが
不可視点ですね
組み合わせた
厳密なテストも行いましょうと言ってます
ここはもう言わずもうかなってところですね
もちろん全部できればベストですけど
せめてユニットテストだけとか
統合テストまでやりましょうとか
続いて
障害が発生したときに
システムがどのように反応するかを
制御できるように
障害モードっていうのも設計しましょうと
リカバリープランを作りましょうってことですね
私が過去に成功したテクニックの一つは
チームが取り組んでいる
全ての作業項目に対して
明確な完了定義を持ち
その一部として品質チェックも
含めることですよというふうに
おっしゃっています
まあ
その通りっていう感じですね
続いていきましょう
ビルドクオリティー
イントゥユアエスティメイト
アンドスケジュアルズですね
見積りとスケジュアルに
品質を組み込んでいきましょうということです
品質そのものをちゃんと
スケジュアリングして組み込むって
意外とやってるプロジェクトって
少ないんじゃないかと思ったりしますね
分かんないですけど
本当にちゃんとした事業会社とか
プロダクトを持ってる会社だったら
やってるかもしれないですけど
ソフトウェアのプロジェクトの見積りっていうのは
不正確なことで知られてきます
まあそうでしょう
不明確かつ予期しない出来事なんて
未来に必ず起きますからね
見積り納期が遅れているチームっていうのは
見積りを起源として扱い
目標を達成するために
品質を犠牲にしなければならない
というプレッシャーを感じることも
かもしれませんし
実際多いと思います
このような場合チームのスピードが
さらに低下してしまうことは
以前にも述べた通りです
見積りっていうのは不正確ですが
コードを書くだけでなく
コードレビュー
デザインレビュー
セキュリティレビューなど
より質の高い製品を作るための活動にも
十分な時間を確保することで
その質を向上させることができます
ここも大事ですよね
これらの活動には全て時間がかかるので
プロジェクト計画に
織り込んでおくことが重要です
たまに元技術者だったりとか
リーダーがいたら
自分の経験してた技術とか
その話からの見積りのレビューを
することもよくあると思いますけど
ちゃんとレビューがあって
初めてその機能を出荷する
っていうところを考えておかないと
これ作るだけだったら
そんな時間かからないでしょ
27:00
っていう話もあったりしますし
極論ただの文言変更だったりするじゃないですか
文言変更なんだから
そんな秒で終わるじゃんと思っても
別に秒で終わってプロリクエストを出して
ちゃんとレビューされて
なんだそのマージまで
アップル部2つ以上っていうのか
いう条件が課されているチームもあると思います
その後に自動テストが走って
そこから終わったので
やっとビルドできます
マージできますね
っていうのがあると思います
全部含めると秒で終わらないんですよね
そういう風な体制を組んでしまったから
文言変更だけ外すのかって言ったら
それこそ負のループに落ちるので
それ良くないよねって感じがするので
ちゃんとレビューだったりとかいうのも含めて
見積りとかスケジュールに
織り込んでいきましょう
すごく大事な観点だと思いました
今のが以上で
大体品質を高めるためのテクニックでした
最後クロージングですね
クロージングソーツで最後に
ソフトウェアの世界では
他の領域で経験するような
コストと品質のトレードオフというのは
多くの人が期待するような形では
実は機能しませんと
品質とコストのトレードオフという観点で考えると
ソフトウェア開発のプロセスの
効率が悪くなる可能性もあります
品質を高めると変更にかかるコストが削減され
開発チームは常にバグや問題で戦うのではなく
新しい価値を提供することに
集中できるようになります
これ本当そうなんですよね
サステインとベロシティの観点で考えると
品質とはスピードであり
より速い農機を確保するためには
決して交換してはならないものであることが
わかりますということで
今期時はきしめられております
大体40分なったで
10分オーバーでいつも通りって感じですね
予想通りの結論だったというところで
これはもう業界全体として
世界全体としても同じような認識だなというのは
改めて感じますね
品質とスピードトレードオフではなくて
むしろ両方を担保していかなければ
良いプロダクトができないよという話に
尽きるなと思いました
さっき出てきた品質を高めたら変更にかかる
やっぱりコストが削減されるし
開発チームは常にバグや問題で戦うのではなく
新しい機能ですね
どんどん改良改善に走れるので
よりプロダクトの品質も上げることができると
集中できるようになりますよというところで
結果スピードがバリバリ上がると言ってますので
だから最初にまず実は品質というのを下げない
というのが分かりやすい指標なんじゃないかと思います
品質に対して許容範囲というのももちろんありますし
ユーザーが不快に思う限界点というのがあると思います
もしくはユーザーが使えない
いわゆる機械創設ですよね
にならない点というところがあると思いますけど
そこまで下げるというのが大前提に考えられなくて
ユーザーにとって最高の体験を影響するために
どうするかをまずやっぱり考えて
そこを求めていくことですね
考えるだけじゃなくて実際に実行させると
結果最初にすごい時間がかかるので
ベロシティが上がらないじゃんというか
最初からかなり遅いけど
このチーム大丈夫かと思われるかもしれないですけど
後で失うコストというのがどんどんなくなっていって
後になればなるほど
ベロシティがどんどん上がっていくということですね
そこを見据えて
30:00
しっかり最初に時間とか設計とかに注力をして
ベロシティを下げてでも
最初から頑張って品質を高めていく
というのが大事なのかなというふうに思いました
以上
どっちだけ正論だと思ってますし
僕もそうは言っても結果現場はそうはいかないし
お客さんとしては遅いけどお前ら大丈夫かって
それに突っ込んでくるお客さんもいらっしゃると思います
ここは本当に難しいと思うし
頭では理解しても実際は焦りますよね
お尻決まってたり
予算とかお金をちゃんとしっかり投資してるんで
会社としては
なのでそこに対して
急かすような発言をされるのは仕方ないと思いますが
結果後になればなるほど
だいたいわーって燃え始めたりするので
ここの理解というか説明力が結構重要かなと思ったりしますね
この辺なんかしっかり言語化したりとか
具体的にいろんなプロジェクトでやった結果
こんな風な数字とかグラフになりましたよとかがあると
説得材料になると思うんで
やっぱりそういうメトリックスをちゃんと取っていたりとか
プロジェクト終わった途中でもいいので
しっかり計測をしてどうだったかっていうのを
示していくっていうのは結構大事かもしれないですね
実際にはこうだったよみたいなですね
話があるとより説得材料というか
説明力が増すのかなと思ったりしたので
この辺ですねやっぱり数字を取っていくっていうのは
ビジネスなので大事なのでも一つ
今なんか話しながら思いましたね
はい
まあちょっと長々としゃべりましたけど
今日のたかつは一旦こちらで以上にしたいかなと思います
はい今日も参加していただいた
日常郵政さんですね
ご参加いただきありがとうございました
また明日もなんかゆるーく
技術記事読んでいきたいかなと思っています
がちょっと最近引きの要件になって
俯瞰的な話の技術の記事ばっかり
僕ちょっと気になってしまってですね
あまりこう技術技術したような記事じゃない可能性は
もちろんありますので
ご了承いただければ幸いです
またなんか逆にこういうカテゴリーの
記事読んでほしいなっていうのがあったら
いつでも投げていただければなと思います
では今日の朝かつはこちらで以上にしたいと思います
日曜日ですね3連休最後ですかね
晴れてるような東京は結構晴れてるので
やっと遊びに行けるって方もいらっしゃると思うので
有益に日曜日過ごしていただければなと思います
ではこちらで朝かつ終了したいと思います
お疲れ様でした
