« DXとは組織論である | トップページ | PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい »

2021/06/26

アジャイル開発で日本の品質技術をどこで活用すべきか #jasstkansai

JaSSTソフトウェアテストシンポジウム-JaSST'21 KansaiをOLで聞いている。
誉田さんの品質重視のアジャイル開発の講演がとても良かったので、ラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'21 Kansai

akipiiさんはTwitterを使っています 「誉田さんの品質重視のアジャイル開発の講演は良かった。アジャイル開発の中で、日本の良さを活かせる箇所はあるしそこに特定して注力すべき、というメッセージを受け取った。日本はアジャイル開発が遅れているので、励まされる。 #jasstkansai」 / Twitter

【1】アジャイル開発が日本に浸透しない理由は、「多重下請け構造に慣れたおじさん技術者が多いのでそう簡単に変化しない」ことに尽きるのではないか。

akipiiさんはTwitterを使っています 「アジャイル開発は自己組織化を重視しすぎ、という意見は同感。日本の現場では「多重下請け構造に慣れたおじさん技術者」が多いのでそう簡単に変化しない。簡単なのは、人を入れ替えるしかないんじゃないかな。 #jasstkansai」 / Twitter

アジャイル開発のチームは、リーダーがおらず、全員が自律的に動く。
しかし、日本のSIは多重下請け構造が一般的なので、発注者、プロマネ、下請け開発者という階層構造が当たり前。
ソフトウェアの請負契約がそういう縦割りの組織文化をさらに助長させて、ソフトウェア開発に悪影響を与えている。

DXは組織論である」からには、組織文化を変えるだけでなく、その組織文化を生み出す組織構造を壊さなければたぶん治らない。
実際は、年を取るほど新分野を勉強して成長するのが難しいので、人が育つのを1年も2年も待つのは難しい。
今の時代で、ビジネスはそこまで待てるのだろうか??
人を入れ替えるしかないのかもしれない。

cobaltさんはTwitterを使っています 「新人だけで構成されたアジャイルチームが失敗するのは自明では? 成熟したチームに育成目的で新人を入れる方が将来的に良いと思う。 #jasstkansai」 / Twitter

【2】アジャイル開発に日本の品質技術をどこで活用すべきか、について、本当によく考えられていると思った。

akipiiさんはTwitterを使っています 「品質重視のアジャイル開発の肝は、Doneの定義=出荷判定とみなす点と思う。そうすれば、日本の品質技術を適用しやすいし、メトリクスによる定量化も可能になる。 #jasstkansai」 / Twitter

欧米発のアジャイル開発をそのまま取り入れても、たぶん日本ではうまく行かない。
アジャイル開発の肝は、マネジメント系プラクティスよりも技術系プラクティスをどこまで徹底させるか、にあると思う。
マネジメント系プラクティスはたぶん、日本人も理解しやすい。
しかし、実際にアジャイル開発の開発基盤がなければ、ソフトウェア開発で結果を出していくのは難しい。

誉田さんの講演では、Doneの定義=出荷判定とみなすことで、従来の日本が誇る品質管理技術を活かせるようにした点に意義があると思う。
そうすれば、バグの原因分析、なぜなぜ分析、レビューの徹底、XDDPなどいろんな技術をアジャイル開発に適用しやすくなる。
品質をプロダクト品質、プロセス品質に分解し、日本の品質技術がどこに当てはめられるか、どのような効果が得られるか、を明示したのもわかりやすかった。

XPが生み出したTDD、CI、CD等の技術プラクティスに、日本の品質管理技術を組み合わせれば、日本の独自性も生み出せるだろう。

アジャイル開発で日本の品質技術を適用できれば、データによる定量化と統計的予測、統計的品質管理の技法を活用できる。
アジャイル開発に統計的品質管理を当てはめられたら、色んな知見が得られそう。

【3】しかし、アジャイル開発に統計的品質管理を安易に適用しても上手くは行かない。
理由は、アジャイル開発のメトリクスは相対値が多いので、定量的に比較しようがない。
また、アジャイル開発の文化として、メトリクスを自分たちチームの会話に使うので、メトリクスを第三者への説明に使う発想がないし、メトリクスが独り歩きして自分たちの行動を縛るのは嫌う。

akipiiさんはTwitterを使っています 「ストーリーポイントは自分たちのチームの会話に使うものです、と言う回答は思わず膝を叩いた。そう、自分たちのためであり、第三者への品質保証のためではない。 #jasstkansai」 / Twitter

この辺りは、昨今のSaaSみたいに、開発者がソフトウェア開発を行っている行動を自動的にログとして透過的に採取する仕組みを使えばいいと思う。
現代では、ビジネスや人の行動のログは、自動的に採取して、その大量データをAIで分析して活用する仕組みが当たり前だから。

akipiiさんはTwitterを使っています 「メトリクス収集はアジャイル開発で嫌われる問題点はあるが、Webログ採取みたいに、開発者が普通に会社で働いていれば自然に取れるようにすればいい。労働時間、工数は必ず取るし。 #jasstkansai」 / Twitter

【4】アジャイル開発を日本のチームが取り入れたとき、もっと技術系プラクティスを重視すべき、というメッセージは非常に重要と思う。
なぜなら、従来の開発者はテスト駆動開発とか継続的インテグレーションとか、割と使っていないからだ。
特にテスト自動化の技術が疎いように思う。

そして僕自身もこの辺の知識が古くなっていると痛感している。
テスト自動化の技術はここ10年でかなり深化して広がっていると思う。

テスト自動化だけでなく、テスト管理ツールや品質管理ツールも急激に進化して変わっている。
この辺りはもっと調査していく。

TestRailの感想: プログラマの思索


|

« DXとは組織論である | トップページ | PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい »

コミュニティ」カテゴリの記事

ソフトウェア工学」カテゴリの記事

Agile」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« DXとは組織論である | トップページ | PMBOKガイド第7版はアジャイルの観点へ大幅に内容が変わるらしい »