物理のモノづくりと比べたソフトウェア開発
物理的なモノだからこそ難しい事：
ここまでは品質の難しさや取り組みの重要性に関して語ってきましたが、物理的なモノを扱っているからこそ発生するチャレンジを紹介します。
[toc]
スケールの難しさ：
ソフトウェアの世界では処理能力を上げるためにサーバを追加してHorizontal Scalingしたり、マシンスペックを上げてVertical Scalingしたりできます。
ユーザ数やシステム負荷に応じ動的に調整ができます。
しかし、製造するのには材料を購入したり物理的に加工する時間が必要です。
そのため当然加工機も必要ですし在庫する倉庫も必要です。
クラウドと違い簡単に固定費を下げる仕組みが無いため、需要予測が非常に大切になってきます。
リカバリーの難しさ：
サーバの障害アラートが上がるとログを遡って事実確認に入るのと同じく、キャディでお客様から不良の連絡があると事実確認を行います。
遠隔で見れるサーバログと違い、事実確認だけのために実物の配送が必要な場合もあります。
製品が大きすぎて検査員を動かす方が製品を動かすより経済的な場面もあります。
修正もサーバに新しくデプロイするのではなく、物理的に追加加工をしたり、出来ない場合は再制作になります。
ソフトウェアの再制作はファイルコピーで終わるものの、物理的なモノを複製するのにはお金と時間が必要です。
そして当然ですがロールバックも出来ないため非常に神経を使います。
アジリティ向上の難しさ：
ソフトウェア開発ではロールバックを可能にしたり、git branch毎にコンパイルする技術を導入する事で、よりリスクを小さく早く取りやすくなってきました。
設計変更も小さくデリバリーできるようになりました。
しかし、CI/CD同等の技術はスケールの難しさの関係で経済的に実現しにくく、リカバリーの難しさもあり小さくデリバリーする事自体が難しいです。
品質は物理もソフトも同じに扱える
ソフトウェア開発も昔は簡単にロールバックできない、スケールしにくい、アジリティ上げにくい、と数多くの課題に悩まされていました。
ロールバックの仕組みが無いため「最後のチェック」を強化する傾向は製造業と同じくありましたし、デプロイ作業する度に本番環境に直接SSHして汗かきながらコマンドを打っていた時代もありました。
でも、Cloud Native時代の今となっては全く事情が違い、スケールもデプロイの再現性もロールバックも全部実現できる世界になってきました。
物理的なモノづくりとソフトウェアは具体のプロセス観点では違いがあるものの、品質観点から見ると意外と似ている部分もあるかなと思います。
物理のモノとソフトウェアを飛行機や空飛ぶ乗り物の開発文脈で紹介します。
飛行機といえば安全性を意識しますよね。
機内の席の広さや窓の大きさも重要ですが、安全に目的地までたどり着けることが大前提となっています。
実際は法律上数多くの安全性規定があるわけですが、どのように「安全性」という品質要件を考えられているのか深ぼってみましょう。
我々が乗る飛行機は加工部品、電子部品、ソフトウェア、パイロットが組み合わさって初めて機能する仕組みです。
全て重要な要素ですが乗客からしたらそこの詳細は関係なく、安全な空の旅が出来るかが重要で、総合的な結果が一番大切。
仮にジェットエンジンが故障しても嬉しくはないけれども、安全にたどり着けることに越したことはないです。
全ての要素がコントローラブルでは無い中でも、最終的な安全性指標として事故の確率が設けられているのが航空宇宙業界が成熟しているという主張かもしれません。
半世紀以上品質と向き合ってきた業界から、我々純粋なソフトウェア開発者としても参考にできる要素はいくつかあるのではないでしょうか。
モジュール分解しているのはソフトウェアも似ている
安全性というのは確率論なので数値化しやすく見えますが、事故要因は無限大に想像できますよね。
ジェットエンジンに鳥が巻き込まれたり、部品が劣化して壊れたり、そもそも寸法違いの部品が組み込まれていたり。
マニアックな例だと宇宙からの放射能で組み込みソフトの変数が稼働中に変わってしまうとか。
あらゆるリスクを洗い出して発生確率を計算します。
さて、ここで２つのモジュールが同時不具合起こして初めて乗客にインパクトがある事故になる場合、事故率を以下のように表現できるでしょう。（厳密には独立変数前提で記載しています）
P(overall) = P(A and B) = P(A) x P(B)
一方で、いずれかのモジュールの不具合により乗客インパクトがある場合は：
P(overall) = P(A or B) = P(A) + P(B) - P(A) x P(B)
なるべく安全性を上げる上では両方のモジュールが不具合を起こして初めて事故につながるようにレバレッジしたくなり、モジュールに分解して極力独立変数になるように設計する事を意識する方向性になるかなと思います。
書いてみれば当たり前ですが、飛行機の品質を総合的に評価する上で全体を複数の独立したモジュールに分解し、モジュール単位でリスク分析をする事で全体の確率を計算しやすくしています。
機内のビデオ配信システムとエンジン制御のシステムが完全に独立している設計になっているからこそ、ビデオ配信システムはランタイムエラーを起こしても機体の安全性には影響与えない保証があります。
重要なシステムの冗長性を担保するために複数台バックアップ用のシステムを設けることもあります。
ソフトウェア開発する上でもモジュール同士を粗結合にすべきか判断する上で、エラーのトレーサビリティやリスク分析のしやすさも考慮すべきなのかもしれません。
品質考える上でユーザもシステムである
飛行機を設計する上で、全てが広い意味でのシステムとしてモデリングされます。
エンジンも、構造物も、ソフトウェアも、パイロットもシステムです。
何らかのインプットを元にアウトプットを出すものは全てシステム。
そしてシステム毎に不具合の確率や不具合時の挙動を定義していくと、機体だけではなく空を飛ぶ仕組み全体としての不具合の確率が出せます。
ここでパイロットが全体の一部であり、システムでもあるというポイントが特徴的かと思います。
パーフェクトな人間はいないのでパイロットというシステムを定義する上で「◯◯レベルまで訓練したパイロットならX％の確率で操作ミスをする」という前提を設けて、飛行機全体の不具合の確率を計算します。
安全に到着する目的に向けてパイロットのトレーニングを強化する施策もあれば、より操縦を自動化する方法もあります。
ウェブアプリのユーザ幅はパイロットよりは広く定義も曖昧ですが、ユーザに価値提供出来るかはソフトウェアの技術的要件だけではなく、ユーザの思考にも左右されます。
ユーザをトレーニングすべきかそもそも対象外にすべきかはプロダクト次第ですが、ユーザのペルソナや前提知識をしっかりと言語化する事で初めてユーザという「システム」を品質の指標計算に入れられます。
純粋なソフトウェアの世界でもユーザを全体システムの一部だと考えると、最終的に提供したい価値がより言語化できるのかもしれませんね。
品質は継続的に改善する事で単発の何かではない. DevOpsもまさにこれ
航空業界では 「the laws are written in blood」 と言われることもあります。
全ての事件に対して調査が行われ、根本原因が特定され、再発防止対策実施までサイクルが徹底されています。
法律や規定の数が凄まじい事になっていますが、良い意味で改善が続けられてきた証拠とも言えるでしょう。
過去の失敗を元にPDCAを回し続けてきたからこそ、飛行機の事故率は交通事故より低い実績があります。
キャディのソフトウェア品質組織
今の体制：
2022年2月現在、いわゆる「品質」や「QA」や「QC」の専任人材も組織も無いです。
だからといって製造業でいう検査工程が無いわけではないですが、逆に開発者が自らプロセス改善含めて改善に投資する文化になっています。
専任がいないため劣後されるものも多く、最終的なあるべき姿とはいえないかもしれませんが、実は創業から四年間QA組織を意図的に作って来なかった背景があります。
早く専任QA組織を作ると機能を開発する人間として「一旦QAに見てもらう」事が頭を横切ってしまいますよね。
この気持ちは分からなくはないです。
しかし、この思考が根付いてしまうとQAが「テスター部隊」と暗黙知かもしれないが認識されてしまい、本質的にユーザ価値を最大化するための改善活動にリソースが避けられなくなります。
ある意味、開発組織が小さいうちに、皆で多少の障害を起こしたり転びながら成長していくフェーズかなと思っていました。
もちろんテスターのロールを担うリソースは確保していますし、現時点では開発組織も視座高く価値は出せていると思いますが、ぼちぼち限界に近づいています。
開発組織も50人超えて、今後さらに拡大していく必要があるためキャディの開発組織を一段レベルアップさせる施策が必要だと感じています。
ここまで自ら品質と向き合ってきた開発組織だからこそ、最強の品質組織をこれから作れるのではないかと思います。
テスト自体は滑り止めでしか無い
本質的には「検査」でミスに気づくのではなく、そもそもミスが起きないような仕組み作りやプロセス改善が組織の積み上がる資産になると信じています。
最後に意図的にこぼしているものを「検査」で拾うのは健全ですが、意図せぬものがそこで検知されると上流工程の方に目を向けるべきです。
このためにはDevOps的な動きも必要ですし、テストやプロセスの自動化も必要ですし、開発者の目線揃えも重要です。
車輪の再発明も減らして共通化できる部分は横断組織で持つ事で、機能の品質を向上する事もできます。
また価値を最大化する上ではより大胆な施策に挑戦する事も重要で、そこの仕組み作りという意味で、７月にプラットフォームエンジニアングチームを作りました。
開発方針の判断材料として品質指標が重要かも
現状ではSLI・SLO運用はしていません。
厳密に価値や安定性を数値化出来ていないというのもあるのですが、何らかの形で今の品質を表現する判断の軸を設ける事で皆の目線を揃えやすくなるかなと思います。
価値自体を分解し、中間指標にする事で。
今後に向けて
価値提供を一緒に考える仲間を探しています
正直、専属の人を置くことが重要なのかも分からないです。
明確に品質という領域に注力するリソースは必要ですが、それがどういう形でどういうロールなのか、日々の動き方がどうあるべきかまだ分かっていないです。
色々な事例を参考にさせて頂いていますが、一緒に挑戦してみたいなと思う方はTwitterのDM または応募ページからぜひカジュアル面談をでも設定下さい。
現状では専任のテスター部隊を求めているのではなくて、ユーザ価値を届ける上でのコスパを考慮し、プロセス改善からテストまでお任せできる人です。
全工程のステークホルダーが価値提供にフォーカスして、コスパやリスクトレードオフの判断ができる組織を目指しています。
ドメインエキスパートの仲間も探しています
パフォーマンスやセキュリティ等、普段非機能要件とまとめられる領域も暗黙知の機能要件です。
DevSecOpsという表現がバズる理由も分からなくは無いのですが、これも品質基準の言語化の一種であると考えています。
このような新たなムーブメントを社内で作ったり、専門知識を活かしたい方も是非お声がけ下さい。
絶賛仲間を探しております。
