見出し画像
Photo by chiyoizmo

品質向上のプロセスについて考察

DandK

どうやったら品質を向上させるプロセスを作成する事ができるのかについて考えてみたアウトプット

前提

今回はソフトウェアテストについてのテストについては触れません。どっかの機会で触れる予定。
あくまでプロセスについての考察なので、それ以外の具体的な話は触れません。

プロセスについての重要な事

まずプロセスに重要な事は下記の点だと思います。

  • 繰り返し行われていくものであること

  • チームや部門、会社が成熟していく事によってより改善されていくこと

  • 事前に定義、言語化がされていることだと思います

重要な事

まずそもそも上記の状態になっていないプロセスは生まれたばかりのプロセスで暗黙的なものです。そのままプロセスを進めるのは普及に時間がかかったり、認識が異なったりという事態が発生し得るので、まず定義してあげると良いと思います

プロセスの基礎

基礎

仮説

何かを行う為には仮説が必要です。
組織は無計画に何かを実行することはできないです。
ましてや無計画な実行による資源や時間を食い潰す行為は持続的な拡大や学習を行なっていく事を困難にします。

適切な仮説は、残りのプロセスを円滑に実行していく上で必要不可欠だと思います。
適切な仮説を定義するのは難しいです。

なので一番取り組みやすいのは、課題を見つけそれを解決するためのプロセスを設計する事だと思います。
今回の話は品質を向上させるためのプロセスなので例もそれに合わせて下記のような状態で定義します

課題例)

  1. デプロイのパイプラインに時間がかかりすぎてテストしたソフトウェアのリリースに時間がかかる

  2. ソフトウェアの要件定義時に定義されていたものがソフトウェアの設計時に組み込まれていない

  3. 開発チームがドキュメントを定義していないため、テストベースの質が毎回異なり均一なテスト活動ができない

仮説例)

  1. についてはそもそも本当にパイプラインがボトルネックなのか？
    マシーンパワーを上げたら解決できないか？
    並行実行で解決可能なのか？

  2. については要件定義時から設計時に落ちている要件数を考慮して
    そもそも要件定義の定義資料の質が良くないのではないか？
    トレーサビリティが取れていないのではないか？

  3. については開発チーム全体で共通のソフトウェア開発ガイドラインを定義したら解決しないか？
    毎回開発チーム内でレビューする手順を導入したら解決しないか？

例であげているだけでもこのように仮説を上げることができます。

検証

仮説を立てた後には検証する事で、仮説はどの程度当たっているのかや
外れているのかについて検討する準備をすることができます。

前項であげている内容は以下の様に検証するとします。

  1. デプロイパイプラインの実行からデプロイまでの時間をログを見て統計をとる
    並列実行に切り替えた時の統計を取得する
    マシンパワーを上げて統計を取得する

  2. 要件定義時と設計時の実装内容がどれだけトレーサビリティを取れているか調査する
    要件定義書のフォーマットを一度整理して書き直したもので開発に渡してみる
    要件定義から設計時にかかるまでの期間を取得する

  3. 品質部門のスキルトレーニングをして、再度開発チームのドキュメントをベースにテスト活動を行なってみる
    レビュー活動が入った時に抜け漏れや考慮漏れがどれだけ改善されたかアンケートを取ってみる

評価

評価は検証内容が妥当なのかや今後活動を継続するのか、終了するのかを判断する為に重要です。
上記の仮説と検証で行った結果を元に判断を下します。
結果の値の取り扱いには注意が必要で実行や調査を行ったメンバーだけで判断を下すのではなく、関係するステークホルダーを集めて公な場所で結果を必ず判断しましょう。

  1. 変更前は実行からデプロイまで二時間かかった
    並列処理で実行する事で時間が30分までに短縮された
    変更前から変更後の実行時間はおよそ七五％解消された

  2. 要件定義書のUpdate前のトレーサビリティは30%だった
    Update 後のトレーサビリティは60%にまで上がった
    要件定義書の書き方を変更してトレーサビリティはおよそ２倍の値にまで上昇した

  3. 開発チームのレビューや品質改善の結果目新しい改善は得られなかった

フィードバック

上記のすべての段階を実行した後に得られるのがフィードバックです。
ここで重要なのは悪い結果であっても受け止めなければいけないということです。

基礎のまとめ

一番重要なのは、プロセスはフィードバックまで実行して初めて結果が得られるということです。仮説や検証、評価の段階で中断してしまうと結果を取得できないので気をつけましょう。
そうなるとポイントはどれだけ上記のプロセスを早く回せるのかだと思います。
一番時間がかかるのは学習であり、その学習を素早く何回もこなせる個人やチーム、組織が品質を向上するための施策を粘り強く行うことができるのでは無いでしょうか？

プロセスの階層構造

現場からの品質向上における戦略や目標

現場からのボトムアップ

現場→この定義は実際にソフトウェアを作成して、品質を検証する集団または個人とします。
特徴としては、個人単位での改善、作りこみがやりやすい点だと思います。
またスコープの広さが組織や部門に比べて限定的ということもあげられます。

そこで最初に試してみるのは一番課題に感じている品質の問題だと思います。
例えばテスト分析にとれる時間が無い！という場合はチーム内でその時間がなぜ必要なのかの啓蒙を行う。テスト分析に時間をとれるとどのようなメリットをチームが享受できるかの説明をすると良いと思います。

会社や部門が定義している戦略や目標

会社や部門からのトップダウン

会社や部門→この定義は会社全体または現場が複数集まった集団とします。
特徴としては決定した事を組織部門から全体に下す行為は強制力が発生するということ。よくも悪くも影響力が大きいこと。です

上記のトップダウンの性質から一番初めにやるべきなのは、網羅的な方針を定義して上げる事だと思います。
ここで網羅的に広い範囲で品質に関する問題とそれを解決するためのアプローチを定義することで、大きい影響とたくさんのフィードバックが得られるからです。

振り返り

自分で書いていて思ったが、暗黙的な要件として改善がしやすいだったり
提案をしやすい会社やチームを前提にして、今回の話をしているのかなと思います。
例えば文化的にトップダウンが徹底されている組織でボトムアップ的なアプローチがやりにくい場合の対処方法についてはここで記載されていませんし、記載している内容は理想論になると思われます。

次回

ソフトウェアの設計について調べた事や考えた事を記載したいな

書き足りなかったこと

かなり抽象的な話をしていて具体的な話をできていないので、もう少し具体的な話を次回はできたら良いなと思います。
E2EやAPIテスト、ユニットテスト等々の話や手動テストを効率的に行う為にどのようにして戦略を組めば良さそうかなという考察を書いていければと思います。


この記事が気に入ったらサポートをしてみませんか？