シフトレフトという考えについて
こんにちは、トーマです
ソフトウェアテスト界隈で最近「シフトレフト」という用語をよく聞きます。
簡単に言うと、テストを可能な限り早い段階で実施し、結果的にテストに割く工数を減らそうという考えです。
早く実施するだけで工数削減になるの？という点については
ソフトウェアテストの7原則「早期テストで時間とコストを節約」にもある通り、確かに有効です。
不具合の摘出が遅くなってしまうと、それだけ後戻りの手間が増え、それに付随するテストの時間も増えてしまうためです。
個人的にひっかかるのは、このワードがなぜか『アジャイル開発』とセットで扱われていることです。
突然ですが、皆さんは「W字モデル」という言葉をご存じでしょうか。
ずいぶん前から提唱されている、ウォーターフォール開発の型の一つです。
こちらのモデルでは、システム仕様・システム設計・詳細設計と並行して、各テストの設計などを行っていきます。
テストの観点でシステム仕様・システム設計などをレビューし、テスト設計のINPUTとするため、仕様の誤りや不整合に早期に気付ける可能性が上がります。結果として、早期の品質担保が可能です。
・・・あれ？
そうです、これもれっきとした「シフトレフト」の考えです。
シフトレフトは、最近生まれた考えではなく、古くからの考えを言語化したものにすぎないと思っています。
（反論を恐れずに言うと、響きを良くして「よくわからないけど大切な要素」的に扱っているようにも思えます。）
ただ、私も言葉狩りをしたいわけではありません。
私が伝えたいのは、「シフトレフトを実現するためにはアジャイル開発が不可欠」というわけではないということです。
ここで、『静的テスト』と『動的テスト』の話をします。
仕様のレビューなどは、『静的テスト』という呼ばれ方をします。実際に動くものがなくても実施できるテストです。
『動的テスト』は、実際に動作するプログラムで実施するテストを指します。そのため、完成品の存在が不可欠です。
そのため、『静的テスト』に加え『動的テスト』も早期実施したい場合は、アジャイル開発が不可欠となります。
ウォーターフォール開発では動くプログラムの開発はプロジェクトの中盤～終盤となるため「早めに動的テストをすることで品質をより強固なものにしたい」という目的があるならば、スプリント単位で成果物が生まれるアジャイル開発の方が遥かに向いているといえます。
勘違いしないで欲しいのは
「シフトレフトの考えの元での動的テスト＝アジャイル開発が必須」ですが
「シフトレフト≠アジャイル開発が必須」である点です。
要は、シフトレフトの考えを最大限に発揮するための開発手法が、アジャイル開発であるということです。
現状V字モデルで開発しているプロジェクトが、W字モデルを採用するだけでも、立派な「シフトレフト」です。
大事なのは、横文字の用語に惑わされず「品質の早期担保のために何が大切か」ということをしっかり考えることです。
そうすれば「シフトレフト」が意味することや、その考えを最大限に発揮する方法も理解できるはずです。
QCDも欲張りたい（前編）
こんにちは、トーマです。
今回は品質トークです。
突然ですが、QCDという言葉をご存じでしょうか。
Quality（品質）
Cost（コスト）
Delivery（納期）
の頭文字を並べたものです。 この3つは、開発・製造業において、欠かすことのできない重要な要素です。
これらをいずれも向上させることは、組織における永遠の課題です。
他方を優先すると、他方が疎かになりやすいという特性を孕んでいます。
今回はそれぞれの要素の特徴について考えを述べたいと思います。
なお、今回は「ソフトウェア」を前提としての意見となりますのでご了承ください。
Quality（品質）
ソフトウェアの品質の良しあしです。
品質が高い、という状態を説明するのは難しいですが
「不具合だらけで使い物にならない」「動作が非常に重く不快である」「要求が満たされていない」など
品質が低い、という状態を説明するのは簡単だったりします。
日本人は、特に品質にこだわるというイメージが強いですね。
品質には「当たり前品質」「一次元品質」「魅力的品質」という考えもあります。
『当たり前品質』は、文字通り「満たされて当たり前」のことです。
電子レンジを例にすると、電源が付く、ドアが開閉できる、物が温められる、などです。
『一次元品質』は「満たされると満足、満たされないと不満」となるものです。
電子レンジだと、タイマー機能、ワット数の切り替え、ディスプレイの見易さ、などでしょうか。
一般的なのソフトウェア開発における「顧客要求」はこれに当たります。
『魅力的品質』は「満たされると満足、満たされなくても仕方ない」となるものです。
電子レンジだと、オーブン機能、調理機能、省エネ、などでしょうか。
ソフトウェアに+αの価値を付与するものです。
これらは一定ではなく、時代と共に移り変わるものだと思っています。前述したタイマー機能については、もはや当たり前かもしれませんね。
「当たり前品質」「一次元品質」を満たしつつ、「魅力的品質」で差別化をすることが価値向上への近道だと思っています。
Cost（コスト）
製品を作るためのコストです。
材料費・人件費・機器の維持費・特許の利用費など、コストといっても数多くあります。
ジェネリック薬品など、性能が全く同じならばあえて高いものを選ぶ人は少数派だと思います。
ユーザも一緒で、同じ品質・納期であれば、できるだけ安く済ませたいという思いがあるはずです。
（なので相見積もりなどが一般的になっているとも言えます）
Delivery（納期）
これは少し説明が難しいですが、ユーザにいかに早く届けられるかです。
注文したらすぐに欲しいのは当たり前ですね。
同じ料理で10分待つのと30分待つのでは印象がだいぶ異なります。
後者はかなりの付加価値を見出さないと、前者には勝てないでしょう。
他にも、リリースが遅くなったせいで他者製品にシェアを奪われる可能性があります。
せっかく高品質・低予算での作成が実現しても、買ってもらえないのでは本末転倒ですね。
まとめ
以上がQCDの３要素です。
読んでいただければわかる通り、これらを全て満たすのは容易ではありません。
料理を急いで作れ（D）、と言われたら、人手（C）も必要ですし、急いだことで、十分な味付け（Q）にできない可能性もあります。
このバランスをいかにとっていくかが品質担当者の腕の見せ所です。
長くなってしまったので今回はこれで切りたいと思います。
後編では、実際にどうやってバランスをとっていけばいいのか、私なりに綴ってみたいと思います。
QCDも欲張りたい（前編）
こんにちは、トーマです。
今回は品質トークです。
突然ですが、QCDという言葉をご存じでしょうか。
Quality（品質）
Cost（コスト）
Delivery（納期）
の頭文字を並べたものです。 この3つは、開発・製造業において、欠かすことのできない重要な要素です。
これらをいずれも向上させることは、組織における永遠の課題です。
他方を優先すると、他方が疎かになりやすいという特性を孕んでいます。
今回はそれぞれの要素の特徴について考えを述べたいと思います。
なお、今回は「ソフトウェア」を前提としての意見となりますのでご了承ください。
Quality（品質）
ソフトウェアの品質の良しあしです。
品質が高い、という状態を説明するのは難しいですが
「不具合だらけで使い物にならない」「動作が非常に重く不快である」「要求が満たされていない」など
品質が低い、という状態を説明するのは簡単だったりします。
日本人は、特に品質にこだわるというイメージが強いですね。
品質には「当たり前品質」「一次元品質」「魅力的品質」という考えもあります。
『当たり前品質』は、文字通り「満たされて当たり前」のことです。
電子レンジを例にすると、電源が付く、ドアが開閉できる、物が温められる、などです。
『一次元品質』は「満たされると満足、満たされないと不満」となるものです。
電子レンジだと、タイマー機能、ワット数の切り替え、ディスプレイの見易さ、などでしょうか。
一般的なのソフトウェア開発における「顧客要求」はこれに当たります。
『魅力的品質』は「満たされると満足、満たされなくても仕方ない」となるものです。
電子レンジだと、オーブン機能、調理機能、省エネ、などでしょうか。
ソフトウェアに+αの価値を付与するものです。
これらは一定ではなく、時代と共に移り変わるものだと思っています。前述したタイマー機能については、もはや当たり前かもしれませんね。
「当たり前品質」「一次元品質」を満たしつつ、「魅力的品質」で差別化をすることが価値向上への近道だと思っています。
Cost（コスト）
製品を作るためのコストです。
材料費・人件費・機器の維持費・特許の利用費など、コストといっても数多くあります。
ジェネリック薬品など、性能が全く同じならばあえて高いものを選ぶ人は少数派だと思います。
ユーザも一緒で、同じ品質・納期であれば、できるだけ安く済ませたいという思いがあるはずです。
（なので相見積もりなどが一般的になっているとも言えます）
Delivery（納期）
これは少し説明が難しいですが、ユーザにいかに早く届けられるかです。
注文したらすぐに欲しいのは当たり前ですね。
同じ料理で10分待つのと30分待つのでは印象がだいぶ異なります。
後者はかなりの付加価値を見出さないと、前者には勝てないでしょう。
他にも、リリースが遅くなったせいで他者製品にシェアを奪われる可能性があります。
せっかく高品質・低予算での作成が実現しても、買ってもらえないのでは本末転倒ですね。
まとめ
以上がQCDの３要素です。
読んでいただければわかる通り、これらを全て満たすのは容易ではありません。
料理を急いで作れ（D）、と言われたら、人手（C）も必要ですし、急いだことで、十分な味付け（Q）にできない可能性もあります。
このバランスをいかにとっていくかが品質担当者の腕の見せ所です。
長くなってしまったので今回はこれで切りたいと思います。
後編では、実際にどうやってバランスをとっていけばいいのか、私なりに綴ってみたいと思います。
要領が悪いと思ったら
こんにちは、トーマです。
私は仕事の要領がとても悪かったです。（今も言うほど良くはないです。）
特に30代前半くらいまでは何も考えずに働いていたため、思い変えすと酷い姿勢で仕事に臨んでいました。
そんな私ですが、仕事のやり方を少し変えただけで、要領の悪さは劇的に改善しました。
今回は3つほど紹介したいと思います。
※ここは本当に色々な要素があるので3つに絞るのが大変でした。
こまめなすり合わせ
以前の記事でもお伝えした通り、自分のやっていることにズレがないかこまめに確認することは重要です。
結果的に後戻りが少なくなるため仕事も早くなりますし、相手の信頼を得ることもできるので非常に効果的です。
ゴールから逆算する
今の仕事が「最終的にどういった状態になれば完了といえるか」を意識することが大事です。
ここが抜けていると、手段と目的が入れ替わってしまう可能性があります。
（例：『会議によって全員が合意した状態』が目的のはずが、『会議で全員に伝えること』が目的になってしまう、など）
徹底的にパクる
どの組織にも要領のいい人はいるはずです。その人の考え方や行動を分析し、真似ることも大事です。
デキる人には何かしら共通点があります。恥を忍んででもモノにするのが改善への第一歩です。
私自身、8歳も年下の後輩から非常に多くのことを学びました。職場は変わりましたが、尊敬する気持ちは未だ変わっていません。
おわりに
要領がいいことはメリットだらけだと思います。たまにネガティブな意見もありますが大半は妬みです。
少しでも自身をレベルアップさせるために『今よりも要領良く動くにはどうすればいいか』を考え続けることは非常に大切だと考えます。
私もまだまだ勉強中です。
【読書感想文】成長する組織をつくる1on1マネジメント
こんにちは、トーマです
10月から、リーダー側の立場として社内で1on1をやることになりました。 多少のノウハウはあるものの、参考までにと思いkindle unlimitedで掲題の書籍を読んでみました。
この書籍では、メンバーを5つのタイプに分け、それらに応じたマネジメントをしていく、という話が掲載されていました。 その5タイプについて、私の見解も交えて紹介したいと思います
①他者誘導型
『自分を中心に考え、自己の利益を追求するタイプ』
字面だけ見るととっつきにくい印象ですが、「個人の頑張り＝成果」というシンプルな考えなので マネジメントしやすそうに感じます。 頑張れば頑張った分だけ報酬が得られる、という構図が作れれば自立してくれるでしょう。
一方で、会社が傾くなど報酬で報酬で応えられない状況になると一気にモチベーションが下がるため、注意が必要です
届けたいメッセージ
『目標を実現できればこれだけの報酬アップが期待できるから、そのために手伝えることはないか？』
②組織貢献型
『相手との関係性を重視し、組織の一員であることに大きな価値を見出すタイプ』
組織にとってもチームにとっても必要な存在だと思われることに価値を見出すタイプです。 偏見ですが、多くの人はこちらに該当するのかなと思っています。
自己の利益よりも、チームや組織に認められることを大事にするので 報酬や地位ではなく、気持ちを伝えることが何より大事だと思います
届けたいメッセージ
『あなたの頑張りのおかげで皆助かっている。あなたがこれからも必要だ。』
③組織調整型
『組織全体との調和を重視し、組織内で承認（昇格・昇進）されたいと考えるタイプ』
私はこのタイプです。 ②と似ているのですが、自分の実力を示し、人の上に立ちたいと考えるタイプです。 私だけかもしれませんが、報酬よりも地位を重視します。 「給料2万円アップ」「給料1万円アップ+昇格」であれば迷わず後者を選びます。
地位を欲する理由は様々だと思いますが、本人の適正も見極めたうえで 小さめのチームを束ねてもらうなどすれば、モチベーションは高まると思います。
届けたいメッセージ
『次のポジションにいける実力があることをアピールするため、目標を考えよう。』
④理論運用型
『自分のやり方で周囲を動かし、成果を上げたいタイプ』
自分の力で周囲をリードして成果を出すことに価値を見出すタイプです。 ①と似ていますが、こちらはプレイヤーよりもマネージャーや経営側に回りたいタイプだと思います。
「自分のやり方で」とある通り、右に倣えでやっていくのはあまり好きではなく 自分が考えたやり方で結果を残すことを何より大事に考えるので、やり方を押し付けないのが大事です。
届けたいメッセージ
『この課題を解決するためにはどういうことができるか、あなたにも考えてほしい』
⑤正義調和型
『同じ志を持つ仲間と共に、お客様や世の中に貢献していくことにやりがいを感じるタイプ』
ただ目標を達成するだけでなく、それによって多くの人に良い影響を与えることに価値を見出すタイプです。 サービスをリリースして終わり、ではなく、そのサービスが実際にどう利用され、どう評価されているかまでを意識します。
上辺だけでの目標や成果には興味を抱かないことも多い為 最終的にどういった状態を目指すかをしっかりと考え、マネジメントすることが大事です。
届けたいメッセージ
『より多くの人の価値となれるようなサービス開発を共にしていこう』
おわりに
だいぶ独断と偏見が混じっていますが、こういったタイプがいるということは覚えておいた方がいいです。
メンバーにも1人1人個性があり、当然目的や価値観も異なります。
大事なのは、自分のやり方を押し付けるのはなく、1人1人に寄り添ったマネジメントをしていくことだと考えます。
いつでもできる、はメリットだらけ？
こんにちは、トーマです。
ソフトウェア品質保証の基礎知識として挙げられるJSTQB認定テスト技術者資格ですが、このたびCBT試験として実施されることとなりました。
CBT試験とは、全国各地にあるテストセンターで、コンピューター上で行う試験のことです。
最大の特長として、決まった試験日を設けておらず、センターに空きさえあれば好きな時に受験できるという点です。
当該試験に限らず、多くの資格試験は予め受験日が決まっています。
また、それに向けて数か月前から申し込みが始まることが大半です。
今回は、試験日が決められていることのメリット・デメリットについて考えていきます。
正直、メリットの方が少ないと思うので、あえてデメリットから挙げます。
試験日が決まっていることのデメリット
①自分の予定を試験に合わせる必要がある
例を挙げると
- 試験日の数日前が仕事の大事なリリース日である
- 試験日が子供など大切な人との記念日である
- 数年前から楽しみにしていたゲームが、試験日の数日前に発売される
- 友人の結婚・楽しみにしていたライブなど、他の予定と被っている
などなど。
人にはそれぞれ予定があります。それらを試験日に合わせて調整する必要があるため、人によっては「今年はあきらめよう」と考えてしまうかもしれません。
②モチベーションの維持が難しい
申し込みを行うときは、多くの人が「今回は頑張るぞ！」と意気込むかと思います。
当面は勉強にも励むでしょう。ただ、あまりに先が長いと、モチベーションを維持することが難しくなります。
単純な気持ちの問題もあるでしょうし、仕事やプライベートが急に忙しくなる可能性もあります。
その結果「記念受験」「当日、受けにすらいかない」といったケースが発生することとなります。
（主催者側としてはメリットかもしれませんが(笑)）
また「まずは勉強⇒自信がついたら受験」というサイクルが作りにくいのもデメリットと考えます。
③落ちた場合、次回受けようとする気になりにくい
どれだけ頑張っても、問題との相性で落ちてしまうこともあるでしょう。その際に『次こそは！』と思っても、次の開催は1年後…ということもあります。
そこまでモチベーションを維持し続けることは簡単ではありません。
その反面、CBTであれば結果もすぐ出ますし、その結果を見て1週間後に再度申し込む、といった荒業も可能です。
これは持論ですが、資格を持つ人が1人でも増えることはいいことだと思っています。全国的なパワーの底上げになるからです。
ただ、こういった理由で資格取得をあきらめ、その結果その分野で活躍する人が減ってしまうのは大きな損失だと思います。
（もちろん、それに見合う知識があることが前提です。）
試験日が決まっていることのメリット
これは正直メリットといえるか怪しいですが、期限があることで自身を奮い立たせることができると考えます。
デメリット②と真逆のことを言ってますが、ここは本当に人次第だと思います。予め予定が見えているため、ゴールから逆算してスケジュールを立て、実践していける人にとっては勉強のモチベーション向上につながると考えます。
（そこまで自己管理できる人は、CBTでも同じかもしれませんが(笑)）
いつでも受けられる場合「今度でいいか」が永遠に続く可能性もあります。
そういう意味では、日付が決まっていることは必ずしも悪、とは言えないと考えます。
アドホックテストは宝探し
こんにちは、トーマです
本日はソフトウェアテストの技法の一つ「アドホックテスト」について書きたいと思います。
アドホックテストとは
アドホック（ad hoc）は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句です。
それをもじったこのテストは「特定の目的のために行われる、通常のテストプロセスとは別観点のテスト」と私は認識しています。
雑な言い方をすると「テストケースを使わずに、テスターの勘と経験を頼りにバグを見つめるためのテスト」ですね。
- 探索的テスト
- モンキーテスト
- ゲリラテスト
など、様々な呼称がありますが、共通するのは「テストケースを作らない」という点です。
観点はテスターやそれを指揮する人に左右されます。
アドホックテストのメリット
色々ありますが、3つくらいご紹介します。なお、今回はWEBアプリケーションのテストを前提にしてみます。
①通常のテストでは検出できないバグを検出できる
通常、テストケースにはインプットとなる情報があります。多くの場合は設計書ですね。
当然ですが、プログラムの動作１つ１つを設計書に全て書くのは非現実的です。一方でユーザの操作パターンは無限に近いほどあります。
そういった設計書に記載しきれない点（＝通常のテストケースではカバーできない点）を色々と試してみることで、新たなバグの検出につなげることができます。
特に、新規画面や新規項目を追加したときなど、あまり叩かれていない状態であればより効果的です。
②多角的にテストできる
冒頭に記載した通り、アドホックテストのカギは「テスターの勘と経験」です。これは人ごとにと異なります。
そのためテスターによって微妙に異なる観点でテストできる可能性が高く、バグの検出率の向上につながります。
殺虫剤のパラドックスをいい感じにケアできますね。
③時間の融通が利く
アドホックテストはその性質上、ちょっとした空き時間でもアサインがしやすいです。
そのため、プロジェクト内で空いてしまった工数を有効活用することができます。
アドホックテストの注意点
こちらも色々ありますが、長くなるため1つにします。
「目的をもって実施すること」です。
いい加減に操作するだけでは、検出できるバグは限られます。
「ここが怪しいから、こういう動作をさせてみてはどうか」と考えながら実施することが大切です。
テストを通じてテスターが学習し、より検出の難しいバグを検出していけるのが理想です。
たかがテストと侮らず、仮説検証を繰り返すことで、よりバグに近づけます。
そのためには、テストの方向性を示してあげることも大事です。
『 この画面を適当にいじってほしい』
ではなく
『 この画面のこの項目について、こういったパターンでの入力を試してほしい』
のようなイメージです。
まとめ
何かと便利なアドホックテストですが、考えなしに実施しないよう、注意が必要です。
個人的に「モンキーテスト」という表現は好きではありません。（サルのように考えずに実施する、という理解）
「探索的テスト」という表現もあるように、宝（＝バグ）を探す一世一代の冒険のような気持ちで、テストに臨んでもらいたいと思います。
