
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
高橋寿一氏(以下、高橋):(スライドを示して)今日は下のビジネスとか最大公約数的なユーザーの話、Netflixの話をしたいんですが、ちょっと時間がないので、一番重要な、上流テストをどうやって効率的にやっていくかという話を少ししたいと思っています。
繰り返しになりますが、基本的には2週間とか最大4週間のスクラムの中に、単体テストとかレビューとかリファクタリングを入れなきゃならないわけですよね。毎日CI/CDを流しますと。全ケースでもいいんですけど、サンプリングでもいいです。
CI/CDを流して。本当だったら1日何回も自動テストをやりたいですね。日々品質の状況が定量的にわかる状態に今後はしていかなきゃならないのかなあとは思っています。
ここまでが前振りのロジックのところですが、ちょっと質問タイムにいきます。
高木陽平氏(以下、高木):質問係をしている、AGESTAGEST(※株式会社AGEST)の高木です。ヨシノさんから質問が来ております。「UT(Unit Test)だけを積み上げてもイテレーションのゴールは大概ビジネス要件だと思うので、やはりST(SystemTest)がいるのではないでしょうか」という質問です。
高橋:それは正しいと思います。ちょっと端折ってしまったんですが、アジャイルだとユーザーストーリーというかたちでユーザーの要件、ある意味ビジネス要件も織り込まれているとは思いますが、そこがイテレーションの中でどんどん積み上がっていくので、それはやります。
そのユーザーストーリーの中に入らないものが、やはりあります。それがビジネス要件の一部であったり、非機能要件の部分は入らないので。僕はそこだけSTでハンディングしたほうがいいのではないかと(思います)。
ただ、システムテストというものは、やはり上流でやるよりは非効率で、お金も時間もかかるものです。なので、なるべく少なくして、多くのテストを2週間なり4週間内のイテレーションに突っ込むのが品質を上げるコツなのかなとは思っています。
高木:ちょっと古い考え方で、私はアジャイルじゃなくてV字モデルで考えているのかもしれないんですけど。ユーザーストーリー、いわゆるビジネス要件は、V字でいうと右側がSTになるじゃないですか(笑)。
高橋:はいはい。
高木:それをUTでやるというのがなかなか結びつかないんですけれども。
高橋:僕はちょっと違う考えを持っていて。いわゆるV字モデルの要求仕様は、半分以上の部分が単体テストで網羅できるような気がするんですよね。
それはソースコードベースの、網羅率ベースの単体テストかもしれないし、いわゆる機能がちゃんと実装されているかどうかも単体テスト中に入れられるので。そういう意味では全部は入れられませんが、かなり多くの部分が単体テストに入るんじゃないかなと思っています。
高木:なるほど。先ほど回答してしまいましたが、STというのはシステムテストの略で、工程の最後でやるテストのことですね。
高木:もう1つ質問があります。「XP(Extreme Programming)、テストファーストの流れなのになぜなのでしょう」。これは恐らく最初の寿一さんの品質の文献がないという話だと思います。
高橋:すごくマニアックな質問をありがとうございます。XP限定のケント・ベックの本を、すごく読んだんですよ。ケント・ベックが単体テストをどう書くかっていう、ソースコードベースのけっこうめんどくさいソースコードがたくさんあるものをしっかり学びました。
テストファーストに関しても読みましたが、テストファーストはやるべきなんですよね。ただ、「テストファーストをやることによって定量的にこう改善しました」という文献が、少なくとも1990年から2022年までのほとんどの学術的文献を読んでもなかなかない。
だから、XPの中でケント・ベックが定義したことは、ペアプロもすごいし、テストファーストもいいものなので、ぜひやるべきですが、そこに対して定量的なものは今のところはないので。今後、やはり僕らも含めて、そこをやるべきかなとは思っています。
高木:ということは、プラクティスはあるけれど、定量的な部分はまだ確立してないという話なんですね。
高橋:そうですね。定量的な部分は、実はウォーターフォール時代からある網羅率しかないみたいな。もしくは「クラスコードとかきれいだよね」というところになってしまう。
高木:なるほど。
高木:お、いきなり来ましたね。「致命的なバグの決め方、または指標などはありますか。同じプロトタイプでも、利用者の使い方によって致命的か否かが変動するため」という質問が来ています。
高橋:そこに関しては、どんな本を読んでも基本的にはあまりないんですよね。バグトラッキングツールとかそういうものがサンプルで載っていますが、僕はそこは各組織で定義したほうがいいと思っています。
当然、銀行系のシステムとAndroidのゲームでは、致命的なバグの概念はやはりぜんぜん変わってくるので。ただそこは、アジャイルもウォーターフォールも変動させちゃいけないです。なので、各会社、各組織の中で決めて定量的に測っていくのが、僕は真摯で重要なアクティビティだと思います。
高木:致命的というものに関していうと、各会社またはインダストリーによるということですね。
高橋:うん。
高木:続いて、「UTはE2EテストツールでのUIテストも含めての話でしょうか。画面遷移結合のようなテストもUTでカバーされるということですよね?」という質問です。
高橋:単体テストに関しては、ユニットテストですね。僕自身はISTQB(International Software Testing Qualifications Board)の委員なので、僕が言うのもなんなんですけれど。用語は網羅率ベースのUTと、単機能ベースのUTの両方が定義されています。
なので自社内で網羅率ベースでもいいし、単機能ベースでもいいと僕は思っています。今日の話に関しては、UTは基本的には網羅率ベース、関数ベースでの話になります。
高木:いわゆるホワイトボックステストと言われている領域ですね。
高木:では続いて。「コネクティブのバグも、モビリティ領域や決算システムなどの自社内で完結しない多数のプロダクトの連携など、テストフェーズの自動化が難しい領域で、テストは今後どのようになっていくと思われるでしょうか」。
高橋:すごくいい質問ですね。今後もこの話を3時間ぐらいしなきゃいけないんですが、時間がないので手短に。
基本的に、ソフトウェア単独で動くことは今はほとんどなくなっています。マイクロサービスという考え方もあるので、基本的には自分たちの中でコンポーネントを決めて、そのコンポーネントに対してどういう品質を定義してそのまま持っていくか。それを守った後にコンポーネントを付けていくような戦略が必要になります。
例えばNetflixでは、どれが落ちても絶対にシステム全体は落とさないみたいな話をしたかったんですが。“カオスモンキー”みたいな。“カオスモンキー”はググっていただければすぐ見つかります。
そういうシステムが複雑にコネクトされているものに関しては、Netflix的なアプローチがまた重要になります。でもそれだけだとやはりうまくいかないので、各コンポーネントで最低限の単体テスト、いわゆるホワイトボックステストに出口があるのかなとは思っています。
高木:ここではどちらかというと疎結合を目指して、コネクティッドの部分はアーキテクチャで防いでいくという考え方なのですね。
高橋:そうですね。今のアーキテクチャの流行りっていう言い方はおかしいんですが、基本的には疎結合、マイクロアーキテクチャという方向なので、品質を担保するものとしてはいいアーキテクチャに向かっていることになります。
高木:では、アーキテクチャがそこに行っていないところは、やはり結合が必要という話になってしまうんですね。承知いたしました。
高木:最後の質問です。「ここでの単体テストとは主に関数ベースのユニットテストだけのことを指しているわけではなくて、ストーリー・ユースケースベースのE2E自動テストも含めているから、イテレーション中では機能要件のテストもできるという意味合いですか」。こちらは先ほどの質問と少しかぶっていますね。
高橋:この匿名さんはすごく理解をしていると思うんですよ。なので、完璧な姿はホワイトボックステストベースで単体テストをやって、ユーザーストーリーベースの機能確認を単体テストでやると、すごく洗練された組織になると僕は思うんです。
高木:もう1つ、これは深い質問が来ました。「初歩的な質問で恐縮ですが、既存のシステムへの改修案件でウォーターフォール開発からアジャイルに切り替えたい場合、既存のモジュールが含まれているので定量的な単体テスト、自動化を行うのは難しいと思うのですが、こういったケースはどう適用したらいいのでしょうか」と。
高橋:そうですね。すごく短い時間で答えるのは難しいんですが、こういうケースはあります。今後たぶんすごく増えてくると思うんですよ。ウォーターフォールでやっていたのが、組織がアジャイルに行って、ウォーターフォールで作った部分をリファクタリングしたらバグってしまったみたいな。
いろいろ手法はあるとは思いますが、基本的にはウォーターフォール部分に関してはなるべくいじらず放っておいて、新規の部分だけアジャイルでやっていくのが1つの手だと思います。
高木:今までの部分はもうブラックボックス化してしまうしかないという話ですね。
高橋:はい。
高木:そこを改修する時は、もうオールドファッションでやるしかないっていう。
高橋:というふうに割り切ってしまうことも僕はアリだとは思います。
高木:ありがとうございました。いったんここで真ん中のQ&Aは終了としたいと思います。
(次回に続く)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10