00:04
はい、6月16日、金曜日ですね。
すごく朝から16時になってしまいました。
実は僕、今日から福岡に前乗りをするので、
まあ、明日の採用イベントがありまして、
それが福岡で行われるんですけど、
当日行くのはさすがに時間的に厳しかったので、
今日前乗りして、で、明日で参加して、
明日帰りたかったんですけど、
全然帰らなかったので、
明日もまた泊まりまして、
で、あさって、日曜日ですね、
東京に戻ってこようかなと思っておりますが、
全産準備も今からするっていうところで、
今日もまたバタバタするんだろうなっていう感じです。
はい、おはようございます。
ひめみの岸ことくわからです。
では、本日も朝から始めていきたいと思います。
で、本日は、
まあこちらもですね、
Twitterでいろんな方々が読んでおられた記事ですけど、
高度品質はやはりビジネスに影響を与えるという記事があるので、
なんか短いですけどちょっとですね、
僕らの了解で、
でも影響のある、
関係のある記事だなと思ったので、
ちょっと読んでいこうかなと思っております。
では早速入って参りましょう。
私たちソフトウェアエンジニアは、
高度品質についてしばしば議論、
ま、論ずるけれども、
では高度品質の良し悪しが、
どれほどビジネスに影響するのか、
と問われると、
回答に急しますと、
各々、薄々、
高度品質が悪いと変更により多くの時間がかかりますだとか、
欠陥の修正に追われて、
開発時間が埋まれますだとか、
個人の経験や、
エンジニア的一般論に頼った、
訂正的な説明に注視するしかありません。
ソフトウェアを繰り返し変更する、
頻度が高いほど、
高度品質が開発時間に影響を与えるのは、
確かにその通りだと思えるが、
果たしてそれはどれほどのインパクトなのだろうかと。
2022年の研究論文で、
CodeRed The Business Impact of Code Quality、
という記事がありまして、
こちらでは、
コード品質がビジネスに与えるインパクトを、
時間という形で計測している。
市場投入までの時間というものが、
ビジネス上の競争優位を左右するという考えだからです。
本校では、前述の論文を中心に、
市場投入までの時間という観点で、
コード品質とビジネスの関係について、
ちょっと考えていきましょう。
本題、いろんな目次見ているセクションがありますけど、
一つ目のセクションは、
市場投入までの時間と、
コード品質の関係性ですね。
市場投入までの時間というものが、
ビジネス上の競争優位を左右するとは言うが、
市場投入までの時間と、
コード品質との間には、
どのような関係が存在するのでしょうか。
マーク・リチャーズからの、
ソフトウェアアーキテクチャーの基礎という書籍では、
市場投入までの時間を関心ごととしたときに、
必要となるアーキテクチャー特性の一つに、
アジリティというものを挙げています。
同書では、
ソフトウェア開発におけるアジリティを、
変更に迅速に対応する能力というふうにはしています。
で、和田タクト氏による、
アジリティを支える品質特性というものによれば、
03:00
アジリティと関係の深い品質特性というのは、
保守性であり、
その品質副特性として、
理解容易性と変更容易性、
そしてテスト容易性ですね。
というものを挙げられています。
これはバリーヴィエムラの保守性の定義によるものですよ。
はいはいはい。
そして、この保守性とは高度品質がもたらすものであることから、
高度品質が市場投入までの時間を決定づける要因であることもわかります。
市場投入までの時間を短縮するには、
アジリティと並んでデプロイ容易性も忘れてはならない。
ビジネス上のパフォーマンスを高める上で、
テスト容易性と並んでデプロイ容易性が重要である点は、
書籍、リーンとDevOpsの価格でも述べられているところです。
で、これらのアーキテクチャー特性を高めるためには、
素結合なアーキテクチャーが求められるという点で、
高度品質とも関係する特性であると認識すべきであろう。
では続きまして、
計測結果とリポジトリマイニング。
先ほどのCodeRed The Business Impact of Code Qualityという論文では、
次の3つの結果を得ている。
なかなかの衝撃的な数字だと。
1つ目、低品質なコードに含まれる欠陥は、
高品質なコードの15倍です。
低品質のコードの平均開発時間というのは、
高品質なコードの2倍です。
最後、低品質なコードの最大開発時間というのは、
高品質なコードの9倍になります。
具体的な測定結果というのは、
論文内に掲載された次の表の通りだと。
表がペッと貼られているんですけど、
これはちょっとね、
論読すると混乱しそうなので、
皆さんで見てみてください。
ここでの高度品質の判定は、
コード分析ツールのコードシーンというものがあって、
これによって計測される
コードヘルスというメトリクスが使われております。
このメトリクスは、
高度品質と最も低品質であることを示す
1.0から最も高品質である10.0
というまでの数値で表します。
これをさらに10.0から8.0の間であればヘルシーとし、
8.0から4.0をウォーニングとして、
4.0から1.0をアラートというふうにして、
コードベース内のそれぞれのファイルを
3つのカテゴリーのいずれかに分類しております。
上記の低品質なコードとはアラートされたファイルであり、
高品質なコードとはヘルシーとされたファイルを指します。
開発時間、タイムインディベロップメントの計測というのは、
JiraとGitのログから得ています。
例えば、コミットシャープ1がJiraの課題Xとひも付けられていたら、
そのコミットで変更されたファイル1の開発時間は、
課題のステータスがインプログレスとなってから、
コミットされるまでの経過時間となります。
次のコミットシャープ2というのが、
同じく課題Xとひも付けられファイル2を変更していた場合は、
ファイル2の開発時間は、
コミットシャープ1からコミットシャープ2までの経過時間となります。
更に課題Xにひも付くコミットシャープ3が、
ファイル1とファイル2の両方を変更していたら、
ファイル1はコミットシャープ1での計測時間に、
06:00
コミットシャープ2からコミットシャープ3までの計画時間が加えられます。
ファイルにも同様にコミットシャープ2での計測時間にコミットシャープ2からコミットシャープ30の経過時間というのも加えられます
また課題タイプがバグであるかどうかも見ております このようなリポジトリマイニングの対象とされたコードベースの数は論文タイトルにもあるとおり
39であります 論文ですね
正式に全部を読みますと コードレッド ザビジネスインパクトオブコードクオリティ アークウォンテイティブスタディオブサティナインプロパイアテリープロダクションコードベース
というタイトル なので一応39という数字は確かに出てくるんですけどね ごめんなさい
で次のセクションですけど欠陥が15倍による影響です 欠陥が多いということは予定外の作業がそれだけ増えるということになります
ジラでバグに分類された課題の平均数がヘルシーと判定されたファイルとアラート というふうに判定されたファイルで15倍も違うんであれば
高度品質の良し悪しは見積もり制度に影響を与えます バグ対応に要する時間というのは開発計画にどれだけ組み込まれているでしょうか
おそらくバッファーという形で吸収できるよう 計画に組み込まれているプロジェクトも多いと思いますがあまりにバグが多すぎて
バッファーを消費しきってしまっているというふうにあります そのようなプロジェクトは市場投入を計画通りに進められず遅延を起こします
それがビジネスに悪影響を及ぼします さらに顕在化されたバグがそれだけ多いということは潜在的なバグが多いであろうということも予想
できます そういったバグが市場投入後に障害を起こします
そうした開発者は障害対応に追われ開発時間を失っていきます それが進行中のプロジェクトの計画にも悪影響を及ぼし遅延に遅延を重ねる結果となります
はい では続いて開発時間が平均2倍最大9倍による影響です
品質が悪ければ開発時間がより長くなるという傾向が計測結果によって明らかにされました
ヘルシーとされたファイルとアラートというふうにされたファイルを比較した場合に 平均開発時間では
当社というのは前者の2倍以上もしくは最大開発時間で9倍近くなりました この結果は単に開発時間が長くなるというだけの問題ではありません
見積もりという観点で予測可能性というのが著しく下がることも意味しております 算出した見積もりに対して結果として2倍から9倍もの時間がかかってしまうかもしれない
というふうなことですね カテゴリーごとに見てみますとヘルシーでは平均開発時間に対して最大開発時間が2倍弱
アラートだと7倍以上に達しますと 高度に品質が悪いと開発時間が長くなるだけではなく
ファイルごとの開発時間のばらつきも大きくなるということでしょう このように高度品質の良し悪しが市場投入までの時間を引き延ばしてしまうというだけではなく
計画に対する予測可能性を損なわせている要因にもなっておりますと では続いて予測可能性の低下という問題ですね
09:03
先述した3つの計作結果はまさに市場投入までの時間という関心ごとに対し 高度品質が影響することを示しました
高度品質が低ければ開発時間をより必要としさらに予測可能性の低下がプロジェクトの 計画をがかりさせます
そしてこれらは結果としてビジネスの機会費用や機会損失にもつながりますと 一応もっかいあれですね
先ほど見てたその3つの数字をもっかい見ましょうか 一つ目が低品質なコードに含まれる欠陥というのは高品質なコードの15倍です
低品質なコードの平均開発時間は高品質なコードの2倍になります 低品質なコードの最大開発時間というのは高品質なコードの9倍になりますと
これが3つの計測結果でした このような状況に陥った開発チームというのは見積もり時にバッファーを可能な限り大きく積むことで
なるべく確実性の高い市場投入日を計画するようになります しかしこれでは市場投入までの時間がむやみに引き延ばされただけです
こんなやり方はプロジェクト関係者の不信感も生んでしまいます 根本的にはすでに劣悪になってしまった既存コードの品質を改善しなければならない
しかし高度品質が十分に高くなるまでプロジェクトを不安定な状態で放置するわけにも いきません
プロジェクトの予測可能性を高めるための計画作りというのが必要になりますと スクラム開発のようなアジャイル開発手法であればそれはイテレーションごとにチームの
ベロシティを見直すことで実現できるかもしれません 直近の数イテレーションでの見積もり予測を予実を比較することで1回のイテレーションでどれ
ぐらいの開発が進められるかっていうのを 補正できますこれなら予測可能性を高められますと
それにこのようにチームの実績統計に基づいて算出された見積もりであれば プロジェクト関係者もまあ納得するでしょうと
これは高度品質が悪化するとチームのベロシティが下がるという前提に基づいております ベロシティが下がる要因はここまで見てきた通り予想外もしくは予定外の作業が発生し
やすくなるということと一つの変更に対する開発時間が長くなるということになります しかし見積もりをストーリーポイントで行っているのであれば注意点があります
高度品質が良い状態でチームが完了したイテレーションのストーリーポイント合計が 例えば100ポイントだったとしましょう
ベロシティはもちろん100となりますではこれと全く同じ内容の開発を高度品質が悪い状態で見積もったら どうなるでしょうか
100ポイントのままでしょうか 100ポイントより大きくなるでしょうか
いずれにしても1回のイテレーションには収まりきれないでしょうと したがって前者の場合はベロシティが下がる
しかし後者の場合はベロシティが下がらないと 計測するとか基準の数値をどこに置くかで見えなくなっちゃう
もう少し詳しく説明するとチームはベロシティを100としているので前者では例えば イテレーション完了時点で100ポイントのうちの67ポイント分だけ完了して
ベロシティが下がる結果になります しかし後者の場合は見積もり時点で150ポイントという数字になるので今回のイテレーションでは
12:04
150ポイントのうちの100ポイントだけを計画に含めることになるでしょうと したがってベロシティは100のままですと
どちらの見積もり方法が正しいかは知らないが前者は高度品質の悪化がベロシティに現れ 後者は高度品質の悪化が見積もりに現れますと
定点観測するんであれば前者の方が時系列の変化を追いかけやすいです 後者の場合は何を比較すればいいのかがわからない
それはすなわち高度品質の悪化を関係者に説明することが難しくなるということを意味するのではないでしょうか
ただ実際のところ高度品質が悪ければ予定外の作業が増えるのでどちらの見積もり方法で あっても結局ベロシティが下がるでしょう
それならばあまり気にする必要はないかもしれません ただ予定外の作業も一つの変更に対する開発時間が長くなることもどちらの影響も
ベロシティに現れた方がシンプルではないかなというふうには思っております でラストですね高度品質を誰の目にも明らかにしましょう
はいグーグルが言うようにソフトエンジニアリングっていうのはたった一度書いて終わりの プログラミングとは違います
ソフトエンジニアリングとは時間で積分したプログラミングであるという言葉が示すように 何度も繰り返し変更されるソフトウェアを対象としております
そして少なくともその活動が人間の営みである間は保守性を高め維持し続けることだけが コードベースに変更を繰り返すことを持続可能にします
ソフトウェアを保守性のある状態に長時間保つということは普段の戦いにほかならないということ ですと
はい またストライプ社のレポートによれば開発者の平均的な1週間の仕事時間
41.1時間らしいですね のうち42%に当たる17.3時間は品質の低い高度に無駄に費やされております
また別の調査では技術的不細の管理に費やされる開発時間っていうのは開発全体の25% であるがその追跡にツールを利用する組織ってのはわずか26%で
体系的に追跡している組織ってのは7.2%しかありませんでした バックログや静的コード解析ツールなどが活用されていないということでしょうと
一方でコード品質の問題を認識しているのは開発者やアーキテクト プログラムマネージャーであり
経営者やビジネスマネージャーっていうのはほとんど認識しておりません これは42%っていう数字が載せられてますね
そういう調査結果っていうのも別でまとめられております そして高度品質の問題を積極的に管理していると回答したビジネスマネージャーはわずか10%しかおりませんでした
これらの結果からもわかるようにやはり高度品質の問題が組織の中で可視化されず エンジニアしか認識できない状態に置かれております
これでは組織として高度品質の問題に取り組むことなどできるはずもありません だから高度品質との戦いはエンジニアだけの活動になります
しかしツールを活用して高度品質を積極的に可視化し追跡可能にできれば 組織内で問題課題を共有できます
数多くある静的高度解析ツールの中には高度の問題を特定したりメトリックス化するだけでなく その問題を解消するために要するであろう
15:06
方数の参考値を出してくれるようなものになります 経験的に言ってそれらの精度に期待しすぎることはできないんですけど
考えてみればプロジェクトやプロダクトの定期報告には売上やコストといったビジネスメトリックスや アクティブユーザー数やダウンロード数といったユーザー行動に関するメトリックスが含まれていても
高度品質に含まれるような情報というのは無視されます 報告に含まれるのはせいぜい障害発生数や欠陥数ぐらいでしょうと
高度品質の問題が積もり積もって大きくなりすぎた時に初めてその解消に時間が欲しいとエンジニアが相談を切り出します これではコミュニケーションがうまくいくはずももちろんありません
私たちエンジニアはこういうコミュニケーションにももう少し目を向けるべきではないだろうか ということでこの記事は締められておりました
はいすごい記事でしたねおっしゃってることは本当その通りだしめちゃめちゃ言語化されていてありがたかったんですけど
途中途中ですね冒頭でいろんな背景だったりを語られたんですけど
とにかくいろんな書籍論文とかの記事あとはスライドとかを引用していろんな観点で高度品質とそのビジネスとの関係性とかプロジェクトの影響みたいなのを調査されて
こんだけ短いブログにスパッとまとめられているのは素晴らしいなと思いました
はいなんか頭が下がる思いですね
今後の朝活でもこの記事に引用されていたそれぞれ他のですね記事だったりスライドだったりがもし読めるんであればちょっと読んでいこうかなと思いました
それぐらいいい記事だったなと本当に思いました
これは全エンジニア皆さん必ず読んでほしいぐらいのブログだったなと改めて感じました
高度品質がどれだけ影響があるかっていうのはこういう数字で表されていて
結果それがエンジニアの工数どれぐらい奪っていくとかどれぐらい無駄に使っているかって
本当現場のエンジニアも把握してない時点で誰も把握しないことになっちゃうんですよね
例えばファインディーさんみたいなファインディーチームプラスっていうサービスがあるんですけど
あれもコミットベースで初期コミットからプルリク出すまでとかプルリクを出してからファーストレビュー受けるまで
もしくはファーストレビューからマージされるまでなどなどアップループされるまでか
アップループされてからマージされるまでとかを一個一個細かく切り出して計測できるというツールがあるんですけど
それでもこの欠陥とかの話とかは全然数字に表しづらいところですよねこういうのって
コードの品質がどれだけベロシティと影響があるかっていうのは今読んだ通りなので
単にコミットが早かったりとかマージまでの時間が早いつまりなんだっけ
ファーストコミットからマージされるまでっていうのを一つのサイクルというか区切りとしましても
そこに品質がどれだけ良くなったかっていうのは実際数字では見づらいところではありますよね
コード品質ってのはかなり定量で表しづらい感じだと思いますので
これまでも自分たちでどういうところをコード品質とするかっていう基準を決めなきゃいけないんだともちろん思いますが
もし難しければ先ほどですね本記事に使われていました通り何かツールがあるんで
そのツールを使って計測していくのは全然いいのかなと思いますね
18:01
コード分析ツールコードシーンっていうのがあるらしいですこれによってコードの品質が表されて
ヘルスですね数字が1.0から10.0まであって10.0から8.0だったらヘルシーですね
8.0から4.0でウォーニングになって4.0から1.0がアラートで3段階に分けられるんで
困ったら1回これを使ってもいいと思いますが単に開始から終わりまでの時間を計測して
ベロシティがどうかっていうのでそのチームのサイクルスピードだったりとか
ベロシティっていうところは確かにコミットベースで通知は出せるんですけど
コードの品質ってのはそこに隠れてしまうのでちゃんとそれも分析して
両方の目線でしっかりこのチームっていうのはベロシティ早くバリュームをしっかり出している
すごい良いサイクルで開発ができてるっていうのをちゃんと数値化し言語化できるっていうのは
すごく大事なことだって改めて感じました
これ今後のエンジニア人生においてこれめちゃめちゃ大事だなと思いますので
皆さんこのブログ改めて読んでみていただければなと思います
30分も過ぎましたのでこんなところで今日のあたかたは終了していきたいと思います
本日の参加者はねぶさんですね
あとうちのすずさんか
お二人ともご参加いただきありがとうございました
金曜日ですね今日もまた一日しっかり締めていただいて
土日ゆっくり休んでいただければなと思います
僕は冒頭申し上げた通り今日は
今日から福岡に前乗りして
明日採票イベントがあって
明後日日曜日で東京に帰ってこようかなと思うので
今からバタバタ準備して福岡行きたいと思います
じゃあ今日も一日頑張りましょうお疲れ様でした
