本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第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 .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第14回目のテーマは、リーンスタートアップとDevOpsを解説します。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 ＜あらためて学びたいアジャイル開発　連載一覧＞ ※クリックで開きます 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 第13回：ソフトウェア開発における「かんばん」 第14回：さまざまな方法論 − リーンスタートアップ・DevOps リーンスタートアップ リーンスタートアップは、2011年にエリック・リースさんが考えた、主にスタートアップのための起業の開発手法です。アジャイル開発から派生した開発手法ですが、これまでの開発手法が開発寄りだったのに対し、事業やプロダクトよりの内容なので、ビジネス側の人間や起業家など、開発外の人たちに影響を与え、もう10年以上前になりますが、日本語訳がでたときは、とても話題になりました。 とくに、当時MITメディアラボの所長だった伊藤穰一氏がリーンスタートアップを、「 地図を捨ててコンパスを頼りに進め 」と例えているのも有名です。この言葉は、まさにアジャイル開発を表した言葉と言えます。 その名のとおり、リーン思考の影響をうけており、起業して開発したプロダクトに対して、成功に導く確率を高めるための方法がまとめられています。起業家だけでなく、ソフトウェアを使った新規事業を立ち上げるときにも参考になる内容です。 リーンスタートアップのサイクル リーンスタートアップのフィードバックサイクルは上の図のようになっています。アイデアができ、コードが作られ、データを集め、さらにアイデアにつなげていく流れになっています。このあたりはXPやスクラム、アジャイル開発全般の流れにとても似ていますが、データを重要視している点が、今風なスタートアップが好むところでしょう。 リーンスタートアップが広まったあとに、リーンUX、リーンキャンバスなど、たくさんのリーン系アイデアも登場するようになってきました。当時のシリコンバレーでは、リーン思考がブームになっていたのだと思います。 一方で、10年経った今、リーンスタートアップを見てみると、あまり話題になることはなくなりました。時代遅れという言葉もちらほら見かけます。リーンスタートアップの実績が国内でどれだけ出てくるのかが楽しみです。 DevOps 切り離してはならないものを切り離してしまうと、問題が起きがちです。たとえば、開発とテスト。たとえば、開発と運用です。開発と運用が別れてしまった場合、問題の多いソフトウェアをデリバリーしてしまい、運用が疲弊するといった問題が起きたりします。こういった弊害を解決する方法はずっと議論されてきましたが、そこから「DevOps」という言葉が生まれてきたのだと思います。 DevOpsについては、ここでは開発手法として列挙していますが、 Wikipedia やさまざまなイベントの発表資料を調べてみると、開発手法としてのDevOpsもあるみたいです。一昔前だと、開発と運用が分離している組織において「サーバのAdmin権限を与えるのがDevOpsだ」という意見もありました。ちょうどそういう現場で働いていたので、「権限を与える ＝ 信頼する ということなのだな」と妙に納得した記憶があります。 図は [翻訳] DevOpsにおける継続的テストとは何か？ より DevOpsは、上記の画像のように、無限大の形で表現されることが多いです。見てのとおり、左側に開発をさす「Dev」があり、右側には運用をさす「Ops」があります。それぞれのループでPlan、Branch・・・といったアクティビティが並んでおり、2つのループがつながって無限大のような形になっています。このサイクルを高速にまわすことで、改善を続けていきます。 DevOpsに関しては、画像共有サイトのフリッカーのエンジニアが発表した「 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr （意訳： 一日に10回以上デプロイする： フリッカーにおける開発と運用の協力体制）というスライドが有名です。 DevOpsが誕生する2009年の発表ですが、今見てもヒントがたくさんある内容です。当時のフリッカーはブロガーに大人気のサイトでしたが、トップクラスの企業は、日に10回もリリースするのか！と私は当時衝撃を受けました。この日に何回もデプロイ・・・というのは、現在でも継続的デリバリなどの文脈で話題になるプラクティスと言えます。そして、Flickerの発表から10年がすぎ、今では日に何回もリリースするのは当たり前になりました。 DevOpsを実現するツール DevOpsのそれぞれのカテゴリ・アクティビティは、ツールで実現できます。 コード： GitHubやGitLabなど ビルド： JenkinsなどのCIツール テスト： 自動テスト、  パッケージ ： コンテナ技術、ライブラリ管理 リリース： リリース自動化 コンフィギュレーション： インフラの自動構築、オーケストレーションツール モニター： パフォーマンスモニタリングツール これまで紹介したプラクティスとは違い、ツールで実現しようとしているのは興味深い点です。ツールを活用するのが得意な日本人であれば、DevOpsの導入障壁は比較的低いかもしれません。 DevOpsのメトリクス： デプロイ頻度 DevOpsの目標はとても具体的なメトリクス（指標）として示されています。 ひとつめの指標は、デプロイの頻度です フリッカーの事例にもありましたが、リリースの頻度をカウントします。リリース回数を数えることで、継続的な改善が行われているかどうかの目安になります。 DevOpsのメトリクス： 変更のリードタイム 2つ目は「変更のリードタイム」です。 ソースコードに変更のコミットが行われ、それが本番環境にリリースされるまでの時間をリードタイムとして計測します。これは短ければ短いほど、ユーザに価値が素早く提供されていると考えることができます。 DevOpsのメトリクス： 変更障害率 3つ目は「変更障害率」です。 いくらリリース回数が増え、リードタイムがはやくなっても、変更したときの障害が多くなってしまったらもともこもありません。回数を増やし、時間を短くするのと同時に、障害が発生する割合をかぎりなくゼロにしていく必要があります。 DevOpsのメトリクス： サービス復元時間 最後は「サービス復元時間」です。MTTR (平均復旧時間または平均修復時間)とも呼ばれます。 障害が起きてしまった場合にどれぐらいの時間で回復できるかを計測します。短ければ短いほど、ユーザーへの影響は小さくなります。 これらの目標は、4 Key Metrics と呼ばれています。 4 Key Metricsは、2022年にリリースされた最新のテクノロジー動向がまとめられた「 テクノロジーレーダー 」というレポートでも、積極的に採用すべきものとして取り上げられています。よって今後、 この4 Key Metricsが、世界中に広がっていく可能性を秘めています。 DevOpsについては、さまざまな書籍が出ていますが、今回紹介した4 Key Metricsという目標を中心に調べるとわかりやすいです。このあたりの情報がよくまとまっているのは、書籍『 LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する 』です。継続的デリバリーのJezz Hanbleさんも著者に名を連ねています。 Googleからも 4 Key Metricsのレポートが公開されています 。ご興味があれば、あわせてご確認ください。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 第13回：ソフトウェア開発における「かんばん」 第14回：さまざまな方法論 − リーンスタートアップ・DevOps The post 第14回 さまざまな方法論 − リーンスタートアップ・DevOps first appeared on Sqripts .

こんにちは。クオリティマネージャーのおすぎです。 私は中国やベトナムの企業を活用したオフショア開発プロジェクトのPMOとして活動してきました。 昨今のオフショア開発は日本企業内にノウハウが蓄積されて開発プロセスも成熟してきましたし、オフショア企業も日本企業の商習慣や品質基準の理解が進んできたことで成果物の品質も安定してきた印象があります。 いまやオフショア開発なしのソフトウェア開発に出会う方が少ないのではないでしょうか。 しかし数年前のオフショア開発では、これまでのソフトウェア開発ではあまり出会うことのなかった問題が出てくるため、日々新しい課題と向き合いながらプロジェクトを進めていました。 そんなオフショア開発でよく目にしていた事例と、その改善策の一例をご紹介いたします。 問題：動くことを優先する傾向がある オフショア開発の魅力の１つにコーディングのスピードがありますが、仕事の進め方を聞いてみるとトライ＆エラーを繰り返して作り込んでいくメンバーが多かったです。 オフショアメンバーが不慣れなプログラム言語であっても、習得速度は早くどんどん作り込んでいきます。 しかし、正しく実装しているかは受入側が慎重に確認する必要があります。色々試したけど上手く動かなかったという理由で、基本設計の方針（例えばアーキテクチャ設計）とは違った独自の設計で対応することがあるからです。 コードレビューで検出できるものもありますが、コード量が多いと見落としてしまうケースがあります。他にも動作確認すると動いているように見えてしまうためレビューが甘くなることもあります。そのためプロジェクトが進んでいくと従来の設計と独自の設計で整合が取れなくなる処理が出てくることがあります。 修正するにも工程を遡らないと修正できない重篤なバグに繋がることがあり、品質を安定させるために多くの工数が必要になってしまいます。 対策 詳細設計書を日本側で作成する、作業指示書内容を充実する、リリースされたソースコードを細部までレビューする、など対応できることは多くありますが、現実的にはその工数に耐えられないことが多いです。 このような場合はすべてを一気に解決しようとしても無理があるため、優先度をつけて段階的に解決するように進めるのが良いと思います。 一例として軽微なバグには目をつむり、重篤なバグ検出を減らすために基本設計に沿っているかという観点のみ集中してレビューする、という対策が考えられます。 効果 基本設計以外のコードレビューは優先度を下げることになるため、バグの検出数が大きく減ることはないと思いますが、重篤なバグを減らすことでバグの再指摘の件数やデグレの発生が減り、バグの消化件数が伸びていきます。 また、レビューを通じて設計の理解も深まっていき、最終的にはオフショア側の内部レビューだけで基本設計からの逸脱を予防できるようになり、品質が安定していきます。 時間の経過とともに品質が向上していくため、その後の計画も立てやすくなるのではないでしょうか。 問題：影響範囲に対する認識の違い オフショア開発をしていると商習慣や文化の違いに戸惑うことがあります。 例えば私がプログラマーとして活動していたときは、ある関数を変更する場合、その関数が使用されている処理すべてで問題ないことを確認していました。 それは誰かに指示されたりドキュメントに明記がなくてもすることと教育されていたため、プログラマーだったら当たり前の行為だと思い込んでいました。 そのため影響範囲が記載されていないドキュメントを見ても、影響範囲は調べればわかることなので気にすることはありませんでした。 オフショア開発は設計書と作業指示書をベースに作業を進めてもらうことが多いですが、影響範囲について言及しないと対応漏れに繋がり、修正を繰り返すことになってしまいます。 対策 「影響範囲を理解している日本側ですべての影響範囲を記載する」という対策も取れますが、オフショア開発を長い目で見ると問題を先送りしているだけで、次のオフショア開発でも同じ問題に直面することになるでしょう。 「影響範囲も確認するように指示する」といった意見が出ることもあります。しかし、日本人相手なら通用するかもしれませんが、オフショア開発だと指示が抽象的で上手く伝わらないケースが多いです。 「影響範囲を確認する」という依頼をする場合は、日本側が考えている影響範囲とは何か、どのようなプロセスを踏んだ結果なのか、こちらの想定や考えを含めて伝えるようにしましょう。 例えば、「この処理は他の機能でも共通で使用される」「他の機能の処理が変わらないことを確認する」「この処理の使用箇所を検索して、使用箇所すべて処理が変わっていないことを確認する」などです。 また、それらをチェックリスト形式で記載することにして、適切に実施されたのかをレビュー時に確認することを徹底すると、より良いと思います。 効果 検索の仕方まで明記するのは冗長かと思いましたが、こちらが何をしてほしいのか明確に理解できるとオフショアメンバーからは好評だったりします。 レビューを繰り返すなかで作業が定着していくものは、徐々に記載を省略できるようになりますが、チェックリストに沿って影響範囲を確認した上でリリースしてくれるようになり、品質が安定していきます。 このように作業プロセスを浸透させたり、育てていくことで品質の向上に繋がります。 さいごに ITのプロジェクトはオフショアに限らず品質に関する問題が発生するものですが、オフショアではさらに「時差」「言葉」「商習慣」「文化」の違いがあるため、より多くの問題が発生します。 特に「情報が正確に伝わらない」ことに起因する問題に頭を悩ますことが多く、今回ご紹介した事例も情報の伝達や意思疎通がきちんとできていれば回避できたのではないかと考えています。 日本人は行間を読み解いて作業を進める傾向があるので、日本側で作成したドキュメントは情報が不足している、曖昧な表現が多い、主語／述語／目的語を省略している、など誤りや勘違いを生む内容になりやすいです。 私が設計書や作業指示書を作成するときに、2つ実践していたことがあります。 1つ目は「文章で表現せずに箇条書きにする」です。 これだけで主語／述語／目的語を省略し辛いのと、表現も簡潔なものになるため翻訳も容易になりました。 2つ目はレビューです。 このような表現の問題は作成している本人では気づきにくい事が多いため、第三者にレビューして貰うことを徹底していました。 繰り返しになりますが、ITのプロジェクトは品質に関する問題が必ず発生します。 品質の問題といっても多種多様で、改善策も一括りにこれというものはなく、日々頭を悩ませていますが、今後もプロダクト品質やプロセス品質、いずれの品質問題も適切なアプローチで解決できるクオリティマネージャーになれるように精進して参りたいと思います。 【サービス紹介】 ドキュメントインスペクション ドキュメント品質にお困りのみなさまへ、第三者視点によるドキュメントレビューをサービスとして提供しています。 ■ ドキュメントインスペクションのサービス紹介はこちら ｜株式会社AGEST 「インスペクション」とは― 組織全体の品質改善スキル向上に導入効果の高い「インスペクションレビュー」を紹介 The post オフショア開発で品質向上に取り組んだこと first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はアジャイル開発におけるスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、プロダクト開発で起きたシステム課題に対して、導入の敷居が低いスプレッドシートを中心に解決を行った体験談を書きたいと思います。 エラーメッセージに関する課題 現在関わっているシステムにおいて、ある日、エラー制御に関する問題点が開発チームから上がりました。 1. 画面で表示されるメッセージの統一性が欠けている 2. システム共通のエラーコードが存在しない 詳細を解説します。 1.メッセージの統一性 例えば、データを一覧表示する画面でデータ登録件数が0件だった場合、通常は「データが登録されていません」という趣旨のメッセージが画面に表示されます。 データの種別が異なる場合でも、同じ事象のメッセージには統一性を持たせたいところですが、現在関わっているシステムでは、フロントエンドで一部メッセージをハードコーディングしており微妙に表記揺れが存在していました。 これだけだと共通処理を作って解決すればよいとはじめは思いましたが、このメッセージは運用を続ける中で、内部/外部からの指摘で変わる可能性があり、また複数言語向けにメッセージも管理したいなど、単に共通処理を作って解決は難しい状況になっていました。 2.システムのエラーコード Webシステムで使うエラーコードの代表例はHTTPステータスコードです。 例えば400エラーは BadRequest という意味ですが、複数の画面でそれぞれ起こり得る可能性があり、どの画面で400エラーが発生したかをログ等から特定したいとのことでした。 もちろん、ログの設定なり組み合わせで特定は可能ですが、パッと見て分かりにくいですし、運用メンバーがメッセージからどの画面の事象かを特定できれば運用コストの削減になります。 問題の解決方法と要件 これらの問題の解決方法として、システム全体で使うエラーコードとフロントエンドで表示するメッセージを紐づけて管理することにしました。 運用を加味して要件をまとめたところ、下記の通りとなりました。 1. 定義するデータの保存場所は、DB、テキストなど形式は問わない。 ただし、システムとして、フロントエンドとバックエンドでそれぞれ参照したい。 2. エラーコードに紐づくメッセージは、POをはじめ関係者が閲覧でき、場合によっては編集したい。 3. 今後、新機能が実装されるたびにデータを追加したい。 3.に関しては、運用次第でメッセージを変える可能性があること、運用や評価を行う上で開発者以外のメンバーも閲覧できることが必要なためとなります。 システム構成 シンプルな構成になりますが、後でマニュアルとして残すために、 GoogleCloud Developer cheat sheet を用いてシステム構成図を作成しました。 データの保存場所は、手軽に使えるスプレッドシート採用しました。 スプレッドシートは使用する敷居がとても低く、アクセス権を設定することで、直接開発に関わらないメンバーも閲覧/編集することが可能ですし、Jsonなどのテキストファイルと比べるとリポジトリへのアクセス権も不要で視認性も良いです。 ただし、スプレッドシートをシステムから直接参照するのはAPIを介した通信により様々なコストがかかるため、GAS （Google Apps Script）でJsonを生成してリポジトリにcommitする形式を採用しました。 GASのサンプルコードと注意点 GASの処理はシンプルで、フロントエンド用とバックエンド用に関数を2つ作り、後の処理は共通化して別関数に切り出しました。 一部、エラー制御は省いた主要処理のサンプルコードを掲載します。 // Slackにメッセージを送信 function notifySlack(message, filePath, type) { // SlackのWebhook URL、チャンネル名を指定 const slackWebhookPath = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_PATH'); const requestUrl = "<https://hooks.slack.com/services>" + slackWebhookPath; // Google Driveの特定のフォルダにファイルを作成 const folderId = PropertiesService.getScriptProperties().getProperty('DRIVE_FILE_PATH'); const folder = DriveApp.getFolderById(folderId); const file = folder.createFile('error_code.json', JSON.stringify(message), MimeType.PLAIN_TEXT); // 共有リンクを作成してSlackに送信 const url = file.getUrl(); const payload = { text: type + 'JSONを生成しました。共有リンクです：' + url + '\\n' + filePath + 'に貼り付けてください' }; const options = { method: 'post', contentType: 'application/json', payload: JSON.stringify(payload) }; UrlFetchApp.fetch(requestUrl, options); } // JSON生成処理 function generateJson(getErrorCodeAndInfo, filePath) { // スプレッドシートのデータを取得する const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('data'); const data = sheet.getDataRange().getValues(); // JSONを格納するオブジェクトを作成する const json = {}; // シートの各行を処理する for (let i = 2; i < data.length; i++) { const row = data[i]; const { errorCode, errorInfo } = getErrorCodeAndInfo(row); // エラーコードをオブジェクトに追加する json['data'][errorCode] = errorInfo; } return json } // バックエンド用の共通エラーコード取得処理 function backendStatus(row) { // エラーコードを取得する const errorCode = row[2]; // エラー情報を取得する const errorInfo = { 'number': row[3], 'httpStatusCode': row[4], 'httpStatus': row[5], 'message': row[6] }; return { errorCode, errorInfo }; } // フロントエンド用の処理 function frontendMessage(row) { // エラーコードを取得する const errorCode = row[2]; // フロントエンドメッセージの取得 let message = ''; if (row[7]) { message = JSON.parse(row[7]).ja } // エラー情報を取得する const errorInfo = { 'message': message }; return { errorCode, errorInfo }; } // バックエンド用の関数 function generateErrorCodeJson() { const filePath = ''; // JSONのパスを書く const type = 'システムエラーコード' const message = generateJson(backendStatus, filePath); notifySlack(message, filePath, type); } // フロントエンド用の関数 function generateFrontMessageJson() { const filePath = ''; // JSONのパスを書く const type = 'フロントエンドエラーメッセージ' const message = generateJson(frontendMessage, filePath); notifySlack(message, filePath, type); } 初期段階ではGASで生成したJSONをSlackにテキスト送信していましたが、ある程度の長さに達したら省略されてしまったため、途中でDriveに切り替えました。 また、JSONは手動でソースに反映しcommitが必要ですが、将来的にこの運用が長く組み込まれるようになった際は、CI/CDで自動で生成し配置なども検討します。 メリットとデメリット この構成のメリットは、利用の敷居が低くシンプルな構成であること、運用における変更や拡張の要望にとても柔軟に対応できることが挙げられるます。 GASなら、例えばチーム内でエンジニアメンバー以外が管理を引き継ぐ際にも、ブラウザがあればデバッグやデプロイまで出来るため、ChatGPT等でのサポートによりメンテナンスがし易いと考えています。 clasp + TypeScriptで書くのが理想ではありますが、先述の理由に加え、運用途中でシートの形式が変わることが想定され、加えてLambdaやCloudFunctionsなどに移行する未来も有り得ることから、一旦はGASのまま管理することにしました。 デメリットとして、手軽すぎる構成なので壊れやすいという点が上げられます。 例えばスプレッドシートを想定外の形式で編集された場合、GASの作りによりますが、実行が失敗してしまいます。 この場合、バリデーションを行う処理を別で準備したり、入力規則や編集不可な箇所を設定することで対策を行えます。 おわりに 今回の内容は以上となります。 既存の困っていることを解決したいという声が開発チーム内で上がったことがきっかけでしたが、運用を含めて最初はカッチリとした仕組みにせず、スピード感を持って導入し、本格運用したら徐々に見直す形をとりたいと考えています。 今回の内容がプロダクト運用において何かの参考になれば幸いです。 The post スプレッドシート × Google Apps Scriptでシステム仕様をシンプルに管理！ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第4回となる今回のテーマは「統合マネジメント」です。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 統合マネジメント 統合マネジメントという言葉は、あまり聞き慣れないかもしれませんね。 私も時折「統合マネジメントってなんですか？」「具体的に何を行えばいいのか？」といった質問を受けます。 統合マネジメントは簡潔に言うと「プロジェクトのすべての要素を調整」する活動です。 PMBOKでは「プロジェクトマネジメント・プロセス群内の各種プロセスとプロジェクトマネジメント活動の特定、定義、結合、統一、調整等を行うために必要なプロセスおよび活動」と定義されています。 プロジェクトは有期的で独自性のある活動＝ひとつとして同じプロジェクトはありません。リソース、コスト、納期、関わる人々、目的などのすべての要素を総合的に管理・調整することではじめて、プロジェクトマネジメントが実現します。 プロジェクトは固有であり、複数の利害か関与するダイナミックで複雑なものです。プロジェクトの目的を達成する為に、今どのような状態にあって何をすべきかを考える際、プロジェクト統合マネジメントが不可欠です。そして統合マネジメントはプロジェクトマネージャー固有の領域として、PM自身がその活動を担当・指揮していきます。 統合マネジメント７つのプロセス 統合マネジメントではプロジェクト活動に関する総合的なアプローチがなされます。そこではプロジェクト活動を効果的に調整するための「7つのプロセス」を定義しています。 (1) プロジェクト憲章の作成 (2) プロジェクトマネジメント計画書の作成 (3) プロジェクトへの指揮とマネジメント (4) プロジェクトに関する知識のマネジメント (5) プロジェクト実行の監視とコントロール (6) 統合変更管理の実行 (7) プロジェクトクローズ 次から各プロセスを詳しく見ていきましょう。 (1) プロジェクト憲章の作成 プロジェクトの羅針盤とも言える「プロジェクト憲章」、みなさんの組織やプロジェクトでは書いていますか？ プロジェクト憲章はプロジェクトと組織の戦略目標とを結びつけて、プロジェクトへの組織のコミットメントを示すものとされ、通常はプロジェクト初期に1度だけ作成される、プロジェクトの基礎となるドキュメントです。 1）プロジェクト憲章を作り前に行うこと（準備） プロジェクト憲章を作成するもととなる情報が必要です、それはなんでしょうか？主には前段階で作成された（されているであろう）プロジェクト作業範囲記述書（SOW：Statement of Work）やビジネスケース、外部発注の場合には契約書やSLAなどをもとに作成します。 プロジェクト憲章より前に作成された、適当なプロジェクト関連文書類を入手する 文書間の整合性や実現可能性が低い内容がないか確認する 必要に応じて、不明点等を関係者に確認したり交渉を行う 必要になる文書・情報は業種業態、企業文化、そもそもプロジェクトが発注側か受注側か、組織内プロジェクトなのかといったものによっても変わります。自身のプロジェクト憲章作成に対してどのような情報が必要かというイメージやリストを事前に持っておきましょう。 2）プロジェクト憲章に何を記載するか プロジェクト憲章に何を記載するかは、「何を明確にしておかなければならないか」と考えましょう。プロジェクト憲章に明確なフォーマットはなく、プロジェクトの規模や複雑さ、組織内のルールなどによってその記載ボリュームは増減します。プロジェクト憲章はハイレベルな記述によりプロジェクトないの共通理解とその視座をあわせます。 ここでは最適限記載して欲しい項目をご紹介します。 ビジネスニーズ プロジェクトの概要・目的/目標、終了基準 ビジネスケース（メリット） 成果物 納期とマイルストーン 条件（前提条件・制約条件） 予算（承認された財源） 主要なリスク プロジェクト組織体制 役割や権限 変更管理方法 承認者 3）プロジェクト憲章は誰が作るか問題 ドキュメントの性質からプロジェクトのイニシエーターやスポンサーが発行（作成）します。しかし組織によってはプロジェクトマネージャーが作成し、その確認/承認をスポンサーから得るという手続きが多いようです。著者の感覚としても後者の割合が高いと感じます。プロジェクト憲章の存在は前述したようにプロジェクトとPMの活動を助けるものですから、組織内の慣習を理解しながら早めはやめの作成を心がけたいものです。 (2) プロジェクトマネジメント計画書の作成 ハイレベルなプロジェクトアウトラインがプロジェクト憲章で整理されたら、次のステップとしてプロジェクトマネジメント計画書を作成し、詳細な計画作成に入ります。主にプロジェクトの実行、監視コントロール、終結についての方法を規定しますが、要約レベルでも詳細レベルでも大丈夫で、憲章と同じようにプロジェクトの特性に応じた詳細さで記述しましょう。 計画書作成の基本的なステップ (3) プロジェクトへの指揮とマネジメント 前のステップまでに整理された計画を実行に移し、その活動を指揮（リード）して成果物を作成、必要に応じて修正を加えるプロセスです。PMはプロジェクトチームへ指示を与え、会議開催や日々その進捗状況をウォッチして、プロジェクトの計画に沿って効果的に活動がなされているかを確認します。このフェーズで得られる（＝プロジェクトとして残さなければならない）以下のアウトプットを意識して進めましょう。 成果物 成果物は「固有で検証可能なプロダクト、所産、またはワービスを提供する能力で、プロセス、フェーズ、またはプロジェクトを完了するために生成したもの」と定義されます。要するにプロジェクトの成果です。 作業パフォーマンス・データ プロジェクトマネージャーは、プロジェクト実行時に得られた観測値や測定値を管理、収集し、これらはプロジェクトの資産としてこれからのプロジェクトに生かされます。 例えば） ・アクティビティの予実　→ XXタスクはX日で実施できると思っていたが、実際はその倍を要した。 ・変更要求の数　　　　→ 当該A_PJ規模での変更要求数から鑑みて、類似プロジェクトBも同等の予測ができるだろう。 課題ログ プロジェクトで挙がった課題は対応経過が追跡されると同時に、記録として残しましょう。 変更要求ログ プロジェクト実行中に挙がった変更要求もその対応経過と共に記録します。 (4) プロジェクトに関する知識のマネジメント プロジェクトに関する知識のマネジメントとは、過去に得られた情報やツールを利用したり、プロジェクトの目標達成に必要な知識を得て活用するプロセスを指します。またプロジェクト活動で新たに得られたナレッジは、その後のプロジェクトや組織に再活用され、これらを繰り返していくことが大切です。 1）プロジェクトは一から作らない 筆者の経験からも、プロジェクトを１から建てつけることはほとんどありません。プロジェクトに必要な知識や情報は社内（外）に豊富に存在します。例えばBプロジェクトの前身であるAプロジェクトに関わったXXさんであれば、Aプロジェクトのドキュメント一式にアクセスでき、教訓登録簿等などを現在のプロジェクトに活かすことができるでしょう。プロジェクトを任されたら「よし作ろう」ではなく「よし、情報収集しよう」という意識で社内の情報を集めることから始めましょう。 残念ながらそのような情報がない、蓄積されていない、という場合は自組織のプロジェクト高度化のために、知識の蓄積や管理を自組織に対して提案してみましょう。 2）暗黙知を形式知化する 暗黙知とは経験やノウハウといった、明確に表現することが難しい知識を指します。この知識を共有するには会話や相互作用が必要です。いかに暗黙知を形式知（文書化できる知識）にして生かしていくか、を意識しましょう。 3）ナレッジの源泉を引き出す プロジェクト中に起こった問題や課題、或いはこれは上手くいった、というプラスの情報も、その時期が過ぎると忘れてしまうものです。また特に不満や要求などネガティブな部分は表立って声にならないことも少なくありませんが、会社全体の成長・高度化、知識体系に貢献し、将来のプロジェクトをより良くするためにはそれらの「声」を収集することが必要です。そのためにPMはプロジェクト内で信頼関係を築くこと、つまり「発言しやすい、発言できる」雰囲気を作って、「さあ、どうぞあなたが感じたことを教えてください、もっと良くしていきましょう、よくなるはず！」という態度を示すことが重要です。例えばプロジェクト終了後のアンケートでそのような意見を収集する際などに「どのような意見であっても人事評価に影響しない、上長に記名で共有しない」などと付け加えるなども有効です。 (5) プロジェクト実行の監視とコントロール プロジェクトにおける監視とは、プロジェクトは順調か？計画通りに進んでいるか？を見る活動です。そのために活動進捗や途中結果の収集を行い、必要に応じて改善活動（予防・是正・欠陥修正）を適用していきます。 1）どのようにプロジェクトの状態を測定するか 一般的な手法として以下のような分析を行いますが、特に利用されるのが「アーンド・バリュー分析」です。今はさまざまなプロジェクト管理ツールで自動的に測定されることが多いですね。 データ分析方法例） アーンド・バリュー分析（EVM） 費用便益分析 根本原因分析 傾向分析、差異分析 プロジェクトは常に動いていますが、その動きをモニタリングし、目に見える形（データ）にすることで今の自分たちの状況と打つべき対策が明確になります。 EVM ：1960年代にアメリカで生まれたプロジェクト管理技法で、プロジェクトの計画予算と実際に発生した費用、およびそれまでに完了した作業量を対比し、コストとスケジュール実績が計画とどの程度の乖離があるのかを明確化。最終的な推定コスト・完了時期を予測する。現状から将来プロジェクトを予測する際に活用される手法です。 (！) ここではEVM作成方法や分析結果の見方（パターン）などは割愛しますが、馴染みのない方はぜひ調べてみてください。 (6) 統合変更管理の実行 変更が起こらないプロジェクトはありませんが、変更に伴う活動が適切でないとストレスや予期しない負担となります。知らないうちに追加要求をチームが受け取ってしまった、追加要求が捩じ込まれたが納期が遅れてしまう、どうしよう…といった苦い経験は想像に易いでしょう。統合変更管理の管理主眼は、それら必ず起こる変更の「ルールを決めて適切に管理すること」です。 1）その変更要求は受けるべきか、受けざるべきか？ 「XXをこう変えたい」と変更要求がなされたのには理由があるはずです。しかし、例えばその変更要求がプロジェクトスコープの範囲内か、そのプロジェクトフェーズ内で行うべきか（後続対応でよいのではないか）など評価することも同じように重要です。ある要求を受けつけるためには、別のタスクや物事に影響する場合がありますし、その影響によっては適切に「変更しない」という判断になる場合があることも忘れないでください。 また統合変更管理の活動ではそれらの変更ログを必ず文書化して、どのようにして変更要求が承認されたか、その全体的な影響、影響先を把握し、プロジェクト活動にスムーズに統合＝適応させていきましょう。 2）変更管理委員会とは？ 要求された変更（希望）内容によってはPMの権限で判断するものもあれば、プロジェクトスポンサー（オーナー）が判断するものなど様々です。事前に「XXの変更はPM承認、それ以外はPO、XXXレベルは変更管理委員会で決裁する」など事前に定義しておくとよいでしょう。変更管理委員会（CCB：Change Control Board）のメンバも事前にアサインしておきましょう。必要時に招集（MTG）し、プロジェクトからでた変更要求をレビュー、評価し、承認または却下します。 (7) プロジェクトクローズ 全てのプロジェクト作業が終了し、その活動を終えるために必要なマネジメントを指します。プロジェクトは成果物ができたら終わり、ではありません。最終的に必ずプロジェクト憲章に沿って「プロジェクトオーナーらからクローズ承認」を受けることができて初めてプロジェクトをクローズ（終結）することができます。 1）具体的なステップ プロジェクトオーナー等への活動報告 プロジェクトクローズMTG（振り返り会など） プロジェクト活動報告と終了報告書等の提出 プロジェクトナレッジの整理と保管 2）実施するクローズ活動と終結基準 プロジェクトクローズ活動をしっかりできるプロジェクトでありたいですね。形式的な活動も含まれますが、以下の活動を終結基準のチェック項目として意識しておきましょう。 全ての文書と成果物が最新状態であることを確認する 全ての課題が解決されていることを確認する（または適切に申し送り事項として管理されていることを確認する） 成果物の検修完了を確認する プロジェクトの会計を終えている（未払い等がない状態を指す） 人的資源（人員）を返却する（プロジェクトから定常業務へ配置転換する） プロジェクトで利用した各種資源の返却や再分配を行う プロジェクト報告など必要なドキュメントを作成し報告を完了する プロジェクトの知識や教訓を特定、整理し、将来活用できるよう情報保管する ステークホルダーの満足度特定（アンケートやヒアリングの実施） さいごに プロジェクト統合マネジメントは、プロジェクトの土台となる整理（プロジェクト憲章）と計画（プロジェクトマネジメント計画書）、それらの実行（実行・知識の活用、監視コントロール）と変更調整（統合変更管理）を行いながら、その目的目標を達成してプロジェクトの役割を終える（プロジェクトクローズ）に至る、一連の大きな活動サイクルです。ボリュームがありますが、一連の流れと共にプロジェクトではこういう活動が必要なんだ、というポイントを先ずは掴んでいきましょう。 次回のテーマは「スコープマネジメント」です。明確な目標設定と共有方法のコツを学んでいきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？（連載初回全文公開中） 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス The post 【第4回】プロジェクトの統合マネジメント、7つのプロセス first appeared on Sqripts .

ご無沙汰しています。Yoです。 JSTQB FLの学習は順調でしょうか。 前回 に引き続き、今回もJSTQB FL対策として、私が学習中に躓いた箇所を解説しようと思います。今回は「レビュー」に関してとなります。私が個人的に最も苦手だった箇所ですので、同じく苦手意識を持っている方の手助けができれば幸いです。 前回の記事はこちら JSTQB FL対策 弱点強化解説　～1回目～ レビューとは？ まずは「レビューとは一体何か？」という所から説明していきます。とはいえ、レビューとは何であるかについては、 詳細な解説記事 がSqripts内にあるため、そちらに解説を任せるとして、ここでは簡潔に説明をします。 「レビュー」って何をするの― さまざまなソフトウェアレビューの種類・特徴を紹介 レビューは一般的に「批評」という意味であり、成果物の確認やチェックをするといった活動です。 JSTQBシラバスにおいては、主に3章「静的テスト」にて扱われています。 テスト対象のコンポーネントやシステムを実行することは、動的テストと呼ぶ。テスト対象のコンポーネントやシステムを実行しない場合は、静的テストと呼ぶ。このため、テストは要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動も含む。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 ここではレビューも一つのテストとして紹介されています。レビューがテストであるというのはいまいちピンと来ないかもしれませんが、静的テストというものに答えがありそうです。 静的テストに関しては以下のような記載があります。 静的テスト技法では、動的テスト技法（テスト対象のソフトウェアの実行が必要）と異なり、作業成果物を人手で調査（すなわち、レビュー）したり、コードや他の作業成果物をツール主導で評価（すなわち、静的解析）したりする。 ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03 静的テストとはプログラムを動かさずにドキュメントやコードを確認するテストのこと、とのことです。確かにこう聞くとレビューも静的テストの特性と一致しています。 静的テストもテストの1つの技法であるので、その目的は欠陥を発見することにあります。つまりレビューをおおまかにまとめると、「成果物を確認し、欠陥を見つける」活動ということになります。 レビュー種類について レビューについて簡単な解説が済んだところで、この章では、レビューの種類について解説したいと思います。レビューには参加者や目的などで主に4種類に分けることができます。JITQBシラバスに記載の順序でそれぞれ説明します。こちらも詳細は過去の記事がありますので、簡潔に進めます。 非形式的レビュー 欠陥の検出を目的とし、形式的な方法に則らない方法です。他の呼び方として「バディチェック」、「ペアリング」、「ピアレビュー（ピア＝同僚）」と呼ばれるように、「知見のある同僚など」に「サッと見てもらう」という場合が非形式レビューになり、手順や成果物が厳密に決まっていないため、柔軟性があります。 例えば、隣の席の同僚などにサッと見てもらい、明らかな誤りなどがないかを確認してもらう。といったものも非形式的レビューになります。個人の印象ですが、簡単な修正のチェックや、もっと形式的なレビューの準備として行う事が多いです。 ウォークスルー 主に作成者が主導するレビューになります。レビュアーはチーム内のメンバーであることが主で、作成者が主体となり、他のメンバーがコメントや意見を述べる形式です。先に非形式という単語が出ましたが、これは手順や成果物が厳密に決まっていないという意味で、ウォークスルーは非形式なものもあれば形式的なものまで様々です。 開発やQAなどのチーム内で行うレビューというとウォークスルーの場合が多いかと思います。成果物の作成者が説明をしながら主導するため、チーム内の認識合わせといった側面もあります。また、非形式的レビューと同様に、より形式的なレビューの前段階として行われることもあります。 テクニカルレビュー 主に作成者以外が主導する形式的なレビューになります。レビュアーにも技術の専門家が参加する場合があるなど、非形式レビューやウォークスルーに比較してより専門的な視点から評価が行われるものとなります。 専門家が参加し、別の解決方法はないかなど、技術的な議論を行うことが目的となります。 ウォークスルーと比較し、専門家の関与といった点で、一般的に公式度合いがやや高いものになります。 インスペクション 形式的、という尺度で見ると最も形式的なレビューになります。スケジュール、開始と終了基準、参加者の役割といったものが決められており、作成者が他の役割を担わないなど、役割が役割やフローが厳密に定められています。更にレビューの成果をプロセス全体の改善に活用するなど、目的も成果物を精査する以上のものがあります。 指摘事項を修正し再度レビューをしたりすることもあります。イメージとしてはこれまでの3種よりもオフィシャルな場（チームの統括への報告、取引先とのレビューなど）で用いられることが主かと思います。 なぜ苦手なのか ここで少し脱線です。本シリーズは弱点強化と銘打っており、私が苦手だった箇所の解説を行っています。そこで、単に解説するだけでなくどうして苦手だったかを探ってみたいと思います。弱点を克服するヒントがあれば幸いです。 共通している内容が多い 基本的に技法の解説や、ブラックボックスかホワイトボックスかといった問題はそもそも被る内容があまりないため「それは何の説明か」という1対1の理解で事足りることが多いです。が、各レビュー手法の特徴に関しては共通する内容が非常に多く、1対1の理解では対応できないことが多いです。 例えば、レビューの目的「異なる実装方法の検討」はウォークスルーとテクニカルレビュー両方に共通する目的となるため、問題を解くにあたって「共通しているのでこの目的だけでは判断できない」ということも覚えていなければいけません。 これらの問題を解消するために、各レビューの特徴を素早く覚えられるようにまとめることが重要だと考えています。そのために以降の解説では、各レビューの特長を整理することに重点を置いて解説していきます。 問題を解く上でのポイント 上記のような分かりにくさを解消するために、いくつかポイントを絞って解説したいと思います。 目的の違いを覚える 共通の内容があるということは既に説明した通りですが、それを全て覚えるのではなく、そのレビューで固有のものを1つを覚えておくことで各レビューがどういったものか判別がつきやすくなります。 シラバスの各レビューの目的の内、固有のものは以下になります。 非形式的レビュー：影響度の小さい問題の迅速な解決 ウォークスルー：標準や仕様への準拠の評価 テクニカルレビュー：新しいアイデアの創出 インスペクション：ソフトウェア開発プロセスの改善 先ほど説明した各レビューの説明と絡めて考えると理解がしやすいかと思います。非形式レビューは「サッと見てもらう」レビューになるため、目的にもスピード感を意識したものが含まれるのが特徴です。 ここで厄介なことは、主にテクニカルレビューの「新しいアイデアの創出」についてです。ウォークスルーの目的で「さまざまな技法やスタイルに関するアイデアの交換」というものがあります。JSTQBの文言そのままであれば問題ないですが、選択肢の文章が独自のものになっていると上記二つの判別はほぼできなくなるため、目的だけでテクニカルレビューだと判断することはできなくなります。 参加者の違いを覚える 次に各レビューで特徴的なものは参加者の役割です。役割についてはシラバスでは作成者、マネージャー、ファシリテーター、レビューリーダー、レビューア、書記の6つが定義されています。それぞれのレビュー種類によってどのようになっているのか見てみましょう 非形式的レビュー：作成者と同僚によって実施 ウォークスルー：作成者が主導 テクニカルレビュー：経験を積んだファシリテーター（作成者ではない）が主導するのが理想 インスペクション：役割が明確に決まっている　※個々の詳細は割愛 それぞれ最も特徴的な部分を抜粋しています。上記のように大きく異なる点は、誰が主導するのかという点にあります。ウォークスルーとテクニカルレビューで主導する人物が変わっているという点が1つのポイントになります。 テクニカルレビューとインスペクションでは主導する人物は同じなため、その他の役割が明確かどうかという点で差が生まれます。 レビューの特徴のまとめ ここまででレビューの特徴の解説ですが、文字では把握がしにくい部分もあると思うので、以下にテーブルとしてまとめました。こうしてみると、形式度合いが上がるにつれて厳密になっているのが分かります。 レビューに参加するメリット いかがでしたでしょうか。レビュータイプの特徴について整理できたでしょうか。ここからは解説ではなく、レビューへの取り組みといった内容を解説したいと思います。 要件定義などのレビューにQAが参加することのメリットをいくつか紹介します。 第三者目線、ユーザー目線の提供 QAはユーザー目線でのテストを行うことも多いため、開発者とは異なる視点から成果物を評価することが多いです。そのため、レビューの傾向が開発者目線のリスクやアプローチに偏らないようにすることが可能です。 テストに対するリスクを早い段階で検知 更に、成果物に対してどのようにテストをするかという事を早い段階で考えることができるようになるため、テストデータの必要性であったり、ブラックボックステストでは確認が困難であるなどといったテストを行う上でのリスクを早い段階で検知できます。結果としてテストの成功にも貢献することができます。 レビューの成功要因 最後にレビューの成功要因について軽く説明させてください。シラバスにはレビューの成功要件として個別にまとめられています。それだけ重要な概念となります。ここで全てを紹介すると長くなってしまうため、最も重要と考えるものを紹介します。 シラバスには成功要因の一つとして以下のような記載があります。 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。 スキルや知識といった内容ではなく態度や心がけに近いものですが、そもそもどのような指摘やアドバイスであっても受け手が納得しなければ意味がありません。受け手が発言を受け入れられるように態度や説明には気を配る必要があります。 最後に これで今回のレビュータイプの解説を終了します。レビューが苦手と感じている方の助けになれたでしょうか。 ではまた次の記事でお会いしましょう。 The post JSTQB FL対策 弱点強化解説　～2回目～ first appeared on Sqripts .

「テスト自動化の習慣を最速で定着させるためには」と題しているこの連載ですが、今回で最終回となります。 第1回 ではテスト自動化を失敗させないための「毎日テストを回す」習慣を中心に、自動化を始める際のステップについてお伝えしました。そして 第2回 では運用可能な自動テストを作成するにあたって非常に重要な「独立性」の考え方と具体的な実装方法をご説明しました。 今回は、第2回の続きとして自動テストの作成・運用をより効率的に進めるための工夫をご紹介します。今度のキーワードは「共通化」です。日々コーディングをしている開発者の皆様にとっては重複する処理の共通化はごく当然のことですが、ノーコードツールを使ってテストを自動化するときにも同じ考え方が有効です。以下、共通化にまつわる3つの工夫をご説明します。前回まで同様、テストケースの具体例にはノーコードテストサービスのMagicPod( https://magicpod.com )を使用していますが、紹介している概念自体は特にサービス独自のものではありません。 ◆連載｜ テスト自動化の習慣を最速で定着させるためには 第1回：E2Eテストの自動化を最速で成功させる秘訣 第2回：毎日の自動テストを無理なく続けるためのキーワード 第3回：共通処理を活用してさらに効率的に自動化を進めよう 工夫1：データ駆動テスト 第1回でも触れましたが、自動テストを運用する際にむやみにテストケースを増やさないことは重要です。とはいえ、せっかく仕組みがあるのですから色々なパターンのテストを導入したいと思うのも自然なことですね。そこで、おすすめなのは少ないテストケースで大きなメリットを得られる「データ駆動テスト」の利用です。 データ駆動テストとは、テストの「手順」と「データ」を分離することで効率的にテストケースを実装する手法のことです。テストケースの中にはいくつかの変数を含めておき、その変数に入れる値（データ）を表のような形式で指定します。すると、指定したデータのパターンの数だけテストを繰り返し実行することができます。この方法を使えば、データ部分の定義を増やすだけで様々な条件のテストができますので手間のかかるテストケース部分の実装コストは非常に少なくて済みます。 データ駆動テストは非常にポピュラーな手法ですのでほとんどの自動テストツールに機能として組み込まれており、CSV等を使ってデータを定義できるようになっています。実際にMagicPodを使って試してみましょう。まず、テストケースの定義とデータの定義は以下のようになります。データは手入力もできますし、CSVファイルをアップロードすることもできます。 なお、今回のテストケースではテスト対象としてテスト自動化の学習用の練習サイトである HOTEL PLANISPHERE を利用させていただきました。ログイン情報は、サイト上で公開されているものです。 図 1　テストケースの定義 図 2　データの定義 実行した結果は、パターンごとに切り替えて確認することができます。 図 3　テスト結果の切り替え 上では説明のためにほとんど意味のない「様々なユーザIDとパスワードでログインするだけ」というテストケースを示しましたが、実際には ユーザの権限によって表示されるメニューや可能な操作が変わることを確認するテスト ECサイトなどで、購入する商品ごとにパターンを用意して購入までの操作を確認するテスト のような用途が多いかと思います。筆者のチームでは、MagicPodの利用プランに応じて表示が変わる部分のテストをデータ駆動テストで実装しています。 非常に便利でつい多用したくなるデータ駆動テストですが、注意すべき点もいくつかあります。 分岐を多用しすぎない データごとに結果が変わることをテストしたいわけですからテストケース側にはある程度の条件分岐が発生することも多いですが、あまりに分岐が多すぎるとテストケースが複雑になり、かえって何をしているのか分からなくなることもあります。結果が変わる部分についてもなるべくデータ側で表現できるように工夫し、どうしても分岐が多くなるようならテストケースを分割することも検討しましょう。（その際、次に説明する「処理の共通化」が有効になります） パターンを増やしすぎない  最初の説明とやや矛盾してしまいますが、データ駆動テストが便利なあまりになんでもかんでもE2Eテストのパターンを増やして対応しようとするのはあまり良くないパターンです。本当にシステム全体の疎通が必要なテストであれば良いのですが、可能であればE2Eテストは最低限にしてユニットテストやAPIテストで多くのパターンを網羅した方が実行時間を短くできます。 工夫2：処理の共通化 うまくはまるケースがあれば非常に強力なデータ駆動テストですが、基本的に同じ操作の繰り返しにしか使えないので様々な機能のテストを行いたい場合にはもちろん使えません。次はもう少し汎用的な方法として、テストケースの全部ではなく一部の処理を共通化して部品のように使うことを考えてみます。 共通化される処理として代表的なのはやはりログインのように頻繁に使われる処理です。それ以外にも、テストの前処理として必要なデータ作成の処理などがあれば共通化しておくと便利です。処理を共通化しておくと、新しいテストケースを作るときに作っておいた部品を呼び出すだけで良いので当然ケース作成の工数が削減できます。それ以外にも、ユーザから見て分かりやすい単位にまとめることで処理の流れを明確にするというメリットもあります。実際に、前節で使ったホテルの予約サイトのテストを通じて共通化前後のテストケースを見てみましょう。 一通りの情報を入力して予約を行うテストケースを普通に作ると、以下のようになります。 図 4　全く共通化されていないテストケース ここではデモ用のサイトで最低限の情報しか入れていないので10ステップで済んでいますが、実際のサービスをテストする際にはもっと項目が多くなるはずです。クリックやテキスト入力といった細かい粒度のステップが並んでいると、パッと見て何をしているテストなのかが分かりにくくなりがちです。 この手順を「情報の入力」と「確認・確定」に分け、さらに予約処理全体も共通化したものが次の図です。いかがでしょうか。階層化されたものをすべて展開しているので、一見するとかえって難しく見えるかもしれません。 図 5　意味のある単位で階層化されたテストケース 今度はいちばん下の階層を閉じてみました。すると、細かい処理は抽象化されてこのテストケースの概要が一目で分かるようになります。ここまで来れば、初見のメンバーがテストケースをメンテナンスすることになってもどの部分を編集すれば良いのかが分かりやすくなります。また、共通化されたステップには「宿泊数」「人数」といったパラメータが付いていることにも注目してください。このように処理の内容を変数化しておくことによって、同じ部品でも様々な値を入れて使い回すことができます。このあたりの考え方はデータ駆動テストに似ていますね。 図 6　抽象的な階層だけを表示 工夫3：画面要素の共通化 最後は、もっと小さい単位で処理ではなく操作対象の画面要素（ボタン、テキストボックスなど）を共通化するという工夫です。自動テストで画面要素を操作するときは、ロケーターやセレクターと呼ばれる記述を使って対象の要素を指定します。Webアプリケーションの場合は、HTML要素のタグの名前・ID・文字列などがロケーターの構成要素になります。たとえば、「メニュー」という文字列を含むボタンであれば「 //button[text()=’メニュー’] 」のような表現で指定できます。ロケーターの記法は色々ありますが、この例の記法は「XPath」というものです。 ここで画面要素の共通化と言っているのは、こういった要素に名前を付けておいて要素とロケーターを紐づけておく考え方のことで、Object Mapなどと呼ばれることもあります。こうやって説明してしまうと「なんだ、そんなこと当たり前じゃないか」と思われるかもしれませんが、自動テストの実装方法によっては「ステップAとステップBでは同じメニューボタンを操作している」と認識されるとは限りません。「ステップAで //button[text()=’メニュー’] をクリックする」「ステップBで //button[text()=’メニュー’] をクリックする」と、全く別個に認識されている場合もあります。 こうなっていると、もし画面の構造が変わってメニューボタンのXPathが変わった場合、呼び出しているすべての箇所のXPathを変更しなければなりませんし、そもそも呼び出している場所をすべて探すだけでも大変な作業になります。「メニューボタン」という1つの要素として認識しておけば、メニューボタンに対応するXPathを変えるだけで済むので修正が圧倒的に楽になります。ちなみにMagicPodではテスト対象の画面全体を保存しておいて使い回すことができるので、ごく自然な形で画面要素の共通化を行えます。 図 7　MagicPodにおける画面要素の共通化 共通化の本当のメリット ここまで、「テストケース全体」「よく使う処理」「画面要素」という3つの粒度での共通化を紹介してきました。最初に「自動テストの作成・運用をより効率的に進めるための工夫」とお伝えしましたが、効率的に進めるというのはテストの作成スピードが速くなるというだけのことではありません。私たちは日々変化していくソフトウェアをテストしているので、変化に応じて素早くメンテナンスを行えることは作成スピード以上に重要です。様々なレベルで共通化を行うことによって必要な変更点を最小限に抑えることで、テストケースの可読性が上がり、エキスパートでなくても容易にメンテナンスを続けることができます。 おわりに 本連載では、テスト自動化に初めてチャレンジする方をメインの対象としてテスト自動化の進め方・効率的な実装・運用方法をお伝えしてきました。本来もっと短期間で終わらせるべきところ、筆者都合で非常に期間が長くなってしまったことをお詫びいたします。 ここでお伝えしてきたことは自動化をかじったことのある方にとっては当然と思われることばかりで、物足りないと感じられた方も多いかもしれません。自動テスト関連の技術は日々進化しています。筆者がE2Eテストの自動化を仕事として始めたのは10年ほど前ですが、その頃はSelenium 2 (WebDriver)が登場していよいよWebアプリケーションのE2EテストがOSSで手軽に実践できる！と盛り上がっている時代でした。その後モバイルアプリケーションの自動テストフレームワークも充実し、さらにAIを搭載した自動テストSaaSがいくつも出てきて自動化の敷居はどんどん下がってきました。 ただ、どんなツールやサービスを使っていても、コーディングをしてもノーコードでも、最初に理解しておくべき基本的なポイントや躓きやすい点はあまり変わっていません。筆者は以前にも初めて自動化に触れるお客様へレクチャーをする仕事に従事しており、最先端の技術を追いかけるよりも自動化の敷居を下げてたくさんの方に触れていただくことの方に喜びを感じています。本連載が皆様のテスト自動化のはじめの一歩に少しでもお役に立ちましたら幸いです。 連載一覧 第1回：E2Eテストの自動化を最速で成功させる秘訣 第2回：毎日の自動テストを無理なく続けるためのキーワード 第3回：共通処理を活用してさらに効率的に自動化を進めよう The post 第3回：共通処理を活用してさらに効率的に自動化を進めよう first appeared on Sqripts .

はじめまして、QAコンサルタントのアイネイドです。 私はソフトウェア開発と開発プロセスに関する仕事を何十年もしてきました。昨年ソフトウェア品質保証に興味を持ち転職したのですが、その過程で初めて「JSTQB」というソフトウェアテストの資格があることを知りました。 今回のブログでは「JSTQB Foundation Level」の問題を解かせてみる実験を行ってみました。ChatGPTがどれだけ正確に問題を解けるか、興味深い結果が待っていますので最後までお付き合いいただければ幸いです。 1. ChatGPTに試験を受けさせようと思った理由 近年、米Chicago-Kent College of Lawに所属する研究者らは「ChatGPT-3.5」で米国司法試験(選択式)の7科目を受けさせたところ、平均正答率50%(人間の平均正答率68%)となったとのことです。このニュースを見たクオリティマネージャーの私は、同じ選択式問題である「JSTQB Foundation Level」を解くことができるのかということに興味が沸きました。 仮に合格ラインに達する事になれば、資格保持者と同等の知識レベルということになり、より仕事に活かすことができるのではないかと期待したことがChatGPTに試験を受けさせようと思った理由になります。 2. JSTQBについて JSTQBとは何か？ JSTQBについてご存じない読者もいらっしゃると思いますので、簡単に説明をします。 JSTQBは日本におけるソフトウェアテスト技術者資格認定の運営組織として2005年4月に認定されました。各国のテスト技術者認定組織が参加しているISTQB（International Software Testing Qualifications Board）の加盟組織の加盟組織の一つになります。 「JSTQB Foundation Level」の問題について 認定試験にはいくつか種類がありますが、初回ということでまず一番基礎的な「JSTQB Foundation Level」の問題に焦点を当てています。 使用する問題は公式サイト( JSTQB認定テスト技術者資格 )で公開している サンプル問題 で、問題形式は選択肢4つの選択式問題です。 なお、サンプル問題の問題の正解は選択肢Aとなっていることを覚えておいてください。 3. ChatGPTにJSTQBの問題を解かせてみた ChatGPTに問題と選択肢を読み込ませ、正解・正解の理由・他選択肢の不正解の理由を出力するように設定し、出力された内容が以下になります。 問題1 テストや操作で見かけるインシデントの一覧がある。「故障」といえるのはどれか。次の選択肢の中から１つ選びなさい。 - A. ダイアログボックスのオプションを選択した時、製品が異常終了した。 - B. 間違ったバージョンのソースコードをビルドした。 - C. 間違った入力変数を使用した計算アルゴリズムを使用した。 - D. 開発者は計算に関する要件のアルゴリズムを誤った解釈をした。 正解：A 正解の理由 ：製品が異常終了することは、明らかな故障です。他の選択肢は欠陥やエラーを指摘していますが、故障とは異なります。 不正解の理由 ： – B、C、Dは欠陥やエラーを指摘していますが、故障とは異なります。 問題2 次の説明においてテストとデバッグの違いを最も適切に説明しているのはどれか。次の選択肢の中から１つ選びなさい。 - A. テストは欠陥から発生する故障を発見する。デバッグはソフトウェアの故障の原因を発見し、解析し、除去を行う。 - B. テストは欠陥を正確に指摘する。デバッグは欠陥を解析して、事前に除去できるように提案する。 - C. テストは欠陥を除去する。デバッグは故障の原因を特定する。 - D. 動的テストは故障の原因を防ぐ。デバッグは故障を除去する。 正解：A 正解の理由 ：テストはシステムやソフトウェアの欠陥やエラーを発見するプロセスであり、テストを通じて故障が明らかになります。一方、デバッグは発見された故障の原因を特定し、解析し、除去するプロセスです。 不正解の理由 ： – Bはテストが欠陥を正確に指摘することを説明していますが、デバッグの特徴ではありません。 – Cはテストが欠陥を除去することを説明していますが、デバッグの特徴ではありません。 – Dは動的テストとデバッグの関係について説明しており、問題文とは異なります。 問題3 ツールによる静的解析の主な利点の説明文として最も適切なものはどれか。次の選択肢の中から１つ選びなさい。 - A. ツールによる静的解析は、手動によるテスト実行の前に欠陥を検出することができる。 - B. ツールによる静的解析は、ビジネスアナリストや要求エンジニアが要件と一致しないソフトウェアのモデル（状態遷移図など）を構築することを防ぐ。 - C. ツールによる静的解析により、ユーザ受け入れテストのテストケースが少なくなり、テスト実行の期間が短くなる。 - D. ツールを使ってコードの静的解析を行うことで、開発者によるユニットテスト実施のニーズは減少する。 正解：A 正解の理由 ：ツールによる静的解析は、コードやドキュメントなどのテキストを自動的に解析し、欠陥や問題を発見することができます。これにより、手動テストの前に問題を早期に検出できます。 不正解の理由： – Bは静的解析が要件と一致しないモデルを防ぐと説明していますが、主な利点ではありません。 – Cはユーザ受け入れテストのテストケースに関する話であり、主な利点ではありません。 – Dは開発者によるユニットテストのニーズに関する話であり、主な利点ではありません。 問題4 客のクレジット信用枠を決定する銀行のアプリケーションがある。このアプリケーションのテストに最も適したブラックボックステスト設計技法を、次の選択肢の中から１つ選びなさい。 - A. デシジョンテーブルテスト - B. 状態遷移テスト - C. ユースケーステスト - D. 同値分割法 正解：A 正解の理由 ：クレジット信用枠を決定するアプリケーションは、異なる条件やルールに基づいて判断を行います。デシジョンテーブルテストは、異なる条件に対するテストケースを効果的に設計するための適切な方法です。 不正解の理由 ： – Bの状態遷移テストは、状態遷移が重要な場合に使用されますが、信用枠決定アプリケーションには必ずしも適しているわけではありません。 – Cのユースケーステストは、システムの機能やユーザの操作に基づいてテストケースを設計する方法であり、信用枠決定アプリケーションには特に適していません。 – Dの同値分割法は、入力値の範囲を区切り、各範囲の代表的な値をテストする方法ですが、信用枠決定アプリケーションにはデシジョンテーブルテストの方が適しています。 問題5 テスト実行ツールの特徴に関する以下の記述のうち、キーワード駆動テスト実行ツールの特徴にもっとも当てはまるものはどれか。次の選択肢の中から１つ選びなさい。 - A. テスト入力データ、アクションワードや期待結果を含む表が、テスト対象システムの実行を制御する。 - B. テスト担当者の動作が、何度も繰り返すことができるようにスクリプトに記録される。 - C. テスト担当者の動作が、様々なテスト入力データによって実行できる。 - D. テスト結果を記録し、期待結果と比較することができる。 正解：A 正解の理由：キーワード駆動テスト実行ツールは、テストスクリプト内にキーワードやアクションワードを使用してテストケースを設計し、テスト対象システムの実行を制御します。この方法により、テストの再利用性が向上し、テストケースのメンテナンスが容易になります。 不正解の理由： – Bはテストの録画再生ツールの特徴を説明しており、キーワード駆動テスト実行ツールの特徴ではありません。 – Cはテストデータのバリエーションに関する話であり、キーワード駆動テスト実行ツールの特徴ではありません。 – Dはテスト結果の記録と比較に関する話であり、キーワード駆動テスト実行ツールの特徴ではありません。 4. 問題の正答率とChatGPTの能力 驚くべきことに「JSTQB Foundation Level」の問題に対して、ChatGPTは5問すべての問題に対して正解しました。これにより正答率は100％となり、下手をするとChatGPTは「JSTQB Foundation Level」資格保持者より正確な回答ができたのかもしれません。 ※ChatGPTが出力した正解の理由・不正解の理由には一定の信頼性があるとは思いますが正確であるとは断言できないため、サンプル問題に記載された正解の理由・不正解の理由を参照してください。 この結果より、ChatGPTはソフトウェアテストに関わる簡単な文章であれば、推敲や校閲においても力を発揮できるのではとさえ思わせる能力を持っている可能性があるのではないでしょうか。 5. 考察 前章でChatGPTの能力をベタ褒めさせていただきましたが、実は解かせる問題を選択する際に手心を加えています。 例えば問題の一部として「フロー図」がある問題は意識して除いています。図をテキストで表すことができないのかといわれるとある程度可能ですが、人間がやることになるので今回の実験からでは不確定要素と判断しました。 データだけの表であれば、下記のようにカンマ区切りにすることでテキストとして入力できますが、文字の強調やセルの色合いにも意味がある場合はテキスト化が難しい場合があります。 商品名,値段,割引額,売り場 みかん,100円,10%,生鮮食品売り場 シャンプー,300円,5%,日用品売り場 サンダル,1000円,8%,服売り場 ちなみに今回省いたフロー図の問題は以下になりますが、テキスト部分だけを入力すると、毎回のように正解とする選択肢が変わってしまいます。 プロジェクトにおけるカバレッジ目標の一つに、100%デシジョンカバレッジがある。 次の制御フローグラフに示す３つのテストを実行する。  テストA：A,B,D,F,Gのパスをカバーする  テストB：A,C,F,Gのパスをカバーする  テストC：A,C,F,C,F,C,F,Gをカバーする 次のデシジョンカバレッジ目標に関する記述のうち、説明文として最も適切なものはどれか。 次の選択肢の中から１つ選びなさい。  A. 判定（デシジョン／以下、判定）Dは完全にテストされていない。  B. 100%デシジョンカバレッジを達成する。  C. 判定Eは完全にテストされていない。   D. 判定Fは完全にテストされていない。 なお、このテキスト化の方法が正しいかどうかは不明ですが「制御フローグラフ」の図を下記のようなテキストに置き換えると正答するようになります。 制御フローグラフ A→B,Cに分岐 B→Dに遷移 C→Fに遷移 D→E,Fに分岐 E→Gに遷移 F→C,Gに遷移 また、図や表を人間の手でテキスト化した場合以外にも、回答が違ってくることがあります。(不正解の頻度は数回に一度や数十回に一度の場合もあります) このような現象になる原因の一つに「日本語の曖昧さ」があります。 日本語は主語が省略されていたり、どの単語を修飾しているか判断しづらいことがあります。ただ、今回のJSTQBのサンプル問題には英語の物もあるので、それを使用することで正答率が上がる場合もあると思います。 実は今回の結果に驚いたのは日本語の問題であるのに関わらず正解率100%だったことも原因の一つでした。 まだまだChatGPT使う側の人間が気を使わないといけないことは多そうです。 6. まとめ ChatGPTのようなOpenAIは今この時も進化を続けており、今回省いた「フロー図」の認識についても、「フロー図」を画像のまま認識するようなプラグインがあれば、今回のような手心は必要なくなる可能性もあり回答の精度もまだまだ上がっていくことでしょう。 筆者としてはそんな(おそらく近い)未来が少し楽しみです。 機会があれば次は更に上のランクの試験に挑戦させてみたり、バージョンアップしたOpenAIにさせてみたりしてみようかと考えております。 本ブログを最後まで読んでいただいてありがとうございました。 The post ChatGPTにJSTQBの問題を解かせてみた first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 筆者のnoteサイトで、「論理スキル[再]入門」を書こうと思った理由・経緯を綴っています。 ■ 論理スキル・“入門編”のこと　(T3:Pt1:Ch01) よろしかったらご覧ください。 第3回は、基本の論理演算・否定(NOT)、論理積(AND)、論理和(OR)の意味と働きを見ていきます。 各論理演算は、名前だけ見るとものすごそうに見えるかも知れませんが、ひとつひとつはそう難しい演算ではありません。まず、それぞれが「どういうことを言っているのか」を把握しましょう。日常でも同じような考え方をしている時がある筈です。 文中で「条件や主張」という表現を使っていますが、それはこれらの論理演算が文や文章のレベルでも使われるからです（第5回に記載予定）。 ＜論理スキル［再］入門　連載一覧＞ ※クリックで開きます [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか ［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ [第2回] プログラムレベルのロジック (1)概要編 否定(NOT) 否定(NOT)とは 否定(NOT)は次のような演算です。 条件や主張の 真理値を反転 する 単項演算 (演算対象がひとつの演算)  否定の演算式を、本記事では NOT(A) と表す 条件や主張Aが真ならNOT(A)は偽になり、Aが偽ならNOT(A)は真になる 日本語では、「A ではない 」、「Aである ということはない 」という語句が相当する 否定の真理値表を図3-1に示します。 真理値表(真理表、真偽表とも) とは、演算対象の真理値と演算結果の真理値をまとめた表で、”T”は真(true)、”F”は偽(false)の意味です。以下の通りであることを確認してください。 Aが真の時、NOT(A)は偽になる Aが偽の時、NOT(A)は真になる 図3-1 論理否定の真理値表 二重否定 二重否定(否定の否定)は、もとの真理値と同じ値になります（もとの真理値に戻る）。（図3-2） Aが真の時、NOT(NOT(A))は真 Aが偽の時、NOT(NOT(A))は偽 図3-2 二重否定の真理値表 否定の留意点 否定そのものではありませんが、数値の範囲を表す表現の否定は、以下のようになります。（図3-3） 「以上」の否定は、“以上で(は)ない”＝“より小さい”＝「未満」 「xが10以上(x >= 10)」という条件式の否定は「x < 10」 「以下」の否定は、“以下で(は)ない”＝“より大きい”＝「超」  「yが50以下(y <= 50)」という条件式の否定は「y > 50」 上記の逆で、未満の否定は「以上」、超の否定は「以下」。   「超」という語はあまり日常会話的ではないが、ソフトウェアではよく使われる 日常で使う場合は、この辺りの大小・含む含まないの関係を“曖昧に”表し/解釈することがままあります。（第5回に記載予定） 日常で使う時の「否定」の、論理の言葉としての意味合いとの違いも、第5回で取り上げます 図3-3 以上/以下の否定は、未満/超 論理積(AND) 論理積(AND)とは 論理積(AND)は次のような演算です。 条件や主張A, Bがともに真である時に結果が真、そうでない場合には結果が偽になる 二項演算 (演算対象がふたつの演算) 論理積の演算式を、本記事では A AND B と表す 「ふたつの条件が同時に成り立つ(必要がある)場合」「ふたつの条件がともに必要である場合」などを表すのに用いる 日本語では、「 および 」「 かつ 」「 ならびに 」「 そして 」などの接続語が相当する  「そして」は時間的順序を表す意味もあるので注意が必要です 論理積の真理値表を図3-4に示します。 表の1行目が「A, Bがともに真の時」 2～4行目が「そうでない(A, Bがともに真、ではない)場合」 “A, Bどちらかが偽”である場合を含む 図3-4 論理積の真理値表 演算対象が三つ以上の場合 論理積は二項演算ですが、演算対象が三個以上になっても同じように考えることができます。（三条件の論理積の真理値表は図3-5参照） 演算対象が すべて真の時、結果が真 そうでない場合(＝どれかひとつ以上が偽の場合)、結果は偽 図3-5 論理積(三条件)の真理値表 論理和(OR) 論理和(OR)とは 論理和(OR)は次のような演算です。 条件や主張A, Bのどちらかが真である時に結果が真、そうでない場合には結果が偽になる 二項演算 論理和の演算式を、本記事では A OR B と表す 「ふたつの条件のどちらかが成り立つ(必要がある)場合」「ふたつの条件のうちどちらかが必要である場合」などを表すのに用いる（「どちらかが成り立てばよい」と理解しても差し支えないことも多い） 日本語では「 または 」「 あるいは 」「 ないし 」などの接続語が相当する 「ないし」は数量の範囲を表す意味もあるので注意が必要です（第5回に記載予定） 論理和の真理値表を図3-6に示します。 表の1～3行目が「A, Bのどちらかが真である時」 “A, Bがともに真”である場合を含む 4行目が「そうでない(A, Bのどちらかが真、ではない)場合」 図3-6 論理和の真理値表 演算対象が三つ以上の場合 論理和は二項演算ですが、演算対象が三個以上になっても同じように考えることができます。（三条件の論理和の真理値表は図3-7参照） 演算対象が どれがひとつ以上が真の時、結果が真 そうでない場合(＝すべてが偽の場合)、結果は偽 図3-7 論理和(三条件)の真理値表 論理演算で表す例 第1回で出てきた「登録できるユーザーアカウント名」の例を見てみましょう。 登録できるユーザーアカウント名には以下の条件があります。 (a) アカウント名に使える文字は以下のいずれかに限ること 半角英大文字(A～Z), 半角英小文字(a～z), 半角数字(0～9) (b) アカウント名は16文字以下であること (c) 既に登録済みのアカウント名は登録できない a, b, cの条件をすべて満たしているときに登録できる(3条件の論理積)、と解釈すると（条件aはいったん「使用可能な文字だけで構成されている」と置き換えます）、 使用可能な文字だけで構成されている AND 16文字以下である AND NOT(既に登録済み) といった形に表せます。 条件a「使用可能な文字だけで構成されている」を展開すると 半角英大文字である OR 半角英小文字である OR 半角数字である となります。 条件bを「16文字を越えていないこと」と読んで、否定を使って NOT(16文字を超えている) と表すこともできます。 むすび 例が既にそうなっていますが、これらの論理演算は組合せて使うことが多いです。 第4回では、この「論理演算の組み合わせ」の扱い方や、憶えておきたいことを見ていきます。 参考文献 『プログラミング言語C　第2版』(カーニハン, リッチー / 共立出版) 『プログラミング言語AWK』(エイホ, ワインバーガー, カーニハン / USP研究所) JavaScript リファレンス (Webページ) https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference 否定は「単項演算子」のカテゴリーで「論理否定」として、論理積と論理和は「バイナリー論理演算子」というカテゴリーで取り上げられている。（この「バイナリー」は二項演算の意か） Python 言語リファレンス (Webページ) https://docs.python.org/ja/3/reference/index.html 「6.11. ブール演算 (boolean operation)」で取り上げられている。 『スマリヤン先生のブール代数入門』(スマリヤン / 共立出版) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) 『入門！論理学』(野矢茂樹 / 中央公論新社) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 The post [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 first appeared on Sqripts .

はじめまして。四十路にしてブログデビューのおつばです。 よろしくお願いします。 日々のちょっとした作業。いつも通りに手作業で対応してもそこまで時間はかからない。だけどこのちょっとが面倒に感じていること。ちょっとだから後回しにして結局遅れたり忘れたりしてしまうこと。皆さんもありませんか？ありますよね？・・あるってことで進めていいですね？笑 そんなちょっとした作業を自動化することで煩わしさから解放されて、対応遅れや忘れのヒューマンエラー要因のミスも軽減する。そんなことを目的として取り組んでいるプチ効率化の中から、今回は「定型メールをGoogleForm上での選択操作から自動作成＆送信する方法」をご紹介します。 前提 業務で使用するPCには特別なツール類をインストールできない事が多いかと思います。そこで、Googleアカウントがあれば実現できるGAS（GoogleAppsScript）を使用した定型メール自動作成を、当日勤怠連絡メールをサンプルとしてご紹介していきます。 流れとしては以下のような順で進めていきます。 ・必要なものを準備 　　→Googleアカウントを用意 　　→入力用となるGoogleFormを作成 　　→GoogleFormの回答を出力するスプレッドシートを作成 　　→スプレッドシートにメール定型文のベースを追加 ・GASっていく 　　→ソースコードをコピペして編集 　　→処理実行のトリガーを設定 　　→実行してみよう 「GASって何？」の説明は本記事では割愛させてください。GASをテーマにした他の記事でもご紹介していますので、是非ご覧いただければと思います。 ■ GoogleAppsScriptを使ってテスト項目書の体裁を一発で整える </Sqripts> ■ 業務改善にはコレ！＼Google Apps Script／ </Sqripts> 必要なものを準備 GASのコードを書く前に、まずは必要なものを準備をしていきます。 ＜用意するもの＞ Googleアカウント （Google先生ありがとう） Chromeブラウザ （Google先生ありがとう） 少しのやる気 （何気に一番大事） ＜作成しておくもの＞ ① GoogleForm （メール自動作成＆送信の操作用） ② メール定型文 （自動作成する定型メールのベース） 作成しておくもの ①GoogleForm まずは操作用のGoogleFormの作成です。 勤怠連絡メールとなると、状況に応じて連絡内容や宛先が変わってきますので、以下の回答項目があるGoogleFormを作成します。 ＜回答項目＞ 連絡先　：連絡先メールアドレス　を追加 休暇区分：全休、午前半休、午後半休　の選択肢を追加 休暇事由：私用 / 体調不良 / 急用　の選択肢を追加 今回はGASをスプレッドシートに仕込みますので、Formの「回答の送信先を選択」の設定から、スプレッドシートに回答が記録される設定にしておきます。 作成しておくもの ②メール定型文 ①の最後に用意した回答記録用のスプレッドシートを開いて、ベースとなるメール定型文を記載したシートを追加します。「メール定型文」の名前でシートを追加し、A1セルにメール本文の文章を入力してください。 メール文面中の名前、日付、休暇区分、休暇事由が入る箇所は、GoogleFormで選択した項目をGASの処理で自動的に置換して本文に反映させるため、置換処理用キーワードを入れておきます。 ＜置換処理用キーワード＞ 名前：★NAME★ 本日：★DATE★ 休暇事由：★CAUSE★ 休暇区分：★CLASSIFICATION★ GASっていく いよいよGASっていきましょう。先ほど用意した回答記録用のスプレッドシートにて「拡張機能」-「Apps Script」を選択してスクリプトエディタを開き、次のソースコードをまずはコピペしてください。 ソースコード全体 function Send_AttendanceMail(){ //定数 const SUBJECT_HEAD = '【勤怠連絡】'; const NAME = 'おつば'; const MY_ADDRESS = 'o-tsuba@agest.co.jp'; const MAILBODY_SHEETNAME = 'メール定型文'; const MAILBODY_REPLACE_NAME = '★NAME★'; const MAILBODY_REPLACE_DATE = '★DATE★'; const MAILBODY_REPLACE_CAUSE = '★CAUSE★'; const MAILBODY_REPLACE_CLASSIFICATION = '★CLASSIFICATION★'; //対象シートを取得 let DataSheet = SpreadsheetApp.getActiveSheet(); //基準セルを取得（最終行、先頭列） let BaseCell = DataSheet.getRange(DataSheet.getLastRow(), 1); //連絡先 let MailTo = BaseCell.offset(0, 1).getValue(); //休暇区分 let Classification = BaseCell.offset(0, 2).getValue(); //休暇事由 let Cause = BaseCell.offset(0, 3).getValue(); //MailCc let MailCc = MY_ADDRESS; let mailArgs = {cc:MailCc}; //件名 let Today = Utilities.formatDate(new Date(), "JST", "MM/dd"); let MailSubject = SUBJECT_HEAD + ' ' + NAME + ' ' + Today + ' ' + Classification; //対象シート（メール定型文シート）設定 let MailBodySheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(MAILBODY_SHEETNAME); //本文 let MailBody = MailBodySheet.getRange(1, 1).getValue(); //メール本文内の文字列置換 if(MailBody.match(MAILBODY_REPLACE_NAME)){ MailBody = MailBody.replace(MAILBODY_REPLACE_NAME, NAME); } if(MailBody.match(MAILBODY_REPLACE_DATE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_DATE, Today); } if(MailBody.match(MAILBODY_REPLACE_CAUSE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CAUSE, Cause); } if(MailBody.match(MAILBODY_REPLACE_CLASSIFICATION)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CLASSIFICATION, Classification); } //メール送信 GmailApp.sendEmail(MailTo, MailSubject, MailBody, mailArgs); } 部分的に解説 定数の宣言部分 //定数 const SUBJECT_HEAD = '【勤怠連絡】'; const NAME = 'おつば'; const MY_ADDRESS = 'o-tsuba@agest.co.jp'; const MAILBODY_SHEETNAME = 'メール定型文'; const MAILBODY_REPLACE_NAME = '★NAME★'; const MAILBODY_REPLACE_DATE = '★DATE★'; const MAILBODY_REPLACE_CAUSE = '★CAUSE★'; const MAILBODY_REPLACE_CLASSIFICATION = '★CLASSIFICATION★'; ソースコードの先頭で定数を宣言しています。この定数のうち、上から3つは値を変更してください。 ・SUBJECT_HEAD： メール件名の先頭に付ける文字列です。連絡ルールに合わせて変更してください。 ・NAME： メール件名や本文に入る名前です。ご自身の名前に変更してください。 ・MY_ADDRESS： メールアドレスです。ご自身のメールアドレスに変更してください。 （※サンプルですので、記載のアドレスは存在しません。） 上記以外の定数は、先ほどの「作成しておくもの②」で整えた内容に合わせていますので、特に変更する必要はありません。 以降のコードは変更せずともコピペのままで動作しますが、処理の内容を順番に説明していきます。 スプレッドシートからの取得部分 //対象シートを取得 let DataSheet = SpreadsheetApp.getActiveSheet(); //基準セルを取得（最終行、先頭列） let BaseCell = DataSheet.getRange(DataSheet.getLastRow(), 1); //連絡先 let MailTo = BaseCell.offset(0, 1).getValue(); //休暇区分 let Classification = BaseCell.offset(0, 2).getValue(); //休暇事由 let Cause = BaseCell.offset(0, 3).getValue(); //MailCc let MailCc = MY_ADDRESS; let mailArgs = {cc:MailCc}; Form回答が記入されたシートを対象として取得します。 そのシートから最終行、先頭列（つまり直近の回答が入っている列の先頭）を基準にするセルとして取得して変数に代入します。その基準セルから1列ずつ右にズレながら、連絡先，休暇区分，休暇事由，のForm回答内容をそれぞれ取得して変数に代入していきます。 最後に、自身のメールアドレスをCcの宛先として変数に代入します。 件名と本文 //件名 let Today = Utilities.formatDate(new Date(), "JST", "MM/dd"); let MailSubject = SUBJECT_HEAD + ' ' + NAME + ' ' + Today + ' ' + Classification; //対象シート（メール定型文シート）設定 let MailBodySheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(MAILBODY_SHEETNAME); //本文 let MailBody = MailBodySheet.getRange(1, 1).getValue(); 当日の月日を取得して変数に代入し、先頭に付ける文字（定数）＋名前（定数）＋日付（当日）＋休暇区分（シートから取得）の件名を作ります。それぞれの間にスペースを入れるため、定数や変数の間に「 + ‘ ‘ + 」を入れて繋いでいます。 本文は、「メール定型文」シートに用意したセルの値をまずはそのまま取得します。 本文内の対象文字を置換 //メール本文内の文字列置換 if(MailBody.match(MAILBODY_REPLACE_NAME)){ MailBody = MailBody.replace(MAILBODY_REPLACE_NAME, NAME); } if(MailBody.match(MAILBODY_REPLACE_DATE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_DATE, Today); } if(MailBody.match(MAILBODY_REPLACE_CAUSE)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CAUSE, Cause); } if(MailBody.match(MAILBODY_REPLACE_CLASSIFICATION)){ MailBody = MailBody.replace(MAILBODY_REPLACE_CLASSIFICATION, Classification); } 先ほど取得した定型文メール本文の中には「作成しておくもの②」で用意したように、まだ置換処理用のキーワードが入った状態ですので、対象の文字を置換します。この処理を行うことで、GoogleFormで選択した各項目の値、名前、日付がメール本文に反映されます。 メール送信 //メール送信 GmailApp.sendEmail(MailTo, MailSubject, MailBody, mailArgs); ここまでで「Toの宛先」「件名」「本文」「Ccの宛先」が揃いましたので、あとはメールを送信するためのsendEmail関数にそれぞれの値を引数として指定します。 これでGASのソースコードが完成です！ トリガーを設定 ソースコードが整ったら、あとはこの処理を実行するタイミングを指定するために、スクリプトエディタにてトリガーを設定します。今回はGoogleFormを使用しているので、Formで送信を押したタイミングで動作させます。トリガーに以下を設定してください。 実行する関数を選択：先ほど書いたコードの関数「Send_AttendanceMail」を設定 イベントの種類を選択：「フォーム送信時」を設定 それ以外はデフォルトのままでOK 実行してみよう ソースコードと設定が整ったら、GoogleFormから送信をしてみましょう。Form上の選択通りの宛先と内容で定型メールが自動送信されることが確認できると思います。 スマホでGoogleForm回答用URLを開くショートカットを用意しておくと便利です。 ショートカットを選択→開いたGoogleFormで各項目を選択＆送信、の数回ポチポチっとするだけで勤怠連絡メールが送信できます。メールアプリを開いて手動で文章入力を行うよりも早いことが実感できるかと思います！ Slackにも投げてみる と、ここまで書き上げたところで、「Slackチャンネルにも投稿できると便利だと思うんだよなぁ。」そんな天のお告げを受けたので、参考情報として以下2つの方法を簡単にご紹介します。 Slackに投稿する方法 ＜方法Ａ＞ Slackにメール送信するための機能がいくつか用意されています。一部Slack有料プラン用の機能もありますが、こちらを活用することでメール送信からのSlack投稿を実現できます。 [Slackヘルプセンター] Slackにメール送信する ＜方法Ｂ＞ Slackのアプリケーションを追加して「IncomingWebhooks」を設定、HTTPリクエストを送るGASソースコードを書く、ことでメール送信と合わせてSlack投稿を実現できます。 ①Slack上の設定： 　Slackの対象ページを開いてアプリケーションを追加、設定する。 https://api.slack.com/appsを開く 「Create New Apps」からアプリ作成 作成したアプリのIncomingWebhooksを On に設定 投稿したいチャンネルを設定追加して専用のURLを生成 ②GASソースコード： 　「Post_Slack」関数を作成してメール用に用意した件名と本文をSlack投稿する。 メール送信の下にソースコードを追加する（件名と本文を引数で渡す） //メール送信 GmailApp.sendEmail(MailTo, MailSubject, MailBody, mailArgs); //　★ ↓ コレ ↓ ★ Post_Slack(MailSubject + '\n' + MailBody); //「\n」で改行 } 「Post_Slack」関数を追加する 　　件名、本文のデータを処理用のパラメータに整える 　　SlackUrlFetchAppクラスのfetchメソッドを使ってHTTPリクエストを送る 　　「’★ココはSlack設定で生成したURL★’」の箇所は①で生成したURLに置き換える function Post_Slack(PostText) { //WebhookのURL let SlackWebhooksUrl = '★ココはSlack設定で生成したURL★'; //引数で受け取った投稿用メッセージを代入 let Payload = { 'text': PostText }; //Slack投稿のメソッドに渡すパラメータを作成 let Parameters = { 'method': 'post', 'payload': JSON.stringify(Payload) }; //Slack投稿 UrlFetchApp.fetch(SlackWebhooksUrl, Parameters); } おわりに いかがでしたでしょうか。 スクリプトのソースコードを書くとなると、あまり経験が無いとちょっとハードルが高く感じがちですが、今回見ていただいたサンプルはソースコード量としては多くはないですし、順を追って見ていくとそこまで複雑な処理も無かったのではないかなと思います。 今回は簡単な当日勤怠連絡メールとSlack投稿をサンプルとして紹介しましたが、自分の作業に当てはめると「もっとこうしたい」「この定型メールも対応できるようにしたい」など、やりたいことが思い浮かぶかと思います。想像したことを形にできてそれが成果として表れると、より一層のやる気にも繋がります。 この記事でGASに興味を持っていただけたら、作業効率化のネタとしてお役に立てれば、幸いです。 またGASネタ、効率化ネタをご紹介できればと思っています。 最後までご覧いただきありがとうございました。 The post それ、GASっちゃえば？　－定型メールはGoogleForm操作で送信－ first appeared on Sqripts .

1人目QAとしての立ち回り、第3回となる今回は、QAエンジニアや品質保証のことを開発組織に知ってもらうための取り組みについてご紹介します。 前回の記事 では、1人目のQAは開発組織に対して品質文化を浸透させる役割を求められる、と書きました。しかし、「文化の浸透」という大きなことを、一足飛びに実現するのは困難です。 「品質のことを考えよう」「改善活動を行おう」と組織全体に訴えかける前に、まずは品質やQAエンジニアについて、知ってもらうところから始めることが大切です。 ＜1人目QAとしての立ち回り　連載一覧＞ ※クリックで開きます 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ QAエンジニアという“異分子” 1人目QAとして開発組織に加わった場合、周りの開発者からみると、QAエンジニアは「謎の存在」あるいは「異分子」と表現してもいいかもしれません。 いったい何をする存在なのか、居ることによって自分たちにどのようなメリットがあるのか、などが不明確な状態です。 もし中途として採用されたのであれば、組織のトップや一部のマネージャーなどは、QAエンジニアの存在意義や行動についてなんらかの期待をもっているでしょう。あるいは、社内でのジョブチェンジとしてQAエンジニアになった場合も、なんらかのミッションを負っているはずです。つまり、1人目QA本人は、すくなくともぼんやりとは「何をする人なのか」をわかっているはずです。 しかし、周囲はそうではありません。もしかしたら「前職でQAエンジニアにあまり良い印象がなかったんだよね」とか、「テストしてくれる人でしょ？」なんてイメージを持っている可能性すらあります。 「相手はわかってくれているはずだ」という思い込みがキケンなのは、QAエンジニアに限らずお仕事の基本です。そのため、1人目QAは自分自身が「謎の存在である」という気持ちで、周りに認知されるよう動くことが必要です。 開発組織に認知してもらうには 周囲に認知してもらうために1人目QAができることはいろいろとあります。ここでは、私自身が1人目QAとして行ったことや、周囲のQAと情報交換をする中で複数人が実践していた方法について説明します。 なお、以下の方法はいずれか1つを行えばよいというものではありません。複数のチャネルで多方面から発信することで、より効果を発揮します。 ミーティングへの参加など、直接会話する もっとも強力な方法は、直接話をすることです。これは皆さんの実感とも合っているのではないでしょうか。 会ったことがある、話をしたことがある、というのは相手との関係性を良くするうえでとても重要です。とくに1人目のQAとしてさまざまな品質向上活動をしていく場合、開発者に工数を割いてもらったり、いままでのやり方を変えてもらったりと、拒否反応を示される可能性のあるタイミングが多々あります。そうしたときに快く協力してもらえるか、しぶしぶ協力してもらえるか、あるいは協力してもらえないのか・・・この結果は会話の量に大きく左右されます。 会話の機会を持つ方法として私が実践したのが、Joinしてすぐに行った「全開発部ヒアリング」です。これはその名前の通り、すべての開発部に対して「今どのような流れで開発していますか？」「どのようなテストをしていますか？」「品質について困っていたりしますか？」など、いろいろな内容を直接会議をして聞くというものです。また会議の冒頭10分程度では自己紹介やQAエンジニアの位置づけ、今後どう貢献したいかなどを説明し、ヒアリングとあわせて相互理解の機会として活用しました。 私は横断部門の1人目QAとして仕事をしているため、上記の方法を取りました。もし個別の開発部における1人目QAとしてJoinした場合や、会社規模がそれほど大きくなく開発組織が1つという場合は、「全員と1on1ミーティングをする」という手段も検討できるでしょう。部単位での代表者からのヒアリングと比べて、より深い話ができ、つながりも強化できるでしょう。 その他、上司や同僚のスケジュールを常にチェックしておき、呼ばれていない会議でも自分から突撃する、という強者QAも居ます。その方はオープンスペースから「テストが～」等関係ありそうな単語が漏れ聞こえてきたときにも話に入っていったそうです。 勉強会や輪読会の開催 ミーティングへの参加に近いものとして、QAエンジニアとして勉強会や輪読会を開催する、という方法もあります。 一般で行われているのは、JSTQBのシラバスを輪読したり、とくに若手の開発者に対して「品質とは？」や「テストとは？」といった内容を伝える勉強会などです。私自身も入社直後から継続的に勉強会を開いています。 勉強会や輪読会というと、知識を伝えるというイメージを持たれるかもしれません。確かに、ソフトウェアテストやQAに関しては開発者よりもQAエンジニアのほうが詳しいことが多いでしょうし、QAとしての視点で伝えられることはたくさんあります。しかし、私は勉強会や輪読会はただの勉強の場ではなく、むしろ生の情報や思いを直接やりとりするコミュニケーションの場だと捉えています。 生の情報、というのはつまり、現場で実際に開発業務を行っている方の視点での情報です。「今こんなことで困っていて」や「本にはこう書いてあるけど、実際にはそううまくもいかなくて・・・」など、先に挙げたヒアリングよりもカジュアルな形で本音が聞ける可能性があります。勉強会で伝えている内容や輪読会で読んでいる本の内容はあくまでもトリガーであり、より価値があるのはそこから出てくる開発者の本音や声、だと考えています。 また、開催している側から参加者に対しては、思いや熱量を伝える機会でもあります。1人目のQAとして、組織をこう変えていきたい。こんなことをやっていきたい。そのような思いというのは、1回や2回全体周知をしたところで伝わりません。むしろ個別に、頻繁に、何度も伝えてやっと浸透していくものです。そのため、品質文化を浸透させるという大目標には、こうした勉強会や輪読会の場を活用することも有効です。 少し大きな話になりましたが、純粋に接触機会が増えるため、QAエンジニアや品質に関する認知、という点でももちろん有効です。 ちなみに私は勉強会・輪読会の他に「ライブテスティング会」も開催しています。これは、開発チームに提供してもらった実際のアプリケーションを、ビデオ会議で画面共有しながら探索的テストをするというものです。テストする側も、される側も、かなり緊張するイベントなのですが、QAエンジニアやテストエンジニアが何を考えてどうテストしているのかを生で見てもらう良い機会になっています。こちらも認知という意味ではとてもオススメです。 品質やテストに関するナレッジベースをつくり、育てる 上記の2つは、同期的に何かを伝えて認知してもらう、いわばアクティブな方法でした。しかし、アクティブな方法だけでは限界があります。ほぼ自分が会議や勉強会をしている間しか、認知の向上につながらない、という点です。 そこで私がオススメしたいのは、社内Wikiなどに品質やテストに関するナレッジベースをつくり、育てていくことです。このナレッジベースはいわば1人目QAの分身のようなものです。 テストに関する用語や考え方、社外の動向やツールのノウハウなど、知り得るいろいろな情報を残しておきます。こうすることで、組織の誰もが好きなタイミングで情報にアクセスでき、そこから「＊＊＊について相談したい」「＊＊＊について教えて」といった声がけを得られる可能性が出てきます。 また、このナレッジベースは基本的に年中無休です。1人目QA本人が何か別の仕事をしている間にも、誰かがそれを見て問題を解決できるかもしれませんし、知りたかった情報を得られるかもしれません。これによって、知らない間に誰かの役にたち、認知向上につながることもあります。 複数のチャネルで接触機会を増やしつつ、QAを知ってもらおう 今回は品質やテスト、それからQAエンジニアについて、開発組織内で認知してもらう際に有効な取り組みについてご紹介しました。 本記事で挙げた他にも、できることはあると思います。方法やチャネルは複数持つことが有効です。直接対話する機会を持ちつつも、ナレッジ等はできる限り多く、かつ見える形で公開しておいて接触機会を増やすようにしましょう。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ The post 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み first appeared on Sqripts .

はじめまして、QAエンジニアのK.Kです。 今回は10年ぶりに改訂された「知識ゼロから学ぶソフトウェアテスト」を読んだ感想をお伝えします。 www.shoeisha.co.jp この本を読むきっかけ 私にとって、この本はこれからソフトウェアテストを学ぶ人におすすめの入門書であり、10年ぶりに改訂されたとのことで気になっていました。また、改定内容もソフトウェア業界で流行りのアジャイル開発・AIを取り上げたもので、日々の業務で役に立つのではと考え、この本を読もうと思いました。 ※1 ※1 私自身、業務の中でアジャイル開発に触れる機会が増えているように感じています。また、AIに関してもいろいろなサービスが出てきており流行りを感じています。実際、既にAIのサービスを使っており、わからないことがあればすぐChatGPTに聞いたりしています。 改定内容 全体的な章の構成は大きく変わっておらず、これからソフトウェアテストを学ぶ人にとって必要な知識が書かれているため、各章について紹介していきたいところですが、以前、別の方が改定前の書籍をブログで紹介していましたので、今回は改定箇所の内容に絞って書いていきます。 改定箇所以外の内容について興味がある方は下記の記事を読んでみてください。 知らなきゃモグリ!?テストのプロはみんな読んでいるバイブルを紹介 10年ぶりに改訂された理由 10年ぶりに改訂された理由が冒頭に書かれています。 ※以下引用は第3版「知識ゼロから学ぶソフトウェアテスト」より 10年以上改訂しなかったことに、ある日突然気づいた。結構世の中は変わっているぞ！ 10年前に書いたときはベストだと思った記述の多くは、現代のアジャイルやAIソフトウェア全盛にそぐわなくなってきている。 開発サイクルが短くなるだけでこんなに世界が変わるものかとも驚いている。 10年でソフトウェアテストが大きく変化しているため、現在のソフトウェアテストに合わせた記述にする必要があるとのことです。 また、現在のソフトウェアテストについて以下のように書かれています。 アジャイル時代になり多くのテスト活動が開発者テストにシフトしているが、ソフトウェアのサイズは増え続けているので、テスト担当者の仕事は減ることなく多岐にわたっている アジャイルにシフトしたために多くの古くからのテスト手法がおざなりにされているが、当書で記した既存のテスト手法はアジャイル時代でも有効である AIのテストやカオスエンジニアリングは、10年前はほとんど話題にされなかったトピックだが、新規にテスト担当者が学習しなければならない必須トピックである 改定内容について 今回の改定では、各章の内容が現在のソフトウェアテストの状況に即したものにアップデートされており、新たに追加または削除されたテスト技法やカバレッジについての考え方の変化だけでなく、アジャイル開発についての記述も追記されています。どのようにテストをすればよいのか、なぜそのテストが必要なのかから入り、ウォーターフォール開発とアジャイル開発でのテストの違いや筆者の考えなどが書かれています。特に第8章と第9章では、テスト計画や品質管理に焦点を当てており、ウォーターフォール開発とアジャイル開発におけるテスト計画書の書き方や品質管理に使用するメトリクスの違いが大きく書かれています。 また、新たに第10章の「新しいテスト技術」が追記されており、この章では、AIに対するテストとしてメタモルフィックテストや経験ベースのテスト、ニューロンカバレッジについて書かれていたり、現代の複雑なシステム ※2 に対するテストとしてカオスエンジニアリングやランダムテストについて書かれています。 ※2 現代のシステムはオープンソースを利用したり、クラウド環境にシステムを構築したりすることにより複雑化しているため、すべてをテストすることが不可能です。そのため、無限大にあるテストを有限に落とし込むのもテスト担当者の仕事であり、カオスエンジニアリングやランダムテストはそのための手法として当書に記述されています。 本を読んだ感想 この本を読んで最初に感じたのは、アジャイル開発とAIのテストの難しさでした。なぜなら、これらのテストは発展途上であり、今後、アジャイル開発やAIの利用が拡大する中で成長していく技術だからです。 アジャイル開発について アジャイル開発は柔軟な対応が可能で市場リリースを早くできるというメリットがありますが、柔軟な対応と品質の向上の両立は難しい課題です。アジャイル開発だからといって、テストすべき項目やテスト手法がウォーターフォール開発と変わることはありませんが、私の経験上、今までのホワイトボックステストやブラックボックステストでは、逐次変化する状況に対してテストケースを随時更新しながらテストを行うことが困難です。 当書では第4章の探索的テストで以下のように書かれています。 ウォーターフォールでの探索的テストと、アジャイルやAIソフトウェアでの探索的テストでは少しずつ役割が変わっていくのかもしれません。 もちろん、それはもっと探索的テストが活用する方向にです。 また、 短いイテレーションでGUIが変更するようなソフトウェアでは、探索的テストが向いていると筆者は考えています。 このように、探索テストがアジャイル開発に向いていると書かれており、私も探索的テストはアジャイル開発において有用だと感じました。しかし、探索的テストはテスト担当者のスキルに依存する部分があるため、それを主としてしまうとテスト自体が属人化してしまうのではないかとも感じました。 また、アジャイル開発ではこれらのテストの難しさに加え、テスト計画や品質管理の部分でも、ウォーターフォール開発とは異なるため、アジャイル開発のテストは発展途上であり、これからも学び続ける必要があると感じました。 ※3 ※3 私自身はこの本を読むまで、アジャイル開発とウォーターフォール開発でのテスト計画や品質管理の違いについて、あまり意識したことはありませんでした。アジャイル開発では設計からリリースまでが短くなるため、テスト計画をどうすれば良いかと考えたことはありましたが、品質管理において、アジャイル開発に最適化したメトリクスを探そうなどは考えたこともありませんでした。 AIについて AIのテストについては、AI以外の機能テストと明確に異なる部分があります。それは、入力に対する明確な出力が存在しないということです。AIのテストも基本的には既存のソフトウェアテストと同じく、指定した入力に対する出力が返ってくるかをテストしていきますが、その出力が定まっていないためテスト自体が難しいです。当書では、これらの期待値の定義が難しい状況に対するテスト手法の代表としてメタモルフィックテストがあげられています。この手法は、ベースとなる入力と出力が存在する状態で、入力に少しずつ変化を加えていき、出力がどのように変化するのかを確認する手法です。入力に変化を加えたことで出力が大きく変わってしまう場合、AIシステムに問題があるのではないかと考えることができます。 しかし、このテスト手法の最後に以下のように書かれていました。 メタモルフィックテストも完璧ではありませんし、定量的な品質指標を提供しにくいテスト手法です。 特にミッションクリティカルなソフトウェアでは、このテスト手法は慎重に適応したほうがよいと考えます。 ただAIのテスト手法の一番代表的なものなので、これを使うしかないのですが。 このように、まだ効果的なAIのテスト手法は存在しないというのが現状であり、これからも学び続ける必要があると感じました。 どのような人におすすめか 10年ぶりに改訂されましたが、全体的な構成は大きく変わっておらず、読みやすい文章や図により、なぜテストをするのか、どのようにテストをすればよいのかがわかりやすく書かれているので、これからソフトウェアテストを学ぶ人にとっての入門書としておすすめであることに変わりはありませんでした。 また、改定前の当書を読んだことがある人にとっても、この10年間でどのようにテストが変わっているのか、特にアジャイル開発やAIのテスト手法や現状、また、それらに対する筆者の考えがわかりやすく書かれているので、アジャイル開発やAIに触れる機会が多いのであれば、手に取って読んでみても良いのではないかと感じました。 The post AI・アジャイルなど最新技法を網羅！改訂版「知識ゼロから学ぶソフトウェアテスト」を読んでみた。 first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第3回となる今回は、ステークホルダーとの関わり、ステークホルダーマネジメントの重要性についてお伝えします。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ ステークホルダーマネジメントの重要性とその高まり PMBOKでは2012年の第5版でから「コミュニケーションマネージメント」から「ステークホルダーマネジメント」という項目が独立し、その影響と管理の重要性が改めてフォーカスされました。PMBOKでは1996年以降マネジメント領域の新設は一度もなかったため、世界的にステークホルダーマネジメントに注目が高まっていることがわかります。 ステークホルダーとは ステークホルダとは一般的に「利害関係者」と訳します。もともと「株主」を示す経営用語から、今では企業経営やプロジェクトを取り巻いて影響を与えあう意味での利害関係者（従業員から、取引先、PJ結果の影響を受ける個人など）を広域に指すようになりました。PMBOKでは 「プロジェクト、プログラム、またはポートフォリオの意思決定、活動、もしくは成果に影響したり、影響されたり、あるいは自ら影響されると感じる個人、グループ、または組織」 と定義しています。 プロジェクト活動においてさらにステークホルダの存在やマネジメントの必要性が増している理由として プロジェクトが高速化している 多様化するプロジェクトで利害関係が複雑化している こと等があげられます。プロジェクト憲章が承認されPMに任命されチームが形成される「立ち上げ段階」で、いかに早くステークホルダーを特定して、後述するエンゲージメントのプロセスを準備/開始できるかがプロジェクト成功の鍵といえるでしょう。 「エンゲージメント」とは絆づくり ステークホルダマネジメントでは「エンゲージメント」という言葉が使われます。 エンゲージメントは「約束、婚約、社員の愛着心、ブランドと消費者の絆」など業界ごとに対訳が異なりますが、筆者は人事労務分野用語に近い「絆、望んで協力する愛着」といったイメージが近いと考えています。ステークホルダと絆を育んで、プロジェクトに愛着を持ってその成功に力を貸して貰えるよう、PMは活動を続けます。 ステークホルダーマネジメントの進め方 ステップ①：プロジェクトのステークホルダーを特定する ステップ②：どのようにステークホルダーとエンゲージメントするか計画を立てる ステップ③：エンゲージメントを実施する（マネジメント） ステップ④：エンゲージメントの実施状態を確認し、必要なテーラリングを行う プロジェクトのステークホルダー対象者は多岐に渡り、各ステークホルダーの関心ごとは異なるため闇雲に管理すること、当然エンゲージするなどはできません。まずは「プロジェクトのステークホルダーは誰（何）だろう？」と考え、ステークホルダーの関心、関与、相互依存、影響やプロジェクト成功への潜在的影響に関する情報を収集して整理します。次に整理した情報を元に「ステークホルダーにどう関わればプロジェクトが成功するか」計画を立てます。 ステップ３ではエンゲージメント活動として、ステークホルダーとコミュニケーションを取り協業していきます。プロジェクトが進むにつれ、ステークホルダーの状態も変化すると考え、定期的にプロジェクトとステークホルダーとの状態を見直すことも忘れません。 具体的にステークホルダーの特定やエンゲージメント計画にどのような対応があるか、見ていきましょう。 ステップ①：テークホルダーを特定する 漏れなく行いたいステークホルダーの特定 ステークホルダーをマネジメントするためには、その前にそのプロジェクトにおける、ステークホルダーを特定しなければなりません。その際は、社内と社外の利害関係者両方を考慮するようにしましょう。慣れない内は特定作業を難しく感じるかもしれません、そんな時は「事業構造、プロジェクト体制、顧客（ユーザー）中心」など検討の起点や枠組みを決めてから考え始めると良いでしょう。 プロジェクトに影響を与える（持つ）人は誰だろう？ プロジェクトが影響を与える人は誰だろう？ プロジェクトを承認（拒否）できる権力者は誰だろう？ コスト（等）を出してくれる人は誰だろう？ プロジェクトに必要な知識（ナレッジ）を授けてくれるのは誰だろう？ ステークホルダーの特定は近視眼的にならないこと、つまり自分と直接関わる人や物事だけにフォーカスしないことが大切です。例えばプロジェクトが進んでリソースが枯渇した場合やシステムリリースが他のプロジェクトとコンフリクトしたしてしまった、という場合は主要なPMやPMOとの連携/協力が欠かせず、ステークホルダーとして意識すべき対象ですが漏れがちです。見落としがあって「後からステークホルダーが見つかる」場合、その影響によってはプロジェクトにマイナス（リスク）として作用する可能性がありますので注意しましょう。 ステークホルダーを分析する ステップ①ではもう一つ大事なプロセスがあります、それは特定したステークホルダーを「分析」することです。分析といっても難しいことはなく、ステークホルダーマネジメントを計画、実施するために「傾向」を立てる整理だと考えましょう。 ステークホルダー分析にはステークホルダーをマップ化した 「分類マトリックス」 をお勧めします。 エンゲージメントを高めるために、まずは各ステークホルダーの影響力や関心度を明確にすることが必要です。この分析では「権力と影響度」と「関心度」という軸、「高」と「低」というレベルを設けて2×2のマトリックスに ステークホルダーを分類し視覚化 します。 ※この軸は影響×関心の２軸にしていますが、組織によってパターンや内容を変えてもいいと思います。何かしらの軸を持つことで個人の判断で恣意（しい）的に決めたのではないという合理性を持たせることが大切です。 例えば、、、 プロジェクトスポンサーの田中さんはプロジェクトへの権限を持っていて影響がある、そしてプロジェクトへの興味関心も高いので影響度高×関心度高に配置してみよう。経理部門はプロジェクトに対する権限こそないが、あまりコストをかけて欲しくないことからプロジェクトへの興味はありそうだ、もしかすると後半になって何かコスト的な指摘がはいりそうだ。と分析し影響度低×関心度高に配置しよう。と、このように分析/可視化することで、今後各ステークホルダーに対して優先順位や対応方針を明確にしていくことができますね。 マトリックスに対する標準的な対応方針 マトリックス上で可視化されたステークホルダー分析に対して、標準的に以下のような対応をとります。また、全てのステークホルダーに対して満遍なく対応することは難しく、PMは①→②→③→④の「逆ゼット（Z）」順（枠）で見るのがよいと言われます。 ステークホルダと分析結果を記録する ステークホルダーの特定とマトリックスで整理された分析結果を一覧化したものが「ステークホルダー登録簿」です。ステークホルダー登録簿へ明文化することで今後の「計画」やエンゲージメントによる変化をモニターすることを可能にします。 名前など基本情報を明確にした上で「マトリックス」で検討した情報を記載します。また対応内容には分析で得られた方針を元に「どのような態度・対応を講じていくか、その必要があるか」といったステークホルダーへの対策を記載します。 ここで注意したいのがステークホルダー登録簿の管理です。ステークホルダーマネジメントに伴う分析や整理はプロジェクトに必須の営みですが、ステークホルダー分析結果や登録簿に記載された内容はデリケートな部分を含む為その取り扱いには注意が必要です。分析結果や対応戦略等は基本的にはPMのみが管理することをお勧めします。 ステップ②：計画する ステップ①で行ったステークホルダーの特定、分析、整理記載をベースに、ステークホルダーへの対応を計画します。ステークホルダーとの効果的な対話と関与を促す方法を考えます。 例えば経理部の斉藤さんは、、、 現在関心度は高いが経理部としての関心であり、プロジェクトの後半で費用の締め付けや指摘などがあるかもしれない 経理部としては開発予算がXXに収まることがわかれば安心してもらえそうだ 次フェーズ開発コストの獲得を行う際、斉藤さんの発言力は高いが今フェーズの予算消化が物をいいそうだ →なんとか斉藤さんとの関係性を高め、関心度をより高めてプロジェクト支援者になってもらえないだろうか？ →斉藤さんではなくXX役員に後ろ盾になってもらうことで解決できないだろうか？ といったように、ステークホルダーとの関係性を変化させることでよい影響がもたらすことができないか「仮説」をシュミレーションすることからはじめます。分析からステークホルダーのニーズと視点、考え方を理解し、プロジェクトの成功に近づけるためにどんなアクションが取れるかを計画することはPMの役割です。ステークホルダーの立場に立って考えてみましょう。 ステップ③④：ステークホルダーエンゲージメントの実行と定期的な見直し 各ステークホルダーをプロジェクトに巻き込み、プロジェクトの成功に向けて継続的に関わって貰うには、交渉やコミュニケーションを通じて期待をマネジメントすることが必要です。 ステークホルダーと常に情報共有すること、プロジェクト中に発生する変更や進捗情報を知らせるようにしましょう。また適切なれポーティングは可視性が高まるだけではなく、誤解が発生するリスクも減らせます。すべてのステークホルダーに満遍なくは対応できず、またその必要がないことはステップ①でもお伝えしました。完璧なコミュニケーション補完とソリューションはありませんので、例えばの力のかけ具合や頻度を事前に決めておくことが大切です。またプロジェクトが進むにつれ、プロジェクトと同様にステークホルダーの状況（対象者、興味関心、影響度など）は変わります。定期的な棚卸しを忘れずに。 さいごに ステークホルダーを意識し、マネジメントすることはプロジェクトハンドリングするPMの非常に重要な活動ですが、実態として時間的制限から行われない（おざなりになる）、苦手意識があるといった課題を耳にしますPMBOKの知識体系の「最後」に書かれているからか、どうしても主役の対応になりにくいステークホルダーマネジメントをぜひみなさんには理解し実施していただきたく、本連載ではあえてQCDマネジメントやリスクマネジメントといったパートより先にお話ししてみました。 次回は、プロジェクトを始動させる際に必要なプロジェクト憲章やマネジメント計画書の作成とその方法についてお話ししていきます。 The post 【第3回】ステークホルダーマネジメントの重要性と進め方 first appeared on Sqripts .

はじめまして！ QA業界23年のテストエンジニア『つよぽん』です。 今回、ブログ初挑戦となります。最後までお付き合いください。 さて、今回は2023年にCBT化された『JSTQB Advanced Level Test Analyst』（以下、ALTA）の合格体験記です。ALTAの受験～合格に至るまでの体験をまとめました。 これからAdvanced Level（以下、AL)を受験する方のお役に少しでも立てることができましたら幸いです。 Test Analyst 受験までの道のり 2000年からテストエンジニアとして働き始め、2011年に Foundation Level（以下、FL）を取得しました。 2013年の第2回　Advanced Level Test Manager（以下、ALTM）を受験。結果は『不合格』でした。また第2回試験の合格率が6.86％と低かったことや、以下の悩みどころもあり、その後試験を受けることに慎重になってしまいました。 私にとってのJSTQB試験の悩みどころ ・受験料が少々高い(22,000円) ・試験の回答が公表されないのでどこを間違えたかわかりにくい ・過去試験問題がほぼ非公開、問題集が少ない そこから9年　私が、AL試験を再度受けようと思ったのは、2022年8月に現在の会社へ転籍したことが大きなきっかけです。 再受験に向けた問題点、それは以下3つのでした。 学習    　　→　どうやって勉強すればいいだろう？ 資金    　　→　22,000円の試験料が少々高い メンタル    　 →　AL資格取得は本当に必要か？ 解決したのは以下によるものでした。 『学習』　e-learningの提供 　ALを受験するための学習コンテンツ( e-learning )が弊社にありました 　 ⇒　これで学習しよう！！ 『資金』　会社からのバウチャーチケットの提供 　会社から1回分のバウチャーチケットが提供される 　 ⇒　バウチャーを1回分貰えるならタダで受験できる！！ 『メンタル』　組織目標によるモチベーションアップ 　ALの取得目標が組織として設定される（おじさんには結構良い効果） 　 ⇒　会社からのPUSHでキャリア的にもAL持ってないといけないと奮起！ ！ 以降は、AL取得に向けた再受験のお話となります。 JSTQBの受験経歴 私のJSTQB受験履歴を並べてみます。 Ⅰ．FL受験（2011年8月／合格） Ⅱ．ALTM受験（2013年2月／不合格） Ⅲ．ALTA受験（2023年5月／不合格） Ⅳ．ALTA受験（2023年8月／合格） 今回のAL受験では、この10年で業務として関わりの深かった分野である『Test Analyst』を受験することにしました。 Test Analyst 受験（1回目）の失敗談 1回目のALTA受験は2023年5月にCBT化されたものでした。テストの感触としては悪くない。それなりにできた印象でしたが結果は不合格でした。 受験に向けて準備したことは以下の通り。 試験概要の把握 　問題数：40問 　総試験時間：135分　(NDA 5分 + 試験 120分 + アンケート 10分) シラバス の読み込み 　問題はシラバスに沿って出題されるため、シラバスを熟読（3回） 弊社 e-learning による学習 　シラバス読み込み後に講義形式、問題形式による学習の実施 CBT試験のデモ 　ペーパー試験世代のためCBT試験が苦手、事前に操作の把握 また反省点を考えて、次回に備えました。 【反省点】 試験概要の把握しか出来ていなかった 全体をまんべんなく学習してしまった CBT試験の経験不足（ペース配分、操作など苦手感が拭えなかった。） “失敗した経験も次に生かすための大事な財産として心に留めます！” Test Analyst 受験（2回目）の成功談 一番初めに、どうしたら合格できるかを「考えること」から始めました。 そこで導き出した結論が以下となります。 其の壱： 戦略を決めよう 資格試験もテストと同じ！戦略を決めてからスタートすることとしました。 今回の戦略は資格試験の定番　↓↓↓↓↓↓↓↓↓で決定 『敵を知り、己を知れば、百戦して殆うからず』（孫子） 其の弐： 具体策を練ろう 戦略も決まったので次は戦略に沿った具体策を考えました。 『敵（ALTA）を知る』 まずは敵を知らなくては戦えない。徹底的に敵を把握して、分析しよう！！！ 出題傾向の分析 どこが何問出るの？ ISTQB公式サイトの Exam Structure Tables v1.6 をチェックすべし！ 試験ごとの出題配分がChapter単位で公開されています。 ※詳しくは ISTQB公式サイト を参照 上記の『Exam Structure Tables v1.6』のALTAの問題数をまとめた結果は下表となります。 Chapter 問題数 Chapter1 6問 Chapter2 1問 Chapter3 17問 Chapter4 11問 Chapter5 3問 Chapter6 2問 合計 40問 配点傾向の分析 問題の配点はどうなっているの？ ここでもISTQB公式サイトの Exam Structure Tables v1.6 をチェックすべし！ 　試験ごとの問題配点もChapter単位で公開されています。 『Exam Structure Tables v1.6』のALTAの問題配点をまとめた結果は下表となります。 Chapter 配点 Chapter1 10点 Chapter2 2点 Chapter3 44点 Chapter4 15点 Chapter5 6点 Chapter6 3点 合計 80点 合格ラインの分析 何点取れば合格できるの？ 問題数40問、総点数は80点！合格点はISTQBに準拠することより65%なので・・・ 80点×65%＝　52点 　すなわち 52点で合格 です。 合格点に到達するための分析 合格点に到達するためにどの問題を何問正解すれば合格できるの？ そのためにはChapterごとの配点とK Level（配点の高い問題）の出題数を分析！！ Chapter 問題数 K2 K3 K4 Chapter1 6問 4 0 2 Chapter2 1問 0 1 0 Chapter3 17問 3 1 13 Chapter4 11問 9 0 2 Chapter5 3問 0 3 0 Chapter6 2問 1 1 0 K2 = 2点 / K3 = 3点 /K4 ＝ 4点 点数が高いChapterは以下２つです。 Chapter3（テスト技法）＝44点 Chapter4（ソフトウェア品質特性のテスト）＝15点 この二つをマスターすれば 44 + 15 ＝ 59点 となり、これだけで合格ラインに達します。 さらにK Levelも含めて分析するとChapter3（テスト技法）のK4 Level(配点3点)は13問出題されるので 39点 になります。これだけでも合格点の3/4がとれます。 K3 = 3問(9点)のChapter5（レビュー） も配点が高いのでおススメです。 なんかこの分析だけで合格できそうな気になりませんか？ 『己（自分）を知る』 敵を知ったその上で、己(自分)を知らなくても勝つための戦いはできません。 自分の得手・不得手を徹底的に分析しましょう！！！ 得手、不得手の分析 何を得意としているか？（自問する） 私の場合・・・ テスト技法など考えて解くものはモチベーションアップするし、理解しやすい 品質特性など業務で関わった部分は把握しやすい 何を不得意としているか？（自問する） 私の場合・・・ シラバスの理解が苦手（特に業務で関わってこなかった分野） ケアレスミスが多い(正しいものと、間違っているものどちらを選ぶかのミス) 得手、不得手の分析結果より導いた対応策 私の場合・・・ テスト技法は問題集の捜索・確認する 品質特性などは過去業務に照らし合わせて学習する シラバスは読むだけでなく自分で書き出しまとめてみる ケアレスミス対策として、問題の読み方を改善（何を回答するかを先に見る） “得手・不得手は人によって違う。自分を理解して、自分に合った対策を実行することが大事！” 『百戦して殆うからず』 何度、受験しても合格できるようにするべし。そのための対処法を考えましょう！！！ 目標を合格ラインのギリギリに設定しない 合格点(52点)に対して、確実に合格するよう学習しましょう。 「多分取れるだろう」を含めての目標では不合格リスクが高い！！ 学習のピークを試験日に持っていく 学習計画を立て、学習のピーク（一番まとまって学習できる）日程で試験を受けるべき。 其の参： モチベーションアップ対策を考えよう 合格をより確実なものにするために、モチベーションアップする案を検討！！ みなさんはどんな場合にモチベーションがあがりますか？ 私の場合は以下設定をしました。 合格時の成功報酬の設定 合格時に自分へのご褒美を設定。これだけでモチベーションは爆上がりです。 合格した場合のメリットの分析 合格した場合に自分にどんなメリットがあるかを考える。 『新たな学習チャンス』：次のスキルアップに向けた時間を確保できる 『業務的なアピール』　：資格保持を業務的なアピールとして使える 其の四・計画に沿った学習 今回の戦略・計画に沿って、5月中旬～8月下旬(2か月半)で以下の追加学習を行いました。 配点の高いテスト技法についても、問題集をこなし、取りこぼしのないように準備をして試験に臨みました。 No 追加学習 サイト 1 シラバス （前回テストで出題された内容） https://jstqb.jp/syllabus.html#syllabus_advanced_altta 2 JSTQB公式サイトのAL試験過去問題の解説 セミナー(TA)視聴 https://www.youtube.com/watch?v=IWUkunUZNoA 3 ソフトウェアテスト技法練習帳 https://gihyo.jp/book/2020/978-4-297-11061-1 4 JSTQB（非認定）ソフトウェアテスト問題集 (Advanced Level Test Analyst） https://learner-jstqb-al.booth.pm/items/3105863 5 JSTQB e-learning （再確認) https://agest.co.jp/academy/ 試験当日～結果判定 試験当日は、『やるべきことはやった。いい状態』で迎えられました。 手ごたえは以下です。 時間配分:試験時間を30分残して見直し開始、見直し含めて3分前に完了しました 試験内容：戦略・計画がハマった。一度受験した経験も追い風になりました 合格予想率：80%　⇒　試験結果は約2週間後。申し込みサイトのボタン一つで結果がわかる 今回は予想率通りの結果『合格』でFINISHできました。 まとめ JSTQB認定テスト技術者資格は、知識やスキルを体系的に学ぶことができます。 今回受験したALTAはFLで学んだ知識をより拡張したものとなります。より深く、広い知識を得ることで、業務に対しての理解度や共通認識での会話力が高まり、テストエンジニアとして、良い成果に導いてくれるものと思います。 また知識を有していれば資格は不要という方が多々見受けられますが、仕事の初見では、知識の有無は詳細に計れないところがあります。そのために資格という目に見えるものは知識の有無を示すのに有効であると考えます。 ソフトウェアテスト業界でFL取得が当たり前となる昨今、AL取得が次のステップとして必要になってきています。皆さんも、自分に合った戦略・計画を整えて学習することにより、JSTQB AL資格を取得しましょう。 最後まで読んでいただき、ありがとうございました！ The post 10年ぶりのJSTQB AL受験～TestAnalyst合格体験記～ first appeared on Sqripts .