金融、公共交通、電力、通信等の社会インフラを支える業界では、その業務に使用されるコンピュータシステムの信頼性を担保するために様々な法規制があります。   人の生命に直接関係するお薬や医療機器を製造する製薬・医療機器業界もその一つです。   本記事では初めて製薬・医療機器業界のコンピュータシステム導入・運用に携わる方々向けに、同業界に適用される法規制の一つである CSV（Computerized System Validation）の基本的な事柄をご紹介します。 製薬業界のコンピュータシステムの特徴 製薬業界でもコンピュータの利用が急速に普及し、従来は人手と紙記録で行われていた多くの作業がコンピュータ化されています。   一方、コンピュータの欠陥による重大事故も発生しており、コンピュータシステムの信頼性と安全性への要求がますます高まっています。   医薬品は生命に直接関係するため、基本的に「不良品ゼロ」が要求されます。このため、医薬品製造者が業務に使用するコンピュータシステムについては「バリデーション」の実施により、管理するデータと出力結果の信頼性確保が要求されています。 「バリデーション」と「CSV」 お薬を作る工場では製造工程、作業手順、製造管理、品質管理等の方法が、製品品質に対して「期待される結果」を与えることを検証し、文書化することが求められています。これは「GMP省令（医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令）」という法令に基づくもので、この検証と文書化のプロセスを「バリデーション」と呼びます。   同様の考え方をコンピュータ化システムについても適用し、各種業務に使用するコンピュータ化システムをバリデーションすることを「コンピュータ化システムバリデーション（CSV）」と呼びます。   ここで「コンピュータ化システム」という言葉は、「コンピュータシステムで統合された工程又は作業、及びコンピュータシステムにより実現される機能を利用する業務プロセス」を指す広い概念です。 CSV と規制対象 CSV はお薬の製品開発、臨床試験、製造、品質保証、流通、販売後安全管理に亘る、製品ライフサイクル全般で使用されるコンピュータ化システムを対象としています。   前章で「GMP省令」という法令を紹介しましたが、製品ライフサイクルの各段階に対応して下記に示す基準が定められており、「GxP」と総称されています。 GLP（Good Laboratory Practice）：医薬品の安全性試験の実施に関する基準   GCP（Good Clinical Practice）：医薬品の臨床試験に関する基準   GMP（Good Manufacturing Practice）：医薬品の製造管理及び品質管理に関する基準   GQP（Good Quality Practice）：医薬品の製造販売品質保証に関する基準   GDP（Good Distribution Practice）：医薬品の適正流通に関する基準   GVP（Good Vigilance Practice）：医薬品の製造販売後安全管理に関する基準   また、これらの基準による規制は日本国内に留まらず、海外でも各国で同等の法令が制定されており、お薬の輸出入を行う場合はそれに従うことが求められています。 CSV の概要と特徴 CSV の基本的な考え方は一般的なコンピュータシステムの検証と同じですが、開発・検証プロセスとその文書化についてガイドラインが制定されている点が特徴です。 CSV の全体像 （図1）に CSV が前提とする開発・検証プロセス全体像と主要作成文書を示します。   ウォーターフォールの V字モデルに沿った開発・検証を行う点では一般的なシステム導入と同じです。   一方で可監査性を目的とした開発・検証文書の整備が重要視されており、システムアセスメントや供給者監査等、第三者的な視点での評価がプロセスに組み込まれています。   （図1）開発・検証プロセスと主要作成文書 開発業務に於ける主要作成文書 （表1）に開発業務に於ける主要作成文書を示します。   要件定義の前提として「システムアセスメント」の実施が規定されています。システムアセスメントの結果はバリデーション計画にも反映されます。 （表1）開発業務の主な作成文書 検証業務に於ける主要作成文書 （表2）に検証業務に於ける主要作成文書を示します。   「供給者監査」の実施が規定されており、システム開発ベンダーが CSV に関する充分な知識と経験を保有し、定められた品質管理システムを実践していることを、発注側が監査します。 （表2）検証業務の主な作成文書 プロジェクト管理上の考慮点（ケーススタディ） CSV 対象プロジェクトでは、開発・検証段階での文書作成・管理に要するリードタイムと工数が、プロジェクトの計画・管理に大きな影響を及ぼします。   本章では 文書作成・管理視点から見た課題と対応事例を、筆者の経験からケーススタディ的にご紹介します。   CSV 対象システム構築プロジェクトで筆者が特に重要と考える ①：文書作成・管理目的の理解、②：文書体系整備、③：文書管理、④：変更管理の事例です。   尚、これらの事例は筆者が製薬企業側の PM として参画した、複数の導入プロジェクトに基づくものです。 ①：文書作成・管理目的の理解 筆者が最初の CSV 対象プロジェクトを経験するまでは、開発・検証文書は、開発者⇔システムユーザ間の仕様合意・品質記録と、本番運用開始後の保守を目的として作成・管理するという理解でした。   CSV 対象システムでは上記に加え、お薬の製品品質に関する適切なリスク管理が行われていることを、ユーザ企業の品質保証部門や外部査察・監査に対して説明できる文書であることが要求されます。   このため、説明責任視点でも納得性のある文書体系・文書管理プロセスの整備・運用に多くの時間を割いてきました。   一例として、システム構築プロジェクトと並行して CSV 文書体系・文書管理プロセス整備をゼロから行った、Aプロジェクトの事例をご紹介します。   CSV 文書は、製薬企業の品質保証部門が承認した基準書や手順書に従って作成・管理される必要があります。   国内では 2012 年度から CSV 規制が適用になったこともあり、その企業では CSV に関する基準書や手順書が無い状態でしたので、先ずはこれを整備する必要がありました。   しかし、Aプロジェクトの計画時点ではこれらのタスクは想定していなかったため、途中で品質保証部門を始めとする関係各部門を巻き込んで、サブプロジェクトとして対応しました。   社内にはノウハウが無かったので、早期から CSV を実施している外資系製薬企業に見学に行ったり、CSV 経験・ノウハウを持つ開発ベンダーからコンサルティングを受けたりして、何とか形だけは整備して本番運用を開始しましたが、今振り返ると突っ込みどころ満載の突貫工事だったと思います。   ②：文書体系整備   （図1）に示した各文書は内容の整合性が担保されていることが CSV の大前提となります。 Bプロジェクトの設計仕様書（DS）レビューで、に品質保証部門のレビュアーから「要求仕様書（URS）の要求項目が漏れなく DS に反映されていることは確認できていますか？」という指摘がありました。   Bプロジェクトでは、それまでの文書レビューは個別文書毎の内容レビューが中心でした。異なる開発工程の文書間で整合性を網羅的に確認する、という発想自体が無かったので早速対応に追われました。   対策として、要求仕様（URS） ⇔ 機能仕様（FS） ⇔ 設計書（DS）間相互の記述内容に過不足や不整合が無いことを確認する「トレーサビリティマトリクス」を作成しました。  幸い URS ⇔ FS ⇔ DS の各文書と項目には体系的な ID が採番されていたので、ID を紐付けることで文書間のトレーサビリティを可視化することができました。   もしこれらの文書が整合性確認を意識せずに作成されていたとしたら、最悪の場合は URS や FS の体裁修正まで手戻りが発生することも考えると、初期段階での文書体系整備の重要性を認識した一コマでした。   これ以降、開発文書の成果物にトレーサビリティマトリクスを入れたプロジェクト計画を作るように留意しました。 ③：文書管理  CSV 関連文書は文書間の整合性維持や、規定通りの承認経路によるタイムリーな承認が必要となります。    加えて本番運用開始後も査察対応等のために、監査証跡の記録や目的文書への迅速なアクセスが必要となります。   このため、文書管理に要する工数とリードタイムが、プロジェクトリソースとスケジュールに大きな影響を与える場合があります。   Cプロジェクトでは設計・開発工程のスケジュールが遅延して、受入テスト・CSV のスケジュールが圧迫されている状態でした。   対策の一つとして、検証文書の承認リードタイムを短縮することで CSV 全体のリードタイムを短縮する取組を進めました。   具体的には、GxP 文書の管理目的で運用していた文書管理システムと承認プロセスをそのまま流用して、Cプロジェクトの CSV 文書管理を行うことにしました。   文書管理システムを活用し、承認者が出張等で不在の際にも社外での承認を可能にしたり、承認プロセスを可視化して遅滞している承認を督促したりすることにより、スケジュールを遵守することができました。   又、副次的な効果として、文書の変更管理や発行管理にも同システムを活用して、外部監査や査察対応の際にもアカウンタビリティの高い管理ができるようになったと思います。    一方、紙と印鑑で承認していた時のようなバックデート対応等は難しくなるため、例外的な処理を含めた業務ルール設計とそれを遵守する教育や文化の醸成にも配慮しました。    これ以外にも 品質保証部門が承認した手順書に従って各文書が作成されていること   必要な職責のレビューと承認が全て完了していること   ウォーターフォール開発の場合は各文書承認日付の前後関係に矛盾がないこと   等々、一般のプロジェクトでは後回しになりがちなことが、CSV 対象プロジェクトでは大きな問題になることがあるので、計画段階で管理タスクを可視化して確実に実施することが必要です。 ④：変更管理  Dプロジェクトはその企業で初めての MES（工場の製造実行システム）導入であったため、機能設計書（FS）の確定が遅れていました。加えて開発・単体テスト段階になっても仕様変更や追加が多発したため、変更管理手続きの煩雑さと手間が課題になっていました。    当初、Dプロジェクトでは品質保証部門が制定・運用する、GxP の変更管理プロセスを準用していました。    このプロセスはお薬の製造工程変更や標準作業手順変更のような、製品品質に直接影響する変更を主として想定しており、変更理由と必要性評価、影響内容と範囲、品質リスク評価、変更許可理由 等を全て規定の様式で文書化して残すことが求められるものでした。    しかしシステム開発の場面では、明らかに製品品質には影響しない仕様変更や機能追加も多く、煩雑な変更管理プロセスが形骸化したり、遵守されない状況が発生していました。加えて、変更管理文書の査閲・承認がボトルネックとなり、開発工程のスケジュールにも影響が出ていました。    対策として、変更申請時に製品品質への影響リスクを Dプロジェクト内で事前評価する手順を設けました。  低リスクのものについては一般的なシステム開発の変更管理プロセスを適用し、中・高リスクの案件についてのみ、GxP の変更管理プロセスを適用するようにしたのです。    又、GxP の変更管理プロセスの中でも、リスクが低い変更案件は手続きや承認レベルを簡素化するルールを適用することで、手続きの簡素化・迅速化とリスク低減を両立しました。 まとめ  製薬業界でコンピュータ化システムを導入する場合に必要となる CSV について、概要をご紹介しました。    CSV は法令による規制ですので正しく実施して、査察や監査にも耐えられるシステム構築や運用が必須です。    このためにはプロジェクト計画段階で、一般的なシステム構築プロジェクトに比べて追加で必要となる文書作成・管理のリードタイムと工数を織り込んでおくことがポイントです。    プロジェクト体制面では品質保証部門（QＡ部門）の参画が必須なので、早い段階から巻き込んで良い関係を築き、二人三脚で進めることが成功要因の一つです。    開発ベンダーについては、CSV 経験の無いベンダーでは要求される各種事項への適切な対応が難しいと思います。逆に経験豊富な開発ベンダーからは、効率的な CSV 実施のアドバイスや他社事例等の有益な情報提供が期待できるため、ベンダー選定はプロジェクトの成否を分ける大きなポイントとなります。    最後までお読み頂き、ありがとうございました。    本記事が製薬・医療機器業界の GxP システム構築に携わる皆様のお役に立てますと嬉しく思います。 Appendix 参考となるサイト など 厚生労働省／コンピュータ化システム適正管理ガイドライン 国内での CSV 実施要領の基準となるガイドライン文書です。 GMP Platform CSV に留まらず、医薬品の製造や品質管理を総合的にカバーする情報発信サイトです。   （株）イーコンプライアンス 医薬品、医療機器業界を中心に、当局規制内容の解説や対応方法の情報が充実しています。 用語説明 GMP 省令： 医薬品及び医薬部外品の製造管理及び品質管理の基準に関する省令   URS（User Requirement Specification）： 指定されたコンピュータ化システムに関する機能上の要求仕様が記載された文書   FS（Functional Specification）： 要求仕様書に記載された要求仕様に対応する、より具体的な機能が記載された文書   DS（Design Specification）： 機能仕様に記載された具体的な機能を実現するコンピュータ化システムを作成するための詳細仕様が記載された文書。   DQ（Design Qualification）： 設計時適格性評価。要求仕様書に記載された要求事項が、機能仕様書、設計仕様書等に正しく反映されていることを確認し文書化すること。   IQ（Installation Qualification）： 据付時適格性評価。コンピュータ化システムが、設計仕様等に記載されたとおりに据え付けられ、プログラムがインストールされたことを確認し、文書化すること。   OQ（Operational Qualification）： 運転時適格性評価。コンピュータ化システムが、運転時において、機能仕様等に示された機能及び性能を発揮することを確認し文書化すること。 PQ（Performance Qualification）： 性能適格性評価。コンピュータ化システムが稼働時において、要求仕様等に記載されたとおりに機能し、性能を発揮して運転できることを確認し、文書化すること。 The post 製薬・医療機器業界のCSV入門｜Computerized System Validation first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第7回となる今回のテーマは前回に続き「スケジュールマネジメント」です。 後編となる今回は、スケジュールの作成と作成したスケジュールをどのように使ってマネジメントしていくかにフォーカスします。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 前回のおさらい 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ １）スケジュールマネジメントとは ２）スケジュール作成に必要な準備・検討 　　・アクティビティを定義する：WBSで要素分解する 　　・作業の依存関係を確認して順序を決める：アクティビティの順序設定をする 　　・アクティビティ所要期間（工数と時間）を見積もる スケジュールの作成 1) クリティカルパスを使ってスケジュールを考える スケジュールを作成する技法は幾つもありますが、クリティカルパスメソッドを押さえておきましょう。 クリティカルパスメソッド（ CPM：Critical Path Method ）は、プロジェクトを完了させるために実行しなければならないタスクを特定する技法です。クリティカルパスとは、プロジェクトの全工程を最短時間で完了するための作業経路で、重要な作業を特定することでスケジュールとその柔軟性も判断することができます。プロジェクトは細かなタスクの集合体であり、その一連のタスクを連ねた時に「最も時間のかかる経路」をクリティカルパスと言います。 クリティカルパス＝最長の重要タスクですから、ここに遅れがでると後続に影響がでてプロセス全体も遅延する為、スケジュールの作成においてクリティカルパスを特定しておくことはとても重要です。 プロジェクトマネジメントの資格試験などではクリティカルパスの求め方などが出題されますが、今はプロジェクト管理ツールなどで比較的簡単に求めることができるでしょう。みなさんにはスケジュール作成への活かし方やその必要性について感じていただければまずはOKです。 Wiki： クリティカルパス法 2) スケジュール作成のアウトプット 計画したスケジュールは整理記載して、その後のマネジメントとプロジェクト活動に使用しましょう。スケジュールを表現する形式は様々ありますが、以下のようなアウトプットは最低限作成しましょう。 ・ガントチャート　　　　　：アクティビティの開始日、終了日を横軸で記した工程表 ・マイルストーン　　　　　：主要な成果物に関わる予定や終了日、外部との重要なインターフェイスなどを記載管理する ・プロジェクトカレンダー　：稼働日、非稼働日、納品日、シフト、特別なイベントなどを記載したプロジェクト専用カレンダー 3) ガントチャート ガントチャート（ GANTT ）はみなさんに馴染みあるツールではないでしょうか（PMBOKではバーチャートと呼びます）。プロジェクト活動の中でその進捗を管理するためにガントチャートは高い頻度で活用されます。 スケジュールを作成するためにアクティビティを整理する時にWBSを作成しましたが、このWBSはガントチャートに進化させることができます。WBSを横90度に回転させてみましょう。 するとWBSの各階層がガントチャートの「成果物、要素成果物、活動タスク（アクティビティ）」になりますね。必要な情報、特にタスクの開始日と終了日を設定して時間の概念と担当者を加えれば、最もシンプルなガントチャートができあがります。 4) スケジュール作成時にできる「転ばぬ先の杖」 スケジュールが作成できた時点で「思ったような期間にスケジュールが収まらない」、「要求されているリリース日ぎりぎりになりそうで不安が残る」という現実を見て重い気持ちになるはずです。不安を抱えた計画を実行しても良いことはありません、この時点でできることはなんでしょうか？ ①減らせる作業はないだろうか？ 例えばAという機能は実装しなくても、すでに存在するBという運用を使えばすむのでないか？というように、改めて計画を見直してみましょう。また役割分担を変更することで、例えば「CさんはAという機能実装するために事前に仕様書の読み込み時間が必要。一方、Dさんはすでにその仕様書を読んでいると聞いている。作業を交代すればその分の時間が削減できそうだ」ということもあるでしょう。当たり前を見直して、少しでも作業を減らせるポイントを見つけましょう。 ②人を増やせないだろうか？ 追加人員を投入して期間を圧縮する方法を「クラッシング」といいます。追加分のコストとトレードオフ（コスト増加）になるのですが「お金がかかってもスケジュールが短縮されれば」と考えて実施されるケースも少なくありません。基本的には人を増やせば所要時間の短縮につながりますが、事前の引き継ぎや作業にあたる為の知識を得る必要がある場合、すぐに期待するパフォーマンスや短縮効果が得られないことも理解しておきましょう。 ③手がつけられるところからはじめる？ 前後関係（FS）の作業を並行して実施することで期間を圧縮する方法を「ファストトラッキング」といいます。例えばAチームの作業と後続開始のBチームの作業には数日の待機期間があるが、待機せず同じ時期に作業を行えば待機期間が削減できます。ただし、無理な前倒しには注意してください。例えば「要件定義前に開発を始めて、要件が変わったので開発が無駄になった」というように手戻りリスクがあるからです。 ④メンバ変更はできるだろうか？ 「チームにはAさんがアサインされているが、Bさんの方が経験豊富で同じタスクを数倍早く完了できると考えられる。交渉してAさんとBさんを交代してもらうことはできないだろうか？」というように、スキルと生産性が高い要員を引き入れたり交代したりすることも一つの方法です。日頃からメンバのスキルセットへ関心を持っておくことも重要です。 ⑤プロジェクトスコープの削減はできないだろうか？ どうしても要求スケジュール内に収まらない時の手段として、スコープ自体を調整することも選択肢に入れましょう。その際は必ず承認が必要です。 スケジュールをコントロールする スケジュールは作成してからがスタートであり本番です。プロジェクトは絶えず変化するので、常に見守りながら変化に即してスケジュール見直したり修正していくものです。計画時点からの変化、要求変更やシステム問題、体調不良での要員離脱など、必ずスケジュールを修正しなければならない問題は起こります。「なんでスケジュール通りに行かないんだ！」ではなくスケジュール通りに行かないもの、さあどうしようか、と思える心構えと備えをしておきましょう。 1) スケジュールをコントロールするために とはいっても、できれば計画通りにコトが運んで欲しい…と思うのも当然です。 まずは常にプロジェクトスケジュールと「現在の状態」の確認を行うこと スケジュールに変更を来しそうな要因へ事前に働きかけ、その芽を摘むこと スケジュール変更が必要か常に確認する 変更発生時（変更発生が必要と思われた時）にはその影響をを測定して、速やかに変更を適用すること 2) PMは常に自分の「予備（バッファ）」を持っておく 前述の通り、どれだけ準備計画しても、必ずスケジュールを変更しなくてはならないことは起こります。起こるとわかっていることですから、備えを計画しておくこともできますね。 計画通りにいかないというのはスケジュールが伸びる（増加する）ことです。この増加に対して「予備として備えておいた期間を充て」ることで余裕を持たせることができます。ではどれぐらいの予備を想定しておけばいいかというと、これは概ね10％程度が適当だと言われています。もちろんみなさんの経験から10％を前後する場合もあると思いますが、大規模プロジェクトや難易度の高いプロジェクトでは10％より多めに設定するとよいでしょう。 3) 打ち手は「クリティカルバス上」でなければならない クリティカルパス＝最長の重要タスクであり、ここに遅れがでると後続に影響がでてプロセス全体も遅延しますね？スケジュールにおける準備や打ち手は常にクリティカルパス上に意識を向けて、クリティカルパス上に施さなければなりません。例えば、リーダーや責任者は「クリティカルパス上の作業を担当しない」のが原則です。なぜならリーダーはチームメンバのマネジメントや監督も必要であり、十分にクリティカルパス上の「タスク」にリソースを投入できないリスクが考えられます。またパス上に「優秀なエンジニアや担当者を配置する（※経験不足の人員をアサインしない）」といった工夫（打ち手）もあるでしょう。当たり前ですが他の経路（クリティカルパス以外）に人員やコストを投入しても、意味がないとは言えませんがスケジュール短縮はできませんね。 また注意として「クリティカルパスに打ち手を施し期間短縮すると、新しいクリティカルが生まれる（生まれる可能性）」ことになります。「今の」クリティカルパスがどこにあるのか、常に追いかけてコントロールするようにしましょう！ 予備（バッファ）の注意ポイント ①「個別のアクティビティに対してバッファを持たない」ということです。なぜならアクティビティの正確な対応期間がわからなくなり管理不能に陥るからです。あくまでプロジェクト全体又は設計・開発・テストなど工程の最後に対して予備期間を設けて、必要に応じて適応いくようにしてください。 ②学生症候群やパーキンソンの法則という言葉を聞いたことはありますか？簡単に言えば、人は「時間」や「資源」の余裕がある（余裕があるとわかる）とその余裕を残さず使ってしまう、というものです。（①）にあるように、タスクにバッファを置くと計画上は目に見えて（バレて）しまい、メンバに使われてしまう可能性が高くなります。そうすると折角捻出した予備も水の泡です。ですのでメンバに見えないようにPMだけがバッファを持つこと（バレないように後まで隠しておくこと）がコツです。 さいごに 2回に分けてスケジュールを作成する為の準備となるWBSでの要素分解、アクティビティの順序や見積もり方法、スケジュール作成、そのマネジメント方法を学びました。納得できるようなケジュールを作成することがプロジェクトの成功に直結します。 次回のテーマは「コストマネジメント」です、予算オーバーを防ぐ計画策定と管理方法を整理していきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ The post 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているタカです。 普段はプロジェクトのマネジメントや開発者としてプロダクトの開発に関わっています。 以前投稿した Notionでプロダクトバックログを管理するビューを作成する の記事の最後に触れた NotionのGitHubインテグレーション機能 と、その機能を活用した自分たちのチームのブランチとプルリクエストの運用フローを紹介します。 Notionでプロダクトバックログを管理するビューを作成する NotionのGitHubインテグレーション機能とは Integrate GitHub – Notion Help Center NotionのGitHubインテグレーションは、NotionとGitHubを接続し、GitHubのプルリクエスト (PR)とNotionのページに紐づける機能です。 機能としてはシンプルで、連携したGitHubのリポジトリにあるプルリクエストを自動または手動でNotionのページのプロパティとして表示するものになります。 ただ単に表示するだけではなく、プルリクエストのステータス（Open、Merged）が自動で反映されるので、Notionからプルリクエストの状態を即座に確認できるというメリットもあります。 なお、GitHubとNotionの連携設定は 公式のヘルプ を参照してください。両サービスの権限があれば設定は簡単に行えます。 プルリクエストの紐付け方法 紐付け（リンク）方法は下記のステップで行えます。 1. NotionのページにIDプロパティを追加する 2. 外部接続 GitHubプルリクエストプロパティを追加する。 1. ステータスプロパティがある場合、そちらとプルリクエストステータスの連携設定も可能 3. プルリクエストを紐づける 1. 手動の場合、プルリクエストのURLをプロパティに貼り付ける 2. 自動の場合、プルリクエストのタイトルにID名称（キャプチャの場合SBI-976）を追加する。 ステップ1 ステップ1 ステップ1 ステップ2 ステップ2 ステップ2 ステップ3 手動 ステップ3 手動 ステップ3 手動 チームで導入した運用ルール この機能をベースに直近の開発ではブランチとプルリクエストの運用方法を見直しました。 ブランチ 自分たちのチームのブランチ運用は git-flow を採用しています。 このフローにおいて機能改修を行うブランチ feature/ ︎ ︎の名称を feature/PBI-⚪︎⚪︎ としました。 意図としては、プロダクトバックログ（PBI）ごとになるべく1つのブランチで作業することにして、どのような改修作業を行うかを明確にしたいためとなります。 なお、hotfixによる急ぎの対応では、このルールの限りではありません。 プルリクエスト こちらのルールでは、ブランチ名称を踏まえ、 developのブランチに出すプルリクエストのタイトルには、必ず PBI のIDプロパティを含める というルールにしました。 PBIをタイトルに含めることで、連携機能により、自動でNotion側のPBIにプルリクエストが反映されます。これにより、コードの修正が必要なPBIを受け入れ完了にする際に、自動反映されたプルリクエストがMergedの状態であるかを確認することも出来るようになりました。 なお、ブランチのルールには沿わないですが、細かい修正を行う際に、複数のPBIを1つのプルリクエストに紐付ける場合は、そのタイトルに全ての関連PBIのIDを含めることで、それぞれに自動的に紐付けが行われます。 導入してみて感じたメリット 本ルールを導入して分かったメリットは作業をした内容が可視化されることでした。 開発担当者にしてみれば、自分の作業内容を プロダクトオーナーやQA担当者をはじめ、チーム内に共有できますし、要件に対してどのような修正を行ったかも一目でわかるようになりました。 また、レビュアーから見ても、GitHubのプルリクエストをすぐ見れる導線が増え、ブランチやプルリクエストにPBIのIDをつけることで、1ブランチで複数のPBIの作業をすることが少なくなり、1回のレビューの量が減るメリットにもなりました。 おわりに 今回の内容は以上となります。 運用負荷がほぼゼロとうこともあり、今回設けたルールは自然とチームに受け入れられました。 GitHubとNotionの連携機能を使うことで無理なくバックログとプルリクエストを紐付けて可視化ができるので、プルリクエスト名を統一したい、バックログからプルリクエストを辿りたいなどで困っているチームのは、ぜひ一度試してみてください。 関連記事 Notionでプロダクトバックログを管理するビューを作成する The post GitHubプルリクエストをNotionで管理：効率的なブランチとプルリクエスト運用のガイド first appeared on Sqripts .

こんにちは。Q4Aと申します。 私はテストエンジニアとして、長らくお客様常駐で業務した後、ここ数年は現場を離れて部門管理を担当しています。現場時代でも担当案件の状況説明やリリース判定時に、品質の良し悪しについて説明したり考えたりするシチュエーションは多々ありましたが、今も商談の場でお客様と話をしていると、やはり品質の良し悪しについては凄く気にされています。 言葉としてはポピュラーですが、ひとくちに品質と言ってもいろいろな視点があります。今回はそんな話をしたいと思います。 品質が良いってどういうこと？ 「皆さん品質が良いってどういうことだとお考えですか？」 私は部門内の新人研修でよくこの質問をするのですが、一般的なECサイトを例に考えてみましょう。 面白いことに回答は多岐にわたります。 「機能が充実している」 「レスポンスが早い」 「使い勝手がよい」 いろいろな意見が挙がりますが、 はい、全部正解です。 所謂ひとつのワインバーグ的な有名な決め言葉ですが、 「品質とは誰かにとっての価値である」 ワインバーグ と言われるように、品質にはいろいろな視点があるのです。 そのため我々テストエンジニアは、様々な視点でお客様やユーザーの求める品質を考えてテストする必要があります。機能テストや性能テスト、セキュリティ診断等、お客様から直接指定のご依頼がある場合はよいですが、大規模プロジェクトや社会性の高い製品の場合は、あらゆる視点の品質を考慮しなくてはいけません。規模の小さい製品でも、機能テスト要求の中にユーザーの操作性や他ソフトとの共存動作など見えないニーズも隠れていたりします。 ただ、このように様々な視点を一から全部考えるのは大変ですよね。そんなあなたのために先人の知恵があります。それらは品質モデルというもので体系的にまとめられているのです。 ISO/IEC 25000 シリーズ（SQuaREシリーズ） 品質モデルとは、ソフトウェアの品質を確保するのに必要な特性をモデルとして定義したものです。国際規格であるISO/IEC 9126が長らく重用されてきましたので、9126の数字を聞いたことがある人は多いと思います。その後、ソフトウェア技術の進化や利用形態の多様化など様々な要因を経て再編され、現在はISO/IEC 25000 シリーズとして整備されています。 ISO/IEC 25000 シリーズは、システムおよびソフトウェア製品の品質要求と評価に関して規定している国際規格「Systems and Software Engineering – Systems and Software Quality Requirements and Evaluation」の頭文字を取って、SQuaREシリーズとも呼ばれています。SQuaREシリーズでは「製品品質モデル」「利用時の品質モデル」「データ品質モデル」と3つのモデルを定義しています。私たちに馴染み深い製品品質モデルで説明すると（図1参照）、8つの品質特性と31の品質副特性で構成されています。 図1）出典： IPA「つながる世界のソフトウェア品質ガイド」 これらの特性が、冒頭で述べたいろいろな視点で品質を考える時の着眼であり観点となるのです。 例えば「機能適合性」の副特性「機能正確性」では、機能が期待どおりの処理をしているかやデータ出力しているかが確認の観点になります。そのため機能テストを実施して動作を確認します。 「性能効率性」の副特性「資源効率性」では、システムが利用する資源の量が要求を満たしているかが確認の観点になります。そのため性能テストを実施してメモリ使用量やCPU使用率などを確認します。 このようにSQuaREシリーズを利用すれば、品質を考えるときの視点が品質特性や品質副特性として網羅されているので、様々な視点/切り口で漏れなく品質やテストを考えていくことが出来ます。この点が品質モデルを利用する一番のメリットだと私は考えています。 もう1つのメリットとしては、SQuaREシリーズは国際規格なのでステークホルダーと共通の認識のもと話をすることができる点にあります。文化や立場の違い、異なる基準で品質を評価しようとすると混乱が生じるので、合意形成するにも便利だと思います。 いともたやすく使える？品質モデル・品質特性の利用方法 ここからは私の経験事例も交えて、品質モデル・品質特性の利用方法をご紹介します。 品質モデル・品質特性は、対象システムやサービスに対して、各品質特性・品質副特性ごとに品質目標や評価基準を定めて、要求を満たしているかリリース前までに評価するといった使われ方が最もポピュラーかと思います。特に非機能要件はおざなりにされがちなので、きちんと定めておくことが重要です。 品質特性ごとにテスト観点を定義 私が以前参画していたあるプロジェクトでは、そこからさらに一歩踏み込んで、各品質特性・品質副特性ごとにテスト観点を定義して共有していました。かなり大規模なプロジェクトで、多人数でテストしていたのですが、担当者や担当チームによるテスト品質のバラつきが課題になっていました。品質特性ごとにテスト観点を定義することで、一定水準で網羅的なテスト品質を確保することが出来ました。 ただ注意点としては、共有したテスト観点はあくまで基準であり、きっかけであり、製品や機能によってはそこからさらにテスト観点を追加する必要があることです。「定義した観点だけテストしていればいい訳ではない」と考え続けることが重要だと思います。 探索的テストのチャーター検討に利用 もう1つ身近な事例を挙げますと、探索的テストのテストチャーターを考える際に、品質特性をベースに考えたことがありました。 例えば「性能効率性」の副特性「容量満足性」の観点で、各機能のデータ保存時における出力先容量不足時のエラー挙動を確認したり・・・ 「使用性」の副特性「ユーザーエラー防止性」の観点で、各入力フォームに誤った入力のまま登録エラーになった際に、入力済の正しいデータを保持しているか各登録画面で確認したり・・・ このように品質特性は、ちょっとしたテスト観点の検討のきっかけとしても利用することが出来ます。 そうはいっても、JSTQBの試験などで言葉は知ってるけど、品質モデルや品質特性の中身を詳しくはよく知らない。文献見ても小難しいことが書いてあるし、という方も多くいらっしゃるのではないでしょうか。 そんなあなたに「つながる世界のソフトウェア品質ガイド」ー！ SQuaREシリーズについては、 IPA （独立行政法人　情報処理推進機構）が発行している 「つながる世界のソフトウェア品質ガイド」 を参照することをお勧めします。 1つ1つの品質特性、品質副特性に対し、比較的分かりやすく説明してあります。例えば「使用性」の副特性「適切度認識性」と言われてもよく分かりませんが「製品又はシステムが利用者のニーズに適切であるかどうかを利用者が認識できる度合い。」と説明があると理解できます（図2参照）。 図2）出典： IPA「つながる世界のソフトウェア品質ガイド」 ただしこの要求を満たしているか確認するためにどのようにテストするかはまた別問題で難しいです。同ガイドには、各品質副特性の品質測定量も記載されていますので、興味のある方は参考にしてください。 最後に同ガイドの特徴をお伝えしておくと、PDF216ページで読み応え十分というところです。もう京極夏彦先生の小説くらい長いです。ですので私は必要な時に必要な箇所だけ確認する使い方をしています。 また、冒頭の「第1章　あらためて品質を考える背景」などは、読み物としても非常に面白いです。発行は2015年と古いものの、IoT時代におけるテストの重要性を改めて再確認させられ、テストエンジニアとしてのモチベーションを高めるのにも最適です。 まとめ さて、ここまで品質モデル・品質特性について経験事例も交えてお話してきました。品質にはいろいろな視点が求められるため、ソフトウェアの品質モデル・品質特性を下敷きに考えるとよいと思います。 いろいろな視点の品質を網羅的に確認することができる 国際規格なのでステークホルダーと共通の認識のもと話をすることができる 学ぶにも使うにもよい体系的にまとめられたガイドもあるので、ぜひ使ってみてはいかがでしょうか。 最後までお読みいただきありがとうございました。 ＞「ありがとう」それしか言う言葉がみつからない・・・ The post いともたやすく使える品質特性ッ！ first appeared on Sqripts .

みなさんこんにちは、マッシュです。 今回、eKYCのテストを行う際に使用可能なテストデータの作成方法について紹介していきたいと思います。 はじめに eKYCとは electronic Know Your Customer の略で、免許証やマイナンバーカード、本人のセルフィー撮影など、本人確認が必要な手続きを オンライン上 で行う仕組みのことです。 ※オフラインで行う本人確認はKYC(Know Your Customer) ※ eKYCとは（Wikipedia） eKYCは口座開設やクレジットカードの発行等で使用されているため、みなさんの中にも実際に使ったことのある方は多いのではないでしょうか。では、eKYCを利用した時のロケーションは同じだったでしょうか。部屋の明るさ、照明との距離等、様々な違いがあったはずです。 エンドユーザがシステムを利用するロケーションが異なるなら、その点も考慮したテストデータを使用してテストを行うべきです。そこで、私がこれまでに行ったeKYCのテストで使用したテストデータの一部を紹介していきたいと思います。 テストデータの事例 それではさっそく、eKYCのテストで活用できるテストデータの紹介をしていきます。 光量、光源のテストデータ 光量を調整可能な光源を使用して、本人確認書類の明るさを調整し、上限と下限の光の許容値を超えた場合の動作を確認します。券面に直接光を当てないように注意し、本人確認書類の周囲の明るさを調整できるように環境を構築します。 強い光や弱い光を照射し、本人確認書類の表示物の読み取りやすさを変化させます。これにより、「読み取れない」または「読み取り時にエラーが発生する」といった結果を得ることができます。 また、光量を数値化して調整可能な光源を用意するか、光量を計測する照度計を用いることで、テスト条件を定量的に示すことが可能となります。 上記と同様の方法で、色温度の異なる光源(電球色、白色、昼光色など)を使用することで、本人確認書類を読み取れない色温度がないかを探ることができます。 背景のテストデータ 本人確認書類を読み取る際の背景を変化させます。本人確認書類の券面と同色または類似色、デザインイラスト系、布、木目、光を吸収することを想定した黒一色の背景など、ユーザがeKYCを利用する際のロケーションをイメージしながら様々な背景を準備します。 用意した背景の上に本人確認書類を配置し、本人確認書類と背景の境目を不明瞭にすることで、「読み取れない」、「読み取りづらい」といった結果が出ないかを探ります。光源や照度など、背景以外の要素は一定のものとして、背景の影響を明確に区別するために注意します。 白とびのテストデータ 高輝度のライトなどを使用して、光を本人確認書類の一部にピンポイントで照射し、白飛びを起こした状態で撮影を行います。 住所や名前などの文字部分や顔写真など、白飛びを発生させる箇所や面積を変化させながら、本人確認書類の撮影を行います。eKYCでの読み取りが成功した場合には、本人確認書類の情報が人の目でも読み取れる状態で取得できているかの確認も必要です。 手ブレ(ピンぼけ)のテストデータ 次は手ブレのテストデータを用意したいと思います。 ここまでに紹介したテストデータについては、光源や光の角度、背景を同じにすることで再現が可能な内容でした。手ブレを起こすだけであればスマホを振りながら本人確認書類の撮影を行うことで可能ですが、毎回、同じ角度、度合いで手ブレを起こすのは困難です。そのため、テスト条件を定量的に示せず、テスト結果も曖昧になってしまいます。 そこで手ブレのデータについては、ツールを使用して作成していきたいと思います。まずは元となる手ブレが起きていない画像と ガウシアンフィルタ を使用可能な任意の画像処理ソフトウェアを用意します。ガウシアンフィルタは、撮影した画像のノイズ(荒れ)を軽減する効果を生む技法ですが、デメリットとして、処理をした画像のエッジ(輪郭)がぼやけてしまう欠点があります。 この特徴を利用し、元となる手ブレが起きていない画像をガウシアンフィルタを通して標準偏差の値を調整することで、意図的にエッジのブレを起こした画像を作成します。この画像をテストデータとして使用することで、手ブレの方向、度合いを定量的に示すことが可能となります。 まとめ 今回ご紹介したのは、テストデータのごく一部に過ぎません。実際の本人確認書類には擦れや傷、汚れなどがあり得ますし、また、本人のセルフィー撮影においても髪の色、化粧の程度、カラーコンタクトの有無など、さまざまな要素を考慮する必要があります。 今後もテストデータを検討する際には、システムを利用するユーザのペルソナやロケーションを十分に考慮したいと思います。 The post eKYC（電子顔認証）のテストデータの紹介 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。このシリーズでは、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 初回のテーマは「優れたスクラムマスターが絶対に言わないこと」です。 アジャイルになれない現場のコミュニケーション 私はアジャイルコーチとして、アジャイル開発の現場を支援する仕事を、はや14年以上続けています。よって、様々な現場を見てきたつもりですが、アジャイルになりきれていない現場でのコミュニケーションには、共通する点が多くあります。そのなかでも比較的よく聞く言葉を選ぶとすると、以下のようなものが浮かびます。 「〜さんがこう言っていた」 「すごく困っている」 「なんでこういう事を聞いたかというと・・・」 1 については、現場にいない人の話をしています。誰かの言った（であろう）言葉の意図を、正確に理解するのは至難の業です。 2 については、困り具合が曖昧です。この人の「すごく困っている」はどれぐらいの度合いなのでしょう？ 1時間困るぐらい？ 1日困り続けるぐらい？ もしかして一生？ 3 については、この言葉の前に質問や確認があったことが想定できます。なぜこの人は、理由や意図をもったいぶって先に説明せずに、質問や確認を行ったのでしょうか？ 優秀なアジャイルコーチやスクラムマスターは、上記のような言葉は使いません。 なぜなら、どれも非効率なコミュニケーションの言葉だからです。 アジャイル開発において、コミュニケーションはとても重要な要素のひとつです。それなのにわざわざ非効率な方法を選ぶ必要はないでしょう。ましてやエンジニアも非効率から効率を作り出すのが職務と言えます。こちらもわざわざ遠回りする方法を選ぶ必要はないでしょう。 細かい点かもしれませんが、こういった小さな言葉の使い方の違いが、大きな認識の違いを生み出します。 アジャイルなふるまい スクラムマスター、スクラムチーム、アジャイルチーム、アジャイルコーチ・・・。アジャイル開発に関わる人達には共通する「ふるまい」があります。 アジャイル実践者は「個人やチームの自律」を目指そうとするので、「〜しなさい」といった命令をしたり、「進捗どうですか？」のような管理的な言葉をあまり使いません。必要な場合だとしても最低限にするでしょうし、将来的になくしていく努力を進めているはずです。 これと同じく、スクラムを推進するスクラムマスターや、アジャイル開発全般を支援するアジャイルコーチにも似たような「ふるまい」があります。 これが「スクラムマスターのためのコミュニケーション講座」で学んでいくテーマです。 ふるまいは身のこなし方であったり、言葉であったりします。これらを学びながら、よりよいコミュニケーション・コラボレーションスキルを身に着け、スクラムイベントなどでのファシリテーションスキルを身に着けていきます。 この講座の内容 この講座では、以下の内容を中心に解説を行っていきます。 ファシリテーション技術 コーチング技術 1on1技術 「ファシリテーション技術」 はその名の通り、この講座のメインとなるスキルです。なんとなく「こういうもんだろう」とファシリテーションを行っている人は多いでしょうが、ファシリテーションについてはさまざまな書籍や解説書、トレーニングがあるように、体系立てて学べる部分も多くあります。ここでは「なんとなく」を「ロジカル」に変えるための解説を行っていきます。 「コーチング技術」 はファシリテーション技術と同じく、この講座のメインとなるスキルです。ファシリテーションといえばMTGなどの司会者のイメージがあるでしょうが、コーチングの主要技術もファシリテーションに有効活用できるものばかりです。純粋なコーチング技術の中から、スクラムマスターやアジャイルコーチに役立つ部分を解説していきます。 「1on1技術」 は、スクラムマスターやチームメンバーの育成に利用できる技術です。今では多くの現場で取り入れられている手法ですが、実際にやってみるととてもむずかしい方法であることがわかります。この難しさを分解し、もっと効率的な1on1の方法を考えていきます。 これ以外にも、「様々なコミュニケーション方法とその使い分け」や将来的にスキルを高めていく「コミュニケーションを鍛えるトレーニング」についても解説する予定です。 「様々なコミュニケーション方法とその使い分け」 では、我々が何気なく使っているコミュニケーションの種類を整理し、それぞれの特徴を解説します。コミュニケーションの方法は、その特徴に合わせて、さらに相手に合わせて使い分ける必要があります。どのように使いこなすのが効果的かを解説していきます。 「コミュニケーションを鍛えるトレーニング」 では、ここまで学んできた技術をより高めるための方法を考えていきます。この講座ではさまざまなテクニックや経験談を語る予定ですが、その場で理解できても、どう使っていけばいいか迷うこともあるでしょう。実際の現場でも活用できるように、筆者が経験したトレーニングや、自分のチームでも明日からできるスキルアップ方法を説明していきます。 この講座の対象読者 この講座の対象読者は以下になります。 スクラムチームを支えるスクラムマスターや、スクラムマスターを目指す方 アジャイル開発支援全般ができるアジャイルコーチや、アジャイルコーチを目指す方 私はプログラマからキャリアを積んできましたが、新卒研修やOJTでプログラミング言語は学んだことはあっても、仕事の現場で使えるコミュニケーション方法を学ぶことはありませんでした。多くのエンジニアも私と同じなのではないでしょうか？ 我々は仕事に限らず、人生の多くの時間をコミュニケーションに使います。よって、ソフトウェア開発に関わるすべての人たちが、この講座の対象読者とも言えます。 ＊ アジャイルコーチの仕事はさまざまです。単純にアジャイル開発やスクラムを教えるだけでなく、アジャイルプラクティスを教えるだけでもなく、アジャイルなふるまいができる人を育てなければなりません。そうしなければ、アジャイルコーチに依存する現場が生まれてしまうからです。 私が支援する現場では、それぞれの状況に合わせて勉強会という名のトレーニングを行ったりもします。トレーニングは、アジャイル開発をやるうえで、つまづきやすい部分にスポットライトを当てるケースが多く、人気のものだと「見積もりと計画づくり」、「効果的なインセプションデッキの作成」「アジャイルQAのための品質改善」などがあります（一部は Udemyでも公開している のでご興味があればどうぞ）。 https://www.udemy.com/user/dai-fujihara/ 今回のこの講座の土台になっている「チームが自走するためのコミュニケーション入門」は、一番人気のトレーニングです。このトレーニングは支援先で行っているオンライントレーニングなのですが、エンジニアだけでなく、ビジネス側にも人気で、アジャイルチームとのコミュニケーションの取り方だけでなく、そこからアジャイルな考え方を学んでくださっています。 この講座を進めながら「なんとなく」だったコミュニケーションを、「よりよい」コミュニケーションにするために、一緒に学んでいきましょう！ 次回はスクラムイベントで一番使うであろう「ファシリテーション」の解説です。 The post 優れたスクラムマスターが絶対に言わないこと first appeared on Sqripts .

こんにちは、みなさん！QAエンジニアのゆかわです。 ふりかえりの場が暗い雰囲気になりがちで、改善が上手くいかなかったり、形骸化してしまったりした経験はありませんか？そんな課題を解決する手法として、kudo cardsを導入した事例をご紹介します。 うちのふりかえり、なんか暗い？ 私たちのチームの従来のふりかえりでは、KPTなどの手法が用いられてきました。しかし、プロジェクトを良くしたいという想いから、「Problemの分析（なぜ上手くいかなかったのか？）ばかりに焦点が当たる。」、「なんとかTryを見つけても難易度が高くなってしまう。」という課題があり、暗い雰囲気が漂っていました。別のチーム（いつも楽しそうにしている）で実施していたkudo cardsという手法を紹介してもらい、私たちのチームでも活気のあるふりかえりを実現するために取り入れてみることにしました。 kudo cardsとは？ kudo cardsは、チームメンバー同士がお互いに感謝や称賛の気持ちを伝えるために使用するカードです。この手法は感謝カード、サンクスカードなどとも呼ばれています。 オフィスにボードや箱などを設置して、感謝を伝えたいときに記入し、共有します。リモートワーク主体のチームではドローツール（例えばMiro）を使う場合もあり、いくつかのテンプレートも用意されています。 カードには、Thanks、GreatJob、Congratulationsなど、複数のバリエーションのカードがあり、感謝や賞賛をしたい内容によって使い分けることができます。 実施方法や準備などは ふりかえりカタログ を参考にさせていただきました。 出典:「 ふりかえりカタログ / Retrospective Catalog P.79 Kudo Cards 」より このふりかえりカタログには、kudo cards以外にも様々な手法が紹介されているので、ふりかえりに課題を感じたら参考にさせていただいています。 ふりかえりでの活用事例 私たちのチームでは、隔週でふりかえりを行っており、その最初の約10分間でkudo cardsを行っています。その後は通常通りKPTを用いたふりかえりを行います。kudo cardsの具体的な手順は以下の通りです。 1. カードの記入 私たちはリモートワークでの業務を行っているため、物理的にカードの受け渡しをすることができません。そのため、Miroなどのドローツールを利用してカードの共有をしています。 ふりかえりの中で5分間程度時間をとり、参加者各自がカードに記入をします。行動に気づいたときに伝えられるのが一番よいのですが、日々の業務に追われている中で記載するのは大変です。そのため、ふりかえりの時間の中でしっかり時間を取ることを重視しています。 2. カードの共有 書いたカードを記入した方自身が共有します。 共有している中で他の参加者から「私もそう思う！」といった声があがることがあります。その意思表示として記載されたカードに★印をつけるようにしています。そうすることで同じ内容でも複数人が同様に感謝しているということがわかり、行動の自信につながります。 kudo cards導入後に見られた変化 kudo cards導入後、感謝を伝えられた人からは「単純に嬉しい」、「自身が行っている行動に自信が持てた」といった声があがりました。一方で、伝える人からも「場があることでしっかりと伝えることができる」というポジティブな意見を得ることができました。 導入前の課題であった、「Problemの分析（なぜ上手くいかなかったのか？）ばかりに焦点が当たる。」という点についても、kudo cardsであがってきた内容を、続けて行っているKPTのKeepとして流用することで軽減できています。ふりかえりの最初に実施することで、アイスブレイクとしての効果もあり、発言者の偏り軽減や発言の頻度増加にもつながっています。 回数をかさねていくにつれてカードの内容自体にも変化が見えてきました。最初は「いつもありがとう」といった抽象的な内容が主だったのですが、具体的な行動「この意見貰えて助かった」や成果を称賛するメッセージが増える傾向が見られました。kudo cardsの導入によりメンバーの行動に気づけるようになってきたのだと思います。 まとめ kudo cardsは、事前準備もボードやカードを用意するだけで簡単に取り入れることができる手法です。私たちのチームでも、コミュニケーションが活性化したり、自信を持って行動ができるなどの効果を実感しています。 ふりかえりが形骸化してしまったり、活気がないと感じている方はぜひ一度試してみて下さい。感謝と称賛の気持ちを伝えることができ、チームの結束を高めることができるでしょう。 最後まで読んでいただき、ありがとうございました。 The post ふりかえりに活気を！〜kudo cards導入事例の紹介〜 first appeared on Sqripts .

こんにちは、まゆげです。 今回は「便利なツール「Pict Master」が使えない環境でもペアワイズテストのパターンを効率よく作りたい」をテーマに、その際に使用するツール「PICT（Pairwise Independent Combinatorial Testing tool）」を紹介していきたいと思います。 はじめに 以前の記事（ 「Pict Master」でペアワイズ法のテストケースを高速生成！ ）でペアワイズテストのパターンをPict Masterで作成する方法が紹介されていました。 「Pict Master」でペアワイズ法のテストケースを高速生成！ ただ、いざ使おうとしたら、作業環境でダウンロード許可が下りないなど様々な事情でPict Masterが使用できなかったというケースに遭遇したことはありませんか。 かくいう私も過去に諸事情でPict Masterを使用できず、PICTのみ使用できる環境で少しだけ苦戦したことがありました。 組み合わせのパターン抽出の際に条件付き制約を考慮するのはPict Masterの制約表に記載するのが視覚的でわかりやすいですよね。それをPICTで実行しようとした時には条件付き制約の構文をPICT実行時のモデルファイルに記載しないといけません。その場合、構文を書くことに慣れていないと導入の際の高い壁になってしまうこともあるのではないかと思います。 便利なPict Masterが使えない環境でもPICTを使用してパターンを作成したい、でもモデルファイルの書き方に自信がなくて一歩踏み出せないという方に向けて、単純な条件付き制約ならば割と簡単に書けてPICTを実行できる方法を紹介したいと思います。 ぺアワイズテストやPict Masterについては先ほど紹介した 以前の記事 を参照いただくとして、今回使用するPICTを簡単に紹介します。 PICT（ Pairwise Independent Combinatorial Testing tool ）とは PICTとはペアワイズテストのテストパターンを条件に合わせて効果的に生成できるコマンドラインツールです。様々な実行オプションと実行時に付けるプレーンテキストで作成したモデルファイルにはベースとして因子と水準を記載し、さらに条件付き制約の構文を記載する（しないケースもある）ことによって目的に合ったテストパターンを生成することができます。 詳しくは GithubのPICT紹介ページ を参照してみてください PICTはコマンドラインから以下のように実行しますが、特に実行オプションなしの場合はシンプルでとても簡単です。 >PICT.exe モデルファイル名.txt ただ実行するにあたってのポイントはモデルファイルの書き方になります。ということで条件付き制約を含めて記載方法を紹介していきます。 モデルファイル（条件付き制約を含む）の書き方 以前の記事 で使われていたスーツオーダーシステム（勝手に命名．．．(;^_^A　）の例を使ってPICTを実行できるようにしていきたいと思います 因子水準表は以下のようになっていました。 ではこの因子水準表を元にモデルファイルを書いていきます。 モデルファイルの書き方 その1　※因子と水準の書き方 ↓条件付き制約がなければいたって簡単、因子（パラメータ）、水準（値）の書き方 例のように因子（パラメータ）ごとに行を分け、それぞれの水準（値）をカンマで区切ります。また因子と水準はコロンで区切ります。 例）<因子> : <水準1>, <水準2>, <水準3>, … ○上記因子水準表を元に書くと以下のようになります ITEM: Jacket, Pants, TwoPieceSuit, ThreePieceSuit, Tuxedo FINISH: Single, Double, No SIZE: Small, Medium, Large, Order PATTERN: Plain, Stripe, Check, Order OPTION: No, Yes モデルファイルの書き方 その2　※条件付き制約がある場合 手順１ 　 仕様をもとに一文で条件付き制約を書いてみる ★下記例の様にシンプルな一文に起こしてみる （例）もし因子Aが〇〇であれば（〇〇でなければ）、因子Bは～になる(～にならない) 手順２ 　 記載した一文を構文に書き換えてみる ★条件文はIF～THENで記載 （例）IF [A] =(<>) ”〇〇” THEN [B] =(<>) “～” ; 「=」の場合は「〇〇が～ならば」 「<>」の場合は「〇〇が～でなければ」 因子は［］で囲うこと 水準が文字列の場合は””(ダブルコーテーション)で囲うこと、数値の場合は””は不要 構文の文末には；(セミコロン)を記述 ORやAND、INといった論理演算子も使用できます ではスーツオーダーシステムの例に記載のあった条件付き制約3つを文章化します。 ※本文中で「条件付き制約」と記載しているものは以前の記事では「制約条件」と記載されているため、以下制約1、2、3では原文の表現をそのまま引用しています。 制約1： <制約条件> 『購入アイテム（ITEM）』が「ジャケット（Jacket）」の場合 <制約対象> 『仕上げ（FINISH）』は「なし（No）」となる 制約1を一文にすると もし [ITEM] が "Jacket"であれば [FINISH] は "No"となる。 さらに構文化すると IF [ITEM] = "Jacket" THEN [FINISH] = "No"; となります 制約2： <制約条件> 『購入アイテム（ITEM）』が「ジャケット（Jacket）」以外の場合 <制約対象> 『仕上げ（FINISH）』は「シングル（Single）」もしくは「ダブル（Double）」となる 制約2を一文にすると もし [ITEM] が "Jacket"でなければ [FINISH] は "Single" か "Double"となる。 さらに構文化すると IF [ITEM] <> "Jacket" THEN [FINISH] = "Single" OR [FINISH] = "Double"; となります 制約3： <制約条件> 『購入アイテム（ITEM)』が「○○スーツ(○○Suit」もしくは「タキシード（Tuxedo）」以外の場合 <制約対象> 『オプション（OPTION）』は「なし（No）」となる ※この制約3の場合、PictMasterの例のようにワイルドカードをつかって、さらに別条件も重なる場合、複雑になってしまい間違えやすくなります。 ですので、ここはシンプルに「〇〇スーツ」と「タキシード」以外というのを「ジャケット」か「パンツ」の場合としてしまった方が間違いは少なくなります。 したがって制約3は以下のように文章化します。 もし [ITEM] が "Jacket" か "Pants" であれば [OPTION] は "No"となる。 この場合、文章のまま以下のように記載しても良いですし、 IF [ITEM] = "Jacket" OR [ITEM] = "Pants" THEN [OPTION] = "No"; ORをひとまとめにしてINという演算子を使って、以下のようにも記載出来ます。 IF [ITEM] IN {"Jacket", "Pants" } THEN [OPTION] = "No"; ↓上記条件付き制約を構文化したものを下記にまとめます。 IF [ITEM] = "Jacket" THEN [FINISH] = "No"; IF [ITEM] <> "Jacket" THEN [FINISH] = "Single" OR [FINISH] = "Double"; IF [ITEM] IN {"Jacket", "Pants" } THEN [OPTION] = "No"; 前述の「モデルファイルの書き方 その1」で作成した 因子、水準のベース と「モデルファイルの書き方 その2」で作成した 条件付き制約 を記載したものをモデルファイルとして作成します。 ↓以下内容を記載してモデルファイル（ファイル名は任意）として保存する ITEM: Jacket,Pants,TwoPieceSuit,ThreePieceSuit,Tuxedo FINISH: Single,Double,No SIZE: Small,Medium,Large,Order PATTERN: Plain,Stripe,Check,Order OPTION: No,Yes IF [ITEM] = "Jacket" THEN [FINISH] = "No"; IF [ITEM] <> "Jacket" THEN [FINISH] = "Single" OR [FINISH] = "Double"; IF [ITEM] IN {"Jacket", "Pants" } THEN [OPTION] = "No"; 補足 　条件（条件付き制約になるもの）が複雑になりそうな場合、まずは一つずつ簡潔な箇条書きで整理してから文章化するのもオススメです 作成したモデルファイルでPICTを実行する コマンドラインから実行する方法は前述の通りですので以下に実行結果を記載します。 ITEM FINISH SIZE PATTERN OPTION TwoPieceSuit Single Order Plain No Tuxedo Single Medium Order Yes Jacket No Large Check No TwoPieceSuit Double Small Order Yes ThreePieceSuit Double Order Check Yes Pants Double Medium Order No ThreePieceSuit Single Large Stripe Yes Tuxedo Double Small Plain No Jacket No Medium Plain No Pants Single Small Stripe No Tuxedo Single Order Check Yes ThreePieceSuit Single Small Plain No Pants Double Large Plain No TwoPieceSuit 　　Double Large Stripe Yes Tuxedo Single Order Stripe Yes Pants Single Order Order No ThreePieceSuit Single Medium Order Yes Pants Single Small Check No Jacket No Small Stripe No TwoPieceSuit Double Medium Check Yes Jacket No Medium Stripe No Jacket No Order Order No Tuxedo Double Large Order No ThreePieceSuit Single Order Plain Yes いかがでしょうか、このように簡単に生成することが出来ます。 知っておくと 便利な実行オプションを活用しよう 便利に使えるオプションを紹介します。 /e: ファイル名 　重要な組み合わせを予め加えることができる スーツオーダーシステムの例だと最高金額になる以下の組み合わせを加えていましたので上記オプションを適用します。 ファイルへの記載方法はPICTの出力結果と同様にする ↓表の組み合わせを下記の様に記載して例えばケース指定.txt（任意）として保存 ITEM FINISH SIZE PATTERN OPTION Tuxedo Double Order Order Yes 以下のようにファイルを指定して実行します。 >pict.exe モデルファイル名.txt /e: ケース指定.txt 実行すると指定した組み合わせを含めてパターンが生成されます。 ITEM FINISH SIZE PATTERN OPTION Tuxedo Double Order Order Yes TwoPieceSuit Single Order Plain No Tuxedo Single Medium Order Yes Jacket No Large Check No TwoPieceSuit Double Small Order Yes ThreePieceSuit Double Order Check Yes Pants Double Medium Order No ThreePieceSuit Single Large Stripe Yes Tuxedo Double Small Plain No Jacket No Medium Plain No Pants Single Small Stripe No Tuxedo Single Order Check Yes ThreePieceSuit Single Small Plain No Pants Double Large Plain No TwoPieceSuit 　　Double Large Stripe Yes Tuxedo Single Order Stripe Yes Pants Single Order Order No ThreePieceSuit Single Medium Order Yes Pants Single Small Check No Jacket No Small Stripe No TwoPieceSuit Double Medium Check Yes Jacket No Medium Stripe No Jacket No Order Order No Tuxedo Double Large Order No ThreePieceSuit Single Order Plain Yes 赤字箇所 がオプションで追加した組み合わせです。 その他の便利なオプションをいくつか載せておきます。 /o:N 　組み合わせるパラメータの数 (N(初期値: 2)) ★PICTのオプションで3因子間以上（N因子間）でも生成可能★ /d 　モデルファイルに記載するパラメータに対する値の区切り文字を指定する （指定なしオプションのデフォルトはカンマ） /r 　生成結果をランダム化するので毎回同じ出力結果にはならない 紹介したPICTの実行オプションで3因子間網羅も出来るし、Excel等で見やすく表示できるようにすることも、生成結果をランダム化することで様々なパターンをテストすることも可能です。 PICTが使用できない！そんな時は！ （ Pairwise PICT ONLINE の紹介） ここではモデルファイルを同じように入力欄に直接記載して実行することで同じ結果が得られます。 （参考）Pairwise Pict Online ※ただし、インターネット上のサイトを利用することになりますので、セキュリティ上のリスクを考慮しないといけません。お客様に使用許諾を得るなどの対策が必要ですので使用する際には慎重を期すようにしましょう。 まとめ 条件付き制約をわかりやすい文章に出来れば構文化は簡単にできます 結果誰でも条件付き制約の構文を記述するというハードルが下がってPICTを気軽に使いやすくなります まずは簡単な条件付き制約の構文を書くところから始めて、慣れてきたら色々な演算子などを駆使してより複雑な条件付き制約の構文を書いてみましょう おまけ せっかくなので作成例をもう一つ、仕様から文章化して実行結果までを参考までに記載しておきます。 ホテルの予約システムの仕様例　※PICT適用のためのサンプル仕様（オリジナル）です 【仕様】 ・ 部屋のタイプは4種類（シングル、ツイン、ダブル、ダブル2台） ・ 一部屋の宿泊人数は1名～4名 ・ 宿泊プランには朝食付き、朝夕食付き、素泊まりがある ・ 一回の予約で可能な宿泊日数は1泊～5泊 ・ シングルは1名利用に限る ・ ツインとダブルの1名利用は可能 ・ ダブル2台の部屋は2名から4名の利用が可能 ・ 3泊以上の場合に限り、素泊まり利用が可能 ・ 連泊は5連泊までを上限とする 【因子水準の整理】 部屋タイプ：シングル、ツイン、ダブル、ダブル2台 宿泊人数：1、2、3、4 プラン：朝食付き、朝夕食付き、素泊まり 宿泊数： 1、2、3、4、5 【条件付き制約の文章化】 もし［部屋タイプ］が”シングル”だったら、［宿泊人数］は1名であること もし［部屋タイプ］が”ツイン”か”ダブル”だったら、［宿泊人数］は2名以下であること もし［部屋タイプ］が”ダブル2台”だったら、［宿泊人数］は2名～4名であること もし［宿泊数］が”素泊まり”だったら、［プラン］は”朝食付き”か”朝夕食付き”であること もし［プラン］が”素泊まり”だったら、［宿泊数］は3～5泊であること 【モデルファイル（因子水準、条件付き制約の構文化）】 type: Single, Twin, Double, Doublex2 Guests: 1, 2, 3, 4 Plan: breakfast, dinner, stay Stays: 1, 2, 3, 4, 5 IF [Type] = "Single" THEN [Guests] = 1; IF [Type] = "Twin" OR [Type] = "Double" THEN [Guests] <= 2; IF [Type] = "Doublex2" THEN [Guests] IN {2,3,4}; IF [Stays] <= 2 THEN [Plan] = "breakfast" OR [Plan] = "dinner"; IF [Plan] = "stay" THEN [Stays] IN {3,4,5}; 【実行コマンドと実行結果】 > PICT.exe モデルファイル.txt ↓　↓　↓ 以下は出力結果を表に転記してナンバリングしたものです。 一連の流れを載せてみました。水準が数値の場合だった際の条件付き制約の構文の例も併せて記載してあります、これらを参考に是非色々試してみてください。。 参考資料 GitHubのPICTの紹介ページ PICTについて詳細なことはこちらを読むとさらに理解が深まります。 PICTの最新版 （2023年12月現在の最新はVer.3.7.4）の在り処の紹介 以前はインストーラでインストールが必要でしたが、現在は.exe（実行ファイル）のみの配布となっています。 最後までお読みいただき、ありがとうございました。 The post PICTを活用してペアワイズテストのパターンを手軽に生成する方法 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 ＜テストエンジニアのための論理スキル[再]入門　連載一覧＞ ※クリックで開きます [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT 第6回のテーマは、「文レベルの論理の言葉」のうち条件や場合を示す言葉の意味と働きです。 「希望者が5人集まったら、イベントを開催します」といった、 “特定の条件/場合を前提とした主張” を言いたい時があります。このような表現はソフトウェアにとっても重要であることは 第1回 で述べました。実際、ここまでに出てきた例の殆どで使われています（読み返してみてください！）。 この、条件や場合を示す言葉に出逢った時は、どういうことに注意を向けるとよいでしょうか。 前回に引き続き、一般的な文章や日常会話などで用いられる語句や表現を 一般語 と呼びます。 条件・場合を表す言葉の基本形・“ならば” 文章の中で“条件や場合を示す”際に目印として使われる語句の代表格が、 “ならば” や “場合” です。 「論理の言葉」としての“ならば” 典型的な条件の表し方は、 「PならばQ」 という形を取ります。 「テストが全件合格したら、テストを終了する」 「当日雨天の場合、大会を中止とする」　etc. Pを 前提(仮定)または前件 、Qを 帰結または後件 といいます。 「テストが全件合格」「当日雨天」が 前提 「テストを終了する」「大会を中止とする」が 帰結 「PならばQ」は、 「Pという前提が成り立つなら、Qという帰結が成り立つ」 ということを表しています。 この“ならば”の働きを「 条件法 」といいます（「もし昨日晴れていたら、○○ランドに行ったのに」のような、事実に反することを述べる条件法とは異なります）。 PとQの関係に注意してください。 「PならばQ」は、「Pが成り立つ時はQが成り立つ」「Pが成り立つのにQが成り立たないことはない」とだけ言っており、「Pが成り立たない時」のことは何も言っていません。 従って、PでなくてもQであることがあり得ます。（集合のベン図的に表すと、「PならばQ」は図6-1の左を指しています）。 図6-1　「PならばQ」のベン図 「テストが全件合格」していなくても、テストが終了することはあり得る（他の条件があるかも知れない） 「当日雨天」の他にも大会を中止する条件はあり得る（強風の場合、参加者が揃わない場合、など） 等値(同値)の“ならば” 「PならばQ」もその逆「QならばP」もともに成り立つ、という場合もあり、これを「双条件法」といいます。（PとQが“同じ大きさ”でぴったり重なる。図6-2） 図6-2　双条件法(等値(同値)の“ならば“) 「稼働中にバッテリー残量が10%を切ったら、“充電して！”と音声で知らせます」  稼働中に“充電して！”と音声が流れる場合は、バッテリー残量が10%を切っている 「獲得ポイントが○○になったら、ランクAAになります」 ランクAAになる条件は○○ポイント獲得のみ 等値(同値)の“ならば”を明示する語句として、「……の場合、そしてその場合に限り、～である」という言い回しが用いられることもあります。 （英語の論文などでは”if and only if …”という表現が使われます(“iff”と略される)） ソフトウェアに出てくる“ならば” ソフトウェアでは、条件や場合を示す“ならば”は、成り立つ成り立たないというよりは、特定の条件/場合に対応する特定の処理/動作や、特定の処理/動作ができるための条件を記述する局面で使われることが多いでしょう。 「条件を満たさない時の動作」といった記述が添えられることも多いです。 ある箇所で次のような記述があったとして： 「利用者がログインしており、SP権限を持っている場合は、XYZ機能を使うことができる」 「数値のいずれかがゼロの場合、エラーメッセージE1を出力する」 別の箇所で、 「別の条件が満たされている場合、XYZ機能を使える」や 「別の条件に該当する場合、エラーメッセージE1を出力する」 という記述があることもあります。 逆・裏・対偶 「PならばQ」の“変形” 「PならばQ」のP(前提)とQ(帰結)との関係に着目して、次の三種類の変形が考えられます。（図6-3） 図6-3　逆・裏・対偶 逆 ：　PとQを入れ替える。 「QならばP」 裏 ：　PとQをそれぞれ否定する。 「NOT(P) ならば NOT(Q)」＝ 「PでないならばQでない」 対偶 ：PとQをそれぞれ否定し、さらに入れ替える 「NOT(Q) ならば NOT(P)」＝ 「QでないならばPでない」 もとの文の「 裏の逆(または逆の裏) 」に等しい 逆・裏・対偶は、同じ変形を二度繰り返すと、もとの形に戻ります。図で確認しましょう。 もとの文：「PならばQ」 逆「QならばP」の逆は、「PならばQ」 裏「PでないならばQでない」の裏は、「PならばQ」 対偶「QでないならばPでない」の対偶は、「PならばQ」 なお、逆と裏は互いに対偶の関係にあります。（図6-3） もとの文と逆・裏・対偶との関係 もとの文に対して、逆・裏・対偶について以下のことが言えます。 逆・・・「PならばQ」が成り立っていても、 逆「QならばP」が成り立つとは限らない 「テストを終了するなら、テストが全件合格している」？？ 「大会が中止になるなら、当日雨が降っている」？？ （「等値(同値)の“ならば”」なら、逆は成り立つ） 裏・・・「PならばQ」が成り立っていても、 裏「PでないならばQでない」が成り立つとは限らない 「テストが全件合格していないなら、テストを終了しない」？？ 「当日雨が降らないなら、大会は中止にならない」？？ （「等値(同値)の“ならば”」なら、裏は成り立つ） 対偶・・・「PならばQ」が成り立つなら、対偶「QでないならばPでない」は必ず成り立つ 「テストが終了していないなら、テストが全件合格しているのではない」 「大会が中止にならないなら、当日雨は降っていない」 条件・場合の表現をチェックする 文章の理解を確実にするために、条件・場合の表現の逆や裏を考えて、文章全体を調べてみたり考えてみたりする方法があります。 逆： 「Qが成り立つ場合には、Pという前提が成り立っていると考えてよいか」と考えてみる 裏： 「Pでないならば、Qにはならないか」と考えてみる 具体例① もとの文：「利用者がログインしており、SP権限を持っている場合は、XYZ機能を使うことができる」 逆： 「XYZ機能を使うことができる」なら、「ログインしており、SP権限を持っている」と言えるか。他の場合はないか 裏： 「ログインしており、SP権限を持っている」のでないならば、「XYZ機能を使う」ことはできないか 具体例② もとの文：「数値のいずれかがゼロの場合、エラーメッセージE1を出力する」 逆： 「エラーメッセージE1を出力する」ならば、「数値のいずれかがゼロ」であると言えるか。他の場合はないか 裏： 「数値のいずれかがゼロ」でないならば、「エラーメッセージE1を出力」しないか 「同じ処理をする他の場合はないか？」「ここに記されている“条件や場合”を満たしていない場合の動作はどうなる？」といったことを自然に気にかけている人も多いと思います。それは、 「PならばQ」の形の文に対して、PとQの関係が自然に気になるから なのかも知れません。 むすび 6回にわたって、“論理的”に考えるための「基本的な道具」である「 論理(ロジック)の言葉 」をいくつか見てきました。 取り上げたのはあくまでも「基本的な道具」です。これらを憶えたら、ぜひ次のステップに進んで論理のスキルを高めてください。 文章レベルの論理：文章の構造を理解するための論理の言葉 長い文章の筋道を追ったり、話を整理して論旨を把握するのに役立ちます 推論：考えの筋道を立てるためのルール 前提から結論を導き出したり、 複数の事象を一般化して考えたり、事象から原因の仮説を立てたりする方法 （故障の要因の推測や、故障の原因の推測などに役立ちます） 参考文献 『入門！論理学』(野矢茂樹 / 中央公論新社) 『論理的思考の技法〈1〉第2版　「ならば」をめぐって』(鈴木美佐子 / 法学書院) 『新版　論理トレーニング』(野矢茂樹 / 産業図書) 『スマリヤン先生のブール代数入門』(スマリヤン / 共立出版) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) 連載一覧 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか 【連載初回、全文公開中】 [第2回] プログラムレベルのロジック (1)概要編 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算 [第4回] プログラムレベルのロジック (3)解説編・論理演算の組合せ [第5回] 文レベルのロジック (1)文レベルのAND/OR/NOT The post [第6回] 文レベルのロジック (2)条件・場合を表す言葉 first appeared on Sqripts .

こんにちは。まーくー＆くまねこです。 ゆるっとシリーズ第6話です。 前々回 、 前回 から引き続き、学び直し回です！ 書籍「基本から学ぶソフトウェアテスト」を読んで、現在でも活かせる内容があるのか？ないのか？会話形式でお話しさせていただきます。 最後まで楽しんで読んでいただければ幸いです！ 自己紹介 まーくー QA業界経験2x年のベテラン（おじさん）エンジニア。 過去のミスに愕然とする事ってありますよね？えっ？ありませんか？私はあります。。。 くまねこ QA業界経験1x年のエンジニア。 ジムに行った後、「運動したし、食べまくるぞ！」ってなる日ありますよね？僕はいつもです。。。（元の体重に戻りつつあります） イラストby くまねこ 何やらまーくーが愕然としている模様…何があったのでしょうか？ 今日も二人のやりとりをお楽しみください！ 今日も仲良く学び直し！山あり谷ありの探求の旅？？？ ぐあああぁあああああ！（突然の叫び！） あらっ、まーくーさん、どうしたんですか？Knock knock Downしてますね…？（愕然として青ざめている…何があったんだろう…？） く、くまねこさん、、、書籍「 基本から学ぶソフトウェアテスト （第4版）」P.83の欄外を見てくれぇ・・・ は、はいっ！ふむふむふむふむ…（ふむむ…何があるんだ？？？） ここだよ…こ、ここぉ～！Woo～！ 訳注：原著は1993年に執筆されており、2000年問題はそのころまだ騒がれていなかった。 基本から学ぶソフトウェアテスト 今までの学び直し記事で、「20年前の書籍を紹介している」って書いてたけど、原著は30年前のものだったんだぁ。。。 30 years ago～！…そうみたいですね♪（もっと昔だったのかぁ…ますますエインシェント！でも、何を取り乱しているんだろう？） 全世界に公開されている記事で30年前のものを20年前のものと、虚偽の記載をしてしまった。もう取り返しがつかない・・・。原著に裁かれているような気がするぅ…ぐあああぁあああああ ちょっと落ち着いてくださいよ。まぁ日本では20年前に発売された書籍だから問題ないんじゃあないですか？This book was made in Japan！We live in Japan！さっ、今日は第5章、第6章から学び直していきましょう！ （えっ？あっさり？Why？取り乱した自分が恥ずかしい。。。そんな自分に負けないためにあれを使おう…）お、おぉ。そ、そうだね。ま、学び直して行こう！Bigbang ？ \ / → → ﾉｼ Hello World Yeah～！ \ /（訳：まーくーさん、BigBang使ってここまでの流れを再創生したのは良いけど…うっかり自分から「学び直ししよう」って言っちゃった～！ぐあああぁああああ～！((( )))） 第5章 障害の報告と分析を読んで まずは「本章のねらい」からですね。本章では「障害レポートをどう使えばプログラマとスムーズに意思疎通できるかを説明する。」とあります。 「バグチケット」「バグ票」「バグレポート」「障害票」など現場によっていろいろな呼び名がありますよね？ そうだね、本記事では書籍に記載のとおり「障害レポート」で進めましょう！ はーい。 障害レポート以外でもプログラマとのコミュニケーションは取る必要があるけど、テスト担当者としてプログラマと障害のやり取りをする一番重要なツールが障害レポートだ。これが上手く書けないといわゆる「バグピンポン」が発生してしまう。 ﾉ あ、プログラマとテスト担当者で障害レポートが行ったり来たりするやつですね。なかなかこちらの言いたいことがプログラマに伝わらず悲しくなってくるやつですね。 でもテスト担当者の書く障害レポートの内容が不十分だったり、書き方が悪かったりすることが原因で発生することが多いんだ。テストを実施する立場で言えば、この章はとても重要だね。 心して掛かります！ちなみに「本章で紹介するレポートは、紙での運用を想定している。」っていうのは、時代を感じますね。 いまはほとんど障害管理システムを使っていたり、表計算ソフトなんかで表にして運用することがほとんどだからね。でも第一報は紙って現場もまだあったりするよ。 えー。びっくり。そうなんですねー！障害管理システムでも紙でも基本的に内容はいっしょですよね？本章で記載されている以下をちゃんと理解して、良い「障害レポート」が書けるよう学び直します ・障害レポートの項目 ・質の高い障害レポートの書き方 ・再現性のある障害分析の方法とコツ ・障害を再現させる方法 基本から学ぶソフトウェアテスト おぉ、冒頭にとても良いことが書いてあるね！ 障害を見つけたら、その場でレポートを作成せよ！ 基本から学ぶソフトウェアテスト メモを取ってあとから書こうとしても、時間が掛かったり、曖昧な記述になってしまったり・・・すぐに書くって大事ですよね。 うん。すぐに書けないこともあるけど、極力早めに書いた方が良いのは間違いない！障害を早く開発側に報告できるしね。次にレポートの内容について記載すべき項目があげられているよ。 ふむふむ…ふむふむ…書籍に記載されている障害レポートのフォーマットを見てみると、現在の業務でも使っている項目は網羅されているようです。共感したのは、障害検出～報告までのところです。実際のテスト中に障害と思われる現象を検出した時、今までの手順や条件などを整理しながら、必要なことをなるべく簡潔に開発チームに伝えられるように心がけています。 GOOD！障害レポートの報告内容によって問題の重大さの認識や、開発側のデバッグ効率などに影響を与えるから、改めて理解して実践できるようになっておきたいところだね。 あと、スケジュールに余裕がないピリピリした状態でも開発チームと良い関係で進めていけるよう、障害レポートの表現にも気を付けています。ちょっとした気配りをするだけで、テスト担当者・開発者間の行き違いや感情的な衝突を防いだりできるので、言葉遣いも重要ですよね！ 誰が言ったか知らないが、「バグを憎んで人を憎まず」ってのが大事だよね ですね（心に刻みます！）。次は「再現性のある障害の分析のコツ」＆「障害を再現させる方法」！これは興味のある方も多いのではないでしょうか？ だよね。まず障害の分析として以下を挙げている。 ・最も致命的な現象を明らかにする ・最も簡単で制約の少ない条件を明確にする ・同じ障害を発生させる別の手順を見つける ・関連する障害を探す 基本から学ぶソフトウェアテスト ふむふむ。上記の情報がそろっている障害レポートなら、開発者もプログラムの修正がしやすそうですね！ 続いて「再現性のある障害の分析のコツ」＆「障害を再現させる方法」が詳しく記載されているよ。 ここは特に現在のテスト担当者にも活かせる内容ですね！障害を検出したときって、上記ポイントを明らかにするために、過去にさかのぼって操作や条件を思い出したり整理したり・・・考えること多いですよね。 この書籍の分析のコツや障害再現方法を参考にすれば、テスト経験が浅くても良い障害レポートが書けそうだね。 焦ってると頭の中だけで考えてながら進める事が多いですけど、色々やり過ぎて迷子にならないよう、上記ポイントを押さえつつメモを取りながら進めていくと良いかなって思いました。 オーゥケイ！そんな我々が報告した障害レポートがどこへ行こうとしているか、くまねこさんは知りたくないか～い？ Yeah～！ \ /（訳：突然エンジンがかかった？？？とりあえず乗っておく～！） このまま第2部、第6章も読んでいくぞー！カモォン！ Yeah～！ \ /（訳：ぎゃー！） 第6章 障害管理システム を読んで 6章は障害管理システムについて。私もくまねこさんも、障害管理システムとして独立して管理しているプロジェクトや、Redmineなどを使ってタスクと一緒に管理するプロジェクトを担当したことがあると思うけど、ここでは前者の意味合いで書かれているかな。 現代ではアジャイル開発のように短いスパンで設計～テスト～リリースするプロジェクトも多いですし、本書は30年前のものの書籍だからウォーターフォール開発前提の重厚な内容だとすると、導入が難しいところもあるかもしれませんね。 ただ本章のねらいでも「障害レポートを報告後どうするかを述べる。」と記載されていて、「障害を管理する」という点では共通して学べることもあると思うから、読み進めていこう。 まず、「障害管理」というところではテスト対象で報告された障害の可視化（重大度の大きな障害が何件あるか、修正された件数が何件あるか等）ができる点は当然良い点として挙げられると思います。 製品の品質状況やプロジェクトの状況を可視化することができるよね。 ただ可視化したことで、人や管理の問題（誰がどれぐらい件数を出しているのか、起こりえる問題など）についても言及があって、改めて障害管理システムの与える影響について考えさせられました。 そうだね。正しい運用をしないと、プラスの影響だけでなくマイナスの影響も出てしまうんだね。 やはり、テスト担当としてプロジェクトに参画すると、自分の実績って「どれぐらいのペースでテストを消化しているか？何件の障害を検出して報告できたか？」というのが大きいと思います。 報告した障害レポートの数を競ったり、人の障害レポートの数をみて「あ、自分の報告少ない！」って焦ったりね そうそうそれです！でも、障害管理システムで集計された数字が他のテストメンバーや開発メンバーに与えるマイナスな影響についても言及されていて、プロジェクトを運営する側は正しく障害管理システムを運用しなければならないとわかり、とても参考になりました。 そうだね。マネジメントする立場からすると、ある程度数字で判断しなければいけない場面ってあると思うけど、障害管理システムのいちばんの目的は下記にもあるように「障害の発生/修正状況を管理する」ということだから、そのことを意識して使っていくよう注意が必要だね。 障害管理システムは、修正すべきバグを修正するためにある。この目的に直接関係ない事は、二の次である。 基本から学ぶソフトウェアテスト はい。また、テスト初心者であっても本章を読むことで、プログラマやプロジェクトマネージャー等さまざまな役割のメンバーが、それぞれの視点で障害管理システムを利用する際に考えなくてはならないことが分かると思います。 障害管理システムが備えておくべき要件と各役割の全体像を理解するには良い記載かも知れないね。次に、障害管理システムで出力できるレポート関連について記載があるけど、どうかな？ 検出した障害の一覧というところで、基本的な項目や出力できるレポートの種類は現在とあまり大きな差異はないように思います。ちょっと結びつけるには強引かもしれませんが、 以前の記事 で話した「目的に対する最終的な成果」についての報告で、出力したレポートを使ってテスト担当として障害傾向や品質状況についての考えをコメントできるようになると、より説得力のある報告ができると思いました。 そうだね。ここで学んだことを活かして、障害管理システムを使いこなしていきたいね！ ゆるっと♪どうやってる？探索的テストの世界！ まとめ 今回は障害関連ということで見てきたわけだけど、どうだったかな？ 第5章の障害報告については大事なポイントが整理されていて、自身がやっていたこととの比較から良い学び直しになりました。障害報告フォーマットについては、今までの経験からすると新しい発見はあまりありませんでしたが、基本は陳腐化しないものであるということが実感できてよかったです。 学び直してるねぇ(笑) （茶化さないでくださいよー）また、現場によって障害報告フォーマットの項目が異なることもあるので、そういった場合には「改善提案」という形で今回学び直したフォーマット項目に留意しつつ、不足部分があれば提案して、導入するメリットまで説明できるようにしていきたいです。 良いね！紙で障害レポートを書くことを前提にしていたり、時代を感じる記載はあったけど、全体的に現在でも大事にすべきポイントが多々記載されていたね。私もテスト結果のレポートなどを提出する時には、第6章に書かれている「障害管理システム」の運用の考え方やフォーマットを参考にして、今後の活動に役立てていきたいと思う！ よーし、第2部もこの調子で学び続けていかなければ…バーイ！ ﾉｼ 三 Yeeeeeeeeeeaaaaaaaaaah！ \ / （アンコール！アンコール！） 次回予告 三 ﾉｼ（戻ってきた）さて、今回はここまでにしようか。 お互いJSTQBのALの学習は進んでないけど(笑)、次回はどんな感じかな？ 次回のまーくー＆くまねこは、 JSTQB ALTM試験、勉強する気ある？どうでしょ！（仮） JSTQB ALTM試験、受けるかも？受けないかも？どっちでしょ！（仮） の２本でーす。 最後まで読んで頂き、ありがとうございました！ よろしければ、過去のゆるっと♪シリーズもお楽しみください！ 次回もまた見てねー ﾉｼ 三 ﾉｼ 三 ゆるっと♪シリーズ 第1話 ゆるっと♪ファームウェアテストよもやま話 第2話 ゆるっと♪学び直し！アジャイルソフトウェア開発技術者検定試験 第3話 ゆるっと♪どうやってる？探索的テストの世界！ 第4話 ゆるっと♪学び直し！ [書籍]基本から学ぶソフトウェアテスト！ 第5話 ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！②～あきらめてしまわないでね 難しさ感じても～ The post ゆるっと♪学び直し！[書籍] 基本から学ぶソフトウェアテスト！➂～きっとそこに信じていた、バグ管理の姿があるはずさ♪～ first appeared on Sqripts .

新卒でフロントエンド開発者をしています、イソダです。 先輩が作成した社内情報お問合せSlackBot をLangChainというツールを使用して、ベクターデータベースとChatGPTに接続して、より賢く、より人間らしい回答ができるようにシステム改修しました。今回はそのシステムについて簡単に紹介したいと思います。 （今回作成したシステムはまだ運用をしておらず、今後の運用を調整中です。） Cloud FunctionsとSlack APIに踊らされたSlack Bot作成 LangChainとは Introduction | Langchain LangChainはChatGPTなどの言語モデルを活用したアプリケーションを開発するためのフレームワークです。利用方法としては、ChatBot、データベースやドキュメントなどの知識を元に質問に答えてくれるお問合せAI、ドキュメントの要約などいろいろあります。 今回はLangChainを使用して、社内制度へのお問合せSlackBotを作成していきます。 システム構成 作成したシステムの構成は次のようになっています。 社内情報お問合せAIシステムの構成図 まずSlackからの質問文をLangChainで受け取ります。 これをLangChainからベクターデータベースにクエリとして送信します。 すると質問文と関連があるドキュメントを抽出して返ってきます。 次にLangChainからChatGPTにドキュメントの内容を参考にして質問に答えるように指示を出します。 そしてChatGPTから回答が返ってきます。 返ってきた回答をそのままSlackに返します。 LangChainはGoogle Cloud Functions、ベクターデータベースはGoogle Cloud Storage上に構築しています。 以降は、ベクターデータベースの作り方とLangChain、ベクターデータベース、ChatGPTとのやり取りについて説明していきます。 ベクターデータベースの構築 ベクターDBは、様々な形式のデータをベクトルとして保存し、クエリに対して類似度検索をして該当したデータを返してくれるデータベースです。 今回は社内向けのWebサイトに掲載されている情報を取り入れてベクターDBを作成しました。Webサイトをクローリングで取得してtxtファイルとして保存したものを利用しています。本記事ではクローリングについては説明しません。 以下がPythonで実装したベクターDB作成のコードです。 from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import FAISS from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import CharacterTextSplitter import dotenv # OPENAI_API_KEYの読み込み # (このコードがあるディレクトに.envファイルを作り、 # 中身に OPENAI_API_KEY=オープンAIのキー を書いておく) dotenv.load_dotenv() # データの読み込み loader = DirectoryLoader("Webサイトのtxtデータがあるディレクトリ", glob="**/*.txt") documents = loader.load() # テキストデータを小さく分割 all_splits = CharacterTextSplitter().split_documents(documents) # ベクターDBの作成 db = FAISS.from_documents(all_splits, OpenAIEmbeddings()) db.save_local("./faiss_index") まずローカルに保存してあるWebサイトのtxtデータを DirectoryLoader ＆ load() で読み込みます。引数の glob で拡張子がtxtであるファイルのみ読み込むよう指定しています。 次にベクターDBに格納するテキストデータをある程度の長さで分割していきます。この工程を行う理由としては、ベクターDBにクエリを出したときに帰ってくるドキュメントを短く、かつクエリと深く関連しているようにするためです。Webサイトなどのドキュメントは、１ページに複数個のトピックが書かれていることが多いです。これを短く分割することで、１つのドキュメントに含まれているトピックを絞り、クエリとは関連のないトピックが含まれることを防ぎます。 分割を行うインスタンスを CharacterTextSplitter() で呼び出し、分割を行う関数 split_documents() に先ほど読み込んできたWebサイトのデータ documents を渡しています。 最後にベクターDBを作成します。今回はFAISSというベクターDBを使用しています。またテキストデータをベクトルに変換する埋め込みモデルはOpenAIのものを利用してます。 FAISS.from_documents(ドキュメント, 埋め込みモデル) でベクターDBが生成されます。できたベクターDBは、 db.save_local("./faiss_index") でローカル上のfaiss_indexディレクトリに保存します。 faiss_index ディレクトリ内に index.faiss と index.pkl という２つのファイルが生成されます。 問合せシステムの構築 以下のコードがPythonで実装した問合せシステムです。モジュールはGoogle CloudとLangChainのものをインポートしています。以降の節で詳しく説明していきます。 import os import functions_framework from google.cloud import storage from langchain_community.vectorstores import FAISS from langchain_openai import ChatOpenAI from langchain_openai import OpenAIEmbeddings from langchain_core.messages import HumanMessage @functions_framework.http def ai_question_vectordb_api(request): try: query_dict = dict() question = request.get_data(as_text=True) # GCSからベクターDBをダウンロード storage_client = storage.Client() bucket = storage_client.bucket("test_vecdb_for_langchain") blob = bucket.blob("index.faiss") blob.download_to_filename("/tmp/index.faiss") blob = bucket.blob("index.pkl") blob.download_to_filename("/tmp/index.pkl") # ベクターDBにクエリ vectorstore = FAISS.load_local("/tmp/", embeddings=OpenAIEmbeddings()) docs = vectorstore.similarity_search(question, k=3) input_documents = str() for d in docs: input_documents += "input_documents: {}\n".format(d.page_content.replace('\n', '')) # 問合せに対する回答を生成 llm = ChatOpenAI(model_name="gpt-3.5-turbo-16k", temperature=0, request_timeout=60) query = input_documents query += "question: {} ".format(question).replace('\n', ' ') query += "questionに答えてください。" answer = llm([HumanMessage(content=query)]) return answer.content except Exception as e: print(e) return "ごめんなさい。。何か問題が起きたようです。。" 質問受付 @functions_framework.http def ai_question_vectordb_api(request): question = request.get_data(as_text=True) 一行目の @functions_framework.http はGoogle Cloud Functionsで実装するときのおまじないみたいなものです。Slackから送られてきた質問を request で受け取ります。 request はただの文字列の想定なので、テキストとして読み込んで question 変数に代入してます。 ベクターDBへのクエリ # GCSからベクターDBをダウンロード storage_client = storage.Client() bucket = storage_client.bucket("test_vecdb_for_langchain") blob = bucket.blob("index.faiss") blob.download_to_filename("/tmp/index.faiss") blob = bucket.blob("index.pkl") blob.download_to_filename("/tmp/index.pkl") # ベクターDBにクエリ vectorstore = FAISS.load_local("/tmp/", embeddings=OpenAIEmbeddings()) docs = vectorstore.similarity_search(question, k=3) input_documents = str() for d in docs: input_documents += "input_documents: {}\n".format(d.page_content.replace('\n', '')) まずベクターDBであるFAISSをGoogle Cloud Storageからダウンロードして、ローカル上に保存します。今回はGCFs上の一時ファイル置き場として使える /tmp ディレクトリ上に保存しています。ダウンロードするファイルは２つで、拡張子が .faiss であるものと .pkl であるものです。 次にローカル上に保存したベクターDBをメモリに読み込みます。 読み込みは FAISS.load_local(”FAISSがあるディレクトリ”, embeddings=OpenAIEmbeddings()) で行います。ここで埋め込みモデルとして、ベクターDB作成時と同じモデルを指定します。読み込んだベクターDBに対してのクエリは vectorstore.similarity_search(質問文) で行います。このクエリの返答としては、質問文と類似度が高い文書が複数個返ってきます。今回は k=3 で３つの文書を返すように指定しています。そして帰ってきた文書を input_documents に整形して格納します。 ChatGPTへのクエリ # 問合せに対する回答を生成 llm = ChatOpenAI(model_name="gpt-3.5-turbo-16k", temperature=0, request_timeout=60) query += input_documents query += "question: {} ".format(question).replace('\n', ' ') query += "questionに答えてください。" answer = llm([HumanMessage(content=query)]) return answer.content まずChatOpenAIをインスタンス化して変数 llm に代入しています。このインスタンスは、OpenAIのgpt-3.5-turbo-16kモデルを使用してます。引数の temperature は0~1の値を取り、1に近いほどChatGPTが生成する回答文がランダムになります。今回はテストがしやすいように、値を0にして、同じ質問文に対しては同じ回答を返すように設定してます。あとは変数 query にChatGPTに送りたい文章を入れていきます。ここでは、ベクターDBが返した文章と、Slackから送られた質問文を整形して入れています。 そして、 answer = llm([HumanMessage(content=query)]) で実際にChatGPTと会話を行います。ChatGPTの回答はanswer.contentに入っているので、これをSlackにそのまま返しています。 動作例 以下の画像が実際にSlack経由で実装した問合せシステムに質問した結果になります。試しに弊社の資格取得支援制度について質問したところ、社内情報に特化して、かつ自然な感じで回答してくれます。また「制度の申請方法を教えて」など質問する内容を詳細に絞ってあげると、それに対応して制度の細かい部分まで答えてくれます。 問合せシステムに社内制度について質問した結果 社内制度の詳細について質問した結果 まとめ LangChainを使うことで、ベクターDB+ChatGPTと連携してAIアプリが簡単に作成できました。今回は使用しなかったのですが、LangChainのChainという機能を使うことで、さらに簡潔に、かつデバッグがしやすくなるらしいです。以降はそのあたりも勉強しようかと思います。 The post LangChain+ChatGPT+VectorDBで問合せbotを賢くした話 first appeared on Sqripts .

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

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

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

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

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

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

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

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

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