本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第6回となる今回のテーマは「スケジュールマネジメント」です。 「スケジュールマネジメント」という言葉からどのような活動をイメージしますか？ プロジェクト憲章でプロジェクトの目的目標が明らかになり、それを達成させる為のスコープも決まりました。次にやることは「そのプロジェクトの目的目標を、スコープの範囲内でいかにして達成するか」という詳細な計画づくりです。 この「計画づくり」&「計画の管理」がセットになって、詳細化されたものがプロジェクトマネジメントで云う「スケジュール」であり「スケジュールマネジメント」です。 適切な計画なしにプロジェクトを実行することは決してできませんが、 計画方法がわからない いつもスケジュールが破綻してしまうが、よりよいスケジュール計画方法がわからない といった課題を抱えている方も多いと思います。 今回と次回の2回に分けて、スケジュールを立てる為の準備とスケジュール作成方法を一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス まずはじめに目標を細分化すること プロジェクトの計画は「こう進めていけばプロジェクトが完成（成功）するであろう」というシナリオ作りだと考えましょう。目的目標をどのようにすれば行動に移せるか、行動するために不足している情報や漏れはないか？とイメージを膨らませ、何度も繰り返して「実行に移せるようなサイズ」まで分解することからはじめます。これを「要素分解」と呼びます。 間違っても、いきなり目標からすぐに工程表をひく、ということはないように、、、！ スケジュールマネジメントのステップ スケジュールマネジメントでは以下６つのステップ（プロセス）で行います。 アクティビティの定義 目標を細分化することを「要素分解」と言います。つまり要素分解された小さな要素ひとつひとつの集合体が目標になります。 このように目標を要素に細分化し「何をしなければならないか」を考える技法が、みなさんもよくご存知のWBS（ WBS：Work Breakdown Structure ）です。最終目標を細分化したものが「成果物」と呼ばれ、WBSではその成果物を要素→アクティビティに分解していきます。アクティビティはその名の通り「活動・作業」ですね。 1) 要素分解の王道ツールWBSの基本 WBSは一般的にツリー構造で作られます。 最も上は目的目標やプロジェクト名、次（2階層目）に成果物、その下に要素成果物と呼ばれる「上の成果物をさらに分解するとどのような要素か（何が必要か）」を示し、最後に要素成果物を完成させるために必要な作業としてのアクティビティを書き出します。このアクティビティが一般的には活動タスクとなります。 WBSは作成すればするほどスキルがあがり、作成スピードもアップします。みなさんもご自身の身近なものや予定などでWBS要素分解の練習をしてみましょう！ 2) 要素はどこまで分解するの？ 要素分解をどこまで行うか？という質問を頂きますが、プロジェクトの規模などにより変わってきます。 大きな粒度で活動を管理してもよい場合もありますが、大雑把すぎると進捗が見えにくくなるなどの問題が起こります。また、細分化しすぎても進捗管理自体に工数がかかります。プロジェクト管理できる適当なサイズになるようにしましょう。 中にはすぐに見通せない要素もあるかもしれません。無理をして全ての作業を特定しようとせず、将来的な作業などは段階的な詳細化でよいでしょう。完璧なWBSの作成には無理があり、時間をかけすぎて実作業にあてる時間を消化しないよう気をつけましょう。 3) 要素分解の最終チェック 要素とは「事項の成立やその効力に必要で不可欠な条件」です。抜け漏れがないように確認していきましょう。 筆者の経験からWBSの検討をキックオフ（プロジェクト立ち上げ時）のイベント/アクティビティとしてチームメンバと行うこともおすすめします。 1つ下にある全ての作業を実施するだけで作業が終わるか （必要充分） 各作業に必要となるものが他の作業で作成されているか （INPUT） 各作業で作成されたものが他の作業で利用されているか （OUTPUT） 　POINT　 作成は上から下へ、再び下から上へ確認する。 4) WBSとガントチャート（バーチャート） WBSは要素やアクティビティ（＝何をすべきか）を明確にするために使う技法です。ガントチャート（バーチャート/工程表）はそれに対して「いつすべきか」を明確にしていく技法ですので、しっかりと区別して使い、計画していきましょう。またガントチャートから作り始めることは成果物、要素成果物、アクティビティの抜け漏れ発生が高まるので「WBS作成→ガントチャート作成」という流れをセットで行うようにしてください。 作業の依存関係を確認して順序を決める：アクティビティの順序設定 アクティビティに順序をつけるということはどういうことでしょうか？ WBSはあくまで要素を洗い出す技法なので、要素やアクティビティの順序関係は意識しないというルールになっています。そのため、洗い出したアクティビティを実行するために「何をどの順番で対応するのか？対応するのがよいか？」ということを決めていく必要があるのです。 順番としては上から下に、成果物の対応順序→要素成果物の対応順序→アクティビティの対応順序と整理していきます。 1) XXが終わらないとXXに進めない？「論理的順序関係」 順序設定では、 採用が終わらないと教育研修ができない 採用と教育研修のマニュアル作りは同時にできる というように「何かが終わらないと次ができない関係性」にあるのか「同時並行できる関係性」にあるのかを考えて整理します。ただし、最終的には「同時にやりたいが対応者がいない」など全体的な考慮を加えた上でスケジュールが決定されます。 論理的順序関係には以下4つのパターンがあります。 終了ー開始関係（finishーstart：FS） ： あるアクティビティが完了すると、関連するアクティビティが開始できる（このケースが最も多い） 終了ー終了関係（finishーfinish：FF） ： あるアクティビティを終了すると、関連するアクティビティも終了できる 開始ー開始関係（startーstart：SS） ： あるアクティビティが開始されると、関連するアクティビティも開始できる 開始ー終了関係（startーfinish：SF） ： あるアクティビティの完了は、先行アクティビティの開始に左右される 2) 整理した順序はネットワーク図に整理する アクティビティ間の論理的順序関係を構造的に示すのに「ネットワーク図（ネットワークダイアグラム）」が使われます。 前後記載：順番に実行しなければならない作業 並列記載：並列に実行できる作業 　POINT　 ここではリソースの制約を考慮しなくてよい。 アクティビティ所要期間（工数と時間）を見積もる アクティビティの順序づけができたら、いよいよ時間の要素を組み込んで計画します。それぞれのアクティビティごとにどれだけの時間（期間）が必要か考えます。この検討はとても重要で難しいです。まずは専門家や有識者とディスカッションすること、併せて以下に挙げるような技法を使って考えてみてください！ 1) アクティビティ期間の見積もり技法 組織やプロジェクトの性質によって適応する見積もり技法が異なりますが、どの技法も取り出して使えるようにしておきましょう。 2) おすすめは「3点見積もり」 計算式）全体の所要期間＝(楽観値＋最頻値＋悲観値)÷3 上記の3点見積もりは三角分布を適用していますが、最頻値のウエイトを高めたベータ分布公式 （楽観値＋４×最頻値＋悲観値）÷６（加重平均） を使用するケースも見受けますね。いずれの場合も適用する楽観値、最頻値、悲観値の各値の精度（信頼性・正確性）が大切です。特に根拠はないけどこれぐらい？と「置いた値」を公式に当てはめては、せっかくの見積もりも残念なものになってしまいます。どうしてこの期間を見積ったのか？という問いに対して「根拠」を持って説明できるようにしましょう。 各値の精度を高めていくには、専門家や有識者からのフィードバックや、見積もり対象アクティビティの性質をよく知っているプロジェクトチームメンバとのディスカッションなどが有効です。メンバとのディスカッションには、アジャイル開発手法である「プランニングポーカー（planning poker）」（チーム全員での各自が思う相対的見積もりを提示し、作業項目の規模を見積もる手法）を使ってみるのもいいでしょう。 3) 気をつけたいこと 見積もりをアクティビティ実行担当やチームリーダーに依頼するのもとてもよい方法ですが、特に自信がない担当者だと工数を多めにしたり、逆に根拠もなく少ない工数で出してくることもあります。勘や経験だけからくる見積もりも危険です。 PMはメンバが見積もった工数の根拠を「なぜそう考えたのか？見積もりの根拠は？」と尋ね、見積もりが妥当かどうかを判断するようにしてください。 さいごに 今回はスケジュールを作成する為の準備となるWBSでの要素分解や、アクティビティの順序や見積もり方法を整理していきました。 次回はこれらをINPUTとしてスケジュールを作成し、スケジュールをどのように使ってマネジメントするのかという部分に触れていきます。 連載一覧 【第1回】プロジェクトマネジメントとは何か？（連載初回全文公開中） 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス The post 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ first appeared on Sqripts .

こんにちは、そして初めまして、sakkyです。   私達は日々、短いものから長いものまで、色々な文章を書いていますが、文章を書くのを苦手に感じたり、なんだかイマイチしゃっきりしないと感じたり、記載の過不足があるのではないかと思ったりする事も多いのではないでしょうか？   私自身、要求仕様書から実装仕様に落とし込みをする時に、お客さんとの会話で認識していた事を書き忘れていてメンバーから「このパターンもあると思うけど、記載がない。どう動くべき？」と言われてハッとした事もあります。メンバーが気付いてくれなければ仕様漏れしたアプリをリリースしてしまう所でした。   また、「ちょっといい書き方が出来なかった気がするけど、理解は出来るよね？」と思って書いた部分について、「この書き方だと、処理中でも処理後でもいいように取れるんだけど、処理終了前に完了していないとダメなんじゃない？実際はどっち？」と、記載の曖昧さによる事実確認をされたりすることもありました。   最初から抜け・漏れや曖昧な記述を排除出来ていれば、発生しなかったやりとりで、相手に確認の時間を取らせる必要もなかったはずです。また、近くに居れば会話で済ませられますが、お客様とのやり取りやリモートワークでの遠隔でのやりとりとなると、確認の文章を考えたり、言われた事の意味を念の為に再確認したりと、やりとりが増えたりして余計に時間がかかってしまう結果となる場合が多々あります。(待ってる時間も勿体ないですよね) そこで、私が普段文章を書く時に、上記のような認識齟齬や問い合わせが発生しないようにする為に気を付けている事を洗い出し、その中からひとつピックアップしてどんな事をしているかをお見せしたいと思います。   文章を書く上で気を付けている事を洗い出す まず、自分が普段文章を書く上で気を付けている事(簡潔に、抜け・漏れなく、読みやすく、わかりやすく、認識齟齬をなくす)を、思いつくままにピックアップしてみます。 文体は統一できてる? 粒度は均一? 句読点多すぎない? 用語は統一できてる? この用語は通じる? 5W1Hにあてはめる 以上・以下・未完・超過を分けて使えてる? 曖昧な表現ない? もっと短く出来るはず! 分割した方が良くない? 纏めた方が良くない? 前後入れ替えたらどう? 箇条書きにする 表にする 図にする 対で考える 絶対に誤字・脱字はある! 見直し3回! 一晩寝かせる 印刷してみる 誰かに(部分的にでもいいので)チェックしてもらう 目次だけでも作ってみる 言いたい事を箇条書きにしてみる どうでしょう?   思ったより多いような、少ないような?   常に意識しているもの、気になった時や詰まった時だけ使っているものがありますが、今回は「5W1Hにあてはめる」に焦点を当ててみたいと思います。 5W1Hにあてはめる なぜ「5W1Hにあてはめる」を選んだかと言うと、文章を書く上で抜け・漏れのチェックに大いに役立つからです。   何度も色んな所で見聞きしている5W1Hは、 W hen(いつ)、 W here(どこで)、 W ho(だれが)、 W hat(なにを)、 W hy(なぜ)、 H ow(どのように)の、5つのWと1つのHの事です。   5W1Hを使うメリットで良く言われる事に「現在の状況を客観的に見る事ができ、頭の中が整理される。頭の中が整理される事により、改善や立て直しをやりやすくなる」、「5W1Hを使って情報を伝えると、相手との認識ずれを防ぐことが出来る」と言ったものがあり、まさに私が文章を書く時に気を付けている事にぴったりと当てはまる内容です。   書いた文章を5W1Hに当てはめて該当するものに対する記載の有無を確認する事により、記載する情報が必要十分であるか、抜け・漏れがあるかをチェックする事が出来ます。(客観視、認識ずれ防止) また、5W1Hにあてはめる為に文章を再確認し、過不足があればどのように文章を書き直すかを考える事になる為、より読みやすい文章へ書き換えるチャンスも増える事となります。(改善) さらに過不足がなくても5W1Hにあてはめた部分を眺めていると、並べ替えて読みやすく出来そうな事に気付く場合もあり、文章改善のチャンスが増えます。(重点的に見直ししているとも言えますね) では、実際にやってみましょう。 まずは、以下のような表を作ります。   手書きでも、Excel表を使っても、頭の中で思い浮かべるだけでも良いですが、慣れない内は書き出せるものがあった方がやりやすいと思います。(チェック項目は英語・日本語併記で作りましたが、いずれかだけでOKです) 項目 該当箇所 When(いつ) Where(どこで) Who(だれが) What(なにを) Why(なぜ) How(どのように) 次に、自分が書いた文章をそれぞれに当てはめてみます。   例として以下の文章を使ってみましょう。 データ投入者が商品情報を全て入力し終えたら[実行]ボタンを押します。全てのデータが正常に入力されていれば確認画面が表示されます。エラーがあればエラーメッセージが表示されます。」 最初に、文章を分割してみます。   まず大きく2つに分けられそうです。   入力する部分である「データ投入者が商品情報を全て入力し終えたら[実行]ボタンを押します。」と、チェック結果である「全てのデータが正常に入力されていれば確認画面が表示されます。エラーがあればエラーメッセージが表示されます。」です。   次に、前者について更に分割してみましょう。   データ投入者が｜商品情報を｜全て入力し終えたら｜[実行]ボタンを押します。｜   分割が終わったので、それぞれを表にあてはめてみましょう。   「データ投入者が」は、 “だれが” にあてはめられそうなので、Whoに入れます。   項目 該当箇所 When(いつ) Where(どこで) Who(だれが) データ投入者 What(なにを) Why(なぜ) How(どのように) 「商品情報を」は、 “なにを” にあてはめられそうなので、Whatに入れます。 項目 該当箇所 When(いつ) Where(どこで) Who(だれが) データ投入者 What(なにを) 商品情報 Why(なぜ) How(どのように) 「全て入力し終えたら」は、 ”いつ” にあてはめられそうなので、Whenに入れます。 項目 該当箇所 When(いつ) 全て入力し終えた Where(どこで) Who(だれが) データ投入者 What(なにを) 商品情報 Why(なぜ) How(どのように) 「[実行]ボタンを押します。」は、うーん、どこがいいでしょう？   なんとなく “どのように” にあてはめられそうな気がしなくもないので、仮であてはめてみます。 項目 該当箇所 When(いつ) 全て入力し終えた Where(どこで) Who(だれが) データ投入者 What(なにを) 商品情報 Why(なぜ) How(どのように) [実行]ボタンを押します あてはめた結果を考察する あてはめて見ると「Where(どこで)」と「Why(なぜ)」が埋まりませんでした。   ここで、あてはめられなかった部分に対する文章が必要であるか否かを考えてみます。   Whereは、暗黙の了解もしくは前段の文章で「現在表示中の画面」と言う言葉が隠れていそうです。   一連の流れで操作する画面にたどり着いていると思われるので、前の文章が想定通りに画面にたどり着けるようになっていれば明示しなくても良いと判断できます。   Whyは、最初の文章分割で大きく2分割した2ブロック目の実行ボタンを押した結果を見ると、データ投入者が投入したデータの正当性をチェックする為であると読めそうです。   文章が仕様書であれば正当性チェックを何故行うか、どのように行うかの文章が必要になりそうな気がします。ユーザーマニュアルであれば、文面から(エラーチェックが行われる事、)正常なら確認画面に遷移する事、エラーならエラーメッセージが出る事が記載されていて、暗黙のエラーチェックの実行と、結果による分岐がある事が分かる為、ケースバイケースで文章の追加を検討する必要がありそうです。   また、「[実行]ボタンを押します」のあてはめにちょっと困ってしまいました。   あてはめに困る部分がある場合は、文章分割が細かすぎたり大きすぎたりする事が理由になっている事もあるので、あてはめを中断して文章分割を見直してみるとうまくあてはめられる場合があります。あてはめられる場所を深く考えすぎずに一旦考え直すのも良いと思います。   こういった割り当てられなかったり、文章分割し直しした部分については、何回も5W1Hあてはめをやっていると何となくやれるようになって来たりもするので、うまく行かなくても多少強引にやってみるのが良いかなと思います。強引に行ったり、組み替える事により新たな気付きが発生するかも知れませんから。 考察をもとに文章の改善を考える 考察では、Whyの部分に当たる文章の要否検討をした方がいいと結論が出ました。   ここからが難しい所ではあるのですが、チェック対象文章をもう一度見てみます。 「データ投入者が商品情報を全て入力し終えたら[実行]ボタンを押します。全てのデータが正常に入力されていれば確認画面が表示されます。エラーがあればエラーメッセージが表示されます。」   試しに「データ投入者が商品情報を全て入力し終えたら[実行]ボタンを押します。」と「全てのデータが正常に入力されていれば確認画面が表示されます。エラーがあればエラーメッセージが表示されます。」の間に文章を入れてみましょう。   「[実行]ボタンを押した後、入力データのエラーチェックが行われます。その結果、」なんてどうでしょうか？   「データ投入者が商品情報を全て入力し終えたら[実行]ボタンを押します。[実行]ボタンを押した後、入力データのエラーチェックが行われます。その結果、全てのデータが正常に入力されていれば確認画面が表示されます。エラーがあればエラーメッセージが表示されます。 [実行]ボタンを押した後の挙動が明示されました。   再度、文章を読み直し、追加した部分があった方が良いのか、冗長なのか、別な表現の方が良いかと言った事を考えてみます。   それを繰り返し、よりよいと思う文章にしていきます。 おわりに 文章を分割して5W1Hにあてはめてみると、記載が必要なものの抜け・漏れが検出できる事が確認出来ました。   何かしっくりこない場所、記載が足りないと感じる場所で効果を発揮すると思いますので、やった事がない方は試してみると良いと思います。   また、慣れて来ると表を用意しなくても頭の中であてはめが出来るようになり、文章の記述スピードも上がって来ると思いますので、最初は苦労しても何回かやってみると良いと思います。 5W1Hは検索してみると色んな記事がすぐに見つかる位に有名で、色んな所に応用が効きます。   文章を考える時、チェックする時など、何回も活用していけば自然とその思考が身に付き、他に応用が効くようになると思いますので、継続的に実践してみることをおすすめします。   私の経験則ですが、文章は意識して書けば書く程、書き方が良くなっていきます。量が質になるパターンですね。   日報とかちょっとしたメッセージでも意識して書いてみると書く練習になりますので、気が向いた時にちょっとだけ意識を向けて文章を書いてみてください。   ふとした時に、文章を書く苦手意識が減っていたり、意識しなくても文章が良くなってるなと思う事があるようになると思います。   最後に、一言。   私は、この手のテクニックの紹介は、気になるものをちょっとつまみ食いしてみて、自分に合えば使えばいいし、合わなければ捨てればいいと思っています。   先にピックアップしたもので「お、これは使えそう」と思われるものがあれば、是非試してみてください。きっとどこかでプラスになります。   (「いやいや説明してもらわないと使えないよ」と言うものがあれば、また次回と言う事で…) The post 文章を書く時に気を付けている事(5W1H) first appeared on Sqripts .

会社や部署の1人目QAとしてJoinした場合、「このタスクをこなしてください」といった、やることが定まった状態とは限りません。 むしろQAに限らずその組織におけるそのロール1人目というのは、そのロールの役割や組織内の位置づけなどを自ら定めるところからのスタートになります。このことを、私は「仕事をつくる」と表現しています。 QAとして仕事をつくるには、開発組織の現状を把握する必要があります。単純にテスト業務を巻き取ったとしても、直後にはある程度バグが減るかもしれません。しかし、組織としてはそれで満足とはならないはずです。とくに正社員のQAとしてJoinしたのであれば、たとえば組織づくりや仕組み化などを通じ、1人目のQAがずっと手を動かし続けなくとも改善される状態を期待されます。 本記事では、このような仕組み化のための現状把握について、その手段と内容をご説明します。 これから組織に1人目のQAエンジニアを迎え入れようという方や、1人目QAとしてJoinする方に参考にしていただけると幸いです。また、いわゆるテスト会社に所属するQAエンジニアとして客先に入る方にもヒントとなる部分があると考えています。 ＜1人目QAとしての立ち回り　連載一覧＞ ※クリックで開きます 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 現状把握の方法 開発組織の現状を把握するためには、いくつかの方法があります。もちろんどれか1つというわけではなく、複数の方法を試したり、あるいは時間をあけて何度も行うことも必要になるでしょう。 直接ヒアリングをする まず考えられる方法は、直接ヒアリングをして話を聞くことです。とくに入社直後であれば、あいさつもかねて会話はしておいたほうが良いでしょう。 テキストチャットのみでのやりとりでも一定距離は縮まりますが、会話すること、それもできれば直接会うことの効果は大きいです。 世の開発者の中には、残念ながらQAエンジニアに対してネガティブな印象を抱いている人もいます。開発スピードが遅くなったり、重箱の隅をつつくような指摘をたくさん起票されてあまりおもしろくない、など理由はさまざまです。理由は何にせよ、これまで居なかったQAエンジニアが組織にやってきた、という状況はある程度心理的なバリアが張られている前提で行動するほうがよい、と考えています。 そのため、まずはビデオ会議なり、対面のMTGなりで直接話をすることからはじめましょう。 また、余裕があれば複数のロールや職位の方から話を聞くのも有効です。 開発部の部長から見た組織の現状と、開発メンバーから見た組織の現状とは多少の違いがあるものです。今後QAとしてなんらかの取り組みをするうえで、一方の視点だけで判断するとうまくいきません。複数の視点から組織の現状を捉えることが大切です。 ちなみに、開発組織の規模にもよりますが、世のQAの中には「入社後にエンジニア全員と1on1をしていろいろ話を聞いた」という猛者もいます。 アンケート調査を行う 直接ヒアリングする他に、アンケート調査を行って質問項目に回答してもらう、という方法もあります。 コミュニケーションや会話の機会としては効果が減ってしまいますが、組織に複数の開発部門・開発チームがあって、それぞれの違いや差を把握したい、といった目的に対してはアンケートも有効です。 また、アンケートで開発部門に対して行う質問を通じて、QAとしての考え方や価値観、組織をどうしていきたいのかなどの思いを伝えることにも繋がります。 『サーベイ・フィードバック入門』という書籍には、以下のように書かれています。 ・あなたの職場では、オープンにコミュニケーションできていますか？ ・あなたの職場では、メンバー同士は信頼しあっていますか？ 言うまでもなく、こうした質問項目を何度も問うこと自体が、「職場ではオープンにコミュニケーションすべきである」「メンバー同士は信頼しあうべきである」というメッセージを、暗に伝えているのです。 サーベイ・フィードバック入門 QAに置き換えて考えると、たとえば開発組織に対して「単体テストのカバレッジを計測していますか？」と問えば、それはカバレッジ計測が大事である・やりましょうというメッセージになります。 ただ漠然と「今どうなっていますか？」というアンケートを行うのではなく、伝えたいメッセージを意識した状態で調査項目を設計すると、より効果的なアンケートになるでしょう。 実際にチームで一緒に働く 現状について開発チームに聞くのではなく、チームの一員として実際に業務を行うことで、生の情報を得ることができます。とくにテスト等のQA活動における課題を体感するには、この方法が一番です。 入社直後のQAは、既存の仕組みやプロセスを最もフレッシュな目でみることができます。そのため、開発メンバーにとって「あたりまえ」になってしまっているけれども対応したほうがいいところ、などを見つけられるでしょう。 何を把握すればよいか ここまでは現状把握のためにやるべきことの説明でした。とくに意外なやり方はなかったかと思います。 ここからは開発組織の現状把握といったときに何を把握すればいいのかを説明します。 開発プロセスやテストプロセス まずは、既存の開発プロセスやテストプロセスについて知ることが大切です。 長く続いている開発チームなどではこのあたりが暗黙知になっていることもままあります。その場合は、QAが自身の把握のためにプロセスをドキュメント化するところから始めるのも有効です。手近なところからチームに貢献できますし、図などにプロセスを書き起こそうとするといろんな方から「実はここがプロジェクト規模によってやらないときもあってね・・・」などの追加情報が出てくることもあります。 そのようなチーム内での細かいルールなどを知る土台にもなるため、現状の開発プロセスやテストプロセスを知り、可視化することがオススメです。 理想・現実・問題・課題 現状把握の先で改善活動につなげることを考えると、当然開発チームの問題を把握することも必要です。 私がQA業務でよく使う図をご紹介します。 この図は、よく混同されがちな「問題」と「課題」の違いについて表した図です。 本記事では「現状把握」と表現していますが、知るべきなのは今の状態だけではありません。 開発者やマネージャーが考える、理想の状態とはどのようなものかを知ることも大切です。もしかしたら、理想が明確になっていないかもしれません。その場合は、QAがリードして一緒に理想と現実を明確にするのも良いでしょう。 そこで明確になった理想と現実とのギャップが、今の開発組織における「問題」となります。 そして、QAはそこから「課題」、すなわち理想と現実とのギャップを埋めるための施策を考え、行うという流れです。 この図に基づいて考えていくことで、各要素が整理され、かつ周囲とのすり合わせが行いやすくなります。 現状とれているデータ 開発組織における問題の把握とともに行うべきなのが、現状どのようなデータがとれていて、どのように管理・集計・公開されているか、です。 大きな目的としては、QAが開発組織での改善活動を進める際に、その効果を定量的に示すことです。昨今は4 Keys Metricsなどがよく知られていますが、品質についてもなんらかの指標に基づいて改善の取り組みを行うべきです。 指標としてはたとえば、障害発生件数やテスト期間、不具合対応工数などさまざまなものが考えられます。これらはその組織ごとに選択・検討するべきものなので、「これを測っておけばOK」という絶対的なものはありません。 ただ、避けなければならないのは「なんとなく」で改善活動を行うことです。 とくに1人目のQAは、その組織内での評価が固まっていない、いわば不安定な状態です。極端なことを言えば、「居てもとくにメリットを感じないよね」と思われてしまう可能性もあります。そのような事態を避け、見える形の成果を出していくには、定量的な成果を意識していくことが大切です。 そのために、現状とれているデータは何かを把握し、それを元に改善ポイントを検討するのがよいでしょう。 一方、1人目のQAが入った時点では品質に関するデータやメトリクスがとくに集計・公開されていない、ということも多々あります。この場合は、QAとしても「＊＊が＊%改善しました」といった説明ができないため、他の工夫をする必要があります。 私がこうした状況で鉄板だと思っていること、そしてまさに今行っていることとして、「現状を計測・可視化するための仕組みをつくる」ことがあります。つまり、今可視化できていないのであれば、可視化すること自体がひとつの成果である、という理屈です。 先にご説明したアンケート調査なども該当しますし、SCMなどの開発ツールからさまざまなメトリクスを取得することもできます。 こうしたデータ収集や可視化からスタートして、品質改善に取り組むポイントを選ぶことも1人目QAの仕事のひとつだと考えています。 開発組織の今を知るところから改善をスタートしましょう 本記事では、1人目QAが開発の改善やさまざまな仕組み化を行ううえで必要となる現状把握の方法や把握すべきことについてご説明しました。 とくに品質面で課題のある組織などでは、1人目のQAがJoinした直後は「とにかくテストを！」といった目の前のことに意識が向きがちです。これ自体はやむをえないことですが、長期的には目先のテストを行うだけでは、組織全体が良い方向に向かっていきません。 まずはQAとして、開発組織の今を知るところから始めて、少しずつでも改善を行っていきましょう。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み The post 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 first appeared on Sqripts .

こんにちは。MOです。 普段はお客様の情報システムサポート業務を中心にサーバリプレイス案件などに携わらせて頂いております。 今回はVMware Workstation Player上のゲストOSの移行案件の出来事をお話させて頂きます。 環境と作業の概要 今回、VMware Workstation 12 Playerの環境からゲストOS単位でのデータコンバートを実施し、VMware Workstation 17 Playerの環境へ移行を行いました。その際、ゲストOSに動的に割り当てられたIPアドレスを、固定のIPアドレスに設定変更（ /etc/sysconfig/network-scripts/ifcfg-eth0 ファイルの編集）しました。 ● 旧環境 VMware Workstation 12 Player ホストOS：Windows 10 Professional ゲストOS：CentOS 5.11 ● 新環境 VMware Workstation 17 Player ホストOS：Windows Server 2019 ゲストOS：CentOS 5.11 ● 実施した作業 Windowsネットワーク設定 VMware DHCP Serviceの停止 /etc/sysconfig/network-scripts/ifcfg-eth0 ファイルの編集 問題の発生と原因の調査 上記移行作業後、ゲストOSの再起動をしてIPアドレスが固定化されたか確認したところ、指定したIPアドレスではなく動的に割り当てられたIPアドレスになる事象が発生しました。 原因追及をしたところ、ホストOSで「VMware DHCP Service」 の自動起動設定が有効になっており、VMware上のゲストOSを再起動した際に「VMware DHCP Service」も自動起動されて、動的にIPアドレスが割り当てられていたためでした。 上画面のように「VMware DHCP Service」の「スタートアップの種類」が『自動』になっている場合、VMware上のゲストOSを再起動すると「VMware DHCP Service」が自動起動され、ゲストOSに自動的にIPアドレスが割り振られてしまいます。この場合、IPアドレス固定化のためのに設定ファイルを編集しても「VMware DHCP Service」が有効である限り、こちらが優先されてしまいます。 解決策とその実行 IPアドレスが自動的に割り振られないために「スタートアップの種類」を「無効」にすることで「VMware DHCP Service」を自動起動させず、VMWare上にあるゲストOSのIPアドレスを固定化することができます。 また上記の作業をコマンドベースで行う場合は、下記コマンドでスタートアップの種類が変更できます。 ● 実行コマンド sc config "VMnetDHCP" start= disabled C:\\Windows\\system32 ”VMnetDHCP” start= disabled [SC] ChangeServiceConfig SUCCESS ※自動有効にする場合は「disabled」から「auto」を、手動にする場合は「demand」に変更します。 まとめ 今回はVMware Workstation Player環境化でのゲストOS移行でのお話をさせて頂きましたが、この他にもHyper-VやDockerなどのプラットフォームを利用したコンテナによる仮想化などもあります。 今後はますます仮想環境が普及していくと思いますので、より精度を高めていけるよう努めていきます。 The post VMware Workstation Player上のゲストOSのIP固定化について first appeared on Sqripts .

連載3回目となる今回は自動テストの成功基準の説明になります。 自動テストは実装したものの運用が続かず断念することが多いと感じます。目的を明確にして自動テストを導入したものの、その目的を達成できているとは思えないと感じることはないでしょうか。 「何が問題かわからないが運用が続かない」という場面に必要なものが自動テストの成功基準です。 ＜ 自動テストはなぜ失敗するのか 連載一覧＞ ※クリックで開きます 【第1回】自動テストはなぜ失敗するのか？ 【第2回】TestArchitect for Mobileの動作検証 【第3回】自動テストの成功基準｜6つのポイントをチェックする 自動テストの目的と6つの成功基準 自動テストの目的 自動テストの目的はテストの効率化です。その目的を達成するためには運用時の実行回数を重ねることが必須です。自動化スクリプトを実行する運用フェーズで何回、何十回も実行することが自動テストの成功には必要です。 実行回数を重ねるためには「実行のしやすさ」「実行する価値」を考慮した自動テストの構造にしなければなりません。 効率化の効果の少ないテストの自動化、メンテナンス効率の悪い構造など実行しやすい運用を考えていない自動化システムでは実行が続かず自動化断念となってしまいます。 自動テストの失敗する多くの場合、自動テストの成功基準を持っておらず成行きで自動化の実装を行っていることが多いです。自動テストの長期運用を成功させるための基準を設け、その基準をクリアできるスクリプトの実装を行うことが成功に必要になります。 6つの自動テストの成功基準 私が考えた長期間で自動テストの運用が成功する基準は以下の6つになります。 手動に比べ30%以上の効率化/工数削減ができること 自動化が必要なテストが選別できていること 実行途中で処理が止まらないこと 実行結果の誤判定がないこと 実行から結果確認まで自動で実行出来ること メンテナンスの効率化の対策が入っていること 項目ごとに解説していきます。 1. 手動に比べ30％以上の効率化/工数削減ができること 効率化することが重要な目的であるため効率化の度合いは重要な基準になると考えています。30%以上と基準を置いたのはスクリプト作成工数を含めて、5回程度実行することで実装コストの元をとれることを想定しています。 実際にあった現場では１回あたり10％の効率化で自動化成功と考えていました。基準値を考えず成行きで自動化した結果、現状の数値で満足してしまっているパターンでした。1回あたり10％の効率化では10回程度実行しなければ、手動に比べて自動化が有効と判断できません。これでは十分自動化導入の効果が得られているとは思えず自動テストを導入する価値がありません。 30％を超えない場合、問題があると考えるべきです。この場合、使用している自動化ツールの機能が不十分で自動化できる範囲が狭いなどが考えらえます。そのため別の自動化ツールを検討する必要があります。 2. 自動化が必要なテストが選別できていること 自動テスト運用が断念する大きな要因は必要性の感じないテストを自動化することによる効果が薄く感じることにあります。運用フェーズで実行する価値のあるテストが自動化できていなければ、実行する必要性や効果が見られず実行すること自体が非効率となります。そのため必要なテストが自動化できていることは重要です。 簡単に自動化できるテストを抜粋し、自動化できる件数が多くすると考えていたプロジェクトがありました。結果的に仕様変更などでスクリプト修正が発生した際にコストをかけてまで実行する必要性がなく数回の実行で運用断念となりました。 何度も実行する価値のあるテストは何かを考えて、必要なテストを自動化することが自動テスト成功には重要な要素です。 3. 実行途中で処理が止まらないこと 途中でスクリプトの実行が止まってしまう場合、実行をやり直す必要が出てきます。夜間に実行する場合、途中で止まってしまうと再実行は次の日となり時間ロスが大きくなります。 時間ロスをなくすためには実行エラーを無くし、実行する件数が多くても最後のシナリオまで実行が止まらないようにする必要があります。そのためには実行エラーを無くすことだけでなく実行エラーが発生しても次以降のスクリプトが正常に動くような対策があることなどとるべき対策があります。 1件1件のスクリプトが正しく動いても100件、500件とまとめた件数を一度に実行することで実行エラーが発生する場合もあるためスクリプト実装時のテストはまとまった数の実行確認を行い、問題が発生しないか確認する必要があります。 4. 実行結果の誤判定がないこと 自動化することで効率化を行う場合は、再試験を行わないように実行結果の誤判定があってはなりません。誤判定が1件でもあれば自動テストの試験結果の妥当性が危うくなり、品質の低い自動テストと見られればテストとして存在意義がなくなります。 結果の誤判定は効率的にテストを進めるためには実装段階で解決しておく問題です。ツールによっては必要な結果確認ができないものもあります。そのようなツールは自動テストの考慮から外しておくべきです。 100回実行しても100回正しく実行するようなスクリプトにする必要があります。運用段階でこの問題が発覚するとやり直しが発生するためテスト実施の進捗に影響するため、実装段階の確認で問題を曖昧にせず必ず潰しこんでおかなければなりません。 5. 実行から結果確認まで自動で実行出来ること 実行から結果確認まで自動化することでテスト全体を効率化する必要があると考えています。そうすることで担当者の作業は実行前の準備と実行、結果の確認だけになり作業の効率化が実現できます。 結果確認を自動化せず、1件1件ログを見て結果確認するようなことは避けなければなりません。100件程度なら人間で対応可能ですが1000件、2000件となると人間で対応していると非常に大きな工数になります。工数がかかるという以前に作業が回せなくなります。 そういった状況に陥らないためにすべてのスクリプトの実行結果に確認処理を入れ、テストケースへ結果入力まで自動で行う仕組みを入れておく必要があります。結果確認の処理は自動化するうえで必須の処理です。必要な結果確認ができない自動化ツールはツールの選定で初めから候補を外しておく必要があります。 6. メンテナンスの効率化の対策が入っていること 仕様変更は必ず入ると想定し対策を入れ効率化を行う必要があります。処理の共通化がその対策になります。処理の共通化を行うことでスクリプト作成の効率化が行えるだけではなく仕様変更や処理追加など変更時の修正工数が大きく削減することができます。また初期処理での条件設定、変数定義なども共通化しておくとよいです。 処理の共通化は自動テストの基本です。 以上の成功基準の基準を作りその基準に沿って自動テストを実装することが必要です。しかし実装だけでは長期の運用に耐えうる自動テストができるわけではありません。実装後の振り返り、もしくは定期的な運用の改善などのタイミングで基準をもとに現状を確認することで問題の有り無しの区別ができます。 振り返り時の成功基準の活用 成功基準を使った導入後の振り返りの例を説明します。 過去に私が経験したプロジェクトで振り返り時にこの基準を使った時の考察結果です。 No 導入基準 結果 結果詳細 1 手動に比べ30％以上の効率化/工数削減ができること ◎ 40％～80％の効率化が可能 2 自動化が必要なテストが選別できていること 〇 必要な機能は最大７０％自動化可能 3 実行途中で処理が止まらないこと △ 設定ミスで実行エラーが頻発 4 実行結果の誤判定がないこと △ 設定ミスで実行エラーが頻発 5 実行から結果確認まで自動で実行出来ること ◎ 一連の動作は全て自動化できている 6 メンテナンスの共通化の対策が入っていること ◎ 必要な対策は導入完了 成功基準と照らし合わせて考察してみた上記の場合、「 実行途中で処理が止まらないこと 」「 実行結果の誤判定がないこと 」の2点に問題があることがわかりました。要因を分析すると複雑な自動化システムの構造による設定ミスによる実行エラーが原因であることがわかりましたので、取るべき対策は設定ミスを減らすための「自動化環境の構造や設定項目の簡素化」が必要になります。実行担当者でのミスを減らすことで運用が改善できるため対策をとるべきであるということがわかりました。 上記のように成功基準があることで問題が具体的になり、目的に対してやるべきことが明確になりました。実装の際の基準だけでなく振り返りの際の基準としても使うことで、自動テストを成功に近づけることができます。 定期的に成功基準に基づいた振り返りを行い、目的に見合った自動テストになっているか運用で問題が発生していないかを確認すると良いです。 まとめ 目的を細分化した成功基準を作り、その基準をクリアできる自動テストの実装をすることが成功に必要なものです。成功基準があれば導入時のとるべき対策が明確になり、振り返り時に問題点が明確になります。自動テスト成功には必須なものといえるでしょう。 自動テストの実装はできたが運用が続かない場合、自動テストの成功基準をもとに自動テストの導入を行ってみてはいかがでしょうか。 連載一覧 【第1回】自動テストはなぜ失敗するのか？ 【第2回】TestArchitect for Mobileの動作検証 The post 【第3回】自動テストの成功基準｜6つのポイントをチェックする first appeared on Sqripts .

はじめまして。IAです。私はソフトウェア開発エンジニアとして7年のキャリアを積んだ後、現在はQAエンジニアとして働いています。 今回はなぜ私が開発エンジニアからキャリアチェンジしたのか、キャリアチェンジしたことで得たことは何なのかを紹介したいと思います。 私のキャリアとキャリアチェンジした背景 まず、開発エンジニア時代の私のポジションと、現在のQAエンジニアとしてのポジションを簡単に説明します。 ソフトウェア開発エンジニア時代 組み込みアプリケーション開発（要件定義～結合テスト） 業務アプリケーション開発（基本設計～単体テスト、結合テスト） QAエンジニア テスト設計・テスト実装・テスト実施（システムテスト） テスト見積り・テスト計画の作成ができるように学習中 次に、キャリアチェンジを決断した背景には自身の希望と業界の動向の両方があります。 自身の希望 自分の取得技術が固定化することを避け、新たなスキルを取得し自己成長を目指したためです。 元々、専門性を高められることよりも幅広い分野で活かせることが魅力的だと考えIT業界を志望していました。最初は開発エンジニアとして開発業務を行っていましたが、特定の技術分野や業務に集中した開発が続いており、新たなスキルや実績を積むという点について限界を感じていました。そこで、より広範囲の分野にアクセスしスキルを取得できる職種を探していました。どのソフトウェア開発においても必要なテストという領域であるという点と、幅広いジャンルや新しい技術に携われそうというイメージからQAエンジニアという職種に興味を持ちました。 業界の動向 ソフトウェアを量産する時代から高品質の時代への転換で、QAエンジニアの需要が高まっているため。 開発者としての経験がQAエンジニアに活かせたこと ソフトウェア開発でのテスト経験がある キャリアチェンジ後、QAエンジニアとして最初に行った業務がテスト設計でした。 開発エンジニアの時代に開発工程の一環として単体テスト・結合テストの工程を担当したことがあります。組み込みアプリケーション開発の単体テストではフローチャートをベースにコード単体テストの設計・実施を行い、業務アプリケーション開発ではコード単体テスト及びモジュール間結合テストの設計、実施を行いました。 これらのソフトウェア開発でのテストの経験があったことで、分岐や境界値など開発者目線でテストをして欲しいであろう箇所を速やかに理解することができました。さらに入社時に行われるテスト設計者研修に参加することで、そのテストを行うために有効な手法が何かを学ぶことができたため、開発未経験者よりも深くテスト設計について理解できたと感じてます。 ソフトウェア開発の流れを理解している ソフトウェア開発フロー全体を通じた見識がありました。特に私はウォーターフォールモデル型開発を経験していたため、要件定義や基本設計書の各工程で行われる具体的な設計内容や、対応するテストについての具体的なイメージが元からありました。この経験を基に対応する工程に合わせたレベルのテスト設計を行うことができました。 QAエンジニアとして得られたこと（経験・知見・新たな視点など） 開発者からQAエンジニアに転職したことでソフトウェアの品質という側面から顧客に貢献することができ、開発者とはまた違った仕事の達成感を感じています。業務アプリケーションやWebサイト、スマートフォンアプリ等の幅広い種類のシステムに触れ、各システムの特徴を考慮して有効なテストアプローチを考えることができました。開発エンジニア時代には触れることが無かったソフトウェア環境のテストを行うこともあり、新しいスキルを身に着ける機会も得られました。 また、テスト設計を行うに当たり、ユーザー観点について意識を改めることができました。 単体テストや結合テストの観点の大部分は要件定義書や機能仕様書に記載されている事であったのに対し、QAエンジニアで実施するシステムテストやUATでは、ユーザーにとって使いやすいシステムになっているか等のユーザーの立場に寄り添った観点も汲み取る必要があったため、意識を改めることができました。 開発者視点から切り替えてテスト設計をすることは大変でしたが、ユーザーに意識を向けることでユーザーの満足度を高められるように努力しました。 さらに、テスト設計をするときは誰でも同じ結果が得られるテストケースを用意することが求められます。テスト設計者と実施者は別であることがあります。そのためテスト設計を行う際は具体的な操作や期待結果を詳細にわかりやすく記述することで、一貫性と再現性を保つテストを行うことができるよう意識しています。 キャリアチェンジを考えている開発エンジニアに向けて ソフトウェアに高い品質が求められるようになった今、品質を保証するQAエンジニアの存在は非常に重要になると思われます。 キャリアチェンジを考えている開発エンジニアの皆さんにとって、テスト設計・実施の経験を活用し適切なテストを設計することができる点や、開発者としての知見から顧客の開発環境を理解し改善するためのアドバイスもできる点から、QAエンジニアは新たな可能性を秘めた道であると思います。 最後に、QAエンジニアを目指す方に是非学んで欲しい資格を紹介します。 [ JSTQB Foundation Leve l] こちらはソフトウェアテストの基礎レベルの資格です。テストに特化した専門資格で、テストで扱う手法や用語について広く学ぶことができます。 この記事をもとに、今後QAエンジニアを目指す皆さんの参考になれば幸いです。 The post 開発エンジニアの新たな道：QAエンジニアへのキャリアチェンジ first appeared on Sqripts .

振る舞い駆動開発(BDD)は品質向上や、テスト自動化の役に立つアプローチです。またアジャイルなソフトウェア開発やプロダクト開発に取り入れるのもとても有効ですが、期待できる効果は少し違ったものになります。本記事ではアジャイルコーチとして、アジャイルなチームにBDDを紹介するという立場で、働きや効果について考えてみます。 なおBDDについての素晴らしい解説をブロッコリーさん(風間さん)が執筆されています。BDDとはなにか、基本から使い方まで丁寧に説明されているので、ぜひそちらを参考にしてください。本記事では、TDDとの違い、SbE、「発見・定式化・自動化」のプロセスについて、理解されている前提で書いていきます。 TDDとBDD/ATDD(1)　TDDはテスト手法ではない コミュニケーションツールとしてのBDD BDDは「機能を開発する前に振る舞い(テスト)を書く」という点でTDD (テスト駆動開発) に似ています。何を実現すればいいのか、どんな機能が求められているのか、明らかにしてから作業を進めるというものです。作るものを具体的に決めるので、ゴールが明確になり、作るものがブレたりムダなことをしないというメリットがあります。 同時にBDDは利用者やビジネスユーザーといった、開発者ではない人、すなわち使う人の観点から望ましい振る舞いを定義します。同時にその定義を開発者や技術者、すなわち作る人から見ても自明なように書き下すという、コミュニケーションを促進するツールという側面があります。 アジャイルな開発においては使う人と作る人の意思疎通が欠かせません。アジャイル宣言の背後にある原則にもあります。BDDはそこを強化する効果があるわけです。 ビジネス側の人と開発者は、 プロジェクトを通して日々一緒に働かなければなりません。 アジャイル宣言の背後にある原則 使う人がほしいものを表現したり、作る人が作るものを記述するやりかたはたくさんあり、BDDはそのひとつです。BDDには特に、以下のような強みがあります。 使う人と作る人が一緒に働く場を提供する 成果物である定式化した振る舞いが、使う人と作る人の共通の言語で表現される 振る舞いをそのまま自動化でき、テスト資産になる 使う人と作る人が協働して進めるBDDは、以下のステップで進みます。 多様な利用者や開発者が協力して、ほしいものを「発見(Discovery)」する ほしいものを具体的に「定式化(Formulation)」する。開発者にとっては達成すべきゴールとなり、利用者にとっては実現を約束された内容になる 開発者は、自分たちが作ったものがゴールを満たすか客観的に判定できる   (「自動化(Automation)」すれば判定が圧倒的に容易になるが、必須ではない) 利用者は開発者が提供したものを確認するとき、約束は満たしていると信頼できる。そのため他の点を確認すればよくなる   (自動化は必須ではないが、されていれば約束通りかどうか信頼しやすくなる) 利用者の期待と異なる点があったら、そこから新たな「発見」につながる 約束は” 契約 “と呼んでもいいかもしれません。ひとつの機能の一部だけかもしれませんが、作る人が作るもの、使う人が受け取るものについて双方が守るべき” 契約 “です。この考え方を広げて適用すると、ATDD(受け入れテスト駆動開発)に近づいていきます。 複数のメンバー、とりわけ異なるスキルや背景を持った人々が協調するのがアジャイルの要諦です。BDDはそこに効きます。一般に要件定義と呼ばれるプロセスを、協調作業にできるのです。モブプログラミングあるいはモブワークのやり方も向きます。 協調し会話するためには、お互いに通じる言葉がないと不便です。様々な立場の関係者が共通の語彙として使えるユビキタス言語があれば、効果的な会話ができます。BDDのテストはユーザーの言葉で記述し、開発者がそれを実装の言葉に翻訳するので、自然とそこにユビキタス言語が作られていきます。 開発者どうしのコミュニケーションにもBDDが役に立つ BDDで振る舞いを定式化して記述すると、開発のゴールができあがります。開発者がチームとして協力するとき、ゴールがはっきりしていると作業計画づくりをしやすくなり、分担や連携の切り口もわかりやすくなります。振る舞いが一連の操作をシナリオとして表現していると、どれだけ完成したか進捗も把握しやすくなります。 開発しているプロダクトが複数のレイヤーで構成されていると、開発者もレイヤーごとに担当を分けることが多くなります。ユーザーから見た振る舞いはすべてのレイヤーを縫い合わせるように動作するため、担当者同士の連携ポイントを提供します。一部のレイヤーの開発が進んだり遅れたりしていても、すぐに気がつけるわけです。 またレイヤーごとに開発するとき、レイヤーごとに単体テストをするためのテストケースやテストデータが必要となります。担当者それぞれに適当なデータを作ると、認識違いや検討漏れが出る場合があります。BDDの振る舞いに具体的な値を含めておけば(SbEのアプローチ)、共通のテストデータができます。SbEについて、詳しくは ブロッコリーさんの連載の第3回 を参照してください。 TDDとBDD/ATDD(3)　BDDとATDDとSbE BDDで表現する要素としない要素 BDDでは振る舞いとして作るもののゴールを表現できます。ただしBDDでは捉えにくいものもあります。以下に、BDDで表現できる要素と表現しにくい要素を整理しました。 表現できる 機能要件 BDDは振る舞いを中心にテストを構築するため、具体的な機能要件を捉えやすい ビジネスルール BDDシナリオはビジネスプロセスやルールを表現するのに適しており、これらを明確にする ユースケース ユーザーの視点からの要件や期待をシナリオ化し、テストを行うことができる 表現しにくい アウトカムやインパクト ユーザーの行動変化や長期的な影響は、プロダクトの直接的なテストにはならない アーキテクチャや内部品質 システムの内部構造やコード品質は、外部から見た振る舞いで表現できない 非機能要件（パフォーマンス等） パフォーマンスやセキュリティなどの非機能要件は、振る舞いとして捉えにくいものがある ユーザーインターフェースの詳細 UIの見た目要素や細かい操作方法などは、BDDでは無視した方が取り扱いやすい 技術的な制約や依存関係 特定の技術的制約や依存関係は、テストシナリオでは表現しにくい メンテナンスや運用の要素 機能として表現されないメンテナンスや運用の要素はカバーしにくい (運用機能として作るものならできる) 表現しにくいものは、別の方法でゴールを記述したり共有したりする工夫が必要になります。頑張ればBDDで実現できるかもしれませんが、おそらく他にもっと効果的な方法があります。自分たちのプロダクトと状況に合わせて、BDDが向くところを選ぶようにします。 試行錯誤をコントロールするBDD アジャイルな開発に限らず、スピードを重視して開発しているとき、ムダなことはやりたくありません。使う人の要望が分かりきっているならそのまますぐに作りたいですし、不確実性が高いなら試行錯誤を効果的かつできるだけ頻繁にやりたくなります。望まれていないものを作るのはムダです。不確実性が高いときには試したいポイントが不明瞭だとムダが発生しやすく、またコミュニケーションやドキュメントも余分に過ぎるとムダになります。 分かりきっていることはどう表現し、伝えればいいのでしょうか。試行錯誤するとき、何を試すのかはどう表現するのでしょうか。ここでBDDが使えます。 BDDで振る舞いをテストケースとして定式化します。ここに書かれているのは、求められていることです。ここには書かれていないこともたくさんあります。それは都合よく解釈すればいいのです。都合よくというのは、ランダムや勝手ではありません。いまの状況で求められている通りにしつつ、開発者にとって最もムダがないようにするのです。 業務システムのデータ入力機能なら、決まり切った項目をすべて正しく登録できるという、たくさんのステップを書いたテストになります。すべてのデータ項目を網羅しないといけないし、バリデーションもテストしたいでしょう。 いっぽう、ECサイトの商品検索にAIを組み込む機能開発を考えてみると、話が違ってきます。おそらく実証実験段階で、さまざまな使い道とその実現可能性を検討したいはずです。このときBDDでテストしたいのは1テストケースでひとつの点のみです。「関連する商品がヒットする」「文意を汲んで結果に反映する」「売りたいものが上位に出る」などを確認したいわけです。検索の細かな手順や例外系、異常系は、今は関心の対象外です。関心がない点は、作る人が都合よく、早く出来上がるように作ればよい。エラーになったらクラッシュしても構わないわけですね。 一発で完全な品質の完成品を狙うのなら、そのように作ります。試行したい要素以外は関係ないのであれば、できるだけ省略し簡素にすませます。こうしてムダを省きます。その度合いを、定式化した内容の詳細さや網羅性でコントロールできるというわけです。 定式化した振る舞いを、約束や契約として考えるという話をしました。品質の高いものが求められるなら、網羅的で細かい点まで記述した契約になるでしょう。試行錯誤の一環でとにかく早く試したいなら、その試すこと以外は契約に含めず、大部分を開発者の裁量に任せる簡潔な契約になるでしょう。 約束や契約と言われると、詳細まで完璧に網羅するのが正しいという気がします。しかしコミュニケーションツールとして考えれば、そのときどきに応じて伝えたいことを適確に伝えるのが正しい使い方になります。協調するのに必要十分な詳細さ、あるいは曖昧さを選んでください。 このこともアジャイルソフトウェア開発宣言にありましたね。 契約交渉よりも顧客との協調を アジャイルソフトウェア開発宣言 本当にBDDのほうがスピードが出るのか スピードを求めるときBDDが役に立つと書きましたが、これは本当でしょうか。状況による、というのが答えになります。考え方として、いまの(BDDを用いない)やり方と、BDDを用いるやり方を比べて、ムダが少ない方が速いわけですね。ではいまのやり方にどんなムダがあるのか、それがBDDでは減るのか、プラスBDDで発生するコストはないか、検討することになります。 いちばん典型的で分かりやすいのは、手戻りのムダでしょう。開発者が作ったものが、利用者の思ったものと違ったり、実際に使ってみると問題があって、作り直さないといけない。これが利用者と開発者のあいだのコミュニケーション不足に起因するものなら、BDDで不足を補えるチャンスがあります。BDDの発見プロセスに利用者と開発者の両者が参加するのでコミュニケーションそのものの労力は増えますが、そのおかげで手戻りや作り直しが減れば、トータルでペイできそうです。 利用者がほしいものを説明できない、言語化に苦労するような場合には、BDDやSbEのアプローチで楽に記述できるかもしれません。抽象的な仕様をMECEに書き下すのにはそれなりのスキルや経験が必要なので、そのせいでコミュニケーションのムダが発生しているなら、BDDで効率化できるかもしれません。 作りすぎのムダも、BDDで減らせるかもしれません。一般的な仕様書の書き方では「このときはどうなってもよい」「ここは好きにしていい」とはあまり書きません。そうすると、どうなってもいいんだけどな…と思いつつ、何か決めて仕様書に書くことになります。作る人から見ると、仕様書に書いてあればすべてかならず実現するしかありません。選択肢はありません。 このとき、もっと低コストで実現できる仕様にすればムダが減ります。開発者はいちばんムダの少ない実現方法を選べるかもしれません。また、今の時点では不要な部分を実装しないですませれば、これもムダを減らせます。「任せる」や「今はどうでもいい」という表現、コミュニケーションを許容するために、BDDが役に立つかもしれません。 すべての機能をBDDで作ろうとすると、コストがかかりすぎるかもしれません。仕様を表現する方法はBDDだけではないので、今のやり方で十分ムダなく作れるなら、BDDを選ぶメリットはないかもしれません。上記のムダが発生しそうな箇所のみBDDを適用すれば十分です。機能で選ぶ手もあるし、仕様を把握しているのが誰かによって選んでもいいでしょう。テストを記述したり自動化するのが得意な人が担当する部分だけBDDにする作戦もあります。 BDD≠E2E BDDで「自動化(Automation)」まで取り組むならば、自動化のコストも重要な要素です。TDDに比べるとBDDのほうがテストを実行するためのレイヤーが増えがちで、インフラや仕組みなどを準備して自動化にこぎ着けるまでの作業は多くなります。また個々のテストを自動化する際も、ステップ実装まで含めた手間がかかります。テスト自動化によって開発工数全体を削減しようと思うと、BDDはハードルが高いかもしれません。 BDDは使う人の観点からふるまいを記述するので、テスト自動化のテクノロジーとしてはE2Eテストになりがちです。しかしE2Eテストは実装やメンテナンス、また実行コストも高くなります。BDDだからといってE2Eテストにする必要はないと、頭を切り替えましょう。ビジネスロジックに関する振る舞いであれば、ロジックを実装している箇所のユニットテストとして実現できるかもしれません。シナリオテストであれば、バックエンドのAPIテストで十分かもしれません。 おわりに BDDのプロセスの最初に「発見」があります。BDDをコミュニケーションツールと考え、ここを使う人と作る人の協調作業にするのが、とりわけアジャイルな開発におけるBDDの大きなメリットです。シフトレフトという言葉で考えれば、「仕様を考えるところ」まで左に持って行くことになります。逆に言うと、仕様が決まった後でBDDを利用するのでは大きなメリットを捨てることになります。 BDDの定式化で書く内容を増減して作る内容をコントロールできます。しっかり書けばしっかり作ることになり、軽く書けば軽く作れるので、いま現在大事なことにフォーカスしやすくなります。もちろん最終的にはすべてを完全な品質で作るわけですが、いま必要なことをいまやり、後でやればいいことを後に回して、時間を味方につけるのがアジャイルな計画づくりです。 アジャイルコーチからアジャイルチームにBDDを紹介するという内容で、本記事を書いてきました。BDDがみなさんのセンターになったら嬉しいです。 The post BDDはアジャイルに向く ― アジャイルコーチから見たBDD first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまさです。 前回 のVSCodeでgithub copilotを使った開発効率向上の話に引き続き、今回はVSCodeでGenieAIという拡張機能を用いてコード品質を高める手法のご紹介をしたいと思います。 OpenAIのAPIキーが必要になりますが、こちらも開発を強力にサポートしてくれるツールです。 GitHub Copilotを使ってみたら開発効率が劇的に向上した話 GenieAIとは GenieAIはVSCodeの拡張機能の一つでChatGPTを利用したAIアシスタント機能を提供する拡張機能です。 主な機能は以下の通りです。 コード補完: 開発者がコードを入力する際に、文脈に応じた最適なメソッド名や変数名といったコード補完候補をリアルタイムで提示します。コーディング速度の向上が期待できます。 テスト実装: 既存の関数やメソッドに対して、入力値や期待出力を考慮したテストケースをAIを用いて生成します。テスト駆動開発を強力にサポートします。 バグ検出: AIによるコード解析により、論理エラーや例外処理漏れなどのバグを即座に検出し警告を出します。手戻りの削減につながります。 コード最適化: パフォーマンスボトルネックやメモリ使用量の改善点を特定し、アルゴリズム変更やコード修正を提案します。効率的なコードへのリファクタリングを支援します。 コード解説: 複雑な処理の流れやクラスの設計意図などを、選択したコード部分に対して自然言語で丁寧な解説を生成します。コード理解を加速します。 コメント生成: コードファイルや関数に対して適切な概要説明やインラインコメントを自動で付与します。ドキュメント作成作業の軽減に寄与します。 GenieAIはAnthropic社が開発した新しいAIアシスタントで、VSCodeとChatGPTを連携させることが可能になっています。生産性向上やコーディング作業の効率化に有用なツールといえます。 GenieAIのインストール GenieAIはVSCodeの拡張機能ですので、一般的な拡張機能と同様に以下のようにしてインストール可能です。 これでGenieAIのインストールは完了です。 GenieAIは内部的にOpenAIのAPIを利用しているため、利用時にはOpenAIのAPIキーの入力がもとめられます。こちらには利用中のOpenAIのAPIキーを入力してください。 またGenieAIの各機能を実現するためのプロンプトは初期は英語で設定されているため、こちらを出力結果が日本語になるようにプロンプトを変更しておくことをオススメします。 プロンプトの変更は以下のようにして行うことができます。 GenieAIの設定画面が表示されます。 上記で表示した設定画面内の各プロンプト設定項目を以下の例のように変更します。 ※こちらは設定例ですので各種任意のプロンプト内容でOKです。 Genieai › Prompt Prefix: Add Tests: 「 以下のコードに対するテストコード実装を生成してください 」等 Genieai › Prompt Prefix: Find Problems: 「 以下のコードの問題点を日本語で指摘してください 」等 Genieai › Prompt Prefix: Optimize: 「 以下のコードを最適化してください 」等 Genieai › Prompt Prefix: Explain: 「 以下のコードの内容をわかりやすく日本語で解説してください 」等 Genieai › Prompt Prefix: Add Comments: 「 以下のコードに対して適切なコメントを日本語で追加してください 」等 Genieai › Prompt Prefix: Complete Code: 「 以下のソースコードに対して適切にコード補完してください 」等 このように設定することで日本語での利用がしやすくなります。 各機能を試してみる コード補完 GenieAIのコード補完機能は、開発者がコードを入力している最中に次に入力する可能性が高いコード候補をリアルタイムで提示する機能です。 例として以下のようなコードを記載します。 # 配列データ内のnumdataを合計して返却する関数 def sum_numdata(jsdata): if __name__ == "__main__": jsdata = { [ {"strdata": "a", "numdata": 11,}, {"strdata": "b", "numdata": 21,}, {"strdata": "c", "numdata": 16,}, {"strdata": "d", "numdata": 41,}, {"strdata": "e", "numdata": 15,}, ] } 上記は不完全なコードですが、関数「sum_numdata」でメイン内での配列データjsdata内のnumdataを集計して合計数を出力する予定です。この状態で以下のようにVSCode上で操作を行います。 コードを全て選択し右クリックして表示されるコンテキストメニューで選択します。 するとGenieAIのコード補完機能によりサイドバーに補完されたコードが出力されます。 実装しようとしていた関数の内容が実装され、メイン内の変数の定義も最適化されています。 この状態で以下のようにすることでエディタに補完されたコードが反映されます。 補完により作成されたコードは以下のようになりました。 # 配列データ内のnumdataを合計して返却する関数 def sum_numdata(jsdata): # 合計値を初期化 total = 0 # 配列内の各要素についてループ for item in jsdata: # numdataの値を合計値に加算 total += item["numdata"] # 最終的な合計値を返却 return total # メイン実行ブロック if __name__ == "__main__": # 辞書ではなくリストとしてjsdataを定義 jsdata = [ {"strdata": "a", "numdata": 11}, {"strdata": "b", "numdata": 21}, {"strdata": "c", "numdata": 16}, {"strdata": "d", "numdata": 41}, {"strdata": "e", "numdata": 15}, ] # 関数を呼び出し、結果をprintで表示 result = sum_numdata(jsdata) print(f"合計: {result}") # 出力: 合計: 104 コード補完を用いることでAI側でコード実装を予測し、実装しようとしていたコードを作成してくれるという例です。利用シーンによっては大いに工数を削減できる可能性があります。 テスト実装 GenieAIのテストコード生成機能は、既存のコードから自動的にテストコードを生成してくれる機能です。ここでは先程のコード内の関数「sum_numdata」に対するテストコードの生成を行ってみます。 関数「sum_numdata」を選択し右クリックして表示されるコンテキストメニューで選択します。 サイドバーに生成されたテストコードが出力されます。 生成されたテストコードは以下のようになりました。 import unittest # 配列データ内のnumdataを合計して返却する関数 def sum_numdata(jsdata): # 合計値を初期化 total = 0 # 配列内の各要素についてループ for item in jsdata: # numdataの値を合計値に加算 total += item["numdata"] # 最終的な合計値を返却 return total # テストケースクラスを定義 class TestSumNumdata(unittest.TestCase): # 正しい合計を返すかテスト def test_sum_numdata_correct(self): data = [ {"strdata": "a", "numdata": 10}, {"strdata": "b", "numdata": 20}, {"strdata": "c", "numdata": 30}, ] result = sum_numdata(data) self.assertEqual(result, 60) # 期待される合計値は60 # 空のリストが渡された場合、0が返るかテスト def test_sum_numdata_empty(self): data = [] result = sum_numdata(data) self.assertEqual(result, 0) # 期待される合計値は0 # numdataキーがない場合の例外処理が適切かテスト def test_sum_numdata_missing_key(self): data = [ {"strdata": "a"}, {"strdata": "b", "numdata": 20}, ] with self.assertRaises(KeyError): sum_numdata(data) # テストランナーを実行 if __name__ == '__main__': unittest.main() 単純なテストだけでなく準正常系等のテストコードも生成してくれます。不足分があるなどいう場合には下記のように追加の生成要求も可能です。 サイドバーに追加のテストコードと説明が出力されます。 以下のようなコードが生成されました。 # numdataに文字データが含まれている場合のテストを追加 # numdataに非数値データが含まれている場合にTypeErrorが発生するかテスト def test_sum_numdata_non_numeric(self): data = [ {"strdata": "a", "numdata": "10"}, {"strdata": "b", "numdata": 20}, {"strdata": "c", "numdata": 30}, ] with self.assertRaises(TypeError): sum_numdata(data) またテストコードの生成だけではなく対象の関数の修正提案もしてくれています。 (なぜか中国語が混じってしまっているようですが。。) def sum_numdata(jsdata): total = 0 for item in jsdata: try: # 确保只把数字类型的数据加到总和中 total += int(item["numdata"]) except ValueError: # 如果转换为整数失败，抛出TypeError raise TypeError(f"Expected a numeric value for 'numdata', but got '{item['numdata']}' instead.") return total 自身の記述したテストコードに加えて、こちらで出力されるテストコードも追加するといった使い方をすることでテストを充実させ、よりコードの保守性を高めることができるようになります。 バグ検出 GenieAIのバグ検出機能は、コード中の潜在的なバグをAIが自動的に特定して開発者に警告する機能です。実際にコードで試してみましょう。 import random # メイン実行ブロック if __name__ == "__main__": RETRY_MAX = 5 retry_count = 0 do_retry = True while do_retry: x = random.randint(1,10) if x == 5: print("ok.") else: retry_count += 1 if retry_count > RETRY_MAX: raise Exception("retry error, x is not 5.") print("complete.") コード全体を選択し右クリックして表示されるコンテキストメニューで選択します。 サイドバーにコードの問題点が出力されます。 上記のとおり、コードにはループが終了しない問題がありましたが、その問題を丁寧に指摘してくれています。対処法も説明してくれていますので修正も容易です。 今回は割と明らかなミスでしたが、そうでない場合でもよりセーフティなコードになるような提案をしてくれたりと、よりコードの品質が高まるように補助してくれます。 最適化 GenieAIのコード最適化機能は、開発者のコードをAIが解析し、実行速度やメモリ使用量といったパフォーマンスを向上させる提案をしてくれる機能です。 先程のコードを少し修正したものを対象に実行してみます。 import random # メイン実行ブロック if __name__ == "__main__": RETRY_MAX = 5 retry_count = 0 do_retry = True while do_retry: x = random.randint(1,10) if x == 5: print("ok.") do_retry = False else: retry_count += 1 if retry_count > RETRY_MAX: raise Exception("retry error, x is not 5.") print("complete.") コード全体を選択し右クリックして表示されるコンテキストメニューで選択します。 最適化されたコードと解説が出力されます。 最適化されたコードは以下のようになりました。 import random # メイン実行ブロック if __name__ == "__main__": RETRY_MAX = 5 retry_count = 0 while True: # 無限ループ x = random.randint(1, 10) if x == 5: print("ok.") break # ループを抜ける else: retry_count += 1 if retry_count >= RETRY_MAX: # `> RETRY_MAX`から`>= RETRY_MAX`に変更 raise Exception("retry error, x is not 5.") print("complete.") こちらの例ではフラグ変数を使わずにbreak文でループから抜けるように修正し、よりシンプルになるように最適化してくれました。 パフォーマンスに関わる部分などでも適切に提案してくれますので、細かく活用することで可読性と性能改善に関しての品質向上が期待できます。 コード解説 GenieAIのコード解説機能は、開発者が選択したコードスニペットに対して、その処理内容や意図を自然言語で解説してくれる機能です。 例として以下のようなコードに対して解説を実行してもらいます。 def sample(nums): n = len(nums) for i in range(n): for j in range(n-i-1): if nums[j] > nums[j+1]: nums[j], nums[j+1] = nums[j+1], nums[j] return nums nums = [5, 2, 4, 1, 3] print(sample(nums)) サイドバーにコードの内容の解説が出力されます。 上記のようにsampleという関数がバブルソートのアルゴリズムでソートしていることを解説してくれています。引数や仕組みについて細かく説明してくれるので非常に理解しやすいです。 主に他者のコードを扱うときのキャッチアップに大いに役立つと思います。このコードは何をしているのだろうというときにこちらを利用することで細かく理解できると思います。 コメント生成 最後はコメント生成機能です。GenieAIのコメント生成機能は、コード内に適切なコメントを自動で挿入することができる機能です。こちらもコード解説機能に近いですが、コード内に明確に説明が残るというメリットがあります。 例として以下のコードにコメントを付与してもらいます。 def fetch_user_data(user_id): user = db.find_user(user_id) if not user: return None transactions = get_transactions(user.id) sum_amount = 0 for transaction in transactions: sum_amount += transaction.amount data = { "user_id": user.id, "name": "{} {}".format(user.first_name, user.last_name), "total_transaction_amount": sum_amount } return data コード全体を選択し右クリックして表示されるコンテキストメニューで選択します。 サイドバーにコメントを付与したコードが生成されます。 コメントを付与してくれた結果は以下のようになりました。 def fetch_user_data(user_id): # ユーザーIDを元にデータベースからユーザー情報を取得する user = db.find_user(user_id) # ユーザーが存在しない場合はNoneを返す if not user: return None # ユーザーIDに紐づくトランザクション（取引）情報を取得する transactions = get_transactions(user.id) sum_amount = 0 # 取引の合計金額を算出する for transaction in transactions: sum_amount += transaction.amount # 返すユーザーデータを辞書形式で構築する data = { "user_id": user.id, # ユーザーID "name": "{} {}".format(user.first_name, user.last_name), # フルネーム "total_transaction_amount": sum_amount # トランザクションの合計金額 } # 構築したユーザーデータを返す return data わかりやすくコメントが追加されていますね。未定義の関数であっても名称と前後の流れから推測してコメントを付与してくれています。コメントの付与等は意外と工数がかかったりすることがあったり、人によりわかりやすいコメントのつけ方に悩んだりするものですが、こちらの機能を利用することで、そうした悩みも無くコメントを付与できます。 コメントもコードの品質において重要な要素の一つですので、こちらを利用することでまた一つコードの品質を高めることができたと思います。 その他 GenieAIは基本的にコードを選択し、そのコードに対してAIに操作をしてもらうというような処理を行っています。以下のようにすると上記以外に自由にAIに対して指示が可能です。 このように上部に自由にプロンプトを入力できるようになるので、ここにソースに対する質問や指示を指定することで、任意の処理をAIに依頼可能です。 まとめ いかがでしたでしょうか。GenieAIはGitHub Copilotよりも能動的にAIに処理を行わせることが可能です。特にバグ検出とコメント生成では、GitHub CopilotよりもGenieAIの方が使いやすさと生産性が高いと考えられます。 GenieAIなら人間の開発者が気づきにくいコード上の欠陥をAIが特定し、保守性の向上に役立てることができます。工数の削減と品質の向上を同時に実現できるため、ソフトウェア開発における生産性向上に期待できると思います。 開発者とAIアシスタントが協調して作業を進めるアプローチも、生成AIを最大限に活用する方法の一つではないかと思います。 The post GenieAIでコードの品質を高めよう｜VSCode拡張機能GenieAIを用いてコード品質を高める手法 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 ＜テストエンジニアのための論理スキル[再]入門　連載一覧＞ ※クリックで開きます [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT 今回の第5回から、「文レベルの論理の言葉」に焦点を当てて解説します。 長い文章も短い文のつながりで筋道がつくられています。ひとつの短い文の中にも構造があります（論理演算でつながれるような語句と語句との関係や、前提と結論といった関係など）。第5回・第6回は、そのような、一般的な文章の構造を支える「論理の言葉」を取り上げます。 文中では、一般的な文章や日常会話などで用いられる語句や表現を 一般語 と呼びます。 文や語句を否定する言葉、つなぐ言葉 「監視対象の いずれか が 異状を示していたら、緊急対応の判断を下す。そうでなければ引き続き状況を監視する」 「A、B、Cが すべて 見つかり、 かつ 良好な状態なら、合流地点に集合する」「どれかが見つからないか、 または 良好な状態で ない 場合は出発点に戻る」 etc. ……というように、 一般語でも論理演算（ 第3回 ・ 第4回 参照）に相当する言葉を使って主張を組み立てたり文を表したりします（そもそも、一般語の意味や働きから論理的側面を抽出して論理の言葉を作ったのですが）。 否定(NOT)に相当する一般語の例：　“～でない” 論理積(AND)に相当する一般語の例：　“かつ”、“および”、“ならびに”、（ほか、ANDの関係であることを明示する修飾語句） 論理和(OR)に相当する一般語の例：　“または”、“あるいは”、（ほか、ORの関係であることを明示する修飾語句） 一般語として使われる時は、「論理の言葉( 論理的な側面に焦点を当てた使い方 )」とは意味や働きがちょっと異なる場合があります。 言葉は同じものを使うだけに、意味の違いを識別するのが難しいこともあります。  文章の筋道を把握しようという時には 「どの意味で使っているか」に注意を向ける のが望ましいです。 ソフトウェアやシステムの仕様書といった文書類はソフトウェアの振舞いを規定/記述するのが目的ですが、書き手が「論理の言葉」を意識して使っているとも限りません。 “～でない”の留意点 論理としての否定は、全体を打ち消す 否定「～でない」は、「Aである」という主張や判断 全体の否定 であり、「A でないものや場合すべて 」を含みます。 「Aであるということはない」 という表現がニュアンスとしては“合っている”でしょうか。（図5-1） 図5-1　否定のベン図 「Aさんは朝食にパンを食べる」の否定は「Aさんは朝食にパンを食べる、 ということはない 」 「朝食を食べない」も含むし、「朝食には(パンでなく)白米を食べる」も含む 「Bさんは毎日朝の散歩をする」の否定は「Bさんは毎日朝の散歩をする、 ということはない 」 「朝の散歩を全くしない」も含むし、「朝の散歩をする時もある」も含む 「（項目Aは整数の入力項目につき）項目Aに整数を表す数字 でない 文字を入力すると警告される」 「整数を表す数字 でない 文字」には、英字、記号、漢字、平仮名、カタカナ、……などがある 一般語では、“反対の意”を表すことがある 一般語としての否定の表現には、「主張全体の否定」というよりは、もとの主張と反対のことを主張したり、感情や考えが込められることがあります。 「Cさんは若手に優しく ない 」は、「若手に厳しい」という意味に解釈されることがある 「Dさんは、鶏の唐揚げは好き ではない 」は、 「鶏の唐揚げは嫌い」や「食べたくない」というニュアンスが込められていることがある ほか、「今年の入学生は全員優秀 ではない 」、「その作家の作品は全部読んで いない 」、etc. 数値の範囲を表す表現の否定 否定そのものの話題ではありませんが、第3回で触れた「数値の範囲を表す表現の否定」への補足です。 一般語では、「以上」と「超」、「以下」と「未満」を“曖昧に”表し/解釈することがしばしばあります。 「より大きい(＝超)」の意味合いで「以上」と言う 「○○以上」の否定のつもりで「○○以下」と言う　etc. SNS投稿のまとめサイトですが、格好の例があります。 「なら何ミリでもダメじゃね…？」 松屋の丁度いい肉の厚さについて書かれた ポスターのキャッチコピーが難しい togetter この例のように気づきやすいとは限りませんし、逆に、“論理的”な意味で使われているのを設計者や実装者が「解釈違い」をしてしまう……という悲劇も起こる可能性があります。 “かつ”(AND)の留意点 暗黙の“かつ” 一般的な文章では、暗黙の裡に論理積(AND)と見なされる（読み手が見なす）場合があります。 ANDであることを明示する接続語などは使われていないが、文脈上「これらの条件を同時に満たすこと」が想定されている（と読み手が解釈しやすい）場合です。 典型的な例として、条件や事項の 列挙 数値の範囲を示す表現(「x以上y以下」など) 複数の連続する事象で、先行する事象が後続事象の前提となる場合( 第2回の「ファイルを1文字ずつ出力するプログラム」の例 ) 「暗黙のAND」と解釈できるからといって、その解釈が唯一で正しいとは限りません。 第1回の“例題”「遊園地のアトラクションの注意書き」 は、そのような表現になっています。 本アトラクションは以下の方のみ利用できます。 ・身長130センチ以上190センチ以下 ・体重90キログラム以下 ・年齢満15歳以上 これを最初にANDの関係と思って読んだ人は多いのではないでしょうか。しかし、この表現はORの関係として読んでも“妙なアトラクション”なりの条件と解釈はできるでしょう（「こんなのおかしい」「あり得ない」という感想は抱くかも知れませんが）。どちらとも明示されていない以上、どちらの解釈が“正しい”かはこの箇所だけでは判定できません。そして、どう解釈したかによって「そのアトラクションを利用できる人/できない人」の条件も変わってきます。（図5-2） 図5-2　3条件の AND? OR? ANDの関係であることを示す語句 論理積(AND)の関係を示すのに使われる語句はさまざまあります。 “そして”、“また”、“さらに”：　事項の列挙などで目にします。“そして”は時間的順序関係を意味することもありますが、ANDの関係には時間的な順序は含みません “だが”、“しかし”（など逆接の接続語句）：　逆接の前後が「ともに成り立つ」とした上での表現なので、ANDの関係になります 例「入力ファイルを開くことができるが、中身が空の場合」⇒ 「入力がファイルを開くことができ、かつ、中身が空の場合」 “または”(OR)の留意点 排他的な“または” 論理和(OR)の「どちらかが真」には「両方とも真」の場合も含まれますが（ 第3回参照 ）、一般語の“または”は「 AかBかどちらか一方のみが成り立ち、A, Bともに成り立つことはない 」という意味で使われることも多くあります。 「容疑者Xの逃走先は、札幌か、または沖縄だ」 札幌と沖縄に同時に向かうことはできない 「サービスの購入には、一括年払いか、または月払いのどちらかが選べます」 一括の年払いと月払いをともに選ぶことはできない この意味合いでの“または”を「 排他的な“または” 」と呼んで、論理和の“または”と区別することもあります。（図5-3。 論理和の“または”は「包含的」 とされます） 図5-3　論理和(左)と排他的な”または”(右) なお、「排他的な“または”」に相当する論理演算もありますが、論理和とは異なる演算です(真理値表が異なる)。 “ないし” 論理和(OR)を表す言葉として“ないし(乃至)”も使われることがありますが、“ないし”には二通りの意味があります。 “または”、“あるいは”と同義 数量・時間などの上下・前後の限界を示して、中間を省略する際に用いる （参考： goo国語辞書 ） むすび 一般的な文章でも使われるAND/OR/NOTに相当する言葉の、論理の言葉としての意味や使い方と、一般語としての意味や使い方、その違いや留意点を見てきました。普段はあまり意識することはないかも知れませんが、仕事で読み書きする時には注意しましょう。 第6回では、これまで出てこなかった「文レベルの論理の言葉」を取り上げます。 筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。 ■ 論理スキル・“入門編”のこと　(T3:Pt1:Ch01) よろしかったらご覧ください。 参考文献 『入門！論理学』(野矢茂樹 / 中央公論新社) 『論理的思考の技法〈1〉第2版　「ならば」をめぐって』(鈴木美佐子 / 法学書院) 『新版　論理トレーニング』(野矢茂樹 / 産業図書) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT The post [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第5話です。 前回 から引き続き、学び直し回です！ 書籍「基本から学ぶソフトウェアテスト」を読んで、現在でも活かせる内容があるのか？ないのか？会話形式でお話しさせていただきます。 最後まで楽しんで読んでいただけければ幸いです！ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 度重なる流行り病に体力が落ち、黄昏行く街の中、癒しを求めてさまよい続けてます。。。 くまねこ QA業界経験1x年のエンジニア。 ゆるっとジムに1年間通い続け、体重 -5 ㎏、体脂肪率 -6 %を達成。 ジムにいる本格的な方々に憧れ？、バンダナを着用して現れる。 イラストby くまねこ くまねこ、何かが違う…？ 今日も二人のやりとりをお楽しみください！ まだまだ学び直し！の旅は続く… ・・・（今日もジム行ってきたぞ…ウォーキングだけ！えらい！よくやったくまねこ！あっ、まーくーさんだ…何やら黄昏れてるぞ…昨日の疲れ引きずったままなのかなぁ…？ちょっとテンション高めに挨拶してみよう。）オゥイエァ！まーくーさん！お疲れ様ッスゥ～！(グータッチを求める) お、おう、おつかれ…（ちょこんとグー）どうしたんだい？何やら気合の入ったバンダナもして… 実はゆるっとジムに通ってまして、1年前と数値を比較したら結構効果が出ていたんですよ！通い始めはジムに着くなりすぐ帰ろうとしていたのですが笑、ゆるっと続けていたら週３ぐらいのペースに習慣化できてきました。さすがに本格的な方々ほど追い込めませんが、雰囲気だけでも出していこうと、バンダナを巻いています！イェア！ （何かのキャラも混ざっている…！？）そ、そっか、引き続き頑張ってね！（私もお酒に呑まれてぶくぶく太り始めたし…よし、気合を入れよう！）早速だけど、今回は前回の続きで学び直ししていくよ。書籍は我らが神の師匠が書いた本「 基本から学ぶソフトウェアテスト 」。今日は第1部の第3章と4章をやっていこうと思う！ Yeah～！ \ /（訳：まーくーさん復活したけど、学び直しを忘れてなかった～！） 第3章 テストの種類と位置付け を読んで まずは「本章のねらい」からですね。本章ではソフトウェア開発プロセスや用語、テスト技法について書かれているとのこと。そして、この書籍を読むのを辞めてしまう人は、大体この章で挫折してしまうと書いてあります…(( ))  (震えてみる) 本章を一読した感じ、注意書き通り全てを細かく理解するというよりも、全体を広く理解できるようにしていくと良さそうですが、どうしましょう？ ふーむ、そうだねぇ… (目が笑ってない＆小刻みに震えていて怖いぞ笑）。でも、下記のように書いてあるし、固く考えすぎずにまずは概要をつかめれば良いんだと思うよ。 ここでの目的は、プログラムの内部設計に関して、プログラマに基本的な質問が出来、回答の要点を理解することにある。 基本から学ぶソフトウェアテスト より そ、そうですね…(( ))（でもまだビクビクしている・・・フェンスに腰かけよう）。 じゃ、内容に入っていこうか。書籍に倣って開発・テストのプロセスレベル（計画段階／設計段階／コーディング／回帰テスト／ブラックボックステスト／保守）で一旦整理してみたよ。それぞれの概要を理解＆覚えられると良さそうだね。今日の会話で私たちが気づいたポイントを穴埋めしてみようか。 計画段階と設計段階のテストでは、レビューを用いて、正しさ、完全性、矛盾の有無、実現可能か、妥当か、テスト可能かという点について、レビューで検証する必要がある事を説明していますね。 特にウォーターフォール型開発だと、要求仕様や設計が完全ではなく漏れが有ったりすると、出来上がったものも不完全な状態になるからね。レビューの種類なんかは JSTQBFLのシラバス にもレビュー種類の記載があるね。シラバスだと非形式的レビュー（ペアレビューなど）も記載されているけど、こちらの書籍では当然やっている前提かな？ コーディングのテストについては盛りだくさんですね。 うん。ホワイトボックステストのメリットや、種類、それからメトリクスなど概要レベルだけど、記載が多いね。ミューテーションテストの考え方はこの本の頃からあったんだぁって、ちと勉強不足を感じたよ 回帰テスト、テストと修正では、回帰テストの性質や、テスト計画からテスト完了までの流れと、テストタイプについて記載されてますね。 テストタイプは15種類紹介されているね。状態遷移テストなんかなじみのテストタイプもあるし、テストタイプの復習にはうってつけかもしれない。 保守・機能拡張では、移植性テストについて記載されています。 DBの移植をした時、バージョン違いのDBにそのまま移植したらあちらこちらでプログラムが動かなくなったなんてこともあった ハードウェアやOSを変更したときには大事なテストだよね。 まとめるとこんな感じかな？ 【第3章テストの種類と位置づけ～まーくー＆くまねこまとめ～】 良い感じですね！「本章のねらい」でも書いてありましたが、自分なりに把握しやすいようにまとめていくとわかりやすいです。Mark’s Map！我々の経験したテストは、ブラックボックステストの範疇が多いですよね。 以前の記事 で書いた状態遷移テストもこの中に含まれますしね。 ゆるっと♪ファームウェアテストよもやま話 他にどの辺りが気になったかな？ やっぱりビッグバンテストのところの記載が痺れましたね！ ビッグバンテスト法ではシステムを完全に組み上げるまでモジュールもプロセステストしない。全部を同時にテストし、吹き飛ぶ時も全部いっしょなのだ。 基本から学ぶソフトウェアテスト より ふむふむふむふむふむふむふむふむ（テストの名前と結果が痺れるなぁ…） むむ…！これはまさに「今ウブなプロジェクトのBigbangで俺たちはヘロヘロになるぅ 」って感じだね！ Woooow！そしたらまーくーさんが最後に「いったいなんだったんだ…こんなテスト…こんなバグぅ…いったいなんだったんだ…きっとなにもかもがちがう！なにもかもちがう！なにもかもがちがう！Wooooooo～！」って言って取り乱して、もう一度Bigbang起こして宇宙を誕生させてください！（ニヤニヤ） オゥーケイ！（お、おっけーなのかなぁ？） 第3章はこのぐらいでしょうか。予定通り第4章まで、アクセル踏み込む感じですか？ Wow！退屈が見えない！行くぞ～！ Yeah～！ \ /（訳：ぎゃあ～！） 第4章 ソフトウェアエラー を読んで 第4章はエラー退治の獲物（ソフトウェアエラー）を13種に分類して記載されています。エラー退治…なんだか冒険に旅立つような気持ちです…アドベンチャー！ アドベンチャー！(笑)早速読み進めていこう！まずは「品質」って何ってところから説明しているね。 まーくーさん、ここの記載も痺れるぅうう！改めて気づかされますが、仕様通りなことを確認するだけのテストじゃあやっぱりダメなんですね！！！（ひえぇー） ソフトウェア開発者の顧客の多くは、このように知識があって、明確に仕様を定義してくれるわけではない。こういったソフトウェアを作る開発者にとって、製品やサービスの品質というのは顧客の満足度であって、仕様に合っているということでは決してない。 基本から学ぶソフトウェアテスト より そうだね。ソフトウェアの品質に関する国際規格SQuaREでは（ソフトウェア）品質とは以下のように定義されていて、ドキュメント通りに動作するからと言って品質が良いとは限らないんだよね。暗黙のニーズにも注意しないと、お客様に満足いただける品質（≒テスト）にはならないんだ。 「明示された状況下で使用されたとき、 　　明示的ニーズおよび暗黙のニーズを 　　ソフトウェア製品が満足させる度合い」 つながる世界のソフトウェア品質ガイド より 同じようなこと言ってますね(笑)現代にも受け継がれてる！！！ 次にソフトウェアのエラーについて記載されているね。この辺りの考え方は JSTQBFLのシラバス にも書いてあるし、両方読むことでエラーとは何かについて、より理解ができると思うよ。 そうですね。本書ではエラーは13種類に分類され記載されていて、読み返して理解していきたいと感じました。この部分を理解しておくことで、探索的テストやエラー推測テスト等のテストの引き出しとしても活用できると感じました。 Good！あと「テストに関するエラー」というところも気になったところだね。テスト担当者としては減らしたい「エラー」だけど、実際には操作を間違えていたけれど結果的に不具合で修正となるようなケースもある。また、本当にテスト担当者の操作ミスであったとしても、テスト担当者が間違えやすいインターフェースはユーザーが使用するときにも問題となるかもしれない、という考え方は良いなぁと思ったよ。 単なる「オペミス」だとテスト担当者としては恥ずかしいですけど、慎重に調べたうえで恐れずに報告できるようにしたいですね！ まとめ 今回は様々な用語が出てきて、新たに覚える部分が多いと大変に感じる章だったと思います。でも、まーくーさんがリスト化していたように整理して、繰り返し読んで理解することで、実際の業務の中でテスト種類ごとのポイントをおさえたテストが作成・実施出来たり、エラーを効果的に見つけられるようになれると思います。 そうだね。実際のところ、テストの種類や用語については現場によって表現が変わったりすることもあるけれど、本書の内容を自身の土台として理解しておくことは有効だと思うよ。今回もためになる情報を得ることができたね！俺たちはもっともっと学び続けて行かなければ…バーイ！ ﾉｼ 三 Yeeeeeeeeeeaaaaaaaaaah！ \ / 次回予告 基本編も残りは第5章だけだね。このままやっても良さそうだけど、第5章と第6章は障害関連だから、今回はここまでにしようか。次回はどんな感じかな？ 次回のまーくー＆くまねこは、 JSTQB ALTM試験、勉強してるの？まだでしょ！（仮） JSTQB ALTM試験、受けるかも？どうしましょ！（仮） 最後まで読んでいただき、ありがとうございました！よろしければ、過去のゆるっと♪シリーズもお楽しみください！次回もまた見てねー ﾉｼ 三 ﾉｼ 三 The post ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！②～あきらめてしまわないでね 難しさ感じても～ first appeared on Sqripts .

イベント概要 市場の不確実性・リリーススピードなどモノづくりにおける課題の多様化・仕組みの高度化など、開発現場では様々な変化が求められる時代になっています。もちろんテスト・QAにおいてもスピード感やAIの活用がより求められるようになってきています。 本イベントではQA業界のパイオニア3名が”アジャイル・AI時代における品質保証の今”というテーマで、そんな時代を生き抜くためのヒントを皆様にお届けします。 本イベントは AGEST Testing Lab の所長である高橋 寿一、研究に協力頂いている鷲崎 弘宜氏、そしてゲストスピーカーの平鍋 健児氏による研究発表となります。 QA業界のパイオニアの講演と立食形式での情報交換会による、 オフラインならでは の体験をお届けします。 ※1 アジャイル・AI時代を生き抜くための品質保証の知見と、共に学ぶ仲間とのつながりを得る貴重な機会をお見逃しなく！ ※1 オンライン配信はありません Sqripts会員限定でご招待！ 今回は当セミナーにSqripts会員のみなさまを抽選でご招待します。 ぜひご参加ください。 ご来場者特典 知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書(高橋 寿一 著) をプレゼント ▼ セミナー参加応募フォームはこちら Speakers 鷲崎 弘宜 氏 早稲田大学 グローバルソフトウェアエンジニアリング研究所所長、早稲田大学基幹理工学部情報理工学科教授、国立情報学研究所客員教授 コンピュータに関する世界最大の学会IEEE Computer Societyの次期会長（2025年 会長）を務めるとともに、情報処理学会ソフトウェア工学研究会主査を務め、ソフト ウェアエンジニアリングや関連技術の展開を国内外でリード。研究室では産学官連携ならびに国際連携を通じてビジネスと社会のための知的ソフトウェアエンジニアリングの研究、教育、実践、社会実装を推進。ソフトウェア解析や品質評価・高信頼化、再利用および機械学習応用を得意とし、それらの適用を通じての要求から設計、実装、テスト・検証、運用・保守、ビジネス接続、さらには情報教育・人材育成まで幅広く成果を上げている。 平鍋 健児 氏 ＜ゲストスピーカー＞ 株式会社 永和システムマネジメント 代表取締役社長、株式会社チェンジビジョン 代表取締役CTO、Scrum Inc.Japan 取締役 1989年東京大学工学部卒業後、UMLエディタastah*の開発などを経て、現在は、アジャイル開発の場、Agile Studio にて顧客と共創の環境づくりを実践する経営者。 初代アジャイルジャパン実行委員長、著書『アジャイル開発とスクラム 第2版』（野中郁次郎、及部敬雄と共著） 他に翻訳書多数。 DXを加速するアジャイル ～変化を味方にしたチームづくり～　プロローグ１ — 平鍋健児氏とアジャイル 高橋 寿一 情報工学博士　株式会社AGEST チーフ技術アドバイザー、AGEST Testing Lab.所長、AGEST Academy学長 フロリダ工科大学大学院にてCemKaner博士(探索的テスト手法考案者）、JamesWhittaker博士(How Google Tests Software著者）にソフトウェア品質の指導を受けたあと、広島市立大学にてソフトウェア品質研究により博士号取得。 Microsoftシアトル本社・SAPジャパンでソフトウェアテスト業務に従事、ソニー(株)ソフトウェア品質担当部長を経て、現在は株式会社AGEST チーフ技術アドバイザー、AGEST Testing Lab.所長及びAGEST Academy学長を兼務。 日時・場所 日時： 2024年3月7日（木曜日）15:00～18:00（Door Open 14:45） ※講演は15:00-16:55 その後立食形式の情報交換会を17:00-18:00で開催します 場所： 帝国ホテル東京　本館2階 蘭の間 〒100-8558東京都千代田区内幸町1-1-1 交通アクセス： 帝国ホテル東京「アクセス」ページ タイムテーブル 15:00-15:05 開会挨拶 15:05-15:45 鷲崎 弘宜 氏 講演 アジャイルメトリクスの全体像と利用者・顧客満足に向けて 15:45-16:25 平鍋 健児 氏 講演 デジタルビジネスの潮流とアジャイル開発〜ビジネスとエンジニアの協働チームづくり〜　　　　　　　　 16:25-16:55 高橋 寿一 講演 AI時代のソフトウェアテスト入門（シフトレフトするの？シフトライトするの？） 16:55-17:00 休憩・移動 (本館2階　牡丹の間) 17:00-18:00 情報交換会 (立食形式) 18:00 閉会 ▼ セミナー参加応募フォームはこちら 募集要項 応募資格 2024年2月21日（水）19時時点で参加応募フォームからのお申込みかつ、 Sqripts無料会員の登録が完了していること 応募方法 下記「セミナー参加応募フォーム」に入力の上ご応募ください。 Sqripts会員未登録の方は、応募フォーム入力後画面より無料会員登録をお願いします。 （Sqripts無料会員登録は こちら ） 応募期限 2024年 2月 21日（水）19時00分 定員 50名（応募多数の場合は抽選） 参加費 無料 来場者特典 知識ゼロから学ぶソフトウェアテスト 第3版 アジャイル・AI時代の必携教科書(高橋 寿一 著) をプレゼント 当選発表 抽選結果は2月下旬にメールでご連絡します ご案内 当日参加される方は、お名刺を2枚ご持参ください セミナー参加応募フォーム MktoForms2.loadForm("//lp.agest.co.jp", "730-KXO-656", 1808); お問い合わせ先 当セミナーに関するお問い合わせ先 株式会社AGEST　マーケティング本部 Mail： ml-mk_web@agest.co.jp The post ◆Sqripts会員をご招待◆3.7開催｜QA業界のパイオニアが語る！アジャイル・AI時代の品質保証の今 first appeared on Sqripts .

このシリーズでは「組織におけるパスワード管理」をテーマに、パスワード管理の重要性、危険性、攻撃に対する備え、ベストプラクティスについてお伝えしていきます。 第1回は、パスワードの基礎知識と主な管理手法について解説します。 パスワードの基礎知識 「パスワード」とは、最も長く、また最も多く利用されている認証要素の一つです。主な利用方法としては、固定のパスワードをユーザーが事前に設定し、認証時にそれを入力して利用します。 認証の要素として、ユーザーが “知っていること”(＝what you know)に基づく方式であり、知識認証で代表的なものと言えます。 パスワードを用いる認証においては、何らかの生成手順（＝暗号化アルゴリズム）により生成される暗号文がパスワードの実態です。当然のことながらパスワード自体の秘匿性を保つことで、認証要素としての役割を果たしています。 パスワードの歴史 Cepheus, Public domain, via Wikimedia Commons 現在ではPCやスマートフォンなど様々なシーンで使用されている「パスワード」ですが、その起源は暗号の歴史と密接に関わっており、本質的な起源は紀元前の時代まで遡ると考えられています。 例えば、歴史的に有名な「シーザー暗号」は紀元前約100年に誕生してます。 シーザー暗号 は「特定の文字列を3文字ずらすという暗号化アルゴリズム」から暗号文が生成される仕組みとなっており、この暗号文を「パスワード」と捉えることもできるのです。 一方で、より一般的な意味でのパスワードは 、 インターネットが誕生した1960年代にマサチューセッツ工科大学（＝MIT）で誕生したという説が有力です。パスワードの歴史がいかに長いか想像に容易いかと思います。 パスワードの特徴と現状（メリット、デメリット） 認証方式の一つとして広く利用されているパスワード認証ですが、メリット、デメリットも存在 します 。 それぞれ、主なものをご紹介します。 メリット シンプルで便利 ：パスワードは特定の文字列を組み合わせれば生成可能であり、老若男女問わず誰でも利用が可能。 高い普及率 ：上述の理由にも依存 します が、Webサイトはもちろん、IoT機器等のシステムリソースが限られる条件下でもシンプルな仕組みゆえに、実装可能な場合が多く、普及率は群を抜いています。 「 パスワードレス 」 という言葉が一般言語化しつつある現在でも、パスワード認証を前提にするアカウントは増加傾向にあります。 デメリット 忘れたら終わり ：パスワード自体を忘れた場合、パスワードリセット手続きを正しく行える場合を除き、基本的に二度と該当アカウントにアクセスできないというデータ消失のリスクがあります。 安全性の不安 ：便利さと高い普及率というメリットの裏返しとして、主に“使い回し”や、“弱いパスワード利用”に代表される不適切なパスワード利用・管理が一般化していると言わざるを得ません。サイバー攻撃の約8割でパスワードを含む認証情報が悪用されているという調査結果 ※1 があるなど、安全面において課題があると言えます。 ※1：出典：verizon data breach investigations report 2022 パスワードの管理 パスワードが便利であることは疑いの余地がないのですが、現在のサイバー攻撃で最も頻繁に狙われる情報の一つがパスワードであるとも言えます。このため、パスワードの適切な管理なくしては、パスワードを認証要素の一つとして使用することが難しくなってきています。ここでは、パスワード管理の主な手法と特徴を考察していきたいと思います。 パスワード管理の手法と特徴 主なパスワード管理手法は以下の3種類となります。ここでは、各管理手法のメリット・デメリットを定量的な視点を含めて解説します。 メモ/手帳で管理する シンプルで低コストであることが主なメリットです。また、技術的なセキュリティの観点では、オフラインであることからサイバー攻撃に対して高い耐性があることもメリットとな ります 。 一方で、パスワードを利用するためには常に持ち運ぶ必要があり、メモ/手帳自体を 忘れる（可用性の低さ） 紛失する（機密性の低さ） 覗き見される（機密性の低さ） 可能性が高いという、物理的なセキュリティの観点でのデメリットがあります。 また、パスワード利用時に毎回キーボード入力をしなくてはいけないという業務効率性の低さも大きなデメリットです。 パスワードを利用するたびに毎回キーボード入力を行う時間を試算してみましょう。 一般的な組織の労働形態として、1日8時間労働、年間休日120日の組織をモデルケースとし、1日当たりパスワード入力に要する時間を5分と仮定すると、以下の計算式分の時間が年間でパスワード入力作業に割かれていることになります。 [一人当たりが年間でパスワード入力作業に割く時間] 245日(365日―120日)　×　5分　＝　1,225分　＝　20時間25分　＝　2.5日 /人 *5分は想定となり、パスワード忘れやメモ/手帳を探す時間等は含めておりません。 更に、これが1000人の組織であれば組織全体でパスワード入力作業に要する時間は以下の通りです。 [一組織が年間でパスワード入力作業に割く時間] 2.5日　×　1,000　＝　2,500日/組織 1,000人の組織ではパスワード入力作業に年間で2,500日を費やしていることとなり、いかに無駄が発生しているか理解することができます。全ての従業員がメモ/手帳で管理しているケースはあまりないとは思いますが、定量的観点で業務の無駄を評価する際に参考にして頂ければと思います。 スプレッドシート（エクセル）で管理する シンプルで低コストであり、PC等があれば利用できる利便性の高さが主なメリットです。 一方で、パスワード利用時にキーボード入力若しくはコピペが必要となる業務効率性の低さ、オンライン管理となるためPC等がマルウェア感染した場合に容易に情報漏洩してしまうサイバー攻撃への耐性の低さが主なデメリットとなります。 実際に、スプレッドシートを暗号化せず（弱いパスワードによる暗号化も含む）PCのデスクトップ等に保管しているケースがほとんどかと思いますが、このような管理下でサイバー攻撃に遭うと、管理しているパスワードは容易に漏洩してしまいます。 またメモ/手帳ほどではないにしろ、パスワード利用時に毎回スプレッドシートを開き、データを探し、コピペする時間の無駄も無視できません。 以下はメモ/手帳で記載した想定と同じ条件で、スプレッドシート管理によるパスワード入力作業の無駄を定量的に分析する際の参考となります。 [一人当たりが年間でパスワード入力作業に割く時間] 245日(365日―120日)　×　1分　＝　245分　＝　4時間　＝　0.5日 /人 *1分は想定となり、スプレッドシートを探す時間等は含めておりません。 [一組織が年間でパスワード入力作業に割く時間] 0.5日　×　1,000　＝　500日/組織 パスワードマネージャー で管理する パスワードマネージャーには主に無償ツール（例：Google、Microsoft等のブラウザ機能）と有償ツール（例：Keeper、LastPass、1password等）が存在します。 無償ツール、有償ツール共に最大のメリットは、パスワード入力、生成といった作業が不要となり、パスワードを「覚える必要がなくなる」ことと言えます。 パスワードマネージャー導入による業務効率化の定量的な分析は、現在のパスワード管理手法の状況に応じて、既述の [パスワード入力作業に関わる計算式] で算出された時間がほぼ無くなるため、組織全体では大きな効果が得られると言えます。 一方で、デメリットとしては、 無償/有償を含め、ツール選定が難しいこと パスワードマネージャーベンダー自体がサイバー攻撃に遭った際のサードパーティーリスクが存在すること が挙げられます。 尚、パスワードマネージャーの選定時のポイント等については、別の記事で詳しくご紹介します。 まとめ パスワードの歴史は古く、最も普及している認証要素である。 パスワードは知識認証に基づく認証要素である。 パスワードはシンプルで便利であるが、一方で不適切な管理を原因としたセキュリティ上の課題がある。 サイバー攻撃の約8割でパスワードを含む認証情報が悪用されている。それだけ、攻撃する側にとっても貴重な情報と言える。 パスワード管理の手法は主に「メモ/手帳」「スプレッドシート」「パスワードマネージャー」の３つがあり、それぞれメリット/デメリットがある。 「メモ/手帳」「スプレッドシート」による管理手法では、パスワード入力作業という時間の無駄が発生する。 「パスワードマネージャー」による管理手法では、パスワード入力作業という時間の無駄を改善することができる。 次回はブラウザのパスワードマネージャーの危険性について解説します。 The post 【第1回】パスワードの基礎と主な管理手法について first appeared on Sqripts .

初めまして。QAエンジニアのまちこです。今はお客様先に常駐してWebシステムのUATを担当しています。テスト分析・設計、テスト実施を行う毎日です。 QAの仕事に携わって２ｘ年、今では当たり前のようにテスト分析・設計、テスト実施を行っていますが、まだテスト初心者で初めてテスト設計して作成したテスト仕様書は、ただテストベースのドキュメントに記載してあることだけをコピーしたようなものでした。テストケースの内容も記載方法も全く不足していて、今の私なら恐ろしいほどのダメだしをしているはずです。 「テスト担当者は、期待結果を識別する際、画面上の出力だけでなく、データおよび環境的な事後条件も考慮する。テストベースが明確に定義されていると、理論的には、正しい結果を容易に識別できる。ただし、テストベースのドキュメントは、曖昧で矛盾を含み重要な領域をカバーしていないか、もしくはまったく存在しないことがある。」 ISTQB® テスト技術者資格制度 Advanced Level シラバス日本語版 テストアナリスト Version 3.1.1.J03 1.4.2 テストケースの設計 上記のようにJSTQBシラバスにも記載がありますが、テストベースのドキュメントは曖昧だったり、矛盾を含むことがあります。時には記載内容が不足していることもあります。その中で試行錯誤し「今では当たり前」といえるようになったテスト分析・設計、テスト実施の私なりのコツ（心がけていること）をご紹介します。 記載内容から想像・想定を膨らます 私が仕様理解をする際に心がけていることなのですが、想像・想定を膨らませながらテストベースのドキュメントを読み進めてテストベースの「抜け漏れ」を防ぐことです。 例えば・・・ テストベースにユーザー登録の手順について、以下の記載があったとします。 ■ユーザー登録は次の手順とする Step1　個人情報入力 Step2　勤務先情報入力 Step3　その他情報入力 Step4　[登録]ボタン　クリック 登録完了 このような場合に 記載通りの手順でのユーザー登録の検証 各Stepでの入力値の検証が必要 Stepはスキップが可能なのだろうか？→スキップできるか否かの検証も必要 前のStepに戻ることは可能なのだろうか？→前のStepに戻る検証も必要 前のStepに戻れたとして、入力内容は保持されているだろうか？ 等・・・ このような想像は、今まで行ってきたテスト分析・テスト設計・テスト実施の経験が発想の元になっていると思います。また、他の方が作成したテスト仕様書のレビューからも気づきを得てきました。 他にも自分が普段使っているWEBサービスやアプリケーションを利用していて感じたことも発想の元になっています。例で挙げた「前のStepに戻れたとして、入力内容は保持されているだろうか？」という観点も、アンケートの入力中に前のページに戻った際に入力した値がクリアされていて使いづらさを感じた経験から想像に至っています。想像を膨らませて思いつけることは個人差がありますが、まずは記載内容だけを鵜呑みにするのではなく、意識的に「何か他に必要な検証はないか？」と想像することを心がけています。 必要な検証内容を想定したり、他にどんな検証が必要かを想像しながらテストベースを読み進め、想定した検証内容や不明点などを書き留めておくようにします。 テストベースを読み進めて疑問に思っていたことが記載されていて疑問が解消できれば、それをテストケースの期待値として検証内容を想定できます。最後まで残った疑問は開発者へ質問します。 開発者に質問した結果、回答がただの記載漏れであれば、対象のテストベースに記載してもらえば記載漏れを防ぐことができたことになります。 回答が記載漏れではなく仕様の検討がなされていなかったために記載していなかった、といった仕様の検討漏れだった場合、質問したことで開発者に仕様検討漏れに気づいてもらうことができますので、仕様の検討漏れを防ぐことができたことになります。 テストベースの記載内容が充実すれば、テスト分析・テスト設計もやりやすくなります。なので、仕様理解を進める際に記載内容を鵜呑みにするのではなく、1つの記載から想像を膨らませて検証内容を想定していくのが1つ目のコツです。 曖昧をそのままにせずに明確にする 繰り返しになりますが、テストベースのドキュメントは曖昧なことがあります。記載が曖昧だとテストケースの期待値の記載もそのまま曖昧となります。 例えば・・・ テストベースのドキュメントの記載に「不正な場合にエラーメッセージを表示する」とあったとします。それをそのままテストケースの期待値に採用したらどうなるのでしょうか？自分がテスト実施する際にテストケースの期待値として「エラーメッセージを表示する」とだけあったら、正しく判断できるでしょうか？ メッセージの文言は何？ メッセージの表示形式はどんな？インラインで表示？メッセージダイアログを表示？ とテスト実施時に不明点が出てしまいます。 実際に私が参画していたプロジェクトで、テスト実施のヘルプに入った別チームのテスト仕様書の期待値が「エラーメッセージを表示する。」となっていたことがありました。表示されたメッセージが正しいものであるのか判断することができずに、テスト仕様書の作成者に確認を取ったり、参照したテストベースのドキュメントを探したり、ドキュメントから該当のメッセージを探し出すといった余計な時間がかかってしまいました。 余計な時間がかかるだけではなく、実施者によっては表示されたメッセージの内容まで確認せずにメッセージが表示されていたのでOKとしてしまうかもしれません。 テスト仕様書の記載は、初めて実施する人でも分かるように確認手順や検証結果の期待値は明確に記載されていることが理想です。ですが限られた時間のなかで作成することもあり、テスト仕様書を詳細に作り込むことができないこともあります。 そんな時でも可能な限り、 テストベースの記載内容が曖昧な場合にはテスト設計時までに開発者に質問して記載内容を明確にすること テスト仕様書の確認手順や検証結果の期待値は曖昧にせずに明確に記載すること を心がけています。 テスト実施者が効率よく、迷うことのない優しいテスト仕様書を作成できるように、テストベースの記載内容の曖昧さやテスト仕様書の記載を明確にすることが2つ目のコツです。 ユーザーがやるかもしれないと想像してやってみる ユーザーがやるかもしれないと想像する・・・というとユースケースを想定してテストシナリオを考える。と思われるかもしれませんが、ちょっと違ってテスト実施時にテストケースにはないけどちょっと気になったことを「ユーザーがやるかもしれない」と思ってやってみるということなんです。 例えば・・・ [登録]ボタンをクリックしてから処理が完了するまでの処理中に、画面に変化がなく[登録]ボタンがクリックできる状態になっていたら ユーザーに処理が開始されたのか分からないじゃん！ ユーザーはもう一回ボタンをクリックするかも、いや連打しちゃうかも みたいに思ったりしませんか？そんな風に思ったらテストケースには記載はないけどやってみるんです。 実際にテスト実施中に、ボタンクリック後の処理中にボタンがクリックできる状態だったことがあったのでボタンを連打してみたんです。そしたらアプリケーションが固まってしまった！ということがありました。 テストケースには「処理中にボタンをクリックする」とはなくても、”もしかしたらユーザーがクリックしちゃうかもしれないので、クリックしてみよう。”とユーザーがやっちゃうかもしれないと想像してやってみることで潜んでいたバグを見つけることができました。 また画面に変化がなく処理が開始されたのが分からないので「処理中なら処理中と分かる画面表示にした方がユーザーには分かりやすいのでは？」といった、ユーザーにとって分かりずらい画面表示になってしまっていたといった気づきを得て問題点を開発者に提示し、改善に繋げられたこともありました。 このようにテスト実施中にちょっと気になったことをそのままにせず、ユーザーのことを想像してやってみることが3つ目のコツです。 まとめ 今回紹介した３つのコツは、誰もが無意識で実践しているような当たり前のことかもしれません。テスト分析・設計、テスト実施がちょっと難しくて苦手と思っている方でも、これらのコツを意識することで効果はあると思います。私が今日に至るまでテスト分析・設計、テスト実施時に心がけ、実践して効果がありましたので！！！ そして、皆さんも日々試行錯誤しながら自分なりのコツを掴んでより良いテスト分析・設計、テスト実施ができればと思います。 最後まで読んでいただき、ありがとうございました。 The post 無意識から意識的に！やさしいテストのコツ！ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第5回となる今回のテーマは「スコープマネジメント」です。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス スコープマネジメントの目的とは何か？ プロジェクトの成功に不可欠な活動がこのスコープマネジメントです。同じ目的・目標に向かっているようで実は違う方向を向いていた、プロジェクト後に出来上がるシステム（成果物）に食い違いがあった、ということは日々のプロジェクトに少なくありません。視座を合わせる、同じ目的・目標に向かう、目的目標を達成してプロジェクトをゴールたらしめるための「地図」がスコープであり、地図に沿って進めていくことがスコープマネジメントです。 (1) 二つのスコープ プロジェクトでは「プロダクトスコープ」と「プロジェクトスコープ」二つのスコープを明らかにします。 つまり私たちは何を作るのか？そして作るためにどんな準備や作業が必要か？を検討して、明確にしましょうということです。 例えば「フルーツを使った新作ラーメンを作りたい！」と考え、そのために先ず近隣のライバル店を調査しメニュー考案し、材料を揃え調理、試作や提供価格の決定などを経てお客様へ提供できるよね、という定義をします。どんなものを作りたいか？というゴールイメージであるプロダクトスコープがなくてはいつまでも成果物は作れませんし、当然そのために何をすればいいかも明確になりません。これら２つのスコープは常に対の関係で考え、整理していきましょう。 (2) プロジェクトスコープとは スコープ（Scope）の語源は「見る・観察」を意味するラテン語の「scopium」で、「可視・適用・対象の範囲」を指します。プロジェクトマネジメントにおける「スコープ」も同じ意味の活動を意味します。 【第1回】プロジェクトマネジメントとは何か？ でも「独自の目標と期限を持つのがプロジェクトの特徴」であり、プロジェクトをマネジメントすることは、プロジェクトを「その技術や経験を適用しながら、適切にヤリクリ（マネジメント）」する必要があるとお伝えしました。そのように様々な制約の中でプロジェクトを成功させるには、目的を明確にすること、どこからどこまでを実行範囲とするかを定め、達成できるようにマネジメントすることがとても重要です。 また、今後みなさんがプロジェクトスコープを検討する時に忘れないでいただきたいのは「範囲は やること だけでなく、 何をやらないか（範囲外か） も必ず決める」ということです。 成果物ややるべきことは漏れなく決められているか？ 不要な成果物はなにか？作業はなにか？それらが含まれていないか？ (3) スコープクリープを回避する、転ばぬ先のスコープマネジメント スコープクリープ（Scope Creep）という言葉をご存知でしょうか？ スコープクリープとは、プロジェクトで決めた/定義した成果物や範囲などが調整なしに逸脱・変更されてネガティブな事象を指します。プロジェクトにおいて変更は不可避だと言えますが、ここでいう変更は「調整のない・変更手順に則っていない」変更を指します。スコープクリープという言葉を使っていなくても「追加要求・変更・差し込み」と言えばみなさんの想像にも易く、いつでも誰にでも起こるというとがわかるでしょう。 ● PMI（Project Management Institute）の調査によるとプロジェクトの50%でスコープクリープが発生している（参考： PMI ） ● クリープ現象 ：クリープ(creep)は、物体に持続応力が作用すると、時間の経過とともに歪みが増大する現象 プロジェクト開始後に予期せぬ変更を要求された チームが把握してない機能があった（追加された） 追加の成果物を求められた 成果物の納期を急に早められた するとどうでしょうか、変更に伴い想定外のスケジュールやコストの増加調整が必要になったり、対応者の不足、チームから不満や不安の声も出るかも知れません。その影響度によっては、プロジェクトは一気に窮地に追い込まれます。 ではスコープクリープはなぜ起こるのでしょうか？ 理由は様々で明確なトリガーがある訳ではありませんが、筆者の経験から元々のスコープ設定の甘さ、スコープの合意が曖昧だった、ステークホルダーが複雑だったり巻き込めていなかった、コミュニケーション不足、最終合意不足などが挙げられます。 プロジェクトの大きなリスクとなるスコープクリープを少しでも減らし、プロジェクトを成功に近づける為、適切なスコープマネジメントを行いましょう。そのためにも、次から6つのステップを意識して進めてみてください！ スコープマネジメント6つのステップ (1) スコープマネジメントの計画 まず初めにスコープマネジメントをどう進めるか「計画」を立てることから始めます。簡単に言えば、6つのステップの2から6をどのようにして進めるかという計画です。 作成するドキュメント： スコープマネジメント計画書 プロジェクトのスコープをどのように定義、作成し、監視・コントロールし、その妥当性を確認するかといったことを記載する。 要求事項マネジメント計画書 要求事項の整理・分析、メンバーの具体的マネジメント方法などを記載する (2) 要求事項の収集 先ずはプロジェクトに何が求められているのかを収集・整理する非常に重要なステップです。要求と要件の違いにも注意しましょう。 「やってほしいことを（やりたいことを）要求として整理すればいいんでしょ」「プロジェクト憲章やINPUT文書があるから十分」と考えては失敗の始まりです。確かに、プロジェクト憲章を元に作業範囲や成果物を定義しますが、ほとんどの場合は十分ではありません。プロジェクトの成功は、ニーズを発掘しプロジェクト（プロダクト）の要求事項に要素分解できて初めて実現されます。そのためにステークホルダーに積極的な関与を促すこと、ドキュメントの有無に関わらずステークホルダーへのヒアリングを行うことを省略せず、しっかりと要求事項を文書化し要求骨子として残すことが重要です。 作成されるドキュメント： 要求事項文書（機能要求事項、非機能要求事項、プロジェクト要求事項、品質要求事項） 要求事項トレーサビリティマトリックス クライアントからの要求事項をマッピング（Aという要求がどこの誰から出たものか、その詳細など）し、要求事項の達成状況や結果を追跡するのに役立つ 要求事項収集時のコツ： まずはプロジェクトやその目的について理解してもらう（よく理解できていないプロジェクトに要求要望は言いにくいものです） 大人数を対象としたブレインストーミングやアンケート、個別少人数のインタビューなどを使い分け網羅的に要望収集する 要求事項の引き出しやヒアリングには必要な専門家をアサインする（品質要求・テスト要求のヒアリングはQAエンジニアが参加するなど） (3) スコープの定義 ステップ(2)で収集した要求を元に、明確にスコープを定義し文書化します。要求はすでに文書化しているのになぜ改めてスコープを整理・定義するのか？それは要求事項が全てプロジェクト要求（スコープ）として含まれるとは限らないからです。要求を「整理・選別しその範囲（する・しない）を決める」のがこのプロセスです。またこの定義がこの段階でどれぐらい詳細化されているかが、プロジェクト成功に極めて重要です。 作成されるドキュメント： プロジェクトスコープ記述書 定義されたプロジェクトスコープの記述（段階的に詳細化）、成果物、受け入れ基準、プロジェクトからの除外事項を記述 (4) WBSを作成する 定義したスコープを実現するために、WBS（作業分解図：Work Breakdown Structure）を使って必要な要素を整理しましょう。 WBSとは、目標や作業範囲＝スコープを要素に分解して、それらを達成し切ればプロジェクト目標を叶えられるように、作業を抜け漏れなく整理・管理するフレームワークです。またWBSとGANTT（工程表：ガント/ガントチャート）は異なりますが、混同して捉えているケースをよく見るので気をつけましょう。 要素分解のWBSと進捗管理のGANTT： WBS：計画するために目標を細分化する GANTT：活動の順番や影響力を整理する ※プロジェクトマネジメントツールの活用により、WBSを書かずに直接GANTTチャート上に要素分解するケースも増えています。 (5) スコープの妥当性確認 生成された成果物の妥当性確認、所謂「検証」を行うステップです。顧客やステークホルダーと共に成果物をレビューし、満足した形で成果物が完成していることを確認、成果物を公式に受け入れて「承認」されることで完了します。 いくら初期にスコープや成果物を定義しスポンサーと確実に合意していたとしても、時間の経過により忘れたり思い違いが発生することもあります。いよいよ成果物が完成したのに承認が受けられない！あるいは妥当性確認に時間がかかり長引く、などの事態を避けるために、プロジェクト工程ごとに分割して承認確認を取る、チェックリストを活用するなどの工夫もしてみましょう。 (6) スコープのコントロール 最後のステップはスコープコントロールです。 プロジェクト実行中に常に行いますが、プロジェクトのステータスをモニタリングし、スコープの変更を管理しましょう。「スコープクリープはプロジェクトで決めた/定義した成果物や範囲などが調整なしに逸脱・変更されること」とお話ししましたが、このスコープのコントロール過程で適切にプロジェクトに報告されたり、検討を踏まえて変更が決まったりしたものは「公式な変更」と言えますね。 さいごに プロジェクトの目標・目的と同様にスコープも明確であればあるほどよいですが、時として「全てを詳らかにしてからスタートしなければならない」とこだわりすぎると時間がかかり、ビジネスのチャンスを失ってしまうことにもなりかねません。わからないことは後でといった「段階的詳細化」にするバランスが大事です。 次回のテーマは「スケジュールマネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？（連載初回全文公開中） 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス The post 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ first appeared on Sqripts .

みなさんこんにちは、ノッカーです。 今回、USDMにかかわる記事の第二弾を書かせていただきます。 前回の記事 では、USDMを使用することで、要求や仕様を階層化することで、実装時の抜けや漏れ、誤りなどの問題が効果的に解決できることを紹介しました。 ■ USDMで初期品質を高めよう！ </Sqripts> 前回の振り返りとしては以下4点。 要求を分割する ・複合的な要求を単純な要求に分割する ・曖昧な要求を具体化する 要求を分割することで、より要求が具体化されました。 要求を階層化する ・元の要求を上位要求として分割した要求は下位要求とする 分割前の要求の配下に一覧化することで解決しなければならない細かい要求が明確になりました。 理由を記述する ・それぞれの要求に対して理由付けする ・認識のブレを抑えるために本質的な理由をつける 「なぜその要求が必要なのか」を理由として記述することで要求の本質が理解できて、認識のブレを防止しました。 仕様を導出する（要件を定義する） ・要求に含まれる具体的な処理や振る舞いを表現する ・特定できるレベルの粒度まで細かくする 要求を満たす仕様を導き出すことで何をすればいいのか明確になりました。 そして、前回までの完成図がこちらです。実用レベルではありますが、見た目が単調で読み込みにくいという課題があります。 今回は、より工夫を凝らして、可読性向上や管理の効率化を図り、以下の問題を解決していきます。 要件の本質を簡潔に示したい 仕様が多すぎて混乱しそう 仕様毎の進捗状況が不明瞭 さらに、私が取り入れているプラスアルファの手法も併せてご紹介いたします。 可読性向上や管理の効率化 今回追加する部分は以下の図のフォーカスが当たっている部分です。 （１）キーワードラベル 　馴染みのある用語や別名を記述します （２）説明を記述 　補足事項や背景など要求の記述では足りない情報を記述します （３）グループ 　要求や仕様が多い場合に小さい集合に分類して範囲を限定します （４）仕様ラベル 　仕様であることを示し、要求と明確に分離します （１）キーワードラベル まずはキーワードラベルについてです。 キーワードラベルは、上位要求に対して一覧性を持たせるために記述されます。参考図はごく一部分ですが、現場レベルでは上位要求が複数段階にわたることがあるため、キーワードラベルがあるかどうかで索引の容易さが変わります。 たとえば、要求が「保存するデータの容量がHDD容量を超える場合に空き容量不足であることを通知してほしい」という場合、キーワードラベルとしては「空き容量不足通知機能」や「HDD容量通知機能」とすることにより、 要求の本質を簡潔に示し 、一目で理解できるようにします。 （２）説明を記述する 次に説明欄についてです。 説明は理由を補足するために記述します。 そのため、要求と理由の内容だけで完結できる場合は記述を省略しても問題ありませんが、後で必要になる場合も出てくるかもしれないですし、統一性の観点からも記入する枠は用意しておいた方が良いです。 （３）グループ 次にグループについてです。 グループは数ある仕様を分類ごとに区分けします。グループ名は一括りにした仕様の総称で問題ありません。図には6つの仕様しか含まれていませんが、実際の現場では数十から数百もの仕様が記載されることがあります。 この手法では、グループを設定することでカテゴリごとの仕様を明示し、左揃えで記述することでグループの区切りがはっきりとして視認性が向上します。これにより、どのようなカテゴリがグループに含まれるのかを示し、仕様の関連性を視覚的に理解することができます。 （４）仕様ラベル 仕様ラベルには以下の2つの意味があります。 仕様であることを示す 「レビュー済み / 実装済み / テスト済み」などのステータス管理 チェックボックスにはそれぞれ意味を持たせ、チェックを入れていきます。上の図では3つのステータス管理が可能となっています。チェックボックスの個数やステータスの内容には具体的な指定がなく、各プロジェクトに合わせてステータスを定義することができます。 プロジェクトごとに毎回異なるステータスが設定されると誤認や混乱が生じる可能性がありますので、一定の範囲内で統一されたステータス管理を行うことをおすすめします。 また、アップデートが必要となる場合は、混乱を避けるためにも関係者に十分に周知し、確実かつ迅速に情報を伝えるようにしましょう。 ちょっとした工夫で上手にアウトプット 私が個人的に管理している表では、プラスアルファとして理由欄とグループ行にそれぞれ淡い赤と青の背景色を設定し、キーワードラベルから下の部分をグループ化しています。通常はこの図を袋綴じにしています。もし今回の図を使用してファシリテーターとして説明する場合、以下の図のように袋綴じにしてからスタートします。 「まずはHDD容量不足通知機能についてご説明します。容量不足による保存失敗を未然に防ぐため、＜上位要求＞の機能を実装します。細分化したものが以下の通りです。」と言って袋綴じを開きます。 「＜上位要求＞を満たすためには、保存するデータ容量に対して空き容量が確保できるか確認する必要があります。そのため、＜下位要求＞の機能を実装します。その仕様が青色の部分となります。」といった具合に、背景色を設定しておけば、例え傍聴者がUSDMで用いられる呼称を知らなくても、どこを示しているかがわかるようになります。 そして、それぞれの仕様を説明できたら、仕様ラベルの左端に✓マークを入れていきます。これで説明漏れも防げるようになりますし、どこを説明しているか、どこまで説明したかがわかりやすいです。 ※私が参画しているプロジェクトでは、左端の仕様ラベルは「仕様説明済み」というステータスを使用しています。 私も最初はそれぞれのUSDMの役割ごとに色付けした結果、逆に見づらくなってしまったことがあります。元々整った表ですので、控えめくらいが丁度良いのかもしれませんね。 最後に 今回のまとめです。 要件の本質を簡潔に示したい キーワードラベルでスッキリ見せて効率的な索引化 仕様が多すぎて混乱しそう グループで用途別に分けて視認性向上 仕様毎の進捗状況が不明瞭 仕様ラベルに役割とルールを持たせてステータス管理 フォーマットさえ作ってしまえば、あとは使いまわすだけのものになり、記載する際もUSDMを用いていないときに書く労力とさほど変わらないだけではなく、USDMに則って作成された資料は階層化されて詳細化された仕様書なので、説明しやすいですし、理解しやすく構成されています。 しばらく運用していけば、どのあたりに何が書かれているかがわかるようになりますし、要求にも仕様にも番号が割り振られているので、指し示す場合においても役に立ちます。 更に私がこのUSDMを知っていく上で、これって別の用途にも使えるのでは？と思ったことがあります。例えば料理や旅行などです。 カレーライスを作りたい！ ロンドンに行きたい！ となればこれは上位要求になります。 日常生活でもUSDMを使ってできることはあり、練習の一環としても良いかもしれません。 仕事においては、タスク管理や課題管理の基盤としても有用です。「これはなぜ必要なのか？」と疑問に思った場合、要求を確認して解決することができます。同様に、「どこまで進んだっけ？」となれば、仕様ラベルで管理されていれば問題を解決するのに役立ちます。 USDMはUniversal Specification Describing Mannerとフルネームの最後にある通り「マナー」なので各プロジェクトが使いやすいようにアレンジできるのが利点だと私は思います。 以上がUSDMにおける 可読性向上 や 管理の効率化 のご紹介となります。 ここまで読んでくださいまして、誠にありがとうございます。 関連記事 ■ USDMで初期品質を高めよう！ </Sqripts> The post USDMで仕様を上手にアウトプットしよう！ first appeared on Sqripts .

はじめまして、QAエンジニアのK.Kです。 今回は流行りのAIを使ってコードレビューを実施してみましたので、その結果をお伝えします。 AIとは まず初めにAIについてご説明したいと思います。AIとは、Artificial Intelligence(人工知能)を略した言葉で、コンピュータープログラムによって人間の知能を模倣し、機械が推論、認識、判断などの人間と同じ知的な処理機能を実行するための技術を指しています。 近頃、このAIを利用したサービスが私たちの生活において急速に増加しており、 音声を認識して対応するAIアシスタント(Alexa、Siriなど) 障害物を避けながら掃除をするお掃除ロボット 様々なコンテンツを生成する生成AI(ChatGPT、画像生成AI、音声生成AIなど) など、AIは私たちの生活や社会構造に大きな変化をもたらしています。 AIによるコードレビューの可能性と課題 なぜAIでコードレビューをするのか コードレビューには、バグの早期発見や潜在的な問題の解決、コーディングスタイルの統一など、多岐にわたる利点がありますが、プロジェクトの進行やデッドラインに追われる中で、コードレビューに十分な時間を確保することは容易ではありません。 そこで今回は、AIによって効率的かつ品質の向上につながる有益なコードレビューが可能か見ていきたいと思います。 AIを利用したコードレビュー コードレビューの実施環境について 今回はOpenAI社が提供している「OpenAI API」を利用して、2023年の11月に発表された最新モデルの「GPT-4Turbo」を使ったコードレビューを行っていきます。 レビュー対象のコードについて こちらが今回コードレビューの対象となったコードで、「指定したパスに存在するフォルダ名とフォルダの作成日時の一覧を取得する」、「JSONファイルを保存する」、「JSONファイルを読み取る」といったファイル操作関連の処理を実行するためのユーティリティファイルとなっております。 このコードに対して私がレビューをする場合、「JSONファイルの保存先パスが関数内で”output”変数として定義されているが、JSONを読み取る関数でも使用しているので関数のパラメータもしくはグローバル定数とした方がよいのではないか」、「各関数に関数を説明するためのドキュメントがないため何の処理をしているのかがわかりにくい」などの指摘が考えられます。 import os from datetime import datetime import json def get_directories_with_creation_date(path): dirs_with_dates = [] for item in os.listdir(path): item_path = os.path.join(path, item) if os.path.isdir(item_path): # Retrieve creation date creation_timestamp = os.path.getctime(item_path) creation_date = datetime.fromtimestamp( creation_timestamp).strftime('%Y-%m-%d %H:%M:%S') dirs_with_dates.append({"name": item, "date": creation_date}) return dirs_with_dates def save_file(name, json_data): if not os.path.exists("output"): os.mkdir("output") with open(f"output/{name}.json", "w", encoding="utf-8") as file: json.dump(json_data, file, ensure_ascii=False, indent=2) def load_file(name, dir="output"): if os.path.exists(f"{dir}/{name}.json"): with open(f"{dir}/{name}.json", "r", encoding="utf-8") as f: return json.load(f) else: return None AIによるコードレビュー それではAIにコードレビューを依頼していきます。 AIへの指示は4つの要素として分けることができ、 命令：モデルに実行してほしい特定のタスクまたは命令 文脈：モデルをより良い対応に導く外部情報または追加コンテキスト 入力データ：応答を見つけたい入力または質問 出力指示子： 出力のタイプや形式 参考： Prompt Engineering Guide 今回は、AIに対して以下の指示を与えました。 命令: 下記ソースコードについてレビューしてください。レビューで問題点を見つけた場合、問題点と問題点を修正するためのコードを出力してください。問題点を修正することで発生するメリット、デメリットについて出力してください。 文脈: あなたは優秀な日本人SEです。あなたのタスクはソースコードをレビューし、問題点を全て発見することです。 入力データ: 1:import os 2:from datetime import datetime 3:import json 4: 5: 6:def get_directories_with_creation_date(path): 7: dirs_with_dates = [] 8: …省略 その結果、AIより以下の回答が返ってきました。 このように、AIがコードの内容を読み取り、フォルダ名のパラメータ化による保守性の向上やフォルダ作成時に別のプロセスとの競合でエラーが発生しないようにmakedirs関数を使用したり、エラーハンドリングの追加などの安全性の向上につながる回答をしてくれるため、AIによる効率的なコードレビューが可能であることがわかりました。 より効果的にAIを利用するために AIによるコードレビューは効率的かつ品質の向上につながるレビューですが、ただ漠然とAIにレビューを依頼しただけでは、思っていた通りの結果が得られないことがあります。例えば、先ほどのAIによる指摘では関数のドキュメントに関する指摘が不足しているように感じました。そこで、よりうまくAIを利用する方法を探ってみました。 ChatGPTのサービスを提供しているOpenAI社によると、AIをうまく利用するための手法の一つに、「AIに対する指示は「ふわふわした」不正確な説明を減らす」というものがあります。 そのため、AIに対して、先ほどの指示に「レビューの観点(関数のドキュメントに関する指摘のみ)」とドキュメントのコーディングスタイルを統一するための「コードのコーディングスタイル(Google style)」を付け加えた指示を与えました。 命令: 下記ソースコードについてレビューしてください。問題点とそれを修正した後のコードも出力してください。問題点を修正することで発生するメリット、デメリットについて出力してください。レビューでは関数のドキュメントに問題があるかのみ見てください。 文脈: あなたは優秀な日本人のSEです。ソースコードをレビューし、問題点を全て指摘してください。レビュー対象のソースコードは「Google style」に従って書かれています。 入力データ: 1:import os 2:from datetime import datetime 3:import json 4: 5: 6:def get_directories_with_creation_date(path): 7: dirs_with_dates = [] …省略 その結果、AIより以下の回答が返ってきました。 AIへの指示に「レビューの観点(関数のドキュメントに関する指摘のみ)」や「コードのコーディングスタイル(Google style)」などの見てほしい観点に関する文言を付け加えることで、先ほどの指摘とは異なり、各関数のドキュメントに対する指摘が回答として返ってきています。 そこで、観点を指定した場合と指定していない場合で5回ずつレビューをして、指摘された観点の回数を表にまとめました。 指摘 観点(ドキュメント)指定なし 観点(ドキュメント)指定あり エラーハンドリング 1回指摘 指摘なし レースコンディション 3回指摘 指摘なし 責務の分離 1回指摘 指摘なし 入力データの検証 1回指摘 指摘なし ハードコーディング 2回指摘 指摘なし クロスプラットフォーム 4回指摘 指摘なし ドキュメント 1回指摘 5回指摘 このように、AIは「観点」を与えることで、観点にそったレビューをしてくれることがわかります。 AIによるコードレビューの問題点について AIを利用するうえで問題となるのがAIの精度です。コードレビューの結果に指摘の誤りや指摘してほしい箇所に対する指摘がないことがあると、コードレビューをしたにもかかわらず品質の向上が思うようにいきません。 こちらは別のファイルに対して先ほどと同じ指示を与えた結果になります。 命令: 下記ソースコードについてレビューしてください。問題点とそれを修正した後のコードも出力してください。問題点を修正することで発生するメリット、デメリットについて出力してください。レビューでは関数のドキュメントに問題があるかのみ見てください。 文脈: あなたは優秀な日本人のSEです。ソースコードをレビューし、問題点を全て指摘してください。レビュー対象のソースコードは「Google style」に従って書かれています。 入力データ: 1:from typing import (Any, Dict, List) 2:from langchain.retrievers.document_compressors import ( 3: LLMChainExtractor, EmbeddingsFilter) ... 80:class MyCustomCallbackHandler(BaseCallbackHandler): 81: """Custom CallbackHandler.""" 82: 83: def __init__(self, callback=None): 84: self.prompts = [] 85: self.callback = callback 86: self.pertial_token = "" 87: 88: def on_llm_new_token(self, token: str, **kwargs: Any) -> Any: 89: """Run on new LLM token. Only available when streaming is enabled.""" 90: if self.callback is not None: 91: self.pertial_token += token 92: self.callback(self.pertial_token) 93: 94: def on_llm_start(self, serialized: Dict[str, Any], prompts: List[str], **kwargs: Any) -> None: 95: kwargs["run_id"] = str(kwargs["run_id"]) 96: kwargs["parent_run_id"] = str(kwargs["parent_run_id"]) 97: 98: self.prompts.append({ 99: "prompts": prompts, 100: "serialized": serialized, 101: "kwargs": kwargs 102: }) 103: 104: 105:def create_model_from_json(model_name, json_data, callback): …省略 229:def get_file_extension(file_path): 230: return file_path.split(".")[-1] …省略 719:def run(**kwargs): ...省略 781: return result その結果、AIより以下の回答が返ってきました。 このように、「ドキュメント」に問題があるコードをもれなくレビューしてほしいと依頼したにもかかわらず、「on_llm_new_token」関数や「get_file_extension」関数などへの指摘が欠けていました。 これらの指摘の漏れは、AIに対する指示をさらに詳細化することで減らすことができると考えていますが、AIの結果をそのまま受け取るのではなく、必要な指摘を見極めなければいけないと感じました。 まとめ 近年、AIを利用した革新的なサービスが急速に増加しています。その中で、AIによるコードレビューは開発者たちの手助けとなり、品質の向上につながるものだと感じています。しかし、AIは発展途上の技術であり、AIの判断がすべて正しいとは限りません。AIによってできること、できないことを理解し、適切な場面でAIを利用することがよりよいコードレビューにつながるのではないかと考えます。 【サービス紹介】AIテクニカルコードレビュー AGESTの次世代QAエンジニアがAIを活用したコードレビューを実施します。 - 社内に蓄積されたレビュー観点とAIを組み合わせたレビューを実施 - AIのレビュー結果を次世代QAエンジニアが確認 上記を実施することで、AIによる誤りを排除した、効率的かつ精度の高いコードレビューとなります。 AGESTは製品の品質向上に貢献いたします！ お困りごとがありましたら、お気軽にご相談ください。 ■ AIテクニカルコードレビューのサービス紹介はこちら ｜株式会社AGEST The post AIを使ってコードレビューをやってみた first appeared on Sqripts .

皆さんこんにちは。　テストエンジニアの新村です。 昔に比べアプリの高性能化、汎用性が高まり、それに伴いテストの量が増えたと実感しております。 工数には限りがあるので出来る限り効率化していくうえで、必要に迫られるのがテスト業務の自動化です。この記事では主にテスト業務を自動化したい皆様向けに、自動化の課題と使用するツール、エクセルを使った自動化機能についてお話しできればと思います。 ※なお本記事で扱う自動化機能はGoogleスプレッドシート+GAS等でもほぼ実現可能です。 テスト業務の自動化 テストプロセスの説明 テスト業務を自動化する前にまずはテストプロセス（工程）について説明します。 JSTQBによると、テストプロセスは計画から評価終了後の作業までを含めて、「テスト計画」「テストのモニタリングとコントロール」「テスト分析」「テスト設計」「テスト実装」「テスト実行」「テスト完了」の7つに大別されています。 それぞれの内容について簡単に説明しますと、 「テスト計画」「テストのモニタリングとコントロール」では、テストの目的を決めます。実施予定のテスト対象の開発理由、納期などを考慮し、テストで何をすべきかを計画します。 「テスト分析」「テスト設計」では、テスト計画をもとに具体的なテスト手法を作成します。 「分析」でテストの目的に合う実行すべきテストの手法や条件の決定、「設計」では分析結果をもとにテストを設計していきます。 「テスト実装」「テスト実行」では、テスト設計を元にテスト実施時に用いるテストケース、テストデータを作成し、それを実行する作業を行います。 「テスト完了」では、テスト完了の判定と結果報告を、開発者や管理者などに報告します。テスト完了の判定は終了基準に到達しているかどうかによります。テストの成果物を確認とテストの経験をもとに、今後のテストプロセスの改善活動を行います。 以上のテストプロセスの中で、文書がメインの「テスト計画」以外が自動化可能な対象となります。 テスト業務自動化のメリットとデメリット 自動化することのメリットとデメリットを記載します。 自動化するメリット 時間短縮:手動で行う手間を省けます。 エラーレスな処理: 手作業に比べてエラーを最小限に抑えられます。 費用を抑える：自動化した作業分、費用を抑えられます。 データの視覚化: グラフやチャートと連携して使えば、データを視覚的にわかりやすく表示できます。 自動化するデメリット 保守作業の追加：手動とは異なり、対象のシステムに変更があった場合、自動化のプログラムを修正する作業が増えます。 複雑な業務には不向き：対象が複雑なシステムやアプリには自動化には向きません。コードの作成に時間がかかり、自動化がそもそも不可能なケースもあります。 テストと別の費用が発生：通常のテスト業務に加え、自動化に使用するツールの費用、対応した技術者の確保が必要となります。 そこで自動化への第一歩としてエクセルを使ってのテスト業務自動化を紹介してきます。 エクセルを選んだ理由としては、多くの人が知っている使っている認知度とシェア率の高さ、開発の難易度がそれほど高くない点につき、先述したデメリットをある程度カバーしてくれるからです。更にエクセルは連携性に優れており、エクセルで作成したデータを他のシステムやアプリに展開、もしくは他システムとアプリのデータをインポートして利用することが可能です。 表計算ソフトの利用率は85%。 最も利用頻度の高い表計算ソフトはエクセルで表計算ソフト利用者の8割以上がメインで利用。 最も使いやすいと感じる表計算ソフトもエクセルが8割以上の支持を獲得。 表計算ソフト利用者のうち、アドオン機能利用経験者は約5割。 参考：「 BtoBサービスの比較メディアUtilly 2022年5月 表計算ソフトの利用状況に関するアンケート調査 」 テスト業務自動化に使えるエクセル機能 エクセルのどの機能がどのテスト業務の自動化に役立つかを載せていきます。エクセルを使っている方には今更と思うLv1から、こんな事も出来るよというLv5までテスト業務に使えそうな機能を掲載してみました。少しでも参考になれば幸いです。（※Lvの設定は著者の主観で付けさせていただきました。） カテゴリ Level 説明 指定語句で書式変更 Lv1 条件付き書式を使用して指定語句を強調 データ入力制限で語句統一 Lv1 データ入力制限でセルに入力する値を制限 No自動入れ Lv2 関数を使用してセルに番号を自動付与 関数や計算式の結果に語句を追加 Lv2 ユーザー定義で計算結果のセルに語句をつける レポート自動作成 Lv3 マクロでテスト結果から必要なデータを抜き出す操作を記録し以降自動化 テスト自動統計 Lv3 テスト結果やテスト項目処理数などの統計を関数で処理し、表で可視化 VBAを使用してのテスト自動統計 Lv4 VBAでテスト項目の中から該当のバグが起きる項目の合計数を抜き出す ファイルチェック Lv4 VBAのDirコマンドを使い提出するファイルの存在をチェック テスト実施を自動化 Lv5 テスト業務自動化ツールSeleniumとVBAを使用してテストを自動化 BTSを自動更新 Lv5 テスト業務自動化ツールSeleniumとVBAを使用してデータを抜き出しBTSを自動更新 指定語句で書式変更 (Lv1) 条件付き書式とは、指定したセルの値や数式の計算結果に対して、条件（ルール）を設定し、その条件を満たしたセルを定めた書式にする機能です。この機能はテスト項目書やテストスケジュール表で役に立ちます。 テスト項目書で例にとると、場合によっては1000以上の項目があるテスト結果から「NG」である結果を強調するために、この条件付き書式で「NG」を指定し目立つ色で変えたり、発見したバグが修正済みで確認不要となったときは「修正済み」を指定し取り消し線や灰色で目立たなくしたり、といったことを自動で行ってくれます。 条件付き書式設定前の画面です。 結果欄にはOKとNGが混在していますが、どこにNGがあるかわかりづらい画面となっております。 条件書式設定で「NG」の時に「濃い赤の文字、明るい赤の背景」に設定しました。 前の画面に比べてNGが目立つようになりました。 データ入力制限で語句統一 (Lv1) テスト項目書で統計を取る時は同じ語句でなければなりません。例えば「OK」の項目を「〇」「ＯＫ（大文字小文字違い）」「問題なし」などと入れてしまうとそれぞれ別語句とカウントされ、統計が取れなくなります。入力するのは人なのでどうしても書き方には差が出てしまいます。そこで統計に関わる所はセルへの入力を制限するエクセルの機能を使います。指定した値しか設定できないので前述のようなことは無くなります。 下の表でOK、NG、未回答数を計算してますが、E3で「OK」ではなく「〇」としているため、OK数が合っていない現象が発生しています。 現象を解決するために、データの入力規則で入力させたい値のみ指定します。 セルを選択すると指定された語のみ入力可能で、他の語を入れようとするとエラーになります。 これで数が合わなくなる現象は起きなくなります。 No自動入れ (Lv2) テスト項目書を作る時に作成済みのテスト項目の間に途中に項目を挿入、もしくは既存のテスト項目を削除するとNoがずれて最初から打ち直すことになり、手間となります。そこで以下の関数を使って自動的に番号を割り振れば、テスト項目数を変更しても自動でNoが更新されます。 A列にNoを入れてますが、追加や削除があるとNoをもう一度最初から記入しなければならず面倒です。 方法は色々ありますが、一番簡単なのは関数ROWを使った =ROW(A1(対象の列の頭))-ROW($A$1(対象の列の頭))+1 です。行を削除しても追加しても既存のNoは自動更新されます。 関数や計算式の結果に語句を追加 (Lv2) 関数や計算式を使うと結果のみのセルとなり見栄えが悪くなります。関数や計算式がセルに入っており、結果も変わってしまうので変更することも出来ません。そこでセルのユーザー定義機能を使うことで結果の文頭や文末に語句を追加することが出来ます。ユーザー定義とはデフォルトの書式ではなく、ユーザーが独自に作成した表示形式のことをいいます。前述のNoや回や件など単位を結果に表示する時に便利です。 合計を下の表のF列に載せていますが、関数 COUNTA を使っているので数字だけで見栄えが良くなく、隣のE列に項目名を入れても他のセルの長さに合わせた影響で不格好な表示になっています。 [セルの書式設定]の[ユーザー定義]で数字の前に語句を入れることで、計算結果の数字の前に好きな語句を入れることが出来ます。 レポート自動作成 (Lv3) 毎日の進捗状況やバグを報告するのに毎回毎回最初から記述するのは大変でミスも出てしまいます。そこでマクロで自動化すると効率的です。マクロでテスト項目書から必要なデータを抜き出す操作を記録させてボタン一つで作成することが出来ます。 例えば上記のように上長（青い背景）と顧客先（黄色い背景）に出す内容が異なる時、以下のようにマクロで記憶します。 マクロ作成手順 まず上長用のフォーマットを新規のシートに作成します。 マクロの記録を開始し、項目名（この場合は総項目数、実施数、新規バグ数、既存バグ数）を記入、書式を設定、取り出す数値とコメントを関数で指定し、記録を完了。 次に一旦上長用のフォーマットを削除して、同じシートに顧客様用のフォーマットを作成。 マクロの記録を開始し、上長時と同じく項目名（この場合は実施数、残存項目数、新規バグ数、既存バグ数）を記入、書式を設定、取り出す数値とコメントを関数で指定し、記録を完了。 それぞれの記録したマクロを呼び出すボタンを最後に作成することで、今後はボタン一つでレポートが作成できます。 テスト自動統計 (Lv3) テスト項目書で必要なのは項目の結果を記載するだけではなく、進捗状況を把握しておく必要があります。テスト項目数が膨大になると結果を数えるのは手動では骨が折れてしまいます。そこで、関数や表を使います。テスト結果や日々のテスト項目処理数など様々な統計を関数で処理でき、表を使うことで進捗状況を可視化できます。 項目数が増えたり、シートが複数にまたがったりすると進捗を確認するのが大変になります。 進捗というシートを別に作り、テスト結果を集計した数字を利用して関数や計算、表やグラフで進捗状況を表示するとわかりやすくなります。 VBAを使用してのテスト自動統計 (Lv4) Lv3テスト自動集計より細かい設定ができます。例えば複数のシートのテスト項目の中から該当のバグが起きる項目の合計数を抜き出すなど、関数やマクロでは難しい場合はVBAを使用して統計を取ります。 VBAの起動方法 エクセルの開発タブをクリック 開発タブが表示されていない場合は、 [ファイル] タブ、[オプション]、[リボンのユーザー設定] の順に移動します。 [リボンのユーザー設定] および [メイン タブ] の下の [開発] チェック ボックスをオンにします。 Visual Basicアイコンをクリック ■VBAコード Sub 複数シート検索() Dim i As Long, j As Long, keyword As String, intPerfectMatch As Integer '起票レポートにあるレポート番号を取得 MaxRow = Worksheets("起票レポート").Range("A2").SpecialCells(xlLastCell).row MaxRow = MaxRow - 2 For j = 21 To MaxRow keyword = Worksheets("起票レポート").Cells(j, 2).Value intPerfectMatch = 0 k = Worksheets("起票レポート").Index k = k - 1 '各シートで対象文字があるか検索。 For i = 1 To k Set Rng = Worksheets(i).Cells.Find(keyword) If Rng Is Nothing Then Else intPerfectMatch = intPerfectMatch + 1 adr = Rng.Address Do Set Rng = Worksheets(i).Cells.FindNext(After:=Rng) If Rng.Address = adr Then Exit Do Else intPerfectMatch = intPerfectMatch + 1 End If Loop End If Next i '対象セルに数を記入。 'intPerfectMatch = intPerfectMatch - 1 Worksheets("起票レポート").Cells(j, 8).Value = intPerfectMatch Next j End Sub 上記モジュールは、各テスト項目書のシートを検索し、 FindNext メソッドを使ってBTSのバグNoが何個あるかの検索を行い、個数をバグの統計列に自動記入するようにしています。 ファイルチェック (Lv4) テストの成果物にはテスト項目書だけでなく、エビデンスのファイルを提出する必要があります。エビデンスは時には膨大な量となり、ファイルの存在を目視で調べるのは骨が折れます。VBAでファイル存在チェック機能を作成すれば自動で確認することが出来ます。 ■VBAコード Sub ファイルチェック() Dim Sheet As Worksheet Set Sheet = ThisWorkbook.Sheets("メイン") ' シート名を適切に変更 Dim ReslutCell As Range Dim Cell As Range Dim Path As String ' A1からA5までのセルに記載されたパスをチェック For Each Cell In Sheet.Range("G3:G8") Path = "C:\\\\" + Cell.Value + ".png" Set ReslutCell = Cell.Offset(0, 1) ' 隣のセル If Path <> "" Then If Dir(Path) <> "" Then ReslutCell.Value = "〇" Else ReslutCell.Value = "×" End If Else MsgBox "セル " & Cell.Address & " にパスが記入されていません。" End If Next Cell End Sub ファイルの存在を調べるには Dir コマンドを使います。上記モジュールはセルに記載されているファイル名が特定のパス（今回はCドライブ直下）にあるかを調べて、隣のセルに結果を記載するようにしてます。 テスト実施を自動化 (Lv5) テストの結果や設計をサポートするだけではなく、テスト業務自動化ツールを利用すれば自動でテスト実施もエクセルは出来てしまいます。テスト業務自動化ツールはここではブラウザのテスト業務自動化ツールSeleniumを使って説明いたします。 ※　テスト対象がSeleniumで動かせるものでないと使えません。事前に確認してください。 Seleniumのインストールとエクセルの準備の仕方 Selenium Basicをインストール テストで使うブラウザの同バージョンのドライバーをダウンロードし、Selenium Basicをインストールしたフォルダにコピー＆上書き ■VBAコード Sub sample() Dim driver As New WebDriver Dim strURL As String Dim strWebBroeser As String Dim i As Integer strURL = "<https://www.google.co.jp/>" strWebBroeser = "chrome" driver.Start (strWebBroeser) 'ブラウザ起動 driver.Get (strURL) 'URL指定 '検索文字列入力 driver.FindElementByName("q").SendKeys ("EXCEL") '検索ボタンクリック Set searchButton = driver.FindElementByName("btnK") searchButton.Click driver.TakeScreenshot(0).Copy DoEvents Range("A2").PasteSpecial End Sub SeleniumをVBA上で動かします。Chromeを立ち上げてテスト対象サイト（今回はGoogle）でエクセルを検索し、結果をスクリーンショットでエクセルに貼り付けるコードとなります。 BTSを自動更新 (Lv5) バグを起票した時にBTSに登録しますが、テスト項目書にもバグを記載するケースがあります。BTSで対象のバグに更新があった場合、テスト項目書でも更新状況を反映しなければラグが出てしまいテストで混乱するケースも出てしまいます。Seleniumを使えばDBから自動的にデータを取得し、更新分を反映させることが出来ます。 ※　BTSがSeleniumで動かせるものでないと使えません。事前に確認してください。 ■VBAコード Sub Test() Dim driver As New WebDriver Dim strURL As String Dim strWebBroeser As String Dim i As Integer TARGET_URL = "<https://weather.yahoo.co.jp/weather/jp/13/4410.html>" strWebBroeser = "chrome" driver.Start (strWebBroeser) 'ブラウザ起動 driver.Get (strURL) 'URL指定 'Chromeを起動し、指定されたURLのページを表示する driver.Get TARGET_URL 'テーブル情報を取得し、エクセルに貼り付ける driver.FindElementById("yjw_week").FindElementByTag("table").AsTable.ToExcel ThisWorkbook.Worksheets("DB").Range("A2") 'ドライバをクローズし、Chromeを終了する driver.Close Set driver = Nothing End Sub SeleniumをVBA上で動かします。Chromeを立ち上げてDB対象サイト（今回はYahoo!天気）から対象データ（東京の天気）をコピーする作業です。ここから更に条件を付けくわえれば、更新があったもののみ記入といった自動化も可能になります。 さいごに これから自動化を目指す人にとって、テスト業務の自動化には高いハードルがあります。 自動化できれば作業が効率化できるが、自動化するための作成・保守の工程と費用が追加される。 自動化に向かない作業もある。 この二点を意識して自動化を進めることが大事です。 自動化できれば作業が効率化できるが、自動化するための作成・保守の工程と費用が追加される。 自動化を推し進めようとしてもプログラミングスキルの不足や自動化の対象が曖昧なまま進めて失敗すれば、自動化に費やした費用や時間も無駄になってしまい、テストを自動化しない方がかえって費用がかからずに済んだということも間々あります。 自動化に向かない作業もある。 複雑なアプリやシステムには向かないことは前述しましたが、他にも「頻繁に画面やシステムが変わる」「テスト実施は一回のみで十分」な対象にも向きません。まずはそのテスト対象が自動化する価値があるか、自動化できそうかを判別する必要があります。 手軽に見える自動化は実は綿密な計画が必要とされます。まずは身近なツールであるエクセルで自動化のメリット・デメリットを体験して、対象のアプリが自動化に適していることが判明できれば、他の自動化専用のアプリやツールへとより複雑な自動化プロセスへステップアップし、更なる自動化への道に進んでいけると思います。 最後まで読んでいただき、ありがとうございました。 The post エクセルの各機能を利用してテスト業務自動化へステップアップ first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。 ■ 論理スキル・“入門編”のこと　(T3:Pt1:Ch01) よろしかったらご覧ください。 今回第4回は、 第3回 で見た論理演算の組合せについて解説します。 ＜テストエンジニアのための論理スキル[再]入門　連載一覧＞ ※クリックで開きます [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 論理演算の組合せ① 第3回 で出てきた3条件の論理積や論理和や、「登録できるアカウント名文字列の条件」（3条件の論理積として扱いました）は、実は「二項演算である論理積/論理和の組合せ」です。（図4-1参照） 図4-1　二項演算の組合せによる、三条件のAND/ORの真理値表 もっと“複雑”な組合せができることもあります。たとえば次のような、ふたつの数値がそれぞれ所定の範囲にあるという条件は…… 入力Aの数値がminA以上で、かつ、入力Aの数値がmaxA以下である　か、 または、 入力Bの数値がminB超で、かつ、入力Bの数値がmaxB未満である 次の三つの論理演算の組合せでできていますから…… ①入力Aに関する二つの条件のAND式 ②入力Bに関する二つの条件のAND式 ①②に関するOR式 論理演算の式として下記のように表せます： (A >= minA AND A <= maxA) OR (B > minB AND B < maxB) 論理演算を組み合わせる時は、何と何がAND/ORの関係にあるかに気をつけましょう。 個々の論理演算式を丸括弧”()”で括ると、書き間違い・読み間違いを抑えられます。 （「登録できるアカウント名」を、使用可能な文字(3条件のOR)をまとめずに論理演算の式で表してみてください） 論理演算の組合せ②AND/ORとNOTの組合せ (ド・モルガンの法則) 論理積(AND)の否定、論理和(OR)の否定 組合せの中で、AND式やOR式をNOTで括った「AND式の否定」「OR式の否定」はよく出てきます。テストを考える時にも頻繁に出くわす形です。 (S1)「買い上げ商品点数が5点以上で、かつ、買い上げ合計金額が2,000円超の場合、特典Saが付与される」 (S2)「買い上げ商品点数が20点以上か、または、買い上げ合計金額が10,000円超の場合、特典Sbが付与される」 という仕様があった場合、テストとしてはS1, S2それぞれについて次の両方を考えます。 (Ev) 条件を満たす場合 (Ei) 条件を満たさない 場合（Evの否定） S1のEiはAND式の否定・ NOT(A AND B) 、S2のEiはOR式の否定・ NOT(A OR B) です（図4-2, 4-3, 4-4）。 図4-2　S1, S2でテストしたい場合 図4-3　S1真理値表(Ev, Ei) 図4-4　S2真理値表(Ev, Ei) 「条件を満たさない」場合のAとBの真偽はどう考えればよいでしょうか。 AND式の否定　……「A, Bがともに真」ではない時に真になります。 「ともに真、ではない」 とは？ OR式の否定　……「A, Bどちらが真」ではない時に真になります。 「どちらかが真、ではない」 とは？ ド・モルガンの法則 AND式/OR式とその否定(NOT)との関係を理解しやすくしてくれるのが ド・モルガンの法則 です。 A AND B(Aであり、 かつ 、Bである) の否定 　⇔ Aの否定か、または、Bの否定（ Aでないか、または、Bでない ） NOT(A AND B) ⇔ NOT(A) OR NOT(B) A OR B(Aであるか、 または 、Bである) の否定 　⇔ Aの否定、かつ、Bの否定（ Aでなく、かつ、Bでない ）  NOT(A OR B) ⇔ NOT(A) AND NOT(B) この関係は常に成り立つ。（図4-5, 4-6） 図4-5 NOT(A AND B) ⇔ NOT(A) OR NOT(B) 図4-6 NOT(A OR B) ⇔ NOT(A) AND NOT(B) 具体例 S1(AND式)の否定 「買い上げ点数が5点以上」を条件A, 「買い上げ合計額が2,000円超」を条件Bとすると、 特典Sa付与の条件　……        ＝　A AND B 条件を満たさない場合 　……   ＝　 NOT (A AND B) ド・モルガンの法則 を適用して　  ⇒　 NOT(A) OR NOT(B) ⇒条件Aが成り立たないか、または、条件Bが成り立たない場合 ＝「買い上げ点数が5点以上ではない」か、または、「買い上げ合計額が2,000円超ではない」 （ 「買い上げ点数が5点未満か、または、買い上げ合計額が2,000円以下の場合」 ） S2(OR式)の否定 「買い上げ点数が20点以上」を条件C, 「買い上げ合計額が10,000円超」を条件Dとすると、 特典Sb付与の条件　……        ＝　C OR D 条件を満たさない場合 　……   ＝　 NOT (C OR D) ド・モルガンの法則 を適用して　  ⇒　 NOT(C) AND NOT(D) ⇒条件Cが成り立たず、かつ、条件Dが成り立たない場合 ＝「買い上げ点数が20点以上ではない」、かつ、「買い上げ合計額が10,000円超ではない」 （ 「買い上げ点数が20点未満で、かつ、買い上げ合計額が10,000円以下の場合」 ） 込み入った条件への適用 ド・モルガンの法則は、今回冒頭に挙げた「2変数の数値の範囲の組合せ」のような、込み入った論理演算の組合せにも当てはまります。 考えやすくするために、A, Bの範囲を表す詳細な条件式を“まとめて”表します。 𝔸＝入力Aの値が範囲内にある 𝔹＝入力Bの値が範囲内にある 全体はOR式　……         ＝　𝔸 OR 𝔹 「そうでない」場合 は　　　……  ＝　 NOT (𝔸 OR 𝔹) ド・モルガンの法則 を適用して　  ⇒　 NOT(𝔸) AND NOT(𝔹) ＝（ 入力Aの値が範囲内ではなく、かつ、入力Bの値が範囲内ではない ） NOT(𝔸)について  展開すると　　　　　　　　…… ＝　NOT(A >= minA AND A <= maxA)   ド・モルガンの法則 を適用して　  ⇒　NOT(A >= minA) OR NOT(A <= maxA)  否定を取り除いて(不等号を逆転)　⇒　 A < minA OR A > maxA NOT(𝔹)について  展開すると　　　　　　　　…… ＝　NOT(B > minB AND B < maxB)   ド・モルガンの法則 を適用して　  ⇒　NOT(B > minB) OR NOT (B < maxB)  否定を取り除いて(不等号を逆転)　⇒ 　 B <= minB OR B >= maxB ⇒(A < minA OR A > maxA) AND (B <= minB OR B >= maxB) ＝ 「『入力AがminA未満であるか、または、maxA超』であり、かつ、 『入力BがminB以下であるか、または、maxB以上』」 むすび ド・モルガンの法則を標語風に掲げておきます。実際に「その形」に出会った時にこの法則が頭に浮かぶよう、憶えてしまいましょう。 （いつか、「なぜそう考えてよいのか」の解明にチャレンジしてみてください） ANDの否定は、否定のOR 　/　 ORの否定は、否定のAND （否定のORは、ANDの否定 　/　 否定のANDは、ORの否定） 論理演算もド・モルガンの法則も、「直感的にそうだと感じていたこと」と同じだ、と感じる人も多いのではないでしょうか。それはその通りで、論理の言葉といっても普段使っている言葉の意味や働きとまったく異なるものではありません。そう考えると論理の言葉のハードルは下がるのではないでしょうか。 第5回・第6回は、文レベルのロジック（文や文章を理解する時に働く論理の言葉）に話題を移します。第5回は、前回と今回出てきた論理演算の言葉が文レベルではどのような意味/働きを持つのかを見ます（今回でも、そこはかとなく「文レベルの論理積・論理和・否定」が現れていますね）。 参考文献 『入門！論理学』(野矢茂樹 / 中央公論新社) 『スマリヤン先生のブール代数入門』(スマリヤン / 共立出版) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) 『論理的思考の技法〈1〉第2版　「ならば」をめぐって』(鈴木美佐子 / 法学書院) 『新版　論理トレーニング』(野矢茂樹 / 産業図書) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 The post [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ first appeared on Sqripts .

皆さん、こんにちは！　QAエンジニアのいかぽっぽです。 お客様や上司から、このテスト、ざっくりどのくらいかかりそう？と聞かれて困った経験はないでしょうか？ ざっくりとは言っても、それなりになぜこのくらいかかりそうなのか？の説明は必要です。本記事では、基本的なソフトウェアテストの見積の考え方や手法についてご紹介したいと思います。 テスト見積の経験がまだあまりない方や、より精度の高い見積を作成したい方にぜひお読みいただければと思います。 見積とは？ そもそも見積とは？のおさらいになりますが、 目分量や心づもりではかっておおよその見当をつける。目算する。 工事や製品などの、原価・日数・経費などを前もって計算して出す。 「デジタル大辞泉」より と定義されています。 基本的な考え方や手法はソフトウェア開発と同様ですが、テストの見積においては、主にテスト工程全体や各テスト工程ごとの作業期間、スケジュール、規模感、必要なリソース、コストなどを対象としてアウトプットすることが一般的です。 品質のゴールやテストスコープ、テストタイプ、テスト環境、使用するツールなどの様々な条件によって、算出結果は大きく変動します。 テスト見積の目的 テスト見積の目的は、予算取りのため、プロジェクト計画のため、テストを遅延なく推進するため、など様々あります。また、お客様やプロジェクト管理者だけでなく、見積に基づいて作業を行うQAエンジニアにとっても非常に重要なものです。 目的次第で、用いる手法や算出単位も変わります。 テスト見積の主な手法と特徴 テスト見積でよく用いる手法として、大きくは3つの分類があります。 他にも手法は様々ありますが、ここでは私のこれまでの経験上、多様なテスト見積のシーンに適用できるより汎用性の高いものに絞ってご紹介します。 その1：　類推見積 過去の類似したプロジェクトなどの実績や情報をベースにして、類推して見積もる方法です。具体的な手法としてKKD法やデルファイ法などがあります。（各手法の詳細説明については割愛させていただきます。ご興味のある方は、ぜひ検索してみてください！） メリットとしては、プロジェクト開始前、もしくは初期（要件定義が完了していない状態）でもある程度根拠のある見積を作成することができること。また、他の手法と比べ、時間をかけずに手早く算出することができます。そのため、プロジェクト全体の予算取りや各テスト工程の概算見積の際によく使われます。 一方、デメリットとしては、プロジェクト特有の条件が反映されづらい点、精度のブレが大きめなことなどが挙げられます。 巷でよく耳にする「エイヤで出す」というのは、だいたいはこの類推見積のパターンが多いです。 その2：　ボトムアップ見積 各成果物やタスク単位での工数を算出し、それらを積み上げて見積もる方法です。プロジェクト開発ではお馴染みのWBS（Work Breakdown Structure）はこのボトムアップ見積の代表格と言えます。 メリットとしては、成果物やタスク単位で細分化、可視化するため、納得度の高い見積を作成することができる点です。スケジュールやコストの予実管理にそのまま使えることも大きな特徴です。 デメリットとしては、プロジェクト初期での適用が難しいこと。ドキュメントや画面数など一定の基準となる単位をインプットとして用いるため、少なくとも要件定義レベルまでは完了している必要があります。また、他の手法と比べ、見積作成に手間と時間がかかるケースが多いです。 その3：　パラメトリック見積 係数モデルなどを用いて、パラメーターを設定して見積もる方法です。主な手法としては、FP法やCOCOMO法、CoBRA法などがあり、国内外問わず利用実績の多い標準的な手法であるため、係数の信頼度が高く納得性を得られやすいことが最大のメリットです。 しかし、これらを厳格に適用するためには、見積のインプット情報収集や係数設定にそれなりの経験、スキルが必要であるため、現実的にはパラメトリック見積の考え方を活かしてアレンジした見積を行うケースが多いかと思います。（この後、具体例にて説明します。） 各手法を用いた具体例 各手法を用いた見積算出のイメージについて、簡単な具体例で説明したいと思います。 その1：　類推見積での算出イメージ 例）過去実績のあるA案件をベースに、類似案件（A´案件）のテスト工数を類推見積で算出する場合 A案件の実績データ 　　テスト対象：100画面　に対して、 　　テスト設計：n人日、テスト実施：m人日 A´案件のテスト対象が300画面（＝A案件の3倍のボリューム）だった場合、テスト設計とテスト実施の工数合わせて、 （n人日＋m人日）× 3　人日 として見積もります。 その2：　ボトムアップ見積での算出イメージ 例）テスト設計の工数をボトムアップ見積で算出する場合 テスト設計の各タスクを洗い出し、それぞれの工数を積み上げます。 1画面のテスト設計につき、18h 　　― 仕様把握：2h 　　― テスト観点の抽出：4h 　　― テスト項目作成：8h 　　― レビュー：2h 　　― レビューコメントの反映：2h テスト対象は全部で10画面あるとすると、テスト設計のtotal工数は、 18h × 10画面　＝22.5 人日 となります。 この場合、1画面分のテスト設計を実際にサンプルとしてやってみた実績値を適用すると、より精度の高い見積を算出することができるでしょう。（実際のプロジェクトでは、なかなかそんなことをしている余裕はないのが現実ではありますが・・・） その3：　パラメトリック見積での算出イメージ 例）作成するテストケースのボリュームをパラメトリック見積で算出する場合 対象の機能ごとに規模感をカテゴリー分けして、重み付けを行います。 規模感：大きめの機能　→200（ケース）を設定 規模感：普通の機能　　→100（ケース）を設定 規模感：小さめの機能　→ 50（ケース）を設定 規模感：大きめの機能が10、規模感：普通の機能が50、規模感：小さめの機能が30あるとすると、 （10機能 × 200）＋（50機能 × 100）＋（30機能 × 50）＝　8,500ケース となります。 上記の例では、FP法の考え方を使った係数設定（重み付け）を行っています。この重み付けは、規模感や複雑度などある程度定量的な情報を見積結果に反映することができるため、これらのインプット情報がある場合はぜひ積極的に取り入れてみてください。 より精度の高い見積を目指すためのポイント ここまで、大きく3つの分類に分けてご紹介しましたが、それぞれメリットとデメリットがあるので、手法を組み合わせて使うことも効果的です。 見積を作成したら、以下3つのポイントに着目してチェックすることをおススメします。 見積対象や条件の洗い出しに漏れがないか 成果物やタスクなど、見積の対象、条件の洗い出しに漏れがないかの確認を行います。 よくあるのは、お客様側で対応してもらえると思って見積には含めていなかったタスク（例えば、テストデータ投入など）が実は自分たちで対応しなければならなかったことが後から発覚し、追加工数が発生する、という残念なしくじり事例です。 見積を依頼した側と見積を作成した側の認識のズレをなくすためにも、抜け漏れ確認は重要なチェックポイントと言えるでしょう。 見積根拠が明確になっているか お客様や上司が見積を確認する際に、納得性がある見積になっているでしょうか？ 算出結果の数字のみを記載するのではなく、前回のX倍のボリュームと仮定、など前提となる考え方を記載しておくと、見積作成のロジックを読み取ることができるようになります。（前提自体が誤っていた場合は、そこから軌道修正ができるようにもなります。） なぜXX人月必要なのか？、その内訳まで説明できるように根拠を明確にしておくことが重要です。 見積のPDCAサイクル化を図り、予実を照らし合わせて振り返ることが大切 見積を作成したらおしまいではなく、予実について振り返り、ギャップの原因を分析することも大切です。過去実績として「使える」見積にしておくことで、次回の案件時、より精度の高い見積を作成することができます。 見積作成→実行→予実振り返り/ギャップ分析→見積修正/データ化のように、PDCAサイクル化することで、見積の精度向上を図りましょう。 おわりに 繰り返しになりますが、テスト見積においては、漏れなく、根拠を明確に、そして予実の振り返りを行うことが大切です。 ぜひ実践してみていただけると幸いです。 最後までお読みいただき、ありがとうございました！ The post QAエンジニアが教えちゃいます！テスト見積のコツ first appeared on Sqripts .

こんにちは。GSです。 Visual Studio CodeとGitHub Copilotの組み合わせは非常に強力です。多くの人が「GitHub Copilotを使う＝コード自動補完を使う」と考えているかもしれませんが、Visual Studio Codeのアップデートにより、さらに便利な機能が使えるようになっています。これらの機能を駆使することで、Visual Studio Codeだけでより多くの作業が完結するようになりました。 これらの便利で強力な機能を踏まえ、AIと共に開発を行うための手順と実例をいくつかご紹介します。 「 GitHub Copilotを使ってみたら開発効率が劇的に向上した （Sqripts）」という記事もありますので、それを合わせて読むことで、GitHub Copilotについての理解がより深まると思います。 環境 この記事では、Pythonコードを対象としています。そのため、Pythonを実行できる環境を整え、Python向けの拡張機能をインストールしています。 以下は、今回使用した拡張機能の一覧です。 Visual Studio Code バージョン: 1.85.1 コミット: 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 日付: 2023-12-13T09:48:16.874Z Electron: 25.9.7 ElectronBuildId: 25551756 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin arm64 23.2.0 Visual Studio Code 拡張機能 Python 名前: Python ID: ms-python.python 説明: IntelliSense (Pylance), Linting, Debugging (Python Debugger), code formatting, refactoring, unit tests, and more. バージョン: 2023.22.1 パブリッシャー: Microsoft VS Marketplace リンク: https://marketplace.visualstudio.com/items?itemName=ms-python.python Pylance 名前: Pylance ID: ms-python.vscode-pylance 説明: A performant, feature-rich language server for Python in VS Code バージョン: 2023.12.1 パブリッシャー: Microsoft VS Marketplace リンク: https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance GitHub Copilot 名前: GitHub Copilot ID: GitHub.copilot 説明: Your AI pair programmer バージョン: 1.151.0 パブリッシャー: GitHub VS Marketplace リンク: https://marketplace.visualstudio.com/items?itemName=GitHub.copilot GitHub Copilot Chat 名前: GitHub Copilot Chat ID: GitHub.copilot-chat 説明: AI chat features powered by Copilot バージョン: 0.11.1 パブリッシャー: GitHub VS Marketplace リンク: https://marketplace.visualstudio.com/items?itemName=GitHub.copilot-chat GitHub Pull Requests and Issues 名前: GitHub Pull Requests and Issues ID: GitHub.vscode-pull-request-github 説明: Pull Request and Issue Provider for GitHub バージョン: 0.78.1 パブリッシャー: GitHub VS Marketplace リンク: https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github GitHub Repositories 名前: GitHub Repositories ID: GitHub.remotehub 説明: Remotely browse and edit any GitHub repository バージョン: 0.62.0 パブリッシャー: GitHub VS Marketplace リンク: https://marketplace.visualstudio.com/items?itemName=GitHub.remotehub GitHub Copilot Chatについて エージェント 解説に入る前に、GitHub Copilot Chatの重要な機能であるエージェントについて説明します。GitHub Copilot Chatは、開発者のコーディング体験を一新する「エージェント」という先進的な機能を提供します。このエージェントはAI技術を利用して、開発者との対話を通じてコード生成や問題解決をサポートします。従来のコード補完機能を超え、開発者の意図を理解し、複雑なプログラミングタスクを支援することで、GitHub Copilotは単なるツールを超えた存在へと進化しました。開発者の思考を拡張する「パートナー」としての役割を果たし、ソフトウェア開発の生産性と創造性を高める可能性を秘めています。 Visual Studio Codeの最新バージョンでは、GitHub Copilotの機能を拡張する「エージェント」機能が追加されました。この機能は、@workspace、@vscode、@terminalという3つのキーワードに関連しています。 @workspaceキーワードを使用すると、GitHub Copilotのエージェント機能はプロジェクト全体のコンテキストを把握し、コード生成に活用します。これにより、プロジェクト固有のコーディング規約やライブラリの使用方法に合わせた提案が可能になります。 @vscodeキーワードは、Visual Studio Code固有の機能や設定に関連したコード提案を行います。これはエディタのカスタマイズや拡張機能開発に特に有用です。 @terminalキーワードを使用したエージェント機能は、コマンドラインツールやスクリプト作成に関するサポートを提供します。これにより、CLIツールの使用方法やスクリプトの最適化に関する洞察が得られ、効率的な開発環境の構築や自動化スクリプトの作成をサポートします。 これらの機能により、開発者は特定のコンテキストに適したコードをより効率的に生成できるようになります。 スラッシュコマンド こちらはGitHub Copilotに対して与える命令です。GitHub Copilot Chatの画面で「/」キーを押すことで候補が表示されます。また、「@」で始まるものは前述したエージェントに関するものです。 スラッシュコマンドは、単体で実行できるものと、エージェントと併用して実行されるものの2種類に分かれます。以下は各スラッシュコマンドに関する簡単な説明です。 @workspace /explain : 選択したコードがどのように動作するかをステップバイステップで説明します。 例:  @workspace /explain function calculateDaysBetweenDates(begin, end) {...} @workspace /fix : 選択したコードのバグを修正する提案をします。 例:  @workspace /fix function calculateDaysBetweenDates(begin, end) {...} @workspace /new : 自然言語の説明に基づいて新しいプロジェクトを作成します。 例:  @workspace /new ホームページと紹介ページを持つ新しいReactアプリケーションを作成します。 @workspace /newNotebook : あなたの説明に基づいて新しいJupyter Notebookを作成します。 例:  @workspace /newNotebook pandasとmatplotlibを使用したデータ分析のためのノートブックを作成します。 @workspace /tests : 選択したコードのためのユニットテストを生成します。 例:  @workspace /tests function calculateDaysBetweenDates(begin, end) {...} @vscode /api : VS Code拡張開発に関する質問をします。 例:  @vscode /api VSCode拡張機能で新しいコマンドを作成する方法は? @terminal : 統合ターミナルで何かをする方法を説明します。 例:  @terminal npmパッケージをインストールする方法は？ 特定のエージェントを指定せずに与えられたコマンドや指示は、現在開いているファイルを対象とします。また、ファイル内のテキストを選択している場合、対象範囲は選択範囲に限定されます。さらに、命令が特定のエージェントを前提としている場合は、エージェント名が自動的に付与されます。例えば、 /tests という指示は、 @workspace /tests に置き換えられることもありますが、この置き換えは必須ではありません。Inline Chatで実行する場合は /tests だけでも実行可能です。 どこでコマンドを実行するか、またどのようなコマンドを実行するかによって、コマンドの対象となるコンテキストは変わってきます。 プロジェクトの自動作成 GitHub Copilot Chatを使用することで、指定した内容のプロジェクトを作成できます。複雑なプロジェクトを作成する場合には、「作成したいプロジェクトに関する詳細な情報」を提供する必要があります。 新規にVisual Studio Codeのウインドウを立ち上げ、GitHub Copilot Chatの拡張機能を使用してプロジェクトを作成してみましょう。プロジェクトの作成には、 @workspace /new という命令を使用します。 今回は以下の命令を用いてプロジェクトを作成します。 @workspace /new hello worldを標準出力するpythonプロジェクト。プロジェクト名はexample1。 ワークスペースの作成ボタンを押し、保存先フォルダを選択することで、ワークスペースが作成されます。 ワークスペースが作成されると、ウインドウが立ち上がってきます。 Next.jsを使用したワークスペースやFast APIを使用したワークスペースなど、フレームワーク名を指定することで、それに応じたワークスペースを作成することが可能です。 Inline Chatで自動生成 「Hello World」を出力する src/main.py を、GitHub Copilot Chatの機能の一つであるInline Chatで書き換えてみます。 src/main.py を開き、コマンドパレットからInline Chatを実行してみましょう。 Ctrl + Shift + p（MacではCommand + Shift + p）でコマンドパレットを開き、「inline chat」と入力します。すると、Inline Chatに関する候補がいくつか表示されると思うので、その中から「Inline Chat: Start Inline Chat」を選択します。 「main関数を作成し、すべての処理を含めてください」と入力し確定させると、依頼内容に沿ったコードが提案されます。 提案されたコードが適切だと思った場合は、「同意する」ボタンを押して結果を反映させましょう。もし適切でないと感じた場合は、「破棄」ボタンを押すか、新たに命令を入力して別のコードを提案してもらいましょう。 今回は、提案されたコードに同意し、さらに続けて関数を書いてもらいます。 「関数の実行時間を計測するデコレーターを作成し、main関数に適用してください」と入力し、実行してみましょう。 新たなデコレーター用関数が作成され、それがmain関数に適用されたコードが提案されました。 「同意する」ボタンを押して確定させ、コードを実行してみましょう。 GitHub Copilotへの指示に従って指定した通りのコードが作成され、問題なく実行できました。 GitHub Copilotを使用した不具合の説明・修正 先ほどのコードを一部書き換え、エラーが発生するようにしました。今回はprint関数に渡している文字列から、ダブルクオーテーションを削除してみました。 エラーに対する説明や修正依頼の方法は、一般的にヒントのアイコンから行われることが多いですが、Inline Chatを使用することで、説明と修正案の提供を同時に行うことが可能です。 エラーのある箇所にカーソルを当て、Inline Chatを起動してみましょう。今回はCtrl + i（MacではCommand + i）のショートカットキーを使用して起動します。 /fix 命令（不具合に対する修正提案コマンド）にエラーメッセージが追加された状態でInline Chatが起動します。この状態で命令を確定させると、エラーの原因から修正内容、実際の修正方法までがすべて表示されます。提案された修正内容を適用したい場合は、「同意する」ボタンを押して操作を完了させます。 ターミナルからエラー解決 ターミナルから、先ほどエラーが発生していた main.py を実行してみましょう。 小さなダイアログが表示されます。その中にある「Copilotを使用して説明する」を押すと、 次に、Inline Chatの画面が表示され、最後に実行したコマンドに関する説明が表示されます。 CLIコマンドを聞く（調べる） ターミナルを使用している際、どのようなコマンドを打つべきか知りたくなることがあります。直接Copilot Chatに質問することも可能ですが、Inline Chatを使用することでより効率的に質問し、回答を得ることができます。 今回は、このワークスペースをgitで管理するために必要なコマンドを聞いてみましょう。 ターミナルでCtrl + i（MacではCommand + i）のショートカットキーを押すとInline Chatが起動します。 「このワークスペースをgitで管理したい」と質問を入力すると、 このように、必要なコマンドを教えてもらうことができます。インターネットで検索する手間が省けるのは便利ですね。 今回は、 git init コマンドを実際に実行し、このワークスペースをgit管理対象として設定しましょう。 最後にターミナルで実行したコマンドを説明する git init コマンドを実行した後、Inline Chatを起動します。チャット欄に表示されている @terminal の後ろに続けて #terminalLastCommand を追加し、確定しましょう（ # を入力すると追加のコマンド候補が表示されます）。 実行したコマンドとその結果に関する状況を確認するのに、この方法は適しているようです。 ターミナルの文字列を選択して説明させる エラーが発生する状態のPythonファイルを実行した後、エラー内容をマウスで選択します。その後、Inline Chatを起動し、チャット欄に表示されている @terminal の後ろに続けて #terminalSelection を追加して確定させます。これにより、選択した文字列についてGitHub Copilotに説明を求めることができます。 ターミナルに表示されている文字列であれば、選択することによってGitHub Copilotに様々な説明を求めることができます。これは多くの用途に利用できる便利な機能だと思います。 GUIでコミットメッセージを自動生成 コミットメッセージを考えるのは意外と難しい作業です。しかし、GitHub Copilotには、コミットされる内容を元に自動的にコミットメッセージを提案する機能があります。 まず、すべてのファイルをコミットすることから始めましょう。 git add . git commit -m "first commit" 続いて、 src/main.py ファイルを修正します。 今回は「hello world!」というメッセージをカタカナに修正しました。 この変更を加えた後、src/main.pyを再度ステージングしましょう。 git add src/main.py Visual Studio Codeのサイドメニューからgitを開くと、コミットメッセージ欄にキラキラマークが表示されていることが確認できます。 このキラキラマークのボタンを押すと、コミットメッセージが自動的に生成されます。 コミットメッセージの統一に悩んでいるチームには、この「ボタン一発で生成されるコメントを標準とする」というアプローチも良い選択かもしれません。 コミットメッセージからその内容を推測しにくい場合は、コミットが大きすぎる可能性があります。コミットメッセージの自動生成機能を適切に利用することで、コミットのサイズも自然と小さくなる傾向があるでしょう。 CUIからコミットメッセージを自動生成 Visual Studio Codeのターミナルを使用すると、コミットメッセージを自動生成することができます。まず、ターミナルで git add src/main.py を実行してみましょう。するとターミナル上にキラキラアイコンが表示されます。このアイコンをクリックし、「コミットメッセージの生成」を選択することで、メッセージの自動生成を行うことができます。 生成されたメッセージは、そのまま git commit コマンドとして表示されます。 Inline Chatでの @terminal エージェントとの対話、各種コマンドの説明・修正、gitの拡張機能など、Visual Studio CodeのターミナルとGitHub Copilotの組み合わせは非常に強力です。別途ターミナルソフトや環境を用意する必要なく、Visual Studio Codeのターミナルだけで作業する方が効率的な場合もあるでしょう。 ドキュメント自動生成 関数や処理に自動的にドキュメントを付けることができます。 src/main.py を開き、Inline Chatから /doc を入力して確定してみましょう。 今回の例では、既存の関数に対してコメントが自動生成され、その内容が提案されました。提案されたコメントが適切だと思った場合は、「同意する」ボタンを押してコメントを確定することができます。コメントを付けることで、IntelliSense（インテリセンス）の使い勝手がさらに良くなります。関数にコメントをつけるルールを設けているチームには特におすすめの機能です。 テストコード自動生成 /tests 命令を使用して、 src/main.py に対するpytestを使用したテストコードを自動生成してみましょう。src/main.pyを開き、Inline Chatを起動します。さらに、 /tests 命令に「pytestを使用したテストコードにしてください」という指示を付け加えました。 細かな指示を与えること（今回はテストツールを指定）で、生成されるテストコードをある程度コントロールできるようです。このような指示をテンプレート化しておくと、効率的にテストコードを作成する（または作成させる）ことが可能になるかもしれません。 まとめ GitHub Copilotのエージェント機能は、開発者が抱える疑問や問題に直接対応し、解決策を提示する強力なアシスタントとして機能します。これにより、冗長な検索作業を省略し、コーディングの効率を大幅に向上させることが可能です。たとえば、新しいAPIの学習や新しいライブラリの使い方の理解が必要な場合、GitHub Copilotに問い合わせることで迅速に答えを得られます。また、コーディング中に遭遇する様々なエラーに対しては、自動的な修正提案や説明を通じてデバッグのスピードを上げることが可能です。 GitHub Copilotは単なるコード自動補完ツールにとどまらず、コードを書くユーザーを理解し、それに応じたサポートを提供する知的なパートナーのような存在です。これは特に、独学で学ぶ開発者や新しいプロジェクトに取り組む際のサポートとして非常に有効です。Visual Studio Code内で直接アクセスできるドキュメントの自動生成やテストコードの作成、コミットメッセージの提案など、開発の各ステージで潜在的なサポートを提供します。 最後に、GitHub Copilotは開発者との対話を通じて進化するAIツールです。ユーザーのフィードバックや使用パターンに基づき、より適切なサポートを提供するという点で評価されています。AIテクノロジーと人間の創造性を組み合わせることで、ソフトウェア開発の未来はより刺激的かつ効率的なものになるでしょう おまけ この文章は、プロのライターになりきったChatGPTによって校閲されました。タイトルと画像の作成も、ChatGPTとDALL-E3が担当しました。 文章校閲に使用したプロンプトは以下の通りです。 # ペルソナ プロのライター # 命令 入力文章をステップに沿って修正してください。 # ステップ 1. 誤字脱字修正 2. 全体の文章トーンを把握 3. 全体の文章スタイルを把握 4. 文章冒頭のトーン、スタイルに合わせて、全体の文章を調整 5. 修正後の文章を出力 # 入力 ${入力文章} ブログの全文を一気に貼り付ける場合も、ブロックごとに分けて貼り付ける場合も、どちらの方法を選んでも、しっかりと校閲することができます。また、「ステップバイステップ」というLLM（Large Language Models）の性能を引き出すマジックワードがあります。このマジックワードをさらに詳細に分解し、具体的な手順を書き出すことで、より高い精度での結果を期待することが可能です。「step by specified function」とでも言いましょうか。 The post Visual Studio CodeとGitHub Copilotでコーディング効率を革新！AIを駆使した開発ガイド first appeared on Sqripts .