本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第9回となる今回のテーマは「プロジェクトの品質マネジメント」です。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 品質をマネジメントする、とは プロジェクトマネジメントにおける品質のマネジメントとは、ステークホルダーの目的に合致させるためにプロジェクトとプロダクトの品質要求事項を計画し、組織の品質方針等を取り入れた形でマネジメントしていく活動です。マネジメントの対象は「プロジェクトの品質」と「成果物の品質」の主に2つです。 品質のマネジメントと聞くと、不具合やバグが出ないようにするといったイメージになるかも知れませんが、たしかにそれは品質の1つではありますが全てではありません。成果物だけではなく、プロジェクト、つまり進め方自体の品質管理にフォーカスしていることが重要です。例えば、プロジェクトのスケジュールが計画に対して維持されているか、予算内で実行できているか、これらのスケジュールマネジメントやコストマネジメントにかかる部分もプロジェクトの品質マネジメントにおける品質対象です。 品質マネジメントは以下3つのステップ（プロセス）で行います。 品質のマネジメントを計画する ステークホルダーの真のニーズを確認して「品質要求事項」を特定することから計画ははじまります。またCOQ（Cost Of Quality）、つまり品質を担保するために必要なコストを考慮し獲得しておくことが大切です。 1) 病気もプロジェクトも予防が大切 品質にかかるコストは以下の4種類に分類されます。 大切なのは適合コストと不適合コストのバランスです。適切に適合コストを使わないと不適合コストの発生確率を高めることになりますが、適合コストばかりかけすぎると利益を圧迫してしまうことになります。コスト効果としては一般的に適合コスト＞不適合コストをかけた方がよいです。 2) 「よい品質」にはばらつきがある 一言で「よい品質」「品質が保たれている」といっても、多くの場合同じ品質が指されていることはありません。Aさんは「 XX まで担保されればよい品質だといえる」と思っていても、Bさんは「それでは不十分で XXX でなければ担保されているとは到底言えない」といった感じです。また顧客とのやりとりで「高いクオリティで」という曖昧な要求を受け取る経験も少なくないはずです。 近代的品質マネジメントの提唱者は以下のように言っています。 「品質とは要求条件の一致である」 「無欠陥（Zero Defect）、検査より予防」 フィリップ B.クロスビー 「品質は誰かにとっての価値である」 G.M.ワインバーグ つまり、「品質がよい状態」とは、ステークホルダーの要求を満たし、ステークホルダーにとって価値あるものを提供することと言えますが、見ての通り「よい品質」という定義の曖昧さや捉え方によるばらつきがある（起こる）ことも同じように示していますね。 だからこそ、プロジェクトが考え目指す品質や組織で定義されている品質方針を踏まえて「どうすれば実現できるか」を品質マネジメント計画書などのドキュメントで明らかにし、みんなで品質視座をあわせて目指していけるように準備しましょう。 ＜品質マネジメント計画書に記載される基本的事項＞ プロジェクトの品質基準 品質に関する役割と責任 品質レビュー対象やレビュープロセス 品質マネジメント活動や方法 品質ツール 不適合や是正措置プロセスなどの手続き規定 3) 品質を測定する尺度を決めておく 品質尺度とは、品質の適合を「どのように検証するか」を具体的に規定したものです。クオリティメトリクス（QM）と呼ばれることもあります。例えば、時間通りに完了したタスクの割合、突き当たりの合計ダウンタイム、コード行あたりのエラー、顧客満足度、テスト網羅率の基準としてテスト計画がカバーする要求事項の割合などがあります。品質そのものへの考え方やばらつきがある、とお伝えしたように、品質を何かしら測定する尺度を持っておくことで「こんなはずじゃなかった、これは違う」というトラブルや認識齟齬を予防しましょう。 4) 品質指標 上記の品質尺度に対して、品質指標は「品質を満たしているということはどういう状態か」を定義しておきます。品質指標が顧客の要求を満たした状態か、できる限り具体的な状態を定義しておくことが品質尺度と同様に大切です。 品質のマネジメント 品質のマネジメントでは、組織の品質方針をプロジェクトに組み入れて、品質マネジメント計画を実行します。品質のマネジメントは場合によって「品質保証」とも呼ばれます。プロジェクトマネジメントの観点では、品質保証の焦点はプロジェクトの「プロセス」にあるとともに「検査より予防」の考え方と密接に関連しています。その為、計画した品質を担保する仕掛けや仕組み（規約・ガイド）が正しく機能しているかを＜確認＞することがが重要です。 1) どうやって品質確認する？QC７つ道具を押さえておこう！ 品質標準と運用基準を満たすために、プロジェクトでは常に品質改善活動を行っていかなければなりません。継続した活動の中で、無駄なくプロセスを実行できるようパフォーマンスの測定結果を確認し、問題点を改善していきましょう。改善点を洗い出すためには、まず品質コントロール測定結果を分析します。分析には「QC7つ道具（7つの手法）」や「品質監査」を用いて問題点や改善につながるヒントを抽出し、必要なプロセスの改善点をまとめて必要に応じ変更（変更要求）を行いましょう。 また「QC7つ道具」を使った数値分析は主に製造現場で活用されてきましたが、「新QC7つ道具（N7）」は実測や数値化が難しい場合や言語データも併せて分析することで設計や営業など幅広い改善活動に活用される手法です。QC7つ道具と新QC7つ道具がどのようなもので、どのように活用することができるのかを簡単にでもいいので把握し、ぜひ品質マネジメントに取り入れてみてください。 ＜QC7つ道具：データ整理や関係性分析手法＞ パレート図 特性要因図（フィッシュボーン図・フィッシュボーン分析） グラフ ヒストグラム 散布図 管理図 チェックシート ・QC7つ道具は「Q7」と略称されます。 ・QC7つ道具及び新QC7つ道具の作成手順は「JIS Q 9024:2003 マネジメントシステムのパフォーマンス改善－継続的改善の手順及び技法の指針」でJIS化。 ・新QC7つ道具は「New seven tools for QC」あるいは「New 7 QC Tools」と呼ばれ、「N7」と略称されることもあります。 3) プロジェクトの品質保証活動に組織の品質保証活動を活かす 組織内に品質保証部門などを有する場合、プロジェクト活動でそれらの部門との連携やプロジェクトチームに組み入れるなどして、故障解析や実験計画、品質改善などのマネジメント活動を実行しましょう。豊富な品質ツールと技法を持った専門部門はプロジェクトにとって優れた資源です。 4) 製品は80％が設計で決まる、デザイン・フォー・エックス（DfX）という考え方 1990年代に米国で提唱、実践されたデザイン・フォー・エックス（DfX：Design for X）は、設計（デザイン）における個々の側面を最適化するためにプロダクト設計に取り入れる技術的なガイドラインのことを言います。DfXのXは信頼性、展開、組み立て、製造、コスト、サービス、使い勝手、安全性、および品質といったプロダクトの開発におけるさまざまな側面を指します。こうして多面的な設計思想を持つことで、コスト削減や品質改善、パフォーマンス向上や顧客満足の達成を目指しましょう。 品質のコントロール 成果物（アウトプット）が品質要求事項を満たしているかを検査し、その結果適合・不適合とを判定します。適合とされた上で、ステークホルダに受け入れられてはじめて「受け入れ済み成果物」と呼ぶことができます。 1) 品質マネジメント７原則 「品質マネジメント7原則」とは、品質マネジメントシステムの規格のISO9001で、適合性と有効性を維持した品質マネジメントシステムを構築する為の大枠を7つの原則として示したものです。 原則1：顧客重視 原則2：リーダーシップ 原則3：人々の積極的参加 原則4：プロセスアプローチ 原則5：改善 原則6：客観的事実に基づく意思決定 原則7：関係性管理 ISO9000:2015 品質マネジメントシステム－基本及び用語 さいごに プロジェクトマネジメントにおける「品質のマネジメント」はテストやプロダクト、サービスだけでなく、それらを生み出すまでのプロセスが重要になっていきます。開発中に多くの品質問題がでる、それらの対応などで計画していた開発期間を大幅に超過する、プロダクトは完成したけれども不具合が多発してしまう。もしそんなことが起こっていれば、これは品質のマネジメント自体に課題がないか目を向けてみてください。 次回のテーマは「リスクマネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 The post 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 first appeared on Sqripts .

こんにちは。QAエンジニアをしているポポラスです。私はコールセンター等でサービス受付をするシステムの受入テストを担当しております。 私の現場では、ユーザーの実際のオペレーションの情報が少なく、テストベースは要件定義書のみでテスト設計を行っております。そのような状況において、ユーザー観点を出し、実際のオペレーションに沿ったシナリオを設計するために私が工夫した3つのことを、経験事例を交えてご紹介させていただければと思います。参考になりましたら幸いです。 前提 私が経験していた現場は、システムの操作方法に関する情報が乏しく、また実際の利用者からのヒアリングが出来ない状態でした。そのような中で第三者検証として受入テストを担当させて頂いた際の経験です。 工夫したこと 以下の内容は、実際に私が現場で工夫したことになります。もし実際のオペレーションの情報が無く、設計にお困りの場合、観点出しのお役に立てることがあるかもしれません。ぜひご覧ください。 その１：機能の目的を考える 機能の目的を考えることで、実際のオペレーションに近いシナリオを導き出せることがあります。 以下は実際に私がテスト設計を担当した機能での経験事例になります。 <経験事例> ■機能 サービス対象端末の特殊在庫の表示 ■機能の目的を考えなかった場合のシナリオ まず、機能の目的を考えなかった場合のシナリオは以下になります。 前提条件： なし シナリオの流れ： ①端末Aの画面に遷移し、特殊在庫を表示する ②特殊在庫を選択し、オーダーを完了させる ■機能の目的を考えた場合のシナリオ 特殊在庫機能の目的は、通常在庫が切れた場合かつサービス利用者がどうしてもその端末を希望する場合に、予備の在庫を臨時的にサービス利用者に提示すること、と考えられます。 上記の目的から、以下のシナリオが導き出せます。 前提条件： 端末Aの通常在庫なし シナリオの流れ： ①端末Aの画面に遷移し、通常在庫切れ表示となることを確認 ②特殊在庫を表示する ③特殊在庫を選択し、オーダーを完了させる 機能の目的を考えたことで、「前提条件」と「シナリオの流れ①」がより実際のオペレーションに近い条件として導き出すことができました。 その２：3w1h 機能の目的を考えることで実際のオペレーションに近いシナリオを導き出せましたが、この「3w1h」では、そのシナリオに対して観点のバリエーションを持たせることができます。 今回ご紹介する「3w1h」は以下の要素となります。 Who（だれが） When（いつ） Where（どこで） How（どのように） 実際に私の現場で実践した3w1hは以下になります。 <経験事例> ■機能 サービス対象端末の特殊在庫の表示 ■「Who（だれが）」の考察 これは「システムを使用するユーザー」という理解で考察します。実際にサービス受付システムを使用するユーザーは以下3つのタイプが存在しますので、観点のバリエーションに加えることができます。 コールセンターのオペレーター 店舗の担当者 サービス利用者 ■「When（いつ）」の考察 これは機能が使われる「状況」という理解で考察します。状況として以下4つのパターンが考えられます。 通常在庫が切れた時 通常在庫が補充された時 特殊在庫が切れた時 特殊在庫が補充された時 ■「Where（どこで）」の考察 これは場所ではなく、私の現場の場合は機能を使用するプラットフォームという理解で考察します。プラットフォームは以下3つのパターンが考えられます。 コールセンターのオペレーターが使う受付システム 店舗の担当者が使う受付システム サービス利用者が直接Webサイトからオーダーする受付システム ■「How（どのように）」の考察 これは「どのように機能を実行するか」という理解で考察します。以下4つのパターンが考えられます。 デスクトップPCから特殊在庫を確認する ノートPCから特殊在庫を確認する スマートフォンから特殊在庫を確認する タブレットから特殊在庫を確認する その３：UMLを使ったアプローチ 工夫その１と２は、ユースケース図やアクティビティ図といったUMLを、テスト視点で活用することで導き出すアプローチもあります。UMLを使うことで、機能の目的や3w1hの観点を整理することができ、整理した観点を俯瞰的に見ることで、観点の抜け漏れや新しい観点の気付きにも繋がります。 ユースケース図 アクティビティ図 その４：顧客から情報を引き出す 顧客から市場での実際のオペレーションの情報を引き出すことで、シナリオの設計に活用できます。これは最もシンプルな方法ですが、最も実際のオペレーションに近い情報となりえます。 その５：観点のフォーマット化 工夫その１～４で導き出した観点をフォーマット化することで、他要件の観点出しにも流用が可能となります。更にフォーマットをチーム内で共有し、ユーザー観点を蓄積していければ、フォーマットのブラッシュアップを行っていけます。 結果 上記の工夫を行うことで、受入テストのユーザー観点不足を緩和することができ、より実際のオペレーションに近いシナリオを充実させた受入テストを行うことができます。 まとめ 実際のオペレーションの情報がほとんど無い現場でも、機能の目的や3w1hを考え、UMLを活用することで、ユーザー観点を導き出していけます。更に、導き出した観点をフォーマット化してチーム内で資産化することで、今後の他要件への流用やユーザー観点のブラッシュアップなどの付加価値を生むことができると思います。 本記事の内容は、受入テストのテスト設計としては当たり前の内容かもしれませんが、私の経験事例が皆様の参考になれば幸いです。 最後まで読んでいただき、ありがとうございました。 The post ユーザー観点を追加したい！そんな時に。受入テストにおけるユーザー観点の考え方 first appeared on Sqripts .

第1回目の記事【 パスワードの基礎と主な管理手法について 】で、パスワード管理手法のうち、業務効率化の観点及び安全性向上の観点からパスワードマネージャーによる管理が有効な手段であることをご紹介しましたが、今回は具体的な選定のポイントについてご紹介をしていきたいと思います。 【第1回】パスワードの基礎と主な管理手法について パスワードマネージャーの選定ポイント 無償ツールと有償ツール パスワードマネージャーは主に無償・有償の観点でツールを大別することができます。 無償ツール：主にブラウザベンダーがブラウザに標準搭載しているパスワードマネージャー機能のこと 有償ツール：専門のサイバーセキュリティベンダーから提供されているもの ※無償ツールの中には有償ツールを提供するベンダーが提供する無償版も存在しますが、今回はスコープ外とします。 無償ツールの特徴（メリット、デメリット） 以下に、無償ツールの特徴をご紹介します。 [代表的な提供ベンダー] Apple（Safari）、Google（Chrome）、Mozilla（Firefox）、Microsoft（Edge,IE） [メリット] ランニングコストがかからない ： 文字通りですが、無償であることが最大の魅力です。 利用・導入の容易さ ： ブラウザの機能となるため、導入作業無しに即時利用が可能です。 [デメリット] 安全面の不安 ： ブラウザはパスワード管理をするための物ではないため、安全面よりも利便性を追求しています。その上で、追加的に付与された機能であるブラウザパスワードマネージャーには安全面で以下の危険があることを認識しておく必要があります。 パスワードの保存/利用と暗号化 一部のブラウザでは一貫した暗号化がなされない（若しくは、なされていなかった）ことが専門家により指摘されております。具体的には、本来、機微情報であるパスワードを暗号化して保管し、復号して利用する場合、そのパスワードを復号できる人は唯一、利用者本人であり、利用者本人がパスワードを利用しないときは完全に暗号化されている必要があります。（＝ゼロナレッジアーキテクチャ ※1 ） しかし、一部のブラウザにおいて、部分的に暗号化がなされておらず平文で保管される瞬間や場所がある（若しくは、あった）ことが指摘されております。 アクセス制御 皆様は普段どれくらいの頻度でブラウザにログインを行っているでしょうか。多くの方は、ほぼ常時ブラウザにログインした状態で作業をし、頻繁にブラウザからログアウト→ログインをするというのは稀なのではないでしょうか。これ自体が悪いわけではありませんが、パスワード管理の観点では危険と隣り合わせの行為と言えます。 ブラウザでパスワードを保管している場合、ブラウザにログインしている間、パスワードは平文で確認することができる状態となっているため、上記のようなブラウザの使い方をされている方は、ほぼ常時パスワードが暗号化されていない状態に晒されていることになります。この状態で端末を紛失したり、他人が端末を操作できてしまえば保管されているパスワードが全て漏洩する危険があると言えます。 マルチデバイス対応とアタックサーフェイス ブラウザでパスワードを保管する場合、その情報は他のブラウザとは共有されません。つまり、複数のブラウザを利用する場合、それぞれのブラウザでパスワードを保管する必要があります。利用方法にもよりますが、一般的に複数回パスワード生成や保管の作業をする必要があるという利便性の低さと、機微情報であるパスワードを多くの箇所に置くことにより、アタックサーフェイス（＝サイバー攻撃を受ける可能性があるポイント）が増えるという安全面での懸念があると言えます。 有償ツールの特徴（メリット、デメリット） 以下に、有償ツールの特徴をご紹介します。 [代表的な提供ベンダー] Dashlane、Keeper Security、LastPass、1Password [メリット] 高い安全性 ： 有償ツールはパスワード管理専用ツールであり、安全面を最重視した設計となっているため、無償ツールがかかえる「安全面の不安」を以下のように解消することができます。 パスワードの保存/利用と暗号化 有償ツールの中でも採用している暗号化アルゴリズム、暗号化の単位は異なりますが、基本的に ゼロナレッジアーキテクチャ ※1 に基づいた暗号化メカニズムが採用されており、パスワードが平文で晒されるようなことがない設計となっています。 アクセス制御 有償ツールのほとんどがログインタイマー等の設定がデフォルトで有効化されており、パスワード利用後は自動的にログアウトする設計となっています。 利便性が下がるように思われるかもしれませんが、有償ツールのログインに指紋認証や顔認証を用いることで、利便性が大幅に下がることを防ぐこと可能です。 痒い所に手が届く ： 一部後述する「パスワード利用状況の可視化」、「適切なパスワード共有管理」等のパスワード管理専用ツールとしての機能を利用することができ、包括的なパスワード管理が可能です。 [デメリット] ランニングコストがかかる： 当たり前ですがコスト発生はデメリットであり、メリットとの比較が必要になります。 ※1 ゼロナレッジアーキテクチャ（ゼロ知識アーキテクチャ） ゼロ知識アーキテクチャとは、顧客データの平文（暗号化されていないデータ）をベンダーのクラウドに送信することなく、ユーザーのデバイス上でのみ暗号化と復号を行う仕組みです。 アプリケーションが平文を保管することはありませんし、ベンダーのクラウドが平文でデータを受信することもありません。 データが他のデバイスに同期される場合には、他のデバイスで復号（デコード／暗号化データの解読）されるまで、データは暗号化されたままとなります。 無償ツールと有償ツール、選定のポイントは？ GoogleChromeのパスワードマネージャー では、無償ツールと有償ツール、どちらのパスワードマネージャーを利用すべきなのか。 ここからは、選定時のポイントについて解説をしていきます。 無償ツール　→　有償ツールの順序で考える 最初にお勧めしたい大切な考え方は「無償ツールで運用できないか？」からスタートすることです。この考え方でスタートし、どうしても有償ツールが必要な場合には有償ツールを検討する、という順序が重要となります。 その上で、無償・有償の判断が分かれるポイントして以下の要素が参考になります。 個人利用か法人利用か？ この観点でいうと、個人利用＝「無償ツール」、法人利用＝「有償ツール」と考えるのが一般的です。 個人利用の場合、パスワードの管理責任は各個人にありますが、法人利用の場合、その管理責任は法人に帰属する点がポイントです。一般的に有償ツールには、組織全体のパスワード管理状況を可視化し、管理者は各従業員の「 パスワード使い回しの有無 」や「 弱いパスワードの利用 」をチェックする仕組みが搭載されています。しかし、無償ツールにはそのような仕組みは存在しません。（もちろん、スプレッドシートやメモにも存在しません） そのため、法人利用に無償ツールを選定してしまうと、適切なパスワード管理が組織的になされているか分からず、サイバー攻撃後のインシデント調査ではじめて管理体制の不備を指摘されるという結末になりかねません。こういったことから、基本的には法人利用＝ 有償ツールが適している という結論になります。 ※但し、小規模な組織等で、何らかの手段で適切なパスワード管理を組織として担保できる場合には、法人利用でも無償ツールは有効な手段となり得ます。 例：セキュリティ知識のある数名で設立したベンチャー企業など。 共有アカウント（＝ID/PW）はあるか？ そもそも、「パスワード共有」自体、行わないことがベストなのは言うまでもありませんが、業務上、やむを得ないケースも存在致します。 よくあるのが、SNSアカウントの運用を複数人で行うケースや、外部から付与・貸与されているアカウントを複数人で行うケースです。 このようなケースでは、必然的に1つのアカウントを複数人で共有しながら運用していくことになるため、ID・パスワードの管理を安全かつ効率的に行うことが業務上でとても重要となります。 そして、ほとんどの有償ツールにはこのような課題を解決するためのパスワード共有機能が搭載されています。詳細な機能説明は各ツールごとに異なるため省きますが、この機能を用いることで、メールやスプレッドシートで平文もしくはそれに近い低強度な保護でID・パスワードを共有するのではなく、有償ツール上で、必要な時に、必要な人にだけ（＝Need to KnowやLeast Privilegeの原則に沿った）、高強度の保護と共にID・パスワードを簡単に共有することが可能となります。 まとめ パスワードマネージャーは無償ツールと有償ツールで大別されます。 無償ツールは安全性よりも利便性を重視しており、有償ツールはその逆と言えます。 無償/有償をどちらかにするか考える時は「無償ツールでいけないか？」から考え、ダメなら有償ツールを考えるのがオススメです。 個人利用＝「無償ツール」、法人利用＝「有償ツール」が基本的な考え方となります。 法人利用の場合、従業員の「パスワード使い回しの有無」や「弱いパスワードの利用」をチェックする仕組みが必要となります。 次回はMITREフレームワークに見るパスワード管理について解説します。 シリーズ「組織におけるパスワード管理」記事一覧 【第1回】パスワードの基礎と主な管理手法について The post 【第2回】パスワードマネージャーの選定時のポイント first appeared on Sqripts .

みなさんは、知的生産や知的生活ということばを聞いたことはありますか？ 初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。 ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考えています。もちろん、好き・嫌い、合う・合わないはあるでしょう。 そのため「全員に身につけておいてほしい」ではなく「そういった考え方があると知ってほしい」と、一段階トーンを下げた言い方をしています。 この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 知的生産・知的生活とは テクニックの話をします、とは言ったものの、知的生産・知的生活について事前情報なしに話を進めてもわかりづらくなってしまいます。 まずは知的生産・生活をこの連載においてどのような意味で扱うかや、それがエンジニアにとってどう関係するのかからスタートしましょう。 知的生産界隈における有名な書籍のひとつに、『知的生産の技術』があります。 この本によると、知的生産は 知的生産というのは、頭をはたらかせて、なにかあたらしいことがら――情報――を、ひとにわかるかたちで提出すること 「知的生産の技術」（岩波新書） くらいに考えておけばよい、とされています。 これを元に、私は知的生産というものを、 インプット 処理 アウトプット の3要素で考えています。 つまり、アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする。これが知的生産です。 そして、知的生産を日常生活の中に組み込み、ひとつの楽しみとして行うことが「知的生活」であると考えています。 ちなみにこの『知的生産の技術』は1969年に初版が発行されたもので、知的生産という概念はこれだけ昔から存在していました。 ITエンジニアと知的生活 前述の知的生産の要素に照らすと、多くのITエンジニアが行っているような 技術書を読む 技術的な情報を集める、調べる 勉強する テックブログを書く 勉強会などで発表する 技術書や技術系同人誌を書く なども、ひろく知的生活の一部と言っていいでしょう。 一部、というのは、たとえば技術書について「読みっぱなし」では知的生産とは言えません。そこからアウトプットまで行って初めて知的生産といえます。もちろんこれは感想ブログを書く等に限らず、本で得た知識を普段の仕事に活かすことも立派なアウトプットでしょう。 我々ITエンジニアは知識労働者（ナレッジワーカー）と表現されることがあります。知識や経験を使って価値を生み出すことが求められます。これは、まさに知的生産といえます。 ITエンジニアの周辺では、たびたび「自己研鑽」が話題になります。気合いを入れて毎日勉強するのも良いですが、そうではなく日々の知的生活を楽しんでいたらいつのまにかスキルアップしていた、そういった形もアリだと考えています。皆さんの周りにもそのようなタイプのエンジニアが居るのではないでしょうか。もしくは、あなた自身がそうかもしれません。 楽しみながらスキルアップしたいという方にとって、知的生活をより楽しく実りあるものにするためのテクニックや考え方を学ぶことは、エンジニアとしての成長に直結するのです。 知的生活をよりよくするためのツールや考え方 先に、ITエンジニアにとっての知的生活の要素として インプット 処理 アウトプット の3つが考えられる、と述べました。 それぞれの要素について、よりやりやすくしたり、効果的に行うためのツールや考え方があります。 本連載では次回以降これらのツールや考え方、実際の活用方法などをご紹介します。本記事でも、それぞれ簡単に触れておきましょう。 インプット 知的生活では日常的なインプットが大切です。我々ITエンジニアは日ごろからさまざまな情報が勝手に流れてくる環境にあるため、あえて「大切です」という必要はないかもしれません。 SNSではソフトウェア開発にまつわるプラクティスや言語・フレームワークなどの情報も日々流れてきます。もちろん、読書や日々の業務中の調べ物もインプットにあたります。 「どうやって情報を集めるか」に苦労する方も居るかもしれませんし、一部には「大量に流れてくる情報をどう拾いあげ、自分のものにするか」で困っている方もいるかもしれません。 個人のナレッジを蓄積・管理する概念として「PKM：Personal Knowledge Management」があります。主にデジタルなツールを用いて、インプットした情報を管理しその後の処理→アウトプットにつなげる方法論で、蓄積した複数のメモやノートの類似性やつながりから新たに着想を得たりします。 こうしたデジタルツールを用いた情報蓄積は、ふだんからPCやデジタルデバイスに向かって仕事をしているITエンジニアにとって好相性です。皆さんの中にも、言葉自体は初めて聞いたけれども前からやっていたことに近いな、と感じる方がいらっしゃるでしょう。 処理 前段のインプットにて得た情報を蓄積することで、先のアウトプットに至るためのさまざまな処理を行います。処理といっても、ここでは機械的にできることだけではありません。 会社のテックブログの執筆当番が回ってきて、「何を書こうかな・・・」と過去のメモを見返してうんうんとうなるようなことも、この処理に該当しています。 ここでは主に、蓄積した情報をもとにどう発想するかや、発想を得るための道具について扱います。 ソフトウェアテストを仕事にしている方は、「マインドマップでソフトウェアテスト」という手法を聞いたことがあるかもしれません。この例ではマインドマップはまさに発想を得るための道具ですし、テストのためにマインドマップを使う際の考え方・使い方が発想法に該当します。 アウトプット アウトプットに関しては、ツールというよりも習慣化・仕組み化や、どのような場にアウトプットするかが重要になるでしょう。 現在はSNSやブログサービスなど無料でアウトプットを公開できる場がいくつもあります。また、エンジニアのアウトプットという点では、勉強会で登壇したり同人誌や一般書籍としてまとめることもできます。 ただ、いきなり「アウトプットしましょう」と言われても難しいという方も多いと思います。今後の連載の中では、小さいアウトプットから大きなアウトプットにつなげていく流れについても解説します。 効率だけでなく、楽しく知的生活を送ろう 本記事では知的生産や知的生活について、そしてそれらがエンジニアにとってどう関係するのか、またエンジニアの知的生活の要素についても簡単に触れました。 エンジニアにとっての知的生活は、もちろん成長につながることを目指して行う面もあります。ただ、成長速度や効率ばかりを追い求めてしまうと、苦しくなってしまいます。 この連載では効率もですが、より「楽しく継続できる」ことを大事にしたいと考えています。 仕事のためにとプログラミング言語を習得するよりも、便利ツールや作りたいアプリケーションのために身につけるほうがいい、という考え方と似ています。 知的生活やその要素自体を楽しんでいった先で、気がついたらエンジニアとして成長・スキルアップしていた、という状態を目指していきましょう。 The post 知的生活とはなにか？エンジニアにどう関係するのか first appeared on Sqripts .

こんにちは。クオリティマネージャーのおすぎです。 「段取り八分、仕事二分」という言葉があります。 仕事の事前準備の大切さを表すもので、仕事に取り掛かる前にきちんと段取りを済ましておくことで仕事の8割は完了している、という格言です。 段取りはプロジェクトマネジメントにおいても非常に重要になります。 蛇足ですが「段取り」の語源をネットで調べると 作業の順序や方法を定めたり必要に応じて手配をしたりすることで、歌舞伎の楽屋用語からきているとされています。「段」とは一区切りや一幕のことで、芝居の筋や構成の運びを段取りと言う。  だそうです。 プロジェクトの成功率 一般的に「プロジェクトの成功率は30％」と言われています。 成功の基準は一旦脇に置きますが、例えばJUASが発行している ※1 「 企業IT動向調査報告書 2023 」を見てみると、予定工期を守れたプロジェクトは、100人月未満のプロジェクトの場合で全体の3割程度になっています。 プロジェクトの規模が大きくなればその割合はさらに減る傾向にあるようです。 一昔前のプロ野球なら3割打てれば一流打者と言われたものですが、プロジェクトマネジメントも3割の確率で成功させれば一流の証になるのでしょうか？？？ どうせやるなら3割と言わず10割を目指したいですが、自分の担当するプロジェクトがその3割の成功プロジェクトに仲間入りできるのかどうかは、この「段取り」にかかっていると言っても過言ではありません。 今回はプロジェクトを進める上で「段取り」がもたらすメリットと、私が「段取り八分」を実現するために実際に意識していることをご紹介します。 「段取り」に期待するメリット プロジェクトを段取り良く進めることで様々なメリットがあると思いますが、私は主に２つのメリットがあると考えています。 生産性の向上 業務の効率化 働き方改革が叫ばれる中、生産性を落とさずに就業時間内で作業を完了できるかを求められることが多くなってきました。 働き方改革を実現するためにも生産性の向上や業務の効率化は避けて通れない道だと思いますが、段取りを上手く進めることは、その実現に大きく寄与します。 生産性の向上 何をするのかはっきりしない状態で作業を開始しても、何から手を付けて良いかわからなければ、作業はすぐに停滞してしまいます。 作業のスコープや優先度を明確にすることで、作業を停滞させることなくスムーズに進めることができます。また、スコープがはっきりしていることで作業の手戻りを減らすことにも繋がるため、リソースを無駄なく最大限に活用することができます。 プロジェクトを進める中で発生するであろうリスクを事前に洗い出しておくことで、実際に問題が発生した場合でも速やかに対応することができ、作業の停滞を最小限に留めることができます。 業務の効率化 作業を進めていると様々なことが起こりますが、何かあるたびに手を止めて確認していては、作業も思うように進みません。 大きなプロジェクトになればなるほど対応する人数も増えますが、それぞれが何かあるたびに手を止めていては、結果として膨大な工数を無駄に消費することになります。 作業の手順やフローを明確にしておくことや、プロジェクトの中で使用する定義を明確にしておけば、何か事が起こっても速やかに対応することができるため、作業を効率的に進めることができます。 段取りする上で意識していること 私はクオリティマネージャーとしてテスト工程をマネジメントしており、プロジェクト計画書やテスト計画書を作成しています。 その活動こそが「段取り」に当たりますが、私がプロジェクトの「段取り八分」を目指すために意識している観点がありますのでご紹介します。 ステークホルダーとスコープを整合する プロジェクト計画書やテスト計画書を作成している方は必ず意識していますが、私は特にテストのスコープについてステークホルダーと整合するようにしています。 ソフトウェアテストの７原則に「全数テストは不可能」という原則があります。 その原則通り全てをテストするのではなく、影響範囲やスケジュールなどを考慮してテストのスコープを決めるのですが、「すること」よりも「しないこと」を整合できるように努めています。 何をどのようなテストをするのか決めることは、テストをスムーズに進める上で重要なのは間違いないです。 しかし我々がテストのスコープではないと考えていることを、ステークホルダーがテストのスコープだと考えているケースは少なくありません。 ステークホルダーとの認識齟齬は、追加のテストや作業の手戻りが発生するなど、納期遅れの原因になることがあります。 そのため「テストしないこと」を事前にステークホルダーと整合しておくことが重要だと考えます。 プロジェクトメンバーと手順を共有する プロジェクト計画書やテスト計画書でWBSを作成し、メンバーが何をすべきなのか明確になっていたとしても、その1つ1つを具体的にどう進めれば良いのか決めていなければメンバーの手が止まります。 メンバーの手が止まるだけでなく、プロジェクトマネージャーやプロジェクトリーダーも、その都度メンバーに指示したり、メンバーからの質問に対応しないといけなくなり、思うように進捗が上がらなくなります。 そのためメンバーが作業の手を止めることがないように、WBSで細分化したアクティビティやタスク単位で、作業方針や作業フロー、ルールを定義するようにしています。 その際に注意しているのが、それぞれの目的や意図を合わせて明示しておくことです。 プロジェクトが進むと想定していない様々なことが起こりますが、目的や意図を明確にすることで、メンバー１人１人が応用を利かせた対応がとれるようになります。 プロジェクトマネージャーやプロジェクトリーダーの指示がなくても、メンバーだけで自走してプロジェクトを進めることができるようになっていきます。 腹八分で割り切る プロジェクトは生き物に例えられるように、動き出すと何が起こるかわかりません。 「段取り」が重要なのは間違いありません。 しかし事前に完璧な「段取り」を済ますことは困難ですし、あまりに色々なことを決めすぎても、実際の想定と違う状況になり労力が無駄になることがあります。 そのため「仕事二分」を実現するために「段取り」に拘るものの、その「段取り」も目一杯やるのではなく「腹八分」に抑えるようにしています。 具体的には成果物についてと、目に見える範囲や直前のアクティビティやタスクに対して目一杯段取りを進め、以降のタスクについてはザックリした方針だけ決めておき深追いしません。 それらはプロジェクトが動き出してから段階的に詳細化することで、段取りにかかる労力を分散できるようにしています。 さいごに 昨今はウォーターフォールだけでなくアジャイルの開発プロセスを採用するプロジェクトも多くなっており、状況の変化に対するスピード感が必要になります。 プロジェクトが動き出すと何が起こるかわからないため、想定外の事態が発生したときに、あれもこれも手を出していると、その変化に対応しきれません。 想定外の事態に「仕事二分」の労力の全てを注げることができれば、プロジェクトを成功に導くことができるのではないでしょうか。 私もクオリティマネージャーとして「段取り八分」を徹底し、３割の成功を手にできるようにこれからも邁進したいと思います。 ※1 一般社団法人　日本情報システム・ユーザー協会（JUAS） 企業IT動向調査報告書 2023 https://juas.or.jp/cms/media/2023/04/JUAS_IT2023.pdf The post 段取り八分／仕事二分のマネジメント first appeared on Sqripts .

こんにちは。Sqripts編集部です。 この記事では脆弱性の基本や「脆弱性をなくすことはできないのか」に焦点を当てて解説します。 脆弱性の本質、その存在理由、そしてリスクを最小化するアプローチを解き明かしますので、ぜひセキュリティ対策の参考にしてください。 脆弱性とは？ 用語の定義を理解する 脆弱性とは、システム全体のセキュリティを損なう可能性をもつ「弱点」です。一般的にはソフトウェアのバグ、設計ミスによる欠陥、不適切なセキュリティポリシーや管理体制（による防御の穴）などが含まれます。 総務省の定義によれば、 コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生したサイバーセキュリティ上の欠陥 出典： 総務省『国民のためのサイバーセキュリティサイト』 とされています。 セキュリティ上のリスクを理解する 上記の「弱点」を通じて、攻撃者は不正アクセスを試み、データを盗む、サービスを妨害する、その他の悪意ある攻撃をしかけます。脆弱性に脅威が迫ったときに、システム損害のリスクあるいは、事業継続のリスクなどが生じます。 詳しくは「脆弱性のリスク」の章にて後述します。 なぜ脆弱性が生まれるのかを理解する 攻撃の対象となってしまう脆弱性は、私たちエンジニアが生み出しているという観点を持つことは重要です。脆弱性はシステムを設計する者、システムを利用する者が生み出しており、生み出された脆弱性に脅威が迫ったときに初めてセキュリティリスクが生まれます。 エンジニアから脆弱性が生まれる要因としては、スキル不足、ミスコミュニケーション、要件の急な変更、不十分な品質テストなどさまざまなことが考えられます。人間が関与する限り、完璧なシステムを構築することは現実的には不可能であり、「脆弱性は存在するもの」と認識しておくことが大切です。 利用者から脆弱性が生まれる要因としては、セキュリティアップデートやパッチを適用しないことが挙げられます。アップデートやパッチを適用しない環境下では、既知の脆弱性が存在し続けることになります。 また、パスワードの強度が弱い、パスワードの管理が不適切である（例えば、同じパスワードを複数のアカウントで使用するなど）といった環境も一種の脆弱性と考えられます。 【用語】 脆弱性とセキュリティホールの違いと関係性 脆弱性はシステムの弱点を広く指しますが、セキュリティホールは特定の脆弱性を指します。 セキュリティホールとはつまり、攻撃者がシステムに侵入するための具体的な「窓口」です。 セキュリティホールは脆弱性に内包されており、広義的な弱点を指す「脆弱性」という言葉と、狭義的な弱点を指す「セキュリティホール」という言葉が存在します。 脆弱性のリスク マルウェアへの感染リスク システムの弱点を許容し続けることは、さまざまなリスクを許容するのと同じです。 まず挙げられるのが、マルウェアへの感染リスクです。マルウェアに感染すると、データ漏えいや改ざん・削除といった被害が生じます。 特に近年では、マルウェアの一種であるランサムウェアの被害が世界的に注目されており、データを人質に身代金を要求するといった犯罪行為が後を絶ちません。ランサムウェアによる攻撃も高度化しており、組織化した犯罪集団が「ビジネス」としてランサムウェアを仕掛けてくるケースも目立ちます。 マルウェア感染は、直接的なデータ損失被害だけの話ではありません。顧客の信頼喪失に始まり、金銭賠償、法的責任による事業継続の危機にまで影響を及ぼします。一度評判が損なわれると即座の回復は困難であり、ダメージコントロールには莫大なコストを要します。 ひとたびマルウェアに感染すれば、自分たちが感染源となり、取引先企業への不正アクセスの踏み台になってしまう可能性もあります。あるいは、たとえば某大手動画共有サイトでは、コメント投稿に関するシステムの脆弱性から攻撃を受け、デマコメントが乱立するなど「社会的混乱」を招いた事例もあります。 マルウェアへの感染の要因 マルウェアへの感染の主な要因は、「ソフトウェアのバグ」や「設計ミスによる欠陥」と考えられます。マルウェアやランサムウェアがシステムに感染する際には、システムのバグや設計上の欠陥を突かれる事例が多くなっています。これらの欠陥（脆弱性）を悪用し、不正なアクセスを行ったり、データを盗んだり、システムを遮断したりします。 重要なのは、脆弱性を放置するリスクは派生的に広がっていくことを理解することです。適切にリスク管理と脆弱性対策を実施しないと、放置した分だけ危険度は増していきます。 脆弱性を完全になくすことはできるのか？ 「脆弱性をなくすことはできますか？」 答えはNoです。よく「開発・構築段階で十分なテストをすれば脆弱性はなくなる」と考えてしまうことがありますが、それは誤りです。 技術の進歩、攻撃手法の進化、意図しない操作などとともに新たな脆弱性は常に発見されるため、脆弱性を完全になくすことはできません。 ただし、リスクを管理し、影響を最小限に抑えることはできます。 脆弱性への対策 脆弱性対策の基本：情報収集と適切な管理 ひとことで情報収集といっても、脆弱性の情報は膨大であり、常に新たな脆弱性が発見されるため、すべてを完全に把握することはできません。 IPA（情報処理推進機構）によれば、脆弱性対策情報データベース「JVN iPedia」に登録された累計脆弱性情報は2024年3月時点で206,571件に上り、毎年右肩上がりで件数を伸ばしています。各メーカーや開発元からひとつひとつ脆弱性情報を集めるのは実質的に不可能であり、急速に脆弱性の数が増加する昨今においては、効率的ではありません。 網羅的に情報収集をしつつ、迅速な脆弱性の対策を実現するためには、データベースの活用が有効です。代表的なデータベースとしては以下の3つが挙げられます。 JVN（Japan Vulnerability Notes） 日本国内で使用されているソフトウェアの脆弱性情報を入手するのに適しているデータベースです。 NVD（National Vulnerability Database） 世界全域の脆弱性情報を入手するなら、米国国立標準技術研究所（通称NIST）が運営するNVDを活用するとよいでしょう。（英語表記サイトです） JVN iPedia JVNやNVDなどを一次ソースとして集約するデータベースです。 具体的にどんな情報を得るべきかは、対策に必要な項目から逆算しましょう。脆弱性対策には、具体的な対策手法だけでなく、対策の必要性の有無、対策の優先度を把握しなければなりません。対策の必要性の有無を把握するには、脆弱性が検出されたソフトウェアやバージョン情報を確認します。対策の優先度を判断するには、脆弱性の影響範囲を抑える必要があります。 上記を把握したうえで、定期的なセキュリティチェック、脆弱性スキャニング、ソフトウェアの更新、従業員教育といった具体的な対策に移ります。 脆弱性診断：定期的なセキュリティチェックの重要性 技術の進歩とともに、残念ながらサイバー攻撃も進化しています。一度脆弱性対策を実施したからといって、安全だとはいえなくなってしまったのが現状です。定期的なセキュリティチェックを施すことで、新たな脆弱性にも迅速に対応し、被害を最小限に抑えることができます。 セキュリティチェックには、大きく2つの種類があります。ひとつはプラットフォーム診断、もうひとつはアプリケーション診断です。プラットフォーム診断はネットワーク内のサーバやネットワーク機器、また昨今ではIoT機器なども含む環境の脆弱性有無を調査します。アプリケーション診断では、WebアプリケーションおよびWebサイト、スマホアプリなどを対象に脆弱性を診断します。 どちらの診断も、インターネット経由のリモート診断と内部ネットワークからのオンサイト診断の2つに細分化されます。 2つの脆弱性診断において、自社に必要なリソースがあればその範囲で診断活動を実施するのが最適でしょう。しかし、脆弱性に適切に対応するためには、豊富な知見や経験による「判断力」が必要です。今自分たちが対策していることが、自社にとって正解か否かを判断できなければ、それが企業にとって致命傷となってしまう可能性もあるからです。 自社に十分なリソースがない場合は、脆弱性診断ツールや専門のセキュリティチームを活用することも検討しましょう。 まとめ 脆弱性は常に新たなものが発見されるため、完全になくすことはできません。しかし、放置すればその分セキュリティリスクは高まり、事業継続の危機はもちろん、社会的混乱やパートナー企業へも影響を及ぼす可能性があります。 脆弱性の本質を理解しながら適切な情報収集と対策を施していくことが大切です。そうすれば、万が一脆弱性からの脅威が迫ってきても、被害を最小限に食い止めることができます。 Sqriptsを通じて、読者の皆さんが「自社はどのように脆弱性と向き合っていくべきか」の最適解を見つけられることを願っています。 【参考】 総務省： 国民のためのサイバーセキュリティサイト IPA： 脆弱性対策情報データベースJVN iPediaの登録状況 AGESTのセキュリティ関連ソリューション ● サイバーセキュリティ診断 脆弱性診断サービス ● ULTRA RED セキュリティフレームワークCTEMに則ったSaaS型ソリューション ● クラウドソースセキュリティテストプラットフォーム（Synack） 世界最高峰のエシカルハッカーチームと独自のAIスキャナーを活用したセキュリティテストプラットフォーム など、さまざまなソリューションを展開しています。「必要かどうかがそもそもわからない」段階でもご相談を受けていますので、お気軽にご活用ください。 The post 脆弱性とは？脆弱性をなくすことはできないのか first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 今回のテーマは「ファシリテーション」です。いよいよ具体的な方法の解説に入っていきます。 前回のおさらい 前回は「スクラムマスターが絶対に言わないこと」から、コミュニケーションのポイントをざっくり解説しました。今回からは、より具体的な方法を解説していきます。まずは、場を整えてゴールへと導くために利用できる「ファシリテーション」を解説していきます。 優れたスクラムマスターが絶対に言わないこと ファシリテーションとはなにか？ ファシリテーションとは、チームの能力を高める技術です。最近だと予想できない世界情勢の中で、多様な人達が集まり活動するのが当たり前になってきました。こういったさまざまな「違い」や「変化」がある中で、適切に対立し、オープンかつ建設的に話し合い、物事を進めるためのファシリテーションスキルの重要性は高まっています。 ファシリテーションを行う人をファシリテーターと呼びます。ファシリテーターを理解するために、その特徴を以下にまとめてみましょう。 ファシリテーターは、中立である ファシリテーターは、チームをゴールに導く支援を行う ファシリテーターは、成果を高めるためによりよいコミュニケーションの場を作る これらを眺めてみると、スクラムチームで行うスクラムイベント（計画づくりやふりかえりなどのMTG）で求められる司会進行に通ずるものがあります。スクラムはコミュニケーション主体のフレームワークなので、ここで紹介するファシリテーションといったコミュニケーションスキルとの親和性が高いはずです。 ファシリテーションが機能していない現場例 ファシリテーションを活かした場を考える前に、「活かされていない場」について考えてみましょう。成功する方法を見つけるのは難しいですが、失敗する事例からは多くのことを学べます。 ファシリテーションが機能していない現場を以下のようにまとめてみます。 誰か特定の人が一方的に場をコントロールしようとしている 私は正しく、意見の違う相手は間違っている。よって、MTGでの会話が勝ち負けになりがち 他の人の意見より自分の意見に関心がある。関心を持ってほしい 面子（メンツ）が重要 誤解、対立、防御反応、不信感を感じる こうやって書くと「ひどい現場」に思うかもしれませんが、いろんな現場を見てきた私からすると「よくあるケース」です。ここまでひどいところはなかなかないかもしれませんが、いくつか当てはまる現場はたくさんあります。 たとえば、声の大きい人が上司やリーダー、先輩としているケースを考えてみましょう。こういった方は、すべてを自分でコントロールしようとするコミュニケーション方法を自然に使うことが多いです。その結果、意見を聞くと言いながら、最後は自分の話をしてしまったり、みんなで解決案を議論したいのに、自身の経験やアイデアをとうとうと語り「これやればいいんじゃない？」と考えを押し付けてしまったり。あながち「ない」とは言えない状況だと思います。 ほとんどの提案は相手に響かないという現実 前述の上司や先輩のように、相手からの提案やアドバイスは日常多く発生します。しかし、ほとんどの提案は相手に響かず、アクションに繋がることはありません。 たとえば、アジャイル開発で行われる朝礼やふりかえり（レトロスペクティブ）において、こんなやりとりがあったとしましょう。 「この前のふりかえりでアクションに選んだタスクですが、目の前の仕事が多くて手がつけられなくて困っています」 「みんな忙しいからなかなか難しいよね。ひとまず目の前の仕事を優先したら？」 「僕の場合、カレンダーにやることを全部登録して、その日にできることはその日にやっているよ。君も試してみたら？」 「そもそもやることが多すぎだから、本当にやるべきか考えたほうがいいんじゃない？」 みなさん、メンバーが困っていることの対策を一生懸命考えてくれているようです。もし、あなただったら、これらの提案を全部やってみたいと思うでしょうか？ この状況は、居酒屋でくだを巻くおじさんと似たような構図です。居酒屋でくだを巻くおじさんは、自分の過去の体験を語りながら「もっとこうすれば（私のように）うまくいく」と親切に教えてくれます。とても親切で優しい人なのでしょうが、「相手のためを思って」というより「自分が話したいから」話しているように見えます。  とびっきりのアイデアであれば、飛びついてくる人はいるかも知れません。また、相手との信頼性が高ければ高いほど、やってみようと思うかもしれません。しかし、そこまでの状況でなければ、「うーん。たしかにそうだけど」で思考が止まってしまいます。 他人の言葉や経験は、自分ごとになりにくいからです。 また、何かをやれていない人に対しての「これやれば？」は、相手の否定につながる言葉として受け止められかねません。 ファシリテーションが機能している現場例 それではいよいよファシリテーションが機能する現場を見てみましょう。そこには以下のような特徴があります。 確かな情報を集め、自由に選択を行っている 参加者は決定に貢献したいと内面から思っている 違いがあることを受け入れ、そこから学ぼうとする 相互理解を深め信頼を強める（心理的安全性が高くなる） 学びが多く、刺激的である チームの能力や仕事の質が高まっていると感じる ファシリテーションとは、チームの能力を高める技術です。チームが個人に与える影響や、個人がチームに与える影響が相互に効果を高め合い、チーム能力を向上させるチームダイナミクスを生み出します。 ファシリテーションは、このような場を作るためのスキルです。 提案が自分ごとになるために ファシリテーションが有効活用されている現場であれば、提案やアドバイスは学びとして受け入れられます。やるやらの選択もチームとして最適な選択肢を選ぼうとするはずです。 たとえば、決定事項に合意ができなくても、オープンな議論の上で決まったのであれば、チーム全員でアクションに貢献しようとします。たとえアクションに失敗したとしても、誰かを責めるのではなく、それを学びの機会として受け止め、次に力強く進んでいきます。 自分たちで考え、自分たちで選んだことなので、選択肢が自分ごとになります。 このように、ファシリテーターは、最高のコミュニケーションができる場を作り、建設的なディスカッションを支援し、アクションが自分ごとになるようにファシリテーションしていきます。 ＊ 今回は、ファシリテーションが機能する現場をイメージしてみました。提案が自分ごとになりにくい理由や、あるべき姿の解説も行いました。 次回は、こういった「理想の場」になるために役立つテクニックを解説します。このテクニックは全部で9つあり、それぞれにロジカルな理由や背景があります。 想定や推察を確認する 曖昧な言葉を確認する タブーを話し合う すべての情報を共有する 理由と意図を説明する 自分の「関心」を伝える 提案と質問を組み合わせる 次のステップを一緒に作る アクションを自分ごとにする この9つのテクニックを具体的に事例を交えながら学び、ファシリテーションスキルをどんどん高めていきましょう。 The post あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術 -1- first appeared on Sqripts .

こんにちは。ノウンです。 以前の記事で、「Webサイトのテスト」をスマートフォン（以下スマホ）を使って行う方法を紹介しました。その際は、PCとスマホをケーブルで接続して、PCのブラウザの標準機能であるデベロッパーツール（開発者ツール）を使う方法でしたが、今回はWi-Fi（無線）でPCとスマホを接続して同じテストを実施する方法をメリット・デメリットを交えて紹介します。 Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう Wi-FiでPCとスマホを接続してデベロッパーツールを使用するには条件があります。条件を満たしていない場合、Wi-FiでPCとスマホを接続をすることは出来ませんが、ケーブルで接続することは可能なので以前の記事を参照していただければと思います。 条件 ①PCとスマホを、同じWi-Fi（無線ネットワーク）に接続する ②「Android」は、「Android Studio」が必要かつ「OSver.11」以上である ※OSver.11で対応された、端末の「開発者向けオプション：ワイヤレスデバッグ」が使えることが前提となるため 「iPhone」は、初回の設定時のみスマホとPCをケーブルで接続する必要がある。OSver.は問わない 次に、「Android & WindowsPC」と「iPhone & MacPC」を使用した具体的な手順や設定について紹介していきます。スマホとPCの組み合わせは、この組み合わせでないと設定できませんのでご注意ください。 Android & WindowsPC（Chromeを使用） 以下の端末を使用した場合で説明します。 Android端末（OSver.11以上）＆Windows10 Pro 1. PCにAndroid Studioをインストールする 以下のURLにアクセスして、Android Studioをダウンロード→インストールします。 Android Developers インストールは、表示される画面に沿って進行すれば大丈夫です。迷う要素は特に無いと思いますが、公式のヘルプがありますので必要に応じてご参照ください。 Android Studio をインストールする 2. Android SDKの設定を行う スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用される様にします。 3. 「Tools」メニュー＞「SDK Manager」を選択 4. 「SDK Platforms」タブで、使用するAndroidのOSにチェックを入れる 5. 「SDK Tools」タブで、「Android SDK Platform-Tools」が「Installed」になっていることを確認（「Not Installed」になっていたらチェックを入れる） 6. 「OK」または「Apply」を押下してインストールを実行する これで、スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されます。 7. ADBコマンドを有効にする ADBとは、Android Debugging Bridge のことで、コマンドを有効にするとAndroid Studioを使ってPCでスマホの開発をしたり、コマンドプロンプトからスマホを操作したりと、スマホのみでは行えない操作をPCから行うことが可能となります。 今回はスマホでデベロッパーツールを使用する際、スマホのワイヤレスデバッグが正常に動作するように設定を行います。 設定する際、あらかじめ手順「5」の画像上部「Android SDK Location：」に表示されているフォルダパスを控えておくとスムーズに設定できます。 8. WindowsPCのタスクバーにある「スタート」ボタンを右クリック＞「システム」を選択 9. 「システムの詳細設定」を選択 10. 「詳細設定」タブ＞「環境変数」を選択 11. システム環境変数 の「Path」を選択＞「編集」ボタンを選択 12. 「新規」ボタンを選択＞Android Studioをインストールした時に一緒にインストールされた、フォルダ「platform-tools」のフォルダパスを入力 13. 開いている各ウィンドウを「OK」ボタンを押下して閉じる 【注意】手順13.で「キャンセル」ボタンを押下すると、ここまでの設定が反映されないため、必ず「OK」ボタンを押下して各ウィンドウを閉じてください。 14. PCを再起動する PCを再起動します。 15. ADBコマンドが有効になっているか確認する ここまでの設定が反映されているか、確認を行います。 WindowsPCの「コマンドプロンプト」を起動します。 （「スタート」アイコンをクリック＞「 cmd 」で検索＞コマンドプロンプトを選択。または、タスクバーの検索アイコン・検索ボックスから「 cmd 」で検索＞コマンドプロンプトを選択） 16. 「 adb 」と入力してEnterキーを押下する 画像のようにコマンドの引数（内部デバック[internal debugging：]）、USBの接続[usb：]などの情報）が一覧になって出てくれば、ADBコマンドが有効になっている。 ※ADBコマンドが有効になっていない場合、下記エラーメッセージが表示されます。ここまでの設定や入力した文字列に誤りが無いか確認してみてください。 17. Androidの「開発者向けオプション」を表示する Androidの「設定」＞「デバイス情報」＞「ビルド番号」の部分を連続で7回タップします。 ※Androidによって「ビルド番号」の表示箇所が異なる場合があります。 18. 「開発者向けオプション」を有効にする 「設定」＞「システム」＞「開発者向けオプション」を選択して「開発者向けオプションの使用」のトグルボタンを有効にします。 19. 「ワイヤレスデバッグ」を有効にする 「ワイヤレスデバッグ」のトグルボタンを有効にして表示されたウィンドウで「許可」を選択します。 ※「このネットワークで常に許可する」にチェックを入れてから「許可」を選択すると、2回目以降の接続時にこの手順が不要となります。 20. AndroidとWindowsPCを同じWi-Fiに接続する AndroidとWindowsPCを同じWi-Fiに接続します。 21. AndroidとWindowsPCのペア設定を行う WindowsPCのAndroid Studioを起動＞デバイス表示部分のプルダウン＞「Pair Devices Useing Wi-Fi」を選択して「QRコード」を表示します。 22. AndroidでQRコードを読み込む Androidで「設定」＞「システム」＞「開発者向けオプション」＞「ワイヤレスデバッグ」＞「QRコードによるデバイスのペア設定」＞「QRコードのスキャン」から、WindowsPCのQRコードを読み込みます。 読み込みに成功すれば、ペア設定は完了です。 23. AndroidのChromeでテスト対象ページを開く AndroidのChromeでテストの対象ページを開きます。 24. WindowsPCのChromeを開き、アドレスバーに「 chrome://inspect/devices 」と入力してアクセスする 25. 接続しているAndroidの端末名とブラウザ、テスト対象ページのURLがWindowsPCのChromeに表示されるので、URLの下にある「 inspect 」を選択する 26. デベロッパーツールが開く WindowsPCのChromeの左側にAndroidの画面、右側にデベロッパーツールが表示されます。 27. デベロッパーツール内の通信情報を確認 スマホでアクセスしたwebサイトを操作して、デベロッパーツールでwebサイトの通信情報を確認する。画像は「Network」タブに情報が表示されている状態。 以上で、AndroidとWindowsPCの設定は完了です。 iPhone & MacPC（Safariを使用） 以下の端末を使用した場合で説明します。 iPhone端末＆iMac 1. iPhoneでWebインスペクタを有効にする MacPCでiPhoneのデベロッパーツール（Webインスペクタ）を表示させるには、iPhoneの設定を行う必要があります。 iPhoneの「設定」＞「Safari」＞「詳細」＞「Webインスペクタ」のトグルボタンを有効にします。 2. MacPCのSafariで開発メニューを表示する MacPCのSafariは、デフォルトの設定ではiPhoneのWebインスペクタを開くためのメニューが表示されていないため、設定を行う必要があります。 Safariを起動＞「Safari」メニュー＞「環境設定」＞「詳細」の「メニューバーに開発メニューを表示」にチェックを入れます。 3. iPhoneとMacPCをライトニングケーブルで接続する iPhoneとMacPCをライトニングケーブルで接続します。 4. iPhoneとMacPCを同期する MacPCの「Finder」から接続したiPhoneを選択＞「一般」＞「このiPhoneが接続されているときに自動的に同期」のチェックを外す＞「同期」ボタンを選択します。 同期が完了したら、ケーブルを抜いてください。 5. iPhoneとMacPCを同じWi-Fiに接続する 6. MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞「ネットワーク経由で接続」にチェックを入れる 7. iPhoneのSafariでテスト対象ページを開く iPhoneのSafariでテスト対象ページを開きます。 8. MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞iPhoneで開いたテスト対象ページのURLを選択する MacPCのSafariで「開発」メニュー＞同期したiPhoneを選択＞iPhoneで開いたテスト対象ページのURLを選択します。 9. Webインスペクタが開く Webインスペクタが開きます。 10. Webインスペクタ内の通信情報を確認 iPhoneでアクセスしたWebサイトを操作して、WebインスペクタでWebサイトの通信情報を確認する。画像は「ネットワーク」タブに情報が表示されている状態。 以上で、iPhoneとMacPCの設定は完了です。 設定時の失敗例 設定が上手くいかない例として以下があります。 スマホとPCが異なるWi-Fiに接続されている 接続するWi-Fiは同じである必要があります。普段使用するWi-Fiが1つの場合は特に問題ありませんが、複数のWi-Fiを使い分けている場合は注意してください。 今回紹介した手順は、各手順毎に設定が行えていることを確認しながら進めれば上記以外の要因で失敗することは無い手順となっています。 注意点 PCとスマホを接続した状態のままにしておくと、スマホとPCが勝手に接続されてしまい第三者に見られたくない情報を盗み見される可能性があります。（例：PCを複数人で使いまわして作業をしている場合） 作業をしない時は、PCとスマホの接続を解除しておくことをお勧めします。 接続を解除する方法としては、「PCとスマホを同じWi-Fiに接続しない様にする」が簡単です。 先の手順で記載した様に、「PCとスマホが同じWi-Fiに接続されている」状態だとペアリングが行われるためです。 また、Androidであれば「開発者オプションを無効にする」、iPhoneであれば「Webインスペクタを無効にする」ことでも接続が解除されます。 なお、以前紹介したケーブルでPCとスマホを接続する手順では、ケーブルを抜けば接続が解除されるためその様なことは発生しません。 おわりに 今回はPCのブラウザ機能であるデベロッパーツールを、Wi-FiでPCとスマートフォンを接続して使用する方法を紹介させていただきました。 ケーブルで接続していないため、ケーブル長に左右されずに作業が行えること、スマホやPCの接続端子を自由に使用できる利点があります。 今回の方法を実際に試してみると、スマホとPCがケーブルで接続されていない状態だと想像以上に端末の取り回しがし易く、快適に作業を行うことができました。スマホ＋デベロッパーツールでテストを行う場合にぜひ使用してみてください。 The post Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう(第二弾) first appeared on Sqripts .

こんにちは。インフラエンジニアのTYです。普段はAWS,GCPなどのクラウドを扱ったサービスの検証・開発を行っています。 実は以前「 Asterisk入門~SIPフォンで通話してみる~ 」というブログを書かせていただきました。今回はAsteriskの別の機能についてお話ししたいと思います。 Asterisk入門　～SIPフォンで通話してみる～ 1. 概要 AsteriskはオープンソースのPBXです。PBXとは”Private Branch Exchange”の略で日本では”電話交換機”と訳すのが一般的です。1つの親番号に着信した通話をコールセンターやオフィス内線の様に適切な端末に振り分けます。 そんなPBXであるAsteriskですが、PSTNやSIPでの通話もちろんWebRTCでの通話も可能です。 Asteriskの情報は思っているよりも少なく、自分で構築した際にはWebRTCで通話できるようにするだけでも少し苦労しました。本記事では、私自身の備忘録もかねてAsteriskでWebRTC通話ができるようにしてみたいと思います。 2. 構築 AWS EC2インスタンスにUbuntuをセットアップし、そこにAsterisk,WebRTC通話で利用するブラウザアプリをインストールして構築していきます。 2.1 EC2 EC2インスタンスにUbuntuをセットアップし起動します。インスタンスタイプは小さいもので問題ないです。 2.1.1 セキュリティグループ セキュリティグループは以下のようにします。 セキュリティグループ ※アクセスするIPが制限できる場合は制限しましょう。 2.2 Asterisk導入 2.2.1 Asteriskインストール EC2にsshでログインし、Asteriskを導入します。 まずはシステムが更新されているか確認してください。 shell-session $ sudo apt-get update Asteriskをインストールします。 shell-session $ cd ~ $ wget <http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz> $ tar -xvf asterisk-18[tab] $ cd asterisk-18.[tab] $ sudo su # contrib/scripts/install_prereq install # ./configure --with-pjproject-bundled # make menuselect # make && make install && make config # exit $ cd ~ 次にAsteriskの設定ファイルをインストールします。 shell-session $ git clone <https://github.com/InnovateAsterisk/S2E2.git> $ sudo cp ~/S2E2/config/* /etc/asterisk 2.2.2 Asterisk設定( http.conf ) AsteriskでWebRTC通話を行うにはAsteriskのhttpサーバー機能を有効化します。 /etc/asterisk/http.conf を以下の様に変更します。 shell-session $ sudo vim /etc/asterisk/http.conf [general] enabled=yes ; HTTP bindaddr=127.0.0.1 bindport=8080 tlsenable=no ; HTTPS enablestatic=no Asteriskを再起動します。 shell-session $ sudo service asterisk restart 2.3 apacheインストールと構成 WebRTC通話で利用するブラウザアプリを用意します。今回はブラウザアプリもAsteriskと同じサーバーに配置します。 まずはapacheをインストールし設定します。 shell-session $ cd ~ $ sudo su - # apt-get install apache2 # a2enmod ssl # a2enmod proxy # a2enmod proxy_http # a2enmod proxy_wstunnel 必要なポートを開放します。 shell-session # vim /etc/apache2/ports.conf Listen 0.0.0.0:80 Listen 0.0.0.0:443 Listen 0.0.0.0:4443 Webアプリで利用する設定を行います。この時にDNSサーバーにAsteriskサーバーのIPアドレス指すエントリファイルを作成する必要があります。DNSサーバーは何でもいいですが、AWSだとroute53を利用できます。 shell-session # vim /etc/apache2/sites-enabled/000-default.conf <VirtualHost 0.0.0.0:80> ServerName <Asteriskサーバーのドメイン> DocumentRoot /var/www/html </VirtualHost> apacheを再起動します。 shell-session # service apache2 restart snapとcertbotをインストールし、証明書を発行します。 shell-session # snap install --classic certbot # ln -s /snap/bin/certbot /usr/bin/certbot # certbot --apache certbotが完了すると、新しい設定ファイルが作成されるので、それを開いて ws/ ホストを追加します。 shell-session # vim /etc/apache2/sites-enabled/000-default-le-ssl.conf <VirtualHost 0.0.0.0:4443> ServerName __copy_from_above__ DocumentRoot /var/www/html SSLCertificateFile __copy_from_above__ SSLCertificateKeyFile __copy_from_above__ Include /etc/letsencrypt/options-ssl-apache.conf ProxyRequests off ProxyPreserveHost On ProxyPass /ws ws://127.0.0.1:8080/ws ProxyPassReverse /ws ws://127.0.0.1:8080/ws </VirtualHost> apacheの設定はこれでOKなのでapacheを再起動し、設定を反映します。 shell-session # service apache2 restart # exit $ cd ~ 2.4 ブラウザアプリインストール WebRTC通話で利用するブラウザアプリをインストールし、ドキュメントルートに配置します。 shell-session $ git clone <https://github.com/InnovateAsterisk/Browser-Phone.git> $ sudo cp -r Browser-Phone/Phone/* /var/www/html/ 2.5 Asteriskユーザー設定( pjsip.conf/extensions.conf ) ここまでで利用するWebRTCアプリの設定が完了しました。最後にAsteriskサーバーの設定を行います。 まずは pjsip.conf でWebRTCで利用するユーザーを作成します。 /etc/asterisk/pjsip.conf を編集します。githubから設定ファイルをインストールしているためそこに以下を追記します。 このconfファイルでAsteriskで使用するユーザーを定義します。 ※パスワードはお好きな文字列に変更してください。 shell-session $ sudo vim /etc/asterisk/pjsip.conf ; == Users [User1](basic_endpoint,webrtc_endpoint) type=endpoint callerid="One Hundred" <100> auth=User1 aors=User1 [User1](single_aor) type=aor mailboxes=User1@default [User1](userpass_auth) type=auth username=User1 password=1234 [User2](basic_endpoint,webrtc_endpoint) type=endpoint callerid="Two Hundred" <200> auth=User2 aors=User2 [User2](single_aor) type=aor [User2](userpass_auth) type=auth username=User2 password=1234 [User3](basic_endpoint,webrtc_endpoint) type=endpoint callerid="Three Hundred" <300> auth=User3 aors=User3 [User3](single_aor) type=aor [User3](userpass_auth) type=auth username=User3 password=1234 次に /etc/asterisk/extensions.conf を編集します。こちらもgithubからインストールしているため以下を追記してください。 このconfファイルでダイヤル番号とユーザー紐づけます。 shell-session $ sudo vim /etc/asterisk/extensions.conf [subscriptions] exten => 100,hint,PJSIP/User1 exten => 200,hint,PJSIP/User2 exten => 300,hint,PJSIP/User3 [from-extensions] exten => 100,1,Dial(PJSIP/User1,30) exten => 200,1,Dial(PJSIP/User2,30) exten => 300,1,Dial(PJSIP/User3,30) exten => _[*0-9].,1,NoOp(Music On Hold) exten => _[*0-9].,n,Ringing() exten => _[*0-9].,n,Wait(2) exten => _[*0-9].,n,Answer() exten => _[*0-9].,n,Wait(1) exten => _[*0-9].,n,MusicOnHold() exten => e,1,Hangup() ここまでで設定出来たらAsteriskを再起動します。 shell-session $ sudo service asterisk restart ここまででAsteriskサーバーおよびWebRTCアプリの構築は完了です。実際に動作を確認してみましょう。 3.動作確認 動作確認のためWebRTCアプリに接続します。Chromeで以下のURLにアクセスします。 shell-session https://<Asteriskサーバーのドメイン> アクセスすると以下のようなサイトが表示されます。 WebRTCアプリ アカウントをクリックし、Asteriskサーバーに登録します。赤枠内にはAsteriskサーバーのドメインを入力します。パスワードには pjsip.conf で設定した値を入力します。 Asterisk登録 Asterisk登録2 そのほかはデフォルトのままで保存します。 シークレットウィンドウや別ブラウザなどでもう一つWebRTCアプリを表示し、そちらは別のアカウントで登録します。本記事の内容だとUser2 or User3があるはずです。 アカウントが2つ登録出来たらどちらかのアカウントから発信してみましょう。右上の電話マークをクリックし発信先にダイヤルします。ダイヤル番号はUser1なら100、User2なら200といったようになっています。このダイヤル先の設定は extensions.conf で行っています。 WebRTCダイヤル うまく設定できていればブラウザ同士で通話ができるはずです！ 4.さいごに 今回はオープンソースのPBXであるAsteriskをWebRTCの通話ができるように構築しました。音声のみの通話だけでなくビデオ通話も可能になっています。また、AsteriskはPBXであるため、通話の転送や着信をキューに入れて待機させておくことも可能です。 本記事でインストールしたWebRTCアプリには”SIPJS”というライブラリが使用されています。これはjavascriptでAsteriskを利用できるようにするためのライブラリでこのライブラリを利用すれば自作のWebRTアプリでAsteriskを利用することも可能です。私はまだそこまでチャレンジできていませんがそのあたりにもチャレンジしていきたいと思います。 ありがとうございました。 The post Asterisk入門～WebRTC通話編～ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第8回となる今回のテーマは「コストマネジメント」です。 限られた財源を意識してプロジェクト内で追加コストが発生しないように管理し、プロジェクトの目的・目標を達成することはとても重要です。 しっかりとしたコスト計画方法を知り、コストをマネジメントを適用することで、プロジェクトにとってコストは「管理するだけではない、変化に対応する武器」になるはずです。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ コストマネジメントとは コストマネジメントとは、プロジェクト予算内で遂行するための必要コストの見積もりや予算策定、それらをコントロールする活動を指します。 プロジェクトを行うには、当然ですが人件費や開発費用といったコストが発生します。プロジェクトにおける「鉄の三角形」である QCD ※1 に「C：COST」があるように、コストをしっかりと管理していないと、プロジェクトを終えられたとしても赤字になるなどして、プロジェクトが失敗したという評価になる可能性があります。また、予算超過が原因でプロジェクトが停止してしまうこともあります。まれに小さなプロジェクトでは詳細なコスト管理まで求められないこともありますが、プロジェクト予算が設定されている場合にはしっかりとコスト計画とマネジメントを行っていきましょう。 コストマネジメントは以下4つのステップ（プロセス）で行います。 ※1 QCD 「QCD」とは、Quality（品質）、Cost（費用）、Delivery（納期）の頭文字を重要度の高いものから順に並べたものです。 コストマネジメントのはじめかた 1) WBSやGANTTチャートから「コスト管理表」を作成し見積もってみる アクティビティタスクのコスト合計＝要素成果物のコスト 要素成果物のコストの合計＝成果物のコスト 成果物のコストの合計＝プロジェクト全体のコスト 各活動のコストを見積もる際は、タスク実施に必要な期間やそのタスクで利用する人件費や原材料費など必要な経費も追加します。また成果物の作成や伴う活動を外注する場合には、別途見積書を入手してコストに付加していきます。 2) コスト計画や管理表記載時の注意点 コスト計画や管理表に記載する際は、管理する資源ごとの単位を規定しましょう（例：時間を測定する場合は、労働時間や日数、通貨など）。記載の精密さのレベルや正確さのレベル設定も併せて必要です（例：見積りの正確さの許容範囲を±10％とする、といったレベルを設定するなど）。 また計画したコストの値からどれぐらい変動があったら手当をしなければならない、といった「閾値」を設けておかないと、Aさんは「これくらいのコスト変動（予実差）は許容できるだろう」と思っていても、Bさんは「すぐに処置が必要だ」と感じるかもしれません。そのような感覚に左右されないコスト監視やコントロールができるよう事前に計画、準備記載しておきましょう。 コストの見積もり 1) 見積もり精度のブレは結構大きい（最初から正確を求めない） プロジェクトの見積もり精度はプロジェクト活動が進むにつれて向上します、つまりプロジェクト初期（立ち上げフェーズ）はどうしてもその精度は十分ではありません。 ※PMBOKによる指標 また「超概算」と呼ばれる見積もりは-50～＋100%、予算化するタイミングでの概算は-10%～＋25%とされています。 2) 見積もり方法 コストの見積もりは、人件費（単価）、材料費、インフレーション、リスク要因など数多くの変数の影響を受けます。専門家や社内外にある経験や知識を集積して見積もるようにしましょう。 過去の類似プロジェクトの見積もり 業界、領域、専門分野の情報　 成果物の内製化や外製化の検討 （代替案分析） など 3) マネジメント予備、コンティンジェンシー予備 マネジメント予備（予備費）、コンティンジェンシー予備（予備費）という言葉を聞いたことがあるでしょうか？どちらもプロジェクトのコストとして予備的に計画/準備されるコストです。 コンティンジェンシー予備とは、主にリスク発生を鑑みて適応されるコストです。 例えば「成果物のどこかに手直しの発生が想定されるがどこであるか（手直しが発生するかも）わからない、もし発生した場合にかかるコストを予め用意しておこう」というものがこのコンティンジェンシー予備の使い先になります。一般的にはPMの裁量で使用することができます。 マネジメント予備は上記に対して「予期せぬ作業や事象に備えて用意」しておくコストです。例えば「プロジェクトの途中でクライアントから突発の追加要求が上がってきた」という「いざ」という事態に使うかもしれません。使用にあたってはプロジェクトスポンサー（PO）の承認が必要です。組織やプロジェクトによって「（見積予算 + コンティンジェンシー予備）× ○%」と一律規定、準備する場合もあります。 4) 品質コストを盛り込もう 品質コスト（COQ：Cost Of Quality）の前提条件を盛り込む必要があります。品質コストとはその通り品質を確保するためのコストであり、予防コスト、評価コスト、不良コストなどが含まれます。 コストをマネジメントするために コストコントロールの大部分は、コストの消費と当該支出の作業結果の関係を把握し分析することです。その時に単に「支出だけ」を追跡するのではコストコントロールの意味はぼやけます。必要なのは、達成した作業の本当の「価値」であり、それらを数値的に捉え「コントロール」することです。 「遅れています」「進んでいます」「月末までには完了すると思います」 こういった主観的な報告（説明）に対して、マネジメント者として客観的に「ほんとうに？」という疑問や、「そうだよね」という納得を返せる助けになるのが、複数の指標をコストに換算して管理できるアーンド・バリュー・マネジメント(EVM：Earned Value Management)という手法です。 まずはEVMを解し、プロジェクトの進捗状況や将来の問題をコストコントロールをしながら察知できるようにしましょう。 1) EVMで実績と進捗を定量的に可視化 EVMを使用する最大のメリットは コスト目線でのプロジェクト状態を「客観的に」測定することができる 精度の高い将来予測（見積もり）ができるようになる ことにあります。実際に、1960年代の米国でその膨大な国家赤字を見直すために、国防省でプロジェクトのパフォーマンス測定方法が見直されたことにEVMの起源があります。その後は米国産業界のガイドラインとして、政府調達のプロジェクトの前提条件となっています。 2) EVMで使う指標 EVMとは現在の進捗状況や将来の問題を察知するプロジェクト管理の手法のひとつです。難しくはありません、4つの指標を覚えましょう。 これらのPV、AC、EVの指標を使い、コストを縦軸、経過期間を横軸とするグラフを作成します。このグラフを基にこれまでのプロジェクトに費やされた作業量から推定し、プロジェクト完了にはどうなるか、という見積もりができるというわけです。EVMやそれら使った実績推移グラフからスケジュールの遅延やコストの超過が読み取れるなど、計画と実績の乖離が起きていたら即座に手を打つなど、問題が改善できるうちに対処するなどの予防を行いましょう。 3) EVMを使わないプロジェクト規模 EVMの他にも複数のコスト分析方法がありますが、まずはEVMをコストマネジメントに取り入れられれば十分です。むしろ、誤解を恐れずに言えば多くのプロジェクトで十分にEVMが使われていません。小規模プロジェクトではコスト管理のためのコストをかけることで、プロジェクト自体がショートすることになりかねないからです。筆者の感覚では最低5000万円以下のプロジェクト規模であれば、EVM以外のコスト管理をおすすめします。 コストが溢れそうだ！その時は。 プロジェクトは段取り（準備）が肝であり、コストもいかに計画、計算、想定しておけるか（計画の上で実行できるか）が、その後のプロジェクト成功の鍵です。残念ながら、どれだけ計画しても「まったく計画通り」に進むことは少ないですが、少なくともそれらの「事態」に予備費を準備したりするなど備えをしてきましたね？ みなさんがコストに対して、最も注力して対処するタイミングは「計画時」です。 コスト計画時に プロジェクトオーナーから指示された予算よりオーバーしてしまいそうだ 明らかにプロジェクト憲章に記載した予算と乖離があるぞ とわかったらしめたものです。計画時には2つの方法で予算とコストをポジティブに調整していきましょう！ 1) 基本的なコスト修正対応（1） 成果物の機能を簡易的な内容に調整したり、予定していた活動やタスクを見直す＝（今回は）やめる/スコープから切り離すなどしてコスト調整する「ECRS（イクルス）」を試しましょう。 ECRS（イクルス）とはEliminate（排除：取り除く）、Combine（結合：つなげる）、Rearrange（交換：組み替える）、Simplify（簡素化：単純にする）の頭文字で、元々は製造現場における的確な課題抽出と効果的な業務改善の手法として考えられたものですが、現在ではさまざまな業務改善に用いられています。 排除（Eliminate）：その業務をなくすことができないか？ 結合（Combine）：その業務を他の業務などと一緒にまとめられないか？ 交換（Rearrange）：その業務の順序や場所などを入れ替えることで、効率化できないか？ 簡素化（Simplify）：その業務のやりかたをより簡単にできないか？ 一般的にE→C→R→Sの順に改善効果が大きいと言われています。 2) 基本的なコスト修正対応（2） 予算自体を変更する（してもらう）交渉を恐れずに行いましょう。プロジェクトオーナーやクライアントなど、決裁者との会議や検討を設定し、予算自体適切に変更するための承認活動を行います。つまりプロジェクト憲章自体の予算を変更する、ということになります。いわずもがなですが、安易に予算変更（予算オーバー）承認を得るという考え方ではありませんので注意してくださいね。 多くの場合は、修正対応 （1）と（2）を組み合わせた検討と交渉/承認がスタンダードです。無理な計画、無理のあるコストでプロジェクトを実行しても、後々苦しくなります。プロジェクトの目的/目標の達成に必要な修正対応は早めに行いましょう。 おわりに PMは「限りある予算と限りない要求という圧力」と常に共にあり、コストマネジメントは大変困難な仕事です。そしていかに計画・準備とマネジメント施しても、どうしてもオーバーランするものだと意識してください。ITプロジェクトでは規模が大きくなる程予算超過率も高く、超過しないプロジェクトの方が少ないでしょう。コストの適正さや課題を日頃からプロジェクトオーナーと共通認識をもっておくこと。最も情報が少ないプロジェクト初期がコストマネジメントの重要タイミングであることを忘れず、コストマネジメントを困難にする様々な要因に立ち向かっていきましょう！ 次回のテーマは「プロジェクトの品質マネジメント」です。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ The post 【第8回】コストをプロジェクトの武器にする！ first appeared on Sqripts .

はじめまして。テストエンジニアのサバコ、りんご、ぴょんです。 私たち2名は、昨年よりQA事業に携わる部署の所属となり、現在はテスト実施業務に従事しています。まずはテスト実施で経験を積みつつ、将来的にはテスト設計者へステップアップしたい・・・！という目標を掲げ、日々業務に取り組んでいます。 そんな私たちは昨年、社内で1ヵ月間の「テスト設計者研修」を受講する機会がありました。今回のブログでは、テスト設計未経験の私たちが1ヵ月間の設計研修で何を学び、どんなことを感じたかをお話ししたいと思います。 テスト設計者研修の概要 1．座学（約１週間） はじめに、約1週間の座学を行いました。座学ではテストに関する基礎的な内容を中心に学習しました。 ソフトウェアテストの基礎とテスト工程の概要を学ぶ ブラックボックステスト技法の学習および演習 理解度テスト（1日）：主に各テスト技法の習得度を確認するテスト 2．テスト設計演習×2回（各1週間） 座学の次は、テスト設計演習を２回にわけてそれぞれ１週間ずつ行い、より実践的な学習を行いました。 演習用のシステム仕様書を基に「テスト設計仕様書」を一通り作成し、適切なテスト技法を用いてテストケースを作成するまでの演習 2回目の演習では、顧客への説明を想定したプレゼンテーションも行う テスト設計者研修で学んだこと、感じたこと 1．テストに関する知識・考え方の変化 座学の研修は基礎知識に関する講義が中心でしたが、その中でも重要なポイントについては実例を交えた丁寧な解説があり、テスト業務の全体像が理解しやすい講義でした。特に、テスト設計の一連の流れを学ぶことができたのはとても有意義でした。 受講前は、テスト実施業務で使用している「テスト項目書」は、開発仕様書などから直接起こすもので、イメージとしては「Verification（検証）」の視点に基づくものと考えていました。 しかし、実際には機能の洗い出し、テスト観点の抽出、洗い出した機能へのテスト観点の割り当て・・・など、様々な分析を行いながら「テスト設計仕様書」を作成し、開発仕様書には記載のない部分、ユーザーの要求・ユーザーの使い勝手なども意識した「Validation（妥当性確認）」の視点も含めて、ひとつひとつのテストケースが作られていることを学びました。 普段目にしている「テスト項目書」がどのようなプロセスを経て作成されているかを学び、また設計演習でそのプロセスを実際に順を追って体験できたことで、現在のテスト実施業務においても、 なぜこの観点が用いられているのか この項目にかかる工数は適切なのか などを考えながらテストに取り組むようになりました。 また、 挙動は仕様通りだが、システムの応答時間が若干遅いのでは （とあるシステムで）メッセージの送信時間に、時間だけでなく「日付」も付与した方がユーザーにはわかりやすいのでは など、ユーザビリティの観点を考慮して報告・要望も挙げられるようになってきたり、テストを行う際の「意識」にも少しずつですが変化が出てきたように思います。項目書の文字を追うだけのテストではなく、設計者の意図やテストを行う意味をしっかり理解した上で実施することで様々な気付きが生まれ、より質の高いテスト実施が可能となることをあらためて実感しています。 他にも、テスト設計演習の際、「ローレベルなテスト項目書の作成」を心掛けるよう指導がありましたので、実業務で触れるテストケースについても、 経験の浅いテスターでも、正しいテストが実行できる前提条件・実施手順となっているか 明確な期待値の記載がされているか など、ローレベルな項目書になっているかを常に考えながら見るようになりました。 「テスト設計には正解がなく、テスト設計者によってテスト項目にも違いが出る」とのことでしたので、この先もテスト実施を数多く経験していく中で様々なテスト項目書・テストケースに触れながら、実施しやすいテスト項目書のノウハウを身につけていきたいです。 2．難しかったこと、苦労したこと ブラックボックステスト技法の理解・習得 「同値分割法」「境界値分析」は比較的理解しやすく、実業務でも「テスト項目に具体的な入力値の記載がされていなくても、同値クラスや境界値を入力してテストする」など、ある程度自分で考えて活用できるようになりました。 が、「デシジョンテーブル」「組み合わせテスト」は、どういったケースに用いると有効なのかの見極めと、正しい条件が設定できているのか・・・などの判断がしづらく、演習でもうまく活用することが難しかったです。 とはいえ、膨大・複雑な仕様、入力条件を整理するためにはテスト技法の活用は必要不可欠とのことなので、それぞれの技法に慣れるために「テスト技法の問題集」などを活用し、自学に励みたいと考えています。 顧客への説明を想定したプレゼンテーション 緊張感が高まる中、「テスト設計仕様書」と「テストケース」をどのように作成したかの説明に終始する・・・という反省点の多いプレゼンとなってしまい、少々ハードルの高い演習でした。後に過去の研修の模範的なプレゼンテーションの動画が共有され、プレゼンのあるべき姿が把握できました。 正しいテストを行うためには、ステークホルダとの綿密なやり取り・テストに関する意識の擦り合わせが特に重要であることを学びました。 3．全体的な感想 ・主に「Meet」を利用したオンライン研修でしたが、並行してコミュニケーションツール「Metalife」も活用しました。「Metalife」は、研修メンバー全員での会議はもちろんのこと、受講者同士個別でも気軽にやり取りができるツールで、アバターを作成できるゲームのような機能が搭載されていたこともあり、気軽に利用できました。対面でないと一方通行になりがちですが、こうしたツールを上手に活用したコミュニケーションの取りやすい研修だったと思います。 ・テスト設計の知識が乏しかったため、理解のスピードや演習の進みが遅く、講師の方には苦労をお掛けしたことと思います。そんな中でも、都度Slack・ハドルミーティング等で最大限のアドバイス・フォローをいただくことができたので、設計演習・プレゼンテーションとも反省点は多々あるものの、ある程度の形に仕上げることができました。 ・研修全体を通して、学ぶべき情報量が多く、1ヵ月ではとても頭に入りきらない・・・と焦る気持ちが大きかったですが、研修で使用した資料や演習教材は研修終了後も参照できるよう共有されているため、今後も折に触れ参考にし、引き続き設計に関する知識を深める努力をしたいと考えています。 まとめ 1ヵ月という短い期間で、理論だけでなくテスト設計演習・プレゼン演習なども含めた実践的なスキル研修まで学ぶことはなかなか大変でしたが、得られたものは大きかったと思います。 社内で充実した研修を受講できたことで、テストに関する学びを深められ、日々のテスト実施にも自信を持って取り組むことができるようになりました。 今後も日々の業務を行う中で、研修の内容を反芻しながら知識を増やし、直近の目標として、まずはJSTQB FLの合格を目指したいと思います。 そして将来的には、テスト設計業務にも挑戦しスキルを更に高めていけるよう、前向きに進んでいきたいです。 おわりに 講師の方による研修ブログに、さらに詳しい研修内容の解説があります。ご興味のある方は是非ご覧ください！ テスト未経験者向けに研修を行って、気付かされたこと(前編) テスト未経験者向けに研修を行って、気付かされたこと(後編) The post テスト設計未経験者がテスト設計研修を受けて感じたこと first appeared on Sqripts .

こんにちは、エンジニアのしているタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、自分たちのプロダクト開発チームで行なっているNotionとGitHubを使ったリリースバージョンの管理について紹介したいと思います。 リリースバージョンとは プロダクトの開発において、開発の区切りや本番リリースを行う段階で、プロダクトに バージョン という一意の番号を付与することがあります。 これはプロダクト（ソフトウェア、インフラ等）のとある段階を指し示すための番号であり、この番号とリリース日などを併せて管理することで、プロダクトの実装済み機能や改修の状態が、チーム内外から分かりやすく判別できるようになります。 例. A機能はバージョン1.0.0で実装した。Bの改修はバージョン1.1.2で行っており、このタイミングでデグレードが起きたなど このうち、本番環境にリリースしたものをリリースバージョンと呼びます。 リリースバージョンを定義することで 「◯月◯日」にリリースした機能 ではなく、 バージョン1.0.0でリリースした機能 といった呼称にでき、機能やリリース時期の関係が分かりやすくなります。 リリースバージョンと管理内容 自分たちのプロダクト開発チームでは4つのリリースバージョンを定義しています。赤字の数字が対象のバージョンに対応する部分です。 これらのリリースバージョンは、リリース日と後述の情報を併せてNotionのDBで管理しています。 リリースバージョンのDB. リリース日はグレーアウトしています ページの内容 リリースバージョンと紐づけて管理している内容は以下の4つになります。 Product Back Log（PBI） リリースノートのページURL コンテナのリビジョン リポジトリのmainブランチのタグ 1.のPBIは、Notionで別管理しているPBIのDBとの関連付けを行っています。また、2. のリリースノートのページURLは、公開したリリース情報に関するページなどのURLを載せています。 3.と4.については以降で個別に解説します。 コンテナのリビジョンを取得する 自分たちのプロダクトの環境は、Google CloudのCloud Run（コンテナ）を使用しています。 デプロイをするかサービスの構成を変更すると、コンテナごとにリビジョンと呼ばれる設定やコードバージョンのキャプチャ情報が生成されます。 このリビジョンにはコンテナのURLや環境変数などの設定に加えてデプロイしたソースコードも含まれ、GUI上から選択することでコンテナ単位で過去のリビジョンに戻すことも可能です。 Cloud runのリビジョンは、事前にインストールした gcloud CLIにプロダクト環境のプロジェクトを設定したうえで、以下のコマンドで取得できます。 $ gcloud run revisions list | grep yes このコマンドを実行するとリージョン選択を促されます。 リージョンを選択すると存在するコンテナの現リビジョンが表示されるので、先ほどのNotionのページにコピー & ペーストしています。 リポジトリのmainブランチのタグ管理 次はGitリポジトリでmainブランチのタグ管理を行います。 通常、タグはリポジトリをcloneしてきたうえで、ローカルリポジトリのmainブランチに切り替えて打つ方法が一般的です。 $ git checkout main $ git tag -a 1.0.2 -m '1.0.2リリース' $ git push origin 1.0.2 （又は git push origin --tags） ただし、ソース管理をGitHubで行なっている場合、 GitHubのRelease機能 を使うことでより簡単に管理が可能です。 機能で管理するメリットはいくつかありますが、タグ打ちとRelease関連情報の記録を同時に行うことが最大のメリットかと思います。 リリース機能の特徴 * GUIでタグを打てる * リリース情報を（commit情報を引っ張ることで）半自動生成で書けてファイル添付も出来る * リポジトリの利用者がRelease機能のページからソースや配布ファイルを簡単にダウンロードできる Release機能の使い方 1. リポジトリトップページの Tags をクリックします。 2. Releasesタブで、 Draft a new Release ボタン をクリックします。 3. Releaseの画面で、 Choose a tag プルダウン からタグを新規作成し、Targetブランチを指定します。今回は本番リリースのバージョンを管理するのでmainを指定します。 入力欄 4. タイトルと説明を入力していきます。本文はGenerate Release Notesボタンでcommit内容が自動で入力されますので、これを使用します。 5. 併せて、Notionのリリースバージョンページへのリンクも掲載して関連付けを行います。 6. 作成ボタン を押して画面が作成されたらOKです。 作成後のページ。内部情報が含まれているのでグレーアウトしています おわりに 今回の内容は以上となります。 現状、本日紹介した内容はリリース作業の一部として組み込んでおり、担当者が手動で実施しています。 現時点ではまだ発展途上であり、今後管理すべき情報がもっと増えた場合はそれに応じて追加していく予定です。 なお、コンテナリビジョン取得やNotion APIを用いてのページ作成等は比較的簡単に自動化できる思うので、リリース時の負荷はまだまだ減らせると思います。 リリース内容の管理に困っている方はぜひ一度試してみてください。 The post GitHubとNotionで実現するアジャイル開発のリリースバージョン管理 first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 はじめに どちらが「論理的」だと感じますか？ 図1-1、PさんとQさん、どちらが「より論理的」だと感じますか？　その理由は何ですか。 図1-1 食堂で注文を話し合うPさんとQさん 「論理の言葉」を覚えたら “実践編”のテーマ 論理スキル”実践編”では、”入門編”で出てきた「基本的な論理の言葉」を基にして、文や文章の論理構造を読み取ったり、筋道立った文を作ったりするための 「推論」の形 を見ていきます。 不具合/故障のチケットやテストサマリレポートを書きあぐねた経験はありますか。テストベース（要件定義書、機能仕様書、ユーザーストーリー、etc.）や返ってきたチケットを読んで、「どんな場合にどうなるのかわからないな？」「何故この対応でよいと言えるんだろう？」などと感じたことはありますか。 ソフトウェアの世界でも、(長めの)文/文章を読み書きする機会は多くあります。こうした困りごとをなくすためにも、 論理の言葉の使い方、使われ方 の感度を研ぎ澄ませましょう。 ●入門編：テストエンジニアのための論理スキル[再]入門 記事一覧はこちら ｜Sqripts 推論：　話の筋道をつくる、読み取る 推論とは 何か言いたいことがある時、最終的に言いたいこと(結論)と、その結論の前提があります。結論も前提も何かしらの主張や判断ですが、ここではざっくり「文」と呼びます（本連載では、文脈によって「主張」「判断」「文」を使い分けます）。 前提となる文(主張/判断)をつなげて組み立て、結論となる文(主張/判断)を導くことを 推論(inference) と言います。(図1-2) 1-2 “推論”とは 推論では、前提(根拠)から結論までのつながり、話の筋道が重要です。(図1-3) 前提が、結論(言いたいこと)の根拠になっている 前提から結論までのつながりに無理や飛躍がない 図1-3 推論で大事なこと その話の筋道を組み立てたり、話の筋道をチェックしたりするのが、 推論の形 。 そこで活躍するのが、“入門編”で見てきた 論理の言葉 です。 形が整っていれば自動的に「正しい筋道、正しい推論」となるわけではありませんが、形がよくない立論は言っていることが正しくてもよい主張とは言えません。（「「真」と「妥当」」の節参照） 推論の種類と、”実践編”で扱う推論 推論には種類がいくつかあります。(図1-4) 図1-4 演繹と帰納とアブダクション 演繹 （えんえき） 演繹（deduction） とは、ひとつ以上の前提から結論を導き出す推論の形です（図1-4は「前提から結論」をいくつか組み合わせた複合的な形になっています）。 何かを根拠とともに主張する時、正しいと広く受け入れられた事柄に基づいて個別の事例を論じる時、などに使われます。 前提がすべて正しいなら、結論が正しいかどうかは形から判定できます。 帰納 （きのう） 帰納（induction） とは、個別の事例から一般的/普遍的な前提(各事例に共通する規則・法則、性質・特徴など)を導き出す推論の形です。 ソフトウェアのテストで、「画面AでPという操作をしたら故障Xが起こった」「画面Bで操作Pをしたら故障Xが起こった」……「どの画面でも、操作Pをしたら故障Xが起こる（のでは？）」と仮説を立ててテストを広げていくのは帰納的な推論の働きです。 有限個の事例に基づいているため、この推論から導かれる「事例に共通すること」は必ずしも正しいとは限りません（“当てはまらない例外”があり得る）。 アブダクション、レトロダクション アブダクション(abduction)、またはレトロダクション(retroduction) とは、個別の事例から、その事例(結論)に至る前提や理由を導き出す推論の形です。 アブダクション的な推論として、 デバッグ があります（故障から、その故障を引き起こす原因である欠陥を推定する）。また、欠陥の 原因分析 でもこの種の推論が働きます。 この推論から導かれる「前提と当てはまる推論」も、必ずしも正しいとは限りません（デバッグでも、原因を特定したと思ったら違っていた、やり直し。ということは多々ありますね）。 “実践編”で取り扱う推論の種類 “実践編”では、前述のうち演繹的な推論/思考を形成する推論の形を取り扱います。 帰納やアブダクションでも必要になる、思考の基盤です。 演繹的な推論にもいくつか種類がありますが、本連載では「ふたつ以上の前提(主張/判断)から、結論となる主張/判断を導く」形式を主に取り扱います。 「真」と「妥当」　～正しさの留意点 正しい推論であるためには、ふたつのことに留意する必要があります。(図1-5) 図1-5 真と妥当 「真」であること　……内容の正しさ(真偽) 前提が間違っていたり、結論が間違っていたりしていては、正しい主張とは言えません（当然ですね）。正しい前提に基づいて、正しい結論を導出するものである必要があります（図1-5の上の文が真です）。 「妥当」であること　……話の筋道の正しさ(妥当性) 前提や結論が真でも、適当に(自分に都合よく)理屈をつけるのでなく、 話の筋道が「よい形」をしている 必要があります （図1-5の上の文が妥当です） 。 「よい形」とは： 論理の言葉を適切に（意味と働きに即して）使っていること 文(主張)と文(主張)とのつながりの中で矛盾や飛躍を生じていないこと 真偽も大事だが、話の筋道も大事 前提や結論が正しくても、非妥当な(よい形でない)推論は間違った推論です。 次のa, bどちらも、①②③それぞれは正しいとしても、①②から③を主張することは妥当ではありません。 (a) ①イヌはイヌ科の動物である。②イヌは哺乳類である。∴③イヌ科の動物は哺乳類である。 (b) ①ネコにはしっぽがあるか、またはにゃあと鳴く。②うちのネコはにゃあと鳴く。∴③うちのネコにはしっぽがない。 一方、前提や結論は間違っていても、妥当な(よい形をしている)推論は作れてしまいます。 (c) ①哺乳類は空を飛ぶ。②イヌは哺乳類である。∴③イヌは空を飛ぶ。 (d) ①ネコには縞模様があるか、または単色である。②うちのネコには縞模様がない。∴③うちのネコは単色である。 両方揃って、初めて正しい推論と言えることになります。 内容の真偽はその内容を吟味しないと判断できませんが、筋道の正しさは形から判断できます。本連載で取り上げる「推論の形」はその筋道の正しさを確保する役に立ちます。 なお、「よい形」を作れていない推論や、内容に誤りがある推論の特徴を「誤謬(ごびゅう)」と言います。これらについてはシリーズ後半の記事「気をつけたい落とし穴」で取り上げる予定です。 冒頭の“問題” 「食堂で注文を話し合うPさんQさん」は「「論理的」ってどういう感じのこと？」を感じてもらいたくて考えたもので、考え方の正誤や優劣を論じるものではありません。 Pさんの主張を整理・補足すると、①初めての店では外れのなさを優先して注文する。②唐揚げは大体どの店でもおいしい（から、外れがない/少ない）。③唐揚げ定食を注文する。 となっていて、①と②から③が無理なく出てきます。 Qさんの方はどうでしょうか。 ①初めての店では（その店の「推し」として）「本日のおすすめ」を頼む。②さらに煮魚定食はこの店で一番安い（から、懐に優しい）。③煮魚定食を注文する。 Qさんの主張には、 それが嫌いな食べ物でも頼むの？ とか、 「本日のおすすめ」がメニューの中で一番高かったらどうするの？ という疑問が生じます。前提①②と結論③の間に飛躍がある感じがします。 （本“問題”は、『論理的思考の技法Ⅰ』を参考にしました） （注：「食事の注文は論理的に考えてなされなければならない」と言っているわけではありません！） （注：どちらの「注文の論理」も、ありだと思います） （注：何にせよ心地よく選んで心地よく食事を楽しみましょう！） クイズ 次の主張は「よい形」をしていると思いますか。 （『例解・論理学入門』を参考にしました） （解答は次回に） 問1 Aさんの性格を考えると、①Aさんはギャンブルに手を出すと破産する。 しかし、②Aさんはギャンブルには手を出さない。 従って、③Aさんは破産しない。 問2 その時代、①家柄がよくて、裕福ならば、誰でも結婚できた。 ②彼の家柄はよかった。 しかし、③結婚できなかった。 従って、④彼は裕福ではなかった。 参考文献 鈴木美佐子 『論理的思考の技法Ⅰ〔第2版〕』法学書院 2013 弓削隆一, 佐々木昭則 『例解・論理学入門』 ミネルヴァ書房 2009 図版に使用した画像の出典 TopeconHeroesダーヤマ, 『分かりやすいプレゼン資料 1秒で伝わるビジネスイラスト集』 インプレス 2016 人物画(シルエット)をお借りしています。 Loose Drawing  人物画をお借りしています。 The post 論理のかたち。推論とは｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは、エンジニアのタカです。 普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。 今回は、自身が所属する開発チームで起きたコミュニケーションの課題を解決した バーチャルオフィスツール Gatherについて、導入前後でどのようにチームに変化があったのかを紹介したいと思います。 チームのコミュニケーションの課題 開発チームが2023年夏頃に行った振り返りで、特に新しくチームに入ったチームメンバーからコミュニケーションの敷居が高いという意見が上がりました。 チームメンバーはオフィスや遠隔地の自宅などそれぞれ異なる場所で働いており、会話を伴うコミュニケーションツールはSlack（ハドル） とGoogle Meetを使用していました。 これらのツールでは、話す前に「通話いいですか？」などを一度Slackチャンネルに投稿してから行なっており、会話へのアクションが段階を踏むことで気軽に行えないという意見が上がりました。 そこで、解決策の一つとして上がったのがバーチャルオフィスツール ※1 でした。 もちろん、出社時にコミュニケーションを取ることで解決する部分はありますが、遠隔地で勤務しているチームメンバーも含めて常に全員が揃う機会は少なく、今回試すことにしました。 ※1：仮想のオフィス空間 = ワークスペースにチームメンバーがアバターとして表示され会話やチャットを行う。まるでオフィスに居るように人（アバター）の動きが可視化されるのが特徴 Gatherとは バーチャルオフィスツールは数多くありますが、無料プラン ※2 をチームで使って比較検討を行い、最終的に以下のような理由から Gather を使うことに決めました。 操作性 アバター移動の操作性とレスポンスがよく、使っていてストレスが無かった 親しみやすさ ワークスペースが上から見下ろすタイプのドット絵で描かれた2Dで、キャラクターもドット絵で馴染みやすい 筆者を含む2Dゲーム世代(?)のメンバーのウケがとても良かった ※2：この記事を書いている段階ではGatherは最大10名まで無料 Gatherを触ってみての感想 以下、Gatherの導入にあたり設けたチームルールと、主な機能を使ってみての感想になります。 導入したチームルール 定例MTGを含む、全てのチームコミュニケーションはGather内で行う 機密に関わる話、チーム外のメンバーを交えたMTGなどは除く ステータス状態を逐次変更する ステータスはコマンドで変更でき、誰が不在かが分かりやすいため 主な機能の使用感 1. アバターでのコミュニケーション Gatherを選んだ理由の一つでしたが、アバターの操作性、レスポンスがよいです。 またチームメンバーの今の状態が一覧で見れることで「あの人は今誰かと話している」「話しかけて大丈夫そう」など現実のオフィスに近い感覚で状況把握ができるようになりました。 誰かと話して別の人を呼びたい時も、手を振るという機能を使ってすぐに通知が飛ぶので、ストレスなくコミュニケーションを行うことができました。 2. ビデオ通話（多人数、少人数） ビデオ通話の品質は、meetと比較しても特に遜色はありませんでした。MTGルームや各自席周辺などのフォーカスが当たる部分に入ることで、その部分に居るメンバーはシームレスに通話に移行するので使いやすいです。 ただし、人数が増えると、PCスペックや回線によっては、ビデオをONにしたときにややPCが重くなるケースがあったため、その場合はビデオを切ってMTGしてもらうなど対策を行なうことでこの問題は解消されました。 なお、フォーカスの無い場所ではアバター同士を近づけると話せますが、基本的に各自の席周辺や大きなフォーカスエリア（MTGルーム）で話すことが多くなったため、立ち話のように何も無い場所で会話することは少なくなりました。 3. デスクトップアプリ 個人的に、Gatehrはデスクトップアプリがとても使いやすいと感じました。 アプリはミニモードという表示が行え、Gatherからフォーカスを外した時はデスクトップ上に自分のステータスが最小表示されます。このときに誰かが自分の居るフォーカス部分に来ると、ミニモードのままで通話ができます。 常に画面を出しっぱなしにしても良いのですが、集中したいときは気になるので、このモードのおかげでリモートワークのメリットと、オフィスワークのメリットの両方が満たされると思いました。 なお、この状態でキャラクターを動かすことはできないので、MTGルームに行くなどの際は、Gatherアプリを選択してキャラクターを動かします。 4. その他機能 GoogleカレンダーやSlackとの連携、Gatherへの外部アクセス制限、ゲスト招待機能、オフィステンプレートの編集機能などを使用しています。 この中のGoogleカレンダー連携は、予定の数分前にデスクトップに通知を出せるようになるので、MTG参加忘れに役立ちます。 コミュニケーションに起きた変化 Gahterを使い始めてすぐにコミュニケーションの変化を実感しました。そのうち、特に実感したことをいくつかピックアップします。 良い方向に変わったこと 1. コミュニケーションコストの低下 振り返りで課題として上がっていたコミュニケーションの敷居の高さは無事解消されました。 Slackで一言投稿するよりも、話しかけてOKのステータスの人に近寄って呼び出すことは心理的ハードルが低いという意見がありました。 また、アバターだからか誰と誰が話しているかも分かりやすくなり「朝会で報告した問題点について有識者と話していそう」など状況が掴めるようになりました。 2. MTGへのシームレスな移行 MTGをGatherで行うことにより、MeetなどのMTG用ツールの起動が不要になりました。 全員でMTGを行う際は、オフィスのように全員が集まれるエリアに移動するだけでMTGが行えるので、特にストレスなく開始できます。 議事録やチャットもGather上のホワイトボードに記録でき、全体向けに共有が必要な場合はその場ですぐに共有ができるので、プロジェクトで必要なコミュニケーションは、基本的にGather上で動作が完結できます。 気になった点 1. コミュニケーションコスト低下により、作業時間が減るメンバーが出てきた メリットと表裏一体ではありますが、気軽に会話をしやすい環境になったため、特にコアメンバーへは相談や質問でのコミュニケーションコストが生じ、作業時間が減少するという問題が起きました。 設計やレビューなどの必要なコミュニケーションが増えることは良いことですが、本来は自分で解決できるような簡単な質問も増えてしまう傾向が見られました。 リモート、オフィス関係なく基本的なことではありますが、質問する場合のルールを決めたり、優先作業に集中したい場合は応答不可にして貰うルールを設けることを検討しています。 2. リモートメンバーとオフィスメンバーが混在する場合の取り決め オフィスに出社しているメンバー同士ですと、わざわざGather上で話すよりも直接話すことが多いため、リモートメンバーからは状況がつかめなくなります。 弊社はフリーアドレス席のため、固まって仕事をすることはほぼ無いのですが、出社中の場合はステータスを記入してもらうことで状況をリモートメンバーにも明示することを検討しています。 おわりに 今回の内容は以上となります。 バーチャルオフィスツールは初めて使いましたが、結果的にコミュニケーションに対する敷居が格段に下がり、リモートワークにおけるメンバーの満足度が向上しました。 主にリモートワークでコミュニケーションに課題があるチームは一度使ってみる価値はあると感じたので、気になった方はぜひ一度試してみてください。 The post リモートワークのコミュニケーションコストがバーチャルオフィスGatherでグッと下がった話 first appeared on Sqripts .

はじめまして。テストエンジニアのchikaです。 最近はリモートワークも増えチャットツールを導入した企業が多いと思いますが、 チャットツールを使っていて情報を取りこぼしたこと 仕事はこなせているけどもうちょっと効率良く作業できないかな～と思ったこと はありませんか？ そんな２つの課題を解決に導いたTeamsの便利機能を実体験を元にご紹介したいと思います。 Microsoft Teamsとは？ マイクロソフト社が提供するコミュニケーションツールで、チャットや通話、ビデオ会議といった複数の機能が実装されています。また、Officeアプリと連携してファイルを共有したり編集ができるとても便利なツールです。 便利機能の紹介 チャットの見落とし防止 Teamsを使い始めた当初、いつの間にか色んなグループにメンバー追加されどんどんチャットがきて必要な情報を見落としてしまう始末…とても困っていました。そんな中で見つけたTeams初心者にオススメの機能です。 メッセージの保存機能 重要なチャットや後から読み返したいチャットなど、どのグループチャットからも自分専用の場所に保存することができる機能です。 保存したいメッセージの右上［‥］＞「このメッセージを保存する」をクリックすればOKです。 保存したメッセージは、右上の自分アイコンの「保存済み」をクリックすると保存済み一覧が表示され、必要なメッセージのチェック時間を削減することができます。 【補足】チェックし終わったメッセージは「保存」を外しておくと、必要な情報が整理できて 未読の確認機能 検索欄に”/unread”と入力すると、左側のフィードに未読メッセージの一覧が表示されます。　　休み明けやリアルタイムにチャットを確認できなかった場合に重宝します。 ※［アクティビティ］＞未読のみ のトグルをONにしても同様です。 自分専用チャットによる 作業効率アップ 今まで必要な情報はメモ帳やExcelにまとめていましたが「自分専用のチャット」があることに　気付き、使ってみたらファイルを開いて知りたい情報に行きつくまでのちょっとした手間が省け、　以前より情報収集のスピードがアップしていました。 日常的に使えば使うほど「タイパ （Time Performance）」を実感できる機能です。 自分しか閲覧できないチャットで、自分宛てにメッセージを送信して使用します。 画面左にある「①チャット」をクリックし、固定表示の「②自分の名前（あなた）」をクリック 又は、画面上の検索欄①に自分の名前を入力し「②自分の名前（あなた）」をクリック あとは、通常のチャットと同じようにメッセージを書いて送信すればOKです。 今回はほんの一例をご紹介しますが使い方次第で時短の可能性は広がりますので、是非ご自身で　活用法を探してみて下さい。 リンク先やフォルダの場所一覧 リンク先のURLやフォルダの場所を記載しておくと、探す手間だけでなくチャット毎に整理ができ編集もラクなので便利です。 ※但し、デスクトップのショートカットやブラウザのお気に入りの方が便利な場合もあります 操作/手順の簡易マニュアル化 テストツールの操作やテスト手順は、頻繁に使うものは覚えているものの時々使うものは忘れがちです。そんな手順の一部を抜粋したりポイントを記載（簡易マニュアル化）しておくと、テスト実施時や依頼を受けた際の対応スピードがアップします。また、ExcelやWordの手順書は機能毎にファイルが分かれているケースが多いですが、必要な手順だけチャットに送信しておけばTeamsの検索機能でピンポイントで手順を見つけることもできます。 ※但し、複雑な手順は不向き（ExcelやWordの方が見やすい） メッセージの下書き 誰かにメッセージを送る前に内容を整理したり後で送信したい時など、下書き代わりに使用すると便利です。ファイルとは違い記載するだけで内容が維持されるのも良い点です。 端末間の情報共有 Microsoftアカウントは５つのデバイスまで登録可能なので、自分のアカウントでログインした　テスト用端末／事務用端末 のチャットを使って結果（スクリーンショット）を共有できます。今までは不具合チケット起票用のスクリーンショットをテスト用端末から社内メールを使って事務用端末に送付していたので、工程も時間も短縮されました。 注意事項 業務で使用する場合は、セキュリティ上の問題がないかご確認のうえ行って下さい。 上記で紹介したTeamsの便利機能は、他のコミュニケーションツールにも同等の機能があります。 　　例えば「Slack」でいうと以下になります。 - メッセージの保存機能 ⇒　メッセージのブックマーク機能 - 未読の確認機能 ⇒　［アクティビティ］＞未読メッセージ のトグルをON - 自分専用のチャット機能 ⇒　［ダイレクトメッセージ］＞自分の名前 (自分) チャット おわりに 今回紹介した機能は簡単に情報の見落とし防止や時短による効率アップが図れると思うので、 皆さんに活用してもらえたら嬉しいです。 以上、最後まで読んでいただきありがとうございました。 The post Teamsで業務効率UP！便利機能の紹介 first appeared on Sqripts .

本連載では、ここまで主に「1人目のQAがやるべきこと」について、経験ベースでお伝えしてきました。 今回は少し視点を変えて、1人目のQAがやるべきではないこと、アンチパターンについてご紹介したいと思います。 やるべきことは組織の状況などによって変化することもありますが、アンチパターンは状況によらずある程度共通する部分がある、と考えているためです。 本記事では、代表的なアンチパターンを4つ説明します。 ＜1人目QAとしての立ち回り　連載一覧＞ ※クリックで開きます 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 目の前のタスクに集中しすぎる 一つは、目の前のタスク、「すぐに実施できて達成感が得られそうなタスク」に集中しすぎてしまうことです。 とくに組織にJoinした直後のQAは、できる仕事がたくさんある状態だと思います。 そこで 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqripts でご紹介したように組織の現状把握をしつつタスクの取捨選択を行うわけですが、このときに個々のタスク、とくに達成感・「仕事をした感」が得やすいタスクを選び取りがちです。 たとえばリリース後に見つかる不具合が多い開発チームに入っていき、テスト設計・実行やリリース前の探索的テストに注力したとします。もちろんこれ自体は良いことです。しかし、そこでバグを見つけたり開発チームに感謝されたりしながら、1か月2か月と過ごしていったとして、それは1人目QAとしてのミッションに沿っているのでしょうか？ 会社として、問題のあるチームに入って立て直してほしいという狙いがあれば、動き方としては良さそうです。しかし、広く会社全体の品質保証のやり方を考えてほしい、といった狙いがある場合はどうでしょうか。 目の前のタスクを行って一定の成果が出ることは良いのですが、ついそこにハマってしまう危険もあります。1人目QAとして期待される動きや成果を考慮したうえで、場合によっては広く組織全体にアプローチするようなやり方が必要かもしれません。 得意なやり方、実績あるやり方に頼りすぎる なんらかの課題に対して、自分の得意なやり方や実績あるやり方を当てはめてしまうというのもよく目にするアンチパターンです。 テスト技術に自信がある、テストプロセスの整備の経験が豊富など、QAエンジニアそれぞれにはなんらかの得意なジャンルや手法があるかと思います。 そして、とくに入社直後のQAの場合は目に見える成果が欲しくなるため、つい自分の得意技で攻めようとしてしまいがちです。しかし、たとえばシステムテストの自動化が得意だからといって、なんでもかんでも自動化によって解決できるわけではありません。 必ずしも得意ではなかったとしても、今自分のいる組織にとって何が必要なのかを見定めるところからスタートするのが良いでしょう。結果として、やるべきことに対して自分のスキルが不足している場合には、社外の有識者を頼ることも一つの選択肢ですし、エンジニア部門のマネージャー等と協力しながら「経験はないけれどもチャレンジしてみる」こともできるかもしれません。 周囲のスムーズな理解を期待してしまう 1人目のQAと周囲の開発者やマネージャーとの間には、物事の見方・捉え方や知識の幅などに多くの違いがあります。とくに1人目として入社した直後のQAと、長く勤めているメンバーとではこの違いが顕著になるでしょう。 QAに限らず、そのロールの1人目として働く場合は「自分がどのような役割なのか」を周囲に理解してもらう必要があります。たとえば、1人目QAの方から「QA＝テストしてくれる人、という認識を持たれがち」といった話も伺います。これが誤解である場合、組織におけるQAの位置づけをもっと違ったものとして考えている場合は、適切に伝えていかなければなりません。 ところが、周囲の理解は簡単に得られるものではありません。QAとしての活動をわざわざ邪魔してくる人はいないかもしれませんが、誤解や無知（にQA側からは見える状態）などは必ず発生します。 そのため、開発者やマネージャーはQAのことを知っているはず、一度説明すれば理解してもらえるはず、といった「周囲のスムーズな理解」を期待するのは危険です。 QAの役割や関わり方など、なんらかの情報を組織の中に広めていくということは、思った以上に時間がかかることです。「簡単にはわかってもらえない」「伝わったと思っても伝わっていないことが多い」という前提を持ちつつ、しつこいくらいに伝え続ける動き方が1人目QAには求められます。 独力でなんとかしようとしてしまう QAかどうか、1人目かどうかに関わらず仕事全般に通じるアンチパターンですが、とくに1人目QAの方はハマりがちな傾向にあるように思います。 組織1人目のロールの場合、相談できる相手が居ないか、限られることが多いです。 かつ、1人目QA自身も「プロとして呼ばれてきたわけだから、相談しづらいな・・・」と感じてしまうのかもしれません。 いろいろな組織課題を独力で解決しようと考えても、多くの場合解決できないか、時間がかかりすぎてしまいます。それでは組織にとってもメリットがありません。 私自身1人目QAとして働いて感じたことは、品質への興味を持った方は少なくない、という点です。開発者の中にもテストをうまく・効率的に行いたいと考えている方はいますし、マネージャーの中にも品質向上のために試行錯誤した経験のある方が必ずいます。 そうした方々の取り組みや課題を拾い上げて一緒に解決していくことも、1人目のQAとしての価値です。「自分がなんとかする」という責任感もすばらしいですが、いったん脇に置いて「積極的に周りを巻き込んで一緒になんとかする」という考え方に変えてみるのもよいでしょう。 また、社内に相談相手がいない場合は社外を頼るという方法もあります。 昨今は（私も含めて）カジュアル面談プラットフォームなどを用いて「他社QAと情報交換しましょう！」という場を設けている方もたくさんいます。もちろん社内の情報の扱いには注意が必要ですが、純粋な技術課題・組織運営課題として抽象化したうえで社外の方と話をしてみる、経験談を聞いてみるのも有効です。 1対1の会話でなくとも、社外の勉強会やイベント等に参加して他社事例を聞くことも有効です。勉強会などで「今の自分が抱えている問題にピッタリはまるヒントは得られなかった」という方もいますが、私はそのような都合のよい機会はほぼないと考えています。 そうではなく、普段から勉強会やイベント等に参加をして情報を集めておき、いざ自分がなんらかの課題に直面したときに過去見聞きした情報からヒントを得るものです。 書籍や、Web上に公開されている資料なども含めた意味での「他人の知恵を借りる」ことは常に意識しておきたいですね。 1人だからとタスクや情報を抱え込まないのがポイント 今回は代表的な4つのアンチパターンをご紹介しました。 共通する点としては、1人だからといってタスクや情報を抱え込まないようにすべき、という点です。 1人目のQAは周囲から謎の存在になったり、あるいは「テストしてくれる人」のような固定イメージで見られたりすることがあります。そうならないためにも、自分がどのような役割を担いたいのかや何ができるのか、いま何をしているのかなどを常に発信していきましょう。 連載一覧 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 【第2回】組織に品質保証を浸透させるアプローチ 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 The post 【第5回】1人目QAアンチパターン first appeared on Sqripts .

金融、公共交通、電力、通信等の社会インフラを支える業界では、その業務に使用されるコンピュータシステムの信頼性を担保するために様々な法規制があります。   人の生命に直接関係するお薬や医療機器を製造する製薬・医療機器業界もその一つです。   本記事では初めて製薬・医療機器業界のコンピュータシステム導入・運用に携わる方々向けに、同業界に適用される法規制の一つである 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 .