AWS Dev Day 2023 Tokyo KeyNote #2 t_wada: 質とスピード 荒ぶる四天王
時間
予算
品質
スコープ
過去の経験上、削られがちなのは「品質」
品質?
「品質とは何か」の問い、あまりにもヘビー
モデリングによって「品質モデル」を発掘する
今回紹介するもの;SQueRE 品質モデル
利用時の品質と製品品質
外部品質
使いやすさ
内部品質
作る側にとっての品質
可読性・再利用性・・
ここが犠牲にされがち
自分たちを犠牲にするのは調整コストが低いから!!
ある種の自己犠牲
質とスピード = 今回は「内部品質とスピード」という話になる
内部品質?
さらに注目すると「保守性」
理解の容易性
変更容易性
試験性
保守性がさがるとどうなる
時間とお金(だいたいイコール)に悪いインパクトがある
保守性が悪いことをステークホルダーに説明しなければならない(伝えにくい)
保守性を上げる=時間をかける?
そうでもない
時間をかけてものを作ると「技術力が上がる」わけではない
クイック&ダーティの神話
汚くて速い <=> きれいでゆっくり を切り替えるようなスイッチは人間には存在しない
コンピュータの場合はある程度成り立つのかもしれんね(実行時間の制約によってロジックをかえるとか)vvani.icon
質とスピードは互いに正の関係
質をあげればスピードも上がる
スピードをあげたければ質を上げる必要がある
質を下げることはスピードを下げることにつながる
実際には質もスピードも尊重しなければならない(book; infrastructure as code (olleyly)
どちらかを諦めようとすると、すぐにどちらも成り立たなくなる・・
テスト自動化の損益分岐点
3回 or 4回 という研究が多い
期間としては1か月以内にすぐに現れるとされている(マーチン・ファウラー
実際、開発中の時点ですぐに恩恵を感じるよね vvani.icon
質とスピードのトレードオフ無効化に完全に注力する例
技術を固定して
教育不要なベテランを集めて
モノクロームな組織でサイクルを回す
この場合、組織としての存続可能性がトレードオフになっている
若者は育たず、誰かがいなくなったときに組織が死んでいく
レバレッジの効く技術はおすすめ。こういうものは文化に影響を与えやすい
誰がが頑張れば、みんなが受益者になるようなもの
EX:デプロイの自動化
みんなの時間、余力が生まれやすくなるね
みんなの余力がある状態になると素晴らしい
初期投資するときに狙って選ぶとよい
うちの業界は特殊なので・・
実は関係ない
ソフトウェアである限り、質とスピードの特性は変わらない
ハードウェア比率の高い場合でも、取り入れると強くなりそう
テスラが良い例、部品の変更を圧倒的に短い期間で実現している
外部委託は基本的にダメa
テスト自動化を提案する際のテクニック
「もうみんなやってますよ」で説得
なぜ有効?
日本は事例主義
判断をする人すら、判断基準を他人にゆだねることが多い
コード・せっけいの質を判断する力をどうつけていく?
教育の話だvvani.icon
自分で作ることで経験していくしかないだろう・・
最初から最後まで(運用まで)かかわるべき
ソフトウェアの良し悪しを図るためには「最後まで」が必要
設計のしっぺ返しを体感できるから
自然発生を待つのは時間がかかりすぎるので・・
研修
Cygames 社内ワークショップの例
Controlled Failiure の場を作る
自分たちのコードを題材にするのが最も良い