テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 気をつけたい落とし穴(前編・形式面) ここまで、基本的な推論の形を取り上げて、その考え方を解説してきました。 今回と次回は、推論を読んだり組み立てたりする際に「気をつけたい落とし穴（誤謬）」に焦点を当てます。 今回は、各回でも説明した「形式面で気をつけたい落とし穴」のおさらいです。 まず前回クイズの解答から。 前回クイズ解答 問題(再掲) ISTQB Foundaton Level V4.0シラバスの記述を元にした主張があります（()内は章節番号）。 それぞれについて、形に着目して、妥当な（よい形の）主張かどうか、 前回 の説明を元に考えてください。 解答 問1。 媒介項「人間」は大前提①（全称肯定の主語）で周延されており、周延の規則①を守っています。 大名辞「エラーを犯す」は大前提①、結論③とも不周延。小名辞「開発者」は小前提②で全称の主語、③で特称の主語で、どちらも周延の規則②を守っています。 ①②③いずれも肯定であり、肯定と否定の規則③を守っています。 以上から、妥当な形です。ちなみに第1格のAAIという式です。 問2。 媒介項「欠陥」が①（特称の主語）、②（肯定の述語）ともに不周延であり、周延の規則①に反しています。 また、①②とも特称文ですから、全称と特称の規則①に反しています。 この2点から、非妥当な形です。 一見、意味内容は正しそうに見えるかも知れませんが、媒介項が①と②で同じ概念(の範囲)を指しているかどうか不明です。 媒介項には別の問題もあります。 ①では「欠陥」と言っているのに対し、②では「欠陥の原因」と言っています。両者は同じ概念と言えるでしょうか？ ちなみに第1格です。式の形はIIIになります(前述の理由から、すべての格で非妥当)。 問3。 媒介項「テスト」は①で周延されており（全称の主語）、周延の規則①を守っています。 大名辞「デバッグ」は①③で周延されています（否定の述語）。 小名辞「ホワイトボックステスト」は②③ともに「ホワイトボックステストの全体」（全称）と解釈できます。 大前提①が否定、結論③が否定で、肯定と否定の規則②を守っています。 以上から、妥当な形です。ちなみに第1格のEAEという式です。 問4。 媒介項「コミュニケーションの問題」は②で周延されており（全称の主語）、周延の規則①を守っています。 大名辞「リスク」は①③ともに不周延、小名辞「人の問題」は②③ともに不周延で、どちらも周延の規則②を守っています。 ①②③いずれも肯定であり、肯定と否定の規則③を守っています。 以上から、妥当な形です。ちなみに第3格のIAIという式です。 推論の形式で気をつけたい落とし穴 各回で説明してきた推論形式には、形式面で気をつけたい落とし穴(誤謬：ごびゅう)があります。 今回、復習を兼ねて一覧できるようにしました。 これらは、その推論形式の性質から 意味内容の真偽とは関係なく 「これは間違った推論」と言えてしまう誤りです。 いくら内容面では正しいと思えるとしても、形の上で問題があるものは筋道を損ねてしまっており、よい主張とは言えません。 “または”で気をつけたい落とし穴 “または”は包含的 論理の言葉としての“または”（選言。“入門編”では論理和(OR)として紹介)は、「PとQがともに真でも成り立つ」という性質を持っています。 参照 ・ 論理スキル[再]入門 [第3回] プログラムレベルのロジック(2)解説編・基本の論理演算 ・ 論理スキル[実践編]“または”を使って推論する この特徴から 包含的選言 などとも呼ばれます。 図8-1 “または”(論理和(OR))の真理値表 選言三段論法での誤謬 この性質から、選言肢の一方が真だからといって、他方が偽であるとは言えません。 図8-2は誤り です（PとQを入れ換えても同じ）。 （ 選言三段論法の回 では“タイプB”という本連載独自の呼称を使っています） 図8-2 選言三段論法の非妥当な形 （排他的な“または”なら誤りではないが） 日本語だと同じ“または”という語になりますが、 「P, Qどちらかが真だが、ともに真ということはない」「Pが真であるか(その場合Qは偽)、または、Qが真(その場合Pは偽)」 という場合を表す“または”があります。 これは“排他的選言”や“排他的論理和(Exclusive OR, XOR)”などと呼ばれます(図8-3)。 この意味の“または”である場合は、図8-2の形は正しくなります。 図8-3 排他的な“または”(排他的論理和, 排他的選言)の真理値表 （どちらでも正しいのはこちらの形） 選言三段論法 で、包含的選言でも排他的選言でも正しいのは、選言肢の一方を否定し、残る選言肢を結論とする形です（図8-4。PとQを入れ換えても同じ）。 （ 選言三段論法の回 では“タイプA”という本連載独自の呼称を使っています） 図8-4 選言三段論法の妥当な形 どちらの意味で使われているか、どちらに該当するのか、に気をつける 残念ながら、私たちが日ごろ使う言語では、どちらの選言かによって異なる言葉を使い分けるようにはなっていません。 文や主張の中に“または”が現れた場合は、どちらの意味なのかを選言肢の内容や文脈から判断する必要があります。 例。 ヨーロッパ向けの製品を担当するには、フランス語の知識か、またはドイツ語の知識が必要です。 フランス語の知識とドイツ語の知識を両方持っていても仕事の妨げにはならないでしょうから、この“または”は包含的な選言と解釈できます。 【非妥当】「担当しているミオさんはドイツ語ができるから、フランス語はできないかもね」 【妥当】「担当しているエマさんはドイツ語はできないそうだから、フランス語に堪能ということなんだろう」 両方の知識を持っている人は担当できないという条件がつくなら、【非妥当】の方も正しくなります（が、そういう条件にしている理由が気になりますよね……）。 例。 ハルトさんは、エマさんか、または、ミオさんのどちらかと結婚するだろう。 重婚を認めていない国/地域であれば、この“または”は排他的選言と解釈するのが自然でしょう。 【妥当】「ハルトさんはミオさんと結婚する。だから、ハルトさんはエマさんとは結婚しない」 “ならば”で気をつけたい落とし穴 “ならば”と逆・裏・対偶（何度でも確認しましょう） 条件法“ならば”と逆・裏・対偶のうち、 「PならばQ」が正しい(真である)時に正しいと言えるのは対偶「QでないならばPでない」のみ です。 参照 ・ 論理スキル[再]入門[第6回] 文レベルのロジック (2)条件・場合を表す言葉 図8-5 条件法と逆・裏・対偶 仮言三段論法での誤謬――前件否定と後件肯定 混合仮言三段論法 で、 「①PならばQ。②Q。③従って、P」は 「PならばQ」の「逆」 を、 「①PならばQ。②Pではない。③従って、Qではない」は 「PならばQ」の「裏」 を、それぞれ言っていることになります。 （前者が 後件肯定 の誤り、後者が 前件否定 の誤り） これは誰しもうっかり間違えてしまいがちな、陥りやすい「落とし穴」です。 森高千里というミュージシャン/シンガーのヒット曲に次の一節があります（発表は30年ほど前）。 私がオバさんになったら　あなたはオジさんよ 「私がオバさんになっても」作詞・森高千里 森高千里さんが2024年夏のライブ(野外フェス)に出演した際の写真が先日ネットに公開されたそうですが、往時から全然変わらぬお姿とか。 （参考： 別サイト(J-CASTニュース)の記事 ） その姿とこの歌詞から、 ①森高千里がオバさんになったならば、我々はオジさんである。 ②だが、森高千里はオバサンになっていない！ ③従って、我々はオジさんではない！！ という推論が成り立つ！　のでは！！　……と考えたくなりますが、残念ながらこれは前件否定です。 直感や願望、見た目のインパクトなどから、つい「わかりやすい」推論に飛びついてしまうというのは、ありがちなことです。 （論理的には、そして現実にも、森高千里さんがオバさんにならないからといって、男子がオジさんにならないとは限らないわけです） （ただし、逆と裏が成り立つ場合はある） “ならば”が、「PならばQ」と同時に「QならばP」を主張する 等値(同値)の“ならば”（双条件法） であるならば、元の主張が正しい時に逆や裏も正しくなります。 参照 ・ 論理スキル[再]入門[第6回] 文レベルのロジック (2)条件・場合を表す言葉 ・ 論理スキル[実践編]基本的な推論形式 図8-6 双条件法の働き(仮) 双条件法の例①。 ある数Xが1より大きい自然数で、かつ1と自分自身を除き約数を持たない時、そしてその場合に限り、Xを素数という。 用語や概念の定義では双条件法は重要な役割を果たします。なぜだと思いますか？ 双条件法の例②。 志望者がフランス語か、またはドイツ語の知識を持っている場合、そしてその場合に限って、ヨーロッパ向けの製品を担当することができる。 条件法の“ならば”の場合に対して、「ヨーロッパ向けの製品を担当できる条件」はどう違うでしょうか？ “ならば”の前後に気をつける 等値の“ならば”はそれと分かる言い回しなしに使われることもありますから、なおさら、前件と後件の意味内容とつながりには注意を払いましょう。 例。 「あの科目は、テストの結果が悪かったら単位は取れない。単位が取れなかったということは、テストの結果が悪かったんだ」 テストの得点だけが単位取得の評価項目なら、この“ならば”は等値(同値)の“ならば”であり、推論は正しいと言えます（例文では情報がないので、正しいと断言するのは早計です）。 他にも評価項目があるなら（出席回数/出席率など）、この推論は 後件肯定 の誤りです。 例。 「もしあなたがこの手紙を読んでいるなら、私は既に死んでいるということだ」 小説、映画、ドラマなどでしばしばお目にかかる場面ですが、 「あなた」がその手紙を読んだのに「私」が生きているということはなく、「私」が死んだ時のみ「あなた」の目に触れるのでしょうから、これは等値(同値)の“ならば”、双条件法と考えてよいでしょう（なので、ミステリーやスリラーでは、実は死んでおらず……という展開が活きるわけでしょうね）。 両刀論法でも気をつける 両刀論法 も“ならば”を用いた推論ですから、前件否定や後件肯定には気をつけましょう。 定言三段論法で気をつけたい落とし穴 前回 取り上げた形ですが、おさらいしましょう。 四個概念の誤謬 以外は、形から判断がつきます。 概念の数に関する誤謬 定言三段論法に4個(以上)の概念が登場してしまうと（ 四個概念の誤謬 。 媒概念曖昧の誤謬 などともいいます）、概念(名辞)どうしの関係がつけられず、正しい推論ができなくなります。 特に次のような場合に気をつけましょう。 使われている言葉の意味は明確か 「同じ言葉を同じ意味」で使っているか（文によって違った意味に解釈できることはないか） 「同じ概念には同じ言葉」を使っているか（文によって違った概念を指していると解釈できることはないか） （言葉の意味や使い方が揺らいでいないか、というのは、定言三段論法に限らず気をつけたいことでもあります） 周延に関する誤謬 媒介項Mが特称(主語の場合)か、または肯定(述語の場合)でしか現れていないなら、 媒介項不周延の誤謬 （周延の規則①の違反）です。 図8-7 媒介項不周延の例 大名辞不当周延の誤謬 、 小名辞不当周延の誤謬 （周延の規則②の違反）は、それぞれの名辞(概念)の全称/特称、肯定/否定に注意しましょう。 図8-8 大名辞不当周延、小名辞不当周延の例 肯定と否定の規則に関する誤謬 否定二前提の誤謬 (肯定と否定の規則①の違反)、 不当肯定の誤謬 (同②の違反)、 不当否定の誤謬 (同③の違反)は、全体の形を見ましょう。 図8-9 否定二前提の誤謬、不当肯定の誤謬、不当否定の例 次回 次回は、演繹的な推論に限らず、考えを組み立てたり述べたりする際に 意味内容の面で「気をつけたい落とし穴」 を取り上げます。 これまでで取り上げていない“落とし穴”がたくさん出てきます。お楽しみに。 参考文献 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 レイモンド・スマリヤン(著), 高橋昌一郎(監訳), 川辺治之(訳) 『記号論理学　一般化と記号化』 丸善出版 2013 鈴木美佐子 『論理的思考の技法Ⅰ〔第2版〕』法学書院 2013 弓削隆一, 佐々木昭則 『例解・論理学入門』 ミネルヴァ書房 2009 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 気をつけたい落とし穴(前編・形式面) The post 気をつけたい落とし穴(前編・形式面)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

はじめまして、QAコンサルタントのツルリンです。 2024年6月8日(土)に実施されました、第32回 初級ソフトウェア品質技術者 資格試験に合格することができましたので、合格体験記として、JCSQEに関する情報と受験に向けた私の取り組みをご紹介します。 これから初級ソフトウェア品質技術者 資格試験を受験する方のお役に立てれば幸いです。 受験の動機 QAコンサルティングに必要となるソフトウェア品質向上に関する包括的かつ体系的な知識修得のために受験しました。コンサルティング業務遂行や担当プロジェクトの成功においては、包括的かつ体系的なソフトウェア品質向上に関する知見を確立することが重要であり、最新の方法論やベストプラクティスに精通し、問題解決や品質管理において的確なアプローチを提供できる専門家となることが求められていると感じています。今回の受験を通じた知識修得が信頼できる相談相手としての地位を築くための基盤となると信じており、より深い専門性と専門知識を身につけることで、クライアントに対する価値提供を最大化するための一歩にできると考えて、受験しました。 JCSQEとは JCSQE （ソフトウェア品質技術者資格認定：JUSE Certified Software Quality Engineer）とは、すべてのソフトウェア技術者が品質技術を身につけ、実践していくことにより、ソフトウェア品質の向上を実現することを目的とした資格試験です。一般財団法人日本科学技術連盟（JUSE）が主催しており、初級試験は年2回（6月と11月）、中級試験は年1回（11月）、定期的に実施されています。 JCSQE ソフトウェア品質技術者資格認定 ソフトウェアの品質技術を高め、継続的・効果的に品質向上を目指すために、あなたのソフトウェア品質力を認定します。 　詳細はこちら　 JCSQE ソフトウェア品質技術者資格認定 関連情報 初級ソフトウェア品質技術者資格試験の概要 出題範囲：初級ソフトウェア品質技術者資格試験 シラバスVer.3.0に準拠 ※主参考図書『ソフトウェア品質知識体系ガイド ‐SQuBOK Guide‐第3版』 試験時間：60分 問題数：40問 出題形式：マークシート形式 合格ライン：70%程度 SQuBOK Guide について SQuBOK Guide （ソフトウェア品質知識体系ガイド：Software Quality Body of Knowledge）は、JCSQEの主参考図書になっています。 SQuBOK Guideにはソフトウェアの品質マネジメントや品質技術に関連する技法から、事例、関連文献、国際規格などが網羅的に整理されていて、ソフトウェア品質に関するトピックの全体像が把握でき、知識が整理できるようになっています。 初級ソフトウェア品質技術者資格試験 シラバスVer.3.0の項目は、SQuBOK Guide 第3版の目次と完全一致しています。 ソフトウェア品質知識体系ガイド （第3版） －SQuBOK Guide V3－ | Ohmsha 本書は、ソフトウェア、ITシステムの専門家である著者らが長年取り組んできたソフトウェアの品質について体系立てて整理し、簡潔に解説したものです。第1版発行から13年、第2版から6年が経過し、ソフトウェアを取り巻く環境は大きく変化しました。これを踏まえ、従来... 　詳細はこちら　 オーム社 関連情報 受験申込み 試験料 15,400円（税込） 最初に、受験地域を選んで申込みを行います。その後、受験可否の連絡があり、期限までに受験料を振り込んで、初めて受験登録完了となります。 受験地域は、宇都宮、東京、名古屋、大阪、福岡から選択できました。 会場定員の都合により、申込のタイミングによっては、受験できないことがあるため、上記のような流れになっているようです。早めに申し込む必要がありそうです。 受験準備・勉強方法 参考書籍と学習リソース JCSQEサイトの 学習方法 を参考に以下を使って勉強しました。 ソフトウェア品質知識体系ガイド － SQuBOK Guide － 第3版（約330ページ） 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】 過去の出題内容 初級ソフトウェア品質技術者資格試験 出題解説問題の一部が解説付きで公開されています。 また、上記に加えて、試験対策アプリ（テス友）も活用しました。 勉強方法と時間配分 勉強期間は、約2カ月でした。 【2か月前】 SQuBOK Guideを3週間くらいで一通り確認し、初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説も1週間くらいで全問を解きました。 【1か月前】 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】を4周しました。 過去の出題内容も記憶するレベルまで繰り返し確認しました。 テス友で朝10問・夜10問を目標に繰り返し回答しました。 【試験直前の1週間前～直前】 ラストスパートとして、問題集とテス友を中心に最終確認を行い、間違った問題、自信のない問題のポイント、解説などをA6サイズの手のひら大ノートに復習のために整理したり、メモしました。 【受験当日】 A6サイズの手のひら大ノートを試験会場に持参し、間違った問題を中心に試験開始直前まで確認しました。 気を付ける点 専門用語の定義がJCSQEと他の資格とで微妙に異なる部分がありますので、JCSQEの定義を正確に把握する必要があると感じました。 レビュー技法は、公式なものからカジュアルなものまで、多くの種類があり、試験では、目的、参加者、実施方法などの違いをかなり細かいレベルで問われますので、表形式でまとめるなど、整理しておく方が良いと思います。 試験は、SQuBOK Guideからの出題になりますが、SQuBOK Guideは300ページ以上あり、網羅的な記載で、重要ポイントも特に明示されていませんので、暗記するのは厳しいです。私は、問題集やテス友を繰り返して、既出問題を確実に得点できるように心掛けました。 受験当日の流れ・受験後の感想 試験会場、流れ、注意事項 試験は、大阪会場で受験しました。受験者は約50名でした。 試験会場には、試験開始40分前（9時50分）から入室可能でした。 開始10分前から試験終了までは退室できず、退室すると失格となります。 試験問題は持ち帰ることはできません。 試験終了後、配布された受験票控えに印刷されたQRコードからアンケートに回答します。（所属企業に関する情報や合格した場合、氏名掲載を希望するかなど） 実際の試験での難易度と感想 試験時間60分で、40問を回答する形になります。時間は十分にありました。 SQuBOK Guideから満遍なく出題されているように感じました。半分程度は問題集、過去の出題内容、テス友で解いた記憶のある問題であったように思います。 40問中、30問は自信あり、残り10問は確信がなく、再確認を行いましたが、8割以上は正解できたという感触で、それほど難しくはないと感じました。 合格発表・結果の確認方法 試験日：　6/8(土)10:30～11:30 合格発表：8/1(木)午前 受験地域別に合格者受験番号がWebサイトに掲載されます。 氏名掲載希望者は、氏名が掲載されます。 第32回結果：260名中、139名合格（合格率53.5%） 結果通知：8/5(月)午前（電子メール） 認定証到着：8/8(木) 試験結果のお知らせと資格認定証が送付されてきました。 試験結果のお知らせには、採点結果が記載されていました。90点でした。 まとめ 今回の私の受験の取り組みをまとめると以下のようになります。 SQuBOK Guideで、ソフトウェア品質の全体像を把握する。 問題集、テス友を繰り返して、記憶として定着させる。 間違った問題は、ノートに書き出して、同じ間違いをしないように復習を行う。 また、余裕があれば、再度、SQuBOK Guideを確認することで、試験問題とSQuBOK Guideの内容がつながって、更に理解が促進されると思います。 今回の初級ソフトウェア品質技術者 資格取得を通じて、SQuBOK Guideを何度も確認することで、ソフトウェア品質の全体像を体系的に把握できたことが一番の成果であったと感じました。 是非、機会があれば、中級ソフトウェア品質技術者資格試験にもチャレンジしてみたいと思います。 The post 初級ソフトウェア品質技術者 資格試験(JCSQE)の受験体験記 first appeared on Sqripts .

以前の連載である 1人目QAとしての立ち回り では、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。 今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 初回である今回は、連載全体で対象とする部分の概要とQA組織を立ち上げる際の流れ、序盤に考えることになる「QA組織の形」について見ていきます。 QA組織を立ち上げる際の流れ QA組織の形について考える前に、まずはQA組織を立ち上げる前後の流れについて整理してみましょう。業種や開発組織の規模などによっても異なりますが、ここ最近筆者がみるのは以下のような流れです。 1人目QA採用フェーズ 立ち上げフェーズ 組織化・拡大フェーズ その後 順に概要を説明します。 1. 1人目QA採用フェーズ その名の通り、これまで組織にいなかったQAエンジニアを新たに採用するフェーズです。採用される側のQAエンジニア個人としてはこのタイミングでできることは基本的になく、開発部門のトップやCTO、個々の開発者などががんばる段階です。 この段階にある各社さんは、 QAエンジニアのイベントに顔を出し、交流する カジュアル面談で外部のQAに話を聞く 他社のQAに副業として支援やアドバイスを受ける など、さまざまな工夫をしながら情報を集め、採用を目指しています。 2. 立ち上げフェーズ 1人目のQAエンジニアが無事採用できたら、立ち上げフェーズになります。参画した1人目QAを中心として組織を作っていく段階です。 この段階において、1人目QAにはさまざまな役割があります。 大きくは 組織づくり と 品質向上のための活動 です。 QAエンジニアを採用したということは、開発組織としてなんらかの狙いがあります。障害が多くて困っているなど急ぎの課題を抱えている場合もあれば、今は問題ないけれど組織の今後を考えていまのうちに・・・という場合もあります。 いずれにせよ、1人目QAには開発組織内に向けたなんらかの活動と成果が求められます。これは当然ですね。このような活動を総称して、ここでは 品質向上のための活動 と呼ぶことにします。 また並行してQA 組織づくり に対しても貢献が求められます。実際に私も1人目QAとしての業務を始めた当初は、むしろこちらの割合が多いくらいでした。2人目以降の採用のため、募集要項を作成や、会社の状況や開発組織のようすなどを積極的に社外に発信したりしました。 3. 組織化・拡大フェーズ 組織化・拡大フェーズは、QAエンジニアの採用が進み、複数人のチームで動き始めている段階です。 社内に複数の開発チームが存在する場合にはQAエンジニアがそれぞれ担当を持つなど、このあと触れる開発組織とQAとの関わり方・組織パターンがわかれてきます。 4. その後 3の組織化・拡大フェーズまでの流れはある程度各社さん共通になるかと思います。しかしこの先は組織の形や規模、プロダクトの特性などに応じてさまざまな方向に分かれます。 たとえば開発組織がそれほど大きくない場合は「しばらくQAは今の体制でいこう」といった、いったん拡大をストップしてメンバーの中でできるQA活動に注力する選択もあるでしょう。 一方で規模の大きな組織、プロダクトが大きかったり、複数のプロダクトがあったりする場合には「採用して育てる」という方針をとる会社もあります。この場合は、自社内でジュニアなQAエンジニアを育てるための教育コンテンツ整備やグレード設定・評価の仕組み作りなどもQAエンジニアが担うことになります。 ここまでの内容を図にしたものが以下です。 QA組織のフェーズと活動の例 以前の連載である「 1人目QAとしての立ち回り 」は、 2. 立ち上げフェーズ における 品質向上のための活動 が主な範囲でした。 今回の連載では、主に 2. 立ち上げフェーズ 3. 組織化・拡大フェーズ における、組織づくりの面を対象とします。 QA組織の形を考える ここからは、QA組織を立ち上げる際に考えるべきポイントのひとつである、組織の形について説明します。 QA組織を立ち上げよう！と考えたときに、いきなり採用を始めるわけにはいきません。もちろん、優秀なエンジニアの採用が困難な昨今、採用活動を始めるのは早い方が良いですが、単純に複数人がいればQA組織になるわけではありません。 開発組織や会社におけるQAの立ち位置や、将来的にQA組織が何を担おうとしているのかがまず先にあって、それに応じた最適な（と思われる）組織の形があるはずです。 QA組織の形は会社や開発組織によってさまざまなものが考えられ、単一の正解はありません。自組織にとって最も良い形を模索していくことになるでしょう。 なにもないところから最適な形を考えるのは難しいため、ヒントとなる考え方を2つ、ご紹介します。 組織の形を考えるヒント：QMファンネル 1つ目は QMファンネル（3D版） です。 しばしばQAと一括りにされる、テストエンジニアとSETとQAを整理してバランスをよくするための「QMファンネル（3D版）」 QMファンネル（3D版） として、上記の資料中では説明されています。 QAエンジニアが3つ（テストエンジニア、パイプラインエンジニア、QAエンジニア）のスペシャリティに分かれており、それぞれについて5つのロール（スプリット、インプロセス、コーチ、コンサルタント、プロモーター）が存在します。 組織の形を考えるにあたって、これらのスペシャリティ×ロールをどのような構成にするのかを検討するとよいでしょう。 資料中では「ダメなロールバランスのTE組織の例」として、ロールのバランスが悪いパターンについても例示されており、こちらも見ておくと失敗を避ける役に立ちます。 ダメなロールバランスのTE組織の例(2) 斧を研がない木こり QMファンネル（3D版） より 組織の形を考えるヒント：QA組織パターン 2つ目は、このSqriptsでも連載中の 藤原 大 さんが公開している QA組織パターン – 構造ごとのメリットデメリットまとめ です。 こちらの資料では、開発チームとQAチームがどのような関係性・人の構成になっているかのパターンが6つ紹介されています。 たとえば私が現在の組織で目指しているのは、「QA組織横断組織体制（アサイン型2）」に近いものになります。 QA横断組織体制（アサイン型2） QA組織パターン – 構造ごとのメリットデメリットまとめ より このパターンでは横断組織としてのQA組織があり、そこに属するQAエンジニアがそれぞれ担当の開発チームを持つスタイルです。まだまだ組織を作っている最中なのでこの形は実現できてはいませんが、いずれは、と考えています。 このように、理想とする組織の形について検討しておくことは、採用のうえでもQA活動を行って組織にさまざまなものを浸透させていくうえでも大切です。 組織の形を考える過程では、QAチームのミッションや開発チームへの関わり方などについてもあわせて検討する必要が出てきます。たとえば開発チーム複数に対してQAが1名だとすると、内部に入り込んでのQA活動を行うのは限界があります。したがって、外から開発組織にアプローチするような動き方がメインになるでしょう。 このような開発組織へのアプローチについては、以前の記事 【第2回】組織に品質保証を浸透させるアプローチ | Sqripts にて触れていますので、こちらもご覧ください。 【第2回】組織に品質保証を浸透させるアプローチ 前回の記事では、1人目QAとは何かや1人目QAに求められているもの、そして1人目QAとしてJoinした後の立ち回りなどについて説明しました。今回は1人目QAが実際に組織の中で「品質保証」を浸透させる際のアプローチについて説明します。1人目QAの役割である「品質文化の... 　続きを読む　 Sqripts 関連記事｜Sqripts まとめ 今回は、主に1人目QAがJoinする前後の流れや、QA組織の形などについて説明しました。 1人目QAを採用する前からこういった内容が検討できるとベターですが、基本的には1人目として採用されたQAエンジニアが主体となって考えていくことになるでしょう。とくに組織の形については決まった正解がなく、悩むことも多いかもしれません。本記事でご紹介したヒント等を頼りに検討してみてください。 次回からは、 2人目以降のQAを採用する際の考え方 QA組織のチームビルディング QAとして、チームとしてのキャリアの作り方 教育や評価 など、チームを作るうえでのポイントについて幅広く触れる予定です。 【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方 ​「1人目QA」というワードを、2020年ごろからよく聞くようになりました。​もちろんそれ以前から、組織の中で1人目のQAとして活動をされてきた方はたくさんいました。しかし、QAエンジニアという職種の認知が広まったことで「いままでQA専門の人は居なかったけど、ウ... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 【第1回】QA組織立ち上げの流れと組織の形 first appeared on Sqripts .

AIの世界では、ChatGPTをはじめとする生成系AIが広がり、テキスト生成モデルである大規模言語モデル（LLM）の仕事での利用も増えています。 今回紹介するオープンモデルLLMは、AI技術の発展において重要な役割を果たしています。ChatGPTのようなクローズドなLLMモデルは高性能ですが、LLMを活用したツール作成や検証などの研究目的での利用にはコスト面の課題があります。オープンモデルLLMは 無料で利用できるため、スタートアップや予算の限られたプロジェクトなどでも、柔軟に対応できる点が評価されています。また、Google Colabを使えば高性能な環境を用意せずにオープンモデルLLMを試せます。 この記事では、GPT-3やGPT-4に比べてコンパクトながら高性能な、GoogleのオープンモデルLLM「Gemma」をGoogle Colabで使用する方法を解説します。 オープンモデルLLM「Gemma」とは Gemmaの概要 Gemma は、Googleが開発した軽量で最先端のオープン型大規模言語モデル（LLM）です。Google DeepMindとGoogleの他のチームによって開発され、ラテン語で「宝石」を意味する名前が付けられています。また、Googleは2024年6月に「Gemma」の新バージョンGemma 2をリリースしました。 特徴とメリット オープンモデル : Gemmaは誰でも自由にダウンロードして利用できるオープンモデルです。 軽量: 「Gemma2 2B」「Gemma2 9B」「Gemma2 27B」の3つのサイズがあり、なかでも「Gemma2 2B」は軽量でありながら高性能を実現しており、モバイルデバイスや組み込みシステムでの活用が期待できます。 商用利用可能 : 利用規約に同意すれば、Apache License 2.0のもとで商用利用が可能です。 コスト効率 : 無料で利用できるため、スタートアップや予算の限られた組織にとってアクセスしやすいです。 幅広い利用可能性 : Google Colabなど、さまざまな環境で実行可能で、手軽に利用できる環境が整っています。 安全性 : 学習データから特定の個人情報や機密データを除外しており、安全性が高いです。 高いパフォーマンス : 主要なベンチマークで高い性能を発揮しています。 Google Colab環境の準備 それでは、Gemmaを動かす環境であるGoogle Colabについて説明します。 Google Colabについて Colab（正式名称「Colaboratory」）では、ブラウザ上で Python を記述・実行できます。Colab には、AIなど重い処理を高速に実行できるGPUが使用でき、しかも無料で使えます。特徴としては、以下の点があります。 環境構築がほぼ不要 簡単に操作が可能 無料でGPUが使用できる 共有が簡単にできる 注意点 便利なGoogle Colabですが、無料プランは次のような制限があります。 90分何も操作しないとリセットされる インスタンス起動してから12時間経つとリセットされる GPUを使いすぎると、しばらくGPUを使えなくなる（CPUは使用可能） 有料プランにすることで、上記を制限なく使うことができます。また、より速いGPUが使えたり、より多くのメモリを使えたりするメリットもあります。無料プランで物足りない場合は、検討してみても良いでしょう。また、Google Colabを使用するにあたり、APIキーやパスワードのような機密情報を扱う際には、コードに直接埋め込むことは推奨されません。秘匿情報を安全に扱うために「シークレット機能」を使いましょう。具体的な使い方は、後ほど説明します。 事前準備 早速、Google Colab を使っていきましょう。まずは、Gemmaを動かすための新規のノートブック(作業する場所)を作成するところから解説します。 Google アカウントにログインした上で、以下の公式サイトにアクセスしてください。 https://colab.google/ [New Notebook]をクリックして、新規のノートブック(作業する場所)を作成します。 すると、このような画面が表示されます。 新規のノートブックの[編集]-[ノートブックの設定]を選択し、ハードウェア アクセラレータで、「T4 GPU」を選択します。「CPU」のままでGemmaを動かすと、処理スピードが非常に遅いので、必ず変更してください。 Gemmaを利用するために、KaggleでAPI Tokenが必要です。まずは、以下のサイトにアクセスし、[Request Access]を押下して、Kaggleに登録して、Gemma利用規約に同意してください。 https://www.kaggle.com/models/google/gemma/ 以下のように表示されれば登録完了です。 次に、API Tokenを生成します。アカウント設定ページにアクセスして、[API]のセクションで「Create New API Token」をクリックします。ダウンロードしたjsonファイルに、usernameとkey(API Token)が記載されています。これは、後ほど使用します。 これで事前準備は完了です。 Gemmaのセットアップ手順 それでは、早速Gemmaを動かしてみましょう。 Gemma in PyTorch に記載されている情報を参考に、実行していきます。 まずは、先ほど入手したusernameとkey(API Token)を、「シークレット」に登録します。「新しいシークレットを追加」を押下して、KAGGLE_USERNAMEと、KAGGLE_KEYを追加、usernameとkey(API Token)をそれぞれの値の部分に入力します。 次にシークレットの情報をプログラムで読み込みます。 [+コード]を押下して、次のプログラムコードを入力します。全て入力が終わったら、「Shift + Enter」を押します。これにより、先ほど入力したセルのプログラムを実行して次のセルが選択されます。（以後、プログラムコードの実行は全て「Shift + Enter」で行います。） import os from google.colab import userdata # `userdata` is a Colab API. os.environ["KAGGLE_USERNAME"] = userdata.get('KAGGLE_USERNAME') os.environ["KAGGLE_KEY"] = userdata.get('KAGGLE_KEY') これで、KAGGLE_USERNAMEとKAGGLE_KEYをプログラム中で使用できます。プログラム中に直接usernameとkey(API Token)を記載すると、セキュリティ的に良くないので、シークレット機能を活用してください。 次にGemmaを動かすのに必要な各種ライブラリをインストールします。 !pip install -q -U torch immutabledict sentencepiece モデルの重みをダウンロードします。 ここでは、Gemma2 2Bモデルの指示用調整（IT）「2b-it」を選択しています。9Bや27Bモデルは、無料のGoogle Colabでは、メモリの関係で動かせませんでした。 # Choose variant and machine type VARIANT = '2b-it' #@param ['2b', '2b-it', '9b', '9b-it', '27b', '27b-it'] MACHINE_TYPE = 'cuda' #@param ['cuda', 'cpu'] CONFIG = VARIANT[:2] if CONFIG == '2b': CONFIG = '2b-v2' import os import kagglehub # Load model weights weights_dir = kagglehub.model_download(f'google/gemma-2/pyTorch/gemma-2-{VARIANT}') # Ensure that the tokenizer is present tokenizer_path = os.path.join(weights_dir, 'tokenizer.model') assert os.path.isfile(tokenizer_path), 'Tokenizer not found!' # Ensure that the checkpoint is present ckpt_path = os.path.join(weights_dir, f'model.ckpt') assert os.path.isfile(ckpt_path), 'PyTorch checkpoint not found!' モデル実装をダウンロードします # NOTE: The "installation" is just cloning the repo. !git clone <https://github.com/google/gemma_pytorch.git> import sys sys.path.append('gemma_pytorch') from gemma.config import GemmaConfig, get_model_config from gemma.model import GemmaForCausalLM from gemma.tokenizer import Tokenizer import contextlib import os import torch モデルをセットアップします # Set up model config. model_config = get_model_config(CONFIG) model_config.tokenizer = tokenizer_path model_config.quant = 'quant' in VARIANT # Instantiate the model and load the weights. torch.set_default_dtype(model_config.get_dtype()) device = torch.device(MACHINE_TYPE) model = GemmaForCausalLM(model_config) model.load_weights(ckpt_path) model = model.to(device).eval() サンプルテストの実行 具体的なプロンプト（LLMに対する命令）を入力し、その応答を確認してみましょう。 Wikipediaの「人工知能」 の冒頭の解説文章を要約させてみます。 ※以下では、文章を途中省略していますが、実際に実行する際は、Wikipediaの文章を入力しています。 prompt = """ 次の文章を100文字に要約してください。 人工知能（じんこうちのう、英: artificial intelligence）、AI（エーアイ）とは、「『計算（computation）』という概念と『コンピュータ（computer）』という道具を用いて『知能』を研究する計算機科学（computer science）の一分野」を指す語]。 （中略） 「われわれは少し先までしか分からないが、多くのやるべきことが残っているのは分かる」。 """.strip() # Generate sample model.generate( prompt, device=device, output_len=4096, ) 要約結果は次のようになりました。 Gemma2の出力 AIの発展が非常に急速な進歩を遂げている一方で、今後さらに発展する可能性は十分にあり、その将来の進化をどのように予測するのかについては、まだ明確な答えは見つかっていない。 <end_of_turn> ChatGPT-4oとの比較 大規模な商用モデルであるChatGPT-4oと比較してみました。 ChatGPT-4oの出力 人工知能（AI）は、計算機を用いて知能を研究する計算機科学の分野であり、言語理解や推論などをコンピュータで実行させる技術である。AIは歴史的に大きく発展してきたが、未来に向けてさらなる課題が残っている。 Gemma2とChatGPT-4oの出力結果を比較すると、どちらも要約の質は非常に高く、甲乙つけがたいと言えます。どちらも程よくまとまっており、ユーザーにとって有益な情報を提供しています。ただし、処理速度に関してはChatGPT-4oが圧倒的に優れており、これは使用しているマシンスペックの違いによるものと思われます。どちらのモデルもそれぞれの強みを持っており、用途に応じて使い分けることで、より効果的にAIを活用することができます。 Colab上のGemma2：3分 ChatGPT-4o：5秒 実務に利用できるか さて、簡単に動かすことができたGemmaですが、実務に使えるかどうか、考えてみましょう。オープンモデルLLMであることから、次のようなシチュエーションで有益ではないでしょうか？ 運用におけるコスト削減したい、低コストで試験的に導入したい セキュリティが厳しい環境でも社内データをLLMで活用したい 特定ドメインにおける自動化、効率化を図ったり、社内サーバーで安定して運用したい 社内のドキュメントを簡単に要約したい ただ、課題がないわけではありません。 パフォーマンス 商用のLLMに比べ、OSSモデルのパフォーマンスはやや劣る場合が多いです。特に、生成タスク（クリエイティブな文章作成やコード生成など）では、商用モデルの方がより洗練された結果となります。 スケーラビリティ 大規模なOSS LLMを実務環境に導入するには、計算リソースが必要となり、その運用コストがかさむ場合があります。また、OSS LLMのモデルは商用モデルと比べて最適化されていないことが多く、パフォーマンスのチューニングが必要となってきます。 特定分野への適用 OSSモデルは一般的なデータで訓練されていることが多く、特定の業務ドメイン（例えば法務や医療）に対する特化はされていません。そのため、専門的なドメインに適応させるには追加のデータセットとトレーニングが必要です。一方、クローズドなモデルでは、特定のドメインに対応するよう事前に最適化されている場合が多く、専用のトレーニングデータやパラメータ調整が行われているため、特定分野への迅速な適応が可能です。これにより、企業や専門機関は必要なセキュリティやプライバシー保護を維持しつつ、高精度なモデルを利用できるメリットがあります。 まとめ 本ブログでは、Google Colabを利用してGemmaを実行することで、誰でも簡単に高度なAI技術を試すことができることが、確認できました。Gemmaに加え、Llama3やBLOOMなど多くのオープンソースLLMが存在し、それぞれの特徴と強みを活かして、AI活用の幅広い選択肢が提供されています。 AI技術の進化により、誰でも高性能なAIを手軽に利用できる時代が到来しました。技術の民主化が進み、個人や中小企業でもAIを活用したサービスやツールを簡単に開発・利用できるようになっています。弊社でも、AIを活用したサービスとして「AIテクニカルコードレビュー」や「AIデバッグ」を提供しており、これらのサービスは開発プロセスの効率化と品質向上に大いに貢献しています。今後もAI技術の進化に伴い、さらに多様なサービスが登場し、私たちの生活やビジネスに新たな可能性をもたらすことが期待されます。 ▼関連記事はこちら AIを使ってコードレビューをやってみた ｜Sqripts AIの目で見るバグの世界 ｜Sqripts The post Googleの作ったオープンモデルLLM「Gemma」をGoogle Colabで使ってみる first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ 第3回目のテーマは、1on1においてコミュニケーション方法を使い分けるために「コミュニケーションのタイプ」を学びます。 前回のおさらい 前回はコミュニケーションの方法について解説しました。 コンサルティング ティーチング（トレーニング・メンタリング） カウンセリング ファシリテーション コーチング 1on1 それぞれ特徴があり、使い分けができることがわかりました。 今回はこれらの方法の使い分け方を解説します。 コミュニケーション相手別の使い分け 私はアジャイルコーチとして働いていますが、コーチングだけでなくコンサルティング（可能な限り現段階でのベストプラクティスを提供する仕事）も行っています。 たとえば、ITに詳しくない方や、新卒で社会人になったばかりの方に対しては、コンサルティングやティーチングが有効です。なぜなら、まだ知らないことが多いため、課題と解決策の間に大きなギャップがあり、なかなかゴールにたどり着けない状況になりがちだからです。 逆にCTOやエンジニアリングマネージャなど、相手のITスキルが高い方の場合はどうでしょうか？ 彼らは私に負けない知識や経験を持っている可能性があります。下手をすれば私より詳しいかもしれません。あるいは、知識や経験がなくても、それを身につけるポテンシャルを持っているかもしれません。この場合、コンサルティングやティーチングによって、学べる機会を奪ってしまう可能性もあります。 そういった人たちに「コンサルティング」や「ティーチング」は有効に機能しません。 こういった問題を避けるために、 相手や課題の領域によって、コミュニケーション方法を変えていく必要があります。 コミュニケーション方法の使い分け コミュニケーション方法の変化についてまとめたのが上記の図です。代表的な3つの方法をベースに解説します。 まず、コンサルティングは解決策を伝える方法なので、未経験者やすぐに解決策が欲しい人に対して有効な手段です。デメリットをあえてあげるなら、学ぶ機会が失われます。 次に、ティーチングやトレーニングは、新しい方法やスキルを学ぶ効果的な手段です。残念ながら、誰でも有効的に学びを得られるわけではなく、学べばスキルを身につけられる人にマッチする方法と言えます。参加するだけでは得られないことも多く、学ぶ姿勢や学びをのちに活用できるスキルが必要です。 最後のコーチングは、相手の中に答えがあるのが前提となるため、あくまで相手が答えを見つけるための支援を行う方法です。支援と入っても、助けるのではなく、一緒に答えを見つけていく伴走型の方法になります。よって、未経験者にコーチするよりも、経験者や自律して考えられる人に対して行うケースが多くなります。 このように、相手の経験やスキルによって、コミュニケーション方法を使い分けて対応していくのが効果的です。相手が求めるものに対して、適切な方法を選ぶのがプロフェッショナルなコミュニケーションの使い手と言えます。 余談ですが、前回でも解説した通り、1on1はコミュニケーション方法を、相手や状況に合わせて使い分けるコミュニケーション方法です。よって、最低限でも上記3つの方法を理解し使いこなせるようになる必要があり、相手や状況に合わせてうまく切り替えながら、クライアント（部下）に成果を出させなければなりません。 さまざまな方法を知るだけでなく、成果も出さなければならないのが1on1が難しい理由のひとつだと思います。 コミュニケーションタイプ別の使い分け 相手の経験やスキルによって、コミュニケーション方法を使い分ける必要性を解説しました。もうひとつ考えておきたいことがあります。それは、コミュニケーションのタイプです。 コミュニケーションのタイプについては、有名なもののひとつにDiSC理論（参考： DISC assessment ‐ Wikipedia ）があります。これはアメリカの学者が提唱したコミュニケーション理論で、おおきく4つのタイプに分類しています。 支配タイプ （D: Dominance）は、問題を克服するために、積極的に力を利用するタイプです。いわゆる従来型のリーダータイプで、チャレンジ精神が旺盛で、成果を追い求める傾向があります。 感化タイプ （i: influence）は、問題を解決するために、人をうまく操るタイプです。持ち前の社交性を活用しながら場の雰囲気を読み取り、着地点をうまく見つけるスキルが高いタイプと言えます。 提案タイプ （S: Submission）は、問題解決のアイデアを受け入れ、決まったことに対しては従順に遂行していくタイプです。協調性が高いため、コミュニケーション相手の立場に立って物事を考えてくれるタイプと言えます。 コンプライアンスタイプ （C: Compliance）は、ロジカルに物事を考えるタイプです。計画を重視し、法令や規則、ルールを厳守します。少し堅いイメージがありますが、慎重に物事を進めてくれる安心感があるタイプと言えます。 血液型占いと同じく、すべての人類が4つのタイプに分けられるわけではないですが、大きく分類することで、それぞれの特徴に合わせたコミュニケーション方法を考えられます。それぞれのタイプ別のコミュニケーションを見てみましょう。 支配タイプへのコミュニケーション 支配タイプは、ぐいぐい進むリーダータイプです。遠回しな表現よりも、単刀直入なコミュニケーションを好む傾向があります。 支配タイプは、細かい点を気にしないので、アクションをゼロから考えるよりも、選択肢をいくつか提示して議論したほうが物事が進みやすくなります。内容が曖昧だと「つまりどういうこと？」となりがちなので、解像度の低いものを持ち込むより、精度が高めのものを持ち込む方が良いでしょう。 支配タイプに何かを伝えたいときはどうするのがよいのでしょうか？ たとえば、細かい点を気にしないので、要点だけを伝える方法があると思います。また、誰かに指示されるよりも自分でリードしたいため、「まかせる」と裁量を大きく与えるのもひとつの手でしょう。 感化タイプへのコミュニケーション 社交性の高い感化タイプは、時代や流行にも敏感で、アイデアをどんどん出していくコミュニケーションを得意としています。よって、相手が出してくる情報をどんどん承認すると（頷いたり関心を持つ）、パフォーマンスが上がっていく可能性があります。 何事もポジティブに受け止めてくれる感化タイプですが、逆に細かい点が苦手なので、支配型から見ると「よくしゃべるけど、結局何がしたいの？」となりがちです。また、細かい点を議論するより、広い視点での議論のほうが盛り上がります。 感化タイプに何かを伝えたいときはどうするのがよいのでしょうか？ 影響力を気にするタイプなので、先にも書きましたが承認を多く行うことが効果的です。いわゆる褒めて伸びるタイプと言えます。逆に、人前で怒られるのが苦手なので、悪いフィードバックは個別に伝え、今後への期待も添えて伝えるといいでしょう。 提案タイプへのコミュニケーション 協調性の高い提案タイプは、衝突をできるだけ避けて物事をすすめるのが得意です。聞くのが上手なので、感化タイプとの相性はとても良いでしょう。 物事を平穏に進めるスキルは高いと言えますが、ディスカッションやディベートといった議論をぶつけるやりとりが苦手です。安定性を求める傾向があるので、チャレンジングな支配タイプが苦手になるかもしれません。 提案タイプに何かを伝えたいときはどうするのがよいのでしょうか？ 協調性の高さから自分の意見が言えていない可能性があるので、何かを決める場合、じっくり何回も確認するのが良いでしょう。相手のことを感じ取る能力に優れているため、こちらからも積極的に言葉をかけたり、しっかり反応したりするふるまいがマッチします。 コンプライアンスタイプへのコミュニケーション コンプライアンスタイプは、計画性が高く、正確に物事を進めるのが得意です。じっくり作戦を練り、確実に成功する方法を選ぼうとします。 逆に言うと変化に弱いと言えます。頭で理解できないと前に進めない傾向もあり、チャレンジングに進めようとする支配タイプとの相性は悪いかもしれません。 コンプライアンスタイプに何かを伝えたいときはどうするのがよいのでしょうか？ 曖昧な言葉を使うより、具体的な言葉を使ったほうが伝わるでしょう。感覚に任せて話すより、ロジカルにロジックを積み上げるほうが共感されます。すぐに結論を出すのが苦手なので、関連するデータや事例を集めて提示するほうが納得感を持ってくれるでしょう。 ＊ 今回は、具体的なコミュニケーションの使い分け方法を解説しました。経験やスキルに合わせて方法を変えたり、相手のタイプによって使い分ける方法を紹介しました。 コミュニケーションタイプの分類は、今回紹介したDiSC理論だけでなく、いろんなものが存在します。 【図解】「タイプ分け 」とは 〜あなたはどのタイプ？タイプ分けで上手くいくコミュニケーション – HELLO, Coaching! あなたは何タイプ？コミュニケーション上手になるための4タイプ診断法 – リクナビNEXTジャーナル 相手だけでなく自分のタイプを見分けることにも利用できます。自分のタイプが分かると、苦手なタイプが分かり、対策を打ちやすくなるからです。 次回は実践例を参考に1on1のレベルを高めていきましょう。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ The post 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ first appeared on Sqripts .

こんにちは、AGESTのバックエンドエンジニアのまさです。 今回は、CursorエディタのComposer機能を用いて、AIにテストコードを記述してもらう方法をご紹介します。テストコードはソフトウェアの品質を高めるために重要ですが、手作業で書くのは時間がかかるものです。そこで、AIの力を借りて効率的にテストコードを生成してみましょう。 具体的な手順やコード例を交えながら、詳しく解説していきます。 ※今回ご紹介するCursor Composerは現時点ではPro版でないと使用できないようですので、その点だけご注意ください。なお、Free版には2週間のPro版トライアルがついています。 【参考】 Cursor Pricing（価格表） Cursorエディタとは Cursorは、VSCodeをフォークしたAI活用型の新しいコードエディタです。VSCodeユーザーであれば、馴染みのあるインターフェースと操作性で、移行しても違和感なく利用できます。コード補完機能やリファクタリング支援など、開発者の生産性を向上させるための機能が豊富に備わっています。Composer機能を使うことで、コード全体の分析やコードの自動生成が可能です。 環境構築 Cursorのインストール まずは、公式サイトからCursorをダウンロードし、インストールします。 Cursor公式サイト インストール後、Cursorを起動します。 Cursor起動後、ユーザー設定 > Cursor Settingsを開きます。 設定メニュー内の「Features」内のComposerをenabledに設定します。 プロジェクトの準備 テスト対象のコードを用意します。ここでは、Go言語を使用した例を示しますが、他の言語でも同様の手順で進められます。 example/ ├── main.go └── utils/ 　　　 ├── example.go 　　　 └── item.go テスト対象のコード作成 まずはテストに使用する構造体を utils/item.go に実装します。 package utils // Item構造体を定義します type Item struct { ID int // アイテムのID Name string // アイテムの名前 Price int // アイテムの価格 } 次にテスト対象となる関数を utils/example.go に実装します。 // utilsパッケージに含まれるユーティリティ関数を定義します package utils // ItemsTotalPriceは、与えられたItemスライスの合計価格を計算します func ItemsTotalPrice(items []Item) int { total := 0 // 合計価格を初期化 // 各アイテムの価格を合計に加算 for _, item := range items { total += item.Price } return total // 合計価格を返却 } Composer機能を使ったテストコードの自動生成 テストコードを生成する手順 example.go ファイルをCursorで開きます。 Ctrl + i をキー入力します。 CursorのComposerの入力画面が表示されます。 入力ファイルの「+」を押下し、item.goを追加します。 プロンプトに「ItemsTotalPriceに対するテストコードを作成してください。」と入力します。 ComposerがAIを利用してテストコードを生成します。 生成されたテストコードの確認 自動生成されたテストコードは以下のようになりました。 import ( "testing" ) /** * TestItemsTotalPrice は ItemsTotalPrice 関数のテストを行います。 * * このテストでは、以下のケースを確認します： * 1. 空のスライスの場合 * 2. 1つのアイテムを含むスライスの場合 * 3. 複数のアイテムを含むスライスの場合 * * @param t *testing.T テストを実行するためのテストオブジェクト */ func TestItemsTotalPrice(t *testing.T) { // テストケースを定義 testCases := []struct { name string items []Item expected int }{ { name: "空のスライス", items: []Item{}, expected: 0, }, { name: "1つのアイテム", items: []Item{ {ID: 1, Name: "アイテム1", Price: 100}, }, expected: 100, }, { name: "複数のアイテム", items: []Item{ {ID: 1, Name: "アイテム1", Price: 100}, {ID: 2, Name: "アイテム2", Price: 200}, {ID: 3, Name: "アイテム3", Price: 300}, }, expected: 600, }, } // 各テストケースを実行 for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { // ItemsTotalPrice関数を呼び出し result := ItemsTotalPrice(tc.items) // 期待される結果と実際の結果を比較 if result != tc.expected { t.Errorf("期待される結果: %d, 実際の結果: %d", tc.expected, result) } }) } } テストコードの解説 アイテムが空の場合 : 空のスライスを渡した場合に合計が0になるかを検証。 アイテムが1つの場合 : 単一のケースで合計価格が正しく計算されるかを検証。 アイテムが複数の場合 : 通常のケースで合計価格が正しく計算されるかを検証。 それぞれのケースで、期待される合計価格と実際の結果を比較し、不一致があればエラーメッセージを出力します。 コードの実登録 上記で確認したテストに問題がなければ「Accept all」を押下します。 再度 Ctrl + i キーを押下すると、エディタ画面に復帰すると、utilsディレクトリ配下にutils_test.goが作成されていることが確認できます。 テストコードの実行 ターミナルで以下のコマンドを実行し、テストを確認します。 go test ./... すべてのテストがパスすれば成功です。 Composer機能の利点 入力ファイルの複数指定 ：Composerの大きな利点はここにあると思います。実は今回のようなケースではgithub copilotでも同様のことは実現できます。ただし実際に実用的な良いコードを生成しようとするならば単一のファイルやコードを入力に生成することは難しく、プロジェクト内の多様なソースを複数参照したうえで生成する必要があります。このCursorのComposerであれば複数のファイルを入力に指定できるため、必要な入力を全て与えることが可能です。 ファイルの生成 ：既存の生成ＡＩではコードを画面に出力することはできても実際にファイルを生成するということはできませんでしたが、Cursorであれば提案された内容のファイルをそのまま出力してくれます。 ファイルの修正の提案 ：処理の修正が必要なとき、そのまま書き換えてしまうのではなく修正候補として表示され、キー入力により同意することで反映されるようになっています。一つ一つの修正内容をしっかりと確認した上で、提案を適用しやすくなっています。 おわりに CursorのComposer機能を活用することで、テストコードの作成が格段に効率化されます。特に、複数のファイルを入力させることにより、今までよりもずっと実用的なコード生成が可能となっています。 また、今回はあくまでテストコードの生成としてご紹介しましたが、もちろんメインのコードの生成も可能です。仕様をプロンプトに入力しコード生成させることでメインのソースを組み立てていくことができますし、既存の処理の修正も可能です。もちろん最終的には自身の目でレビューする必要があるということは他のAIツールと同様です。 今後もAIツールを積極的に活用し、開発効率とコード品質の両立を目指していきたいと思います。 参考 Cursor公式サイト Go言語公式サイト Visual Studio CodeとGitHub Copilotでコーディング効率を革新！AIを駆使した開発ガイド こんにちは。GSです。Visual Studio CodeとGitHub Copilotの組み合わせは非常に強力です。多くの人が「GitHub Copilotを使う＝コード自動補完を使う」と考えているかもしれませんが、Visual Studio Codeのアップデートにより、さらに便利な機能が使えるようになって... 　続きを読む　 Sqripts 関連記事｜Sqripts GenieAIでコードの品質を高めよう｜VSCode拡張機能GenieAIを用いてコード品質を高める手法 こんにちは、バックエンドエンジニアのまさです。前回のVSCodeでgithub copilotを使った開発効率向上の話に引き続き、今回はVSCodeでGenieAIという拡張機能を用いてコード品質を高める手法のご紹介をしたいと思います。OpenAIのAPIキーが必要になりますが、こちらも... 　続きを読む　 Sqripts 関連記事｜Sqripts The post CursorのComposer機能でAIに0からテストコードを作成してもらう first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ ［全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ 【第15回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO ［全文公開中］ 本連載もいよいよ最終回となりました。今回はプロジェクトの終了についてお話しします。 プロジェクト終了（クローズ）時の営みは 【第4回】プロジェクトの統合マネジメント、7つのプロセス の (7) でもお話したように、プロジェクト活動における「最後の活動」です。 ＜統合マネジメント：7つの活動＞ (1) プロジェクト憲章の作成 (2) プロジェクトマネジメント計画書の作成 (3) プロジェクトへの指揮とマネジメント (4) プロジェクトに関する知識のマネジメント (5) プロジェクト実行の監視とコントロール (6) 統合変更管理の実行 (7) プロジェクトクローズ　←こちら ではなぜ改めてこのプロジェクトクローズをおさらいするのでしょうか？それはPMBOKには詳しく書かれていない重要なポイントがあるからです。多くの人がプロジェクトの完了（done）と終結（close）を混同したり、終結に必要な活動をどうしてもおざなり（省略）にしがちです。プロジェクトを正しくクローズすること、これまでの活動をどのように「活かす」ことができるのか。大変だったプロジェクトもそうでなかったプロジェクトも、最後には笑顔で締めくくれるよう改めて学んでいきましょう。 プロジェクトの終結 1) 終結の定義 プロジェクトって成果物が完成したり納品できたら終わりじゃないの？ PMBOKでは「プロジェクト、フェーズ、または契約上の全ての活動を完結するプロセス」と定義されています。つまり、単純に目的目標の達成や成果物の納品「だけ」では物足りないということがわかりますね。またプロジェクトが経た活動や情報が保管（蓄積）且つ完了された状態で、プロジェクトに集結させていたリソース等も適切に解放（返却）させなければなりません。 2) 実施するクローズ活動と終結基準として確認したいこと 全ての文書と成果物が最新状態であることを確認する 全ての課題が解決されていることを確認する（または適切に申し送り事項として管理されていることを確認する） 成果物の検修完了を確認する プロジェクトの会計を終えている（未払い等がない状態を指す） 人的資源（人員）を返却する（プロジェクトから定常業務へ配置転換する） プロジェクトで利用した各種資源の返却や再分配を行う プロジェクト報告など必要なドキュメントを作成し報告を完了する プロジェクトの知識や教訓を特定、整理し、将来活用できるよう情報保管する ステークホルダーの満足度特定（アンケートやヒアリングの実施） これらの対応は相当の時間を要します。またクローズ時に全てを行おうとしても必要な情報が収集できなかったり、プロジェクト冒頭の事は失念してしまうこともあるでしょう。PMはプロジェクト期間を通して、プロジェクト実行や監視と並行してこれらの整理・準備少しづつ進めておきましょう。 組織と未来のプロジェクトへ、フィードバックは完璧に 1) 必ず作ろう終了報告書 プロジェクトは、上手くいったなと思う場合とそうでもない時があるはずです。反省の多いプロジェクトで終了報告を書くのは少々辛く感じるかもしれませんが、プロジェクトが失敗しても成功しても、PMの活動・イベントとして必ずその終了時には「プロジェクト終了報告書」を纏めましょう。「成果物が完成し、いつの間にかPJ体制が解消された」というケースをよく見ます。また「あれ？XXプロジェクトって終わってたんだ、どうだったの？」と周囲に確認されることがないように「正式に終わらせる」ためにも報告が大切です。 以下に簡易的なプロジェクト終了書の項目例を示してみました。項目や記載のボリュームはプロジェクト規模によって異なります。プロジェクトが終了しても残課題や申し送り事項がある場合が少なくありません。その為、終了報告書はプロジェクトの結果報告だけでなく記載した事項を漏れなく「引き継ぐ」という役割も持っています。プロジェクトが成功した場合にも、その成果物を定常業務＝運用に引き継ぐ役割もあります。プロジェクト活動の成果や残課題などを適切に引き継ぐことができなければ、後にプロジェクトに関連する活動でトラブルが発生した際などにズルズルと対応に追われることになるでしょう。 2) 未来に残す手紙 繰り返しになりますが、終了報告書は実施したプロジェクトのみならず、未来の活動（定常業務・プロジェクト・組織の活動等）の為に「プロジェクトで得た経験を蓄積し伝えていく」役割があります。あまりプロジェクト活動が上手くいっていない組織によく見られるのが「何度も同じ失敗や辛い体験を繰り返す」ことです。そうするとメンバーは「また同じことの繰り返しだ…」「全く改善されない…」と疲弊しモチベーションも下がってしまいます。 プロジェクトの目的目標が達成されれば必然的にチームは解散します。その際に適切に終結活動を行わないと、折角のプロジェクト活動で得られた経験や知識、技術も残らなくなってしまいます。よく聞く「XXプロジェクトを経験したXさんなら知っている」という類のものも、経験・知識が蓄積されているように見えて属人的な情報であり、組織の知恵になっておらずとても勿体無いです。プロジェクト終了報告書は別名「教訓報告書」とも呼ばれますが ＜教訓＝Lesson &Learn＞ として知識や技術を残すことがPMとしての最後の重大なお仕事です。 こうしておけばよかった、という改善点もあれば、これは次も使えるといったベストプラクティスは再現できるように継承しましょう。教訓はPMだけでなくメンバーと共に整理できるとよいです。教訓という言い方だと難しく考えてしまうかもしれませんが、未来に残す手紙・メッセージと考えると、スムーズに「伝えたい」ことが書き出せるはずです。 3) 終了報告書に必要なステップ 終了報告書が完成したら、プロジェクトオーナーや主要なステークホルダーに報告し「承認」を貰いましょう。報告に際してはできれば対面が望ましいですが、難しい場合はメールの一文でもいいので「承認した」旨の返信エビデンスを残すようにしてください。承認者であろうプロジェクトオーナーは活動期間中にさまざまな形でプロジェクトに心を傾けてくれた人物です。報告の場でプロジェクトの成果を伝えることはもちろん、PM自身が感じた想いを伝えたり、POへ感謝を伝えることも忘れずに行いましょう。 終了報告書が承認され「PJお疲れ様、終了してもいいよ！」となってはじめてプロジェクトは正式な終了を迎えます。ただしここで「なんだ、XXができていないならPJ終了は認めない」「報告書の記載が不十分」といったように＜差し戻し＞があることはゼロではないので（筆者も経験があります）、そのような事態にならないよう必要十分な報告と申し送り対応の説明などを行うように気をつけましょう！ 自信を持ってプロジェクトを終わらせるために 1) アンケート活用で暗黙知や見えにくい意見をあつめる プロジェクト参加者やメンバーが多い場合や、クロスファンクショナルなチームの場合などには振り返りにプロジェクトアンケートも活用してみましょう。「大勢の場では発言しにくいが、こう思っている」「他でこういう成功例があたので、取り入れてみたい」といったメンバーそれぞれの思いに気付けたりアイデアがでてくることも。2)にあるような「振り返りミーティング」は時間も限られ、またどれだけ工夫をしたとしても発言しにくいケースもあるでしょう。時折「振り返りミーティングを実施したけれど、当たり障りのない発言しかでなかった」「意見がでなかった」と耳にしますが、それらを補完するための工夫としてぜひアンケートを活用してみてください。 ※アンケート実施の際は、アンケート回答がプロジェクト教訓収集等に限定して使用され、個人を特定するものではないといったアンケートポリシーを記載しましょう。 2) 振り返りはナレッジの宝庫 プロジェクト終了の承認が得られた（得られるだろう）時点で、チームでの振り返りミーティング（クローズドミーティング）を準備・実施しましょう。プロジェクトの開始にキックオフがあったように、終了時にはプロジェクトクローズがセットの活動です。終了報告書と同様に、クローズドミーティングはプロジェクトのナレッジを集約し、未来に教訓を残す為に欠かせないイベントですが、目的は経験から学ぶ事であって決してネガティブになったり結果を非難するものではないことに気をつけましょう。またプロジェクトと組織の問題が混同し散漫になりがちですので、それぞれに対する意見は個別に述べてもらうなどの工夫もしてみましょう。 例えば会の冒頭に、以下のような振り返りの目的、ルール、怒ってほしくないことなどを記載し、参加者に伝えるとよいでしょう。 ＜振り返る目的：例＞ プロジェクトで得た気づきを整理、相互に共有し、多角的にプロジェクトを振り返る 後続プロジェクトや定常業務に活かすことのできる教訓を得る 良い点に再現性を持たせ、問題点は繰り返さないようにする プロジェクト結果をレガシーとして残す ＜ルール：例＞ もう一度同じプロジェクトをするなら、または次に向けたポジティブなスタンスで振り返えろう 全てにおいて、個人の称賛/批判ではなく、プロジェクトやプロダクトをより良くするという観点を持とう 振り返りを「次に活かす貴重な教訓＝資産を得る場」だと考えよう ポジティブ&ユーザーハッピーの視点で考えよう 振り返りにはKPTフレームワークやYWTフレームワークなど使い慣れた方法で行います。その場で上手くまとめる必要はありませんので、PMがファシリテーターとなり意見活性を促しましょう。とはいえ「さあ振り返りましょう！」と言ってもなかなか意見は出にくいものです。アンケートで収集した意見を事前にKPT上に書き入れて発言を誘発させるのも方法のひとつですし、発言してくれそうな人や発言しやすい項目をまず選んで、参加者が会話しやすいと感じる雰囲気を作っていきましょう。 振り返りのフレームワーク「KPT」とは。進め方やコツ、成功させる3つのポイント こんにちは、テストオペレーション部のショウです。最近「KPT（ケプト）」を使った振り返りに参加したので、私の体験を踏まえてまとめてみました。まず私から言えることは、”「KPT」は小まめに実施しましょう！”ということです。「KPT」の本領を発揮して成功させるた... 　続きを読む　 Sqripts 関連記事｜Sqripts 3) メンバーに言葉で感謝を伝える プロジェクトクローズドミーティングにはもう一つ重要な意味があります。それはプロジェクトメンバーや関係者を労って、所属していた部門や別のプロジェクトなどに気持ちよく戻れるようにすることです。「本当にありがとう、おつかれさま、またね」と ＜心理的にプロジェクトを終了させる＞ イベントです。言葉にしてプロジェクト活動を讃えあい、感謝を述べ、できる限りモチベーションを高めて次の活動に送りだすことに集中しましょう。またできる限りひとりひとり（もれなく）具体的な労いが言えるように準備したいですね。 その為にクローズドミーティングに軽食などを準備した「打ち上げ」を開催したり、打ち上げにメンバーが所属する上長を招待して「上長からメンバーを労ってもらう」といったテクニックを使うのも効果的でしょう。打ち上げをオフィシャルとしてしっかり実施することにはちゃんと目的があるというわけです。 さいごに 「プロジェクトマネジメントという共通言語としてのフレームワークや方法論の重要性はより高まります」と本連載のはじめにお話しました。それもそのはず、世の中は目まぐるしく変化し、企業組織では常に変化に対応するための多くのアクションが必要となり、現場レベル・部門レベル・全社レベル・短期的・中長期的・小規模プロジェクトから大規模プロジェクトまで、多くのプロジェクトが日々立ち上がる、まさに ＜プロジェクトエコノミー＞ の時代です。 しかし残念ながらプロジェクトマネジメントの手法を実行しただけでは、プロジェクトは上手くまわりません。プロジェクトに関与する人々のモチベーションがプロジェクトの成功や生産性にとても影響するからです。単なる指示命令・監視といったコミュニケーションではなく、相手の個別の価値観や傾向、思考などに寄り添う働きかけや工夫をすることで感情が動き、プロジェクトも動きます。プロジェクトを成功させる為に魔法のような大仕掛けはありませんが、これまでにお伝えしたようなひとつひとつの技術とコツの積み重ねが確実に効いてきます。プロジェクトやメンバーの声や動向に寄り添って、みんなが楽しく笑顔で活動できるようなプロジェクトをみなさんの手で作っていってください！ 【編集後記（Sqripts編集部）】 11ヶ月に渡る西田さんの連載は今回で最終回となりました。 執筆者の西田さん、連載を支えてくださった関係者のみなさま、そして、記事を読んでくださったたくさんの読者のみなさまに心より御礼を申し上げます。 みなさまのプロジェクトが「笑顔で終われる」プロジェクトになることを願っております。 この連載の感想をぜひお聞かせください。 送信フォームはこちらです。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ 【第15回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO ［全文公開中］ The post 【最終回】笑顔で終わるプロジェクトはここが違う！プロジェクトクロージングのTODO first appeared on Sqripts .

こんにちは、QAエンジニアの ノナカ です！ QAのプロジェクトにおいて「今のテストがどれくらい進んでいるのか」または「どれくらい遅れているのか」といった進捗を測定して状況を把握することは、テストの実行を管理する際にとても重要なタスクとなります。本記事ではそういった進捗管理業務において、スプレッドシートに設計したテスト項目書を想定し、テストの「結果」および「実施日」を 、「1.手動」「2.関数」「3.Google Apps Scripts（以下GAS）」の3つパターンで取得する方法をご紹介します。様々なプロジェクトやQA業務、またはGASの使い方などに少しでもお役立てできれば幸いです！ 事前準備 「テスト項目書」シートの作成 まずはじめに、今回の取得対象となる「テスト項目書」を準備しましょう。スプレッドシートにて、簡易的なものを下記に用意しました。今回取得したい部分は、赤枠の「結果」列及び「実施日」列となります。※結果はシンプルに「OK」「NG」のみとし、実施期間は「2024/4/1」～「2024/4/5」の5日間と設定しています。 「進捗管理」シートの作成 続いて、「テスト項目書」シートとは別に１日ごとのテストの進捗を管理できるような「進捗管理」シートを準備します。こちらも簡易的なものを下記に用意しました。 「テスト項目書」シートの「結果」列及び「実施日」列に対応するものが、上図赤枠の各結果行と各日付列となります。上節の「テスト項目書」シートを例に挙げると、F列：「2024/4/1」の8行目「OK」が3件、G列「2024/4/2」の8行目「OK」が1件…というように、各テスト項目に対して「いつ」「結果がどうなったか」をそれぞれ入力する必要があります。 ポイント! – 消化する項目数の予定（予定完了率）について 進捗状況を把握するためには、 計画（理想）に対する実績を比較する ことが必要となります。今回の「進捗管理」シートでは、１日ごとに消化する（テスト結果：OKとなる）項目数を事前に計画して算出しています。算出方法としては、「全体の項目数からテスト全期間を割って平均値を算出する方法」や「テスト項目の消化に掛かる工数・ウェイトや優先度合等から日毎に消化できる項目数を厳密に算出する方法」等があります。今回は前者のパターンで算出しています。 「予定」の算出 今回だと「テスト対象の項目数：10項目」に対して「テスト全期間：5日」なので、「1日あたり2項目の消化」が必要となる計算です。（10 / 5 = 2） 「実績」の算出 実績（テスト結果：OK）の算出方法は、「OK」の値をそのまま関数を使って参照するだけでよいでしょう。 ※今回はテスト結果が「OK」しか設定していませんが、例えば「NG→OK（不具合が解消されたケース）」といったテスト結果もある場合は取得範囲が変わるため注意が必要です。 「◆予定完了率」の算出 「予定完了率」は「その日まで（から）に消化する予定の項目数」に対して「テスト対象の項目数」を割った値を算出する必要があります。ただし、関数の場合は先頭のセルと先頭以降のセルで算出方法が変わるため、下記の通り書き方を少し工夫する必要があります。 先頭のセル（F5セル）のサンプル関数 =F3/$E3 ※「先頭＝テスト初日」の場合、その日「から」消化する予定の項目数となるため、「F3 ＝ 2024/4/1 の予定項目数」を算出する必要があります。 先頭以降のセル（Ｇ5セル）のサンプル関数 =SUM($F3:G3)/$E3 ※「先頭以降＝テスト初日以降」の場合、その日「までに」消化する予定の項目数となるため、「SUM($F3:G3) ＝ 2024/4/1 + 2024/4/2 の予定項目数」を算出する必要があります。 「◆実績完了率」の算出 「実績完了率」でも「予定完了率」と同様の算出方法となります。ただし、参照する行は「予定」の3行目ではなく、「実績」の4行目が対象となります。 補足 今回のテスト項目書は１シートだけですが、例えば複数の項目書を一元で管理したい場合などは、下記のような書き方をすることで全体の進捗を把握することができます。 ※「サマリ」エリアの「予定」および「実績」、「項目数」～「NG」は、各項目書からSUM関数で引っ張ってきています。 複数の項目書を一元で管理する場合のイメージ図 いかがでしょうか。デイリーごとの進捗を把握したいケースの場合、テスト項目書をその都度参照しながら確認していくよりも、格段に把握しやすくなったのではないでしょうか。 それでは次章より、各テスト項目に入力された「結果」および「日付」を取得し、「進捗管理」シートに反映する方法を 「1.手動」、「2.関数」「3.Google Apps Scripts（以下GAS）」の3パターンを紹介していきます。また、それぞれ「手軽さ（誰でも取得可能そうか）」「取得時間（取得に時間がかからなさそうか）」「精密度（取得する値が正確か）」「汎用性（他のファイル等でも管理できそうか）」を筆者の所感として3段階の「★（多ければ多いほど良！）」で評価していきたいと思います。 パターン1 – 手動で取得する 評価 手軽さ　　：★★★ 取得時間　：★☆☆ 精密度　　：★☆☆ 汎用性　　：★☆☆ 解説 テスト項目書に入力された各テスト項目の結果・実施日は、当然ながら人力でカウントすることで手動で取得することができます。ただし人力の場合、ヒューマンエラーによるカウントミスや入力ミスが起きてしまったり、項目数が膨大な場合は取得するだけで工数が膨らむといった問題点があります。反対に項目数が極端に少なく、またテスト期間が極端に短いプロジェクトなどでは非常に有効な手段となるでしょう。 パターン2 – 自動で取得する（関数編） 評価 手軽さ　　：★★☆ 取得時間　：★★★ 精密度　　：★★☆ 汎用性　　：★☆☆ 解説 手動での問題点（カウントや入力のミス、取得に掛かる工数）を回避する方法として、関数を使用する方法が挙げられます。本記事では、「countifs関数」を例に紹介します。 凡例 =COUNTIFS('項目シート名'!「結果」列のセル範囲,結果ステータス,'項目シート名'「日付」列のセル範囲,日付) 「事前準備」章のF8セルに入力する場合のサンプル関数 =COUNTIFS(INDIRECT("'"&$C$10&"'!G:G"),$D8,INDIRECT("'"&$C$10&"'!H:H"),F$2) 上記関数を「進捗管理」シートの各結果行と各日付列のセル（「進捗管理シートの作成」節の赤枠内）に埋め込むことで、対応する結果を自動で取得することができます。メリットとしては手動に比べて遥かに容易、かつリアルタイムでテスト結果を取得できる点となり、デメリットとしては項目書における項目数やテスト期間が増えれば増えるほど（プロジェクト規模が大きくなるほど）、比例して関数の数が増えてしまうため、スプレッドシートに処理の負荷がかかる（例えば起動元のPCの状態によっては開くまでに時間がかかる　等）といった点が挙げられます。そのため、規模感がそこまで大きくないプロジェクトでない限りは、十分有効な手段といえるでしょう。 パターン3 – 自動で取得する（GAS編） 評価 手軽さ　　：★☆☆ 取得時間　：★★☆ 精密度　　：★★☆ 汎用性　　：★★★ 解説 関数のように逐一リアルタイムでテスト結果を取得したくない場合や関数を使用するにはプロジェクト（項目書）の規模が大きすぎる場合、または項目書とは別に用意したスプレッドシートで進捗を管理したい場合などは、Google Apps Scripts（GAS）を使用することが有効です。本記事では、簡単な要件定義からコーディングまでを解説していきます。 要件定義 コーディングするにあたって、まずは要件を定義していきましょう。必要な情報は、取得対象である「テスト項目書」シートの「結果」列及び「実施日」列のデータと、取得した後に入力する「進捗管理」シートの「結果」行と「日付」列の位置、および入力条件となります。それらをまとめた処理のフローを下記に掲載しました。 処理フローのイメージ図 コーディング それでは、上記でまとめた内容を基に、コーディングしていきましょう。要点を絞って解説していきます。 対象のスプレッドシート・シートの指定 まずはじめに、前提として対象となるスプレッドシートおよびそのシート名を指定していきます。 /**対象のスプレッドシート・シートの取得*/   let activeSheet = SpreadsheetApp.getActiveSpreadsheet();  //現在アクティブなスプレッドシート   let activeSheetName = SpreadsheetApp.getActiveSheet().getName();  //現在アクティブなシート   let progressSheet = activeSheet.getSheetByName(activeSheetName);  //「進捗管理」シートの設定   let testSheet = activeSheet.getSheetByName('項目シート'); //「テスト項目書」シートの設定 「progressSheet」を「進捗管理」シート、「testSheet」を「テスト項目書」シートとしてます。今回はテスト項目シート名を直値（’項目シート’）で指定していますが、項目シートが複数ある場合は、「事前準備」章の「進捗管理シートの作成 – 補足」の例にあるように「進捗管理」シートのC列に各項目シート名を記載したうえで、そこから各値を取得する方法などでも対応できます。 「進捗管理」シートの入力位置設定とデータの取得 続いて、「進捗管理」シートに入力するセル位置を設定していきましょう。 /**「進捗管理」シートの入力位置設定とデータの取得*/   let progSheetFirstRow = 8;  //「進捗管理」シートの入力セルの先頭行位置   let progSheetResult = 2;  //「進捗管理」シートの結果の数（OK/NG）   let progSheetFirstCol = 6;  //「進捗管理」シートの入力セルの先頭列位置   let testPeriod = 5;  //テスト期間（人日）   let testTerm = progressSheet.getRange(2, progSheetFirstCol, 1, testPeriod).getValues().flat();  //「進捗管理」シートの入力範囲の取得   progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValue(0);  //「進捗管理」シートを初期化する   let inputData = progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).getValues();  //値を代入する変数を定義する こちらも「セルの先頭行位置」などを直値で指定していますが、体裁などによって行・列やセルの位置が頻繫に変わる場合などは、検索キーでセル位置を自動で取得する方法なども有効です。 「テスト項目書」シートの入力位置設定とデータの取得 続いて、同様に「テスト項目書」シートに入力するセル位置を設定していきましょう。 /**「テスト項目書」シートの入力位置設定とデータの取得*/   let datafirstRow = 3;  //「テスト項目書」シートの入力セルの先頭行位置   let datafirstColumn = 7;  //「テスト項目書」シートの入力セルの先頭列位置   let datalastRow = testSheet.getLastRow();  //「テスト項目書」シートの入力セルの先頭列位置   let testDate = testSheet.getRange(datafirstRow, datafirstColumn, datalastRow, 1).getValues().flat();  //「結果」列を配列に格納する   let dataDate = testSheet.getRange(datafirstRow, datafirstColumn + 1, datalastRow, 1).getValues().flat();  //「実施日」列を配列に格納する 取得元となる「テスト項目書」シートに対しても、同じように設定・取得していきます。こちらも直値です。 結果および日付の比較判定（「OK」の例） 「要件定義」で定義したように結果や日付の判定を行う処理を最後に記載すれば完了となります。判定処理は「テスト結果が空欄かどうか」「日付が空欄かどうか」「日付が指定したフォーマットかどうか」をそれぞれ判定したうえで、適切な結果だった場合は最後に「OKか」を判定して対象の日付のOK数をカウントし、最後にその値を「進捗管理」シートに転記する、といった処理にしてみました。 /**結果および日付の比較判定*/   //for文で「テスト項目書」シートの最終行までループで比較判定を行う   for (i = 0; i < datalastRow; i++)     //結果が空欄のケース（何もしない）     if (testDate[i] === "") {       ;       //結果が空欄以外＋日付が空欄のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] == "") {       ;       //結果が空欄以外＋日付が指定フォーマット以外のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] != "") {       let objectType = Object.prototype.toString.call(dataDate[i]);       if (objectType != "[object Date]") {         ;         //結果が「OK」かつ日付が指定フォーマットのケース       } else if (testDate[i] === "OK" && objectType == "[object Date]") {         key = Utilities.formatDate(dataDate[i], 'JST', 'yyyy/MM/dd');         for (j = 0; j < testPeriod; j++) {           result = Utilities.formatDate(testTerm[j], 'JST', 'yyyy/MM/dd')           keySearch = result.indexOf(key)           if (keySearch > -1) {             inputData[0][j]++;             break;           } else {             ;           }         };       //判定結果を「進捗管理」シートに入力する       progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValues(inputData); 今回は「OK」「NG」の２パターンの結果のみしか定義していませんが、「BK（Blocking）」や「保留」、「NT（No Test ）」などの結果ステータスがある場合も同じような記載方法で処理することができます。 サンプルコード サンプルコードも掲載しておきます。折角なので、確認ダイアログや完了ダイアログの表示も併せてコーディングしてみました。 function AggregateResults() {   /**確認DLGの設定*/   //集計実行日の取得   let today = Utilities.formatDate(new Date(), 'JST', 'yyyy/MM/dd/EE')   //確認DLGの表示   let confirmdlg = Browser.     msgBox("実行確認", today + " 時点のテスト結果を集計しますか？", Browser.Buttons.YES_NO);   if (confirmdlg == "yes") {     ;   } else {     return false;   };   /**対象のスプレッドシート・シートの取得*/   let activeSheet = SpreadsheetApp.getActiveSpreadsheet();  //現在アクティブなスプレッドシート   let activeSheetName = SpreadsheetApp.getActiveSheet().getName();  //現在アクティブなシート   let progressSheet = activeSheet.getSheetByName(activeSheetName);  //「進捗管理」シートの設定   let testSheet = activeSheet.getSheetByName('項目シート'); //「テスト項目書」シートの設定   /**「進捗管理」シートの入力位置設定とデータの取得*/   let progSheetFirstRow = 8;  //「進捗管理」シートの入力セルの先頭行位置   let progSheetResult = 2;  //「進捗管理」シートの結果の数（OK/NG）   let progSheetFirstCol = 6;  //「進捗管理」シートの入力セルの先頭列位置   let testPeriod = 5;  //テスト期間（人日）   let testTerm = progressSheet.getRange(2, progSheetFirstCol, 1, testPeriod).getValues().flat();  //「進捗管理」シートの入力範囲の取得   progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValue(0);  //「進捗管理」シートを初期化する   let inputData = progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).getValues();  //値を代入する変数を定義する   /**「テスト項目書」シートの入力位置設定とデータの取得*/   let datafirstRow = 3;  //「テスト項目書」シートの入力セルの先頭行位置   let datafirstColumn = 7;  //「テスト項目書」シートの入力セルの先頭列位置   let datalastRow = testSheet.getLastRow();  //「テスト項目書」シートの入力セルの先頭列位置   let testDate = testSheet.getRange(datafirstRow, datafirstColumn, datalastRow, 1).getValues().flat();  //「結果」列を配列に格納する   let dataDate = testSheet.getRange(datafirstRow, datafirstColumn + 1, datalastRow, 1).getValues().flat();  //「実施日」列を配列に格納する   /**結果および日付の比較判定*/   //for文で「テスト項目書」シートの最終行までループで比較判定を行う   for (i = 0; i < datalastRow; i++)     //結果が空欄のケース（何もしない）     if (testDate[i] === "") {       ;       //結果が空欄以外＋日付が空欄のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] == "") {       ;       //結果が空欄以外＋日付が指定フォーマット以外のケース（何もしない）     } else if (testDate[i] != "" && dataDate[i] != "") {       let objectType = Object.prototype.toString.call(dataDate[i]);       if (objectType != "[object Date]") {         ;         //結果が「OK」かつ日付が指定フォーマットのケース       } else if (testDate[i] === "OK" && objectType == "[object Date]") {         key = Utilities.formatDate(dataDate[i], 'JST', 'yyyy/MM/dd');         for (j = 0; j < testPeriod; j++) {           result = Utilities.formatDate(testTerm[j], 'JST', 'yyyy/MM/dd')           keySearch = result.indexOf(key)           if (keySearch > -1) {             inputData[0][j]++;             break;           } else {             ;           }         };         //結果が「NG」かつ日付が指定フォーマットのケース       } else if (testDate[i] === "NG" && objectType == "[object Date]") {         key = Utilities.formatDate(dataDate[i], 'JST', 'yyyy/MM/dd');         for (j = 0; j < testPeriod; j++) {           result = Utilities.formatDate(testTerm[j], 'JST', 'yyyy/MM/dd')           keySearch = result.indexOf(key)           if (keySearch > -1) {             inputData[1][j]++;             break;           } else {             ;           }         };       };     };   //判定結果を「進捗管理」シートに入力する   progressSheet.getRange(progSheetFirstRow, progSheetFirstCol, progSheetResult, testPeriod).setValues(inputData);   /**完了DLGの設定*/   Browser.msgBox("実行完了", "集計が完了しました。", Browser.Buttons.YES);   return false; }; 応用編 – グラフで表現してみよう！ 取得した結果をスプレッドシートのグラフと組み合わせて表現することで、より視覚的に状況を把握することができます。 「進捗管理」シート × バーンアップチャート 本記事でご紹介した方法の場合、「完了率」といった積み上げする測定方式のため、「バーンアップチャート」で表現すると、もっともシンプルに進捗率が可視化できるでしょう。 また、グラフで表現することは、例えば上記の場合は「2024/4/2」までは予定以上の前倒し気味でテストが進行されてそうですが、「2024/4/3」以降は消化速度が停滞気味になっていることが分かります。「進捗管理」エリア上では「2024/4/3」に不具合が2件検出されているため、これがテスト項目の消化の阻害要因になってそうなので、不具合の状況確認が必要だな、必要に応じて開発側に連携をとる必要があるな、といった わざわざ各テスト項目書を確認しに行かなくても、一目で一次的な状況が推量できる といった利点などがあります。このようなスピード感を持った一次的な状況把握から二次的なネクストアクションを円滑に行うことができれば、適切なインシデントの管理やエスカレーション、場合によってはプロジェクト自体を上手くコントロールできる場合があります。 「進捗管理」シート × テスト結果積み上げグラフ × 信頼度成長曲線 さらに応用編としてより実践的に活用するために、「進捗管理」シートに対してテスト結果の「積み上げグラフ」と「信頼度成長曲線」を組み合わせて下図に表現してみました。コチラはより実践的な運用がイメージできるのではないでしょうか。 ※本格的なプロジェクトに近づけるために、「進捗管理」シートを少し加工して見せ方を変えています。 いかがでしたしょうか。他にも、プロジェクトや進捗状況に応じて様々な取得対象や表現方法等と組み合わせたりして、色々とカスタマイズしてみてください！ おわりに 本記事では、テスト項目書に入力された「結果」および「実施日」を 「1.手動」、「2.関数」「3.Google Apps Scripts」 の3つパターンで取得することで、進捗状況を測定する方法をご紹介しました。進捗を測定して状況を把握・管理することは、プロジェクトにとってボトルネックとなる問題点を認識できたり、またプロジェクトにおける円滑な進行を助長したりすることができます。 ただし、これらはあくまでも進捗管理における「手段」にしか過ぎません。進捗を管理する「目的」とは、『プロジェクトを問題なく成功に導き、高品質な商品やサービスを提供する』ということを忘れてはいけません。進捗状況を測定することだけに囚われて無駄な工数をかけてしまうといった本末転倒とならないようくれぐれも注意しましょう。またそうならないためにも、日々のテスト管理業務に対して上手くツール等を扱い、よりよいQA業務・品質管理に努めていきましょう！ The post テスト結果を取得して進捗状況を測定しよう first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) 前回の「 ソクラテスは電気羊の夢を見るか？(前編) 」では、「定言三段論法」と呼ばれる推論形式の基本事項を紹介しました。 定言三段論法的な推論を自分から意識して組み立てることは少ないかも知れませんが、考えを整理してみたら定言三段論法的に考えると具合がよさそう、ということはあるでしょう。 文章を読んでいて、「これは定言三段論法で表してみると理解しやすいのでは？」と思えるような論理展開に出会うこともあるでしょう。 そんな時「この理屈は、形の上で正しいのかな？」とチェックできるように、今回は定言三段論法が「よい形」であるための規則を見ていきます。 その前に、前回クイズの解答です。 前回クイズ解答 問題(再掲) 下図の「ソクラテスと電気羊」その1～3について考えてみてください。 小名辞S、大名辞P、媒介項Mに当たるのは何か 各文は全称/特称、肯定/否定どれに当たるか 解答 その1。 小名辞Sは「ソクラテス」、大名辞Pは「電気羊の夢を見る」、媒介項Mは「哲学者」です。 大前提①は「すべてのMはPである(全称肯定)」の形、小前提②は「すべてのSはMである(全称肯定)」の形、結論③は「すべてのSはPである(全称肯定)」の形です。 （ちなみに、①M-P, ②S-M, ③S-Pですから第1格、式はAAAです） その2。 小名辞S、大名辞P、媒介項Mはその1と同じです。 大前提①は「あるMはPである(特称肯定)」の形、小前提②は「すべてのSはMである(全称肯定)」の形、結論③は「すべてのSはPである(全称肯定)」の形です。 （ちなみに、①M-P, ②S-M, ③S-Pの第1格、式はIAAです） その3。 小名辞Sは「ソクラテス」、大名辞Pは「哲学者」、媒介項Mは「電気羊の夢を見る」です。 大前提①は「すべてのPはMである(全称肯定)」の形、小前提②は「すべてのSはMである(全称肯定)」の形、結論③は「すべてのSはPである(全称肯定)」の形です。 （ちなみに、①P-M, ②S-M, ③S-Pの第2格、式はAAAです） ソクラテスが電気羊の夢を見られるために 押さえておきたい定言三段論法の「よい形」の規則 ソクラテスと電気羊・その1は、内容(意味)から「これは前提から無理なく結論が導けるな」と思った人は多いのではないでしょうか。 その2、その3では、やはり内容(意味)を見て「この前提からこの結論は、ちょっと無理があるのでは？」「何かおかしくないか？」と、感じた人も多いのではないでしょうか。 内容や意味の面で「？」と感じる主張は、形を調べてもおかしいものです （内容面で正しそうに見えても、形としてはよくない（妥当でない）ものもあります）。 定言三段論法的な推論の“よしあし”が、内容や意味の吟味以前に、形から読み取れることを見ていきましょう。 定言三段論法の「よい形」の規則 (1) 概念の数 登場する名辞(概念)は、三つであること ひとつの主張(大前提、小前提、結論の組)に登場する名辞(概念)は、小名辞S、大名辞P、媒介項Mの3個に限られます。3個より多いと、意味上の混乱が生じたり、媒介する概念がなくなって論が成り立たなくなります(図7-1)。 明らかに異なる名辞(概念)が4つ以上あるのがいけないのはもちろん、言葉の意味や解釈、表現などから名辞が多過ぎる状態になってしまってもいけません。 図7-1 登場する名辞(概念)は三つ 逆に登場する名辞(概念)が3個より少なく見える場合は、名辞が前提の中で省略されている可能性もあります（周知である、議論の背景として共有されている、などから省略されている事柄を補うと、正しい定言三段論法の形になる場合もある）。 そのような場合は実際の論理展開で見かけることも多いものです。主張を注意深く読み込んで「前提が隠れているのでは？」と考えてみるのがよいでしょう（ただし、本当に名辞が足りていない場合もあります）。 定言三段論法の「よい形」の規則 (2) 周延 周延とは、「 その概念が当てはまるすべての対象について言われている 」状態でした（「 ソクラテスは電気羊の夢を見るか？(前編) 」）。 周延の規則①　媒介項は必ず周延されること 媒介項Mは、前提の中で一度は周延 されている必要があります。 媒介項が周延されることで、「Mに関係しているS」と「Mに関係しているP」が結びつき、結論が成り立ちます。 図7-2 周延の規則①　媒介項Mと周延 「ソクラテスと電気羊・その1」で「なるほど、ソクラテスは電気羊の夢を見るね」と判断できるのは、「哲学者」という媒介項が（「すべての」という全称により）周延され、「ソクラテス」という概念と「電気羊の夢を見る」という概念が「哲学者」を介して結びつくからです（それだけではありませんが）。 その2、その3はこの規則に反しており 、媒介項「哲学者」(その2)、「電気羊の夢を見る」(その3)が周延されていません（後述「周延に関する誤謬」参照）。 周延の規則②　前提で周延されていないものは結論でも周延されないこと 小名辞、大名辞は、前提で周延されていない（不周延）なら結論でも不周延 である必要があります（結論で周延されるなら、前提で周延されている必要がある）。 一部についての主張が、無条件で全体に当てはまるとは言えない からです。 なお、 周延されている名辞を結論で周延しないことはできます 。 図7-3 周延の規則②　小名辞S、大名辞Pと周延 定言三段論法の「よい形」の規則 (3) 肯定と否定 肯定と否定の規則①　前提がふたつとも否定なら、結論は出せない 前提がふたつとも否定の場合、結論は出せません 。 図7-4 肯定と否定の規則①　前提がふたつとも否定の場合 図7-4a 肯定と否定の規則①　前提がふたつとも否定の場合 肯定と否定の規則②　前提のどちらかが否定なら、結論は否定 前提のひとつが否定の場合、結論は否定 になります。 図7-5 肯定と否定の規則②　前提のひとつが否定の場合 図7-5a 肯定と否定の規則②　前提のひとつが否定の場合 肯定と否定の規則③　前提がどちらも肯定なら、結論は肯定 前提がふたつとも肯定の場合、結論は肯定 になります。 図7-6 肯定と否定の規則③　前提がふたつとも肯定の場合 図7-6a 肯定と否定の規則③　前提がふたつとも肯定の場合 肯定と否定の規則・同値関係 肯定と否定の規則②③は、それぞれ逆も成り立ちます。(図7-7) 図7-7 肯定と否定の規則②③の同値関係 定言三段論法の「よい形」の規則 (4) 全称と特称 周延の規則、肯定と否定の規則から導出できる派生的な規則ですが、知っておくと便利な規則です。 全称と特称の規則①　前提がどちらも特称なら、結論は出せない 前提がふたつとも特称の場合、結論は出せません 。 図7-8 全称と特称の規則①　前提がふたつとも特称の場合 図7-8a 全称と特称の規則①　前提がふたつとも特称の場合 全称と特称の規則②　前提のどちらかが特称なら、結論は特称 前提の一方が特称の場合、結論は特称 となります。 図7-9 全称と特称の規則②　前提のひとつが特称の場合 図7-9a 全称と特称の規則②　前提のひとつが特称の場合 定言三段論法の「よい形」の規則　補足 ここまで挙げた「よい形」の規則はすべての格（「 ソクラテスは電気羊の夢を見るか？(前編) 」、図6-6）に共通で、 定言三段論法の形の“よしあし”は、これらの規則で調べることができます。 （これらの規則から派生できる規則は割愛しています。 また、これらの規則を踏まえて格ごとに格の形から来る制約があり、その結果「ひとつの格に、妥当な式は6個」となりますが、それらの説明も割愛します） 定言三段論法・気をつけたい落とし穴(誤謬) 定言三段論法の形式面で気をつけたい点は、「よい形」の規則の裏返しと言えます。 概念の数に関する誤謬 「ひとつの主張に登場する名辞(概念)は3個であること」(図7-1)に関して、名辞(概念)が3個より多くなっている誤りを 四個概念の誤謬 といいます。 現れている名辞(概念)の数だけでなく、以下のような点に注意しましょう。 使われている言葉の意味は明確か 多義的な言葉を使ったり、言葉の意味づけが曖昧だったりすると混乱を招く。 「同じ言葉は同じ意味」になっているか 言葉は同じでも、意味することが違っていると混乱を招く。 「同じ概念には同じ言葉」を使っているか 同じ概念を異なる言葉・表現で言い換えたり、（微妙に）違う言い回しを用いたりすると混乱を招く。 図7-10 四個概念の誤謬の例(1) 図7-11 四個概念の誤謬の例(2) 周延に関する誤謬 周延の規則①(図7-2)を守っていないことを、 媒介項不周延の誤謬 といいます（中名辞不周延の誤謬、媒概念不周延の誤謬ともいいます）(図7-12)。 図7-12 媒介項不周延の誤謬の例 周延の規則②(図7-3)を守っていないことを、 大名辞不当周延の誤謬 、 小名辞不当周延の誤謬 といいます(図7-13, 図7-14)。 （こちらは「 不当周延 」です。媒介項の 不周延 とは言葉も意味も違います） 図7-13 大名辞不当周延の誤謬の例 本連載最初の「 論理のかたち。推論とは 」で例に挙げた「イヌの三段論法」は小名辞不当周延の例になっています。（そのまま再掲していますが、大前提は②、小前提が①と並びを変えて読むと理解しやすいでしょう） 図7-14 小名辞不当周延の誤謬の例 肯定と否定の規則に関する誤謬 肯定と否定の規則①(図7-4, 図-4a)に反して結論を出していることを 否定前提の誤謬 や 否定二前提の誤謬 といいます。 また、肯定と否定の規則②(図7-5, 図7-7)に反していることを 不当肯定の誤謬 、 肯定と否定の規則③(図7-6, 図7-7)に反していることを 不当否定の誤謬 といいます。 あんがい縁がある推論の形 前回、今回と、定言三段論法の概要を紹介してきました。 修飾なしで「三段論法」というとこの形を思い浮かべる人は多いと思います（筆者もそうでした）。どのような推論の仕方をするものなのか、感触をつかめたでしょうか。 私たちが目にしたり、考えたりする中には、このような「概念どうしの関係」として表せるものごとや、そうすると考えやすいものごともあります。 「あの人はそそっかしいから、○○だ」といった主張も、「すべてのそそっかしい人は○○だ。あの人はそそっかしい。だからあの人は○○だ」といった定言三段論法の形で整理したり、考えを明確にしたりできる場合もあります。 （そうすると、「そそっかしい人はみな○○なのか？」といった、考えを批判的に見る視点も生まれやすくなります） こういう推論の形があるということ、そしてできればその考え方を知っておくのは有益でしょう。 クイズ ISTQB Foundaton Level V4.0シラバスの記述を元にした主張があります（()内は章節番号）。 それぞれについて、形に着目して、妥当な（よい形の）主張かどうか、今回の説明を元に考えてください。 （解答は次回に） 次回 次回、次々回は、これまで推論の形ごとに紹介してきた「気をつけたい落とし穴」について、 「形式面で気をつけたい落とし穴」をおさらいし、 「内容面で気をつけたい落とし穴」を詳しく探検 していきます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) ソクラテスは電気羊の夢を見るか？ (後編) The post ソクラテスは電気羊の夢を見るか？ (後編)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

みなさんこんにちは、ノッカーです。 今回もUSDM記法についてご紹介します。これまで2回( 第一弾 、 第二弾 )にわたりUSDMについてお話ししましたが、今回は以下の課題に対する解決策をご紹介します。 多くの要求から必要な情報を探すのが困難 進捗状況を把握しにくい 仕様を実装する際に疑問点が生じる その前に、まずは前回までの内容を振り返りましょう。第一弾の記事では、以下の4つのポイントについてお話しました。 USDMで初期品質を高めよう！～要求仕様を明確に記述するUSDMの紹介 Part1 初めまして、テストエンジニアのノッカーです。日々の業務の中で、いままでとは違う新しい経験ができましたので、その体験談を共有させていただきます。早速ではございますが、以下のような場面に遭遇したことはありませんか？要件定義(要求分析含む)の問題により、... 　続きを読む　 Sqripts 関連記事｜Sqripts USDMで仕様を上手にアウトプットしよう！～要求仕様を明確に記述するUSDMの紹介 Part2 みなさんこんにちは、ノッカーです。今回、USDMにかかわる記事の第二弾を書かせていただきます。前回の記事では、USDMを使用することで、要求や仕様を階層化することで、実装時の抜けや漏れ、誤りなどの問題が効果的に解決できることを紹介しました。今回は、USDMに... 　続きを読む　 Sqripts 関連記事｜Sqripts 前回までのおさらい 要求を分割する 複合的な要求を単純な要求に分割する 曖昧な要求を具体化する 要求を分割することで、要求がより具体化されました。 要求を階層化する 元の要求を上位要求とし、分割した要求を下位要求とする 要求を階層化し、分割前の要求の下に一覧化することで、解決すべき細かな要求が明確になりました。 理由を記述する それぞれの要求に理由を付ける 認識のズレを防ぐために、本質的な理由を記述する 「なぜその要求が必要なのか」を記述することで、要求の本質を理解し、認識のズレを防止しました。 仕様を導出する（要件を定義する） 要求に含まれる具体的な処理や振る舞いを表現する 特定できるレベルまで細かくする 要求を満たす仕様を導き出すことで、何をすべきかが明確になりました。 続いて、第二弾の記事では以下の4つのポイントを取り上げました。 キーワードラベル 馴染みのある用語や別名を記述する 要求の本質を簡潔に示し、一目で理解できるようにしました。 説明を記述する 補足事項や背景など、要求の記述では足りない情報を記述する 要求に関する事情や追加情報を追記できる場所を確保しました。 グループ化 要求や仕様が多い場合、小さな集合に分類して範囲を限定する カテゴリごとの仕様を明示し、左揃えで記述することでグループの区切りがはっきりし、視認性が向上しました。 仕様ラベル 仕様であることを示し、要求と明確に区別する 特定の工程のステータス管理が可能になりました。 以上のプロセスを経て、以下の図が完成しました。 今回の課題の解決策 それでは、今回の課題に対する解決策について説明します。 多くの要求から必要な情報を探すのが困難 進捗状況を把握しにくい 仕様を実装する際に疑問点が生じる ※今回改修する箇所は図の青い部分になります。 プロジェクトやチームで運用する際、個々がそれぞれの正義で一つの目的に向かうと、十人十色の成果物が出来上がってしまうでしょう。USDMで実用性を求める場合、同じ目的に向かう過程でも同じ作りに統一する必要があります。メンバー全員が一つのルールや定められたガイドラインに沿って作成することが重要です。 ただし、それほど難しいものではないので、軽い気持ちで読み進めてください。 （1）キーワードラベルのルール化 前回は 要求の本質を簡潔に表現し、一目で理解できるレベル としてキーワードラベルをご紹介しましたが、今回はそこにルールを加えることで利便性をさらに高める方法をご紹介します。 ルールとしては、 単語を先頭にする 、 区切り文字は「‗」を使用し、区切り文字以降は対象物を記載する の2点です。 例えば、「HDD容量不足通知機能」というキーワードラベルの場合、ルールに従うと「通知‗HDD容量」や「通知‗HDD容量不足」となります。また、「通信速度通知機能」なら「通知‗通信速度」となるので、他にも通知機能がある場合でもルールに従った記述によって検索が容易になります。 実際には複数の要求が存在するため、このルールに基づいて「通知_」という検索ワードを使用することで、多くの要求の中から必要な情報を効率的に探し出せるようになります。 （2）仕様ラベルのルール化と運用方法 前回の説明では、要求と仕様を明確に区別するための指標と、□の用途に意味を持たせることについて説明しました。内容としては概ねそれ以上の深掘りはしていませんが、今回は具体的にどのような用途で使用するのが適切かをご紹介します。 仕様ラベルの□の数は基本3個 仕様ラベルの□は、各工程の完了状況を示すためのチェックポイントとして使用します。基本的には、 仕様をレビューした 、 仕様を実装した 、 実装内容をテストした という3つのチェックポイントを設けます。これにより、「レビューが終わっていないのに実装されてしまった」や「実装前にテストを行ってしまった」などの行き違いを防ぎ、進捗も確認できます。これは一般的なフローに基づいた例であり、プロジェクトに応じて適切な仕様ラベルを使用することが重要です。 仕様ラベルの運用方法 仕様ラベルの□は、チーム全体が仕様の進行状況を一目で把握できるよう、工程の順序に沿って左から順にチェックできるようルール化します。たとえば、「レビューが完了していないのに実装が進んでしまう」や、「実装が完了していないのに検証済みとなる」といった事態を防ぐため、前工程が完了していないと次に進めないようにすることが重要です。これにより、仕様ラベルのチェック状況を一目で確認でき、進捗状況の把握が容易になります。 初めて見る人には、この□が何を意味するのか分かりにくい場合があります。そこで、関係者全員が仕様ラベルの運用方法を理解し、正しく使用できるよう、教育やガイドラインを作成しておくとよいでしょう。特に新規メンバーには、早期に運用方法を伝えることで、スムーズなプロジェクト進行が可能になります。 （3）仕様をSpecify（特定）させる 第1回でもご紹介した内容ですが、さらに具体化するために以下の対応を行います。 要求から目的語と動詞を導出する 目的語の「何を」と動詞の「どうする」を徹底的に検討する 検討した内容を特定（Specify）する この作業は、感覚としては「なぜなぜ分析」に近いものです。仕様を明確にするためには、上記の工程2を何度も繰り返すことが重要です。目的語と動詞を明確にしてさらに細分化していくので、この対応を前述のガイドラインに組み込んでおきましょう。 では実際にこの図の要求である「保存するデータ」の部分を使って、更にSpecify（特定）してみます！ 目的語が「データ」、動詞が「保存する」に該当します。 （AA01-1-1の仕様が細分化されます） 1. 要求を具体化する 「保存するデータ」に関連する仕様が何かを明確にします。具体的な仕様としては以下が考えられます。 データの種類（例：画像データ、テキストデータ、ビデオデータなど） データのサイズ（例：ファイルサイズ、許容量など） データの拡張子（例：JPEG、PNG、TXT、MP4など） データのファイル名（統一するのか、指定はないのかなど） データの例外処理（上記の仕様と一致しないデータの取り扱い） 2. 要求を満たすために対応する仕様を特定し、仕様欄に明記する 特定した仕様を詳細に明記します。 データの種類 データの種類はテキストデータのみとする テキストデータ以外はエラーとして処理する データのサイズ データのファイルサイズは1Byte ≦ X ≦ 10KByte の範囲とする 指定サイズ外のデータはエラーとして処理する データの拡張子 データの拡張子は.txtファイルのみとする .txtファイル以外はエラーとして処理する データのファイル名 ファイル名は以下のフォーマットとし、日時は送信時のタイムスタンプとする <YYYYMMDD>T<hhmmss>_data_<送信元IPアドレス>.txt 例：20000102T090807T012345_data_234.567.890.123.txt データの例外処理 エラーを検知したタイミングでのタイムスタンプを以下のフォーマットでファイル名にして保存する <YYYYMMDD>T<hhmmss>_err_<送信元IPアドレス>.txt ファイル内には送信元IPアドレスやOS情報を保存すること（形式は不問。ただし、実装した形式を追記すること） といった具合に要求の洗い出しと仕様の特定を行っていきます。 表に書き出すとこのようになります。 表にまとめた後は、他の仕様との整合性や、それぞれの仕様に曖昧な表現がないかを確認します。これにより、開発やテストの段階で誤解や抜け漏れが発生するリスクを低減できます。また、特定した仕様が要求を正確に反映しているか最終確認することは、プロジェクトの成功に直結します。全員が同じ認識を持って作業に取り組めるよう、仕様の明確化が重要です。 まとめ 今回の取り組みを通じて、以下の課題が解決されたことをご確認いただけたかと思います。 多くの要求から必要な情報を探すのが困難だった問題 　→ キーワードラベルを用いることで、要求を効率的に検索・特定できるようになりました。 進捗状況を把握しにくかった問題 　→ 仕様ラベルを活用することで、仕様の進捗状況を一目で把握できるようになりました。 仕様を実装する際に疑問点が生じる問題 　→ 仕様の特定プロセスをしっかりと行うことで、実装時の疑問や不明点が事前に解消されました。 これらのツールや手法を効果的に活用することで、複雑なプロジェクトにおけるトレーサビリティの強化や作業の効率化が期待できます。プロジェクトの進行においては、全体の把握と管理がスムーズに進むよう工夫することが重要です。仕様や要求の管理においてUSDMを取り入れ、チーム全体のコミュニケーションを円滑にすることで、より良い成果を生み出せるようになればと思います。 最後までお読みいただき、ありがとうございました。 USDMで初期品質を高めよう！～要求仕様を明確に記述するUSDMの紹介 Part1 初めまして、テストエンジニアのノッカーです。日々の業務の中で、いままでとは違う新しい経験ができましたので、その体験談を共有させていただきます。早速ではございますが、以下のような場面に遭遇したことはありませんか？要件定義(要求分析含む)の問題により、... 　続きを読む　 Sqripts 関連記事｜Sqripts USDMで仕様を上手にアウトプットしよう！～要求仕様を明確に記述するUSDMの紹介 Part2 みなさんこんにちは、ノッカーです。今回、USDMにかかわる記事の第二弾を書かせていただきます。前回の記事では、USDMを使用することで、要求や仕様を階層化することで、実装時の抜けや漏れ、誤りなどの問題が効果的に解決できることを紹介しました。今回は、USDMに... 　続きを読む　 Sqripts 関連記事｜Sqripts The post USDMで要求仕様書の品質向上！～要求仕様を明確に記述するUSDMの紹介 Part3 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 今回のテーマは、1on1においてコミュニケーション方法を使い分けるために「さまざまなコミュニケーション方法」を学びます。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ さまざまなコミュニケーション方法 我々にとってコミュニケーションは、とても当たり前に使う方法です。仕事に限らず、家族がいれば家族と、お店に出かければお店のスタッフと、なんらかのコミュニケーションを取っているからです。 では、自分の使っているコミュニケーション方法について、どう使い分けると良いか？ じっくり考えたことはありますでしょうか？ 当たり前な方法だと、慣れてしまっていてあまり意識することもなく、そう言われるとなかなか答えに迷ってしまうかもしれません。しかし、みなさんが仕事でコミュニケーションを使っているなら、いくつかの方法を使ったことがあるはずです。代表的なコミュニケーション方法には以下があります。 コンサルティング ティーチング（トレーニング・メンタリング） カウンセリング ファシリテーション コーチング 1on1 早速それぞれの方法を見ていきましょう。 コンサルティング コンサルティングは、企業などの課題を洗い出し、解決策を助言する方法です。お客さまは現在進行系で困っており、コンサルタントに具体的なアドバイスを求めます。「具体的」というのは、成功率の高いアクションプランです。 たとえば、クライアントが「プレゼンテーションがうまくできない」という課題を持っていれば、コンサルタントであるあなたは「相手の目を見て堂々と話してください。そして・・」と具体的で、成功確率の高い方法を伝授するでしょう。 ティーチング ティーチングとは、知識やスキルを教える方法です。先輩から教えてもらったり（メンタリング）、外部の講習を受けたり（トレーニング）、著名な人の本を読んだり動画を見たり（ラーニング）、さまざまな形で学んでいるのではないでしょうか？ たとえば、クライアントが「プレゼンテーションがうまくできない」という課題を持っていれば、ティーチャーやトレーナーは「まずこうします。そして次にこうして・・・」と手本を見せてくれたり、実際に繰り返し練習させてくれるでしょう。 カウンセリング カウンセリングとは、専門的なスキルを持ったカウンセラーとの対話によって、相談者が抱える悩みや不安の解決を支援する方法です。カウンセリングはコーチングの元になったという説もあり、カウンセラーは相手の話をじっくり聞くので、過去に向かって掘り下げていくスキルとも言えます。 カウンセリングは、「心理カウンセリング」など、医療に近い場所にある方法と言えるため、専門外の人が手を出すと相手の生命に関わる危険性が伴うため注意が必要です。よって、国際コーチング連盟（ICF）のコアコンピテンシーにも「必要に応じて、クライアントに他の支援的職業の専門家を紹介している」という項目があります。自分にできないことを支援してしまう危険性をさけるための項目です。 たとえば、クライアントが「プレゼンテーションがうまくできない」という課題を持っていれば、カウンセラーは「お困りごとを伺いましょう」と相手の話をよく聞いてくれるはずです。 ファシリテーション ファシリテーションは、会議を効率よく、さらにその成果も高くなるように進行する方法です。議論が必要なら参加者を巻き込みながら思考を広げてもらい、結論が必要なら散らかった論点を整理しながらゴールへと導いていきます。 たとえば、クライアントが「プレゼンテーションがうまくできない」という課題を持っていれば、「プレゼンテーションを成功させるために、どの順番でどう話していきましょうか・・・」とファシリテーターは段取りを整えてくれるでしょう。 コーチング コーチングは最近話題になってきた方法です。海外の企業だと社内コーチがいることが当たり前になり、国内の企業でも採用が進んできています。コーチングはスクールによって思想が分かれるのですが、世界最大規模のコーチング団体である 国際コーチング連盟(ICF)の説明 によると以下のようになっています。 コーチングとは、思考を刺激し続ける創造的なプロセスを通して、クライアントが自身の可能性を公私において最大化させるように、コーチとクライアントのパートナー関係を築くことである 国際コーチング連盟(ICF) ICFは権威的な雰囲気が強いので、書いていることが複雑でわかりにくいのですが、要点をまとめると「クライアントとパートナー関係を築き、クライアントの可能性を最大化すること」という感じでしょうか。ICFはコーチの成果に対するコミットメントをあまり求めない傾向があるようなので、「最大化する」というより「コーチングをすれば最大化されるであろう」というニュアンスが近いかもしれません。 たとえば、クライアントが「プレゼンテーションがうまくできない」という課題を持っていれば、「どうすれば相手に伝わると思いますか？」と相手に問いかけます。この方法だと答えを教えてくれるわけではないので、答えがほしいならコンサルタントを雇うべきでしょう。コーチはあくまで、「クライアントの中に答えがあるはず」という立場でクライアントに接します。 1on1 1on1はもうIT業界では市民権を得た方法だと思います。もともとはアメリカのシリコンバレーの企業文化としてあったようですが、『 ヤフーの1on1―――部下を成長させるコミュニケーションの技法（ダイヤモンド社） 』などで紹介され、国内にも瞬く間に広がっていきました。 1on1はマネジメント手法なので、前提として上司と部下の関係性がありますが、情報交換としての1on1など、通常の会話や対話に近い形でのやりとりもめずらしくありません。また、1on1はコミュニケーションの方法とはいえ、具体的な手順が体系的にまとめられておらず（いずれはまとめられるのかもしれませんが）、人や環境によって大きく違う場合もあるでしょう。 たとえば、部下が「プレゼンテーションがうまくできない」という課題を持っていれば、上司はコンサルティング、ティーチング、メンタリング、コーチングなど、さまざまな方法でごちゃまぜになった形で対応します。そのため、1on1はとても難しい方法とも言えます。その影響か、1on1は簡単にはじめられますが、なかなか文化にならない、話が盛り上がらないといった悩みも多く聞きます。 さまざまなコミュニケーション方法 コミュニケーション方法例 これまでに解説したコミュニケーション方法を一覧で整理してみましょう。たとえば、クライアントが「プレゼンテーションがうまくできない」という課題を持っていれば、コミュニケーション方法ごとに以下のような違いが生まれます。 コンサルティング： 「相手の目を見て堂々と話してください」 ティーチング： 「こうやります」、「こうやってみてください」 カウンセリング： 「お困りごとを伺います」 ファシリテーション： 「どういう順番で何を話していきましょうか」 コーチング： 「どうすれば相手に伝わると思いますか？」 1on1： カウンセリング以外のごちゃまぜ 課題は同じなのに、ふるまい方に大きな違いがあることがわかります。 このように、それぞれのコミュニケーション方法のプロフェッショナルは、それぞれの立ち位置に立ってコミュニケーションを取ります。極端な例ですが、コーチングを行うコーチがアドバイスをしたらもうそれはコーチングではなくなります。 相手によってはアドバイスも必要でしょうが、その場合は、コーチの帽子を脱いで、コンサルティングなどの帽子をかぶってアドバイスをする必要があります。そうしなければ、コーチングから手に入れられる恩恵を得られなくなってしまうからです。 ＊ 今回は、さまざまなコミュニケーション方法について解説しました。それぞれの違いも明確になったはずです。 次回はこれらのコミュニケーション方法を、相手のタイプに合わせてうまく利用する方法を解説していきます。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ The post 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ first appeared on Sqripts .

はじめまして！テストエンジニアのずっきです。 昨年、異業種からQA業界に転職し、現在はQA事業に携わる部署でテスト実施および設計業務に従事しています。将来は、テスト計画から完了に至る一連のテストプロセスを管理できるプロジェクト管理者を目指して、日々精進しながら業務に取り組んでいます。 今回は、そんな私が異業種からQA業界へなぜ転職を志したのか…転職においてどのような不安があったのかを、私と同じく異業種からQA業界への転職を考えている皆さんの一助となるようにブログに綴らせていただきます。 これまでの経歴について 私は、管理栄養士として病院勤務経験を経て、異業種の品質保証業界に転職しました。現在は、テスト実施および設計に携わり、高い品質保証を提供できるQAエンジニアになるべく奮闘しています。 前職について 職種 ：病院管理栄養士 業務内容 ：病院食の献立作成、栄養管理、栄養指導など 異業種からQA業界への転職 自己紹介にも記載した通り、長らく管理栄養士として従事していましたが、将来のキャリアパスに不安を抱くことが多く、以前から興味があったITエンジニアへの転職を考えるようになりました。ITエンジニアに関するスキルや経験がなく、強みとなるものがない…このような理由から行動に移せずにいましたが、生活環境が変わった節目に、ITエンジニアへの転職を強く志すようになりました。 転職に当たっての不安要因と解消法 異業種への転職にあたって「自分に適性がなかったらどうしよう…」「想像していた仕事と違ったらどうしよう…」「自分に務まるのか…」など、さまざまな不安がありました。そこで、短期のプログラミングスクールに通い、実際に体験したことで、さらにエンジニアとして活躍してキャリアを築きたいと強く思うようになりました。 スクールでは、基本的なプログラミングスキルを習得しましたが、最大の収穫は「自分にエンジニアとしての適性があるかどうか」を自覚できたことです。特に、転職活動中に重視していたのは、前職での思考や能力が活かせるかどうかでした。異業種かつ未経験の私にとって、何が武器になるのかを模索した結果、前職で培った思考や能力がQAエンジニアとして最適であると実感しました。 前職の経験がQAエンジニアとしてどのように役立っているかについてお話しする前に、まずはQAエンジニアの仕事内容や役割について簡単に確認しましょう。 QAエンジニアとは QAとはQuality Assurance（品質保証）の頭文字です。QAエンジニアとは文字通り、システムやソフトウェアの品質管理業務を通じて、品質を保証するエンジニアです QAエンジニアの仕事内容とは？年収や必要資格を解説 つまり、普段使用しているアプリケーションやシステムが問題なく使用できているのは、開発した製品が市場に出る前に、テストされて品質が保証されているからです。 QAエンジニアの役割 ITシステムやアプリケーションはSEやプログラマーなどのITエンジニア職により設計・開発が行われます。QAエンジニアは、開発されたシステムやアプリケーションが設計通りに作られ期待通りに動作するか、使いやすい仕組みかを確認し、問題がある場合は是正に繋げる役割を持っています。 QAエンジニアとは？仕事内容や将来性を解説 異業種時代のこんな思考、習慣、経験が役に立つ！ 1. 学習習慣 前職では、病院で栄養士として患者さんの栄養管理業務に従事しておりました。栄養管理業務では、病気に関する知識や薬と食事の相互作用、禁忌などの医療に関する知識が必要不可欠です。そのため、日々の生活の中で「学習時間」を確保する習慣を確立しました。 学習習慣の形成には、下記のようなメリットがあります。 習慣化により、集中して学習に取り組むことができる 学習することに抵抗がなくなる 自分に適した学習方法が確立される ▼学習習慣がなぜ重要なのか？▼ 専門性を高めるためには、「学習」と「経験」が重要だと感じてます。特に学習は参考書や動画教材などで効率的に知識を吸収できる方法です。 異業種・未経験から現在の品質保証会社に入社し、様々な専門スキルの重要性を実感しました。特に、QAエンジニアの知識を提供する「JSTQB Foundation Level資格」は、実施業務や設計業務に従事する者にとって基礎的な知識が体系的に記載されており、ＱAエンジニアであれば取得推奨の資格です。私もこの資格を取得しましたが、テスト活動がどのような要素で構成されているのかを理解することで、業務の目的を明確に認識できました。また、テスト設計時のテスト技法にも役立てています。資格を取得することでスキル向上だけでなく、第三者に自分のレベルを証明できるメリットもあります。 2. リスク管理 病院という特殊な場所では、ミス（誤り）が患者の生命に直結します。たとえば、アレルギー物質の混入を予防するには、混入しにくい環境を整える必要性があります。そのためには、リスクの識別・調査・対策を行う必要があります。 ▼リスク管理がなぜ重要なのか？▼ 品質保証でも、将来起こりうるリスクを過去の事例や経験から推測して、対策や予防を行うことでリスクを回避・軽減することができます。また、プロダクトリスクだけでなくプロジェクトの進行上のリスクも発生します。たとえば、テスト実施業務において計画していたスケジュールと実際の進捗に乖離があり、期限までにテストが完了できないといったプロジェクトリスクが考えられます。テスト実施の早い段階で、期日までに完了が困難であると識別できれば、原因を調査します。たとえば、テスト実施者の経験不足な場合もあれば、テスト対象に不具合が多発していて実施業務が中断している場合もあるでしょう。適切な対策を講じてリスク回避や軽減を図ることができます。 3. 情報収集力 前職の業務の一つに、「栄養管理」という業務がありました。栄養管理とは、入院患者の栄養状態や食事摂取状況をもとに、病状に合わせた栄養評価を行い、食事内容や食習慣のアプローチを決定して栄養状態を改善することが目的です。 栄養状態を改善するためのアプローチを決定するにあたり、電子カルテから現在の栄養状態を正確に確認するだけでなく、症例と比較して今後の栄養状態を予測し、対策を考えることも必要です。客観的なデータだけでなく、患者さんからの聞き取りを行うことで、より個々に合わせたアプローチ方法の策定に役立てることができます。 ▼情報収集力がなぜ重要なのか？▼ QAエンジニアは、テスト活動全体のプロセスに関与します。テストプロセスは、計画、分析、設計、実装、実行などのテスト活動で構成されています。例えば、テスト設計では対象システムの仕様把握を行いますが、実際の現場では完全な仕様書がないことが多いため、テスト設計者として仕様書に記載のない仕様や、欠落していたり曖昧な部分を特定することも重要です。仕様の欠落、矛盾、曖昧さに対して、すぐに開発者や管理者に確認を求めるのではなく、他のテストベースを参照したり、あるいは開発者側で作成されたシステムアーキテクチャやコードを分析し、自分で不明点を補うことが求められる場合もあります。また、既存システムの回帰テストでは、過去のドキュメントやステークホルダーとのやり取りからシステムに関する情報を収集することもあります。収集した情報は、製品の品質に直結するため、最新バージョンの仕様であるかの確認を慎重に行う必要があります。 4. 文章力 前職の業務の一つに「栄養指導」という業務がありました。文字通り、患者さんの病態に合わせた食事の取り方について指導・アドバイスを行います。栄養指導でやり取りした内容や目標設定は、200文字程度でまとめてドキュメント上に記載します。その際に、重要な情報を簡潔にまとめ、第三者も理解できるように記載することが重要でした。また、次回の栄養指導時に評価できるように定量的に情報を記載する能力が求められていました。 ▼文章力がなぜ重要なのか？▼ テスト実装フェーズでは、明確なテスト手順や期待される結果の記載が必要です。不明確な手順や曖昧な期待結果では、テストの結果として合格/不合格の正しい判定ができず、誤った判定をしてしまう可能性があります。そこで重要になるのが「文章力」です。 下記例を参考に文章力の重要性を解説します。 例）「自動販売機に硬貨を投入したらパネルに投入額が表示される」といった機能 テスト手順 期待結果 手順1. 10年前に買ったお気に入りの財布から硬貨を出す 手順2. 硬貨を入れる 手順3. パネルの表示を確認する 金額が表示されていること 上記のテスト手順と期待結果には修正が必要な個所がいくつかあります。 不要な手順 ： テストの目的は対象機能の表示確認（投入した金額がパネルに表示されること）であり、手順1の「10年前に買ったお気に入りの財布から硬貨を出す」はテストの目的に関係ない情報であり、余計な内容です。不要な手順や冗長な文章は、テスト実施者を混乱させ誤った結果を招く可能性があります。 不明確な定義 ： 手順2の「硬貨を入れる」では、具体的な硬貨の種類が明記されていません。「日本円」「USドル」あるいは「ゲームのコイン」など、硬貨の種類が不明瞭です。硬貨の種類が明確でないと、誤った硬貨が使われた場合にテストが不合格になる（偽陰性）可能性があります。 期待結果の曖昧さ： 期待結果の「金額が表示されていること」も漠然としています。正確な金額（例えば「10円」と表示されること）を指定しないと、「10円」を投入して「100円」と表示されても合格になってしまう可能性があり、偽陽性の結果を招くことがあります。 上記を踏まえて修正したテスト手順と期待結果は下記になります。 観点 前提条件 テスト手順 期待結果 表示確認 ・硬貨を準備しておく ・パネルの初期値が「0」であること 1.自動販売機の硬貨投入口に10円硬貨を1枚入れる 2.パネルの表示を確認する 10円と表示されていること この修正により、手順が明確になり、期待結果も具体的で正確な内容となります。 このように、文章力を駆使してテスト手順を適切に表現することで、誤解や誤判定を防ぎ、テストの信頼性が向上します。 文章力の向上は、論理的思考力にもつながります。テストエンジニアにとって論理的思考が重要である理由について、過去のSqriptsに興味深い記事が掲載されていますので興味のある方は、ぜひ以下のリンクをご参照ください。 ※参照： テストエンジニアのための論理スキル[再]入門 [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。第1回の今回は、論理スキルが重要である理由、身につけ... 　続きを読む　 Sqripts 関連記事｜Sqripts まとめ｜ 推奨スキル/資格 本記事では、前職で培ったスキルや考え方が、どのようにQAエンジニアとして活かされているかについてお話しましたが、QAエンジニアを目指すにあたっては、専門知識があることに越したことはありません。 QAエンジニアの知識を提供する「 JSTQB Foundation Level資格」 は、実務経験が全くない私でも取得することができ、難易度もそれほど高くありません。QAエンジニアに興味を持っている方や、これから目指す方は資格取得を目指してみてください。 JSTQB学習のススメ #1 〜JSTQBとは〜 みなさん、はじめまして！　ゆーすけです。「ブログにテスト領域でなんか書いてー」とミッションがおりてきまして、何が書けるかなー、って考えてみました。テストエンジニアといえばテスト技術、テスト技術の資格といえばJSTQB。そういえば、デジタルハーツって「JS... 　続きを読む　 Sqripts 関連記事｜Sqripts 　　　　　　　　　　　　　 非テストエンジニア、JSTQB（FL）を受けてみた こんにちは！WEBコンテンツ制作者のくるみです。今回はソフトウェアテストの知識が浅いWEBコンテンツ制作者が、JSTQB認定テスト技術者資格（Foundation Level）に合格したお話です。動機現在、私はWEBコンテンツ作成に従事していますが、今年の春の組織変更により所... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 異業種から未経験でQA業界へ転職！前職の経験はQAエンジニアとしてどのように活かせるのか？ first appeared on Sqripts .

こんにちは、セキュリティエンジニアの河村です。 今回は白揚社出版の｢情報セキュリティの敗北史｣の書評をお届けします。 情報セキュリティの敗北史 ：アンドリュー・スチュワート 著　小林啓倫 訳（白揚社） ▼書籍情報はこちらです。 情報セキュリティの敗北史 サイバー攻撃の脅威はなぜ増え続けるのか?   相次ぐ個人情報の大規模漏洩、米・中・露による国家主導のハッキング、企業・病院を標的にして猛威を振るうランサムウェア…   IT社会が急 　詳細はこちら　 www.hakuyo-sha.co.jp 関連情報 本の概要 本書は、情報セキュリティに関する出来事を、コンピューターの黎明期である1940年代から現在に至るまで、時系列に沿って解説しています。現代のホットなテーマも、過去に遡ってその文脈を理解することで、より深く本質を捉えることができると感じました。また、情報セキュリティの経済学など、通常の教科書ではあまり詳しく取り扱われないテーマにも触れられており、非常に興味深い内容となっています。 章ごとの概要 以下に、本書の各章で特に注目したい内容をピックアップしてご紹介します。 1 情報セキュリティの｢新次元｣ 第二次世界大戦前後のコンピューター黎明期、ENIACなどのエピソードから始まります。この時代のコンピューターにはネットワークは存在しませんでしたが、情報の閲覧に権限設定があったり、「タイムシェアリング型」という形で、原始的な情報セキュリティが存在していたことがわかります。 2 研究者たちの期待、成功、失敗 主に1970年代までの基礎研究について述べられています。1970年に提出された「ウェア・レポート」では、 大規模なソフトウェアシステムにおいては、エラーや異常が完全に無いことを検証するのは事実上不可能 情報セキュリティの敗北史(P.28) 攻撃者がそのような抜け穴を計画的に探し、利用することも考えられる 情報セキュリティの敗北史(P.28) といった、脆弱性とクラッキングについての洞察が記されており、その先見性には驚かされます。この時代、これらは理論レベルでの研究に留まっていましたが、国家秘密として扱われるなど、その戦略的重要性はすでに認識されていました。 また、1974年にはサルツァーとシュローダーが情報セキュリティの三要素「CIA（機密性、完全性、可用性）」や「フェイルセーフなデフォルト」などを提唱しています。 3 インターネットとウェブの誕生、不吉な予兆 冷戦期に、国家レベルで通信の可用性を確保するため、人間の脳の構造をヒントに、パケットを用いた原始的な通信手段がランド研究所のポール・バランによって1960年代に「分散化とパケットスイッチング」として提唱されました。これが基となり、ARPANETが形成されました。ARPANETの発展に伴い、@を用いたメールシステムが導入され、RFCやTCP/IPなどネットワークの基礎が築かれました。 このように、ARPANETは発展し、やがて現在のインターネットへと進化していきます。しかし、1983年にはフレッド・コーエンによって世界初のコンピュータウイルスが作成され(P.62)、1990年にはロバート・T・モリスがインターネットに甚大な被害をもたらすウイルスを作成・拡散し、史上初めてインターネット関連の有罪判決を受けることとなります(P.66)。 UNIXやC言語も1970年前後に開発されました(P.70)。 1990年前後にブラウザが一般化し、情報セキュリティの重要性が急速に高まりました。ネットワーク脆弱性スキャナSATANが開発されましたが、これは攻撃にも利用できるため、賛否両論が巻き起こりました(P.82)。 4 ドットコム・ブームと魅力的なフィードバック・ループ 1990年代、インターネットの普及に伴い、インターネット関連株が過剰に上昇するドットコム・ブームが巻き起こりました。 この急速な発展に伴い、JavaやActiveXなどのモバイルコード技術が普及しましたが、これらには多くの脆弱性が発見されました。また、サーバサイドの脆弱性として、SQLインジェクションなどのコマンドインジェクションが問題視されました。SSLプロトコルも登場しましたが、根本的な解決には至りませんでした。 アンダーグラウンドマガジン「Phrack」の共同編集者の一人であるハッカー「Route」は、90年代に活躍し、TCP/IPプロトコルスイートを攻撃しました(P.96)。彼が広めた「SYNフラッド攻撃」は、プロトコルのセキュリティ上の弱点を示すものでした(P.98)。 Phrack 　http://www.phrack.org/ こうした背景から、イーベイやヤフーなどの大手企業はセキュリティ確保が困難になり、セキュリティの重要性が増大したものの、多くの企業にとってそれは難題でした。ここで成長したのが情報セキュリティ産業です。しかし、企業が提案したスキャナーやファイアウォールには多くの問題がありました。例えば、ファイアウォールによる偽陽性の検知が顧客のセキュリティ意識に悪影響を与えることがありました。 また、ハッカーに対する一種の崇拝的感情が生じ、フィードバック・ループが形成されたのもこの時期です。エクスプロイトを投稿する文化ができ、脆弱性に関する知見が共有される一方で、スクリプトキディ（技術的に未熟なハッカー）の増加という問題も浮上しました(P.116)。こうしてセキュリティ業界とハッカーが共に成長する一種の共生関係が生まれました(P.117)。 この時期、ハッカーとセキュリティ業界の原動力として「恐怖」が非常に強力であることが明らかになりました（FUD: fear, uncertainty, doubt）。この動向に否定的な意見もあり、マーカス・J・レイナムは「ハッキングがクール」という考え方を「コンピュータセキュリティにおける最も馬鹿げた考えの一つだ」と述べています(P.121)。 5 ソフトウェアセキュリティと｢苦痛なハムスターホイール｣ ドットコムブームの間に生まれたフィードバック・ループにより、企業がパッチを適用しなければならない新たな脆弱性の数は増える一方でした。「ペネトレイト・アンド・パッチ（脆弱性を見つけてパッチを当てる）」という方法論では、企業は進展せず、常にパッチの適用が求められる状況が続き、ある専門家はこれを「苦痛なハムスターホイール」と呼びました(P.124)。 1998年頃には、基盤となるOSが強固なセキュリティサポートを提供していない場合、Webサーバーやアプリケーションがセキュリティを実現できるという考え方が誤っていることが認識され始めました(P.125)。 この頃、ほとんどセキュリティサポートを提供していなかったWindows OSは2000年代初頭に大規模な攻撃を受けました。2001年のCode Redや同年のNimdaなどの大規模攻撃は、企業にマイクロソフト製品の使用を再考させるきっかけとなりました(P.128-129)。 こうした中、2002年にビル・ゲイツが全社宛てに送信したメールをきっかけに、マイクロソフト社は「新しい機能の追加に注力する」から「設計段階からセキュアであり、デフォルトでセキュアであること」へと基本哲学を変更し、結果的に大成功を収めました(P.132-134)。 こうした対策がなされた後も、Slammer、Blaster、Welchia、SoBig、Sasserなどの大規模インターネットワームが発生し、暗い未来を予感させるものでした(P.139)。経済的損失の大きさや、少人数で作成できる点から、感染したコンピュータのネットワークが国家レベルの攻撃に利用されることが明白になりました。 マイクロソフトはパッチ適用に関して、毎月第二火曜日にサービスパックとしてまとめて提供するようになりました(P.146)。しかし、ハッカーはパッチをリバースエンジニアリングして脆弱性を特定し、これが新たな攻撃のきっかけとなることもありました(P.146)。 2004年、マイクロソフトは「セキュリティ開発ライフサイクル(SDL)」の運用を開始しました(P.148)。このアプローチは、セキュリティを実装する際のベストプラクティスとして広く採用され、アドビやシスコにも影響を与えました(P.149)。 一方、オラクルは異なるアプローチを取った結果、マイクロソフトは成功し、オラクルは失敗したと言えます(P.153)。フィル・ヴェナブルズは「必要なのはセキュリティ製品ではなく、セキュアな製品」だと指摘しました(P.155)。この方法論を徹底したアップルも、iPhone 5s以降に搭載されたセキュリティチップ「Secure Enclave」で成功を収めました(P.156)。このチップは、セキュリティ特化のハードウェアをメインプロセッサから独立させ、スマートフォンの盗難リスクに対する優れた対策となりました。 各社がセキュリティに注力する中、ハッカーにとって脆弱性を攻撃するコストは増大し、ターゲットは次第に人間の脳へと移行していきました。 6 ユーザブルセキュリティ、経済学、心理学 1999年、プリンストン大学のエドワード・フェルテンは「豚のダンスとセキュリティのどちらかを選ぶよう迫られたら、ユーザーは常に豚のダンスを選ぶだろう」と述べました(P.160)。一般的に、ユーザーのセキュリティ意識は低いものとされてきました。 セキュリティは最も弱い部分に合わせて全体の強度が決まるため、強固なセキュリティシステムも、管理者の弱点により全体が脆弱になります。 「ユーザブルセキュリティ」の研究は1999年には始まっており(P.162)、優れた暗号化プログラムがあっても、ユーザーインターフェースの設計が悪ければ、目的を達成できないというユースケースが示されています。ユーザーは通常、セキュリティに関心がなく、セキュリティに関する設定において、ユーザーに判断させないことが望ましいとされました。これは2005年のSOUPS（Symposium on Usable Privacy and Security）での研究発表で明らかにされました(P.165)。 フィッシングは2003年に新しいタイプの攻撃として言及され、2005年頃から注目を浴びるようになりました。(P.167) ファイアウォールによって多くの攻撃はブロックされるようになりましたが、メールはファイアウォールを通過するため、ハッカーはこれを利用しました。 パスワードは1961年にMITで開発された「互換タイムシェアリングシステム」で初めて使用されました(P.173)。パスワードは本来シンプルなセキュリティ機構ですが、ユーザーの心理的問題から複雑化し、さまざまな問題が発生しています。 グラフィカルパスワードや生体認証などの代替技術は、パスワードよりも優れた認証手段を目指していますが、使いやすさの面でまだ完全な代替にはなっていません。 ケンブリッジ大学のセキュリティ工学教授ロス・アンダーソンは情報経済学への扉を開きました(P.183)。2001年には「なぜ情報セキュリティの実現は困難なのか—経済学の視点から」が発表されました。 心理学の観点では、フィッシングやソーシャルエンジニアリングを行っていたハッカーは、セキュリティ研究者を大きくリードしていました。 経済学的には、情報セキュリティを高めることが必ずしもプラスであるとは限りません。過剰なセキュリティを達成するためのコストが、セキュリティリスクの期待値を上回る場合もあります(P.197)。情報セキュリティの分野では、このようなコストとリスクのバランスが考慮されていないことが多いです。 7 脆弱性の開示、報酬金、市場 2000年代初頭には、ゼロデイ脆弱性を公表することが必要だというコンセンサスがありました(P.206)。しかし、脆弱性をソフトウェア企業やハッカーが際限なく探し出し、一種の「デススパイラル」に陥っているとも言えます(P.208)。 ゼロデイ脆弱性の公表の是非は、パッチが存在する脆弱性を悪用するハッカーが大勢いるのと、パッチが存在しない脆弱性を悪用するハッカーが少数いるのとで、どちらがより悪質かという問題です(P.213)。これは「ディスクロージャ」の問題です。 かつての脆弱性を完全に公表するフルディスクロージャから、責任ある開示「レスポンシブル・ディスクロージャ」へと徐々に変化しました(P.216)。 ゼロデイ脆弱性は攻撃にも防御にも利用されます。NSA（アメリカ国家安全保障局）は2014年に公表されたHeartbleed脆弱性を、少なくとも2年前からゼロデイ脆弱性として攻撃に利用していたと非難を受けています(P.220)。NSAには、米国の敵国への攻撃と国内のコンピュータセキュリティの確保の二つの使命が与えられていました。 2010年代に入り、多くの企業がバグ報奨金制度を導入しました。これにより、研究者は報酬を得るために、企業にとって有益な脆弱性を探すインセンティブが働きます。 こうした硬直した時代に、ハッカーはアピールのための「スタントハッキング」を発明しました(P.233)。これは、自動車や航空機、医療機器など日常に使用される機器に対するハッキングを行い、その結果を公表するものです。これにより、セキュリティの脆弱性が一般人にとって恐ろしい脅威であるという認識が広まりましたが、実際にはハッカーたちが自己利益のために誇張し、歪曲した幻想と言えます。 8 データ漏洩、国歌によるハッキング、認知的閉鎖 ここでは、情報セキュリティの3つの汚名について述べます。 一つ目は「データ漏洩」です(P.238)。データ漏洩により流出した金融取引や既往歴などの個人情報は、ブラックマーケットで売買され、犯罪者によって成りすまし犯罪などに利用されます。この種の攻撃では、被害を受けた企業と利用者の両方に多大な負担がかかります。 二つ目は「国家によるハッキングがもたらす害」です(P.250)。中国61398部隊によるオーロラ攻撃をきっかけに、APT（Advanced Persistent Threat）という言葉が生まれました。中国と同様、ロシアもハッキング能力向上に多大な資源を投入しており、「ファンシーベア」はロシアの軍事諜報機関GRUと関連する大規模ハッキンググループです。彼らは大統領選挙時にヒラリー・クリントンのホームページに侵入し、改ざんするなど積極的に政治的主張を行いました。中国、ロシア、米国が到達したハッキング能力は、個人では到底到達できない領域です。 三つ目の汚名は「情報セキュリティ分野における『認知的閉鎖』によって生じる機会費用」です(P.264)。閉鎖的なコミュニティ内で構築された虚偽の現実（エコーチェンバー）が、情報セキュリティ分野でも見られるという問題です。1983年にUNIXの共同開発者ケン・トンプソンは、「マスコミやテレビ、映画が、破壊者を『天才的な若者達』と呼び、ヒーロー視する」ことが、「極めて危険な状況を生みつつある」と警鐘を鳴らしていました(P.266)。バグ報奨金制度などを通じて、この傾向はさらに顕著になったと言えます。 9 情報セキュリティの厄介な本質 セキュリティに関する主張には反証可能性がないという問題があります(P.276)。効果のないアドバイスを反証することが難しく、NISTの「組織と情報システムのためのセキュリティおよびプライバシー管理策」などは500ページを超える膨大な量です。その結果、混乱と非効率が生じ、情報セキュリティを専門とする企業ですら、自社のセキュリティ維持が困難になっています。 セキュリティ標準の共通目標は、情報セキュリティの特定の側面において、複雑さを軽減し、より管理しやすくすることです(P.281)。情報セキュリティ分野では、統計の乱用が長年問題となっています(P.284)。恣意的に操作された統計を用いて、実態よりも悪く見せる逆インセンティブが存在します。 コンピュータセキュリティの根本的なジレンマとして、セキュリティを望む人々が、セキュリティを評価・改善するための判断能力に欠けていることが挙げられます(P.294)。 情報セキュリティにおける攻守のバランスは、今後の課題となっています。現在、攻撃する方が簡単であり、守る方が困難という状況が続いています。 「多層防御」は、層が多ければ多いほど良いという考え方が一般的ですが、これがかえって複雑性を増し、セキュリティに悪影響を及ぼすこともあります。 本を読んで 本書を読み進める中で、現在問題となっているさまざまなセキュリティ上の課題も、実は突然現れたものではなく、長い歴史の中で徐々に形成されてきたことがよくわかりました。情報セキュリティの問題は、その時々の技術や社会の動向と密接に関連しており、時系列を追うことで、問題がどのように発展し、どのように解決されてきたかを理解する手がかりとなります。 また、本書を通じて気づいたのは、情報セキュリティの教科書の多くが、依然として情報セキュリティ分野に閉じた視点で書かれていることです。経済学や心理学など、他分野の視点を取り入れることが、より実践的で効果的なセキュリティ対策を構築するために重要であると感じました。現代のセキュリティ問題は、技術的な側面だけでなく、ユーザー行動や組織の経済的動機といった多様な要因が絡んでおり、これを無視することはできません。 先日起きたKADOKAWAやニコニコ動画に対する攻撃も、本書で提唱されている「情報セキュリティの3つの汚点」から解釈することができます。データ漏洩、国家によるハッキング、そして認知的閉鎖といった問題は、現代のセキュリティリスクの根本的な要因として依然として存在しており、これらを理解し、対策を講じることが求められています。 本書は、やや難解な部分もありますが、情報社会の未来を見据えたキャリアを積みたい人にとっては、非常に価値のある内容です。情報セキュリティの歴史的背景や、技術的な進展だけでなく、経済学や心理学といった多様な視点が取り入れられており、現代のあらゆる情報社会での活動に活かせる内容でした。読んで損をすることは決してありませんので、ぜひ手に取ってみてください。 『｢技術書｣の読書術』書評 こんにちは、セキュリティエンジニアの河村です。この度初めてsqriptsに記事を執筆することになりました。数回にわたって技術書を紹介していく予定です。今回は技術書を読むための本、『｢技術書｣の読書術』の書評を行います。本の概要『｢技術書｣の読書術』は、数々の... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 『情報セキュリティの敗北史　脆弱性はどこから来たのか』書評 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 第8回目のテーマは「1on1」です。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1 〜 簡単だけど難しい1on1 前回のおさらい 前回までは、ファシリテーション、コーチングと解説してきました。この連載で紹介する最後のコミュニケーション方法は「1on1」です。 1on1は、今ではよく使われる方法ですが、学びにくい方法とも言えます。そういった理由と学び方、使い方をここでは解説したいと考えています。 心理的安全性のための対話 心理的安全性を生み出すための対話 我々は会話だけでなく、討論、議論、対話とさまざまな方法で相手と情報交換します（参考： 誤解されがちな議論と対話の違い｜CULTIBASE Radio｜Management #6 ）。 会話や雑談は、お互いの印象を良くする効果があります。特に理由なく「天気がいいですね」なんて言いません。なにかしらのつながりを求めて会話を行っているはずです。 討論はどの主張が正しいかを決めるもので、議論は意思決定を行うためのものです。どちらも結論を求めるので、勝負をつけるためのコミュニケーションと言えます。 ファシリテーションの回でも解説しましたが、現在は多様な個性が集まるため、正解のない世界が広がりつつあります。この世界ではなかなか白黒つけられません。しかし前に進まなければならない現実もあります。 このときに役立つのが対話です。 対話によってお互いの主張や考えを明確にして、心理的安全性を高めていきます。 対話とは何か？ 対話はお互いをわかり合うためのツールです。簡単にまとめると 私はこういう考え方をしています。 あなたはこういう考え方をしています。 お互いの考え方には違いがあります。 という情報交換になります。お互いの情報を交換し、その違いを理解するだけですが、交換により新しい情報を双方が得ます。これによって、相手の理解が深まり、選択肢が広がり、勝ち負けでは決められない物事を前に進める準備ができます。 そして、我々はこの状況を踏まえて、結論を出さなければなりません。 お互いのことを理解した状態を作り、それを踏まえた上でどうするかを決める必要があるのです 。 このあたりはリーダーシップの話にも通じるため、ここでは深く説明しませんが、対話によって対話後の議論が少しスムーズになります。対話の実践例を以下に紹介します。ここでは「関係性がうまくいっていない二人」に対して対話を促しています。 Aさん「私はあなたの◯◯がとても嫌だと思っている」 Bさん「私こそあなたの□□を不愉快に感じています」 私「お互いにそう思っていることがわかりましたね。では、このわかった情報をふまえて、もう一度相手のことをどう感じるか教えてください」 Aさん「・・・。相手もそう思っているとは思わなかった」 Bさん「こちらも相手が同じように思っているように思わなかった」 私「また理解が進みましたね。では繰り返し、この情報を踏まえて・・・（繰り返していく）」 お互いがお互いを100％理解するのは不可能です。なのに、我々は「理解したつもり」になりやすい。はじめのうち、それは小さなすれ違いでしかないかもしれませんが、のちに大きな間違いを生み出していきます。よって、このような対話を活用し、お互いが歩み寄り、解決策への協力体制を築いていきます。 1on1と対話 1on1は、対話を中心に相手の成長を支援する方法です。主に人材育成の手段として使われ、企業内だと上司部下の関係性の中で成果を追求していく方法と言えます。 上司と部下という特性上、コーチングのようなパートナーシップを作るのは難しいですが、リーダーやマネジメントのあり方が変化している時代にあわせて、マネジメントとメンバー間に対等な関係性を作ろうとする企業も多くなってきました。「マネージャ ＝ 管理・偉い」 といった価値観も「マネージャ ＝ 支援・対等」へと変わろうとしています。 対等な関係性を意識するため、1on1は基本的に部下が話したいことを話す時間になります。ただ、1on1の特性上、成果を求めるものになるので、1on1をやる意味や、期待する成果や効果は、1on1をはじめるまえに合意しておきます。そうすることで、1on1がただの雑談になるのを防ぎ、期待する成果を出すための場に変わります。 1on1で話す内容は守秘義務によって守られています。安心安全な場を作るために、1on1で話した内容はお互いに他言すべきではありません。中には共有した方がいい情報も出てきます。そういった場合は、双方合意の上で共有します。 くりかえしになりますが、1on1は対話によってお互いの理解を深めていきます。しかし、上司として、時にはコンサルタントとしてアイデアを提供したり、ティーチャーとして解説したり、コーチとして支援したりと、さまざまな帽子をかぶり、かぶりなおしながら対応していくケースも多いでしょう。 そのためには、さまざまなコミュニケーション方法の理解が必要です。理解だけでなく、実践経験も積まなければなりません。1on1は簡単にはじめられるツールですが、扱うのが難しいツールとも言えるのには、こういった理由があります。 1on1のフォーマット例 スクラムマスターだとあまりないかもしれませんが、アジャイルコーチだとスクラムマスターやアジャイルチームを育成する場合があります。筆者の場合、そういった育成に1on1を活用しています。 私がよくやっている1on1のフォーマットは現在以下のようになっています。 近況 アイスブレイク。仕事とやプライベートの雑談 アクションの確認 前回決めたアクションを共有する アクションについて、アップデートがあればその内容を聞く 今日話したいこと 次のアクション クライアントに伝えたいこと（あれば） 前回学んで今回アップデートすること 前回の1on1後に個人でふりかえりを行い、アップデートすることをここにメモして次回その内容を試す この流れを1on1で繰り返し、初回や3ヶ月おきなどに目標を設定して、方向性を調整します。 アジャイルチームやスクラムマスターを相手にすると、以下のようなトピックが多くなります。 これってスクラム的に正しいんだっけ？ こういうときにアジャイル開発だとどうするんだろう？ チームでこっちに進むためには何をすればいいんだろう？ はじめは方法（How）や手段（What）が気になるものです。しかし、1on1を続けていくうちに知っていることが増え、知らないことが減るので、相談内容が変わっていきます。 こういう正解のないケースの場合、どういう選択肢があるのだろうか？（アジャイル開発の原理原則を理解した上で、どう判断するべきかを悩むようになる） キャリアを考えた場合に、どういったアクションを行っていくべきだろうか？（アジャイル関係ないけど、人生にとって大切なテーマに向き合えるようになる） リーダーシップとはなにか？ 自分にマッチするリーダーシップは何なのだろうか？（アジャイルチームの一員から、ひとつ上のリーダーシップに関心が移る） ここまでくると、コーチングが機能します。時には自分の経験を提供する場合もありますが、このレベルの人であれば、自分で答えを見つけられるスキルをもう身につけているからです。 ＊ 今回は、1on1について解説しました。1on1は幅広いスキルが求められ、相手に応じた対応も必要なので難しい技術と言えます。しかし、対話を用いたコミュニケーションは心理的安全性を高め、大きな成長が期待できます。ここまで世界的に1on1が広がっているのも、その効果の高さがあるからでしょう。 初心者が陥りやすい罠としては、上司と部下という関係上、「相手の話を聞くのではなく、自分の話を語ってしまう症候群」があります。その場合は、特効薬として、「1on1で自分の話をしない宣言」をしてみてください。相手の話を聞くだけで、新しい発見がたくさんあることに気がつくはずです。 次回は1on1のなかで利用されるさまざまなコミュニケーション方法を学びます。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1 〜 簡単だけど難しい1on1 The post 実践1on1 〜 簡単だけど難しい1on1 first appeared on Sqripts .

こんにちは。バックエンドエンジニアのカズです。 最近、開発効率を向上させるためにAIを活用することが増えてきています。この記事では、Claude　3.5 SonnetのArtifacts機能をどう開発に活用するかについて共有したいと思います。 Claude 3.5 Sonnetとは Claude 3シリーズはAnthropic社の生成AIモデルであり、Claude 3.5 Sonnetは2024年6月21日にリリースされました。このモデルでは、従来のモデルの2倍の処理速度を実現し、自然言語処理、推論、判断能力が向上している点や、画像や動画の視覚情報を理解することができるマルチモーダル対応や、コード生成を行うことができるようになっています。 Artifacts機能とは Artifactsの具体例としては、以下のようなものがあります。 プログラマー向け: まとまったコードブロックやReactコンポーネント ビジネスユーザー向け: 詳細なレポートやプレゼンテーションの資料 デザイナー向け: 複雑な図表やダイアグラム •ウェブ開発者向け: 完成度の高いウェブページのHTMLコード しかし、ユーザーの質問への回答にArtifactsを利用するかどうかは、回答の長さや複雑さに基づいてClaude側で自動的に判断されます。また、同じ言語の複数のコードファイルが、コメントで区切られて1つのArtifactsにまとめられることがあります。 使ってみる Claude 3.5 Sonnetは こちら のサイトで利用できますが、Artifacts機能は初期設定ではOFFになっているので、 設定画面 のEnable ArtifactsをONにします。 今回は、この機能を使って、Reactで簡単なSNSサイトを作ります。 LLMの特性上、この記事での画面レイアウトとは別のものが生成される可能性がある点に注意してください。 まずは、「 Reactを使って簡単なSNSサイトを作ってください。 」と指示を行います。 このように数秒でWebサイトが完成しましたが、まだユーザー認証やコメント機能の追加が行われていないので、次に、「 ログイン機能とコメント機能を追加してください。 」と指示を行います。 指示通りの機能が追加されました。 しかし、編集や削除機能が足りないため、まだ未完成の状態です。 次に、「投稿の編集・削除機能を追加してください。」と指示を行います。 このように、簡単な指示を3つほど与えるだけで、シンプルなSNSサイトが完成しました。 この状態ではまだサーバサイドの実装ができていないので、実際のアプリケーションでは実装を行う必要がありますが、その実装についても生成を行うことができます。以下の画像は、その一部の例となります。 このように導入手順まで示して解説が行われます。 しかし、生成されたコードは必ずしも完璧ではなく、使用前に必ず確認し、エラーや文法、セキュリティやライセンスについて確認する必要があることに留意してください。 まとめ このように、ソフトウェア開発の初期段階で素案を作成し、アイデアの説明をスムーズにすることや、開発中の問題解決に役立っていると感じます。 一方で、間違っているコードがあり実際に実行してみると動かないなど、チェックや修正が必要な点も多々あるため、自分自身の知識も必要だと考えます。 AI生成は開発プロセスを大幅に加速させる可能性を秘めていますが、それを活用する人間の判断と専門知識が最も重要です。これらの注意点を守ることで、AIの力を最大限に活かしつつ、安全で信頼性の高いソフトウェア開発を実現できるでしょう。 The post Claude 3.5 SonnetのArtifacts機能を使ってみた first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ プロジェクトマネジメントを勉強する人やPMが必ず出会う言葉に「PMの仕事のXX％はコミュニケーションである」というものがあります。PMP試験でも問われる古典的な質問ですが、その正解は「90％」です。とはいえ実際に90％やそれに近い数字かは別として、コミュニケーションがプロジェクトとPMにとって大変重要なのは間違いありません。 しかし、よくよく考えてみるとこの「コミュニケーション」というのが曲者です。単純に対話するだけでなく、聞く、公式・非公式の伝達、相手への説得、メディアの活用などあらゆる場面でコミュニケーションという言葉が使われ、とても複雑で曖昧な要素を含むからです。 プロジェクトをマネージメントするにあたりコミュニケーションやスキルが大切だ、と言われ否定する人は少ないでしょう。だからこそ、この「漠然としたコミュニケーション」を「使いこなす」ために、「具体的にどのようなコミュニケーションが必要なのか」を分解・整理していきましょう！ プロジェクトにおけるコミュニケーションとは 1) 概念 PMは異なる文化・組織的背景を持つステークホルダーの橋渡し役を務め、プロジェクト活動に必要な「情報交換（送受信）」を円滑に行う必要があります。プロジェクト情報の収集、配布、保管、マネジメント、監視、最終的な廃棄などを適切且つ確実に行うために、以下のようなステップでコミュニケーションマネジメントの計画を立て、実際にマネジメントし、計画が想定通りに進んでいるか監視します。 2) 情報交換のメカニズム 情報交換におけるメカニズムや種類は目的や状況に応じて使い分けなければなりません。情報交換の効率や効果を高めるために、これらの要素を理解し切に活用していきましょう。また必ずしも同じ情報交換方式を使い続ける必要はありません。重要なのは、その時々に適した方法を「意識的に選択し、活用できているか」です。 伝達手法 　　　：書面、物理的または電子的（言語・非言語） 口頭 　　　　　：対面またはリモート 正式または略式 ：正式な書類またはソーシャルメディアなど 身振り 　　　　：口調や顔の表情、ボディーランゲージ メディア 　　　：写真、行動、簡潔な言葉の選択、聴覚 言葉の選択 　　：一つのアイデアを表現する一つ以上の様々な語句 3) コミュニケーションの活動対象とその側面 内部 　　　：プロジェクト内および組織内のステークホルダー 外部 　　　：顧客、ベンダー、その他の外部ステークホルダー 正式 　　　：正式な会議（定例および臨時）、会議の議題と議事録など 略式 　　　：電子メール、SNSなど簡略的なコミュニケーション活動 書面と口頭 ：口頭（言葉と声の抑揚）と非言語（ボディランゲージ） 公式 　　　：年次報告書、規制当局や政府機関への報告書 上方 　　　：上級経営層のステークホルダーへ向けたもの 下方 　　　：プロジェクトの作業に貢献するチームなどへ向けたもの 水平 　　　：プロジェクト管理者やチームの同僚へ向けたもの 4) コミュニケーションスキルというものの実態 ひとつの例として、プロジェクトのスケジュールを承認・合意するまでのシーンで考えてみましょう。 上記はごく簡略した流れであり、また進め方はこの流れに限らないでしょう。しかし言えることは、コミュニケーションと呼ばれる活動は細かく分解でき、多彩なスキルで構成されているということです。冒頭にお伝えしたように複雑で曖昧な要素を持ち、あえて言えば「まとまった実態がない」のです。ですから、コミュニケーション能力がある・ない、必要だ、と漠然と語るのではなく、どのようなコミュニケーションスキルが不足していたのかを細かく考えたり、その結果に沿った対応することが必要ですね。 なぜプロジェクト内のコミュニケーションは上手くいかないのか 1) コミュニケーションはメンバーの数だけ煩雑になる（N理論） PMは「コミュニケーション・チャネルの総数を意識せよ」と言われますが、どういうことでしょうか？ コミュニケーション・チャネルとはプロジェクト（あるいは組織）内のコミュケーション経路を指します。そしてチャネル数はコミュニケーションに関わる人の数です。 コミュニケーション・チャネル数の計算式は：n(n-1)/2 n=ステークホルダーの人数 ひとりの人から見たコミュニケーションの 相手 が5人だとすると、チーム6人全員の組み合わせは 6人×（6-1）＝30、コミュニケーションは双方向であることから 30/2＝15 がチャネル数なります。ここで直感的に感じるのは、人が増えれば増えるだけコミュニケーションは複雑化する、つまり誤解やコンフリクトの可能性が増えるということです。「一応XXさんに情報共有しておいて」「XXさんは直接活動しないけれど、体制にいれておく」といった安易なメンバー増幅はとても危険だということです。「適切に最小限のメンバーで活動すること」が、コスト面で考えたプロジェクトにもコミュニケーションマネジメントにも効果を発揮します。 2) 「ノイズ」を理解して、転ばぬ先のコミュニケーション コミュニケーションは単純化すると以下のような送信者・受信者の関係（モデル）があります。 双方向のコミュニケーションはシンプルに見えて実はやっかいです。なぜならそこには常に「ノイズ」が発生し、必ずと言って良いほど自分が思うことはシンプルに相手に伝達されないからです。できることはそのノイズの存在を受け止めた上で「いかにノイズを小さくする工夫が（少なくともこちらから）できるか」に尽きます。 みなさんが伝えたいことは、他者が正しく理解できるようなテキスト、音声、媒体などで構成されていますか？ そのメッセージに合わせた媒体を選択しましたか？（口頭伝達が望ましいメッセージなのに、安易にメールを選択するなど） ノイズを考慮した上で、メッセージが受け取られ且つ正しく理解されているか確認を怠りませんでしたか？ ノイズの例） 物理的ノイズ　: 通信路における物理的な干渉（例: 声の届きにくさ、通信機器の故障） 心理的ノイズ　: 受信者の気分や状態による情報の受け取り方の変化（例: ストレスや集中力の欠如） 言語的ノイズ　: 言葉の意味や用法に関する誤解（例: 専門用語の使い方） 3) その他の考慮しておきたい事項 考慮したいこととしては、コロナ禍以降増えたリモートワークを含め、チームメンバーの物理的な場所やグローバルチームであればメンバーのタイムゾーン、使用できるコミュニケーション方法/技術/ツールとコスト効率、チームの多様性に考慮した言語の適用やルール決め、チームの知識レベルに合わせたリポジトリの活用など様々です。プロジェクトにフィットしたコミュニケーション環境を注意して設定するようにしましょう。 ミスコミュニケーションは必ず起きる。誤解に対処し続けることが大切 コミュニケーションにおける誤解とは、情報の発信者と受信者における「解釈の齟齬」です。 どれだけ綿密に計画しコミュニケーションを図っても、誤解の発生をなくすことはできません。注意しながらもプロジェクト内に誤解や衝突が発生した際には、すぐにPMが解消に向けてアクションしましょう！コミュニケーション・マネジメントに簡単な近道はありません。 1) コミュニケーションの5Cを抑える コミュニケーションにおいては、これら5つの「C」を意識することで、情報伝達の誤解を未然に防ぐことができます。 2) やっぱり基本のコミュニケーション・スキルが大切  PMBOKでは以下のようなスキルをPMに要求しています。この中に「メンバのスキルを（PMが）向上させる」とありますが、PMがすべての情報を管理したり架け橋になることは現実的に不可能ですので「プロジェクト・チーム全体で対処できるようにPMが働きかける必要がある」とわかりますね。コミュニケーションはPMひとりが頑張れば叶うものではなく、チームや組織全体で創って行けるように働きかけたいですね。 さいごに プロジェクト計画後はコミュニケーションと実行管理（監視・コントロール）にPMリソースの多くが注がれます。コミュニケーションは常に「思うように行われない」と考え、情報を伝えたり報告を受けるだけで満足せず、あらゆる伝達方法を駆使しながら「正しく伝わっているか」を確認し続けなければなりません。コミュニケーションを現場の力に変えていきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ 【第14回】コミュニケーションの本質を知り、使いこなそう！ The post 【第14回】コミュニケーションの本質を知り、使いこなそう！ first appeared on Sqripts .

皆様こんにちは、ざわ です。 2024年8月23日(金)に開催された、JaSST’24 Hokkaidoに参加してきました。 初めてのJaSST参加で緊張しましたが、有意義な時間を過ごすことができました！ 基調講演の内容を主に、参加レポートを書いていきたいと思います。 今回のテーマ：りすっきりんぐテスト(テストリスキリング) 今回のテーマは、「りすっきりんぐテスト」とし、テスト技術・知識を学び直し、より深くそして新たに身につけることを目指します。 (中略) みなさんと一緒に学び直し、新たな可能性を考え、再度(Re)すっきりとした気持ちでテストに向き合える。そんなシンポジウムにしたいと思います。 JaSST’24 Hokkaido 開催要項 日々、技術が進歩していく中で、自分の技術はその進歩に追いついているだろうか？ また、追いつくために今、何を学び、身につけていけばいいのだろう？ そんなことを考えていた私にとって、「リスキリング」というテーマは特に心に響くものでした。 (「りすっきりんぐ」が可愛らしくて、ぐっと肩に入っていた力が抜けたのは秘密。。。) 普段、テスト設計やテスト実装を主に担当する中で、すでに知っていて活用している内容もあれば、普段あまり触れない部分の話もありました。知っているからと、振り返ることを怠っていた部分も、新たな知識とともに見直すことで、見落としていたかもしれない部分が見えてきました。まさに「再度(Re)すっきり」という気持ちです。 基調講演：「ソフトウェア品質のダンジョンマッピング」 登壇されたのは、株式会社 日立製作所 サービスプラットフォーム品質保証本部 担当部長の鈴木一裕様です。 広く奥深いソフトウェア品質の世界を、RPGの剣と魔法のダンジョンに見立て、戦士や僧侶などのRPG職業がそれぞれQAで何が得意なのかを考え、自分が現場から離れている今、どの職業に該当するか…そうか、マッパーだ！ という発想から、このタイトルになっているようです。(マッパーという職業は初耳でした！) ソフトウェア品質のダンジョンを進みながら、次々と登場するキーワードを数珠繋ぎにしていく中で、自分が知らなかった分野を学び、リスキリングのネタを見つけてほしいというお話でした。(RPGに例えられるとワクワクしますね！) 基調講演は90分間でしたが、大変面白く、また興味深く拝聴したので、あっという間に感じました。 大まかな講演の流れ 「ソフトウェア品質保証」という広大なダンジョンに、どこから踏み込んでいくのか…。まず、多くの人々が入口とするであろう「テスト実行」から始まり、次に「バグ管理とバグ分析」→「テスト管理・計画」→「テスト実装」→「テスト分析・設計」→「レビュー」→「プロセス改善」→「品質と価値」→「QAエンジニアの仕事」という流れで進んでいきます。 最後に「90分ではとても歩き切れませんでした」とおっしゃっていましたが、こうして概要を見ただけでも、ソフトウェア品質のダンジョンがいかに広く深いかが伝わってきますよね。すべてについて語りたいところですが、ダンジョンはあまりにも深遠ですので、今回は特に重要なポイントをピックアップしてレポートしたいと思います。 なぜあなたのテスト実行は退屈なのか？ ダンジョンは「テスト実行が退屈だという方はいますか？」という問いかけから始まりました。 この問いかけに積極的に手を挙げることはなかったとしても、誰しもがテスト実行中に「退屈だ」と感じる瞬間があるかもしれません。会場内の皆様も同じように感じたのではないでしょうか…私もそうでしたし、私の席から見える範囲では、挙手された方はほとんどいませんでした。(とはいえ、鈴木様もこれを想定されていたのか、会場を和ませる笑いに変えてくださいました) テスト実行が退屈に感じられる要因として、以下の点が挙げられました。 要因1 : 単調な繰り返し 要因2 : テストの必要性が不明 要因3 : 厳密すぎる手順 要因4 : 無秩序なプロセス 要因5 : バグが出ないことへの苦しさ これらの要因は、これまでの経験からもよく理解できるものばかりです。それに対して、対策として以下の5つのアプローチが示されました。 自動化 テスト分析・設計 柔軟なテストおよび探索的テスト ユーザ価値の深い理解 テストの目的の確認 ただし、各要因に対する対策は一つだけではなく、複数のアプローチが有効であることが多いです。 例えば、要因3の「厳密すぎる手順」については、対策として「テストの自動化」と「柔軟なテストおよび探索的テスト」が示されています。テスト実行は本来、知識や理解力、観察眼、さらにはコミュニケーション能力など、さまざまな能力が求められる難易度の高い作業です。プロダクトを理解し、お客様にとっての価値を判断するのは、結局のところ人間の力によるものであり、そのため「テスト実行を推していこうよ」という考え方が示されました。確かに、QAは上流の作業だけでは完結しません。 手動でテスト設計を主な業務としている私にとって、求められているテストがどのようなものであるか、そしてプロダクトの価値をしっかりと見極めて分析・設計を明確に行うことは、非常に重要であり、またすぐにでも実践すべきことだと思います。それは「退屈でない」テスト実施だけでなく、QAの質を向上させることにも繋がるのではないでしょうか。 テスト設計を進めるうえで、改めて「分析」の重要性を見直し、明確で価値のあるQAを実践していきたいと考えています。例えば、過去の事例から学ぶことも大いに有効だと思いますので、まずは鈴木様が紹介されていた本を読んでみるつもりです。過去事例を知り、知見を広めていくことで、同様のケースでなくても応用できると思いますし、自分とは異なる考え方を知ることができ、そうして取り入れた知識や視点でプロダクトに向き合うことで「分析」の一助になるのではないかと思っています。 テスト実行に限らず、他の点についても同様ですが、多角的な視点で物事を見つめることが重要であると感じました。 テスト分析の必要性 テスト設計技術も進化しており、従来の技法の親戚的な技法や、アジャイル開発、機械学習、AIとともに普及が進んだ技法、非機能要件やドメイン固有のテスト技法が挙げられています。この分野は常に進化し続けており、勉強のし甲斐があるというお話がありました。 基調講演から話は逸れますが、今回のワークショップ「技法を探せ！」では、示されたお題に従ってどのようなテスト技法を適用できるかを探し、また他の参加者が見つけたテスト技法を知ることで、今後のテスト設計に役立てることが目的とされました。 限られた時間の中ではなかなか難しく、知識や技術をうまく応用するためには、やはり勉強を続けて身につけていく必要があると感じました。 「テスト分析の必要性」という見出しをつけましたが、設計の話に移ってしまいました。なぜなら、これらの設計技術を活用してテスト設計を行うには、「テスト分析」が先に行われるべきだからです。 テスト設計は「プロダクトの何をテストするのか」という点から始まりますが、その「何」を決めるためにはテスト分析が不可欠です。テスト分析は「テストを通じてどのように品質保証するのか」という全体像を描く技術として位置づけられています。 テスト設計を進める中でテスト分析を行っているつもりでも、全体像を描けているかというと、まだ足りないと感じることがあります。「QAエンジニアとして、この全体像を描く技術を身に着けるべきだ」との指摘がありましたが、「全体像を描く」というスキルはテスト設計だけでなく、管理などの分野にも重要であると感じました。 生成AIの活用 今回の基調講演では、生成AIの活用についても言及されました。 バグ分析： 生成AIを使ってバグ分析を行うようになる可能性 テスト設計： 生成AIを活用したテストの適用により、機械学習におけるテスト設計の課題を解決していく レビュー： 「チェックリストベース」のレビューを生成AIで実施できるようになる可能性 様々な部分で活用が進められているAIですが、具体的な用例とともに言及されたのは、AIをうまく活用するためには「言語化能力」が改めて求められるという点です。 確かに、生成AIに対して内容が明確でない問いかけを行うと、求めている答えとは異なる返答が返ってくることがあります。単なる趣味で一文尋ねた場合でもそのように感じることがあるため、QAの各分野に活用する際には、人間側のロジカルな言語化能力を鍛える必要があると感じます。 QAとは直接関係がないのですが、小学生の社会・算数・理科の成績と国語の成績には高い相関関係があるという学術記事を読んだことがあります。かなり古い記事なので、その内容が現在も学術的に認められているかは分かりません。 しかし、読解力や表現力などの国語の基礎学力が他の教科に影響を及ぼすという点と、生成AIに内容を理解してもらうために言語化能力が必要だという話は、人間とAIのやり取りにも相関関係があるように感じられて、興味深いと思いました。 技術の勉強は、学んだ直後にすぐ応用できるほど簡単なものだけではないかもしれません。しかし、技術の習得を続ける中で、それを自分なりに理解し、応用できるようになるためには、ロジカルな思考力と表現力が必要だと改めて感じました。 これらの能力は、QAの分野だけでなく、社内外でのコミュニケーションにおいても重要だと思います。「日本人はハイコンテキストであることを自覚する」というお話もありましたが、私自身、つい「こう言えばこう伝わるはず」と前提を置いて話してしまい、言葉が足りなくなることがあります。 「伝える」ということは、自分がしっかりと理解していないと難しいものです。例えば、ユーザー目線のテストを行う際にペルソナを用意するように、知識がない状態をイメージし、その状態でどのような伝え方をすれば理解を促せるかを考えることは、自分の中で情報を整理し、かみ砕いて理解するための有効な手段だと思います。 技術やツールについての情報を取り入れることも重要ですが、こうした考え方を取り入れることで、今すぐにでも実践できることから始めていきたいと考えています。そうして技術だけでなく、言語化といった基本的な能力も鍛えていきたいと考えています。 「今」の品質 従来の品質メトリクスとアジャイル開発における品質メトリクスの違いについて、旧来のメトリクスは「開発」にフォーカスし達成した状態を評価しているのに対し、アジャイルでは「開発」と「運用」が一体となり、達成する能力そのものが品質として評価されるという点を比較して紹介されていました。 私自身はアジャイル開発に携わったことはありませんが、アジャイル開発に限らず、近年のQAの進化により、後者のアプローチが求められているように感じることがあります。それは、QAの手法が日々進化し、よりユーザ視点での「価値」を重視するようになってきているからかもしれません。 求められる品質を理解し、ユーザ視点での「価値」を開発側に伝えることが重要だと感じています。先に述べた「こうしていきたい」という考えにも関連しますが、「しっかりと分析」し、「ロジカルに言語化」することで、「品質」への理解が深まるのではないかと思います。これらのスキルを磨いて、自分のQAをより価値のあるものにしていきたいと考えています。 おわりに いくつかの点に絞ってレポートしましたが、いかがでしたでしょうか。私の感想としては、今の生成AIでは担えない「人間」としてのQAエンジニアの価値を見出していけたらいいなと強く感じた90分間でした。 基調講演では、面白く興味深いお話もあれば、つい背筋が伸びてしまうような重要なお話も盛りだくさんでした。ソフトウェア品質ダンジョンの広さを感じつつも、少しだけ覗けたという印象です。その中で、「リスキリングのタネ」も随所に見つけることができました。 鈴木様が公開されている 講演スライド は、ソフトウェア品質ダンジョンのマップを手に入れたい方にとって有益ですので、ぜひ見てみてください。私はこれからもソフトウェア品質ダンジョンに潜り、リスキリングのタネを育てていきたいと思います。 最後まで読んでいただきありがとうございました。 JaSST'24 Hokkaido ソフトウェア品質のダンジョンマッピング 2024年8月23日に開催された、JaSST’24 Hokkaido 基調講演の資料です。https://www.jasst.jp/symposium/jasst24hokkaido/details.html#S2 　詳細はこちら　 Speaker Deck 関連情報 The post JaSST’24 Hokkaido 参加レポート｜りすっきりんぐテスト(テストリスキリング) first appeared on Sqripts .

先日、 有名エンターテインメント企業が受けたサイバー攻撃 は、 さまざまな問題を引き起こす大惨事 となりました。 サービス停止だけでなく、暗号資産による身代金支払い、関連事業の情報漏洩、第三者によるデータ拡散および脅迫… 他人事ではなくなったサイバー攻撃に、私たちはどう立ち向かうべきでしょうか。 今回、そのヒントを得るために、株式会社マクニカ主催、株式会社AGEST共催で開かれたオンラインセミナー「 EDR導入成功の鍵：インシデントレスポンスと運用の最適解 」に参加しました。 セミナーレポートという形で、EDRから講じるサイバー攻撃への対抗策をお届けします。 結論：EDRは導入すべき このセミナーを通じて最も強く感じたのは、EDR（Endpoint Detection and Response）は現代のサイバーセキュリティ対策として不可欠だということです。 高度化・複雑化する現代のサイバー攻撃に対し、従来のアンチウイルス対策だけでは十分に対応できなくなっています。今や、ゼロトラスト思考、つまりすでに脅威が存在するという前提に基づいた迅速な対応が求められています。被害を最小限に抑えるためには、EDRによる高度な検知能力と迅速な対応が不可欠です。これらの理由から、EDRの導入はサイバーセキュリティ対策の要となると考えられます。 この結論に至った経緯と、EDR導入・運用の具体的な方法について、セミナーの内容に沿って詳しく見ていきましょう。 まずは、マクニカ社のセッション内容からレポートします。 サイバー攻撃の現状 まずは、サイバー攻撃が複雑化していることについて、掘り下げた内容の解説がありました。 セミナーでは、サイバー攻撃の攻撃手法の変遷を表す以下の図が示されました。 セミナー資料より 上の図は、サイバー攻撃の攻撃手法の変遷を表しています。 2010年代を皮切りに、Emotetやランサムウェアに代表されるような 金銭目的の犯行 、しかも犯罪のスペシャリストや国家単位によるものが多くなっています。 従来の個人の好奇心を主とした愉快犯的な攻撃とは異なり、昨今の組織的な攻撃は、ビジネスとして明確な目的をもって行われるため、より高度化する傾向にあります。ウイルス感染を完全に防ぐこと、あるいは、感染してしまったことに気づくことは非常に困難になってきました。 セミナー資料より 中でもランサムウェアの被害は甚大で、企業規模問わず、多くの企業がその被害に遭っているという事例が紹介されました。 2024年1〜6月に発生したランサムウェア被害事例（一部）の図が示され、データ暗号化により、1か月以上も業務に支障が発生したり、データの復号化を条件に金銭を要求されていたりするなど、会社経営そのものを脅かすものばかりだったのが印象的でした。 注目すべきは 従業員数 で、千人単位の企業もあれば、約20人ほどの企業もあります。このことからもわかるように、もはや誰もが知る有名企業ばかりが狙われる時代ではなく、あらゆる企業がサイバー攻撃の対象となっています。改めて、セキュリティに対する意識を一新しなければならないと感じました。 従来のセキュリティ対策の限界 サイバー攻撃の現状を踏まえると、従来のセキュリティ対策には明らかな限界があることが分かります。 主な課題として以下が挙げられます。 新種の脅威への対応力不足 ：既知のパターンに基づく対策だけでは、日々進化する攻撃に追いつけません。 事後対応の遅れ ：攻撃を検知してから対応するまでに時間がかかり、被害が拡大するリスクがあります。 可視性の欠如 ：侵入後の攻撃者の動きを追跡し、全容を把握することが困難です。 これらの課題に対応するため、より高度で包括的なセキュリティソリューションが求められています。そこで注目されているのが、次のセクションで詳しく説明するEDRです。 EDRとは？ ここで、EDRについて復習したいと思います。 EDR（Endpoint Detection and Response） とは、エンドポイント（PCやサーバーなど）のセキュリティを強化するための先進的なツールです。主な特徴は以下の通りです。 リアルタイム監視 ：エンドポイントの活動を常時監視し、不審な動きを即座に検知します。 高度な脅威検知 ：従来のアンチウイルスでは検出困難な新種や未知の脅威も、行動分析やAIを用いて発見します。 迅速な対応 ：脅威を検知したら、自動的に隔離やネットワーク切断などの対策を実行します。 詳細な調査 ：攻撃の全容を把握するため、詳細なログや証拠を収集・分析します。 集中管理 ：企業内のすべてのエンドポイントを一元的に管理し、セキュリティ状況を可視化します。 EDRは、従来の「防御」中心から「検知と対応」を重視する現代のセキュリティ対策の要となっています。 このような特徴を持つEDRは、現代のサイバー攻撃に対して非常に効果的だと言えます。では、EDRがどのようにしてサイバー攻撃を「見える化」し、対応を可能にするのか、セミナーでの内容を具体的に見ていきましょう。 サイバー攻撃を「見える化」するEDR 前述の通り、攻撃者の大半が愉快犯的な罪を犯していた2000年代は、「 防ぐことを前提としたセキュリティ対策 」が主流でした。 一方、犯罪のプロ集団や国家のような、より高度な攻撃を仕掛けてくる攻撃者がいる現在では、攻撃を事前に防ぎきることは難しく、 侵入した脅威に対して、より迅速に対応するセキュリティが主流 となっています。 EDRは、検知された脅威がどのような影響を及ぼしていて、どうすればよいのかを把握するために、多数のエンドポイントから集めた膨大な情報を、シンプルな情報に変換する 可視化ツール です。 そのため、起こっていることを迅速に把握し、対処までをスムーズに実行しなければならない現在のセキュリティ対策において、必要不可欠なツールだと理解が進みました。 セミナー資料より ただし、EDRだけで事業をすべての脅威から守り抜くこともやはり困難であり、依然として従来型のセキュリティ対策である アンチウイルス（AV） や 次世代型アンチウイルス（NGAV） は有効だという説明がありました。 AVやNGAVが欠けてしまうと、EDRに上がるアラートが膨大になってしまい、アラート対処をする工数が膨れ上がるそうです。 EDRで上がるアラートが多すぎて、そのアラートを無視してしまうアナリストが全体の3～4割ほどいるという調査結果も紹介され、驚きました。 一方、EDRが欠けてしまうと、万が一AV、NGAVをすり抜けてしまった際には、被害を特定するまでに相当な日数を要し、被害範囲が広範囲に及んでしまうとのこと。 侵入されてから攻撃に気づくまでに、 20日前後の時間を有した 例もあると聞き、EDRの重要性を再認識しました。 どちらか一方だけではなく、従来型（AV、NGAV） + EDRを組み合わせて活用することが、高度なセキュリティ対策としては有効だと学びました。 自社に適切なEDRを選べていないかも？ ここまでを読んで、「わが社はEDRを導入しているから問題ない」と安堵する人はどれくらいいるだろうかと考えさせられました。 セミナーでは、EDRはただ導入すればいいものではなく、要点を押さえた製品でなければ、結局は被害を最小限に抑えることは難しいと強調していました。 EDR製品を選択する際の重要な点は「 二度と感染させない、という視点に立った製品選定かどうか 」です。 もう少し詳しくセミナーの内容を見ていきましょう。 ファスト・フォレンジックを実現できるか あるセキュリティベンダーは、攻撃者が システムへ侵入してから横展開を始めるまでには約1時間24分かかる のだそうです。 言い換えると、この1時間24分の間に、侵入経路や原因、侵害が及んでいる範囲を正確に突き止め、ネットワークから隔離することができれば、被害を最小限にとどめられる可能性が高いということだと理解しました。 つまり、EDR製品の選定においては ファスト・フォレンジックを実現できるかどうか を意識しなければならないということです。 フォレンジックとは、サイバー攻撃や内部不正の際に、被害の裏付けとなるデジタル証拠を収集・解析する手法です。中でも必要最低限のデータを抽出し解析するファスト・フォレンジックは、インシデント時の適切で迅速な初動対応において重要であるとのことでした。 ファスト・フォレンジックとは： 早急な原因究明、侵入経路や不正な挙動を把握するため、必要最低限のデータを抽出及びコピーし、解析すること 。 （NPO法人デジタル・フォレンジック研究会による定義） グローバル規模の調査では、 ランサムウェアの被害に遭った企業のうちの約4割が、2度目の被害に遭っている という報告が紹介されました。フォレンジックを怠ると、調査不十分で被害の原因がわからず、2度目の被害を誘発する恐れがあるそうです。1時間24分という限られた時間の中で、被害を最小限に抑えつつ、二度と感染させない環境を作るには、ファスト・フォレンジックを実現できるEDR製品でなければならないと感じました。 ファスト・フォレンジックの重要性は、EDR選定の核心と言えるでしょう。ここまで見てきたマクニカ社のセッションの要点を、改めて整理してみましょう。 マクニカ社のセッションまとめ ここまでのマクニカ社でのセッションでは、EDR製品の必要性と、選定のポイントについて解説されていました。改めて、重要なポイントをまとめました。 サイバー攻撃は2010年代以降、より複雑化・高度化し、従来の対策では追いつかなくなった 特にランサムウェアの被害は、企業規模問わず世界中で拡がっている （すべてを防ぐことは実質不可能なため）「防ぐことを前提としたセキュリティ対策」から、EDR + 従来のアンチウイルス製品を活用した、「侵入した脅威に対して、より迅速に対応するセキュリティ対策」が主流になりつつある 適切なEDR製品を選ぶには「二度と感染させない」という視点が重要 迅速にデジタル証拠を収集・解析するファスト・フォレンジックが実現できるかどうかが、「二度と感染させない」という視点におけるキーワードになる セミナーでは、ここからAGEST社にバトンタッチ。EDRの運用の実態に迫ります。 実は多いEDRを活用できていない企業 続くAGEST社のセッションによると、あるレポートでは、 EDRを導入している企業の50％以上が「EDRを最大限に活用できていない」と答えているそうです 。 EDRはベンダーが用意したルールをもとに、攻撃と疑わしいものを検知し、製品自身がアラートを上げますが、 検知能力が高いほどアラートの数は増えるとのことでした 。 一方で、脅威かどうかの最終判断や駆除対応は、 専門的な知識を有したユーザー自身によって行わなければなりません 。 セキュリティレベルを上げれば上げるほど、より専門的な知識を持って対処する必要があるということで、EDR運用の難しさを感じました。 EDR運用は専門企業にアウトソースすべき 事例：脅威除去に至る経緯 実際にAGEST社のお客様事例で、EDRや従来型セキュリティだけで脅威を防ぎきれず、最終的にAGESTのセキュリティ専門チーム（SOC）が対応して事なきを得た事例が紹介されました。 ユーザー端末からGoogle広告経由で業務利用するためのソフトウェアをダウンロード 　↓ DLファイルを実行 ※マルウェアは暗号化された状態で正規ファイルと共にダウンロードされた。AVではダウンロードをブロックすることができず 　↓ EDRが不審なふるまいを検知、実行をブロック ※ファイルそのものは悪性と判定されなかったが、振る舞い検知によって実行をブロックすることができた 　↓ SOCチームがログ分析を実施し原因を特定 　↓ 正規ファイルに偽装されたファイルだけでなく、さらに複数の悪性ファイルがダウンロードされていたことを突き止め、全ての脅威を除去 この事例から、EDRはただ導入するだけでは不十分（今回のケースでいえば、ログ分析の知見がなければ端末内の悪性ファイルをすべて除去することはできなかった）と理解しました。 専門知識を持った人材が複数いてはじめて、（24時間365日体制の）強固なセキュリティ環境を構築できるということです。 EDR運用をアウトソースする際のチェックポイント EDR運用をアウトソースする際のポイントはいくつかあるそうですが、必ず確認しておきたい点として以下が挙げられました。 実績はあるか？ 採用したいEDRに対応しているか？ サービスでカバーされる作業領域は？ ※最重要 インシデント時の初動対応は？ 報告やコミュニケーションの方法が選べるか？ 海外にも拠点がある場合）海外拠点にも対応できるか？ なお、AGESTではフルアウトソースのEDR運用代行サービス DH-MDR を提供しているとの紹介がありました。 AGESTのEDRライセンス + 運用代行サービス EDRライセンスの取得から丸投げ運用でエンドポイントを安全に管理。AGESTのEDR運用支援サービスは累計監視台数70万台を突破！安心してお任せいただけます。 　詳細はこちら　 株式会社AGEST 関連情報 まとめ このセミナーを通じて、従来の対策では防ぎきれない高度なサイバー攻撃に対処するためには、迅速な対応が不可欠だということを学びました。エンドポイントにおける多くの情報を可視化するEDRは導入に大きなメリットがあり、また、どのように活用するかが重要であることも理解が進みました。 特に印象に残った点は2つあります。 1つ目は、迅速にデジタル証拠を収集・解析するファストフォレンジックを実現することの重要性です。 2つ目は、運用をアウトソースして最適化することの有効性です。 EDRを導入している企業も、これから検討を始める企業も、この2つを考慮しつつ、今一度セキュリティのあり方を見つめ直す必要があることを実感しました。 今回のセミナーは、サイバーセキュリティの最新動向と、EDRの重要性、そして効果的な運用方法について深く学ぶことができる、有意義な機会となりました。 The post 「EDR導入成功の鍵：インシデントレスポンスと運用の最適解」から見えたEDR活用｜セミナー参加レポート first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) 今回と次回で、「三段論法」と言われると思い浮かべる人が一番多いと思われる形式の三段論法を取り上げます。 今回はこの形式の三段論法の基本的な事項の紹介です。「大前提・小前提・結論」だけでなく、押さえておきたい事柄があります。なんとなく知っていたという人も、今回で「三段論法」の理解を深めましょう。 その前に、前回クイズの解答ですね。 前回クイズ解答 問題(再掲) 問1～問3の主張が両刀論法のどの形に該当するか、また妥当な形かどうか考えてください。 解答 問1。①のふたつの仮言判断A, Bは、前件も後件も異なります。②でA, Bそれぞれの後件を否定し、③でA, Bそれぞれの前件の否定を結論としています。 複雑破壊的 両刀論法です。 問2。①のふたつの仮言判断A, Bは後件が同じです（プロジェクトが遅延する）。②でのA, Bそれぞれの前件肯定から、③A, Bの後件を結論としています。 単純構成的 両刀論法です。 問3。①の「新しいことを考える時間も減る」には、「テストに時間を割く」という前件が省略されている、つまり、前件が同じ仮言判断A, Bがあると考えられます。 ②でA, Bそれぞれの後件を否定し、③でA, Bの共通の前件を否定しています。 単純破壊的 両刀論法です。 問1～問3のいずれも、形は妥当です。（内容については……どう考えますか？） ソクラテスは電気羊の夢を見るか？ ソクラテスに申し訳ないので いつも死なせてばかりでは申し訳ないので、ちょっと毛色を変えてみました。 図6-1の主張その1～3のそれぞれで、前提(①、②)から結論(③)が言えると思いますか？（内容の真偽ではなく、主張の形として） 図6-1 ソクラテスは電気羊の夢を見るか？ 概念と概念の関係を推論する 「ソクラテスと電気羊」の特徴 「 “または”を使って推論する 」、 「 “ならば”を使って推論する 」、 「 “ならば”と“または”で推論する 」 の各回で見てきた三段論法は、文と文をつなぐ 論理の言葉 の意味と働きで結論を導き出していました。 「ソクラテスと電気羊」にはそのような論理の言葉は使われておらず、断定的な文が並んでいるだけです。 定言三段論法 このような、すべての文が断言形式の文で構成される形の三段論法を、 定言三段論法 や断言三段論法といいます。 各文は 主語 と 述語 というふたつの言葉(概念)からなります。図6-1の例では、「ソクラテス」「哲学者」「電気羊の夢を見る」が主語や述語に当たります。 定言三段論法はこれらの文に現れる「 言葉(概念)どうしの関係性 」を論じるもので、前提に出てくる 主語と述語の関係（包含関係の成否） から結論を導き出します。 定言三段論法の構造 三つの概念：S, P, M 主語や述語は何かしらの概念を表す言葉で、S, P, Mの三種類が登場します。 小名辞(S) (小概念)： 結論の主語 になる言葉(概念)です。 小名辞Sが現れる前提を小前提 と呼びます。 大名辞(P) (大概念)： 結論の述語 になる言葉(概念)です。 大名辞Pが現れる前提を大前提 と呼びます。 媒介項(M) (中名辞、媒概念)： 大前提、小前提の両方に現れ 、SとPの間を取り持つ言葉(概念)です。 図6-1の例・その1では、「ソクラテス」が小名辞S、「電気羊の夢を見る」が大名辞P、「哲学者」が媒介項Mとなります(図6-2)。 図6-2 小名辞S, 大名辞P, 媒介項M 結論は常に「小名辞Sが主語、大名辞Pが述語」ですが、大前提、小前提では、S, P, Mが主語・述語のどちらになるかは主張内容によって変わります。 なお、小名辞・大名辞の区別は、それらが指す概念の大きさと一致するとは限りません。 文の並び：大前提→小前提→結論　とは限らない 慣習的には大前提・小前提・結論と並びますが、これは決まりではなく、三つの文はさまざまな並びがあり得ます（3つの文を並べる順列ですから、6通り）。「結論を最初に述べて、その理由や根拠として大前提・小前提を述べる」といった並びはよく見かけます。 文の種類：AEIO 大前提、小前提、結論の各文には、主語と述語に関して 修飾 がかかります(図6-3)。 主語の概念が適用される範囲（判断の「 量 」といいます）。 その範囲によって 全称 と 特称 に分かれます。 全称判断：主語の概念が当てはまる全体について述べる文。例：「 すべての SはPである」 特称判断：主語の概念が当てはまるうちの一部について述べる文。例：「 ある SはPである」 ※固有名詞は全称として扱います。 述語にかかる判断の性質（判断の「 質 」といいます）。 肯定 と 否定 があります。 肯定判断：述語が当てはまると主張する文。例：「すべてのSはP である 」 否定判断：述語が当てはまらないと主張する文。例：「すべてのSはP でない 」 図6-3 全称/特称と、肯定/否定 全称/特称と肯定/否定の組合せで、A, E, I, O, 4つの種類の文があります(図6-4)。表中の丸括弧内は、同じことを言い換えた形です。 全称否定(E)に注意してください。文全体を否定する（「すべてのSがPである、というわけではない」）のではなく、述語だけを否定した「 Sであるものはすべて、Pではない 」という意味になります。 図6-4 文の種類：AEIO AEIOそれぞれにおける、主語と述語の包含関係は図6-5のようになります（Sが主語、Pが述語）。 (あるかも)は、その文では言及していない部分です（該当する要素があるかも知れない）。 図6-5 AEIOそれぞれの、SとPの関係 主語と述語の状態：周延 文の主語と述語は、 その概念が当てはまるすべての対象について言われている か、そうでないか、ふたつの状態を持ちます。 前者の状態を、その主語や述語が 周延されている といい、後者を 周延されていない(不周延) といいます。 前提から「なるほど、ソクラテスは電気羊の夢を見るね」と判断できるとしたら、「ソクラテス」という概念と「電気羊の夢を見る」という概念が結びつかなければなりません。周延という状態はその鍵になります。 周延/不周延は、全称/特称、肯定/否定に応じて決まります(図6-5, 図6-6)。 主語について。 全称判断では、主語は周延 されます（「Sという概念が当てはまるすべて」だから）。 特称判断では、主語は周延されません （Sのすべてについては言っていない）。 述語について。 肯定判断では、述語は周延されません （SでないPがあるかも知れない）。 否定判断では、述語は周延 されます（「Pでない」と断言できるのは、Pという概念が当てはまるすべてについて言えるから）。 図6-6 文の種類(AEIO)と周延/不周延 定言三段論法の形 （本章は読み飛ばしても問題ありません） 定言三段論法の形：格(figure) 三つの文を大前提・小前提・結論の順に並べた時、S, P, Mが主語/述語のどちらになるかで概念の並び方(配列)が決まります（結論は必ず「Sが主語、Pが述語」で決まっている）。 これを「 格(figure) 」といい、第1格から第4格まで四つの格があります(図6-7)。 図6-7 定言三段論法の4つの格 M-Pが「哲学者は電気羊の夢を見る」だとすると、P-Mは「電気羊の夢を見る者は哲学者である」という文になります。Sがソクラテス、Mが哲学者なら、M-Sは「哲学者はソクラテスである」という文を表します。 定言三段論法の形：式(mood) 大前提・小前提・結論がそれぞれAEIOのどれになるかという観点から見た定言三段論法の形を「 式(mood) 」といいます。たとえば、 「大前提がA、小前提がA、結論がA」なら、AAAという式 「大前提がE、小前提がI、結論がO」なら、EIOという式 といった具合です。 格ごとに妥当な式がある というわけで、定言三段論法の形は、「格は第1格で、式はAAA」とか、「第2格のEAE」「第3格のIAI」といったように、格と式で表すことができます。 大前提・小前提・結論の3つの文がそれぞれ4種類(AEIO)あり得ますから、格ひとつ当たりの式は 4 × 4 × 4 = 64 通りあることになります （格は4つあるので組合せ総数は 64 × 4 = 256 通り）。 が、これはあくまで機械的な組合せで、 そもそも、矛盾を生じたり結論が得られないなどの非妥当な式がある さらに、格(図6-7)ごとに、取れる式に制約がある そうした無効な式を取り除くと、格ごとに妥当な式の数はかなり減ります（格ひとつ当たり、6通り）。また、格ごとに妥当な式は異なります。 「よい形」を見分けるために とはいえ、「格」や「式」の知識はともかく、格ごとの妥当な式を憶えるのは、意義はありますが、やみくもに暗記するのもツラいものがあります。 式の妥当/非妥当に関係するのは 文の種類(AEIO)と、主語・述語の周延/不周延 です。ここに着目して、 定言三段論法がよい形であるための規則 （とできればその理由）を理解することを心がけるのがよいでしょう。 クイズ 下図(図6-1と同じです)の「ソクラテスと電気羊」その1～3について、今回の説明を基に考えてみてください。（解答は次回に） 小名辞S、大名辞P、媒介項Mに当たるのは何か 各文は全称/特称、肯定/否定どれに当たるか 次回 次回は定言三段論法がよい形であるための規則（それは具体的な主張が「よい形」かどうか見分けるためのヒントでもあります）を取り上げます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 Loose Drawing 人物とベッドの絵をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する “ならば”と“または”で推論する ソクラテスは電気羊の夢を見るか？ (前編) The post ソクラテスは電気羊の夢を見るか？ (前編)｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

こんにちは、QAコンサルタントのODCオジサンです。今日は抽象と具体という、ちょっと変わった話をしたいと思います。 このテーマを選んだ理由 仕事中に提案書・報告書・会議の議事録などのたくさんの書類を眺めていると、これを書いた人はどうしてここまで細かく書いているんだろう？とか、ここもうちょっと詳しく知りたいんだけど丸められちゃってるな、と読み手としての期待とずれてしまっていることが多いと感じます。また、プレゼンテーションや発表の場でもしかりです。細かい説明にムダな時間を割いてしまって、肝心の本題に入れずに会議時間をオーバーしてしまうことってないでしょうか？ このブログでは「抽象」と「具体」という概念をもう一度見直して、「抽象」と「具体」を自由に行ったり来たりできるとこんないいことがあるよ、というのをお伝えしたいと思います。単に日常生活だけでなく、ビジネス全般やソフトウェアテストにも使えるよ、といった応用までいけるといいかなと考えています。前半は『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功）（以下、細谷本）の内容をベースに、「失敗学」や不具合分析の例を加えてまとめていきます。 抽象と具体とは 抽象と具体とは、二つの対立概念です 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） それぞれ辞書を引くと、 抽象：事物または表象からある要素・性質をぬきだして把握すること 具体：物事が、直接に知覚され認識しうる形や内容を備えていること 大辞泉 となっています。具体はまぁそうかなという感じですが、抽象は定義自体が難しいですね。 日常生活で抽象と具体という言葉が使われる状況を考えてみましょう。何かを説明するときに「具体的にどういうことですか？」とか「もう少し具体的に話してもらえますか？」ということってないでしょうか。「具体」にはわかりやすいイメージがあります。その一方で、「抽象」にはなんだかわかりにくい、難しいもののようなイメージがあります。「あの人の話は抽象的でわからない」のような場合です。 抽象と具体の特徴を表すと次のようにまとめることができます。 抽象 具体 直接目に見えない 実体と一見乖離している 分類してまとめて対応できる 解釈の自由度が高い 応用が利く 学者の世界 直接目に見える 実体と直結 一つ一つ個別対応 解釈の自由度が低い 応用が利かない 実務家の世界 ※「細谷本」より引用 なぜ抽象と具体が重要なのか？ 抽象と具体がなぜ重要かについては「細谷本」から引用します。 社内勉強会などのイベントを何か開催するところを想像してください。イベント後に上司から次のような指示を受けたことはないでしょうか？ パターン1 A「本は本棚に返して、お皿は食器棚に戻して、椅子と机は倉庫に返して….」 B「要は片付けろってことですよね？」 パターン2 A「この部屋のものを片付けて」 B「えっ、抽象的で何を言っているかわかりません。もっと具体的に言ってください。本やお皿はどの棚に返す、とか、総務部の誰に連絡すればよいのかとか…」 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） パターン1でAさんは「具体病」のように見えます。 すべて具体的事例がないと理解も実行もできない 言われたことをそのまま実行することしかできず、一切の応用が利かない 一度ルールや線引きが行われるとそれを絶対的なものと信じて疑わず、環境の変化に適応できない 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） 会社の同僚や上司がみなAさんのようになってしまった場合を想像してみてください。 一方でパターン2でAさんは「抽象病」のように見えます。 いかにも賢そうに見える。べき論を語るのが好き 他人の行動・失敗に対して理想論でアドバイスするだけで実際にアクションすることがない ベストを尽くす、徹底的に強化します、など目標や施策がすべてあいまい 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） こちらはこちらで問題です。必要な問いかけをしても何も返してくれないので、それこそ途方に暮れるしかなくなります。一方で、何かを言うとまとめてくれそうなので、抽象化のレベルさえ合っていれば仕事が早く進みそうです。 これらの「抽象病」「具体病」ですが、いずれもどちらかに偏ってしまっているのが問題なので、うまく行き来できるようになるのが重要ということになります。 ではなぜ抽象と具体が重要なのでしょうか？ 人間は新しい知識を獲得するごとに、それを個別の事象として記憶するか、他に応用できないか考えるクセがついています。例えば木に落ちる雷に一度でも遭遇したことのある人は、これはたまたま偶然だったのだと考えて、それ以上の分析をやめてしまう人が一定数います。一方で、雷はどういった場所に落ちやすいかを調べて、木の下を避けるとか避雷針を立てて雷を回避する策を考える人がいます。これが目の前の「木に落ちる雷」といった具体的な事象から、「雷の性質」という抽象概念に登れる人と登れない人の差になってきます。 具体から一度抽象に移り、再び具体に戻ることによって、人間は知の拡大を続けてきました。これを表すのが『知のピラミッド』（細谷本）です。 知のピラミッド『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） この『知のピラミッド』の具体例については「応用例」の方で述べますが、これを使って知識を拡大できないと、様々な知識を例え獲得できたとしても、単なるバラバラな事象になってしまい、膨大な具体的な知識の塊となって、人間の頭の中に入らないで捨てられてしまいます。抽象化と具体化を繰り返すことで、バラバラな事象から一定の法則や理論の形で知識を蓄えることができ、他の場面に活かすことができます。 これはあらゆる仕事にも当てはまります。抽象病や具体病に陥ることなく、抽象と具体を行ったり来たりできる人こそ、具体から抽象を吸い上げて、それを知識として蓄えることで活用できるので、真の仕事力を持っていると言えます。 では「抽象化」「具体化」について見ていきましょう。 抽象化 抽象化で一番大事なことは「目的のために必要な情報以外を取り除く」ことです。例えばリンゴで例えると、自分が仮にリンゴを販売したい農家だとして、売り上げを上げるために必要な情報はリンゴの「個数」「重さ」「糖度」などであって、その他の情報、例えば「販売経路」「梱包方法」などは実際に購入するときには必要かもしれませんが、「売る」という目的には直接は関係ないので取り除きます。こうして重要な情報だけを抜き出して構造化したものが「モデル」となります。 先ほどの片付けの例でいくと、「本棚に返す」「食器棚にしまう」「倉庫に返す」の共通点を見つけていきます。そうすると、何かを本来それが合った場所に戻すらしいぞ、となって「片付け」という上位概念がでてきます。 図：is-a関係 これはAならばBの関係になっているので（本棚に返す→片付け、食器棚にしまう→片付け、倉庫に返す→片付け）、is-a関係と呼ばれます。 こうした「一言で述べる」以外に抽象化で使えるテクニックを細谷本から抜粋します。 自由度を上げる：一部を変数にしてみる（「タンメン」を食べる→「ラーメン」を食べる） Whyを問う：因果関係を考える 全体を俯瞰する ：隣との関係性でなく一歩上の視点に立つ 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） ※筆者加筆 具体化 具体ばかり述べる人は必要ないような話をしてしまいましたが、実は抽象化した後に具体化しないと、何も実行できなくなりますので、実は具体化も重要です。抽象化も具体化もバランスが取れていることが大事です。 先ほどの例だと「片付けろ」だけでは具体的に何をどこに移動させるかが示されていないので、その場にいる人に聞いて動かすものを指定してもらいます。あるいは手順書に何か書かれているかもしれません。 具体化のテクニックを細谷本から抜粋します。 自由度を下げる：変数に具体値を当てはめる（例：「ラーメン」を食べる→「タンメン」を食べる） Howを問う：実現手段を考える 数字と固有名詞にする ：ダイエットしなさい→「オートミール」を朝に100グラム食べなさい 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） ※筆者加筆 モデリングの世界ではhas-aという関係を使うと具体化できます。例えば「車」はさまざまな部品でできていますが、「車」という製品を作るには個々の部品を考えて設計製造する必要があります。 図：has-a関係 プロジェクト管理の世界では「WBS(Work Breakdown Structure)」というものがありますが、あれもhas-aの関係で成り立っています。「要件定義」には「顧客要求の引き出し」「要件定義書作成」「要件レビュー」などが含まれる、のように大きなプロセスを個々のアクティビティやタスクに分解していきます。これも具体化の事例です。 抽象と具体の応用例① 抽象と具体を行ったり来たりできるようになるとこんなことができるようになるという事例です。『失敗学 実践編: 今までの原因分析と対策は間違っていた!』（濱口 哲也、 平山 貴之）（以下、濱口本）より引用します。 とある病院で、看護師が入院患者AさんとBさんを食堂に連れて行き、食前薬を渡すときにAさんにBさん用の薬を渡してしまった。そうなるとBさんの薬が見当たらないので薬局に探しに行っている間にAさんがBさんの薬を服用する直前で防止できた。 『失敗学 実践編: 今までの原因分析と対策は間違っていた!』 （濱口 哲也、 平山 貴之） という事例です。未然防止はできていますが、一つ間違えると人命に関わるヒヤリハットです。 この事象の再発防止策として、抽象化を行わないと「名前と薬の確認を徹底する」や「本人を示すタグと名前を照合することを徹底する」というのを思いついてしまいます。そうするとこの病院の特定の病室や、似たようなシチュエーションでしか使えない単なるチェックリストになってしまいます。 これを1段階抽象度を上げると、格段に応用の利くものになります。 AさんとBさんの区別が付かなくなったことと、それぞれの薬の区別が付かなくなったことの両方の事象を一歩上から見ると『本体とラベルを分離すると識別不可能』（濱口本）となります。つまり、Aさん本人と、ラベルを示すもの（名前を聞く、タグを確認する）を切り離してしまうと、区別がつかなくなるのでかならずセットにした状態を保ちましょう、ということになります。 これは応用範囲が広いです。例えば、最近の病院では患者を間違えないために患者の足にタグのようなものを付けると思いますが、それはここから来ています。また、人工授精後の受精卵は、シャーレの蓋に名前を書くだけでは蓋を取った途端に区別が付かなくなってしまうので、シャーレの中身（培地）の方に名前を書く（または識別可能なものを置く）、となります。 抽象と具体の応用例② ソフトウェアテストの現場から、テストで検出した不具合を分析する例を見てみましょう。 車載オーディオ製品で、その製品の仕様上聞けてはいけないはずの特定地域の放送局（A局）が聞けるようになっていました、という不具合がありました。聞けたわけですから、製品品質としては悪くないわけです。テストベースとした仕様書がA局は聞けることになっていたため、それを使って設計したテストでは合格となっていました。ところがマーケティングが後から横やりを入れてきて、結果的に欠陥という扱いになりました。 この例を抽象化してみましょう。「ビジネス要件をきちんと分析していなかった」→「ビジネス要求が最優先」→「より優先度の高い要求に上書きされる」。 これを他の例に当てはめてみましょう。昨今ソフトウェア開発は新規より派生開発が増えています。新規機能や改変対象の機能については、要件定義・設計・コーディングまでしっかりとトレーサビリティを確保しながら開発を進めることが多く、またそういったトレーサビリティを確保するための方法論がいくつかあります。ところが新規機能や改変機能に気を取られて、隠れた要求の変化に気がつかないケースがまれにあります。そうした変化した要求が残っていないか、あるいは時間の経過とともに新しい要求が発生していないかをレビュー観点として残し、設計レビューで活用することは未然防止として意味があります。「より優先度の高い要求に上書きされる」という抽象化された法則を、ソフトウェア欠陥を防止する目的で使う例として挙げさせていただきました。 まとめ 抽象と具体について、事例を交えて説明してきました。具体的な事象を我々は普段目にしているわけですが、そこから抽象化して本質を見極めるにはある程度訓練が必要です。身近なものに対しても、これは一体どういうことだろう、というように一歩上の視点から眺める訓練をしておくと、仕事にも役立ちますので一度試してみてはいかがでしょうか？ 出典 『具体⇔抽象トレーニング思考力が飛躍的にアップする29問』（細谷功） ISBN-13 ‏ : ‎ 978-4569845999 『失敗学 実践編: 今までの原因分析と対策は間違っていた!』（濱口 哲也、 平山 貴之） ISBN-13 ‏ : ‎ 978-4817195999 『大辞泉』（小学館） ISBN-13：978-4095012131 The post 抽象と具体 ～真の仕事力のための抽象化と具体化のテクニック～ first appeared on Sqripts .