こんにちは。QAエンジニアの大橋です。
気づいたら入社して3年経過していました。
振り返ってみた時に、QAチームの再立ち上げ的な所から、開発組織内でのQAの関わり方を整理したり、少しずつメンバーが増えていく中で体制を変えていったりと、これまでに無い経験を多くできたとても濃い3年であったと感じました。
そしてQAの組織として、品質でどのようにしてプロダクトに、利用者に、延いてはユニファに寄与できるかを考える事が徐々にできるようになってきました。
その中で、社内で中々にインパクトのあるデータに触れた事、またメンバーとの1on1の中で保守・運用面での品質について会話する機会がありました。
そこで自分なりに、システム開発における品質というものを考えてみました。
※自身の理解に基づく内容でありますため、正確では無い内容を含む可能性があります。
システム開発の始まりから終わりまでを考えてみる
システム開発の流れについて
まずシステム開発の流れについて、ウォーターフォール型の開発の流れを改めて下図で表してみました。
表した図を見てみると、開発したシステムは、リリースして運用に乗せたらその時点で終わりというように見えてしまいます。
しかし、実際には機能追加や不具合修正があり、これらに対しての要求分析・要件定義～テスト、保守・運用が発生し、流れはループしています。
システム開発におけるこのループする流れは、システム開発ライフサイクル（System Development Life Cycle）という形で表す事ができるようです。
システム開発ライフサイクルとは？
ライフサイクルの辞書的な意味は、
デジタル大辞泉*1より。。。
・生活環
・人間の一生をいくつかの過程に分けたもの
・ある製品が開発され、発展普及し、やがて新製品の開発によって衰退する一連の過程。製品の一生
とあり、システム開発ライフサイクルとは、
システムの企画～運用・運用終了までの一連の流れを示すようです。
そして、システム開発ライフサイクルとプロセスを規定するISO/IEC 15288より、下図のような形で表す事ができそうです。
ここまででシステム開発の流れを表す事ができました。
上図の流れのおける各段階で品質とは？を意識する事で、サービスとして提供するシステム全体の品質の向上が望め、延いては、システムを構成するソフトウェアの品質向上も望めそうです。
※調べていく中で様々な情報が出てきて混乱したのですが、規格を元に示せる上図は基本的な形であって、例えばアジャイル開発といったような、複数ある開発手法によって形は変わっていくようです。
システム開発についての流れを考えてきましたが、調べていく中でISO/IEC 12207で規定される、ソフトウェア開発の流れを示すソフトウェア開発ライフサイクルもある事が判りました。
（システム開発ライフサイクルを定めたISO/IEC 15288は、ソフトウェア開発ライフサイクルを定めるISO/IEC 12207をシステム全体に拡張したもののようです。両者の内容は似ていると見えますが、示すものは別ですので混同しないように注意が必要です。）
システム開発の流れに対して品質が与える影響はどういうものか考えてみる
システム開発ライフサイクル中で考慮される品質と状況
システム開発ライフサイクルプロセスは、大きく2つの段階に分けて考える事ができそうなので、下記の2つの段階に分けてみました。
- 開発に関する段階
- 運用・保守の段階
そして、大きくこの2つの段階に対しての品質がどのように考慮され得るのかを考えてみました。
- 開発に関する段階の品質
- 基本的には、要件定義や仕様の検討実施を通して資料が作成され、開発の過程で明文化されるものであり、特段意識せずとも考慮できる
- また、組織や担当者の経験・知見に基づき、明文化されていない事についても考慮される場合がある
- 運用・保守の段階の品質
- 要件定義や仕様検討を通して明文化されるが、リリースした後の運用環境下に置かれてから判明したりするものも多く、考慮には事前に十分な情報収集や運用・保守に関する知識と状況把握が必要
- 利用者側の運用・保守に直接関わるのはCSといった部門で、開発組織に属するメンバー（特にQA、エンジニア）の関わりが薄い場合、情報収集や状況把握自体が難しい
- また、リリースを優先する方針であったり、スケジュールが厳しいといった場合、考慮自体が十分でない事もあり得る
- 考慮した上で、利用者側に一定の負担を負わせる事を許容して計画が進められる事もあり得る
- 要件定義や仕様検討を通して明文化されるが、リリースした後の運用環境下に置かれてから判明したりするものも多く、考慮には事前に十分な情報収集や運用・保守に関する知識と状況把握が必要
開発に関する段階の品質は、利用者の元へ渡る前に考慮されやすいと見え、一定のものを保つ事ができそうです ただ、運用・保守の段階の品質は、利用者の元へ渡る前の考慮を十分に行う事が難しそうです。。。
運用・保守の段階での、品質への考慮が十分でない場合に何が起きるか？
運用・保守の段階での、品質への考慮が十分でない場合に、例えば下記の事が起こり得ると考えます。
- ex.利用者の想定とズレがあり不満を持たれる（思っていたのと違う、コレじゃない等）
- ⇒サービスへの低評価、企業へのネガティブイメージ（信頼）
- ⇒問い合わせ発生、利用中止・解約リスク（利益）
- ex.使い方に関する問い合わせが多く入る（使いにくい、使い方わからない等）
- ⇒対応者の人件費が高くなる（利益）
- ⇒予定していた業務の時間が削れて残業時間増に繋がる（利益）
- ⇒継続的に無視できない費用が発生する事にもなる（利益）
- ex.運用環境下で発生する不具合見つかる（この使い方したらエラー出た等）
- ⇒対応のために予定外の工数が発生する（利益）
- ⇒重篤な場合はサービス停止となる（信頼・利益）
- （本番環境でないと発生せず、ステージング環境では発生させる事が難しい事象も一定ありますが。。）
これらの事象が発生した場合、サービス・会社に対する信頼を損なうだけでなく、利益が減る事に繋がると考えます。 （当たり前品質が損なわれる事にもなる）
そして、サービスを選んで貰えず、利益を生み出す構造が作れなくなり、次の開発や保守に繋げる事ができなくなります。
これにより、システム開発ライフサイクルのループが途切れ、持続可能性が潰えてしまう事になります。
最終的に、サービス提供不可の状況となり、最悪の場合は企業の存続を脅かす事態にもなり得ると考えます。
システム開発の持続可能性と安定したサービス提供のためにQAが考える事
サービスは世の中に出して終わりではなく、如何にして手に取ってもらうか？如何にして使い続けてもらうか？を考える必要があります。
まずは、手に取ってもらわなければ話にならないため、手に取ってもらうための攻めの手が必要と考えます。
これは例えば他社と比較して魅力的に見えるような機能や付加価値であり、製品開発においては必ず考慮されるもので、品質というものは自ずと考慮されるはずです。
対して、使い続けてもらうには？の点については、例えば手に取ってもらった後のアフターフォローの充実や、運用で不具合が発生しないように事前に手を打つといった、言わば守りの手が必要と考えます。
ただ、実際の運用環境に置かれてからでないと判明しない事象が発生したりと、事前に想定は出来ていても、事前の想定から漏れる、知識・経験不足・スケジュール逼迫等により想定ができる状況に無かったりするため、事前に考慮する事は困難です。
ですが、継続して利益を得る事ができる点です。そして同時に、継続してコストが発生する点でもあります。
開発に関する段階の品質には目が行き届きやすいが、運用・保守に関する段階の品質には目が行き届きにくいと考えます。
この目が行きにくい所の品質を考える事で、システム開発の流れを途切れさせずループさせる仕組みを作る事ができ、このループさせる仕組みを作る事が、システム開発の持続可能性と安定したサービスの提供に繋がると考えます。
そしてこの仕組みを作るためにQAができる事は、
- 今回書いたような内容を周知し
- 品質の低下・向上は、不具合の発生を左右するだけではなく、企業の評判・信頼・利益に繋がるものである事の認識を持ってもらえるように
- 根拠立てて説明し理解を得るよう立ち振舞う
- これらの旗振りはQAだとしても、行動はQAだけでなく周囲を巻き込んで起こしていく
と考えます。
QAチームの1メンバーとして、システム開発における品質というものを包括して考えていけるQAチームを作りたいと考えています。
また、全ての開発に関わるメンバーがシステム開発の各段階で、品質とは？を考えていけるような土壌・文化を作っていきたいと考えています。
まだまだこれからで、道半ばにも至っていませんが、少しずつつでもこれらの行動を起こしていく事が、ユニファが掲げるPurposeを実現するためにも、QAが貢献できる所であると考えます。
ユニファではプロダクトを一緒に創っていくQAエンジニアの方を募集しています！ jobs.unifa-e.com
