高速開発でこそ品質コントロールを最初から組み込まないとエンジニアは死ぬ

最初に立ち位置を書いておくと、アジャイルで高速で価値を届けるとかそういうの好きです。とくにカンバンの仕組みが好き。可視化できるから、だろうね。混乱しているチームを立て直すのにはカンバンが一番いい。

その上で、アジャイル（スクラム）とかカンバンとかってエンジニアリングというか科学的？なのかを考えるとどうなんだろうと思うわけです。
マニフェストがマインドセットに寄りかかる部分が多いいのではないか、と。

まぁ「それでもいいじゃん」でもいいんですが、じゃあ「品質は」と投げかけたらどう答えるのかなぁ。XPですか、そうですか。プロジェクトとして必要なスキル、レベルをカバーするメンバを用意するんですか。それじゃ、ウォーターフォールと変わらないですね。ああ、いまは手法を比べる所じゃないですね。

それで「品質」はどうしましょうか。CIでテストを書いて、ビルドとデブロイを自動化しますか。繰り返し作業はどれに関わらず機械化した方がいいです。それには大賛成。エンジニアはもっと知恵を出すところに時間をかけた方がいいもの。

それで「品質」はどうしましょう。バグが出たらチケットシステムでトレースしますか。それも大事ですね。発券されたバグのチケットがいつまでもオープンになっていないこともトレースしてくださいね。滞留している、未解決のままのバグの累積も気になりますから。

切られたチケットの事象と原因をチケットに記録して分析することも忘れないでください。でも、その期間が終わってから分析しても意味はないんですよ。あ、大幅なプロセスの改善なら意味がありますね。で、やり中のときに傾向を見て異常値を見つけて是正しないと。ajgilityを発揮するなら今の状況を把握してフィードバックループを作らないと。

それで「品質」はどうするんでしたっけ。

やった後のメトリクスを落ち葉拾いしてもそれを今生かさないと効果としては半減くらいでしょうか。

ものづくりとしてはどうでしょう。機能としての検証はいいと思うんです。それも機械化しましょう、としているのですから。では、要件を機能として作り込むところはどうでしょう。

やっぱり、アジャイル開発などにも明確な品質コントロールのプロセスの定義が必要なんだなぁと思うんですがどうでしょう。そしてこうした品質コントロールのプロセスはメンバが理解することも大事なんですが、ステークホルダーに刷り込むことも大事なんですよね。

達成した品質をあとから追加で「もっと上げて」と言わせないためにも。最後のは戦略的な話ですが、前者についてはどんな開発手法に関わらずエンジニアリングとして必要なことなんですよねぇ。

こうした品質コントロールをパターン化してテラーリングできるスキルってマインドセットとは違って基礎的なスキルとして必要なんですね。高速開発が求められ、それでアジャイルが選ばれているならそれこそ、品質コントロールを最初から組み込んでおかないと死亡フラグな気がしますね。