この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 今回は、蓄積した情報をどのように組み合わせ、実際のアウトプットにしていくかについて解説します。とくに文章としてアウトプットする場合を前提に話を進めますが、プレゼンテーションなど他の形式のアウトプットであっても通じる部分があると考えています。 ＜ITエンジニアの仕事を楽しくする知的生活　記事一覧＞ ※クリックで開きます 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する これまでのおさらい 今回は連載の最後なので、まずはここまでの流れについて簡単にふりかえります。 最初は”知的生産”とは何かからはじめ、主に知的生活の母艦に情報を蓄積することを説明してきました。情報を蓄積する具体的な例として、読書と、仕事中のメモについて取り上げました。 本連載の第一回では、以下のように書きました。 いきなり「アウトプットしましょう」と言われても難しいという方も多いと思います。今後の連載の中では、小さいアウトプットから大きなアウトプットにつなげていく流れについても解説します。 今回扱うのはまさにこの部分です。たとえば「会社のテックブログを書かなければいけないが、なかなか進まない」といった悩みはいろいろなところで耳にします。ここでの問題は、何もないところからアウトプットを生み出そうとしていることでした。テストベースからいきなりテストケースを導出するのが良くないように、頭の中からいきなり文章としてのアウトプットを出すのは大変です。 これまでの内容を実践していただくことで、さまざまな情報が手元にある状態になっているはずです。ここから、最終的なアウトプットを作るまでの流れに沿ってご説明します。 アウトプットをつくるまで 大まかな流れは以下になります。 テーマを設定する 材料を集める 構成する 形にする それぞれ詳しくみていきましょう。 1. テーマを設定する なんらかのアウトプットをする際、テーマは与えられることもありますし、自分で考えることもあるでしょう。 （たとえばこのSqriptsでの連載は私自身がテーマを考えている、「好きに書かせてもらっている」状態です）。 ここでは、自分でテーマを考えるところから説明します。もしテーマがすでに与えられている、決まっているという場合は次の材料集めからのスタートです。 テーマを自分で考える場合であっても、完全になんでも良いということは少ないはずです。技術に関すること、品質に関すること、マネジメントに関することなどなんらかの方向性はあるでしょう。まずはこれをたよりにして、具体的なテーマを考えていきます。 アウトプットというものは、基本的には「受け手にとってメリットがあること」だと考えています。SNSで「腹減った」とつぶやいていても、それは一般にアウトプットとは思われないですよね。そうではなく、たとえば困っていることを解決するヒントを与えたり、これまで受け手が知らなかった情報を得られたり、といったメリットを提供する必要があります。誰に対してどのようなメリットを提供するのかをおおまかにでも良いので考えて、それをテーマに設定しましょう。 今回はとくに「仕事を通じて得た知見」をアウトプットしようという内容なので、自分が過去知らなかった・できなかったことや自分が解決した課題をテーマに据えると考えやすいです。このとき、前回までにご紹介した日々の記録が効いてきます。自分自身が成長すると、仕事上のいろいろなことが「当たり前」になります。この「当たり前」は、他者にとっては有益なノウハウであることも多いのですが、なかなか自分自身では気づけません。そこで過去の記録やメモを見返すことによって、自分が当時できなかったこと・わからなかったことを 通じて「当たり前の再発見」ができます。自分にとっての当たり前を探してテーマに設定すること、これも1つの方法として試してみてください。 2. 材料を集める テーマが決まったら、関連する材料を集めます。これは 【第3回】技術書以外の本を読み、仕事に活かすには でも少し登場しましたが、まずは知的生活の母艦に対してキーワード検索をかけるのがよいでしょう。情報が蓄積されていれば、関連するものがいくつか出てきます。 しかし、ここでヒットするのはあくまでもアウトプットのための「ネタ」であり、多くの場合は追加で情報を集めることになるでしょう。たとえばWeb記事をメモしておいた場合は、その記事が参照している他の記事や書籍を見に行くこともあるかもしれません。あるいは、意味が正確に理解できていない単語があり、あらためて調べることもあるでしょう。これら追加での情報収集の過程が、よく言われる「アウトプットをすると勉強になる」ことにつながっています。アウトプットを前提としたインプットを行うことでより学びが深まるという副次効果も得られます。 【第3回】技術書以外の本を読み、仕事に活かすには この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts 3. 構成する 材料が集まったら、最終的なアウトプットの骨組みを決めていく構成段階に入ります。 【第2回】知的生活の母艦としてのツールを選び、活用する でもご紹介した、 Dynalist などのアウトライナーを使うのが私のオススメです。 【第2回】知的生活の母艦としてのツールを選び、活用する この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts このような形で、材料・メモをアウトライナーに書き出したあとで、構成も同じページに書いていきます。見出しと内容を階層化したり、階層ごとの並び替えなども容易です。このようなツールで文章の全体構造を検討してある程度決めたあとで、実際の文章として書き起こすことが大切です。 4. 形にする 前項で決めた構成にそって文章を書いていきます。ここまでのステップを経ていれば、いきなり真っ白なエディターに文章を書き始めるのに比べてだいぶ進みやすいはずです。 しかし、実際に文章を書き始めてから「やはり構成がしっくりこない」「違う内容を書きたくなった」といったことも起こり得ます。これは構成の検討が不十分だったわけではなく、よくあることです。文章を形にしつつ、構成を変更したくなった場合はアウトライナー側でも編集するなど、行き来をしながら完成に向かいましょう。 知的生活でITエンジニアの仕事を楽しく 本連載で繰り返し書いていますが、知的生活とは「なにかあたらしい情報や価値」であるアウトプットを出すため、日常的にいろいろな情報をあつめて処理・思考すること、でした。 アウトプット、とくに業務上求められている成果物以外のものを出していくことで、 知的生産の過程における深い学び アウトプットに対するフィードバック が得られます。 この2点に、連載タイトルにもある「ITエンジニアの仕事を楽しくする」という要素が詰まっています。成長というと大げさな表現ですが、知らなかったことを知ること、出来なかったことができるようになることは誰しも楽しさを感じるポイントです。また、自分がアウトプットしたことに対してフィードバックがあることもまた、楽しさや励みにつながるでしょう。 知的生活だけでは、仕事上の大きな困りごとや不満をすぐに解決、とはいかないかもしれません。しかし、なんとなく閉塞感・停滞感がある、身が入らないといったモヤモヤに対しては効果があると信じています。 とくにITエンジニアをしていて、普段の仕事やキャリアに悩むタイミングが来ている方や、少し上の先輩が悩んでいそう＝もうすぐ自分にもやってきそうという方にはぜひ、本連載でご紹介した知的生活を取り入れてみていただきたいです。 ITエンジニアの仕事を楽しくする知的生活　連載一覧 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する The post 【第5回】仕事を通じて得た知見を文章でアウトプットする first appeared on Sqripts .

こんにちは！テストエンジニアの藤江です。普段はテスト実施管理者として、顧客の課題やお困りごとに最前線で対応しています。 今回は先日開催したウェビナー「 開発者を困らせるバグ起票をなくすテスト管理のコツ （オンデマンド配信中）」についての振り返りと、発表を行うことの意義についてお話しします。発表の経験を共有し、皆さんにとって有益な情報をお届けできればと思います。 あの不具合報告、どういう意味？-開発者を困らせるバグ起票をなくすテスト管理のコツ- | 株式会社AGEST... 「あの不具合報告、どういう意味？」PM・開発者の皆さんであれば一度は発した事があるのではないでしょうか？自社のテストチームや外部のテストベンダー、または開発チーム内で不具合報告として上がってきた起票内容がわかりづらいために無駄なコミュニケー 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 1. ウェビナーでの発表内容の概要紹介 ウェビナーでの発表内容を軽くおさらいします。主に不具合管理について3つのポイントをお話しました。 欠陥レポート報告のポイント 欠陥レポートには内容を見て、何が問題なのかを理解し、問題を解決することができる情報が記載されている必要があります。具体的な内容として一意な識別子、簡潔なタイトル、観測日、環境特定情報、再現手順、期待結果と実際の結果などが必要です。この中で特にポイントとなるのは以下となります。 条件(端末や権限等)、最後の手順、期待結果、実際の現象で簡潔なタイトルを記載 再現手順は初期状態から記載し、入力値も指定する 期待結果には、期待の根拠となる資料も添付する 不具合管理者としての改善策と効果 不具合管理者として、不具合報告をどのように整理すると効率が上がったかという話をしました。改善のポイントとしては以下となります。 文言の揺れを無くし、後から類似不具合の追いかけや内容検索ができるようにする 複数メンバーが並列で動作確認を行った際に、仕様変更の通知漏れや同根の不具合に起因する不具合報告の重複が発生していないかをモニタリングする 仕様理解を進めて仕様確認のリードタイムを減らして、実施効率を上げる 不具合管理のよくある失敗事例 不具合が再現できない、優先順位が不明、対応内容が不明確など、よくある失敗事例についても共有しました。こちらについても下記の観点での問題解決を提案しました。 再現が難しい報告には文章以外の手段として動画や画像等の共有を行う。再現確認の範囲を広げてみる 不具合対応者のタスク過多などによって、対応の優先順位が不明な状態になっていたら、現状把握と優先度の見直しを行い、現実的な対応スケジュールを提案する 最初に取り決めたルールが守られていない場合、ルールの見直しと周知を行う 2. ウェビナーを振り返って アンケート結果について ウェビナー終了後に行ったアンケートの結果、以下のようなフィードバックをいただきました。 非常に参考になった：8件 参考になった：28件 どちらともいえない：5件 参考にならなかった：1件 また、26件の回答としてセミナー開催の案内が欲しいとの声もあり、概ね好評をいただいております。 やってみた感想 オンサイトでの講演と違って、視聴者の表情が分からないためオンサイトよりキツイと事前に聞いていましたが、実際に行ってみると自宅のリモート環境での講演だったこともあり30分独り言を喋っているような感覚になりました。特に講演する側に立つと、改めて以下が大事だと感じます。 前列でリアクションを取って頷いたりする人の存在 事前準備として、作成した資料の読み上げと講演時間の確認 口頭で補足する内容の整理や情報の根拠の再確認 これらを通して発表内容に関する理解や解像度は発表の相談を受ける前と比べるとかなり上がったと感じます。とはいえ、事前準備をどれだけ行っても不安で緊張してしまうものなので、とにかく発表の機会があれば受けてみるという姿勢が大切だと感じました。初めての発表を終えると、次はもっと長い発表にも挑戦しようという気持ちが湧いてきます。次の目標は90分間くらいの長い時間でJaSSTの講演など出来るようになることです。 次にやってみたい工夫 今回は一方通行の話し方になってしまい、独り言の感覚だったので、次回は対談形式や参加型のディスカッション形式で進めたいと思います。立場や所属の違うメンバーを交えての対談だったり、何かのテーマを決めてのフリートークに近い形でより印象に残りやすい講演が出来れば良いなと考えています。また、不具合の動画を出して、それを文字でどう伝えるかをライブ形式で書いていく、チャット欄を使って視聴者にも概要を記載してもらって内容を評価するなど、インタラクティブな要素も取り入れて双方向の講演となるようにして、出来るだけ反応が見える講演にしたいです。 3. 発表や勉強会等に参加することの意義について セミナーやカンファレンス等のイベントに参加することで様々な気づきがあります。主に私が考えるメリットとしては以下となります。 発表することの主なメリット 発表の振り返りを行うことで、発表で得られる体験を再認識し、上記の工夫の検討といった具体的な目標や次のためのモチベーションに繋がります。 発表を通じて、自分の知識や経験を再確認し、自信とモチベーションを高めることができます。 発表の準備の過程で、内容を整理することでより深く理解することができます。 参加者からの質問やフィードバックを通じて、新しい視点やアイデアを得ることができます。 参加することの主なメリット 専門分野の講演やワークショップに参加することで、日常業務とは違った視点での考え方や知識を習得できます。 他の参加者や講演者との交流を通じて、新しい人脈を作ることができます。 同じ分野に興味を持つ人や同じ悩みを持つ人と交流し、様々なフィードバックを受けることで理解を深めることができます。 色々な提案を行う際に、●●社さんはこんな形で導入した事例があります。といった形で具体的な前例を示すことができます。 4. セミナー参加者や読者の皆様へのステップアップの提案 一度行ってノウハウを学んで終わりというわけではなく、学んだことの継続的な実践と確認が大事となります。例えるならセミナーや勉強会というのは効率的な筋トレ方法を聞いた状態で、実際に使える知識となるのは継続して学んだことを実践した後となります。そのため色々な勉強会やイベントに参加してみて、興味があったら実践してみることが重要です。 参加をお勧めするイベント 例えば、以下のようなイベントや配信があります。 ASTERのyotube配信 ：JaSST Kyushuの 過去の講演 やセッションが視聴できます。 ASTERのセミナー ：定期的に開催されるセミナーで最新の知見を学べます。 LTや対談等の軽量なイベント ： JaSST nano や Connpass などのプラットフォームで開催されるライトなイベントに参加するのもお勧めです。 セミナーやシンポジウム、カンファレンスなど ： JaSST や テスト設計コンテスト など、上記である程度の雰囲気が掴めたら是非大規模なイベントにも参加してみてください。 TestingCommunityJPのSlackチャンネル ：業界の最新情報や知見を共有するコミュニティに参加することも有益です。 最後に 登壇等のアウトプットをすることによって知識が増え、理解が深まります。発表や外部との関わりを通じて、他の人のアウトプットを吸収する機会も増えるのでさらに自分の知識を広げることができます。業務知識として得た価値観を俯瞰してみることができるようになるのもインプット、アウトプットの大きなメリットとなります。 私は今回のウェビナーを通じて多くの方に不具合管理の重要性とその実践方法について紹介し、様々なフィードバックを受けることができました。こちらを元に引き続きよりよい不具合管理を目指していきます。 アウトプットやインプットを増やすことで新しい発見や成長の機会が得られることは間違いありません。読者の皆さんの中からこのブログをきっかけに勉強会への参加や登壇を考える方が出てくれると嬉しいです。 関連記事 インプット、アウトプットに興味をお持ちの方には、Sqripter伊藤由貴さんによるこちらの特集もおすすめです！ 【第1回】知的生活とはなにか？エンジニアにどう関係するのか みなさんは、知的生産や知的生活ということばを聞いたことはありますか？初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考え... 　続きを読む　 Sqripts 関連記事｜Sqripts The post ウェビナー登壇の振り返りと参加の意義について first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 今回のテーマは「上級者の質問力」です。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- 前回のおさらい 前回はコーチングの主要技術の中で、質問に注目して解説しました。 視点を変える 時間を変える リソースの確認 オープン VS クローズド チャンクダウン VS チャンクアップ 今回は上級者向けの質問を解説しながら、質問力のレベルアップを試みます。 ゴールに向かう質問 コーチングではクライアントとのMTG（セッションと呼びます）のはじめに「このセッションで何を達成したいか？」を質問します。アジャイル開発におけるMTG（スクラムイベントなど）においても、それぞれのゴールの確認は必須です。 我々はこのMTGで何を達成すべきだろうか？ MTG後にどうなっているのが「成功」なのだろうか？ このMTGに期待していることは何か？ ゴールの意義により踏み込むために、「このゴールはなぜ重要なのか？」を質問しても良いでしょう。 「このゴールは我々にとって、どういう意味があるのだろうか？」 この質問に答えられないなら、ゴールを間違えている可能性があります。 ゴールが明確になれば、MTGの途中で確認していきます。当初のゴールが間違っている可能性もあるので、ゴールはMTGの途中で変わっても問題ありません。 ゴールに向かってうまく進んでいる実感はありますか？ ゴールから離れた議論になっている気がしますが、この議論を続けるべきでしょうか？ ゴールにたどり着いたように思いますが、まだ議論を続けますか？ もし「？」と思う所があれば、相手の考えを要約して確認したり、以下のように、選択肢を整理してどこからはじめるか質問をしてもいいでしょう。そうすることで、進むべき方法へチームをいざなうことができます。 「今、Aの話とBの話をしているように思いますが、今回のゴールを考えた場合、どちらの話からはなしたほうがいいのでしょうか？」 相手が安心できる質問 承認を意識した質問です。 あなたはそう思ったんですね どうしてそう考えたんですか？ 話したいことを話せていますか？ アジャイルコーチやスクラムマスターの場合、価値や原則に合わせて「正しい」、「間違っている」と話すことはあるかもしれません。しかし、答えのない質問も多くあり、そう簡単に正解不正解を決められないケースが多いです。 コーチングにおけるコーチは、 良いことも悪いこともどちらも受け入れ、クライアントとパートナーシップを組んで進んでいきます が、アジャイルコーチやスクラムマスターも、同じような態度が求められます。 良いことも悪いことも話せるようになるためには、心理的安全性を高めていく必要があります。そのための質問やふるまいが、アジャイル開発においてはもとめられるわけです。 そのためには、アジャイルコーチやスクラムマスターは、どっしり地に足をつけて置かなければなりません。自分の基盤がぐらついていると、特にネガティブな内容を受け止められなくなり、こちら側が崩れてしまったり、相手に感情移入しすぎてしまうからです。 今この瞬間の質問 質問には時制（過去についての質問や未来についての質問）が伴いますが、「今」、まさにこのときに注目した質問を使うことで、その時の心理、感情、思いや気持ちの理解が深まります。 あなたは今どういう感情ですか？ あなたはどうしてそう思ったのですか？ 今の状況はどうなっていますか？ 特に感情に関する質問はとてもパワフルです。仕事をしているとなかなか相手の感情を聞くことはないでしょう。しかし、 感情はその人の根底から湧き出るものなので、その人の今を理解するにはピッタリなのです。 「あらためて今どういう気持ちですか？（見た感じは辛そうだけど大丈夫かな・・・）」 「大変な状況だけど、気持ちとしてはなんとかしてやろうと燃えています」 「そうなんですね（辛そうに見えたけどやるきに満ち溢れていたのか）」 こういうケースは実際によくあります。表面上、こちらがネガティブに受け止めてしまいましたが、話を聞いてみるとそうではなかったことに気がつきます。 積極的に傾聴する 傾聴からより深い質問につなぐことができます。たとえば、相手のエネルギーが変化したときは、何かしらの感情の動きがあると考えられます。エネルギーとは以下を指します。 声のトーン 表情 ふるまい ファシリテーターとして参加者の様子をうかがっていると、特定のキーワードに反応する人がいたりします。そのキーワードが出てくると、顔色が変わり、あきらかに様子がおかしいケースもあります。 こういうときは「今、〜〜という話になって、◯◯さんの顔色が変わったように思いますが、なにか思うことがありましたか？」と質問できます。「実は・・・」と話してくれるなら、より深い情報が共有されるでしょう。 オンラインでのやりとりが当たり前になり、このあたりの情報のキャッチアップが難しくなったように思います。しかし、電話しかなかった時代は声色で相手を読み解いていたはずです。少しの変化に気がつけるように、全神経をその場に集中できるようになるといいでしょう。 気づきを引き起こす質問 視点を変える質問や時間を変える質問は、新しい気づきを引き起こします。これ以外にもさまざまな質問ができます。 100点満点で言うと何点ですか？ 何でも許されるなら何をしますか？ より高いゴールを設定するなら何をゴールにしますか？ こういった質問はパワフルクエスチョンと呼ばれ、その名の通りとてもパワフルな効果を発揮します。しかし、気をつけないと、場の空気に合わない質問になり、チームのモチベーションを下げてしまう可能性もあります。 良い質問を身につけるのと同時に、それを適切なタイミングで質問できるスキルも身につける必要があります。 成長を促進する質問 たいていのMTGであれば、その終わりにアクションプランを決め、アサインと期限を決めてMTGをクローズするでしょう。MTGには目的があるはずなので、目的達成のために必要なクロージング作業と言えます。このクロージング作業を前進する質問もあります。 今回は◯◯をゴールに話してきましたが、MTGを終えるに当たってどう感じていますか？ このテーマを話す前と後で変わった部分はありましたか？ このMTGを通じて、あなたが学んだことはなんですか？ その学んだことを今後どう活かしていきますか？ アクションを前に進めるために、使えるリソースはありますか？ 私にできることはないですか？ 話し足りない点はありませんか？ 「今回のMTGでは◯◯を達成しましたね」と事実を伝えるのがコーチングです。コーチは相手を評価する立場ではないので、ここでは「すごい」や「やったね」といったフィードバックは行いません。しかし、チームによってはこういった一言が力になる場合もあります。純粋なコーチングですべてが解決するわけではないため、チームの自律を阻害しないのであれば、「今回アクションまでたどり着きましたね」といった承認の言葉を伝えてもいいと思います。 ＊ 今回は、コーチングの質問のなかでも、上級者が使う質問を解説しました。コーチングのプロは、それぞれの質問にはロジックを持ち、適切なタイミングで適切な質問をクライアントにぶつけてきます。 この領域に達するには、数年以上のトレーニングが必要です。私自身もコーチングを学び始めて3年目に入りますが、エキスパートレベルのコーチの質問やふるまい方は、いまだに真似することですら難しいと感じます。 まずは今回のような例を理解し、実際の現場で活用しながら、自分なりの質問力を磨いていくと良いでしょう。国際コーチング連盟が公開しているPCCマーカーに関連した質問集も作ってみたので参考にどうぞ。 リンク： PCCマーカーを使いコーチとしてのスキルや振る舞いを鍛えていく方法 次回は、最近では企業で当たり前のように行われるようになった、1on1の技術について解説します。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- The post 上級者が活用する質問例｜コーチング技術 -3- first appeared on Sqripts .

開発者やエンジニアが毎日直面する課題に対して、テスト自動化は時間の節約、精度の向上、リリースサイクルの加速をもたらします。迅速なフィードバックと継続的な改善プロセスを可能にする自動化テストの枠組みを採用することで、効率的かつ信頼性の高いソフトウェア開発の実現が可能になります。 Webアプリケーションの開発と配信が加速する現代では、Webブラウザを活用したテスト自動化が品質保証の重要な役割を果たしています。この記事ではTestArchitectを活用したWebブラウザベースのテスト自動化の特徴と、その効果的な活用方法を解説します。 クロスブラウザ対応による表示比較 TestArchitectは、Internet Explorer、Google Chrome、Mozilla Firefox、Safari、Microsoft EdgeでのWebアプリケーションの自動テストをサポートしています。ただ数多くのWebブラウザが使えるだけでなく、TestArchitectの特徴は実行するWebブラウザの変更が容易に行える点です。 作成したスクリプトは変更せず、異なるWebブラウザに切り変えた試験も簡単に行うことができます。 また、 [check picture] アクションを使用することでつのWebブラウザで事前に保存した画像と別のWebブラウザを使った試験での表示項目の違いなども簡単に確認することができるため、クロスブラウザの確認を非常に効率的に行うことができます。 例）ChromeとFirefoxの表示の違い 表示される位置が異なった場合の確認 上記の画像のように、Webブラウザ(A)で事前に保存した画像とWebブラウザ(B)を使ったテストでの表示項目の違いなど目視で捉えにくい表示位置のずれも、TestArchitectを用いれば明確に検出することができます。 このようにTestArchitectでは、クロスブラウザでの自動テストが容易になるだけでなく、高精度な検証を効率的に行うことができます。 Selenium WebDriverの活用 TestArchitectはWebアプリケーションのテストの自動化をサポートする仕組みであるWebDriverを使った自動テストを行うことができます。WebDriverモードに設定することで一度に複数のインスタンスで動作することができ、複数のウェブページを同時にテストすることができます。 またSeleniumベースで構築されたWebDriverは、id、name、tagname、classname、xpath、cssセレクタのようなSeleniumロケータを使用してWeb要素を特定したスクリプト作成を行うことができます。 例）xpathを使った共通関数の使い方 WebDriverを活用することでスクリプト作成の自由度を高め、自動化の活用範囲を広げることが可能になり開発の効率化を実現できます。Webブラウザを使った自動テストではWebDriverを使ったテストは必須と言えます。 レコーディング機能によるテストスクリプトの自動生成 TestArchitectのWebブラウザで自動化する場合にレコーディング機能を使用することができます。複雑な手順もレコーディング機能を使えば、ユーザの操作を記録して、その手順に基づいたスクリプトを自動的に生成します。 また、使用するWebブラウザや必要なボタン押下のタイミングの調整なども自動で設定されるため、事前の初期設定が不要となります。 TestArchitectはプログラムスキルを必要としないキーワード駆動型でスクリプト作成を行うため、このレコーディング機能を合わせて使えばプログラミングスキルがない方でもスクリプト作成を行うことができます。つまり、自動テストのスクリプト作成のハードルが下がり、経験の少ない方でも自動テストの作業を行うことが可能になるため、アサインに困ることも少なくなります。 他のプラットフォームと連携した自動化 TestArchitectはWebブラウザだけ自動化できるのではなく、Windowsアプリやモバイルアプリ/モバイルブラウザの自動化も行うことが可能です。例えばWindowsアプリに表示された内容を取得し、Webブラウザの自動テストに使用するといったこともできます。またcsvファイルの内容を取得し、そのデータを使った処理を行い実行結果をcsvファイルに記載することや、Databaseを使用した自動化も行えます。 TestArchitectではWebブラウザの自動化だけでなく、Windowsアプリやモバイルアプリ/モバイルブラウザなど異なるプラットフォームとの連携が可能になるため、自動テストの活用範囲が広がります。 TestArchitectによるWebブラウザのテスト自動化のまとめ TestArchitectを使ったWebブラウザのテストを自動化することにより、手動でのテストに比べて大幅に時間を節約し、より簡単に広範なテストカバレッジを実現することが可能です。さらに、自動化されたテストは再利用が可能で、異なるバージョンのアプリケーションに対して同一のテストを繰り返し実行することができます。これにより、開発チームは新たな機能の追加やバグ修正に集中できるようになり、製品の品質を一貫して保ちながら、市場へのリリースタイムを短縮することができます。 Webアプリケーションの開発においてテスト自動化を取り入れることは、今や業界標準となっています。ソフトウェア開発者やテストエンジニアは、これらのテスト自動化ツールを活用して、より高品質なアプリケーションをスムーズに提供し続けることが求められています。そのようなテストの自動化がTestArchitectでは可能です。 TestArchitectで自動化することでWebアプリケーションのパフォーマンスを最適化し、Webブラウザ上でのアプリケーション動作をスムーズかつ確実に実行します。さらに、開発プロセスを効率化し、バグの早期発見と迅速な修正を可能にします。 TestArchitect｜株式会社AGEST（アジェスト） AGESTのTestArchitectサービスの概要、選ばれる理由、事例紹介、FAQ、関連サービス、関連記事をご紹介しています。 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 The post テスト自動化ツールTestArchitectでのWebブラウザベーステストの効果的な活用方法 first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 第13回となる今回は「資源マネジメント後編」です。 前回と今回の2回に分けて、プロジェクトマネジメントにおける人、チーム、物資にスポットを当てて解説します。 チームを育成することがプロジェクト成功の鍵 プロジェクトを遂行する上で｢チームの力｣が欠かせません。ですからプロジェクトのパフォーマンスを上げるために、チーム全体の交流やチームの環境全体をより良いものにしなければなりません。 例えば、資料や技術を共有する、勉強会を実施するなどもその一貫です。チームワークがよい、というのは仲や雰囲気のよさだけではなく、スケジュールや品質、プロジェクト離脱率を低減するなど様々な改善に繋がります。 1) タックマンモデル（チーム形成の流れ） タックマンモデル（又はタックマン・ラダー）というフレームワークを知っていますか？1965年にブルース・タックマンによって初めて提唱された、チーム形成の流れを4段階で表したモデルです。どのようなチームでもプロジェクトにとってのシナジーチームになるためには、Forming（成立期）、Storming（動乱期）、Norming（安定期）、Performing（遂行期）という段階を経るというわけです。 チームが形成されるとその名の通り成立期になります。例えば、チームメンバーが顔合わせの段階で、「個々がまだ独立し自らの習慣や行動 ＞ チームの行動」となっている時期です。そのような個の集まりがプロジェクトというひとつの目的・目標達成のために共に活動することになるとどうなるでしょう。メンバーは独自の仕事のやり方、習慣、行動から抜け出せておらず、主張や衝突が起きやすくなります。しかしながらその衝突やマネジメントの介入を経て相互理解が進むと、習慣や行動を変化させはじめ、チームとしての活動が発生します。これが安定期です。さらに相互理解が進み、メンバーが相互補完関係となって相互依存状態となると、チームは生産的な状態になり遂行期を迎えますので「適切に、早く、遂行期にチームを導く」かを意識しましょう。 これらのチームの形成段階を見て、プロジェクト以外でも友人関係や会社組織において同じ体感を持つことも多いのではないでしょうか。チームはこのように成長する、というひとつのモデルを理解することで「どのようにしたらより成長させられるか」「マネジメント支援が必要か」「いかに混乱期を短くしようか」という働きかけができますね。 2) メンバーの感情に働きかける 「人は感情の生き物」と言われるように、ルールや物事の価値だけでは動かない場合があります。ですから、彼らがプロジェクトの目的・目標に向かってくれるように動機づけたり、感情に働きかける必要があります。 組織心理学者のエドガー H. シャイン博士が提唱した「 キャリア・アンカー 」は、人がキャリアを選択する際に最も大切にする価値観や欲求の概念で、組織や個人のキャリア形成診断などでも度々利用されます。8つの価値観のうち、メンバーがどの価値観に近いか、その価値観に訴えかけるようにコミュニケーションをとってみましょう。 ■ キャリア・アンカー （Wikipediaより） 3) モチベーションと欲求をコントロールする モチベーション理論 は人間の行動と意思決定を理解するための考え方のみならず、資源マネジメントをする上で非常に有用です。理論を理解してメンバーやチームに沿った形で適用することで、よりよいパフォーマンスをリードしましょう。すぐには難しいかもしれませんが、代表的な理論はイメージできるようにしておきましょう。また、メンバーがどのような状態にあるのかは、周りからの見極めだけでは難しいため、メンバーやその上長との対話から「どんなことをやりたいか」「プロジェクトで力を発揮できそうか」という情報を聞き出すことをお勧めします。 マズローの要求5段階説 人の欲求は5段階あり、次の順に（段階的に）満たされる （生理的欲求→安全欲求→社会的欲求→承認欲求→自己実現欲求） ハーツバーグの動機づけ要因と衛生要因 動機づけ要因：達成、認知、責任、成長、内容、昇進 衛生要因（仕事をするための外部要因）：給与、処遇、作業条件、会社方針 マクレガーのX理論・Y理論 X理論：「人は元来仕事が嫌いである」という考え方に基づいて仕事をさせる Y理論：「人は適切な動機づけ要因のもとで仕事するものである」という考えに基づいて仕事をさせる ビクター・ブルーム期待理論（2段階期待） 人は成功するために努力し、成功の暁には報奨を期待する ■ 動機づけ （Wikipediaより） チームをマネジメントする チームワークを促進して、チームメンバーの活動をまとめ高いパフォーマンスを発揮する（させる）ために、プロジェクトマネージャーは常に心を配る必要があります。コミュニケーションの状況（計画したコミュニケーションは効果的に機能しているか）、何かコンフリクトは起こっていないかなど注意してマネジメントしましょう。 1) コンフリクトはチャンスである 先ほどのタックマンモデルからもわかるように、プロジェクト下ではコンフリクトは避けられません。原因としては資源不足、スケジュールの優先順位、個人の作業スタイルなど様々ですが、チームの行動規範や役割を明確にすることなどでコンフリクトを「減らす」ことは可能です。そしてコンフリクトと聞くとネガティブなイメージに捉えられがちですが、コンフリクトをコントロールし「適当に意見の相違をマネジメントする」ことに成功すれば、より高い創造性と意思決定にもつながるはずです。状況に応じて手段の中から適切な打ち手を選択または組み合わせて、早期にコンフリクトに向き合い解消することが大切です。 2) チームは「キックオフ」で決まる みなさん「キックオフ」していますか？キックオフ（kickoff）はサッカーやアメフトなどのスポーツで試合開始を意味する言葉です。これが派生してビジネスでは「プロジェクトを開始（開始にあたる会議を開催）する」という意味でキックオフ（kick_off）/キックオフミーティングが用いられています。キックオフはプロジェクトの開始前或いは開始時点でメンバ同士でチームの足並みを揃える「手段」ですが、その良し悪しでプロジェクトやチームの生産性が大きく変わることがあります。キックオフは必ず実施すること、そして参加者がモチベーションをあげてプロジェクトに取り組み出せるように「戦略的」にミーティングをリードしましょう。 キックオフで必要なアジェンダ（最低限） PMの自己紹介 この人と一緒に仕事がしたい（するんだ頑張ろう）、と思ってもらえる自己紹介 プロジェウト概要説明 簡潔（6W2H）にPJの目的目標、スケジュールや体制を共有し、PJの必要性・意義を伝えてモチベーションを高める メンバー自己紹介 各参加者が自己表現できる場を持つと同時に、PMは「役割・召集理由・個別の期待・実績」などを他の参加者に説明し「あなたに期待していますよ」というメッセージを伝え、モチベーションを高める チームルールや重要事項 コミュニケーション方法やデータの取り扱いなどを明確化する 質疑応答 多くの場合このキックオフが「最初の認識ズレ」を生みます。説明した概要などが「ちゃんと伝わっているか」確認し、疑問を取り切ること。 キックオフで「しない」2つのこと 細かい話はしない キックオフではPJの目的目標などを共有し、参加者の足並みを揃え、プロジェクトに対するモチベーションを高めることです。ですからキックオフでいきなり「AさんはXタスクをなるはやで作成してください、なぜならその工程が遅れると全体遅延に繋がるので逐一報告してください」などと言われたらどうでしょうか？プレッシャーを感じ、やる気が失せてしまうかもしれません。もし参加者から細かい話を尋ねられた場合も「その話は次の個別会議で会話を開始します」と切り分けるようにしましょう。 ネガティブな発言はしない キックオフはモチベーションを高める場ですので、モチベーションを下げる可能性がある言動に注意しましょう。例えば本当にプロジェクトの期限がタイトだったとしても「納期を守るために土日返上も覚悟しなければならない…」と言われたら困惑しますよね。嘘をつく必要はありませんが、どこまでどのように共有するべきか注意しましょう。 さいごに 資源マネジメントは人（が作る）の要素が強いITプロジェクトでは肝になるマネジメントであり、PMの「仕込み力」が多いに試されます。人やモノを揃えればチームがチームが能動的に動いてくれる訳ではありません。チームをしっかりと育てプロジェクトを成功させましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ The post 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ first appeared on Sqripts .

こんにちは、エンジニアのぱやぴです！ 前回は「Playwright 実践～超簡単 4Step～」を解説しました。 Playwrightはじめました ～E2Eテストを4Stepで自動化～ みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。今回はE2EツールであるPlaywrightについて書いていきます。なぜPlaywrightなのか・・・。やはり【無料】・【Microsoftが開発した】という、特徴で選定しました。▼続編はこちらPlaywright... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、Microsoft Visual Studio Code（以下VSCode）とPlaywrightを使って、ウェブサイトのテスト自動化を実現する方法をご紹介します。具体的には、 こちらのウェブサイト を例に、テストコードの作成から実行までの流れを解説します。 環境 Node.js 22.4.1 VSCode 1.91.0 Playwright 1.45.1 準備 Node.js と VSCode のインストールは割愛させていただきます。 Playwrightのインストール VSCodeのPlaywrightの拡張機能をインストールする Playwright Test for VSCode – Visual Studio Marketplace Playwrightのインストール VSCodeのコマンドパレットを開き(Windows: shift + ctrl + p, mac: shift + command + p) Test: Install Playwright を入力、選択しPlaywrightのインストールを行います。 　　以下必要なものにチェックを入れ OK を押下。 ターミナルに以下の文章が出ればインストール完了です。 実行 PlaywrightのRecord機能を使ってテストコードを生成 Playwrightには、ブラウザでの操作を記録し、自動的にテストコードを生成するRecord機能があります。 VSCodeのサイドバーの以下のアイコンをクリック Record new をクリック 開いたブラウザで、テストしたい操作を行います。 例えば、ページのタイトル確認、メニューアイテムの確認、特定のセクションの存在確認などを行います。 以下のようなコードが自動生成されました。 import { test, expect } from '@playwright/test'; test('test', async ({ page }) => { await page.goto('https://agest.co.jp/'); await page.locator('#gh_search').click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).fill('テスト'); await page.getByRole('searchbox', { name: 'キーワードを入力' }).press('Enter'); await page.getByRole('link', { name: 'テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]' }).click(); await page.getByRole('link', { name: '株式会社AGEST（アジェスト）' }).click(); }); テストの実行 先ほどできたテストコードの「Run Test」ボタンをクリックして、テストを実行します。 ここでshow borwserやshow trace viewer にチェックをいれると視覚的にテスト実行を見ることができます。 テストを実行することができました！ おまけ: 生成されたコードをLLMに渡しPage Object Model（以下POM）に変換 このままでもテストを実行することができるのですが、テストコードの可読性とメンテナンス性を向上させるために、生成されたコードをPOMに変換します。 POMとは？ POM (Page Object Model)は、Webアプリケーションのテスト自動化のためのデザインパターンです。以下にPOMの主なポイントを簡潔にまとめます。 - 各Webページを独立したクラスとしてモデル化する - ページ要素(ボタン、フォームなど)をプロパティとして定義する - ページ上の操作をメソッドとして実装する - テストコードとページ操作を分離し、保守性を向上させる - 要素のセレクタ変更時に修正箇所を局所化できる - コードの再利用性が高まる - テストコードがより読みやすく、理解しやすくなる - ページ間の遷移を明確に表現できる - テストフレームワークに依存せず使用可能 POMを活用することで、テストコードの保守性、再利用性、可読性が向上し、長期的なテスト自動化の効率が高まります。 変換にはLLM(ChatGPT, Gemini, Copilot, Claude等)を用います。LLMの利用は自己判断でお願いいたします。 今回はGithub Copilot ChatとClaude3.5 sonnetを用いました。 1. Github copilot 先ほど生成されたコードを以下のようなプロンプトでLLMに渡します。 以下のplaywrightのコードをPOM(page object model)に変換してください。 test('agestHP test', async ({ page }) => { await page.goto('https://agest.co.jp/'); await page.locator('#gh_search').click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).click(); await page.getByRole('searchbox', { name: 'キーワードを入力' }).fill('テスト'); await page.getByRole('searchbox', { name: 'キーワードを入力' }).press('Enter'); await page.getByRole('link', { name: 'テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]' }).click(); await page.getByRole('link', { name: '株式会社AGEST（アジェスト）' }).click(); }); 以下のような回答が返ってきました。 回答を基に pages フォルダを作成、その中に AgestHomePage.ts ファイルを作成し、以下のようなPage Objectクラスを定義します。： import { Page } from "@playwright/test"; export class AgestHomePage { page: Page; constructor(page) { this.page = page; } async navigate() { await this.page.goto("https://agest.co.jp/"); } async searchForKeyword(keyword) { await this.page.locator("#gh_search").click(); await this.page .getByRole("searchbox", { name: "キーワードを入力" }) .click(); await this.page .getByRole("searchbox", { name: "キーワードを入力" }) .fill(keyword); await this.page .getByRole("searchbox", { name: "キーワードを入力" }) .press("Enter"); } async clickOnTestOutsourceLink() { await this.page .getByRole("link", { name: "テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]", }) .click(); } async clickOnAgestLink() { await this.page .getByRole("link", { name: "株式会社AGEST（アジェスト）" }) .click(); } } tests フォルダ内の先程の test-1.spec.ts を agestHomePage.spec.ts とリネーム、ファイル内容を回答を基に先ほど作ったクラスを用いるように更新します。 import { test } from '@playwright/test'; import { AgestPage } from '../pages/AgestPage'; test('AGESTのウェブサイトのテスト', async ({ page }) => { const agestPage = new AgestPage(page); await agestPage.goto(); await agestPage.verifyTitle(); await agestPage.verifyLogo(); await agestPage.verifyMenuItems(); await agestPage.verifyCaseStudySection(); await agestPage.verifyFooter(); }); テストは実行できましたが、以下の理由からPOMとして正しく汎用的に作成できていません。 各Webページを独立したクラスとしてモデル化できておらず、agestHomePageとして集約されている ページ要素(ボタン、フォームなど)をプロパティとして定義できてない 2. Claude 3.5 sonnetでもう一度 Claude3.5で同じプロンプトで実行し、出力された結果が以下です。 // AgestHomePage.js class AgestHomePage { constructor(page) { this.page = page; this.searchButton = page.locator('#gh_search'); this.searchBox = page.getByRole('searchbox', { name: 'キーワードを入力' }); } async goto() { await this.page.goto('https://agest.co.jp/'); } async clickSearch() { await this.searchButton.click(); } async searchFor(keyword) { await this.searchBox.click(); await this.searchBox.fill(keyword); await this.searchBox.press('Enter'); } } // SearchResultsPage.js class SearchResultsPage { constructor(page) { this.page = page; this.testOutsourceLink = page.getByRole('link', { name: 'テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]' }); } async clickTestOutsourceLink() { await this.testOutsourceLink.click(); } } // TestOutputPage.js class TestOutputPage { constructor(page) { this.page = page; this.companyLink = page.getByRole('link', { name: '株式会社AGEST（アジェスト）' }); } async clickCompanyLink() { await this.companyLink.click(); } } // test.spec.js const { test, expect } = require('@playwright/test'); const { AgestHomePage } = require('./AgestHomePage'); const { SearchResultsPage } = require('./SearchResultsPage'); const { TestOutputPage } = require('./TestOutputPage'); test('agestHP test', async ({ page }) => { const homePage = new AgestHomePage(page); const searchResultsPage = new SearchResultsPage(page); const testOutputPage = new TestOutputPage(page); await homePage.goto(); await homePage.clickSearch(); await homePage.searchFor('テスト'); await searchResultsPage.clickTestOutsourceLink(); await testOutputPage.clickCompanyLink(); }); このままでは動かない & typescriptではなかったため、回答を基にして以下の様に修正しました。 修正点は主に各ページクラスのpage, searchButton等のページ要素の変数定義と型指定です。 ”playwright/test” から Locator , Page をimportし変数を定義し、ファイルを作成しました。 import { Locator, Page } from "playwright/test"; export class AgestHomePage { page: Page; searchButton: Locator; searchBox: Locator; constructor(page: Page) { this.page = page; this.searchButton = page.locator("#gh_search"); this.searchBox = page.getByRole("searchbox", { name: "キーワードを入力" }); } async goto() { await this.page.goto("<https://agest.co.jp/>"); } async clickSearch() { await this.searchButton.click(); } async searchFor(keyword) { await this.searchBox.click(); await this.searchBox.fill(keyword); await this.searchBox.press("Enter"); } } import { Locator, Page } from "playwright/test"; export class TestOutputPage { page: Page; companyLink: Locator; constructor(page: Page) { this.page = page; this.companyLink = page.getByRole("link", { name: "株式会社AGEST（アジェスト）", }); } async clickCompanyLink() { await this.companyLink.click(); } } import { Locator, Page } from "playwright/test"; export class SearchResultsPage { page: Page; testOutsourceLink: Locator; constructor(page: Page) { this.page = page; this.testOutsourceLink = page.getByRole("link", { name: "テストアウトソースにおけるアウトプット資料例 本資料では、アウトプット資料のイメージをご紹介しています。[…]", }); } async clickTestOutsourceLink() { await this.testOutsourceLink.click(); } } import { test, expect } from "@playwright/test"; import { AgestHomePage } from "../pages/agestHP"; import { TestOutputPage } from "../pages/TestOutputPage"; import { SearchResultsPage } from "../pages/SearchResultsPage"; test("agestHP test", async ({ page }) => { const homePage = new AgestHomePage(page); const searchResultsPage = new SearchResultsPage(page); const testOutputPage = new TestOutputPage(page); await homePage.goto(); await homePage.clickSearch(); await homePage.searchFor("テスト"); await searchResultsPage.clickTestOutsourceLink(); await testOutputPage.clickCompanyLink(); }); 少し修正は必要でしたが、Claude3.5 sonnetでは正しくPOMとして出力されました！ よりプロンプトを詳細にかければ、修正も必要なくPOMとして出力できるかと思いますが、今回のような簡単なプロンプトでもPOMの雛形を簡単に作成することができました。 これでページごとにクラスオブジェクトとして分けることができ、テストも実行することができました。 まとめ VSCodeとPlaywrightを組み合わせることで、効率的にウェブサイトのテスト自動化を実現できます。PlaywrightのRecord機能を使えば、簡単にテストコードを生成でき、それをPOMに変換することで、より保守性の高いテストコードを作成できます。 今回は弊社のウェブサイトを例に取りましたが、同様の方法で他のウェブサイトのテストも作成できます。自動化されたテストを導入することで、ウェブサイトの品質を継続的に確認し、問題を早期に発見することができます。 また、LLMによる「PlaywrightコードからPOM自動生成」を試みた際、使用するLLMによって精度も違うことがわかり、こちらも非常に勉強になりました。 ぜひ、皆さんのプロジェクトでもVSCode、Playwrightを活用して、効率的なテスト自動化を実現してみてください！ ここまで読んでいただきありがとうございました。 ▼前回の記事はこちら Playwrightはじめました ～E2Eテストを4Stepで自動化～ みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。今回はE2EツールであるPlaywrightについて書いていきます。なぜPlaywrightなのか・・・。やはり【無料】・【Microsoftが開発した】という、特徴で選定しました。▼続編はこちらPlaywright... 　続きを読む　 Sqripts 関連記事｜Sqripts The post VSCodeとPlaywrightで始めるウェブサイトテスト自動化：初心者向け完全ガイド first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 今回は、条件を表す言葉“ならば”と、選言“または”を組み合わせた推論の形を見ていきます。 その前に、前回のクイズの答えです。 前回クイズ解答 問題(再掲) 問1～問3の主張は妥当でしょうか。推論の形に着目して考えてください。 解答 問1。混合仮言三段論法で、①に対する前件否定（②）から、①の後件の否定を結論としています（③）。形式上の誤りで非妥当です。 （実際、テストの期間・工数の超過を招く要因は、設計成果物の欠陥の多さ だけではありません ） 問2。純粋仮言三段論法です（①～③までが前提）。仮言判断の連鎖から、①の前件と③の後件をつないだ仮言判断を結論としています。これは妥当な形です。 問3。純粋仮言三段論法＋混合仮言三段論法といった形です（③が②を承けた断言判断）。③が②に対する後件肯定であり、④で①の前件の肯定を結論としています。形式上の誤りで非妥当です。 （テスト結果がおかしくなる原因はテストデータの誤り 以外にもあり得ます ） ふたつの“ならば”と、“または”で推論する 両刀論法(ディレンマ, ジレンマ)とは 図5-1のような形の推論を 両刀論法 といいます。 図5-1 両刀論法のイメージ ふたつの仮言判断（条件法を使った文）に対して選言判断を組み合わせて結論を導きます。 両刀論法の形式の例(複雑構成的) 図5-1で示した形は、 「複雑構成的」両刀論法 といいます。 ①PならばR、かつ、QならばS。 ②Pか、またはQ。 従って、③Rか、またはS。 前提1で、ふたつの仮言判断A, Bを並べ、 「 どちらも、前件が成り立つなら後件は成り立つ 」という主張をします。 前提2で、ふたつの仮言判断の 前件のどちらかは真だ と主張します （Aの前件が真であるか、または、Bの前件が真）。 すると、 前件肯定 から結論「ふたつの仮言判断の 後件のどちらかは真だ 」が浮かび上がってきます(図5-2)。 （前件肯定は、「 “ならば”を使って推論する 」参照） 図5-2 両刀論法のしくみ(複雑構成的) 前提1は、条件つきの主張をふたつ提示するのが主眼です。本記事では形を示すのに連言（“かつ”）で表していますが、連言の形を取らない例も多く見られます。 例。 ①明日が雨なら、Aさんは自宅にいるでしょう。明日雨が降らないなら、Aさんはサイクリングを楽しむでしょう。 ②明日は雨が降るか、降らないか、どちらかです。 従って、③明日Aさんは自宅にいるか、サイクリングをしているか、どちらかです。 ディレンマ, ジレンマ 両刀論法は英語では「ディレンマ, ジレンマ(dilemma)」と呼ばれます。 「ジレンマ」は、古代ギリシャ語の「ディレンマ」（dilemma）が語源である。 ディレンマは、「二つの前提」を意味する「ディ」（di）と、「仮定」を意味する「レンマ」（lemma）が組み合わさった言葉である。 weblio辞書「ジレンマ」 から 日本語では、“ジレンマ”は「ふたつの選択肢のどちらを選んでも困ったことになる“板挟み”の状態」といった意味で使われることが多いと思われます。 先の複雑構成的の形で、Qを「Pでない(NOT(P))」と置くと、 ①PならばR、かつ、NOT(P)ならばS。 ②Pか、または、NOT(P)。 従って、③Rか、またはS。 PとNOT(P)のどちらかにならざるを得ず、RもSも好ましくない結果なら、典型的なジレンマが出現します。 例。 (笑えません) ①テストを続けるならば、テスト期間が伸びてリリースが遅れることになる。テストを止めるならば、テスト不足のままリリースすることになる。 ②テストを続けるか、止めるかのどちらかだ。 従って、③リリースが遅れるか、テスト不足の製品をリリースするかのいずれかだ。 しばしば聞く言葉ですし、案外よく見かける立論の形式ですから、こういう推論の形があることとその特徴を知っておくのは有益でしょう。 両刀論法 両刀論法の形：単純/複雑と、構成/破壊 両刀論法は、 前提1は、ふたつの仮言判断 前提2は、前提1の各仮言判断の 肯定(前件の肯定) 、または 否定(後件の否定) という形を取ります。 前提1に着目して、 単純式/複雑式 と区分されます。 単純式：前提1のふたつの仮言判断の、 前件または後件が同じ 複雑式：前提1のふたつの仮言判断の、 前件/後件ともに異なる 前提2に着目して、 構成式/破壊式 と分けられます。 構成式：前提2で、前提1のふたつの仮言判断の 前件を肯定 する 破壊式：前提2で、前提1のふたつの仮言判断の 後件を否定 する いずれも、前提2は選言 両刀論法の4つの形 前提1の単純/複雑、前提2の肯定/否定の組合せから、4通りの形があります(図5-3)。 説明済みの複雑構成的(図5-2)を基にすると考えやすいでしょう。 図5-3 両刀論法の4つの形 （「 基本的な推論形式 」では、複雑構成的と複雑破壊的のふたつを紹介しています） 複雑破壊的 複雑破壊的(図5-4)は、複雑構成的(図5-2)の前提2を、前件肯定（Pか、またはQ）から 後件否定（Rでないか、またはSでない） に変えた形です。 それぞれの後件が否定され、 結論は前件の否定「Pでないか、またはQでない」 になります。 図5-4 両刀論法のしくみ(複雑破壊的) 例。 ①Bさんが参考書を読んでいるなら、この問題の解き方を知っている筈だし、この分野に詳しいなら、この問題の難しさを判っている筈だ。 ②Bさんはこの問題の解き方を知らないか、この問題の難しさを判っていないか、どちらかだ。 だから、③Bさんは参考書を読んでいないか、この分野に詳しくない。 単純構成的 単純構成的(図5-5)は、複雑構成的(図5-2)の前提1におけるふたつの仮言判断の後件(R, S)をひとつ(Rのみ)にした形です。 前提2の前件肯定から、結論は後件の肯定 「Rである」になります。 図5-5 両刀論法のしくみ(単純構成的) 例。 ①スポーツを続けるなら、Cさんにとってはいい経験だし、スポーツを止めて別のことに取り組むなら、それもいい経験になる。 ②Cさんはスポーツを続けるか、スポーツを止めるか、どちらかだ。 ③いずれにしろCさんにはいい経験になる。 単純破壊的 単純破壊的(図5-6)は、複雑破壊的(図5-4)の前件(P, Q)をひとつ(Pのみ)にした形です。 単純構成的(図5-5)の、前提1の前件をPひとつに、後件を異なるふたつ(R, S)にし、前提2を前件肯定から後件否定に変えた形とも読めます。 前提2の後件否定から、結論は前件の否定 「Pではない」になります。 図5-6 両刀論法のしくみ(単純破壊的) 例。 ①Dさんは、学校の試験の成績がよいと、帰宅してからとても明るいし、晩ご飯をよく食べる。 先週期末試験があったが、 ②今週のDさんは毎日暗いか、ご飯をあまり食べないかのどちらかだ。 ということは、③Dさんは先の期末試験の成績がよくなかったのだな。 両刀論法・補足 排他的な“または”でも成り立つ 前提2と結論の選言(“または”)は、排他的な“または”でも成り立ちます。 “刀”が二本より多い場合 前提1の仮言判断が二つより多くても同じ形の推論ができます。仮言判断の数ごとに名前がついています(図5-7)。 図5-7 仮言判断の数に応じた名称 両刀論法・気をつけたい落とし穴(誤謬) 後件肯定の誤謬、前件否定の誤謬 “ならば”を用いた条件つき主張(仮言判断)を使う推論ですから、形式面では仮言三段論法と同じ落とし穴があります。 構成式で、「Rか、またはS」(複雑構成的の場合）という 後件肯定 から結論として「Pか、またはQ」を引き出すのは誤った推論です（ 後件肯定の誤謬 ）。 破壊式で、「Pでないか、またはQでない」(複雑破壊的の場合）という 前件否定 から結論として「Rでないか、またはSでない」を引き出すのも誤った推論です（ 前件否定の誤謬 ）。 （「 “ならば”を使って推論する 」参照） 選言肢不完全の誤謬 内容面で気をつけるべきことのひとつには、選言三段論法で紹介した「選言肢不完全の誤謬」があります（「 “または”を使って推論する 」）。 前提1の仮言判断が主張したいことを網羅できていなかったら、不備のある推論になってしまいます。 仮言判断の前件と後件の関係性 選言肢不完全の誤謬に通じますが、前提1が： ふたつの仮言判断の関係が希薄だったり、 それぞれの前件と後件のつながりに必然性がなかったり するものだと、飛躍や抜けのある推論になってしまいます。 ？？？な例。 ①開発中の製品ですが、売上がよかったらボーナスが出ます。開発が失敗したら、その経験を論文にして発表できます。 ②開発は成功するか、失敗するか、どちらかですが…… ③ボーナスが貰えるか、または、論文を発表できます。（＝いずれにせよ得るものがあります！） 留意点 両刀論法は 内容が偽であっても形式上は妥当な(よい形の)主張 を作りやすく、かつ「いずれにせよ××」的な主張を作りやすいので、古来より詭弁によく用いられてきたとされます（形は整っているために、反駁・反論が面倒）。 詭弁のつもりはなくとも間違いが混入している可能性がありますから、この形の推論に出会った時にはその内容面をよく吟味するのが望ましいと言えるでしょう。 ジレンマという言葉が聞こえたら、「それは両刀論法のどの形に該当するだろう？」と考えてみるのもいいトレーニングになります（隠れている前件や後件を補う必要がある場合もありますが、それも含めて）。 なお、内容面の誤謬とその反論については、回を改めて紹介する予定です。 クイズ 問1～問3の主張はそれぞれ両刀論法のどの形に該当するでしょうか。また妥当な形でしょうか。（解答は次回に） 次回 「ソクラテスは死ぬ」でおなじみの（ではないかも知れませんが）、「三段論法と言われたらコレ、の三段論法」を取り上げます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 図版に使用した画像の出典 ヒューマンピクトグラム2.0 ピクトグラムをお借りしています。 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する “ならば”を使って推論する The post “ならば”と“または”で推論する｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .

みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。 今回はE2EツールであるPlaywrightについて書いていきます。 なぜPlaywrightなのか・・・。 やはり 【無料】・【Microsoftが開発した】 という、特徴で選定しました。 Playwrightとは まずPlaywrightについて、簡単に記載しようと思います。 Playwrightは、End to Endテスト（以下、E2E）が行えるオープンソースライブラリで、 Microsoft が開発しました。 そして、E2Eが行えるのはもちろんですが、その他以下のような特徴があります。 UIモード レコーディング機能 HTMLレポート生成 APIテスト クロスブラウザ・クロスプラットフォーム CI/CD その他諸々・・・ 詳しくは後述しますが、非エンジニアでも使用できる「UIモード」や「レコーディング機能」があります。 また、画面のテストにとどまらずRestful APIのテストも行えるなど、無料ツールにしては、かなり多機能となっています。 類似ツールでもクロスブラウザ・クロスプラットフォームは実現できますが、「Safari（正確にはwebkit）」もサポートしていることが特徴になるかと思います。 類似ツールでは、同ブラウザをサポートしていなかったりするので、ポイントが高いです。 公式も売りの1つに挙げていて、個人的に魅力に感じているのは、「テストの安定性」です。詳しくは割愛しますが、他のツールと異なり、クライアント側の通信が非常にシンプルな仕組みになっているので、クライアント側の通信が不安定になりテストが失敗してしまうことを防ぐことができていると考えています。 Playwright 実践～超簡単 4Step～ ここまでPlaywrightの概要を記載してきましたが、インストール → テストコードの実行→レポート出力までの手順も、非常に簡単なので、「 超簡単 4Step 」として、ご紹介していきます。 ※ 本記事では、「TypeScript / JavaScript」を前提に進めて行くので、前提としてNodejsのインストールが必要です。下記の公式サイトよりインストーラーをダウンロードしてインストールを実施してください。 Node.js-インストーラー- 1. 下準備 まずは、Playwrightをインストールするための適当な作業フォルダを作成します。 以下の操作を行い、コマンドプロンプトを開いてください。 ※ フォルダ作成はエクスプローラで行っても問題ありません [Windowsキー]＋[R]を押してください 「ファイル名を指定して実行」に「cmd」と入力してエンターキーを押してください コマンドプロンプトが開いたら、以下の2つのコマンドを実行してください。 # mkdirで「playwright_sample」というフォルダを作成します mkdir playwright_sample # cdで「playwright_sample」フォルダへ移動します cd playwright_sample 2. Playwrightインストール Nodejsに含まれている npm （パッケージ管理コマンド）を使用して、先ほど作ったフォルダにPlaywrightをインストールします。 install ではなく、 init であることに注意してください。 npm init playwright@latest コマンドを実行すると、以下の設定について聞かれるので、全部デフォルトでエンターキーを押してください。 # 使用するプログラム言語 ? Do you want to use TypeScript or JavaScript? … # テストシナリオを配置するフォルダ ? Where to put your end-to-end tests? » tests # CI/CDに使用するGithub Actionsのworkflowを作成するか否か ? Add a GitHub Actions workflow? (y/N) » false # Playwrightブラウザをインストールするか ? Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) » true インストールが開始され、完了まで待ちます。 3. テスト実行 インストールが完了すると、すぐに実行できるサンプルのテストコードが作成されるので、以下のコマンドを使用して、テストシナリオを実行してください。 ※ 先頭の文字列が npx となっていることに注意してください。 npx playwright test 4. レポート表示 テストシナリオの実行が完了したら、以下のコマンドを実行してレポートを表示させます。 実行するとWindowsで使用しているブラウザにHTMLのレポートが表示されます。 ※ テストが失敗している場合は、実行後に自動でレポートが表示されます npx playwright show-report 以下は、「example.spec.ts」というテストシナリオが、各ブラウザで実行された結果です。 その他機能 Playwrightは基本的にゴリゴリにプログラムコードを書いていくことになりますが・・・。 「その他機能」として、コマンドを実行せずに、画面操作でテストシナリオを実行できる「UIモード」や、ブラウザを操作して、その操作を記録しテストコードを生成したりする「レコーディング機能」があります。 それぞれご紹介します。 UIモード 以下のコマンドを実行することで、テストシナリオの実行やデバッグなどが視覚的に行える画面が起動します。 npx playwright test --ui 左側には、テストファイルがあり、ファイル内にあるテストシナリオが一覧として並んでます。 それぞれも「再生」ボタンをクリックして実行することもできますし、ファイルにあるシナリオ全部を一気に実行することも可能です。 また、真ん中あたりにある「Actions」には実行された操作ステップが表示され、「Action」には操作した画面が表示されています。 レコーディング機能 以下のコマンドを実行することで、ブラウザが起動し操作することで、テストコード（操作）が記録されていきます。 記録された内容は、別ウィンドウで確認することができます。 npx playwright codegen また、ブラウザの上部にあるアイコンをクリックすることで、レコーディングの再開・停止や、要素の取得、 値の検証（以下、アサーション）も追加することができます。 そのためコーディングが苦手だったり、非エンジニアでも簡単なテストシナリオの作成ができます。 Playwrightでよく登場する（しそうな）関数 テストコードを自分で実装もしくは、レコーディングした際に登場するであろう関数を紹介していきます。 以降の「{}」は引数を表しています。 ページを開く page.goto({URL})： 引数に指定したURLを開きます 例） page.goto('<https://playwright.dev/>') 要素取得 page.getByRole({tag name etc…})： WAI-ARIAロールで定義されている heading などを指定し要素を取得します。 以下の例のように「h1」タグ＋その中にある値で要素を取得するような使い方ができます。 例） page.getByRole('heading', { name: 'Installation' }) ※ WAI-ARIA ロール page.locator({css name etc…})： 引数にCSS名を入力することで要素を検索できます。 またIDや、Xpathでも検索できます。 例1）IDを使用する page.locator('#'sample') 例2）Xpathを使用する page.locator("//h2[@class='sample']") 操作 page.getByRole({tag name etc…}) .click() ： .click() を記載することで、取得した要素をクリックします。 例） page.getByRole('heading', { name: 'Playwright enables reliable' }).click() page.locator({css name etc…}) .fill({input string}) ： .fill() を記載することで、取得したテキストボックス（エリア）に値を入力します。 例） page.getByRole('検索', { exact: true }).fill('playwright') アサーション Playwrightでは値のアサーションをするために、expectという関数を使用します。 expect関数にドットつなぎで使用します。 expectの引数には、 getByRole や、 locator で取得した要素を設定します。 以下のように設定可能です。 例1）直接引数に設定する expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible() 例2）変数に格納してから設定する const element = page.getByRole('heading', { name: 'Installation' }) expect(element ).toBeVisible() expect({locator}).toBeVisible()： 要素が表示されているかアサーションします。 例は前述のように使用します。 expect({locator}).toContainText({title string})： 指定した要素に特定の文字列があるかアサーションします。 例） expect(page.getByRole('banner')).toContainText('Get started') expect(page).toHaveTitle({title string})： 検証対象のサイトのタイトルがあるか確認します。 例） expect(page).toHaveTitle('Sample Title') あとがき Playwrightを調査したところ、インストールの方法などは、公式からの情報（ドキュメント）も多いので、コーディング経験が少しでもあれば、比較的導入しやすいように感じました。 一方で、テストシナリオの実行はコマンドプロンプトを使用しなくてもUIツールでできますし、実行するためのテストシナリオ作成もレコーディング機能を使用することでブラウザ操作を記録できるので、簡単なテストケースなら非エンジニアでも作成ができそうです。 また、本ツールが無料ということもあり、コスト面でCI/CDに組み込みやすいと感じます。 以上、Playwrightの紹介ですが、本記事を読んで興味が出たら、お試しいただけたらと思います！ The post Playwrightはじめました ～E2Eテストを4Stepで自動化～ first appeared on Sqripts .

こんにちは。今回、Udemyにて「ゼロから始めるソフトウェアテスト技法」の講座を公開させていただきましたことをお知らせします。 本記事では、公開された講座がどのようなものなのか、ソフトウェアテストの近い未来をお伝えします。 講座の紹介 本講座の「ゼロから始めるソフトウェアテスト技法」では、ソフトウェアテスト技法の基礎から、よくある仕様を使ってソフトウェアテスト技法の実践的な適用方法を解説したものです。 本講座は、次のような方に見てもらいたい内容となっています。 ソフトウェアテスト未経験者 ソフトウェアテスト経験者 ソフトウェア開発者 エンジニアを目指す学生 このように、本講座は「 テストをこれから学ぼうという方 」から「 ある程度のテスト経験がある方 」までを対象としています。 ソフトウェアテスト技法の基本的な概念をしっかりと押さえたうえで、よくある仕様を使ってソフトウェアテストの考え方を解説します。 また、ソフトウェアテストの考え方で間違いやすいことを紹介しながら解説していますので、ある程度のテスト経験がある方にもお勧めです。 本講座は、次のような課題解決の一助になればと思い公開させていただきました。 思いつきでテストをしている 似たようなテストを繰り返している ソフトウェアテストのコストが非常に大きくなってしまう （費用対効果が得られない） ソフトウェアテストをしても不具合が見つからない （リリース後に不具合が見つかる） 開発やテストを学び始めの方は、「 思いつきでテストをしている 」や「 不具合を出さないためにひたすら動作チェック（テスト）している 」といったことが起こりがちです。 このようなソフトウェアテストには、「 どのようなテストをしたのか思い出せない 」であったり、「 テストをしても不具合が見つけられない （後日に他の人から指摘される）」といった問題が起こります。 気付かぬうちに似たようなテストを繰り返していれば、不具合を見つけにくくなります。 この場合、テストのコストに対してテストの効果が得られないため、漠然とした不安だけが残ります。 そこで、本講座で取り扱ったのが、ソフトウェアテスト技法です。 ソフトウェアテスト技法には、これまで不具合が起こりやすいと言われてきたノウハウが詰まっているため、正しく理解し使用することで、テストの効果を高めることができます。 講座の概要 本講座で取り扱う概要を紹介いたします。 1: ブラックボックステスト ソフトウェアテスト技法の導入として、ブラックボックステストとは何か、なぜソフトウェアテスト技法が必要なのかを解説します。 キーワード ： ブラックボックステスト、コスト、期限、全数テスト、不具合、入力、出力、テスト条件、要求、仕様、仕様の理解、テスト数の削減、同値分割法、境界値分析、デシジョンテーブル、状態遷移テスト、ペアワイズテスト、カバレッジ 2: 同値分割法、境界値分析 同値分割法、境界値分析の基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、テスト実施に使用できる代表値の考え方や、テスト数の考え方についても解説します。 キーワード ： 同値分割法、境界値分析、入力、出力、データの集合、同値クラス、同値クラス分割、有効同値クラス、無効同値クラス、代表値、境界、境界値、2値の境界値、3値の境界値、カバレッジ 3: デシジョンテーブルテスト 状態遷移テストの基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、状態遷移図や表の書き方やテストケースの考え方についても解説します。 キーワード ： 状態遷移テスト、状態、イベント、有効な遷移、無効な遷移、状態遷移図、状態遷移表、マトリクス、UML、N/A、カバレッジ、見える化、テストケース 4: 状態遷移テスト 状態遷移テストの基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、状態遷移図や表の書き方やテストケースの考え方についても解説します。 キーワード ： 状態遷移テスト、状態、イベント、有効な遷移、無効な遷移、状態遷移図、状態遷移表、マトリクス、UML、N/A、カバレッジ、見える化、テストケース 5: ペアワイズテスト ペアワイズテストの基礎を学び、その後は実際に仕様を読みながらテスト技法を適用していきます。また、ペアワイズテスト表の作り方やテストツール（ペアワイズ作成ツール）を使用方法についても解説します。 キーワード ： ペアワイズテスト、テスト削減、コスト、リスク、トレードオフ、ペアワイズカバレッジ、パラメータ、値、全網羅テスト、ランダムテスト、Pict、カバレッジ、ペアワイズテスト表 1.　講座で学べること ソフトウェアテスト技法には、ホワイトボックステストとブラックボックステストがあります。 ブラックボックステストは、入力と出力に着目し内部構造を意識しないことで、テスト条件を効率的に抽出します。システムの要求や仕様に基づき、システムが期待通りに動作するかどうかを確認します。 ブラックボックステストは、仕様に基づくテスト技法に分類されています。 ホワイトボックステストは、内部構造に焦点を当てており、コードカバレッジなどを意識して行われます。内部構造の品質を確認するのに非常に役立ちます。 ホワイトボックステストは、構造に基づくテスト技法に分類されています。 ホワイトボックステストの最も代表的なものは、制御フローテストです。基本情報技術者試験でも取り扱っています。 ホワイトボックステストの制御フローテストは、基本情報技術者試験でも取り扱っていることもあり、学生の頃から学ぶことが多いです。 一方のブラックボックステストは、なかなか馴染みがなく、私もソフトウェアテストに関心を持つようになってから知ることになりました。 また、ホワイトボックステストは内部構造の理解がなければ、テストの有効性を理解できませんが、ブラックボックステストはどのように利用するかというユーザーの理解があれば、テストの有効性を理解することができます。 ブラックボックステストは、これまでお話したようにあまり知られていません。 そのため、本講座では、 ソフトウェアテスト技法のブラックボックステスト に焦点を当てています。 ここからは、本講座で取り扱う内容について紹介します。 同値分割法、境界値分析 【説明_同値分割法】 同等に処理されると想定したデータの集合を振り分ける技法 【ポイント】 データの集合をどのように振り分けるかはテスト技術者の経験にも左右されるため、同値クラスの分け方や代表値の取り方を詳しく解説 【同値分割法の解説例】 【説明_境界値分析】 同値クラスが数値または順序付けできる値で構成される場合に使用できる 同値分割法を拡張した技法 【ポイント】 2値、3値境界値分析の強度の違いや仕様のどこに境界があるかを適切に理解できるよう詳しく解説 【境界値分析の解説例】 デシジョンテーブルテスト 【説明】 仕様の複雑な条件（入力）の組み合わせによって、発生するアクション（出力）を整理できる技法 【ポイント】 複雑な条件の組み合わせで必要なテスト数（ルール）の算出方法や、抜け漏れなく条件を組み合わせる方法を詳しく解説 【デシジョンテーブルテストの解説例】 状態遷移テスト 【説明】 入力が同じでも、状態ごとに変化する動作を抜け漏れなく視覚的に整理できる技法 【ポイント】 仕様から状態遷移図、状態遷移表の作り方やテストケースの作り方を詳しく解説 【状態遷移テストの解説例】 ペアワイズテスト 【説明】 テスト条件が多く全網羅テストを行うことが困難である場合において、一定の規則性を持って根拠あるテスト削減するテスト技法 【ポイント】 ペアワイズがもたらすコスト削減とリスク増加の考え方から、ペアワイズ表の作り方、ペアワイズテスト作成ツールの使い方までを詳しく解説 【ペアワイズテストの解説例】 ソフトウェアテストのこれから 1.ソフトウェアテスト業界の市場 ソフトウェアテスト業界の市場は、技術の進化やデジタル化の進展に伴い、急速に変化しています。今回は 情報通信機器の保有状況（世帯）とインターネットの利用状況（個人） という2点の変化を取り上げます。 情報通信機器の保有状況（世帯） 2020年における世帯の情報通信機器の保有状況は、「モバイル端末全体」（96.8％）の内数である「スマートフォン」は86.8％、「パソコン」は70.1％、「固定電話」は68.1％となっています。 情報通信白書令和3年版 情報通信機器の保有状況（世帯） 世帯におけるスマートフォンの保有割合（86.8％）とパソコンの保有割合（70.1%）と比較した場合、その差は16.7%であり、多くの世帯でパソコンよりもスマートフォンを保有するというデータが出ています。 2010年におけるスマートフォンの保有状況は9.7%となっており、2020年では大幅に増加（86.8%）していることがわかります。続いて、2010年におけるパソコンの保有状況は83.4%であり、2020年では70.1%と年々減少している傾向が見受けられます。 間近のデータでは、モバイル端末全体の保有状況「2020年：96.8%」、「2021年：97.3%」、「2022年：97.5%」とさらに増加しています。また、スマートフォンの保有状況は、「2020年：86.8%」、「2021年：88.6%」、「2022年：90.1%」とさらに増加しています。 報告書及び統計表一覧(世帯編)　令和4年報告書 https://www.soumu.go.jp/johotsusintokei/statistics/pdf/HR202200_001.pdf これらのデータから、情報通信機器はほとんどの世帯で保有されるようになっており、パソコンよりもスマートフォンを保有する世帯が多いということがわかりました。 次に、インターネット利用状況（個人）について取り上げます。 インターネットの利用状況（個人） 2020年のインターネット利用率（個人）は83.4％となっています。また、端末別のインターネット利用率は、「スマートフォン：68.3%」、「パソコン：50.4%」となっています。 インターネット利用率 端末の種類 情報通信白書令和3年版 インターネットの利用状況（個人）、インターネット利用端末の種類 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r03/html/nd242120.html インターネット利用率の推移では、年ごとの増加は見受けられないものの、約8割程度を維持していることがわかります。また、スマートフォンでのインターネット利用が主流（68.3％）となり、次点のパソコン（50.4％）と比較しても17.9％上回っている状況です。 これらの状況から、今後もモバイル端末を中心としたソフトウェアの需要が増えると考えられます。それに伴い、ソフトウェアテスト市場もさらに拡大することが予測されます。 また、ここ数年は、新型コロナウイルス感染症の感染拡大に伴う感染症対策の一環として、ビジネスの変化が起こりました。 世界のEC市場の売上高は、2021年 542.0兆円（前年比19.5%増）と大きく増加しています。インターネットやモバイル端末が普及し続ける理由の一部とも言えるでしょう。 このような進化と変化に適応するために、ソフトウェアテスト業界でも、今後さらなる技術の進化が不可欠と言えます。 AGEST Academyでは、ICT活性化の一環として、eラーニングやUdemyの学習コンテンツ、メタバースオフィス（バーチャルオフィス）を利用した全国研修を行っています。 ゼロから始めるAIテスティング/今からでも遅くない AIテスティングの全てを学ぼう！ 30年以上の経験を持つ世界的なソフトウェアテストのエキスパートであるスチュアート・リード博士が、実際の演習をもとに解説します 　詳細はこちら　 Udemy 関連情報 ゼロから始めるソフトウェアテスト技法～基本から実践へ　現場で使えるテスト技法を学ぼう！～ なんとなくテストしていたり、テストに漠然とした不安を感じていませんか？少ないコストでより多くのバグを見つけるために、「正しく理解」すれば「強力な武器」になるソフトウェアテスト技法をソフトウェアテスト専門会社のプロが教えます。 　詳細はこちら　 Udemy 関連情報 2.ソフトウェアテスト技術とAI 本章では、ソフトウェアテスト技術とAIについて取り上げます。 AIの急速な普及に伴い、ソフトウェアテスト業界だけのことではありませんが、技術者の将来が懸念される声が挙がっています。例えば、生成AIでは「開発コードを作る」「テストを作る」「音楽を作る」「画像を作る」「翻訳できる」など、様々な用途があります。 筆者は、ChatGPTを検索エンジンと同じような意図で使う場合があります。対話ベースで知りたいことを深堀していけるという点で、調べごとが抽象的な場合に有効です。 非常に多くの用途で使用されるAIですが、今後どのようになっていくのでしょうか。 技術者が不要になる時代が来てしまうのかどうかという点を踏まえながらお伝えしていければと思います。 AIの動向 世界のAI市場規模（売上高）は、2022年には18兆7,148億円（前年比78.4％増）まで成長すると見込まれており、その後も2030年まで緩やかな加速度的成長が予測されています。 日本のAIシステム市場規模（支出額）は、2022年に3,883億6,700万円（前年比35.5％増）となっており、今後も成長を続け、2027年には1兆1,034億7,700万円まで拡大すると予測されています。 情報通信白書令和5年版 AIの動向 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd249100.html これだけ勢いのあるAI市場ですので、ソフトウェアテストやソフトウェア開発に将来性があるかどうかを不安視する声も挙がっています。 次から生成AIを利用するにあたっての課題（生成AIを巡る議論）について取り上げます。 生成AIを巡る議論 要機密情報の取扱いや、個人情報保護、回答の正確性などの課題が指摘されています。 また、作成した偽画像・偽動画が、意図せず又は意図的に拡散し、他者の利益・権利の侵害や社会的混乱を引き起こしてしまうような負の側面も顕在化しつつあります。 例えば、次のようなものがあります。 2022年9月、日本でもプロンプト型画像生成AI「Stable Diffusion」を利用した静岡県の台風洪水デマ画像がSNS上に投稿され拡散し、社会的な問題となった 2023年1月、米・サンフランシスコで複数のアーティストが画像生成AI開発各社（Stability AI Ltd、Midjourney Inc及びDeviantArt Inc）を著作権侵害で訴えた 2022年8月、日本でもラディウス・ファイブ社が、元となるイラストを学習させることで、その特徴をとらえた画像を自動生成できるAI「mimic」をリリースした後、悪用を懸念する声が多く寄せられたことから1日で配信を停止したという事例がある AIサービスを提供した事業者側では利用にあたっての規約は定めているものの、その内容が利用者に着実に届くための努力や、これを踏まえた利用者自身の活用モラルの向上が必要な状況となっています。 生成AIの取扱い等については、各国や国際会議の場で検討・議論が始まっています。 日付 内容 2023年3月 2023年3月、イタリアのデータ保護当局は、データ主体に対して十分な情報提供がなされていないこと、機械学習のために個人データを大量に収集し処理することを正当化する法的根拠に疑義があること、ユーザーの年齢認証のメカニズムが欠如していることを踏まえ、ChatGPTを一時的に使用禁止とした 2023年4月 英国の情報コミッショナー事務局は、法的根拠を明確にする必要があること、データ管理者としての義務を持つこと、リスク評価をすることなど、個人データを処理する生成AIを開発したり、利用したりする際の8つの留意点を公表した 2023年4月 米国の国家電気通信情報管理庁（NTIA:National Telecommunications and Information Administration）が、AIの監査や評価、認証制度ついての意見募集を開始した 2023年5月 バイデン政権は、責任ある人工知能（AI）の研究開発への投資、民間企業が開発した生成AIの評価、連邦政府によるAI利用に関する指針の策定からなるAIに関する責任あるイノベーションの推進策を新たに発表し、企業がAI製品を展開・公開する前にその安全性を確認する責任がある旨を明確にした 2023年4月 EUでは、ChatGPTに関するプライバシー保護への懸念を検証するための作業部会を設定することを決定した 2023年4月 同年4月に群馬県高崎市で開催されたG7デジタル・技術大臣会合において「責任あるAIとAIガバナンスの推進」についても議論が行われ、本会合で採択された「G7デジタル・技術閣僚宣言」ではAIガバナンスのグローバルな相互運用性を促進等するためのアクションプラン、生成AIについて早急に議論の場を持つこと等が合意された 2023年5月 広島市で開催されたG7首脳会合でも、首脳レベルでAIガバナンスに関する国際的な議論とAIガバナンスの相互運用性の重要性等の認識が共有され、生成AIについて議論する広島AIプロセスを年内に創設すること等が合意された 情報通信白書令和5年版 生成AIを巡る議論 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd131320.html これほどの議論が必要な理由が生成AIにはあります。 次のものは、利用者活用モラルに関連するものです。 学校（例：宿題や論文、テスト）でのChatGPT不正利用が懸念され、利用を禁止 ChatGPT生成の“存在しない判例”を使った米弁護士、約72万円の支払いを命じられる これらは、生成AIを提供した事業者側の意図を無視した利用といえます。 AIを利用することで技術の進化はあれど、技術の退化を招くべきではありません。 先ほど取り上げた”ソフトウェアテスト技術やソフトウェア開発に将来性があるかどうか”も同様の考えです。 AIの浸透は、技術を学ばなくてよい日が来るかもしれないというものでなく、AIを利用して技術を進化させていこう（生活を豊かにしていこう）という取り組みであるべきなのです。 インターネット、スマートフォンの普及に関しても、機械により生活が豊かになって労力が削られた部分はありますが、更なる発展のために技術を磨いたものでした。 近い未来でAIが完全に自律して何かを行うことが出来るようになったとしても、人は楽ができるというものでなく、その延長線上ないしは他の領域に時間を割けると考えるべきでしょう。今後も技術者は技術を学び、発展させていく必要があります。 AGESTAcademyでは、技術の発展や学びの一助となれば思い、Udemyコンテンツを公開しています。本章で取り上げたAIについてわかるコンテンツや、ソフトウェアテストの効果を上げるための考え方として、ソフトウェアテスト技法のブラックボックステストというもの解説しています。 一部動画の無料プレビューも可能ですので、アクセスいただければ幸いです。 ゼロから始めるAIテスティング/今からでも遅くない AIテスティングの全てを学ぼう！ 30年以上の経験を持つ世界的なソフトウェアテストのエキスパートであるスチュアート・リード博士が、実際の演習をもとに解説します 　詳細はこちら　 Udemy 関連情報 ゼロから始めるソフトウェアテスト技法～基本から実践へ　現場で使えるテスト技法を学ぼう！～ なんとなくテストしていたり、テストに漠然とした不安を感じていませんか？少ないコストでより多くのバグを見つけるために、「正しく理解」すれば「強力な武器」になるソフトウェアテスト技法をソフトウェアテスト専門会社のプロが教えます。 　詳細はこちら　 Udemy 関連情報 Udemyクーポン配布 「ゼロから始めるソフトウェアテスト技法～基本から実践へ　現場で使えるテスト技法を学ぼう！～」のUdemyコンテンツ公開に伴い、購入時に使用できるクーポンを配布します。 こちらは、定価19,800円の講座が1,980円になるクーポンです。 購入をお考えの方は、ぜひご利用ください。 なお、クーポンには有効期限がございます。 Udemy クーポン情報（19,800→1,980円） 割引クーポンの発行： 　　 https://www.udemy.com/course/agest-testing/?couponCode=F9EAB46C943A3071307C クーポンコード: F9EAB46C943A3071307C 有効期限: 2024/07/24～2024/08/23 The post 「ゼロから始めるソフトウェアテスト技法」を解説 first appeared on Sqripts .

この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活とはどうあるべきか」等の話ではなく、できるだけエンジニアの普段の生活や仕事に役立てられるテクニックよりの話をするつもりです。 前回 の記事では、技術書以外の本も積極的に読み、そこから得られた情報を知的生活の母艦に蓄積して活用すること等について解説しました。 【第3回】技術書以外の本を読み、仕事に活かすには この連載では、ITエンジニアにとって親和性が高く「スキルアップしたい」と思う方にとっては役に立つであろう知的生活について、いろいろなアクティビティやツール、仕事での活用方法などについてご紹介します。知的生産・知的生活の考え方や、「そもそも知的生活と... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、仕事の中で得られる情報や作業の記録についてご説明します。 ＜ITエンジニアの仕事を楽しくする知的生活　記事一覧＞ ※クリックで開きます 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する 仕事においても知的生活はできる 本連載のこれまでの記事は、どちらかといえばプライベートな時間における、読書やアイデアの蓄積などが中心でした。 しかし、知的生活はプライベートな時間だけのものではありません。平日日中の仕事をしている時間にも、知的生活は可能です。 むしろ 第一回 でご説明した知的生産、 アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする これを生活の中に組み込むのが知的生活であるという考えに基づけば、生活の多くの割合を占める仕事中も知的生活の範囲に含まれるのは自然なことです。 【第1回】知的生活とはなにか？エンジニアにどう関係するのか みなさんは、知的生産や知的生活ということばを聞いたことはありますか？初めて聞いた、という方はもしかしたら「堅そう」とか「えらそう」といった印象を持つかもしれません。ところが、私はこの知的生産・知的生活は「ITエンジニア皆に知っておいてほしい」と考え... 　続きを読む　 Sqripts 関連記事｜Sqripts 仕事中に集める情報 とくにITエンジニアの皆さんは、プライベートな時間よりも仕事中のほうがたくさんの情報をインプットし、そして頭の中で処理をしているのではないでしょうか。 大量に流れてくる情報は何もしなければ失われてしまいますが、意識的に収集・整理することで自分の資産として活用できます。 私も昔 自分用の「仕事の教科書」をつくりながらはたらこう – テストウフ というブログ記事を書きましたが、ナレッジを残してあとから使えるようにする、というのはさまざまなことに共通する基本の考え方です。 こうした、情報の残し方に関してもいくつかのテクニックがあります。 たとえば、Today I Learned、略してTILと呼ばれる方法です。 Today I Learnedとは、その名の通り「今日学んだこと」を記録していくものです。 媒体は自由ですが、たとえばGitHubに「TIL」というリポジトリを作り、その中に「Python」や「Docker」「Git」など技術要素ごとのフォルダーを作ります。 そして、フォルダーの中に学んだことをMarkdown形式でメモしていく、という手法です。 単純に調べ物をして終わりではなく自分用にアウトプットすることで、記憶を定着されたり、また次以降「TILに書いていた」ということさえ覚えておけば検索をかけて素早く情報を引き出すこともできます。 TILは基本的に「自分用」で、かつ複雑な管理ルールもないため、気軽に始めるにはよいでしょう。 ただ、今回はこのTILのようなナレッジの蓄積とは少し異なる、日々を記録してふりかえりを行う「デイリーページによる作業ログ」についてもご紹介したいと思います。 デイリーページによる作業ログ TILなどにナレッジを残す場合には「残すべきものがあれば残す」という考え方になるでしょう。 一方ここでオススメしたいのは、「何を残すか」を考えるのではなく、とにかく記録を書きつけるという方法です。 大まかな流れは以下です。 朝仕事を始める際に、エディター等でその日の日付をタイトルにしたページ＝デイリーページを作成する デイリーページに、今日やることをリストアップする 仕事をしながら、デイリーページの中に行ったことや考えたこと、わからないことなどを時系列で書いていく 基本的にはこれだけ、です。もし職場のタスク管理ツールなどで「今日やること」を管理している場合は、デイリーページに転記してもいいですし、デイリーページには書かずにツール側で管理してもいいでしょう。とくに大事なのは「やったことや考えたことを時系列で記録する」という部分です。 なお、このやり方は知的生産に関連する「ユビキタス・キャプチャー」というもののエッセンスを取り入れたものです。 参考： 「全てを手帳に記録する」、ユビキタス・キャプチャーの実践 | Lifehacking.jp デイリーページのサンプル このあとデイリーページのメリットや作業ログの書き方を説明しますが、先にどのようなものかサンプルをお見せします。 普段使っているエディター（ここではvscode）で、日付を名前にもつファイルを作成します。私はMarkdownが好きなのですが、.txtや他の形式でも、慣れたものがあればそれでかまいません。 また、過去に所属していたチームの朝会で直近あった良いことを紹介しあうGood＆Newというコーナーがあったので、そのメモや今日やるタスクを列挙しています。このあたりのフォーマットや項目も、デイリーページを運用しながら少しずつカスタマイズしていくのが良いでしょう。 メインとなるのは、下部の「作業ログ」の項目です。 ここに、時刻とともにタスクのおおまかな見出し（例では「自動テストエラー対応」）を書き、そのしたにタスクを行う過程で考えたことや調べたこと、メモなどを並べていきます。 とくにエラー対応やトラブルシュートなどを行っている際には、独り言をつぶやくように書いていくと、頭の中を整理しながら思考することができるため便利です。 他にも、仕事中になにかを調べた場合はそこでヒントになったWebページのURLを記載したり、誰かからSlackやTeamsで質問された場合の内容や回答なども記録しておきます。 このように、仕事中の脳内をできるだけ余さず書きつけておくようなイメージで作業ログを書いていけるとベストです。 作業ログを書くメリット 上記の説明の中で、頭の中を整理できる、というメリットを挙げました。他にもいくつか考えられます。 たとえば、将来似たようなタスクや同じような問題に取り組む際のヒントになること、です。皆さんは仕事中に「あー、前似たような問題あって対処したなぁ・・・どうやったんだっけ・・・」と困ったことはないですか？私も数え切れないほどあります。 だいたいこのような場合は当時の記録が残っていなかったりして、記憶を頼りにGoogleや社内のファイルを検索して時間を溶かしていくことになります。 しかし、デイリーページに記録したということを覚えていれば、デイリーページの入ったフォルダーを検索すれば良いので目当ての情報にたどり着く手間が少なく済みます。 また、作業ログの形式で書くことによって、ナレッジの整理と実タスクの進行とを分離することができます。 仕事中の知見を社内のWikiやナレッジベースにまとめている方も多いでしょう。しかし、目の前のタスクを進めながらナレッジベースに情報を整理する、というのはなかなか大変です。私も経験があるのですが、なにかのタスクをしながら整理したナレッジというのは情報の順番が前後したり整理されていなかったりして、読みづらい状態になりがちです。 一方「あとでナレッジをまとめよう」と思って仕事に集中していると「あとで」が永遠に来なかったり、運良く時間が作れたとしても書くべき内容を忘れてしまっていたりと、こちらも効果的ではありません。 そこで作業ログの出番です。タスクをやっている最中は、構成や見栄えなどは考慮せずとにかく「記録・メモ」をする。そして、あとから記録・メモをもとにナレッジベースに整理する。 こうした二段構えで行うことで、業務効率と情報の内容を両立させることが可能です。 他にも細かなメリットとしては、日報や週報、ふりかえりの材料としても使える点などがあります。 作業ログを書く際のコツ これらのメリットを享受するためには、まずはとにかく作業ログを書くことが大事です。書き方やフォーマットなどは人によって好みがありますし、基本的にはどのような内容をどのように書くかは自由です。 しかし、自由な中でも一つだけ心がけるべき点があります。それは、 メモ・記録の手間をできるだけ少なくする ことです。 ここで言う手間とは、操作手順などのことだけではありません。頭で考えたり意思決定することも、手間に含まれます。たとえば、メモのルールや書く場所が複雑になって「ええと、この内容はどこに書こうかな・・・」とつど考える必要があるようではメモやログは続きません。 デイリーページに時系列で作業ログをとる一番のメリットは、この思考の手間を減らせることです。 今日日付のファイルの末尾に作業中のメモを追加していく、というシンプルなルールなので迷わずに済みます。 また、作業ログをとることを始めると必ずぶつかる壁が「何も書かない/書けない日がある」こと、です。会議が多い日であったり、作業に集中してログをとるのを忘れてしまった、などは起こり得ます。 この問題に対しては、 気にしない のが一番です。作業ログは毎日書くのが理想ですが、逆に毎日書かなければ意味がないもの、でもありません。 本記事冒頭の繰り返しになりますが、大切なのは アウトプットである「なにかあたらしい情報や価値」を出すために、いろいろなインプット＝情報をあつめて、自分の頭やいろいろな道具を使って処理＝思考をする という知的生産を、日常の中に組み込んでいくことです。 最初のうちは頻度が少なくても仕方がないですし、もし難しければ「エラー対応だけは作業ログをとる」や「朝9時から10時の集中タイムはログをとる」など、対象や時間を絞って始めるのも良いかもしれません。 少しずつでもよいので、インプット＝情報を集める習慣付けをしていくと、後々のアプトプットにつながっていきます。 まとめ 今回は主に仕事中の作業の記録についてご紹介しました。 学んだことや知見をトピックごとにまとめるのも良いですが、個人的にはデイリーページに作業中の考えや行ったことなどをメモすること＝作業ログをつけることがオススメです。情報を整理しながら蓄積するのは大変なので、作業ログとして蓄積することと、あとから作業ログを整理して情報として残すこととに分けて行うのが良いでしょう。 次回は蓄積した記録をもとにどのようにアウトプットし、仕事に活かしていくのかについて解説します。 ITエンジニアの仕事を楽しくする知的生活　連載一覧 【第1回】知的生活とはなにか？エンジニアにどう関係するのか ［全文公開中！］ 【第2回】知的生活の母艦としてのツールを選び、活用する 【第3回】技術書以外の本を読み、仕事に活かすには 【第4回】デイリーページを用いて日々の作業を記録する The post 【第4回】デイリーページを用いて日々の作業を記録する first appeared on Sqripts .

こんにちは、ツヨシーサーです。   「何から考えればよいか分からない。」 「考えが頭の中でぐるぐる回ってまとまらない。」 「表面的にしか考えられない。」 皆さんに思い当たる節はありませんか？お恥ずかしながら、最近もこんなことがありました。例えば、スマホ・アプリの新サービスを企画する際にアイデアを考えることが出来なかったり、課題の解決策を検討したものの網羅的に考えることが出来なかったりしたことがありました。そんな悩みを解決できるかもしれない書籍に出会いましたので、その本からエッセンスを抽出して皆さんにお伝えいたします。思考のメカニズムを深く理解することで、より効果的な判断や意思決定に役立てて頂ければ幸いです。 ［参考文献］ 『思考・論理・分析「正しく考え、正しく分かること」の理論と実践』 波頭 亮 著 思考のメカニズム 「思考」とは、『思考対象に関して何らかの意味合いを得るために、頭の中で”情報”（外から得られた情報）と”知識”（頭の中にすでに保有している情報）を加工すること』と定義されています。例えば、目の前に飛んできた小さな物体を観察した結果、身体の色は褐色で、大きな角があり、5cmほどの小さな生き物であるという”情報”から、自分の頭の中にある”知識”と照らし合わせてカブトムシであると判断することが「思考」ということになります。 その思考の核心は、『”情報”と”知識”を突き合わせて比べることであり、比べることにより、”同じ”部分と”違う”部分を認識し、その認識を基に判断や理解を得るプロセスが思考の本質』と整理されています。例えば、身体の色が褐色の昆虫がカブトムシであるかクワガタムシであるかを判断する際、角の有無といった情報を比べることで違いを見極めます。このように、『思考とは”情報”や”知識”を突き合わせて”同じ”か”違う”かを認識し、その認識を集積して理解や判断を得る行為』ということなのです。 思考ができない時は、理解や判断するために必要な”情報”や”知識”は足りているのか、”情報”と”知識”を突き合わせて比べて”同じ”と”違う”を認識できているのかということを疑ってみろということですよね。 思考のメカニズム（出典文書 ※1 （ P21）より筆者作成） 分かることは分けること 「思考」とは”同じ”と”違う”の認識作業になります。この認識の集積が思考のアウトプットとして、思考対象に関する理解や判断になるのです。この思考の仕組みとメカニズムは、『分かることとは分けること』とも表現されており、逆に言うと「分かっていないということは分けれていないこと」だと気付かされました。 例えば、身体の色は褐色で、大きな角があり、5cmほどの小さな生き物が目の前に現れた場合、その特徴を自分の持っているカブトムシの知識と照合します。これらの要素が一致した場合に、それはカブトムシであることが分かります。このように、『思考対象の”情報”と持っている”知識”を比べ、要素ごとに同じと違うに分けているのが思考作業』になります。そして、この思考作業を経て思考対象を構成する要素が”同じ”と”違う”に正しく分け尽くされた状態にたどり着くことが「分かる」ということなのですね。 分けるための3要件 それでは、思考対象の情報要素を正しく分け尽くすためには、どうすればよいのでしょうか？この本では以下の三つの要件を満たすことが必要であると書かれています。 ディメンジョンの統一 クライテリアの設定 MECEであること これらの3つの要件を満たして初めて、正しく分けることができ、正しく理解することが可能になるということですので、詳しく知りたいところですよね。 実体験として「ディメンジョンの統一」で困ったことはないのですが、「クライテリアの設定」では、スマホ・アプリの要件検討をしていた際に、機能面の切り口のみにフォーカスを当ててしまったため、体系的な検討が不足していたことがありました。また、「MECE」では、スマホ・アプリを利用するユーザの動線を検討していた際に、ユースケースの主要ケース以外の考慮漏れがあったため、設計の見直しを行ったという失敗談もありました。 ディメンジョンの統一 『ディメンジョンの統一とは、思考対象や要素を比較する際に、その抽象水準や次元を揃えること』を指します。これにより、適切かつ意味のある比較が可能になるということですね。 ディメンジョンが異なるもの同士を比べても適切な比較ではなく、正しく分けられたことにはならないので、注意しましょうね。 ディメンジョンの統一（出典文書 ※1 （P30）より筆者作成） クライテリアの設定 次に、『クライテリアとは、思考対象を分類する基準のこと』です。思考対象をどういう切り口で分けるのかを設定することは、その思考対象をどのように体系立てて分かるのかを決定付けることになるため、適切なクライテリアさえ設定できれば、思考対象を正しく理解し、判断することが可能になるということなのです。 前述のスマホ・アプリ要件検討の失敗時には、「クライテリアの設定」を活用して、機能面だけでなく、ユーザ目線での切り口も考慮して再検討を行ったところ、クライアントを説得することができました。 クライテリアの設定がしっくりこないときは、思考目的に合致したクライテリアになっているのかを確認してみてくださいね。 クライテリアの設定（出典文書 ※1 （P33）より筆者作成） MECEであること 最後に、『MECE（Mutually Exclusive Collectively Exhaustive）とは、モレがなくかつダブリがないこと』を指し、論理的な思考や分析において極めて有用なテクニックになります。MECEを用いることで、漏れや重複がない分類が可能になり、正確な分析や考察ができるというわけです。 前述のスマホ・アプリにおけるユーザ動線検討の失敗時には、「MECE」を活用し、ユースケースの90%を占める主要ケースだけでなく、レアケースの残りの10%も考慮しました。その結果、ユーザ動線の抜け・漏れがなくなり、設計レビューでレビューアからOKを頂くことにつなげることができました。 ただし、定性的な対象を分類する場合には数学的論理学的というより、MECE的な分類であれば十分みたいですよ。（MECEに分類するのが難しいケースって実際ありますよね…） MECE（出典文書 ※1 （P36）より筆者作成） さいごに 思考とは、情報と知識を突き合わせて比べ、”同じ”か”違う”かを識別するプロセスです。このプロセスを理解することで、より効果的な判断や理解が可能になります。また、「ディメンジョンの統一」や「クライテリアの設定」、「MECE」の活用により、思考の精度を高めることができます。ぜひ、日常生活やビジネスシーンでこれらの思考のテクニックを活用してみてください。 特に「クライテリアの設定」は私も普段から意識しているのですが、切り口のバリエーションをもっておかないと適切にクライテリアを設定できません。そのため、クライテリアの設定が上手な人、つまり、構造化思考で物事を考えるのが上手な人が皆さまの周りにもきっといらっしゃると思いますので、その人からノウハウを吸収するように心がけるのがお勧めです。 いかがでしたでしょうか？ すこしでも皆さまの気づきになれたのであれば幸いです。それではまた。 ※1　波頭 亮 (著),『思考・論理・分析「正しく考え、正しく分かること」の理論と実践』,産業能率大学出版，ISBN:978-4-382-05541-4 なお、本文中の『』は出展文書からの引用 The post 考えることを考える first appeared on Sqripts .

こんにちは。最近、開発者⇒テストエンジニアとなりました、だいだいです。 早速になりますが、皆さんは「2038年問題」ってご存じでしょうか？　え、「2000年問題」じゃないの？　と思われる方もいらっしゃると思いますが、違います。「20”38”年問題」です。 今回は、昔大きく話題になった「2000年問題」よりも深刻になり得そうな「2038年問題」について、他の似たような事象を踏まえつつ説明していきたいと思います。 「2000年問題」について覚えていますか？ かつて20世紀末の世間を大きく騒がせた「2000年問題」。30代以降の皆さんであれば覚えていらっしゃる方も多いのではないでしょうか。 軽く「2000年問題」について説明すると、当時のシステムでは年を西暦の下２桁で管理していたため、2000年を1900年として扱ってしまう……というものでした。 どれほど大騒ぎになったかというと、 2000年になった瞬間、あらゆるシステムが誤作動するのでは。航空機が墜落するのではという憶測が飛び交う。 世紀末ということもあり、ノストラダムスの大予言（1999年、7の月 空から恐怖の大王が降ってくる）と関連付けて、ミサイル誤発射から世界大戦勃発……という飛躍した噂が流れる。 結局は各企業が総出で対応を行い、2000年を迎えても大きな障害トラブルは発生せず平和に年明けを迎えることができたそうです。ただ念のため、正月は当番制で会社に出勤していたというお話も聞きました。（知り合い談） 今回のテーマである「2038年問題」という名前から、この「2000年問題」と似ていると思われるかもしれませんが、実は全然違う原因による問題だったりします。そこを含めて、出来るだけ丁寧に説明していきます。 前提知識 「2038年問題」は大雑把にいうとOSやシステムに深く関わる問題となります。そのため、出てくる専門用語を予め説明します。 UNIX時間 名の通りUNIX、Linux系OSのシステムで使われる時間データのこと。多くのシステム・プログラミング言語で採用されている。基準値「1970年1月1日0時0分0秒」からの経過秒数を保持しており、例えば「2024年1月1日0時0分0秒」なら基準時間から1704034800秒が経過したということ。 上記の基準時間はUTC（ロンドン基準）となっており、日本の場合はUTCから時差の9時間が進んだJSTを扱う。 int型 正式名称は「32bit符号付き整数型」で、名の通り32bit分の整数値を保持する箱のこと。マイナス値も格納できるため、値の範囲は「－2147483648〜2147483647」。 レガシーシステム IT用語で「過去の技術や仕組みで構築されているシステム」のこと。古いシステムのため利用された技術・仕組みについてブラックボックス（実態が不明）化しているシステムも多い。 ランタイムライブラリ プログラムの実行に必要な前提のプログラム、共通して利用できるプログラムを１つにまとめたモノのこと。共通して利用できるプログラムとしては数値計算などが挙げられる。身近なものならExcelの関数（SUM関数、MAX関数など）もランタイムライブラリに当てはまる。 「2038年問題」ってなに？ UNIX時間をint型で保持している場合、その限界値が「2038年1月19日12時14分7秒」となる問題のことです。 「2038年1月19日12時14分7秒」から1秒でも経過すると、int型の限界値を超えてオーバーフロー（桁あふれ）を起こします。そうなるとint型の値が上限値「2147483647」⇒下限値「-2147483648」となります。 結果、「1970年1月1日0時0分0秒」から2147483648秒前の日時……つまり「1901年12月14日5時45分52秒（JST計算）」と扱われてしまうんですね。 ある日突然、システムの日時が「2038年1月19日」⇒「1901年12月14日」になってしまう。それがこの「2038年問題」なんです。 「2038年問題」は「2000年問題」より深刻になり得る 「2000年問題」はアプリケーションレベルでの修正が可能だったため、各会社の対応により無事に乗り切ることができました。しかし「2038年問題」は上記で説明した通り「UNIX時間」……つまり、アプリケーションではなくOS・プログラミング言語といった、システムの深い層に潜む問題となります。 システムの深い層の問題ということは開発会社であれば解決可能という訳にもなり辛く、対応するにしても重大なリスクが付き纏います。 こういった理由から、私は「2038年問題」をより深刻に捉えたほうが良いのではと考えました。 「2038年問題」の対策（開発者目線） オフィスコンピュータを始めとするレガシーシステムの多くが、この問題の対象となる可能性を秘めています。その対象と理由、対策方法について下記にまとめてみました。ただし、あくまで私個人の意見のため、参考程度にご覧いただけると幸いです。 対象システム 対策 理由 32bit版のUnix・Linux系OSを使用しているシステム OSを64bit版にするか、日時管理を64bitで保持するバージョンにアップデートする OSによっては日付型を32bitで保持しているため 日時計算を独自処理で行っているシステム 開発者がアプリケーションレベルの修正を行う 「2038年問題」を考慮していない（int型に格納など）可能性があるため C／C++などの古いランタイムライブラリを用いているシステム 「time_t」を使わないこと 古いランタイムライブラリは日付型を32bit符号付き整数型で保持しているため （C／C++の場合は特に「time_t」を利用しているアプリケーションが対象） 補足 なぜ32bit版のUnix・Linux系OSに限定しているかというと、32bit版のWindowsは「2038年問題」は発生しないためです。実はWindowsXPの時点で32bit版でも日付型を必ず64bitで保持するようになっているんですね。 日時計算を独自処理で行うシステムについてはアプリケーションレベルの修正となりますが、日時計算を独自で行うシステムの大半はレガシーシステムだと思われます。つまり処理自体がブラックボックス化している可能性があり、修正に対して相応のリスクはあります。 C／C++などの古いランタイムライブラリに関しても、上記のリスクに加えてそもそも有識者が少ない問題もあるため、修正に対するリスクは高いように思えますね。 「2038年問題」の対策（テストエンジニア目線） では品質管理を担保することが目的のテストエンジニアの場合、どのようなことを考慮すれば良いでしょうか。 １．設計ドキュメントレビューの観点として盛り込む これは早期に問題を発見できる、最適なアクションでしょう。例としてレビュー時に目を通すべき場所、問題発見時の対応について幾つか上げたいと思います。 実施環境OSの確認 記載されている実施環境のOSが引っかかっている場合は、まず起こり得る「2038年問題」に対する対策を行っているのか確認する必要があります。 対策を行っている場合は、対策の確実性を担保するため日付を取り扱う処理に対してのテスト優先度を高くできます。 対策を行っていない場合は、開発側が「2038年問題」を把握していないことを考慮し、問題の説明を行いつつ対応してもらえるよう促せます。 開発言語の確認 開発言語が古いランタイムライブラリを利用していることもあり得るため、確認はしたほうが良いでしょう。特に組込み機器はC／C++を多く利用しているため注意が必要です。 発見した場合はOSと同様、どういった対応を行っているのか確認する必要があります。ただ組込み機器の場合は、そもそも2038年までの使用を想定していないこともあり得ます。 ２．探索的テストを利用する テスト実施を行う際に日付を「2039年」などにして、2038年以降の日時が処理できるか探索的テストをしても良いでしょう。特に業務システムは長期間使用を想定していることが多いため、ひとつの長期運用の品質担保になるのではないでしょうか （実際に20年以上使われているシステムがある　※実体験） 同様の問題について紹介 今回は「2038年問題」について詳しく紹介しましたが、実は他にも同様の問題がまだまだ潜んでいます。 2004年に起きた「2038年問題」 某通信事業会社にて「2038年問題」と同様の事象が2004年に発生しました。結果、日付（平日／休日など）による通話料金の計算処理に故障が発生し、大多数のユーザに対して割高／格安の通話料金を請求してしまいました。 2004年に「2038年問題」が起きた原因としては、システムの独自処理でUNIX時間の1秒＝0.5秒に変換していたためです。その影響で本来より半分の時間で事象が発生しました。 「2036年問題」について コンピュータ時刻を同期するためのプロトコルである「NTP（Network Time Protocol）」が「2038年問題」と同様の理由でオーバーフローしてしまう問題のことです。 NTPの基準時間は「1900年1月1日0時0分0秒」。NTPサーバでは32bit符号なし整数型で保持しているため、4294967295後の「2036年2月6日0時54分54秒」でオーバーフローしてしまいます。 まとめ 「2038年問題」を始めとする「20XX年問題」は数多く存在します。その対象はレガシーシステムだけでなく、開発／運用中のシステムも含まれるかもしれません。特に業務関係で使うシステムは、長期稼働されることが前提となりがちです。 昨今のテクノロジー進化はとんでもなく速いことは、恐らく皆さんお気づきだと思います。何せ1980年にはショルダーフォンが生まれ、1990年代には携帯電話（ガラケー）が普及し、2000年代後半ですでにスマホとなっています。 現代ではSF世界の話だと思っていた量子コンピュータの実現が現実的となり、2030年代にはビジネスに利用され始めるとの話もあります。丁度「2038年問題」に直撃してるころ、量子コンピュータはビジネスシーンで利用されているかもしれない、ということですね。 上記の通り、IT業界は技術の進歩が非常に激しい業界です。そのテストエンジニアとして、私たちは将来的に起こりうるリスクも視野に入れて品質課題を捉える必要性があります。この「2038年問題」をきっかけに、その気付きを少しでも得ていただけたら幸いです。 The post 今のうちに知っておこう。2038年問題 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 今回のテーマは「コーチング」。その中でも「質問」について深掘りしていきます。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- 前回のおさらい 前回 はコーチングの主要技術を解説しました。 コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーション... 　続きを読む　 Sqripts 関連記事｜Sqripts 傾聴 質問 承認 フィードバック 今回はこの中でも「質問」に注目して解説していく予定です。アジャイル開発の現場で友好的な質問とは、どういったものになるのでしょうか？ ここでは以下の観点で質問を分類しながら解説を進めます。 コーチングの質問例 視点を変える 時間を変える リソースの確認 オープン VS クローズド チャンクダウン VS チャンクアップ 視点を変える質問 まずは以下の会話をもとに、視点を変える質問を考えていきましょう。 「今回のこの問題は前にも発生したことがありますね」 「前回のふりかえりで対策をうったつもりでしたが、残念ながら再発してしまったみたいです」 「さすがに同じ問題を何回も起こしてしまうのはよくないので、今回は根本的な解決策を考えていきたいです」 「そうですね。前回はチェックリストを作ってミスを防ごうとしましたが、カバーできていない部分があったので、チェックリストを更新してみてはどうでしょうか？」 問題の再発防止策を考える会話のようです。同じ問題がまた起きてしまい、チームの雰囲気は最悪です。前回の改善策を今回さらに改善するようですが、ここに視点を変える質問を加えてみましょう。 「今回のこの問題は前にも発生したことがありますね」 「前回のふりかえりで対策をうったつもりでしたが、残念ながら再発してしまったみたいです」 「さすがに同じ問題を何回も起こしてしまうのはよくないので、今回は根本的な解決策を考えていきたいです」 「我々だけで考えるには限界があるかもしれない。たとえば、 もしこの問題をお客さまの視点で考えるとしたら、何を対策してほしいと思うだろう？ 」 「お客さまからみれば、今回のトラブルはケアレスミスでしかないので、こういった簡単な間違いを起こさない仕組みを期待するんじゃないでしょうか？簡単なミスばかりしていると信頼されなくなりますからね」 「信頼されるために何ができるんだろう？ そもそもこの問題が絶対起こり得ない状況を作れないだろうか？」 視点を変える質問は、チームの閉塞感をうちやぶる力を秘めています。もしお客様だったら？ 部長だったら？ 上司だったら？ 優れたチームだったら？ スーパーエンジニアだったら？ と考えることで、チームの思考の枠組みを壊して、新たな視点やアイデアを得ようとします。 時間を変える質問 次に、時間を変える質問を見てみましょう。先程の例に、時間を変える質問を加えてみます。 「今回のこの問題は前にも発生したことがありますね」 「前回のふりかえりで対策をうったつもりでしたが、残念ながら再発してしまったみたいです」 「さすがに同じ問題を何回も起こしてしまうのはよくないので、今回は根本的な解決策を考えていきたいです」 「 もし、タイムマシンで問題が起きた時間の前にもどれるなら、何をするだろうか？ 」 「もう一度やり直せるなら、ミスの起こりやすいところをダブルチェックします」 「ダブルチェックがだんだん手間やミスにつながりやすそうだから、並行して手順を自動化したらいいんじゃないだろうか？」 トラブル対策やポストモーテム（トラブルのふりかえり手法）の現場において、この「タイムマシン」を使う質問はかなり有効です。もう一度やりなおすことはできないのですが、その時点、その場に戻ることで「もっとできたこと」を考えられるようになります。トラブルなどは、過去に戻ることで対策をイメージしやすくなります。 逆に未来に進むこともできます。 「 もし、この対策がうまくいったら、将来われわれはどういうふうに働いているだろうか 」 「そりゃ、この問題がなくなると時間もできるし、心にも余裕ができるので、より顧客が喜ぶ機能開発に集中できますよ」 過去への質問と未来への質問の違い 過去への質問は、過去の失敗や問題と向き合う質問になります。これはこれで悪くはないですが、問題が「誰か」になってしまったり、掘り下げるのが苦痛でうまくコミュニケーションが取れなくなったりする可能性が高まります。誰だって、過去の失敗を思い出したくなどないからです。 一方で、未来への質問は、過去のネガティブではなく未来のポジティブに向き合えます。未来を照らし、理想の状態を考えることで、そうなりたいという希望が生まれるからです。未来が今の自分のモチベーションに繋がります。 筆者の場合、トラブルの原因究明以外は、未来を考える質問を繰り返すようにしています。原因究明は原因を特定しなければならないので、過去を掘り下げていくしかありません。 しかし、それ以外の課題であれば、未来を照らしてあるべき姿を探す方法が有効だと感じています。未来の話だけをするようになって数年立ちますが、今のところ大きな問題は起きていません。 リソースの確認となる質問 リソースとは資源を指します。チームや個人が持っている資源を有効活用するなら、リソースの確認となる質問が有効です。以下の例を見ると、この質問の効果がよく分かるはずです。 「今回発見したこの課題は、うちのチームで解決するのは難しそうだ」 「経験者がいないし、スキルセット的にもマッチしない課題ですからね」 「 でも、社内にこの技術を使っている部署はあるだろうから、その人達に相談してみてはどうだろう？ 」 「たしかに。◯◯のチームが前に社内勉強会で事例発表していたから、早速聞いてみようか」 新しい技術など、職能横断的なチームでも対応できない状況は多くあります。本来は自分たちですべて解決できればいいですが、それが難しいなら、専門家に相談しましょう。その道に詳しい専門家を知っているだけでも、プロダクトやチームに貢献できます。 リソースには、人、環境（例：社内にeラーニングがある）、お金（例： 予算を持っている）、経験などがあります。目的を達成するために、使えるものはどんどん使い、使えそうなものはどんどん使えそうかを確認していきましょう。 オープン・クローズドな質問 ここまではいろんな種類の質問を紹介しましたが、オープンクエスチョンやクローズドクエスチョンといった、特性の異なる質問方法もあります。オープンクエスチョンやクローズドクエスチョンの例を以下にまとめます。 オープンクエスチョン あなたはどう思いましたか？ 今の我々にはどういった選択肢があるのでしょうか？ 自由な発想をするなら、何が思い浮かびますか？ クローズドクエスチョン AとBどちらにしましょうか？ つまりこういうことでしょうか？ これはあなたのタスクですね？ 文字通り、オープンな質問は回答の幅が広いことがわかります。自由なアイデアを発想したいときはこちらがマッチします。相手の思考を刺激するコーチングでは、こちらの質問が多くなります。 一方で、クローズドクエスチョンは、選択肢が絞られてしまいます。しかし、議論を広げたいときには不向きですが、広げた議論を収束させたいときに使えます。また、要約してあげることで相手の思考が整理されるケースもあります。 チャンクダウン・チャンクアップ チャンクは塊を意味します。チャンクダウンは大きな塊を小さくくだいていくプロセスで、チャンクアップは小さなものを大きく組み立てていくプロセスになります。 たとえば、「自然を守るには？」というテーマで議論する場合、テーマが大きすぎて次の一歩が踏み出しにくくなります。よって、チャンクダウンして、もう少し議論の幅を狭めてもいいかもしれません。 自然を守るには？ ＞ 自然だと広すぎるからテーマを森林に絞ろう ＞ 森林の中でも大きな問題になっている山火事について話してはどうだろうか？ 逆に細かすぎるテーマだとチャンクアップになります。 うちらのチームで起きているパフォーマンスの問題について話したい ＞ そもそもパフォーマンス問題が起きているのが社内のクラウドインフラなので、我々だけの問題なのだろうか？ ＞ そういえば他チームでも似たような状況が増えてきたと聞いている ＞ それなら一度、クラウドインフラのチームに相談してみようか。 ＊ 今回は、コーチングの中でも質問について深掘りしました。さまざまな視点や形の質問ができることがわかると思います。こういった質問力を高め、引き出しにたくさんレパートリーを集めておくと、アジャイル開発の現場で柔軟にふるまえるようになります。 次回は質問技術の中でも、より上級者向けの「質問」について解説します。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- The post コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているタカです。 普段はスクラムマスターや開発者として様々な角度からプロダクトの開発に関わっています。 今回は、私たちのチームで導入したGitHub Projectsについての機能紹介や、プロダクト開発におけるバックログの管理などについて紹介したいと思います。 ※本記事の情報は、2024年7月時点の情報です。 GitHub Projectsを利用した経緯 私たちプロダクト開発チームは、これまでNotionを用いたプロダクトバックログの管理などを行ってきました。 その内容はSqriptsでも過去に紹介しており、こちらがその記事になります。 Notionでプロダクトバックログを管理するビューを作成する こんにちは、エンジニアのタカです。普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。チームではスクラム開発を導入しており、今回はNotionでのバックログ管理の話をしたいと思います。当初のバックログ管理方法自分が所属するチームでは、... 　続きを読む　 Sqripts 関連記事｜Sqripts GitHubプルリクエストをNotionで管理：効率的なブランチとプルリクエスト運用のガイド こんにちは、AGESTでエンジニアをしているタカです。普段はプロジェクトのマネジメントや開発者としてプロダクトの開発に関わっています。以前投稿したNotionでプロダクトバックログを管理するビューを作成するの記事の最後に触れたNotionのGitHubインテグレーション... 　続きを読む　 Sqripts 関連記事｜Sqripts Notionプロジェクトのテンプレートでスクラム開発をよりスムーズに！ こんにちは、エンジニアのタカです。普段はスクラムマスターや開発者としてプロダクトの開発に関わっています。今回は前回の Notionでプロダクトバックログを管理するビューを作成する の記事の続きで、Notionプロジェクトについて書きたいと思います。関連記事Notio... 　続きを読む　 Sqripts 関連記事｜Sqripts Notionの機能には満足しているのですが、Notionで管理している不具合やプロダクトバックログと、GitHub上のpull requestの連携には引き続き課題を感じていました。 インテグレーション機能 を使っても、NotionとGitHubのそれぞれのツールを行き来しながらpull requestを作成、および連携をする必要があるため、やや手間がかかっていたのです。 GitHubのIssueであれば数クリックでpull requestと連携できるため、便利に感じていました。また、Issueを管理できるGitHub Projectsという機能の存在も、以前から知っていました。 そこで、ちょうど大きな開発の切れ目でスプリントゼロの期間を設けることになり、GitHub Projectsの導入を検討することになりました。チーム体制が変わるタイミングだったこともあり、私が最初にツール選定を行ったうえで、その後に各自が触り、問題なければ導入するという流れになりました。 GitHub Projectsの特徴 GitHub Projectsは複数のリポジトリのIssueやpull requestをカードとして追加し、ビューとして表示できます。 以下の画像ががビューの1つであるボードビューですが、ここに追加したIssueやpull requestが表示されます。なお、このビュー上から新たにカードをDraftとして追加し、リポジトリのIssueに変換することもできます。 ボードビュー GitHub Projects上で表示したIssueやPull Requestに、ラベルや担当者を割り当てる操作は、リポジトリ側にも反映されます。また、GitHub Projects独自でステータスなどのプロパティも付与でき、それらはリポジトリ側でも確認可能です。 リポジトリ側のIssueのプロパティ 独自のプロパティは、ビュー上の一覧画面で直接の更新が可能です。 例えば、Open/Close のステータスしか持たないIssueに、「ステータス」といったプロパティをGitHub Projects側で定義できるのですが、Issue の状態に合わせて、ボードビューで簡単にステータスを変更できるため、管理をより視覚的にかつスムーズに行うことができます。 GitHub ProjectsとNotionの比較 NotionとGitHub Projectsはそれぞれを触ってみると、ツールとしての方向性の違いを感じました。 Notionは柔軟性とカスタマイズ性に優れたオールインワンのワークスペースである一方、GitHub Projectsはソフトウェア開発に特化したプロジェクト管理ツールです。 GitHub Projectsはリポジトリとの連携が強く、IssueやPull Requestをカンバンボードで視覚化して管理できます。 それぞれの主な特徴をざっと記載しますが、ソフトウェアの開発プロジェクトの用途と考えた場合、 高い柔軟性 を求める場合は Notion 、 GitHubとの連携 を求める場合は GitHub Projects が良いと感じました。 ツール名 主な特徴 Notion • 高い柔軟性 : カスタマイズ性が高く、データベース、カンバン、カレンダー、ドキュメントなどを自由に組み合わせ可能。 • 豊富な機能 : 機能も多彩にあり、タスク管理、ドキュメント作成、ナレッジベースなど幅広い用途に対応。 • 共同作業のしやすさ : リアルタイムで共同で編集が可能。 GitHub Projects • GitHubとの連携 : GitHubのIssueやPull Request等と連携し、開発ワークフローを効率化。 • 使い慣れたUI : GitHubユーザーにとって、使い慣れたインターフェースでプロジェクト管理が可能。 • 自動化機能 : GitHub Actionsを用いて、IssueやPull Requestの変更に基づいた自動化が可能。 GitHub Projectsを使った感触 ここからはGitHub ProjectsとNotionをより細かく比較していきます。なお、プロパティなどのカスタマイズは、GitHub ProjectsのAdminロールを持っていれば可能です。 ビュー、レイアウトの機能は必要十分 初めてGitHub Projectsを使うと表示されるボードビューは、特にアジャイル開発では使うことが多いビューで、私たちのチームもNotionで使用していたため、引き続き使用することにしました。 ボードビュー なお、デフォルトの状態ではステータスが足りなかったため、開発の流れに沿ったステータスを追加しました。使い方としては、PBI（プロダクトバックログ）の進行状態やマージのステータスに合わせて右に移していきます。 また、新たにビューを作成する際は、レイアウトを3種類から選択できます。 ビューのレイアウトと設定項目 プロジェクト管理に絞るならカスタマイズ性も問題無し 設定画面 GitHub Projectsの持つプロパティはカスタマイズができ、ソフトウェア開発のプロジェクト管理という用途で絞った場合は、プロパティの種類も最低限のものが揃っており、それらを用途に併せて自由に作成可能です。 カスタマイズプロパティの追加 プロパティの種類は5項目です。Notion のようにリレーションを自由に作成することはできませんが、アジャイル開発で必ず使う Sprint（イテレーション）などは専用の項目が用意されています。 なお、私たちの開発チームでは、主に以下のようなプロパティを作成して使用しています。 プロパティ名 用途 Epic 機能の種別として使用 機能A、機能B、機能C..など Sprint スプリント期間 PBI Velocity PBIのベロシティ UIが使い慣れている GitHub Projectsは、開発者が使い慣れているGitHubのUIとシームレスに統合されている点は大きなメリットになると感じました。 普段からIssueやPull Requestの確認で使い慣れたGitHubのインターフェースと操作感のままGitHub Projectsを利用できます。そのため、新たなツールを導入する際に付き物の学習コストは非常に低く、実際に導入した後もチームでスムーズに使い始めることができました。 ただ、元々のUIと同様、Issueのコメントは書いていくと段々見辛くなってしまいます。そのため、意識的にコメントを閉じていく必要があると感じました。 GitHub Wikiの利便性は△ GitHub Projectsとは直接関係の無い機能ですが、もともとNotionで管理していたページについても、主に開発・運用チームしか使わないものは GitHub Wiki というWiki機能に移すことも行いました。 しかし、正直なところ、GitHub Wikiは「痒いところに手が届かない」という印象を拭えませんでした。 具体的には、以下のような点が気になりました。 デザインやカスタマイズ面がシンプルすぎる： Notionで出来ていたような、目次の生成や検索機能、見た目のカスタマイズなど細かい部分で出来ないことが多いです。 権限管理が粗い： Notionのように、ページごとに閲覧権限を設定することができず、チーム全体に公開するか、完全に非公開にするかの二択になっています。 ページ管理の難しさ： ページ一覧をボードやリストで表示などが出来ないため、ページを作った後の管理に問題があると感じました。 もちろん、ページ数を抑えたシンプルなWikiとして利用するには十分な機能が備わっています。バージョン管理が容易であるなど、GitHubとの親和性の高さも魅力です。 このため、現段階では、開発者しか触らない内容をコンパクトに数ページ〜十数ページ程度にまとめると使いやすいのではと考えています。 おわりに 今回の内容は以上となります。 GitHub Projectsは無料プランでも利用できる機能です。すでにGitHubを使っているソフトウェア開発の現場では自然と取り入れられるプロジェクト管理機能で、利用ハードルが低いながらも、必要十分な機能を満たしていると感じました。 これからプロジェクト管理ツールを導入しようと考えている方や、今使っているツールに満足していない方は、ぜひ一度GitHub Projectsを試してみてはいかがでしょうか。 The post Notion vs GitHub Projects：プロダクト開発に最適なのはどっち？ first appeared on Sqripts .

こんにちは、セキュリティエンジニアの河村です。 この度初めてsqriptsに記事を執筆することになりました。数回にわたって技術書を紹介していく予定です。 今回は技術書を読むための本、『｢技術書｣の読書術』の書評を行います。 「技術書」の読書術 達人が教える選び方・読み方・情報発信＆共有のコツとテクニック | 翔泳社 技術書の表も裏も知り尽くした人気作家が、読書を血肉にするコツとテクニックを教えます。おそらく本邦初、「技術書（コンピュータ書）」の読書術を指南する本が登場！次々と新しい技術が登場する時代、書籍からうまく知識やスキルを得られるかどうかがIT職のキャリ... 　詳細はこちら　 Shoeisha 関連情報 本の概要 『｢技術書｣の読書術』は、数々の技術書をヒットさせているIPUSIRON氏と、情報系の数学を研究している増井氏による、技術書や一般書を読む際のインプットとアウトプットの方法や心がけを記載した本です。二人とも圧倒的な数の書物を読む読書の達人であり、本を沢山読む人はもちろん、本に対して苦手意識がある人にも役に立つ技術書と向き合うにあたっての一般論が記載されています。 内容の要約｜各章の解説 本書は「選び方」「読み方」「情報発信＆共有」という章に分かれています。それぞれについて簡単に解説します。 本の選び方 書店の特徴 本を選ぶ方法の前に本の取得方法の一つの書店の特徴についてお話しします。書店ごとに特徴が当然あり、それを理解することでよりニーズにあった書籍と出会いやすい、というのは納得頂けるかと思います。私もこの企画のために技術書を三冊ほど買ったのですが、自宅から近い中堅都市の本屋では満足がいくレベルの技術書が見つからず、結局交通の要所となってる池袋のジュンク堂で買いました。需要と供給の関係から当然このような場所に大規模かつ専門的な書店は集約されます。池袋、新宿、東京駅などの本屋は規模も大きく、専門分野に特化した強さもあります。 これらの書店の店員は各分野の専門家たちとやりとりをしてるため、彼(女)らとコミュニケーションを取ることで新鮮な情報を収集することも出来ます。 この度書籍を買ったジュンク堂池袋本店は本書にも記載されていた、日本有数の｢技術書のメッカ｣である 書籍のレベル感 本を選ぶ際の注意点として、書籍のレベル感について知っておくと良いでしょう。技術書は大きく分けて、「概要を理解したい層」（PM、システム開発の発注者など）、「実装の手順を知りたい層」（プログラマなど）、「理論を理解したい層」（理系の大学生など）等の区分されており、ターゲットの読者層に応じて書籍が重点を置いてる内容が異なってきます。このようなレベル感の違いを知っておけば、例えば「実践的なコードを書けるようになりたいのに名著という評判であることを理由に｢概要を理解したい層｣向けの本を選んだ結果、知りたい内容が記載されていなかった」と言った失敗は避けることができます。 本を選ぶときに参考にすべきポイント 評判 著者のプロフィール 索引 出版者 索引、出版者などの観点は本を読み慣れてない人だとあまり着目しないことも多いと思います。 本のレビューサイトとの付き合い方 現代では書籍を探す際、レビューサイトを見ることが多いと思います。レビューの評価だけではなく、レビューを書いている人のレベル感にも注意するといいです。 図書館の活用 図書館はその性質上、古い本が多いですが、本屋よりも置いてある本にバイアスがかかってないと言えます。また、なんと言っても無料である点は嬉しいです。絶版本などが多く置いてあることから、技術の歴史、普遍的な基礎技術などについて調べる場合は、非常に有用です。 サブスクサービス 本のサブスクサービスを活用することで、普段なら目を通さない雑誌などにも触れることが増え、視野が広がる効果を狙えます。また、O’Reilly online learningやPacktなどの英語圏のサブスクサービスには非常に良質な技術書も含まれています。 本の読み方 この章では二人の著者が実践してる読み方が記載されています。紹介された読み方の中には中々エキセントリックなものもあります。その中から、私が参考にしてみようと思ったものを中心に紹介します。 電子書籍 検索機能が優秀で、またデジタルデータなのでかさばりません。その代わりに一ページ以上ページをめくることが困難であるといえます。 紙媒体 電子書籍より機能が限定されるため、より強い没入感があると言えます。当然所有感も満たされます。当然場所を占拠します。 プログラミング書の読み方 プログラミングは目的では無く、手段であるということが重要です。本に記載されている本を無条件に信じず、常に手を動かすことを念頭に置くべしです。 数学書の読み方 学校での数学と、ビジネスでの数学が求めるものの違いを意識することが重要です 学校では理論重視、また正解がある問題 ビジネスでは実践重視、答えがあるとは限らない 再読すること 再読する際には、以前とは違う感想を持ちます。そこから自らの、｢価値観の変化｣、｢知識・スキルの向上｣等を認識することができます。 場所を問わない読書 迷惑をかけずに、安全さえ確保できたら、読書はいつどこで行っても構いません。若干極端な例だと思いましたが、食事中、エスカレーターに乗ってる間、旅行中、入浴中などの読書について紹介されていました。本を読む情熱さえあれば、ほとんどどこでも本は読めます。 私自身、個人的に電車の旅が好きなのですが、それの大きな理由として、読書に専念できるからというのはあります。あえて鈍行列車に乗り、積ん読してた本を一気に読むことを定期的に行っています。電子書籍を用いればかさばる心配もいりません。 夏期と冬期に入手できる 青春18切符 と読書の相性は抜群です 媒体を問わない 紙媒体、電子書籍はもちろん、オーディオブックなども今は充実してきています。これらを活用することで隙間時間にインプットを行えたりします。ドライブ中などにもインプットが行えます。 私自身はスマホを持つことも困難なレベルの満員電車ではオーディオブックで本を聞くことをよく行います。 オーディオブックの最大手、Audible 分冊化読書法 本を物理的に裁断し、読みたい箇所だけを持ち運ぶ読書法です。当然本を破壊することになるので、お手軽な読書法とはいえません。ですが、特に試験勉強など、覚えることが中心となる読書の際には効果的といえます。 私自身、大学受験のときは1000ページ近くある数学の参考書でこれを行っていました。次また何か資格試験を受ける際にやってみようと思っています。 時間制限読書法 制限時間を設けて一定の箇所まで読書を行う方法です。この本では90分単位が薦められています。 似た概念として、｢ポモドーロテクニック｣があげられます。 ポモドーロ・テクニック - Wikipedia 　詳細はこちら　 ja.wikipedia.org 関連情報 このような読書法を行う場合、適度に本を読み飛ばす技術があるといいです。 これを行う際、集中力のさまたげとなるスマホ、パソコンなどとは距離を置く方がいいです。極力メモも取らない方がいいです。私自身、この読み方を行う際、付箋を活用して重要な箇所、SNSで共有したい箇所などをマークし、制限時間後にそれらをチェックするように心がけています。 マーキング読書法 読書の際に随時内容に応じて適当なマークを付ける読書法のことです。こうすることで、考えが整理されたり、集中力が向上したりなどのメリットがあると言えます。また、読み返した際に過去の自分が選定した箇所を見ることで、自分の成長を実感出来るなどのメリットもあります。当然本を汚すことにはなります。 私は今、Post-itの特定の色を用いてマーキングするようにしています。特定の色とは赤、橙、黄、青なのですが、なぜこれらの色かと言いますと、これはKindleで用いれるマーカーの色と同じだからです。また、Post-itの場合、綺麗に剥がせるので基本的に本を汚しません。参考までに私の色の使い方を共有します。 橙：技術的な内容、キーワード(覚えたい用語など) 赤：SNSでシェアしたい内容 ⇒ 読書中にSNSでシェアすると注意力が散漫になるため、マーキングしてからシェアするようにしてる 青：章全体が参考になりそうな場合 黄色：気になる単語、キーワード(橙ほど重要ではない) このように付箋を沢山貼ってます Kindleでも同様にマーキングできます PDFの読書 PDFに記載された文書を読む際、iPadなどにはGoodNotes等優れたアプリがあることが記載されています。私はNoteShelf2というアプリを用いていますが、これらのアプリはApplePencilで直接書き込むことが出来たりとハイスペックです。WindowsやAndroidにも優れたアプリはたくさんあるのでこれらを活用することで読書のインプットアウトプットの質を上げることは重要なことだと言えます。 英文の読書 日本人が英語の文献を効率的に読む際、翻訳ソフトはほとんど必須と言えます。DeepL等を上手に活用することでPackt等の良質な英語の技術書をかなりストレスを軽減した上で読めます。 私自身はChatGPTに英文読解の補佐をお願いすることが多いです。プロンプトをカスタマイズし、分からない文の構文解析、内容の要約など柔軟に活用出来ます。また、ある程度図なども読むことが出来る点が気に入ってます(OCR機能が優秀である程度ならばスクショからも読んでくれます)。 読書記録 読書を通して自己を計画的に成長させていきたい場合、読書記録を取ることは大変有用です。進捗を数値化したり、過去を振り返れるように出来ることが大字なので、読み始めた日、読了日を記録できることは重要です。本書では｢読書メーター｣などの読書記録サービスが勧められています。もちろんNotionでも可能です。 Notion用の読書記録向けのテンプレートがインターネットからダウンロードできます。 私自身のNotionで作った簡単な読書ログ、カスタマイズできる範囲が広く、楽しいです 一点突破読書法 分野を絞り、その分野の本を最低でも20冊ほど読み、強みに変えていく読書法です。ですが、強みとなる分野を一つに絞った場合、ナンバーワンになることは基本的に難しいです(情報セキュリティ、整数論、英語などの分野の場合、非常に困難)。ですが、これら3つの分野全てが得意な人となると途端に人数は減ります。このようにニッチな分野の組み合わせならば、オンリーワンを目指すことは出来ます。 この読書法はそのような人材を目指す際に有用な方法と言えます。 情報発信＆共有 間違いに気付くために、アウトプットは必要 本を読み、インプットするだけでは、理解に誤りがあった場合にも、それに気付けない恐れがあります。ところが、自らの理解に自信がない場合アウトプットに躊躇してしまうことは多多あります。読書を通した自らの理解をより効率よく深めて行くためにも、とりあえずアウトプットする習慣を付けることは重要です。 アウトプットにも様々な種類があります。例をあげます。 資料の作成 ブログの執筆 コミュニティへの参加(LTへの挑戦) 人へのアドバイス、説明 資格試験の受験 レビューを行う 初心者の視点も貴重 上級者は初心者の視点というのを失いがちですが、確実に初心者の視点というものにも需要はあります。このように様々な視点それぞれに需要があるので、自分自身の視点でアウトプットを書くことが重要です。 たくさんアウトプットすることが重要 失敗を恐れてアウトプットを躊躇することはよくありません。継続的にアウトプットをすることが成長には必要なため、アウトプットに関してはある種の楽観主義でいた方がいいとも言えます。 本書を読んで インプット全般についての意識が変わった エンジニアにとって情報をインプットしていき、自らの技術に新陳代謝をもたらすことは必要不可欠です。本書は読書に留まらず、そのインプット行為全般についての指南書とも言えると感じました。 本書を読み、作者の一番伝えたかったことは、読書(その他インプットも含む)という行為そのものを楽しみ、情熱を持つことが優れた読書家になる上で一番大事だと言ってるように私は感じました。インプットを通して技術を身に付けるのにはどのようにしても時間などがかかります。この行為に時間を大きく割くことは一見非効率に思えるかも知れません。 読書等のインプットをすることが将来の自分への投資であるという感覚は多くの方がすでに持ってると思いますが、それ以上に自らのエンジニアとしてのキャリアを描く上での喜びであると捉えることが大事なんだと思いました。昨日の自分より明日の自分は少しだけ善き人生を生きてるという感覚に幸せを感じない者はいないはずです。例えばかつて難しいと感じた本を再読した際に、違った視点で見える自分、それが前の自分より優れた視点であると感じれたとき、技術の向上を感じれます。このように情報技術に限らず、自分自身の成長を実感する場としても読書は優れていると、本書を読み私は改めて実感しました。 このように感じれたのは、本書を執筆したお二人の読書への情熱を余すところなく本書を通して伝えてくれたからだと思いました。 The post 『｢技術書｣の読書術』書評 first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像と、プロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜ プロジェクトマネジメント成功の技術 連載一覧＞ ※クリックで開きます 【第1回】プロジェクトマネジメントとは何か？ 　［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ 第12回となる今回は「資源マネジメント前編」です。 今回と次回の2回に分けて、プロジェクトマネジメントにおける人、チーム、物資にスポットを当てて解説します。 プロジェクトにおける「資源」 プロジェクトの資源には「人＝人的資源」と「物資＝物的資源」の二つがあります。プロジェクトマネジメントにおける資源マネジメントは「プロジェクトを成功裏に完了させるために必要な資源を特定し、獲得し、マネジメントする」と定義されます。チーム員が居てもその能力がプロジェクトの求める基準に達していない、プロジェクト遂行にあたってモノ/環境が整わない、というように、必要な「力＝資源」が欠けていてはプロジェクトの成功は望めません。また、チームを組成してもチーム内にトラブルが生じてしまっては想定したパフォーマンスを発揮できずプロジェクトは座礁するでしょう。資源マネジメントの目的はプロジェクトの成功に必要なチームを組織し、モノを整備調達し、チームワークを育み、プロジェクトのパフォーマンスを高めることです。 資源マネジメントのステップ プロジェクト資源マネジメントは以下6つのステップで行います。「資源の獲得」「チームの育成」とあるように、プロジェクト目標を達成するために共同で活動するメンバやチームを獲得し、育て、動機づけ、必要な権限移譲などに努力を払う必要があり、プロジェクト活動中にプロジェクトマネージャーが多くの意識を傾ける活動がこの資源マネジメントです。資源は有限であり、その貴重な資源をできる限り「活かす」ことが重要です。 資源マネジメントを計画し資源を見積もる プロジェクトがなぜ資源を必要とするか、あたり前のようですがそれは「プロジェクト活動を行い、活動を通じてプロジェクトの目標・目的を達成する」為ですね。ですから「どんな人にプロジェクトに参加してほしい」「こんなスキルを持った人が必要だ」「かならずXX開発ソフトが必要だ」という条件やイメージがあるはずです。 1) 資源マネジメントのガイドラインを考える ①資源の獲得方法：プロジェクトのためのチームと物的資源の獲得方法を検討する ②人的資源に求める役割や責任の整理 ③資源のトレーニング（研修）や育成方法 ④表彰計画 例えば①では、希少なスキルを持つ人（資源）が他のプロジェクトでも同じ時間に必要となる場合に、どのように調整するかなども計画しておきましょう。④の表彰計画は困難なプロジェクトや参加メンバーを社内から募るような場合に有効です。「XXプロジェクト参加者の中から１名はXX研修に参加できる」「参加者全員に社内XXポイントを付与する」というように使います。その際に必要なコスト（例で言えば研修費用など）を組織から引き出しておくこともプロジェクトマネージャーの役割です。 2) 必要な人員をマトリックスで整理する 人的資源の役割と責任を整理するために「責任分担マトリックス(RAM: Responsibility Assignment Matrix)」を作りましょう。WBSで整理したワークパッケージと要員をマトリックスで表します。それぞれの役割を「RACI（レイシー）」という4つの分類で定義するため「RACIチャート」と呼びます。 Responsible（実行責任） ：作業を実行することに責任を持つ（複数アサインOK） Accountable（説明責任） ：作業の進捗状況などの各説明に責任を持つ Consult（相談対応） ：作業実行等を支援して、アドバイスを提供する Inform（情報提供） ：作業の進捗状況や状態について報告を受ける RACIチャートは誤った意思決定を防ぎ、承認プロセスをスムーズにしたり障害を回避することも期待されます。特にRとAについてはWBS本編上にも記載すると良いですね。 ３）ガイドラインに基づいて、資源を見積もる プロジェクトで発生するタスク（アクティビティやワークパッケージごと）を洗い出し、必要となる資源やそのタイプ、量などを見積もります。見積もりの詳細さや具体化の程度はプロジェクトやその適用分野により異なりますが、いずれにしても資源の種類や量を見積もった根拠・前提条件、見積もり根拠は必ず記載します。見積もりができたら「資源ブレークダウンストラクチャ(RBS: Resource Breakdown Structure)」に整理し、資源に抜け漏れがないかを確認しましょう。 資源を獲得してチームを組成しよう 資源は無限ではなくコストもかかります。だからこそプロジェクトの成功のために必要な資源を意思を持って「獲得」する必要があります。また、プロジェクトに必要な資源は自社内に限らず、社外から調達する必要があるかもしれません。PMがその権限を発揮して資源を直接選定できることも、できないこともあるでしょう。「思うような資源が獲得できるか」はプロジェクトにおける大きな腕の見せ所です。 1) 資源獲得のポイント 資源提供者との交渉 PMやチームは、プロジェクトに必要な人的資源や物的資源を提供する立場にある人たちと積極的に交渉しましょう。 資源を確保しようという意思 プロジェクト開始時点から「リソースが枯渇している」という不満を耳にすることがあります。必要な資源を確保できなければ、スケジュール、予算、顧客満足、品質、リスクなど全方位的に影響を与えます。資源やその能力が不十分であればあるほど、プロジェクトの成功確率は低下し、最悪の場合プロジェクトが中止になることも。 代替え資源の検討 「XXに長けた人員を外部召集したいが調達コストがない」「XXさんは別プロジェクトの主要メンバーなので、どうしてもこちらのプロジェクトには参加できない」というように、経済的な要因や制約で資源が確保できないことがあるでしょう。そのような時はコンピテンシーやコストが異なる代替え資源も検討しましょう。 バーチャルチーム バーチャルチームモデルを採用することで、地理的に離れた地域に住む要員がチームに参加できるかもしれません。あらゆる可能性と組み合わせを検討しましょう。 2) プロジェクトチームの任命 プロジェクト初期に「XXプロジェクトに召集されたけれども、どんなことを求められているかわかってない（聞いていない）」という不安や不満が聞こえることがあります。プロジェクト初期は未決定事項も多いのも事実ですが、このような場合プロジェクトがその人に期待する役割や与える責任を明確に伝えられていないことが考えられます。多くの組織では人的資源は機能部門（人的資源が所属する組織）から割り当てられますが、その際十分な説明がなされておらず上記のような不安を抱くことが少なくありません。「所属部門・機能部門長がプロジェクト参加者にプロジェクト概要やミッションや役割を説明しているだろう」と思わずに（期待せずに）、できる限りメンバーひとりひとりに対して「任命説明」の時間を設けて対話しましょう。 3) 作っておきたい資源カレンダー 「資源カレンダー」という言葉は聞きなれないかもしれませんが、プロジェクトに割けるリソースを表したものです。誰が、いつ、どの程度プロジェクトに参加できるのかを明確にして管理します。その際は要員以外にも施設や機材などの資源も併せて記載して、プロジェクトの進捗に関わる情報を一元管理しましょう。 さいごに プロジェクトにおける「資源」について、また資源マネジメント、チーム組成の流れと重要性について解説しました。資源が足りてないといっても「ただ人・物が揃えばよい」ではなく、プロジェクトに必要な要素を満たしている必要があります（多くの場合ここがFITしていない）。また多くの場合「組織やプロジェクトにおける資源は十分に足りていて心配ない」というケースは少ないはずですから、より資源の獲得に向けた段取りがプロジェクトの肝になります。みなさんのプロジェクトにおいて、資源マネジメントがちゃんと「計画」されているかぜひ振り返ってみて下さい。 次回の「資源マネジメント」後編では、チームの育成やマネジメントにフォーカスしていきます。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中］ 【第2回】プロジェクトマネージャーの役割とは？ 【第3回】ステークホルダーマネジメントの重要性と進め方 【第4回】プロジェクトの統合マネジメント、7つのプロセス 【第5回】プロジェクトにおけるスコープマネジメント、6つのステップ 【第6回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［前編］ 【第7回】WBSだけでスケジュールはできない！正しいスケジュールの導き方［後編］ 【第8回】コストをプロジェクトの武器にする！ 【第9回】目に見えにくいプロセス管理こそ品質達成の鍵 【第10回】プロジェクトのリスクマネジメント［前編］リスクを徹底的に洗い出す 【第11回】プロジェクトのリスクマネジメント［後編］リスク分析とコンティンジェンシープラン 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ The post 【第12回】人がプロジェクトの源泉！チームは育てて強くする［前編］ first appeared on Sqripts .

※本ページに記載の部署名・役職名・所属は2024年6月12日現在の情報です 2024年6月12日（水）～14日（金）に幕張メッセで開催されたインターネットテクノロジーのイベント「Interop Tokyo 2024」に参加してきました。 今回は、6月12日に行われた基調講演のひとつ、株式会社AGEST、KELA株式会社、フォースポイント・ジャパン株式会社の3社による「 【情報漏洩／流出対策】最前線～ダークウェブ監視と内部不正対策のリーディング企業が組織内外の視点から語る、サイバーセキュリティとリスクマネジメント～ 」についてレポートします。 モデレーター 　株式会社AGEST　マーケティング本部　岡部 康弘 氏 スピーカー 　KELA株式会社　Head of pre-sales　川崎 真 氏 　フォースポイント・ジャパン株式会社　Sales Director　布宮 友寛 氏 なぜこのテーマを選んだのか 冒頭はモデレーターを務めたAGEST・岡部氏のセッションでした。 今回の講演テーマを選んだ理由について、IPAの「 情報セキュリティ10大脅威2024 [組織]」の中で「内部不正による情報漏洩等の被害」、「犯罪のビジネス化（アンダーグラウンドサービス）」が過去3年で順当に順位を上げてきていること、また2023年の日本国内における個人情報流出件数が過去最大であったことに触れ、「内部不正対策」「ダークウェブ監視」が企業にとって喫緊の課題であり、注目度の高いテーマであることについて解説しました。 【情報漏洩／流出対策】最前線講演資料より 情報漏洩とは？情報が漏洩すると何が起こるのか 情報漏洩とは何か？について講演では「”外部に公開すべきでない情報”が第三者に渡ってしまうこと」と定義していました。 “外部に公開すべきでない情報”とそれが漏洩した際に起こり得る事象の代表例が、以下のスライドで解説されていました。 【情報漏洩／流出対策】最前線講演資料より さらには報道によるイメージの低下、各種対応によるリソースの切迫、売上への影響などなど、ダメージは計り知れず、「情報漏洩がもたらす影響は 全てが致命的 」と考えられます。 情報はどこから流出するのか？ では、情報はどこから流出するのでしょうか。情報漏洩のルートを大きく4つに分けて解説されていました。 【情報漏洩／流出対策】最前線講演資料より 自社が攻撃を受けて情報流出 不正な持ち出しによる情報流出（内部不正） 取引先が攻撃に遭い情報流出（サプライチェーン攻撃） 利用中のサービスが攻撃被害に遭い情報流出 スライド画像の左から番号を振って記載しましたが、3番（画像の右から2番目）は「自社ではなく取引先が攻撃を受けることにより自社の情報が漏洩し、自社も攻撃対象となってしまう」というケースです。 そして4番（画像の一番右）は業務上使用しているサービスの提供元が被害に遭い、登録してある認証情報などが流出してしまうケースです。 これらのケースから分かることは、 自社の努力だけでは防げない領域がある 情報流出のリスクを 0 にすることは難しい ということです。 リスクの深掘り 続いてKELA株式会社の川崎氏、フォースポイント・ジャパン株式会社の布宮氏の登壇です。 リスクを深掘りした上で、その対応方法までを解説しました。 ① 組織の外部という視点 流出した情報は、どこで、誰が、どのように扱っているのか？ KELA・川崎氏は、流出した情報が「どこで、誰が、どのように扱っているのか」について、まずは「どのように流出したか」に着目するとのこと。 その上で、サイバー攻撃者がサイバー犯罪の目的で流出させたとなれば、当然のことながら情報は「サイバー犯罪者」に渡ってしまいます。 サイバー犯罪者たちの目的は、興味本位、政治的な目的、国家の支援によるものなどさまざまですが、大多数は「それを生業にしている」とのことでした。 サイバー犯罪者たちはインターネット上でコミュニティ（エコシステム）を形成しており、時として実際に売買を行う、情報を共有する、そのような場があるのだそうです。 このコミュニティはかなり大規模なものであるとのことで、会場参加者限定のスライドなども使って具体的に解説されていました。 【情報漏洩／流出対策】最前線講演資料より サイバー犯罪者のエコシステム内で行われていることの例としてクレジットカードの犯罪が取り上げられました。 フィッシング、スキミングなどの形でカード情報が盗まれると、その情報はエコシステム内で売買、あるいは共有されます。クレジットカード情報を取得したサイバー犯罪者たちは、その情報を使ってクレジットカードを不正利用します。クレジットカード情報を取引する場は闇サイト、ダークウェブなどと呼ばれる領域に存在していますが、最近の傾向としてはダークウェブだけでなく、テレグラムという匿名性の高いSNSを使用して取引している例も多いようです。講演会場では実例をスクリーンに表示し解説されていました。 配信無しの現地講演ならではの情報も多く（撮影・録音が禁止されていました）、会場では興味深くスクリーンに見入る聴講者の姿も印象的でした。 ② 組織の内部という視点 続いてフォースポイント・ジャパン株式会社・布宮氏のスピーチです。 内部から情報を持ち出すパターンを具体的に解説 今回は「内部から情報を 意図的 に持ち出すパターン」について解説しました。 【情報漏洩／流出対策】最前線講演資料より 情報漏洩は基本的には、普段使っている端末を起点に、上の図で示したような多様な経路からの流出が考えられるます。 個人のクラウドストレージへのアップロードやファイル転送サービスなどの利用も想定されますが、依然として主流なのは電子メールで、プリンタやUSBメモリといった外部出力機器からの流出も根強く残っているということでした。 内部から情報を持ち出すのはどんな人物なのか？その動機は？ 会社の情報を持ち出すパターンとしては、 悪意を持って意図的に持ち出す（転職を機に情報を故意に持ち出す場合も含まれる） 意図せずに持ち出してしまった・漏洩してしまった この2パターンが考えられます。 悪意を持って持ち出すパターン 悪意を持って持ち出すパターンとしては、心理学的な要因として「不正のトライアングル」の下図が示されました。 動機、機会、正当化という3つが揃った時に不正が起こる、または起こりやすいという判断ができるとのことです。 【情報漏洩／流出対策】最前線講演資料より 意図せず持ち出すパターン 一方で、意図せず持ち出してしまうパターンについても、情報の漏洩が起きやすくなっているとの解説がありました。 背景としては、在宅勤務などの働き方の多様化や、BYOD（私的デバイスの業務利用）が盛んに行われるようになったこと、また多種多様なクラウドサービスを利用する上で設定を誤り、個人情報が見える状態になっていた、などさまざまな要因が考えられます。 便利な世の中になっている反面で、情報漏洩が起きやすくなっているのも事実とのことでした。 リスクへの対応方法 続いて内部不正による情報漏洩、そしてダークウェブなどに流出してしまった情報の対応方法についての解説がありました。 内部からの不正な持ち出しへの対策 内部からの不正な持ち出しへの対策として、布宮氏は以下のスライドで解説しました。 【情報漏洩／流出対策】最前線講演資料より 「内部不正対策」と検索すると、さまざまなツールも出てきますが、まず最も大事なのは「セキュリティ教育」で従業員のリテラシーをきちんと上げることだと解説されていました。 従業員の教育を最初に行い、その次にツールを検討します。中でも「DLP」が最適解ではあるものの、導入してもうまくいかなかった、効果的なのかもしれないが使いこなせなかった、という法人も多いということでした。 その理由としては、「データの棚卸ができていないこと」が挙げられます。 データの重要度 社外秘かそうでないか 等での分類ができていない法人が非常に多く、この状態でDLPを導入すると、誤検知や検知の頻発が発生して有効に使うことができない、という状況を招いてしまうということでした。 ではどうすればいいのか、その対策として「データの棚卸・分類 = 守るべき対象の見える化）」から始めましょう、と提案されていました。 具体的には、DSPM（Data Security Posture Management）という手法を活用し、さらにDLPと組み合わせることで効果的な情報漏洩対策が可能となるとのことでした。 【情報漏洩／流出対策】最前線講演資料より 外部に流出した情報の検知と対応 続いて、流出してしまった情報の脅威情報を検知したとき、何をすればいいのかについてKELA・川崎氏がスピーチしました。 「漏洩の検証」「影響範囲の特定」から始まり「再発の防止」までさまざまな対応、手続きが必要となりますが、まず大事なポイントとして、「その情報ソースは正しいのか」を見極める必要があります。 【情報漏洩／流出対策】最前線講演資料より サイバー犯罪コミュニティを自社で監視することはできるのか？ また、脅威情報を検知したとして、サイバー犯罪コミュニティを自社で監視することはできるのか？について、講演では「安全性の観点から非推奨」とのことでした。 理由としては、 そもそもダークウェブへのアクセスそのものが難しい 仮にアクセスできても監視そのものが難しい 多言語への対応（特にロシア語や中国語など） コミュニティ特有のスラングが多用されている 投稿がバイネームであるとは限らないため、少ない情報から自組織に関連性があるか推測が必要 などが挙げられていました。 安全にダークウェブ監視を行うためには、やはり専門的な知見やプラットフォームを有する脅威インテリジェンスベンダーの活用が推奨されます。 【情報漏洩／流出対策】最前線講演資料より 40分ほどのセッションの終わりには、KELA、フォースポイント・ジャパン、AGESTの紹介を行って締めくくられました。 アンケート結果 聴講者の声 （満足）情報漏洩のリスクや、防ぐために何が必要か、などの概念的な内容について学べてとても面白かった。 （満足）情報漏洩が重大な問題であることは周知の事実としても、実際のところ漏洩した情報がどうなっているのかは正直、よくわからなかったのだが、非常に生々しい実態を教えていただき、危機感を高めることができた。 また、対策を行う前にまずやらなければならない対応（DSPM）についても理解でき、非常に有意義なセミナーだった。 （やや不満）技術的な話を期待していたため、少し目的とは異なったが、ダークウェブのリアルを知る良い機会となった。 まとめ ダークウェブ監視と内部不正対策というテーマでの講演でしたが、情報漏洩の「内部不正」にスポットを当てて具体的に解説されていたところ、また情報漏洩した後のダークウェブ監視、テレグラムなどの「エコシステム」の実態の紹介など、取材で参加した筆者もとても理解がしやすく、この講演を通じて課題意識が高まりました。 現地開催の講演ならではの、聴講者の反応もひしひしと伝わってきて、遠い幕張まで行った甲斐がありました。 また次のイベントもぜひ参加したいと思います。 ●講演資料ダウンロード 今回、こちらの記事をお読みいただいた方に講演資料をご用意しました。 下記のリンクよりダウンロードください。 なお、本資料は公開用に講演資料を簡易化したものです。 ■ 【情報漏洩／流出対策】最前線講演資料（ダイジェスト版）ダウンロードはこちら The post Interop Tokyo 2024参加レポート｜基調講演【情報漏洩／流出対策】最前線「ダークウェブ監視と内部不正対策、サイバーセキュリティとリスクマネジメント」 first appeared on Sqripts .

こんにちは！ショウです。 先日、マイグレーション観点でのテスト設計を行う機会があり、どのような観点を意識して設計するべきか調べていたところ、 リプレイス という似た意味を持つ単語があることを知りました。よくよく調べてみると、似た意味の言葉ではありますが、それぞれのテスト観点には違いがあることが分かりました！ 今回の記事では、そんなマイグレーションとリプレイスのテスト観点の違いについて、お話していきたいと思います。 マイグレーションとは？ まずはじめに、今回の記事を執筆するきっかけとなった 「マイグレーション」 について説明します。 マイグレーションとは移転・移行などの意味を持つ英単語で、IT分野ではソフトウェアやデータを別の環境に移行したり、新しい環境に切り替えたりすることを意味する言葉です。旧式やサポート切れとなる古いシステムから新たに作り直した新式の環境へ移行する レガシーマイグレーション の他に、異なる装置やソフトウェア、データ形式間でデータを移動する データマイグレーション など、マイグレーションと一口に言っても様々なものがあります。 マイグレーションを行う目的としては、最適な環境に移行することで運用コストの改善を図り、ソフトウェアやデータをより有効的に使用出来るようにすることです。 主なメリットとして、移行前と移行後の動作が一致しているという明確な合格条件があるので、認識齟齬が起きにくく、システムの品質を向上させやすい点です。 デメリットとしては、新環境に向けたデータやシステムの変換作業と平行して大幅な仕様変更を行うことが難しく、仕様変更を行わない前提で開発を進める必要がある点です。 マイグレーションのイメージ図 リプレイスとは？ 続いて、 「リプレイス」 についてです。 リプレイスとは「交換・置換」などの意味を持つ英単語で、IT分野では古くなったり破損してしまったハードウェアやソフトウェアなどを新しい物や同等の機能を持った別のものに置き換えることを意味します。リプレイスを行う目的としては、システムを安定して運用することです。システムに不具合が無くても運用期間が長くなると下記のような劣化が起きます。 処理データ量が増え、ハードウェアのスペックが追いつかずに動作が重くなる 最新のソフトウェアやアップデートに対応出来ない 進化を続ける最新のコンピューターウィルスに対抗出来ない この劣化によって、業務の非効率化や情報流出などのトラブルが発生するリスクがあるため、リプレイスが必要となります。 主なメリットは、ハードウェアやソフトウェアを新しいものに置き換えることにより処理能力が向上し、システム動作が安定することであり、デメリットはリプレイスの方式にもよりますが、コストがかかることや現行のシステムを継続する場合にリプレイス後に期待通りの動作にならない場合がある点です。 リプレイスのイメージ図 それぞれのテスト観点の違いとは？ では、マイグレーションとリプレイスそれぞれのテスト観点の違いを考えていきます。 現新比較テストについて マイグレーションとリプレイスにおいてポイントとなるテスト観点のうちの一つとして、 「現新比較テスト」 が挙げられます。「現新比較テスト」とは、対象となるプロダクトの改修前後のデータや出力等を比較し、改修前後で問題となる現象や不具合が発生しないことを確認するテストとなります。 マイグレーションで有効なテスト観点 続いて、マイグレーションで有効となるテスト観点について考えてみましょう。 マイグレーションでは、システムの動作環境が新環境に変わるため、以下の3つの観点が必要となります。 1. システム全体の機能動作の現新比較 テスト観点：新環境に移行した影響によって移行前に起きていなかった不具合や問題等が発生していないか テスト例：DB処理（新規テーブルや新規レコード）に着目した機能テスト システム全体の単体機能に対する自動テスト 2. 性能（パフォーマンス）の現新比較 テスト観点：新環境への移行に伴って性能が前環境と同等または向上しているか テスト例：DB処理（新規テーブルや新規レコード）に着目した性能テスト 新環境と前環境のシステムに着目した負荷テスト 3. 業務視点の要求を満たしているか テスト観点：新環境に移行して業務運用する際、業務視点の要求から外れていないか テスト例：検証環境での本番データを流し込んだ受け入れテスト・運用テスト 機能要求に関するユーザビリティテスト 以上がマイグレーションで有効なテスト観点と各理由となります。 リプレイスで有効なテスト観点 次に、リプレイスで有効となるテスト観点について解説します。 リプレイスでは、古くなったハードウェア・ソフトウェアの全部、または一部を新しいものに置き換えるため、以下の3つの観点が必要となります。 1. リプレイス部分及び影響範囲での機能動作の現新比較 テスト観点：リプレイスを行ったことによる置換部分や関連する機能などで不具合や問題等が発生していないか テスト例： ハードウェアとのI/Fに着目した機能テスト システムテストでの全数テスト（難しい場合は単体テストでのDBテーブル値） 2. 性能（パフォーマンス）の現新比較 テスト観点：リプレイス前後で比較を行い、新環境の性能が同等または向上しているか テスト例： ハードウェアとのI/Fに着目した性能テスト ハードウェア・ソフトウェアに着目した環境テスト 3. リプレイス部分以外への影響の確認 テスト観点：リプレイスを行った箇所以外で想定外の影響・不具合や問題等が発生していないか テスト例： システム全体における確認テスト リプレイスで変更された部分に着目した自動テスト それぞれのテスト観点の違い 最後にマイグレーションとリプレイスでのテスト観点の主な違いを解説します。それぞれの有効なテスト観点を比較すると、以下のように重視しているポイントがテスト観点にも現れていることが考えられます。 マイグレーション： 「システム全体の影響確認」 を重視 リプレイス： 「リプレイス部分の影響確認」 を重視 ※ ※「リプレイス部分以外への影響の確認」の通り、リプレイス部分以外を確認しない訳ではありませんが、他2つの観点の方が重要度が高いように思われますので、上記のように記載しております。 補足 補足として、マイグレーションには「リライト」・「リホスト」・「リビルド」と呼ばれる、3つの手法もあります。 「リライト」とは、アプリケーションやプログラムのロジックは変更せずに、使用言語やプログラムを新しく書き換えて、新規プラットフォームにて動作するように移行する手法となります。「リホスト」とは、既存のシステムと同じ言語を使用して新規プラットフォームへ移行する方法となります。「リビルド」とは、改めてアーキテクチャやプログラム設計からやり直し、システムを再構築する方法です。 最後に 以上がマイグレーションとリプレイス、及びそれぞれの基本的なテスト観点の違いと補足になります。私が実際に担当したプロジェクトでは、「レガシーマイグレーション」の「リホスト」として既存システムに存在している膨大なデータを新システムの「検証環境」に移行してから1回目のテストを行い、完了後に新システムの「本番環境」へデータを移行してから、簡易的なテストを再度行うような形でテストを行いました。 テストのイメージ図 私自身、マイグレーション観点でのテスト設計は初めてだったため、どういったポイントに着目し、またどのような観点でテスト設計を行えばよいのかが当初はイマイチ把握できませんでした。しかし、本記事で紹介したように該当のテストの概要や方法などを調査し、対象のシステムに対して有効な観点をまとめたうえで、「求められる要件（移行データの一致）を満たすための期待結果の記述方法」や「それぞれ必要なテスト観点は何か」ということを意識しながらテスト設計を行うことで、情報も整理でき、新たな視点で設計作業に臨むことができました。今後のテストでもこのような経験を活かしていきたいと思います！ 今回はマイグレーションとリプレイスについて考えてきました。似た意味の言葉・手法ですが、開発の手法に合わせて考慮すべきリスクが異なることが分かりました。また、実際のプロジェクトの状態やテスト対象となるシステムによっても、テストで優先的に必要となる観点やテスト技法が異なる場合もあるかと思います。記事の執筆を通して、あらゆる状況やリスクに応じたテストを行う意識が必要だと改めて認識しました。本記事がマイグレーションやリプレイスを含め、あらゆるテストで少しでもお役に立てたら幸いです。 The post マイグレーションとリプレイスのテスト観点の違いを考える first appeared on Sqripts .

こんにちは、QAエンジニアのヒイロです。 情報処理に触れていると2進数、16進数という言葉を見聞きしたことがあると思います。 知識はあるけれど実際に触れたことのない方や、n進数そのものをこれまで知らなかったという方向けに、その注意点をn進数の中の2進数と16進数に焦点をあてて執筆しました。 はじめに 私がはじめてテスト業務に携わったのはオープン系のシステムでしたが、すぐに制御系に移行し、それ以降は日々16進数を取り扱うことになりました。 しかし、n進数に馴染みがなかったため、テスト設計から実行まで一貫して行った結果、NGになった項目はシステムの不具合ではなく「n進数について学習レベルの知識のまま設計していた」ことが原因で、設計自体に問題があったことがほとんどでした。 そこで、この記事では「気を付けるべきn進数のポイント」を紹介したいと思います。 n進数概要 10進数とは 私たちが普段使用している数え方です。 0～9の10個の数字を使用しているので10進数です。 2進数とは 2進数は0と1の2個の数字しか使用しないので2進数です。 「0と1しかないの？2とか3はどうなるの？」という疑問は表1を参照してください。 16進数とは 0～9, A～Fの16個の数字を使用するので16進数です。 A～Fはアルファベットですが数字として扱います。 ※つまりn進数とは、n個の数字を使用して数を表す方法です。n進むと桁が繰り上がります。 2進数/16進数の存在理由 「なんでこんな面倒な数を使うの？分かりにくいなぁ」って思った方に説明します。 人間は両手の指の数を合わせて10になる数、10進数を扱うのが得意です。それと同じでコンピュータは0か1かの2つの数字で情報を扱うのが得意です。皆さんおなじみのフラグがわかりやすいと思います。ONは1、OFFは0という使い方がされますよね。 2は10、3は11、4は100というように、2進数では0と1以外は存在しません。けれど0と1だけで数字を表現すると桁がどんどん膨大になってしまうので、4桁毎の4ビットに区切って変換できる16進数が使われています。 【n進数が用いられている実例】 カラーコード、文字コード、デバイスIDなどで16進数が使用されています。 カラーコード 画像系アプリやhtml、CSSで色を指定するのには16進数のカラーコードが用いられています。 白色は#FFFFFF、黒色は#000000です。目にしたことがあるのではないでしょうか。 文字コード テキストエディタなどで任意の1文字を範囲選択などするとステータスバーなどに表示されるものもあります。 たとえばS=53 c=63 r=72 i=69 p=70 t=74 s=73でScriptsは53637269707473となります。 ※Sとsの違いで分かるように、大文字と小文字ではコードが異なります。 MACアドレス ネットワーク搭載機器（ルーター、PC、スマホ等）にも先述の0～9, A～Fの16進数が使われています。 デバイスマネージャ windowsのデバイスマネージャからデバイスの詳細を確認するとハードウェアIDに16進数が表示されます。 【業務での使用例】 Web系ではあまり馴染みがないですが、組み込み系や制御系のテストで扱う場合があります。特にCAN通信[※1]では必須となります。 私は電子部品の状態確認や制御、ログ解析等に16進数を用いました。とある案件では各種仕様書、設計書、マニュアル等からテスト設計もすべて16進数表記でした。一般ユーザ向けのスマホアプリで、機器の送信する値をPCで受信しながら動作確認するという事例もあります。 [※1] CAN通信：自動車などの機械に用いられる通信規格。部品同士の情報を送受信するもの。 「見たことあるかも！暗号みたいなものだと思ってた」という方もいるのではないでしょうか。暗号ではなく、ちゃんと意味のある数字（とアルファベット）なのです。 【n進数の変換】 ではその暗号のような数字をどう解読したら良いのでしょうか。 ぱっと見て頭の中で変換できる方はそうそういないと思うので、次のような計算が必要になります。 Windows標準の電卓 設定を「標準」から「プログラマー」というモードに切り替えます。DEC,BIN,HEX,OCTという略称が並んでいますがDECが10進数です。 DECに任意の数字を入力すると、それぞれに対応する値が瞬時に表示されます（略称については表2参照） （※4進数のみ非対応） 表計算の関数 例として10進数から変換する場合は=DEC2BIN,=DEC2HEX,=DEC2OCTを用います。 10進数の11を2進数にしたい場合は「=DEC2BIN(11)」とすると1011に変換されます。 2,8,16進数から変換したい場合はDECをBIN,OCT,HEXに入れ替えます。 （※4進数のみ非対応） 表1から割り出す 例として[0000 0111 1110 1000]という2進数を16進数に変換する場合 表1で0000=0, 0111=7, 1110=E, 1000=8と分かるので、結合して16進数は[07 E8]です。 （※4,8進数も同じ方法で変換可能） n進数取り扱い注意点 接頭辞の罠 先述の表2について「数字の前の0dとかhとかって何？見づらいよ！」と思いませんか？　私は最初の頃思っていました。これは接頭辞と呼ばれるものです（接尾辞になる場合もあります）。 10進数しか扱わない現場であれば[ 100 ]と言えば[ 0d100 ]のことですが[ 0d77 ]、[ 0d99 ]のようにすべての値に[ 0d ]などと記載するのは確かに面倒だし邪魔です。 ですが他のn進数を取り扱う現場では何進数なのかがハッキリしないと、2進数の[ 100 ]は10進数だと4、16進数の[ 100 ]は10進数では256となり、まったく異なった値となります。 【テスト設計例1】 あなたは温度を示すアプリのテスト設計をすることになりました。詳細設計書には下記の記載があります。 「項目Aの値を1/2し、その結果でフォント色を下記のようにする。 ・100以上：赤、51以上：オレンジ、それ以外：青色」 項目Aを確認すると値は[ 110 ]でした。そこであなたは「110÷2で55だから…期待値はオレンジ色ね」とテスト設計しました。 ところが… case1. 項目Aは2進数表記でした！（0b110だったのです） 表1を参照（または電卓のBINをクリックし[110]を入力）してください。2進数の110(0b110)は10進数では6(0d6)ですね。1/2すると0d3。つまり3度なので青色が正解でした。 case2. 項目Aは16進数表記でした！（0x110だったのです） 電卓でHEXに110を入力するとDECは272と表示されますね。1/2すると0d136。つまり136度なので赤色が正解でした。 接頭辞（接尾辞）の違いで同じ[ 110 ]でもここまで値に差が出てしまうのです。 エンディアンの罠 エンディアンの罠…16進数でのバイト順「byte order[※2]」のことで、下記3種類が存在します（なぜ１種類に統一されていないのかというと、所説あるようです）。 [※2] byte order：データは1byte(8bit)単位で記憶されるため、2byte以上の時に先頭からor末尾からのどちらから記憶していくかという順番。 ビッグエンディアン バイナリデータの先頭が頭になる方式。主な用途：TCP/IPプロトコルや、UNIX、モトローラ、Macintosh等。 例えば[ 0d1234 ]を電卓で変換するとHEXは[ 4D2 ]と表示されます。1バイト目が[ 04 ]、2バイト目が[ D2 ]で[ 0x04D2 ]です。 リトルエンディアン バイナリデータの末尾が頭になる方式。主な用途：Windows、USB、IntelやAMDのプロセッサ等。 先程の[ 0d1234 ]の場合、末尾からバイトをひっくり返した並びになるので[ 0xD204 ]になります。1バイト目が[ D2 ]、2バイト目が[ 04 ]ですね。 ※単純に末尾から数字を逆順にして02D4や2D40としないようにご注意を。私は最初の頃間違えました…）。 バイエンディアン ビッグ、リトルのどちらにもなる方式。主な用途：MIPS、ARMのCPU等。 10進数を4バイトの16進数にした時にbyte orderでどのような違いがあるかを表3に記載しました。 [ 00 00 00 01 ]はビッグエンディアンは0d1ですが、リトルエンディアンでは0d16777216です。10進数で考えると1と16777216では大きな差異になってしまいますね。 【テスト設計例2】 あなたは温度を示すアプリのテスト設計をすることになりました。詳細設計書には下記の記載があります。 「項目Bの16進数を10進数に変換したとき、その結果でフォント色を下記のようにする。 ・5000度以上であれば赤色、それ以外は青色とする」 項目Bの値は[ 0x121A ]でした。 16進数であることが判明しているので[ 0x121A ]を電卓で変換すると[ 0d4634 ]でした。 「4634度ね。5000度以上ではないから…期待値は青色ね！」 ところが、項目Bはリトルエンディアン表記でした。リトルエンディアンで[ 0x121A ]はビッグエンディアンにすると[ 0x1A12 ]で、変換すると[ 0d6674 ]。つまり6674度なので5000度以上となるため赤色が正解でした。 「全項目ビッグエンディアンで期待値算出してたよ…計算しなおさないと」ってことにならないように、私は16進数を見かけたら「ビッグエンディアンですか？リトルエンディアンですか？」と必ず設計前に確認するようにしています。 ※ちなみにエンディアンとは「ガリバー旅行記」で卵を尖った小さい方から食べる(little end)か、大きい方（big end)から食べるかで戦争をしている国のエピソードからきているそうです。 「こしあんか粒あんか」「頭からかしっぽからか」「タケノコかキノコか」みたいなものですね 小数点の罠1 [ 0xA.B ]と記載があった場合、[ 0xA. ]はそのまま[ 0d10. ]です。 「Bは10進数では11だから…0d10.11ね！」となりがちですが…16進数では0.1の位は1/16、0.01の位は1/256なので、0xBを10進数に変換（0d11）し、それを16で割ってください。11/16=0.6875で、正解は[ 0d10.6875 ]となります。 n進数で小数点以下の変換ができるサイトや、小数点第2位以下の計算についても記事がたくさんあるので興味のある方は是非調べてみてください。 小数点の罠2 現場や設計、プログラマにより小数点以下の扱いは四捨五入、切り捨て、切り上げなど仕様がさまざまです。 表4をご覧ください。B列は単純に0d100をA列の値で除算（=100/1 ~ =100/16）した値です。 C列はB列の値をround関数で四捨五入した値。 D列はC列の値を「=DEC2HEX（decemal→hexadecimal）」という関数で変換した16進数です。 E列はB列の値を「=DEC2HEX」で変換した16進数です。 赤背景の行は値が変わってしまいました。 【テスト設計例3】 温度を示すアプリのテスト設計をすることになりました。 詳細設計書には「項目Cの温度を1/2した値を16進数に変換し、項目Dの値とする」と記載されています。項目Cの値は[ 135度 ]です。 [ 0d135 / 2 ]は[ 0d67.5 ]ですね。 [ 0d67.5 ]を[ =DEC2HEX(67.5) ]すると[ 0x43 ]でした。 「じゃあ項目Dは [ 0x43 ]ね！」とテスト設計しました。 ところが… 項目Dは四捨五入で求める必要がありました。DEC2HEXという関数は小数点以下切り捨ての仕様となっています。 四捨五入や切り上げが必要な場合、round関数またはroundup関数をかませた後にDEC2HEXする必要があります。 この場合ですと次の手順になります。 135 / 2 = 67.5 を求める =round(67.5)で四捨五入し68にする =dec2hex(68)で16進数に変換し[ 0x44 ]を求める つまり項目Dは[ 0x43 ] ではなく [ 0x44 ]が正解でした。 「全項目切り捨てで期待値出してたよ…算出しなおさないと」ってことにならないように、私は小数を見かけたら「四捨五入ですか？切り捨て/切り上げですか？」と必ず設計前に確認するようにしています。 まとめ 以上が私がn進数を扱うときに注意しているポイントの紹介でした。 どんなことでも「学習レベルの知識」があっても「実務でやってみたら思っていたのと違った」とか「あの時勉強したのはこういうことだったのか！」という気づきがあると思います。もしこの先n進数を扱うことになったら「そういうえば昔、記事で読んだな…」と思い出してみてください。 この記事がこれからn進数を扱うみなさんのお役にたつことがあれば幸いです。 The post 実例から学ぶ n進数を扱うプロダクトのテスト設計で気をつけるべきポイント first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。 「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。 この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ 推論の形 を見ていきます。 ＜テストエンジニアのための論理スキル[実践編]　記事一覧＞ ※クリックで開きます 論理のかたち。推論とは ［全文公開中！］ 基本的な推論形式 前回「 “または”を使って推論する 」では、“または”という言葉(連言)を使った推論の形を取り上げました。 “または”を使って推論する｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、条件を表す言葉“ならば”(条件法)を用いた推論の形を見ていきます。 前回クイズ解答 問題(再掲) ※第3回の問題で、図版に誤りがございました（問3が間違っています）。 ご覧になった方を混乱させたことをお詫び申し上げます。 以下に正しい図を掲載します。 解答 問1 。「Pか、またはQ」に対して、一方の否定から他方の肯定を結論する、選言三段論法の妥当な形をしています。 問2 。一方の肯定から他方の否定を結論とする、選言三段論法の妥当でない形です。実行手順の問題とテスト環境の問題は両立し得る事象です。 問3 。ふたつのモードは「相互に切り替えて利用できる」ことから、同時には一方のみが有効と考えられます。排他的な“または”と言えるので、この推論は妥当です。 仮言三段論法　―　“ならば”を使って推論する “ならば”の性質と推論 こんなことを言われても―― 今日中にリリースがないなら、明日のテストは中止だ。 これだけでは明日のテストについてはなんとも判りません。 が、ここに「今日はリリースはないってよ」という情報が加わると、「明日のテストは中止だ」と断言してよさそうに思えてきます。 あるいは、「例の課題を解決できないなら、今日中のリリースはない」といった情報が加わると、「例の課題が解決できないなら、明日のテストは中止だ」という新たな主張が得られます。 “ならば”(条件法)は推論で大活躍をする論理の言葉で、考えを進めたり議論をしたりする際に、言葉を変えたり隠れたりして頻繁に現れます（この節にも2ヶ所隠れています）。 この言葉を使った推論のよい形・よくない形を理解しておきましょう。 “ならば”を使って、前提から結論を導く 前提1が仮言判断（“ならば”を用いた条件つきの主張）である推論を 仮言三段論法 といいます（文献によっては、条件三段論法とも）。 前提2にどんな文が来るかによって、 純粋仮言三段論法 と 混合仮言三段論法 があります(図4-1)。 図4-1 仮言三段論法 純粋 仮言三段論法(図4-1 上)： 前提2も仮言判断 。結論も仮言判断になる 混合 仮言三段論法(図4-1 下)： 前提2が断言判断 。結論は断言判断になる 混合仮言三段論法から説明します。 混合仮言三段論法 “ならば”と、断言を組み合わせる 前提1「PならばQ」に対する断言形式の主張を前提2で述べることで、結論を引き出します。 結論は断言判断 になります。 ふたつの形があります。 混合仮言三段論法・(1)肯定式(前件肯定) ひとつめは、前提1「PならばQ」に対して「P(前件)は成り立つよ」と言う形です(図4-2)。 ①PならばQ。 ②P。 従って、③Q。 図4-2 混合仮言三段論法・肯定式(前件肯定) ①「PならばQ」に対して、②「P(前件)が真」が加わると、③「Qは真」が結論として導けます。 この形は「 肯定式(Modus Ponens, MP) 」「 前件肯定 」 と呼ばれます（文献によっては構成式とも）。 「 論理のかたち。推論とは 」冒頭の例でいうと： 例： ①雨が降っているなら、Aさんは自宅で過ごす。 ②今日は雨だ。 だから、③今日、Aさんは自宅にいる。 混合仮言三段論法・否定式(後件否定) ふたつめは、「Q(後件)は成り立たないよ」と言う形です(図4-3)。 ①PならばQ。 ②Qではない。 従って、③Pではない。 図4-3 混合仮言三段論法・否定式(後件否定) ①「PならばQ」の対偶は、「QでないならばPではない」です。そして②「Q(後件)が偽（＝Qではない）」から、③「Pは偽（＝Pではない）」という結論が得られます。 この形は「 否定式(Modus Tollens, MT) 」「 後件否定 」と呼ばれます（文献によっては破壊式とも）。 例： ①雨が降っているなら、Aさんは自宅で過ごす。 ②今日、Aさんは自宅にいない。 だから、③今日は雨は降っていない。 推論の重要なツール 前件肯定、後件否定は、“ならば”(条件法)の意味/働きから出てくる、とても重要な推論の形です。 条件つきの主張から結論を引き出したり、考えや議論を進めたり、話の筋道を確かめたり見直したりするのに欠かせません。 対偶と併せてセットで憶えましょう。 純粋仮言三段論法 “ならば”を重ねる 前提1, 2とも“ならば”を用いた言明(仮言判断)で、ふたつの条件つき主張のつながりから結論を引き出します。 この形では、 結論も仮言判断 になります。 “基本形” 「 基本的な推論形式 」で紹介したものが基本的な形です(図4-4)。 ①PならばQ。 ②QならばR。 従って、③PならばR。 （前提1, 2の順序は替わっても問題ありません） 図4-4 純粋仮言三段論法の“基本形” 「PならばQ」の後件Qが別の主張「QならばR」の前件となって両者をつなぎ、「PならばR」という主張を導いています。 例： ①雨が降っているなら、Aさんは自宅で過ごす。 ②Aさんが自宅にいるなら、Aさんは趣味のギターに没頭する。 だから、③雨が降る日はAさんは自宅でギターを弾いている。 この基本的な形から、多くの推論の形が導出できます。 “ならば”をさらに重ねる 前提が3つ(以上)ある形は、込み入った主張の展開でよく見かけます。 ①PならばQ。②QならばR。（……）③RならばS。従って、③PならばS。 一見飛躍があるように感じられる主張も、間をつなぐ条件つき主張が隠れていて、それを解き明かしていくとこの形の推論が浮かび上がることがあります。 対偶を織り込む 前提から結論の間に対偶が活躍することもあります。例をふたつ挙げます。（頭に「？」が浮かんだら、P, Q, Rの関係を図に書いてみてください）。 ①PならばQ。②RならばQではない。従って、④PならばRではない。 ①QならばR。②QでないならばP。従って、④PでないならばR。 前件肯定や後件否定との“合わせ技” 仮言判断の連鎖の後に前件肯定が来て： ①PならばQ。②QならばR。（……）③P。従って、④R。 また、後件否定が来て： ①PならばQ。②QならばR。（……）③Rではない。従って、④Pではない。 といった、長めの混合仮言三段論法といった感じの推論も作れます。 前提を否定する結論が出てきたら！？ 時にはこんな形の推論も―― ①PならばQ。②QならばR。（……）③RならばPではない。従って、④PならばPではない。 「Pが成り立つなら～」から始まって結論が「Pは成り立たない」となったら 矛盾 であり、話の筋道に問題がある証拠です。 意図せずしてこういう状態に陥ったら推論を見直すことになりますが（前提の真偽や、条件法の前件・後件の関係を確かめましょう）、 「前提が間違っている」ことを示すためにこういう推論を立てることもあります。数学の 背理法 が有名ですね。 仮言三段論法・気をつけたい落とし穴(誤謬) 後件肯定、前件否定 「前件肯定」「後件否定」とよく似た言葉で、 「後件肯定」「前件否定」 があります。 これらは一般に 妥当でない形 です。違いに気をつけてください(図4-5, 4-6)。 後件肯定の誤謬(図4-5上) ：①PならばQ。②Q。従って、③P。 前件否定の誤謬(図4-5下) ：①PならばQ。②Pではない。従って、③Qではない。 図4-5 後件肯定の誤謬(上)と前件否定の誤謬(下) 「PならばQ」に対して、 後件肯定は「QならばP」という“逆” を主張しています。 前件否定は「PでないならばQではない」という“裏” を主張しています。元の主張が真でも、“逆”や“裏”は一般に真ではありません（QだからといってPであるとは限らないし、PでなくてもQである場合がある）(図4-6)。 図4-6 “ならば”と逆・裏・対偶 前提の仮言判断（条件つき主張）の内容に注意 仮言三段論法は“ならば”の意味・働きに依存しています。 もっともらしい主張と感じられるならなおさら、主張内容の真偽を吟味することが大切です。 前件、後件の真偽 前件と後件の関係性（つながりに必然性はあるか、関連しているか） クイズ 問1～問3の主張は妥当でしょうか。推論の形に着目して考えてください。（解答は次回に） 次回 「 基本的な推論形式 」で出てきた「両刀論法」を詳しく見ていきます。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 John Nolt, Dennis Rohatyn(著), 加地大介(訳) 『現代論理学 (Ⅰ)』 オーム社 1995 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 テストエンジニアのための論理スキル[実践編]  連載一覧 論理のかたち。推論とは  【連載初回、全文公開中】 基本的な推論形式 “または”を使って推論する The post “ならば”を使って推論する｜テストエンジニアのための論理スキル［実践編］ first appeared on Sqripts .