みなさんはじめまして、QAコンサルタントのぐっちです。 私はこれまで制御系エンジニアとして様々な案件に携わってきました。今回のブログでは、制御系開発とはどのような開発かというお話から自身が経験して学んだ開発での課題や対策を紹介したいと思います。 制御系開発とはどんなものか 制御系開発と組込み開発は、よく混合されますが、違う開発の種類になります。 制御系開発は具体的なモノを作るのではなく、モノを制御するという考え方がわかりやすいと思います。 車を自動的に目的地に運ぶための仕組みを作り出すシステム開発を制御系開発と考えることがイメージしやすいと考えます。運転手がいない自動車や、ロボットが物を掴む動作をする場合など、人が操作することなく、動作を制御するシステムを作るのがシステム開発の概要になります。 例えば、自動車に乗って高速道路を走っているとします。制御系開発では、自動車が速度を一定に保つように制御するシステムを作成します。もしその速度が目標値よりも速くなったら、ブレーキを軽くかけて速度を下げるよう指示し、目標値よりも遅くなったらアクセルを踏んで速度を上げるよう指示します。これにより、自動車は目標の速度をキープできるのです。 制御系開発は、自動車の他にも、洗濯機の水量調整、エアコンの温度調整、電車の自動運転など、さまざまな場面で活用されています。システムが一定の目標を達成するように「指示」を出す仕組みなので、効率的かつ安全な動作を実現することが可能です。 制御系開発は、私たちの生活の中で自動化や効率化を実現するために欠かせない技術なのです。 開発現場で苦労したこと 次に、実際の開発にて苦労したことを記載していきます。Web開発やアプリ開発とも重複する内容もありますが、主に苦労したことをピックアップして記載します。 ソフトウェアだけでなく、ハードウェアの知識も必要 制御系開発ではソフトウェアの知識だけでなく、ハードウェアの知識も必要になります。もちろん専門家ほどの知見は不要ですが、開発では、デバックボードを使用して、プログラムを流し込んでプログラムの動作確認を行います。 検証では、オシロスコープ ※1 やPLC ※2 などハードウェアを使用してプログラムを制御するテストを行ったりします。普段使い慣れていないものなので、最初使うときには慣れるまで時間がかかりました。 想定する仕様の複雑さ 制御系開発では、様々な条件で起動したり停止したりするため、複雑な仕様になりやすいです。細かな制御が必要であるため、数学的な計算式を使って制御を行う場合もあります。 そういった場合、なぜこの処理になっているのか、どの仕様でこのプログラムが動作しているか等を調べるのが困難な場合も多いです。 また、動作する環境は、自動車やセンサーのようなモノであるため、実際の動作を見ることは中々できません。エミュレータ等を使用し、仮想環境でプログラムを作成したりテストを行ったりします。そのため、使用するツール等の理解や習得も必要になります。 納期の厳しさ 納期についてはWeb開発やアプリ開発も同様になりますが、制御系開発ではモノ（ハードウェア）も含めて完成になります。今ではPCやスマートフォンは容易に準備できるものになるため、準備にそこまで時間が必要にはなりません。 しかし、自動車やセンサーなど動作環境を含めてリリースするとなると様々な準備が必要になります。よって、ソフトウェアの開発だけでなく、ハードウェアの準備や進捗にも気を配る必要があります。 課題に対する対策 上述した課題に対しての対策について以下に記載します。 ハードウェアの知識もしっかりつける 先述でも記載した通り、制御系開発では色々なハードウェアを使用して開発を行うことが多いのでソフトウェアの勉強だけを行っていれば解決できるものではありません。よって、各開発に使用するハードウェアの理解を深める必要があります。 そうすることにより、ハードウェアを含めた動作を意識することができるようになり、ソフトウェアだけでなくモノとして全体を含めた視点で開発に着手できるようになります。 そうすることによってソフトウェアの動作という観点だけでなく、システム全体を俯瞰して意識していなかったことに気付くようになります。 複雑なロジックを理解できる訓練をする 制御系開発だけでなくその他の開発でも同じことが言えますが、複雑な仕組みや仕様を理解するのは容易ではありません。私も最初は苦労をしましたが、なぜそのような計算式を使うのか、なぜそのタイミングで制御を行うのかという視点で物事を考えるとだんだんと理解できるようになり、仕様書に書かれている内容に対しても、問題があるところに指摘できるようになっていきました。その際に役に立ったのはロジカルシンキングという考え方です。ロジカルシンキングとは、物事を結論と根拠に分け、その論理的なつながりを捉えながら物事を理解する思考法になります。今では書籍や研修など様々な訓練方法がありますので、興味がある方はぜひ勉強いただくことをお勧めします。 全体を見据えたスケジュール管理を意識する 先述も述べたように制御系開発ではソフトウェアだけなく、ハードウェアも含めた開発になります。よって、従来であればソフトウェアのリリーススケジュールを考慮しておけば問題ないですが、制御系開発ではハードウェアのリリースも含めたスケジュール管理が必要になります。その分、課題管理やリスク管理もハードウェアを含めた管理が必要になりますので意識してスケジュール管理を行うようにしてください。 まとめ 今回は制御系開発で気を付けるべき内容や対策について記載させていただきました。ここに書いてある内容については、他の様々な開発にも流用できる考え方だと思います。 現在はQAコンサルタントとして業務に携わっておりますが、制御系開発によって得た全体を俯瞰して開発を進めていく経験やロジカルシンキング思考を用いてプロジェクトの課題の解決することで、最終的な成果物の品質の向上に繋がっていることを身をもって実感しております。 今後もプロジェクトを成功に導けるように日々スキルアップを目指して業務を遂行していきたいと考えております。 APPENDIX:用語の説明 ※1： オシロスコープ（Wikipedia） オシロスコープ (英: oscilloscope) は、入力した信号の電圧の変化を時間の関数として視覚的に表示する電気計器。表示される波形から、振幅・周波数・立ち上がり時間（英語版）・時間間隔などの値を得ることができる。昔のオシロスコープでは、これらの値を得るには画面に組み込まれた目盛りを使って波形を手動で読み取って計算する必要があったが、現在のオシロスコープはこれらの値を自動で計算して表示する。 ※2： PLC（Wikipedia） プログラマブルロジックコントローラ（英: programmable logic controller、PLC）は、リレー回路の代替装置として開発された制御装置である。プログラマブルコントローラとも呼ばれ、一般的にシーケンサ（三菱電機の商品名であるが登録商標ではない）とも呼ばれる。 The post プロジェクトを成功させる制御系開発の進め方：学んだ教訓と対策 first appeared on Sqripts .

こんにちは。みぞぐちです。 アジャイル開発のQAとして日々業務を行っています。 11/2に開催された JaSST’23 Kyushu にオンライン参加してきました。今回は「E2Eテストの自動化導入」や「継続的テスト」をテーマにした 『 テスト自動化から、 開発を支える継続的テストへ 』 というセッションについて、要点と感じたことをレポートしたいと思います。 セミナー概要 『 テスト自動化から、 開発を支える継続的テストへ 』 今回のセッションは、ある開発チームがテスト自動化の導入を皮切りに、ソフトウェア開発サイクル全体に段階的にテストを導入していき「 継続的テスト 」を実現するまでの進化の道のりについてお話しされていました。 【登壇者】 末村 拓也（すえむら たくや）さん オーティファイ株式会社 シニアテクニカルサポートエンジニア／テスト自動化スペシャリスト ちなみに「笑わせないと生きていけないタイプの人間なんですよ」とご自身でおっしゃっていた通り、70分の講演は面白くてあっという間でした。 資料は公開されていますので、興味のある方は覗いてみてください。 継続的テストに進化するまでの道のり これは末村さんが6年前にQAやソフトウェア開発に携わったときの話だそうです。 明日リリースするというリリース日程が差し迫っている状況のときに… 開発者 ：「QAテストしてください！」 QA ：「はい！」 QA ：「バグ見つかりました！」 開発者 ：「バグ直りました！」←リリース当日3時間前 QA ：「（え？こっからテストするの～？）」 みたいなことがとてもストレスだったということで、開発者の実装とQAのテストの間に何か見えない壁があってウォーターフォールに近いものが残っていたそうです。この苦しみの源泉は何なのかいろいろ勉強していくうちにDevOpsというのを知りました。 DevOpsとは DevOpsとは、Development（開発）とOperation（運用）を分けて仕事していたのを一緒にしよう、というシステム開発の流れを良くする意味で使われる造語で、それを下支えする技術や概念として継続的インテグレーションや継続的デリバリーという考え方が出てきたそうです。 出典： テスト自動化から開発を支える継続的テストへ （P.9） では、今回の主役とも言える「継続的テスト」とは何なのか。 出典： テスト自動化から開発を支える継続的テストへ （P.10） 上記図のように、継続的テストはすべての場所でテストできると言われています。 開発とQAの間にあった壁が苦しみの源泉でしたが、確かにこの八の字なら壁を取っ払えそうです。ということで、「ある開発チームのテストが継続的テストに進化するまでの道のり」がスタートしました。 クライマックステスト 出典： テスト自動化から開発を支える継続的テストへ （P.15） ある開発チームのお話です。1スプリント2週間で開発／テスト／リリースという流れで仕事をしていて「 一度にリリースする量が多い 」、「 駆け込みマージが多い 」、「 手戻りが多い 」という課題があり、QAの手動テストがボトルネックになっていました。手動テストを自動化したらリリース頻度を増やせるのではないか！ということで、まずはクライマックステストのソリューションとして E2Eテストの自動化 を導入しました。 （ちなみに「クライマックステスト」の名前はChatGPTに考えてもらったそうです。最後の方にどっかーーんとテストするの、何かいい名前ない？と聞いたら「クライマックスはどうでしょう」ということで名付け親になってもらったそうです。いい仕事しますね！） テスト自動化 出典： テスト自動化から開発を支える継続的テストへ （P.22） テスト自動化したらテスト実行速度は1/4～1/2まで短縮し、4時間だったテストは1～2時間になりました。 しかしここにも課題があり… 出典： テスト自動化から開発を支える継続的テストへ （P.25） E2Eテストの自動テストコードが古かったり、新機能追加に対応できていなかったりと、実際に動かしてみて初めて問題に気が付きました。 問題に気付くのが遅かった のです。テスト時間はテストコードのメンテナンス作業が追加発生してむしろ増えてしまいました。 実装の後にテスト工程が集中しているのが悪くて、これを開発中にE2Eテストを回したら、そのサイクルの中で問題にすぐに気付けるのではないか。 出典： テスト自動化から開発を支える継続的テストへ （P.32） ということで次のチャレンジです！ シフトレフト 出典： テスト自動化から開発を支える継続的テストへ （P.35） 今まで開発の後に集中していたテストを開発の途中にもっていこう、という シフトレフト を取り入れました。 開発中に開発者によってテストコードの実装／メンテナンスがされるので、 問題に気付くタイミングが早く なり、CIサイクルの中にE2Eテストを組み込めば自動的に実行されてリリース直前のQAの負荷軽減、コードフリーズ期間の短縮、リリースサイクルの短縮が可能となり、結果、「2週間スプリントを1週間に」、「2週に1回リリースを1週に1回に」改善していきました。 ただし、ここにも課題があり… 開発者たちにフラストレーション がありました。 「CIの実行時間が長くなった」 「UNITテストで充分なのにE2Eテストを書かないとダメなの？」 これは どのようなバグをどのように見つけるか、ということをチーム内で充分共有されていないのが原因 ということがわかり、課題がわかったので次のチャレンジです。 テストリアーキテクティング リアーキテクティングはリファクタリングと類義語で使われますが、リアーキテクティングは直訳すると再設計。テストリアーキテクティングは、今までE2Eテストに寄りすぎていたテストをもっといろんなテストレベルに寄せていこうというものになります。 出典： テスト自動化から開発を支える継続的テストへ （P.41） 左の図のアイスクリームコーンというアンチパターンから、右の図の実行時間が短く実行コストが少ない順に充実させたテストピラミッドのバランスにもっていこう、というのを 開発チーム内で共有しまずは合意 を取りました。 次にテストのバランスを考えてE2Eテストを減らし、同時にテストを削ってもカバレッジは保っていることを裏付けるためのカバレッジ計測を1週間に1回やって、このチームにとって一番最適なテストピラミッドのバランスを確立しました。 これによって、リリース頻度が週1回だったのをテストリアーキテクティングで週4回に増やすことができました。 ただここでも課題が… 品質について議論できていない のではないか…。 次のチャレンジです！ 継続的テスト 「 継続的テスト 」は作る前からリリースの後までずっとテストし続けるということです。 出典： テスト自動化から開発を支える継続的テストへ （P.56） 「 開発前 」 仕様を理解し、仕様の抜け漏れを減らす。つまりは開発～デプロイまでの必要なテストをリファインメントで計画を立てて合意（QA承認済）するため、自動テストが通ったらQAの判断を待たずに（QAは開発者をブロックせずに）デプロイできるようになります。 「 リリース前 」 未知の不具合を探るために、探索的テストをします。 「 リリース時（段階的ロールアウト） 」 ユーザーの反応を見るために一度にリリースしないでちょっとずつリリースしていく、段階的ロールアウトをします。 「 リリース後（GA（General Availability）） 」 全ユーザーに使ってもらい、GA（General Availability）＝ 監視を一つのテスト手段として使い、ユーザーがどんなふうに使っているかというのをテストします。 作る前からリリースの後までずっとテストし続ける「継続的テスト」をしたことにより、デプロイ頻度は週4回から毎日数回になりました！ さらにはチームの課題感も変わり、最初は開発プロセスの中の話ばかりしていたのが、どんなテストが必要か、自分たちがどういう価値をユーザーに提供できるかなど、気付けばチーム全体で 品質について議論できるように なっていました。 最後に末村さんは、「この通りにやれというわけではありません。この話をたたき台にして自分たちのチームでも話してみてください。チームの状況に応じたアプローチが必要です。」とおっしゃっていました。 確かにおっしゃる通り、この「継続的テスト」の取り組みは一つの事例で、全ての開発チームにそのまま適応できるものではなく、開発チームごとの課題やそれぞれの議論の結果があって、解決していくためのプロセスやヒントについてをこの講演から学ぶととらえるのが良さそうだと思いました。 感想 今回のセッションを聴いて、『品質を伴う「継続的テスト」を続けること』が重要だと思いました。ただただ「継続的テスト」をするのではなく、PO／開発者／QAそれぞれが「品質」マインドを持ち続けることでその先のユーザーへの価値提供につなげられると解釈しました。さらに時代と共にユーザーの求める価値が変化し続ける今だからこそ『品質を伴う「継続的テスト」を続けること』がマッチしているのだと思います。（ちなみに、今携わっている自身の開発チームはまさにこれを体現しているので講演を聴いた後、にんまりと幸せを噛みしめていました。） また、セッション内容とは別の観点で着目していたのは、今回一貫して段階的に体系立てて検証する進め方でした。末村さんがやっている「〇〇したことでXXが起こって、そこから出た課題、次のチャレンジ、成果をその都度丁寧に明らかにしていくサイクル」は本当に圧巻でした。これは日々の業務で意識している部分ではあるものの輪郭がぼやけてしまいがちなところでもあったので、自身の課題を見つめなおす講演にもなりました。さっそく明日からの仕事にこの学びを役立てていきたいと思います。 最後まで読んでいただき、ありがとうございました。 The post テスト自動化から、開発を支える継続的テストへ JaSST’23 Kyushu 参加レポート first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第12回目のテーマは、「リーンソフトウェア開発」です。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 リーンという思想 リーンソフトウェア開発は、リーン開発とも呼ばれています。 日本で生まれたトヨタ生産方式は、アメリカやヨーロッパのソフトウェア開発で活用・適用され、体系化されて日本に逆輸入された開発手法です。リーンの考えが、日本のソフトウェア産業に直結していかなかったのは、日本人として残念に思います。 リーンという言葉は、リーンスタートアップなど、現在、様々な書籍でも使われていますが、リーン開発自体はあまり話題にならないように感じています。どちらかというと不人気です。 その理由を考えてみると、リーン開発には、具体的なプラクティスが少なく、「22の思考ツール」と呼ばれるリーンの考え方（スクラムでも出てきたリーン思考）が、多く語られているからかもしれません。 リーン関係の書籍を読み解いていくと、リーン開発にはプラクティスがないのではなく、リーン思考をベースに現場に即したプラクティスを考えていきなさいというメッセージということが見えてきます。このあたりもスクラムととても似ています。 しかし、自分たちで考えるのは大切なことですが、読者を突き放したような言い方にも感じます。せっかくいい思想であっても、使われなければ意味がありません。せっかく、リーン思考、リーンの原則には、現在の開発でも通用するものがたくさんあるのに、このあたりはもったいないと思わざるを得ません。 リーン開発の本はこれまで3冊が日本語訳されています。もし、これからリーン開発を学ぶのであれば、廃盤になってしまいますが、『 リーン開発の本質 』がおすすめです。 この記事でも『リーン開発の本質』をベースに解説します。 リーンソフトウェアの7つの原則 リーンソフトウェアの7つの原則をみていきましょう。書籍『リーン開発の本質』を見ると、価値より原則が先に登場しています。 原則1： ムダをなくす ひとつめは「ムダをなくす」です。「ムダ」がカタカナなのは、リーンが海外からやってきた考え方だからでしょう。英語だと「Waste（無駄、浪費）」という言葉がありますが、トヨタの考えが尊重された結果、「無駄」が「ムダ」になり、その言葉自体が海外でも通じるようになりました。 トヨタ生産方式を源流とするリーン開発なので、ムダ取りは大切な原則でしょう。ムダを見つけ、ムダをなくすことで、顧客への価値提供を最短距離で行っていきます。また、ムダをなくすのは、さまざまなアジャイル開発手法でも取り入れられている考え方です。そう考えると、トヨタ生産方式はさまざまな開発手法に影響を与えたのだと言えます。 原則2： 品質を作り込む 2つ目は「品質を作り込む」です。 事後に欠陥を見つけるのではなく、最初から欠陥が入り込まないようにしていくこと。これを「作り込む」と表現しています。 ソフトウェアだと、作ったあとでも修正ができてしまうので、「作り込む」という意識を持ちにくい部分があるのかもしれません。しかし、トヨタ生産方式だと、生産物が車なので、欠陥を後で取り除けません。製品に欠陥が入り込むと、命の危険にもなります。 日本だと、ソフトウェアのテストは、作ったものをテストするのが主流です。しかもバグを出すと大騒ぎする文化なので、大量のテストを、手動で実行する現場も多いでしょう。トヨタ出身の人が言っていたこんな言葉があります。 すでにバグが埋め込まれているものをテストしてバグを取り除いても、品質がいいとは言えない。 バグを取り除くことに必死になるのではなく、バグそのものが埋め込まれない仕組みや方法を考える必要があります。そうしなければ、開発がバグを作り、テストで発見するという、非効率なもぐらたたきがずっと続いてしまいます。 「品質を作り込む」も、開発手法全般で大切にされている原則です。 原則3： 知識を作り出す 3つ目は「知識を作り出す」です。 ソフトウェア開発は知識創造のプロセスです。プロセスを運営しながら知識を生み出し、成果物だけでなくプロセス本体も改善していきます。 原則4： 決定を遅らせる 4つ目は「決定を遅らせる」です。 ソフトウェア開発において、最初にすべてを決めるのは不可能と言えます。なぜなら、未来を見通すのが難しいからです。 書籍には「ソフトウェアの詳細な設計は、コーディングの最中に行われるものである」とも書かれています。設計を詳細に書きすぎるとコードに近づいてしまいます。だから、あえて決定を遅らせて、コーディング中に設計していく・・・のもひとつの手かもしれません。 意思決定は素早く行うことも大切ですが、「決定を遅らせる」では、大切な意思決定を「あえて」先延ばしし、ぎりぎりまで情報やフィードバックを集めて、決定を行います。 原則5： 速く提供する 5つ目の原則は「速く提供する」です。ひとつめの「ムダをなくす」でもでてきた「速い価値提供」です。 スピードを強みとすることで、競合他社との競争に打ち勝ちます。これはリーンに限らず、アジャイル開発の本質とも言える内容です。 原則6： 人を尊重する 6つ目の原則は「人を尊重する」です。 書籍には「トヨタの製品開発システムの4つの基本理念のうち、3つまでが、製品開発プロセスに携わる人に関係している」とあります。ソフトウェア開発は人間中心の活動です。 さらに、トヨタ生産方式では、自動化を、ニンベンの付いた「自働化」という表現にします。人間を大切にしたトヨタ生産方式らしい表現だと思います。 原則7： 全体を最適化する 最後の原則は「全体を最適化する」です。 リーンではアイデアが生まれてリリースするまでの流れを「バリューストリーム」と捉えて改善していきます。バリューストリームは、日本語にすると価値の流れです。リーン開発ではバリューストリームの一部分ではなく、全体を最適化します。 全体を見ず、部分最適をしても、問題がどこかに移動してまた別の問題が生まれてしまいます。だから、全体を見ながら改善を行っていきます。これは制約理論という有名な理論でも語られています。 リーンソフトウェア開発の22の思考ツール 最後に、リーンソフトウェア開発の22の思考ツールを解説します。この思考ツールは、XPでいうプラクティスに似た立ち位置のものです。これらのツールは7つの原則に分類できます。 1. ムダをなくす ムダを認識する バリューストリームマッピング 価値の流れを図解し、流れる時間を計測して流れを短縮していく 2. 品質を作り込む 認知統一性 統一性を作り込む コンセプト統一性 統一性を作り込む リファクタリング テスティング 3. 知識を作り出す フィードバック イテレーション 同期 集合ベース開発 チーム開発 4. 決定を遅らせる オプション思考 最終責任時点 意思決定 5. 速く提供する プルシステム かんばんの考え方 待ち行列理論 リーンとは別の理論 遅れのコスト 6. 人を尊重する 自発的決定 モチベーション リーダーシップ 専門知識 7. 全体を最適化する 計測 契約 より詳細を知りたい場合は、書籍『 リーンソフトウエア開発 アジャイル開発を実践する22の方法 』をご確認ください。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス 第12回：リーンソフトウェア開発 The post 第12回 リーンソフトウェア開発 first appeared on Sqripts .

はじめまして！テストエンジニアの「大の字」です。 私はゲーム業界でテスターを経て、エンタープライズ業界のテストエンジニアになりました。 今回は、エンタープライズ業界に転身したことで気付くことが出来た「デバッグ」と「テスト」の違いについてご紹介したいと思います。 気付き 前職のゲーム業界では、「デバッグ」や「デバッガー」という言葉が「テスト」「テスター」と同じ意味で扱われていることが多く、私自身も「デバッグ」と「テスト」は同じ言葉の意味だと思っていました。 しかし、エンタープライズ業界でテストの知識を学ぶうちに2つの言葉はまったく異なる言葉の意味だと知りました。 今回はJSTQB認定テスト技術者資格のシラバスを通して、「デバッグ」「テスト」の意味や他にもよく誤解されやすい言葉「エラー」「故障」「欠陥」の意味を再確認してみることにしました。 デバッグとは？ 私は以前まで「デバッグ」は開発者がプログラムのバグを見つける行為だと、ざっくりとしたイメージで認識していました。 では、実際にはどのような意味かをJSTQBのシラバスで確認してみましょう。 デバッグは、故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動である。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ ふむふむ、なるほど！つまり、プログラム内に潜んでいる欠陥を見つけて、原因のプログラムコードをチェックして欠陥を取り除く行為自体が「デバッグ」という意味なんですね。 では、故障の原因である欠陥を取り除いた後、本当にその故障が無くなったかは確認しないのでしょうか？その答えは、これから紹介する「テスト」にありそうです。 テストとは？ 私は「テスト」といえば、テスト手順通りに実行して期待する結果と一致しているかどうかを確認する行為だと思っていました。では、正しい意味はどうでしょうか？JSTQBのシラバスを確認してみましょう。 テストは、実行することでソフトウェアに存在する欠陥に起因する故障を示すことができる JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ 「テスト」とは、欠陥が原因の故障が発生するかどうかを示すことができるんですね。また、故障の発生は確認できますが、その欠陥の原因が特定できないことも特徴と言えます。 では、その欠陥を「デバッグ」で取り除いた後、発生していた故障が修正されたことの確認は行わないのでしょうか？その問いには、再度シラバスの記載を見てみましょう。 テスト担当者が確認テストを実施し、修正により欠陥が解決したことを確認する。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.1.2 テストとデバッグ なるほど。「デバッグ」を行って修正後に「テスト」を行い、検出した欠陥が無くなったこともきちんと確認するんですね。 エラーとは？ 私は「エラー」といえば、プログラム内で誤った動作が発生することだと思っていました。 では、またまたJSTQBのシラバスで意味を確認してみましょう。 人間はエラー（誤り）を犯す。そのエラーがソースコードや他の関連する作業成果物の欠陥（フォールトまたはバグ）となる。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.2.3 エラー、欠陥、および故障 1 つの作業成果物で欠陥を発生させるエラーは、他の関連する作業成果物でも欠陥を発生させる可能性がある。 JSTQB-SyllabusFoundation_Version2018.J03 JSTQB-FL 1.2.3 エラー、欠陥、および故障 テスト業界での「エラー」の意味は、プログラム内だけではなく、ヒューマンエラーを含んだ意味なんですね。ソフトウェアのエラーに留まらず、テストを行う上で発生する人為的なミステイクを含む意味であることが分かりましたね。 次は「デバッグ」「テスト」「エラー」をより深く理解してもらうため、上記3つの中で使われている「故障」と「欠陥」という言葉の意味についてご紹介します！ 故障とは？ JSTQBのシラバスでは下記のような定義がされています。 コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること 「故障」とは、システムが期待する結果と異なる結果になることを意味するのですね。私の経験則上では1つの欠陥で複数の故障が発生することがある印象があります。「故障」を検出するための活動としてテストを行うので、イメージがしやすいですね。 欠陥とは？ JSTQBのシラバスでは下記のような定義がされています。 システムの要件や機能が実現できない原因になる不備や欠点 「欠陥」とは、要件や機能が満たせない「故障」の原因のことなんですね。また、テストによって「欠陥」が存在していることは示せますが、「欠陥」が存在しないことは証明できません。つまり、ソフトウェアに残存する未検出の欠陥数は減らせますが、「欠陥」が見つからないとしても残存する「欠陥」は無いとは言い切れないのが特徴です。 テストをもっと詳しく では、言葉の意味が分かったところで少しテストについて深掘りしていきたいと思います。 テストといえば、以前の私のようにソフトウェアの動作を確認して期待する結果が得られるかを確認するだけと認識されている方もいると思います。しかし、実はテストには下記のような様々な活動のプロセスが存在します。 「テスト計画」「テストのモニタリングとコントロール」「テスト分析」 「テスト設計」「テスト実装」「テスト実行」「テスト完了」 また、テストプロセスにはいくつかのメリットがあります。 プロセスを分けることで、各担当の作業範囲齟齬などのヒューマンエラーが予防できる プロセス毎にエキスパートな人員をアサインすることにより、作業の効率化を実現できる テストプロセスの中で問題点があった場合、どのプロセスに問題があったかを分析し、改善を続けることができる テストプロセスを段階的に行うことで、人為的なミスの防止や作業の効率化、各プロセスの改善等が可能になり、リスクの軽減にも繋がります。 まとめ 「デバッグ」と「テスト」の役割について、理解が深められたでしょうか。欠陥を取り除く「デバッグ」も大切ですが、「テスト」によって故障を検出することで欠陥があることが分かるため、「テスト」は必要不可欠な存在であり、ソフトウェア品質を保つための最後の砦であることがお分かりいただけたと思います。 また、エンタープライズ業界ではシステムの大規模化や複雑化、短納期化が日々進んできています。これらを実現するためにテストプロセスを上手く活用して、ヒューマンエラーの予防や作業の効率化、テストを改善していく仕組み作りが出来ることを今回学べました。 みなさんも今回を機会に各テストプロセスにどのような役割があるかを調べてみるのもいいかもしれませんね。 「/Sqripts」では、テストプロセスについても紹介しています。是非チェックしてみてください。 ・基本的なテストプロセス 基本的なテストプロセス ・テスト分析の重要性～テストを支える縁の下の力持ち～ テスト分析の重要性～テストを支える縁の下の力持ち～ ・テスト設計技法 テスト設計技法 The post テストとは何か？デバッグとは違うの？ first appeared on Sqripts .

本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。 みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 第2回となる今回は、プロジェクトマネージャーの役割や必要なスキル、心構えについてお伝えします。 連載第1回はこちら 【第1回】プロジェクトマネジメントとは何か？ ［連載初回全文公開中：Sqripts会員以外の方も全文お読みいただけます］ PM（プロジェクトマネージャー）とは プロジェクトマネージャーは「プロジェクト目標を達成することに責任をもつチームをリードするために、母体組織が任命する人物である」と定義されます。プロジェクトの成否に大きな影響を及ぼすものとして、PMの存在は第一に挙げられる要素であり、PMはあらゆる プロジェクトマネジメントの知識や技術、これまでの経験や個人の人間力を「総動員」させ、プロジェクトの目的・目標を期限までに達成し、プロジェクト完了の責任を持つ 存在です。 PMの主な役割 PMは プロジェクトの目的・目標を期限までに達成させる為に、プロジェクトマネジメントのプロセスを実行しマネジメント します。 プロジェクトマネジメントのプロセスは主に＜立上げ、計画、実行、監視・コントロール、終結＞の５つのプロセス群に分けられます。 「プロジェクトマネジメントのプロセス」が優れている点は「どの業種業態でも適用可能」である点にあります。ITでも製造業でもサービスでもあらゆる分野に適用できるのがプロジェクトマネジメントプロセスです。 一方でプロジェクト活動において生み出される「成果物自体を生み出すプロセス」は業種業態によって異なってきます。イベント企画のプロセスとダム建設のプロセスは明らかに違いますね。この成果物を生み出すプロセスを実行するのはチームメンバーであり、PMはこの「成果物を生み出すプロセスが（メンバーの活動により）円滑に進み、期日までに成果物が納品できるよう」に、 プロジェクトマネジメントのプロセスとアプローチを駆使してマネージメントする ことがその大きな役割です。 PMとしての役割に集中する 経験のあるみなさんは、この成果物自体を生み出すプロセス（＝現場・メンバーとしての活動）にとても精通されているのではないかと思います。また自らが手を出した方がスムーズに運ぶ場合もあるかもしれません。しかしプロジェクト成功に向ける上での定石という点では、先ずは 「このプロジェクトマネジメントのプロセス（＝PMとしての活動）」に集中してほしい と思います。 小規模プロジェクトや組織の状態によっては、プロジェクトマネージャーをしながら「メンバーの役割も兼任する」ことが少なく有りません。例えばシステム開発のPMとして活動しながら、同時にシステム開発自体にもエンジニアとしての役割を持つような場合です。もしもこのように兼務する場合には「自分の活動のどれがPMとしての役割で、どれがメンバーの役割なのかを意識」して活動することが大切です。どうしてもメンバーとしての活動に時間を割かれる、マネジメントに必要な活動や時間が充てられない、という事にならないよう注意しましょう。 PMの活動と影響範囲 以下はプロジェクトマネジメント専門職の価値と貢献を示すPM独自の活動とされます。 プロジェクト目標とステークホルダーの期待に応えられるよう、プロジェクトチームを導くこと 利用可能な資源と競合する制約条件とのバランスを維持すること スポンサー、チーム、メンバ、その他のステークホルダー間の子ミュウニケーションをはかること PMへの期待と責任の拡大 最近ではPMがビジネスアナリシス（BA）やビジネスケースの作成、プロジェクトのためのポートフォリオマネジメント作成などへの関与が求められるシーンがあります。ビジネスケースとはプロジェクトの「立ち上げ前」にプロジェクトスポンサーなどにより作成され、プロジェクトの立ち上げ理由や目標を設定します。これらの活動に早くからプロジェクトマネージャーが参加し、評価や分析、目標推進方法や提案に関与することで、プロジェクトの成功角度を高めてその後のプロジェクト活動を円滑にするといった期待が込められています。また同じようにプロジェクトベネフィットの実現に向けて、プロジェクト活動後の各種対応へも関与することがあります。プロジェクトマネージャーの役割、その期待は組織やプロジェクト毎に異なりその活動もテーラリング ※ されますが、上記のような 期待に臨機応変に応えること が求められています。 ※テーラリング（tailoring） ：直訳では「仕立て」、プロジェクトマネジメントにおいてはプロジェクトマネジメントの知識や技法等を「プロジェクトに合わせて適切に調整して適応する」ことを意味します。この対応を洋服の仕立てに見立てテーラリングと呼びます。 プロジェクトマネジメントの成功指標 プロジェクトマネジメントにおける成功判断は、伝統的にQCD（品質・コスト・納期）の達成が基準とされていましたが、昨今はそれだけではステークホルダーの満足を得られなくなっています。「QCDS目標を達成したのに、なぜプロジェクトが成功と言えないのか、評価されないのか」という状況に陥らないよう、事前にプロジェクト目標等に成功指標や達成事項を明確にして記録するなどして合意を得ておくこともPMとしての重要な活動となっています。（従来のQCD評価は全体の30％に過ぎないとも言われます） 記載しておくとよい達成事項例） 財務指標や非財務指標の達成 組織移行の完了 ステークホルダーの満足 顧客やエンドユーザーからの受け入れ 組織や現場への成果物の統合 ガバナンス基準の充足　など PMに必要とされるスキルとは？ 具体的にPMにはどのようなスキルが求められるのでしょうか。プロジェクト活動に必要な知識や経験の適用、チームを導くリーダーシップ…など、PMに求められるスキルは多様で切り口は数多く存在します。そこで今回はPMIが提唱する「PMIタレント・トライアングル」を紹介します。 タレント・トライアングルとは、効果的なプロジェクトマネジメントを実施する上で必要とされる３つのスキルセットです。これらのスキルを備え、トライアングルの名の通り「バランスよく発揮」することがプロジェクトの成功に効果的だとされています。 Ways of Working Business Acumen Power Skills Ways of Working（働き方、仕事の進め方） 「仕事（プロジェクトなど）を成し遂げるため」に さまざまな方法とアプローチ（予測型、アジャイル、デザイン思考、あるいはまだ開発されていない新しい手法）を駆使して成果を上げるスキル を指します。 その為PMは多様な働き方や仕事の進め方などを経験・習得すること、またそれらを適切なタイミングで活用させることが求められます。 Business Acumen（ビジネス洞察力） 組織や業界におけるマクロとミクロの影響力を理解し、適切な意思決定を行うための機能またはドメイン固有の知識を持つ ことを指します。効果的に意思決定を行い、自分たちのプロジェクトが組織全体の戦略やグローバルなトレンドなどの全体像とどのように「整合」しているかを理解できるスキルが求められます。 Power Skills（パワースキル）とは 協調的リーダーシップ、コミュニケーション、革新的マインドセット、目的志向、共感力などの対人関係スキル を指します。 プロジェクトやチームに対するリーダーシップはもちろんのこと、「協調的」や「共感力」といった対人関係スキルを発揮してステークホルダーへ関与し、彼らに影響力を維持が求められています。 いかがでしょうか？タレント・トライアングルに示される要求スキルからもPMへの期待、ビジネス戦略とその達成にとって大きな役割を持つことがわかりますね。このほかにもみなさんがプロジェクトに参加する中で、先輩PMの振る舞いなどを見て「自分だったらこうする」「次のプロジェクトならこうできる」という発想から自身のPM像とスキルセットのイメージを膨らませてみてください。 PMとして大切にしてほしいこと 人間性こそプロジェクトの推進力 いくら知識や技術、経験があっても人間性が適切でなければリーダシップを発揮しプロジェクトを円滑に進めることは困難です。 プロジェクトは多くの人と共に団結して目的・目標の達成を目指します。その為、メンバが「一緒にプロジェクトを進めたい」「この人にならプロジェクトを任せられる」と思われるような存在でなくてはなりません。技術と知識という基礎力に加え、その人間性でリーダーシップを発揮しプロジェクトを円滑に進めていきましょう。 management by walking around MBWA(Management By Walking Around)とは「歩きまわるマネジメント」つまり「マネージャーが現場を歩いてマネージメントする」ということです。「席に座って報告を待っているだけ」「定例ミーティングの場でだけ情報収集する」といったマネージメントではなく「自ら情報を取りに行く(pull)」スタイルです。対話をすること、対話の機会を増やすこと、自らその空気と場を醸成すること。メンバーはその行動や空気を汲み取り、自然と安心感やパフォーマンスの変化を呼び起こすはずです。ぜひ意識してみてください。 「自己流PM」に陥らない為に 「自己流のPM」は自分の強みを中心に、伸ばせる範囲に手を伸ばしていきます。それも決して悪くはありませんが「一流のPM」はどうかというと、プロダクトやプロジェクトの全体像を理解した上で、自分がやるべき仕事を担いながら、自分ひとりでは手の届かない仕事を適切にチームに委任するなどします。大切なのはバランスと意識です。 安易に自己流に走り「独走」しないよう、ご自身がもつ特性・要素と伸ばしていくべき方向を意識していくことからはじめましょう。 誰よりも目的・目標の達成にこだわりを持つ PMはプロジェクトの目的・目標を期限までに達成し、プロジェクト完了の責任を負う存在だとお話しました。しかし実際にプロジェクトを実行すると、おそらく計画通りに行かないことが多々発生するはずです。前提や制約条件、発生する困難に対処しながらプロジェクトを推進することは簡単ではありませんが、だからと言ってPMが簡単に諦めたり「このぐらいでいいか」と安易な妥協をしてはいけません。PMはできればチームで最も「目的や目標にこだわる思考」を持ってください。その思考が、どうすれば目的・目標が達成できるだろうか？という行動を呼び起こしチームを導きます。 さいごに プロジェクトの成功に大きく関わるPMとその活動。プロジェクトにおいて非常に重要な存在であるからこそ、その役割や仕事内容、求められるスキルや素養は多岐にわたります。PMはよく指揮者などにも例えられますが、様々な知識をフル活用し、方向性を示し、柔軟性を持って、繊細に、時に大胆にプロジェクトをまとめ上げていく様子は、心技体バランスを持った「総合格闘家」という方がピンとくる気がします。みなさんもぜひPMとしての「筋肉」をさらに鍛えて、プロジェクトを支えていきましょう！ 今回は、PMの役割や期待されるスキルセットなどについて考えてみました。 次回は、「苦手な活動、よくわからない」と言われることも多い「ステークホルダーマネジメント」を、具体的な手法も交えて学んでいきましょう。 連載一覧 【第1回】プロジェクトマネジメントとは何か？ The post 【第2回】プロジェクトマネージャーの役割とは？ first appeared on Sqripts .

こんにちは！エンジニアのぱやぴです！ 全国高等専門学校プログラミングコンテスト(以下、高専プロコン)の第34回福井大会が2023年10月14日〜10月15日に開催されました。今回は私の会社AGESTが協賛することとなり、私もメンバーとして参加してきました。 私自身、高専プロコンのことをよく知らなかったのですが、実際に参加してみて、学生の皆さんの技術力と熱い想いにとても刺激を受けましたので、その様子をお届けしたいと思います。 高専プロコンとは？ 全国の高等専門学校の学生がアイデアや技術力を競う大会です。 「課題」「自由」「競技」の3部門で開催されています。 以下公式HPです。 全国高専プログラミングコンテスト 公式サイト 第34回福井大会(2023) 課題部門 課題部門は2年に1度テーマが変わり、そのテーマに沿った作品を開発し最も優れたシステムを決める部門になります。今回は昨年に引き続き「オンラインで生み出す新しい楽しみ」というテーマでした。 将棋やカルタなどオンラインで楽しめるゲームを開発しているチームや、普段の活動や、ゲームなどをみんなでオンラインで楽しめるように考えられた作品、音楽などをオンラインでより楽しめるような工夫をしている作品などが多く出ていました。 自由部門 自由部門は課題部門とは違い自分たちが困っていることや、関心のあることなど自由なテーマで独創的な作品を開発し、最も優れたシステムを決める部門になります。 学生寮の洗濯管理についてや、アクリル廃材の再利用、高齢者の服薬管理など身近な問題から社会問題など幅広い問題に対処する作品から、音楽やアートなどのユニークな視点での作品が多く出されていました！ 競技部門 競技部門は与えられたルールに沿ってプログラムを作成し、そのプログラムを用いてゲームを行いチーム対抗戦を行う部門になります。 今回は「決戦！n乗谷城」というテーマで行われており、2チーム対戦型の陣取りゲームでした。静かに競技が進んでいくなか、出場している学生さん等の真剣な表情から緊張感が伝わり、熱い戦いが繰り広げられていました！ 会場の様子 今回の会場は福井県鯖江市の「サンドーム福井」という場所でした。 特徴的な外装の建物で、カッコよかったです！！ 内部では学生さん等が、自分のような企業の方や一般の参加者さん等に説明してくれました。 学生さん等はみんな自分たちの作品について熱く説明しており、聞いていると学生さん等のフレッシュさや熱量、作品に対しての自信が伝わってきてとても素晴らしかったです！ また、使っている技術やテーマを決めたきっかけ、デザインなど質問をするとそれぞれ担当の人が回答を返してくれて「なるほど…すごい…」となり続けながら説明を聞いていました！ 競技部門も熱い戦いが繰り広げられていました！次回参加するできたらもっとルールを最初から把握し、より熱く観戦をしたいと思いました！ 個人的に印象的だったもの 全部の作品を体験できたわけではなかったのですが、自分が体験した中で印象的だったものを2つ紹介したいと思います。 VibraSymphony -全ての人にリアルなVR体験を- こちらは石川県の石川高専の自由部門の作品です。 視覚・聴覚のみでしか体験できなかったVRライブに振動するデバイスを取り入れ、臨場感を向上させるという目的の作品でした。 胸部・腹部に振動するスマートフォンを入れたベスト、振動デバイスを入れた靴を着用し、VRライブを体験させていただきました。振動が本当にライブ会場の音の振動を感じているようで本当にその場でライブの音が鳴っているような感覚になりました。 作品の完成度も学生さん等の協力して説明をしてくれたところも非常に素晴らしいと思いました！ Learn Mate 学生の学生による学生のための連絡アプリ こちらは福岡県の有明高専の課題部門の作品です。 学生同士の掲示板、先生との匿名のチャット、ToDoリストや時間割など学生生活を送るにあたって欲しいものがたくさん入っている作品でした。実際に困っていることやこうあったらいいなという学生目線で作られており、自分も学生の時にこのような仕組みがあればな…と思いました！ 先生へ質問をする抵抗軽減のために匿名にしたり、匿名でも悪戯等ができないようにしていたりなど、使用時の想定が細かくされていて素晴らしかったです！ AGEST企業賞 AGEST企業賞を授与したのは福岡県の久留米高専の自由部門「SeQuick－気軽な学習ゲームで、セキュリティ人材を増やそう－」でした！おめでとうございます！ SeQuick－気軽な学習ゲームで、セキュリティ人材を増やそう－ セキュリティ人材の不足を課題としてゲーム形式で楽しく継続的にセキュリティの学習を行う目的の作品でした。非常にセキュリティを学ぶのに効果的であり、会社の研修等でこのようなシステムがあれば、効果的に楽しくセキュリティについて学ぶことができると思いました！ 感想 まず、チームでテーマを決めてみんなで協力して作成をやりとげたということ本当に尊敬します！ また、タイトルにもありますが「熱を浴びた！」と感じました。エンジニアとして、ものづくりをしているものとしてその熱に感動し、自分も頑張ろうと思えました！ また、今回参加している中で企業紹介等を行う機会もあり、弊社が専門としている品質の話題など今回の作品作りのなかで共感してもらえる部分や興味を持って聞いてくれる学生さんが多く、改めて弊社の領域について自信を持つことができました！ 最後に これからのITを引っ張っていくであろう学生さん等と交流できたこと、非常に貴重な体験をさせていただきました！ また、学生さん等のフレッシュさやものづくりへの熱量、チームメンバーと協力しているところをみて非常にエネルギーをもらえました！ 参加した皆さん、お疲れ様でした！ ここまで読んでいただきありがとうございます。 The post 第34回高専プロコンで感じた未来のエンジニアの熱量と創造力 first appeared on Sqripts .

こんにちは。 エンジニアの nobushi です。 RDBが必要な規模のデータを扱うWebアプリケーションを構築する場合、多少なりとも「検索」機能が求められるものだと思います。 しかし、この「検索」機能、要求事項の幅が非常に大きく、場合によっては実現がかなり難しいと思われることもよくあるんじゃ無いでしょうか。 「全文検索」はその代表とも思われるもので、機能自体はとてもメジャーなんですが、RDBだけでできることはそんなに多くありません。 そこで Elasticsearch のような全文検索エンジンを活用するケースも多いと思います。 ただその場合、データ更新をRDB、Elasticsearchの両方に対して行う必要があり、何かと煩雑になりがちです。 PGSync は PostgreSQL とElasticsearchの同期ツールで、PostgreSQLのデータ変更を即時にElasticsearchに反映してくれます。 そのため、アプリケーションではElasticsearchへのデータ更新を行う必要がなく、コードがスッキリします。 今回は簡単にPGSyncの導入をしてみたいと思います。 導入 docker-compose が使える環境で、任意のディレクトリに以下のファイルを配置して / db/ initdb.sh postgresql.conf pgsync/ Dockerfile entrypoint.sh schema.json docker-compose.yml 配置したディレクトリで起動してください。 docker compose up -d docker-compose.yml services: pgsync: build: context: ./pgsync environment: PG_HOST: db PG_USER: postgres PG_PASSWORD: hoge ELASTICSEARCH_HOST: elasticsearch depends_on: db: condition: service_healthy elasticsearch: condition: service_healthy db: image: postgres:16.0 environment: - POSTGRES_PASSWORD=hoge command: >- -c "config_file=/etc/postgresql/postgresql.conf" volumes: - ./db/postgresql.conf:/etc/postgresql/postgresql.conf - ./db/initdb.sh:/docker-entrypoint-initdb.d/initdb.sh healthcheck: test: ["CMD", "pg_isready", "-U", "postgres"] pgadmin: image: dpage/pgadmin4:7.7 environment: - PGADMIN_DEFAULT_EMAIL=johndoe@example.com - PGADMIN_DEFAULT_PASSWORD=hoge ports: - 50080:80 elasticsearch_prepare: image: bash privileged: true user: root command: ["sysctl", "-w", "vm.max_map_count=262144"] elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.10.2 depends_on: elasticsearch_prepare: condition: service_completed_successfully environment: discovery.type: single-node xpack.security.enabled: "false" ES_JAVA_OPTS: -Xms1g -Xmx1g mem_limit: 2g healthcheck: test: ["CMD", "curl", "<http://localhost:9200>"] interval: 1s retries: 180 kibana: image: docker.elastic.co/kibana/kibana:8.10.2 environment: - ELASTICSEARCH_URL=http://elasticsearch:9200 depends_on: elasticsearch: condition: service_healthy healthcheck: test: ["CMD", "curl", "<http://localhost:5601>"] ports: - 55601:5601 PostgreSQL、Elasticsearchのインスタンスと、PGSyncのインスタンスを配置しています。 またPostgreSQL、ElasticsearchそれぞれのViewerとしてpgAdmin、Kibanaを配置しています。 db/initdb.sh #!/bin/bash -xeu set -o pipefail psql -v ON_ERROR_STOP=1 <<- _EOT_ CREATE TABLE IF NOT EXISTS public.sample (id integer PRIMARY KEY, value text); _EOT_ db/postgresql.conf include = '/var/lib/postgresql/data/postgresql.conf' wal_level = logical max_replication_slots = 10 pgsync/Dockerfile FROM python:3.11.5-alpine3.18 RUN apk update --no-cache &&\\ apk add --no-cache redis RUN pip install pgsync==2.5.0 COPY entrypoint.sh . COPY schema.json . ENTRYPOINT ["sh"] CMD ["./entrypoint.sh"] pgsync/entrypoint.sh #!/bin/sh -xeu set -o pipefail redis-server --daemonize yes bootstrap --config schema.json pgsync --config schema.json --daemon pgsync/schema.json [ { "database": "postgres", "nodes": { "table": "sample" } } ] PGSyncの設定 PGSyncはPythonのアプリケーションです。 上記 PGSyncサーバーの構築 ではPythonのコンテナイメージをベースにしています。 また、 Redis が必須なのでRedisも組み込んでます。 起動スクリプト ではRedisサーバーをバックグラウンド起動した後に以下のコマンドでPGSyncを起動しています。 bootstrap --config schema.json pgsync --config schema.json --daemon それぞれPGSyncの前準備、起動のコマンドです。 schema.json を引数として渡しています。 schema.jsonはPGSyncの対象テーブル等の設定を行います。 今回は最低限の設定として対象DBを postgres 、テーブルを sample としています。 この設定だと対象テーブルの全カラムをElasticsearchに同期することになります。 今回は割愛しますが、schema設定では対象のカラムを限定したり、スクリプトで値を加工したりと自由度は高いです。 動作検証 ではpgAdminとKibanaで確認してみます。 pgAdminへのアクセスは上記の docker-compose の通りであれば http://127.0.0.1:50080 で、 KibanaのDevToolへは http://127.0.0.1:55601/app/dev_tools#/console でアクセス可能なはずです。 pgAdminへのlogin http://127.0.0.1:50080 にアクセスするとログイン画面が表示されるので docker-compose の環境変数で設定した以下のメールアドレス、パスワードでログインします。 johndoe@example.com / hoge pgAdminからDBへの接続 ログインしたらDBサーバーへの接続を追加します。 General / Name Connection / Host name Connection / Username Connection / Password db db postgres hoge この段階では sample テーブルは空です。 KibanaでElasticsearchの確認 http://127.0.0.1:55601/app/dev_tools#/console にアクセスするとKibanaのDevToolコンソールが表示されるので GET /postgres/_search と入力して postgres インデックスの内容を表示します。 この時点では sample テーブルか空なのでElasticsearchのインデックスも空です。 PGSyncの動作確認 では、PGSyncが動作することを確認します。 pgAdminから sample テーブルにデータを追加します。 INSERT INTO public.sample VALUES (1, 'value1') 追加した後で、再度KibanaでElasticsearchを確認します。 無事、Elasticsearchにデータが同期されていることがわかります。 所感 PGSyncによってPostgreSQLとElasticsearchの両方をアトミックに更新する必要がなくなるという点で、 利点は非常に大きいと思います。 使い方も難しくなく、また、Pythonのスクリプトが設定できるので自由度もかなり高いです。 Elasticsearchを使用する際には検討してはいかがでしょう。 The post PostgreSQLとElasticsearchの同期ツールPGSyncを使ってみた first appeared on Sqripts .

TestArchitectは2023年夏にモバイル端末（iOS/Android）上で動作するアプリケーションを対象に機能テストが可能な「TestArchitect for Mobile」をリリースしました。モバイル端末を自動化することでWindowsアプリケーション、Webアプリケーションを1つの自動化ツールで制御することができるようになりました。 しかしTestArchitectはモバイル対応ができることだけが優れている点ではありません。TestArchitectは複数プラットホームの対応以外にもキーワード駆動型での簡単なスクリプトの作成、部分一致での画像比較、仕様変更への強さなど他の自動化ツールに無い特徴がいくつもあるため、実際に使ってみてどのようなものなのか検証してみました。 参考： TestArchitectの概要 TestArchitectの特徴 1. キーワード駆動型で複雑な処理もエクセルライクにスクリプト作成できる TestArchitectはキーワード駆動型でエクセルライクにスクリプト作成ができるため作りやすく読みやすいメリットがあります。他の自動化ツールでも簡単にスクリプトが作成できることを売りにしている自動化ツールがありますが、そういった自動化ツールでは簡単な処理だけ簡単に自動化できますが、複雑な処理になるとプログラム技術が必要になる場合が多いです。 　　　　　　　　　　　 TestArchitectは一貫して複雑な処理もキーワード駆動型で自動化できる点が他の自動化ツールと異なる点です。このようにキーワード駆動型を使って簡単に自動化できることで自動化習熟のハードルが下がる点がTestArchitectの良さです。自動テストの現場の問題としてテスト技術者で自動テストのアサインを検討している際にプログラム技術を持ち合わせたテスト技術者を揃えることが難しく、自動化担当者のアサインに困ることがあります。しかしキーワード駆動型を作ったTestArchitectではそういった問題の解消ができます。 TestArchitectはプログラム技術が無くてもスクリプト作成ができるため、数週間ツールを使えば現場で使えるレベルになることができます。私の考えですが自動テストは、テストを熟知しているテスト技術者が自動化担当者になることが良いと考えているため簡単に使えるTestArchitectはテスト技術者にとっても良いツールです。テスト技術者がスキルアップのため、自動テストの技術を身に着けてみたい方はTestArchitectを一度使ってみてはどうでしょうか？ 自動化経験のないテスト技術者にとってスキルアップのチャンスです。 2. 複数プラットホームで自動化ができる TestArchitectは今回対応されたモバイルの他、Windowsアプリ、ブラウザと異なるプラットホームを1つの自動化ツールで自動化することができます。そのためエクセルに登録された情報をブラウザで登録し、PCから送付したメールをスマホで確認するといった複数プラットホームを跨いだ操作も可能です。 初めて自動化ツールを選ぶ際にインターネットで良い評価の自動化ツールを選んでも、自分が自動化したい対象システムにとって必ずしも良い自動化ツールだと限りません。自動化の目的が明確でなければ、どの自動化ツールを選んでよいか分からなくなります。そういった自動化ツールに何が必要かを把握していない場合でも、TestArchitectの自動化できるプラットホームと充実したアクション数があれば、幅広い処理が自動化でき自動化することに困ることはないと言っても過言ではありません。 同じ会社でTestArchitectを使っているプロジェクトがあれば、一度借りて試してみてはどうでしょうか？自動化できることがわかるかもしれません。無料のTeam版もあるので気軽にダウンロードしてお試しください。 3. 仕様変更に強い構成 TestArchitectはスクリプト作成する際に座標指定を行わないため仕様変更に強いというメリットがあります。 座標指定を行う場合ではオブジェクトの位置変更があるとスクリプトの修正が必要になりますが、TestArchitectではインターフェース登録を行います。オブジェクトをTestArchitect内に登録し、その登録名を各スクリプトで呼出して使うためにオブジェクトのIDなどに変更があった場合にもインターフェースを取り直すことで、スクリプトに変更は発生しません。 　　　　　　　　　 オブジェクトのIDなどをスクリプトで設定して使う自動化ツールは、IDなどが変わってしまうとそのオブジェクトを使ったスクリプト全てに修正が発生することになります。こういったメンテナンス効率でTestArchitectは優れています。 インターフェースも簡単に登録することができるため、特に使いこなすことは特別な技術は必要ありません。 また共通関数も簡単に作成することができるため、複数のスクリプトで使用する同じ処理は１つの共通関数を呼出して使用できます。仕様変更があった場合にはその呼び出し元の関数を修正すれば仕様変更の対応が可能になります。 インターフェース登録と共通関数を使うことでメンテナンス効率を高めることができるため、TestArchitectは仕様変更に強い自動化ツールです。 4. ハーネス機能であらゆる対象を自動化できる Java、C#、Pythonで作ったプログラムを取り込み、TestArchitectで呼出して使うことができる機能があります。 この機能を使うことで通常TestArchitectで制御できない処理もハーネス機能を使うことで自動化することが可能になります。これまで諦めていた自動化もTestArchitectなら自動化できるかもしれません。 またハーネス機能を使えばRaspberry Piを使った組込み系製品の制御も可能になります。 組込み系製品の自動テストは組込み系製品を自動化するためのツールを作ることが技術的なハードルが高く自動化の実績が少ないですが、TestArchitectのハーネス機能を使うことでRaspberry Piを使い組込み系製品を自動化することが可能になります。Raspberry Piと連携できるハーネス機能と幅広いプラットホームを自動化できるTestArchitectを使えば、複数のシミュレータ機器を使ったIoT機器の自動化も可能になります。 他の自動化ツールでも工夫しシミュレータなど外部機能と連携することで、同様の幅広い機能で自動化ができますがこのやり方では大きな問題が発生します。1つの自動化ツールで複数の外部機能と連携する場合、構造が複雑になり実行エラーが発生した場合のエラー原因の特定が困難になります。運用担当者は必ずしもスクリプト作成者ではないため、自動化システムの構造を詳しく理解していない場合が多く、問題が発生した際に複雑な構造では原因特定が難しく実運用に問題が出ることが出てしまいます。 一方、TestArchitectは全ての機能を１つのツールで制御するため構造が複雑にならず、１つのツールのログからエラーを特定することが可能になります。自動化できる幅が広がるためのハーネス機能の特徴ですが、1つの自動化ツールで複数のシミュレータなどの外部機能と連携した自動化対象の構造を簡素化できるという特徴もあります。 5. スクリプトの構成が整理しやすい TestArchitectではテストモジュールには役割別に4つの区分が準備されています。 それぞれの区分で実行する処理を分けることで、可読性が高まり担当者が抜けたことでメンテナンスができなくなり自動テストの運用が止まってしまう可能性は低くなります。もともとキーワード駆動型で作りやすく理解しやすい自動化ツールのため、４つの区分があることでよりわかりやすく使いやすい自動化ツールになります。その区分に合わせてスクリプト作成するだけでコーディング規約に合わせたような一定の品質のコーディングができます。 6. 高度な画像判定ができる 一般的な自動化ツールでは画像一致の自動テストは実用面ではあまり使い勝手がよくありません。 その理由は画像判定をピクセル単位の一致で行っているため、誤判定が多いためです。 しかしTestArchitectはKey-Pointを用いて抽出した特異点と一致するものを画像内にあるか判定することができます。そのため完全一致ではなく部分一致での判定が可能です。デジタルカメラで取得した画像を使った画像判定を行うと少しの位置のずれ、画像ノイズが入ることから完全一致では判定は不可能です。 その点Key-Point技術を用いた画像判定を行うとデジタルカメラで取得した画像の一致も可能になります。デジタルカメラでの確認が可能になることから、組込み系製品でのテストにも使うことができます。 　　　　　　　　 画像チェックの自動化はこれまでオブジェクト認識ができなかったときの最後の手段として使っていましたが、部分一致が可能になると使い方が変わるため自動化の幅が広がります。 7. 自動化ツールのライセンス価格が非常に安い 自動化ツールの購入を検討する場合、重要視するポイントは自動化ツールの価格ではないでしょうか。 社内の予算を通すには価格の高い自動化ツールでは、苦労が予想されます。やっと予算を通してもそれが現場で使えなければ、大きな問題になります。 しかしTestArchitectは他に自動化ツールと比べても価格が安く、実行するだけの「Run Only」であれば年間9万3千円で使えます。スクリプト作成・編集可能な「Enterprise」でも年間44万9千円で使うことができます。 他の自動化ツールと比べても価格が低く、多機能な自動化ツールは他にありません。 お客様に中にも「TestArchitectはこれだけ多機能でなぜこれほど価格が安いのですか？」という声もよく聞きます。自動化ツールの購入の重要ポイントである価格が安いという点だけでも、ツール購入の選択肢に入れておく価値があると思います。このTestArchitectという十分な機能が揃った自動化ツールが実行だけなら年間９万から使えるというだけでも、作業者を雇うことを思えばかなりコスト面でのメリットは出てきます。かなりお買い得だと思います。 8. 自動化対象に合わせてカスタマイズ可能 どうしても他の自動化ツールで自動化できないこともTestArchitectであれば、カスタマイズを行うことで他の自動化ツールでできないことも自動化がすることができます。 Linux環境で充実した自動テストを行うことができる自動化ツールを探すとなるとなかなか良いものが見つからず、自動化断念となりかねません。 特殊な環境の合わせた自動化ツールを作成しようにも、新たに自動化ツールを作るために必要となる技術も高いものが求められるため、簡単に自動化ツールを作成しようと踏み切れるものではありません。 そういった問題があってもTestArchitectは環境に合わせたカスタマイズができるため、自動化対象に合わせた自動化ツールにすることができます。もし求める自動化ツールが探しても見つからない場合はTestArchitectのカスタマイズを選択肢に入れてみてはいかがでしょうか？ 纏め TestArchitectの優れた点ばかり説明してきましたが、1点他の自動化ツールに比べて劣っている点があります。 それはTestArchitectの知名度が無いことです。このような価格が安く実用的な自動化ツールが世間に知られていません。 日本以外の国で１０年以上の実績がありますが、日本での導入はごく最近の２０２０年頃からです。海外では実績もあり販売台数も多い自動化ツールですので、日本で知名度が無いことは問題ではありません。日本ではこれから実績を作っていく過程であるため現在は知名度が無いという状態です。 TestArchitectを検証したところ自動テストの現場の様々な問題を解決できる高い実用性を備えた自動化ツールであることがわかりました。他の自動化ツールに無い特徴を持った様々な機能を揃え、いろんな場面で活用することができ、しかも使いこなすことに高いスキルを必要としない自動化ツールは他に無いものだと思います。 気になった人はTeam版であれば無料で使えるため、TestArchitectを試してみてください。 参考： TestArchitectの概要 連載一覧 【第1回】自動テストはなぜ失敗するのか？ The post 【第2回】TestArchitect for Mobileの動作検証 first appeared on Sqripts .

みなさん、こんにちは！　QAエンジニアのゆーすけです。 11/2に JaSST九州 が開催されました。（新潟と同じ書き出し方…） 自分の今期のJaSST参加としては6月東北、9月新潟の2箇所は現地参加としていましたが、今回は九州の中でも福岡開催ということで何やら行けそうな気がしたので、こちらも現地参加をしてきました。 テストの基本に立ち返る 毎年九州内で開催地域を変えてきて、数年ぶりに初期開催拠点の福岡にもどってきたことから 「いまだからテストの基本に立ち返る」 ということをテーマに抱えたシンポジウムでした。 またJaSST実行委員の中に学生の方が参画された、ということもあり、基調講演のターゲットも、 学生向け 開発をやっているけどテストは初心者 という方が対象とした講演とした、とのことでした。 今回のブログでは主に基調講演の内容を拝聴しながら考えた内容をまとめていきたいと思います。 「わからない？をわかる！に変えよう！- QAエンジニアが実践している基本的な考え方と方法」 ということで、上記が基調講演のタイトルとなります。とりあえずどうしても書きたいことだけを先に書くと、 用語はISTQB グロッサリーを活用するのがよい（無料だし！） QAの用語統一はプロダクトや会社によって大きく異なる。 例えば単体テストという言葉をとっても全然違う 単体テスト＝Unit Testのことを考える人もいれば、画面上のかたまりや単機能のことを単体テストという会社もある でたっ！！！ 自分的QAあるあるの１個目にあげてる内容ですね（2個目以降は未設定） これを聞いて、「あー、やっぱこれは広く一般的？なQAあるあるなんだな」と強く思いました。 その証拠に、この話が出たときの会場の笑い＋苦笑い＋強くうなずくなど、参加者の反応が本シンポジウムで最も強くあらわれた部分なのではないのかな、と。 この話は自社内の個人の認識相違であれば笑い話ですむかもしれませんが、受発注関係で出た場合は大きなトラブルになるリスクを孕んでいます。 （とある日の光景）　※昔話を事実を元に誇張しています 営業 「クライアント様から見積と人員提案の依頼が来ましたー！”単体テスト”からやってほしいそうです」 自分 「単体テストから？？そうすると開発知見がないと難しいと思うんだけど、それって本当に『単体テスト』の話？？」 営業 「はい、”単体テスト”って言ってました！」 自分 「（ほんまかいな…）」 もちろんこの話のオチは『単体テスト』の話ではなく、単機能テスト＝結合テストだった、ということになります。 この話もまだ笑い話ですみますが、もし単機能テストだと思っていたら単体テストだった、という逆の場合では必要なスキルレベルが変わってくるので、会社間であれば大きなトラブルになる可能性が高いです。 今回の講演の話では「共通用語を定義できる」というインプットでしたが、「共通用語がある」ということが分かってくると、いろんな用語を聞いたときに「 それって本当に正しい意味で使われているのか、どういう意図で使われているのか 」といろんな部分にひっかかりができ、その「ひっかかる」ということがテストエンジニアとしての血肉になっていくのではないかな、と自分は考えています。 アウトプットする、ということ 講演案内に「紙とペンを使うよ」ということが記載されていたので、「はて？ワークショップ形式で行うのかな？」と思っていた部分があったのですが、実際は、エクササイズとして考えていることの文字でのアウトプットの時間が要所要所で設けられていました。 本シンポジウム中でも複数回に渡って 「レポートを書くところまでがJaSSTの参加です」 という言葉が出ていましたが、これはインプットとアウトプットの関係性的にもとても重要なことだと思っています。 「講義を受ける」といったような知識のインプット工程と、「得た知識を他で活用する」「人に話してみる」「レポートとして作成してみる」というアウトプット工程は、 インプット3割、アウトプット7割 が理想的だと言われています（比率に関しては所説あると思います） このブログ化も、言ってみればアウトプットの一つとして活用している部分になりますが、実際インプットしたものをアウトプットすることは、人によっては中々ハードルが高い場合もあります。 そういった人はインプットとアウトプットを同時かつ、理想的な比率で行えるワークショップに参加してみる、というのもよい機会だと思いますが、ワークショップに参加すること自体がハードルが高い、ということも往々にしてあります。 今回エクササイズとして、できるテストエンジニアとはどういうことができる人か書き出してみよう、といったような実際にペンを走らせる工程が複数ありました。 こういった講演の流れとしてアウトプットの機会があり、なおかつアウトプットしたものを他に公開しない、という心理的安全が保たれたかたちでの講演は中々に効果的かつ効率的だな、と思いながら参加をしていました。 中には持参したPCで書いた人もいたかもしれませんが、やはりペンを使って紙に書く、とテキストで打ち込む、は効果は違う、と思っているので、個人的にはアウトプットは紙とペンで行うのをおススメしたいところです。 余談ですが、20年くらいまえは不具合レポートを手書き＋FAX＆Excel送付で行っていたころもありますが、いかに最小限の労力でレポートを書くか、ということを求めるために、かなりの早さでレポート作成精度が一定値以上までいった、と思っています。 ※文章の一か所直すために全書き直し、とかあったので テクニカルスキル以外も学ぶ 役に立つテストとして、デシジョンテーブル、境界値という話にも触れられていましたが、境界値の例として 未成年・学生無料のイベントがある 未成年の定義としては、開催年度内で17歳であること 年齢判定としては、生年月日の4月1日と4月2日を境界値として考える という内容をあげられていました。 ご存じの方も多いと思いますが、学年というのは4/2～翌年4/1生まれで考えられています。 SEの方がそのルールを知らない場合、その判定で不具合が検出される、という話をしていましたが、テストする側もそのルールを知らなかった場合は普通に市場不具合として出るかたちになります（それもかなり恥ずかしいやつ）。 できるテストエンジニアとはどういうことができる人か書き出してみよう、のサンプルとして 「どのドメインでもテストできる」 という項目があげられていました。 言ってみると前項の事例も教育ドメインと言われれば教育ドメインですが、年齢、学年判定は教育系以外でも多く使われる内容です。 つまり極論的にいうと、 「全ての物事の理は、出し分け、分岐の指標になりうる」 だと思いますので、インプットの感度を強く日々過ごされるのがよりよいテストエンジニアへの道に繋がるのではないのかな、と思っています。 まとめ 今回は予めテックブログに書こう、と思って講演に臨みましたが、最初からアウトプットしよう、という気持ちで物事にあたると、 これをどうアウトプットしようか 自分に必要な情報は何なのか などというインプットしながら同時に脳内でアウトプットする、という状況になると思います。 また今こうして書いていること自体が自分の振り返りや新しい視点の創造になっているので、みなさんもいかにアウトプットをするか、ということに重きをおきながら学習に努めてみてはいかがでしょう。 「レポートを書くところまでがJaSSTの参加です」 書いたので、自分の中でのJaSST九州はこれで終わりになります！ お疲れ様でした！！ The post 初心者向けのQA講演を別の観点からいろいろ考えてみた －JaSST九州レポートにかえて－ first appeared on Sqripts .

こんにちは。RYUです。 現在、私はシステム保守運用のサポート業務を担当しております。業務経験としてはQAの方が多いのですが、今はインフラ系の業務を担当しております。 システム運用業務はミスが絶対許されない厳しい世界です。運用しているサービスの規模や種類にもよりますが、多くのユーザが利用しているWebサービスが停止したり、データが損失するような事態が発生した場合には、恐ろしい損害や事故等が発生する原因にもなってしまいます。それだけに、本番環境などを操作するような作業では、より慎重に取り組まないといけません。 とはいえ、私の性格的にボタンがあったら押すタイプなので、苦労しながらもミス防止を意識しながら、日々の業務に取り組んでおります。 システム運用業務ってこんな感じです 私が担当しているのはWebサービスで、日常的には、アラート発生時の対応やディスク容量の調整等を行います。また、定期的なアプリケーションのリリース作業や、不定期ですがファイヤウォールやロードバランサの設定変更、OSのバージョンアップ、仮想サーバの構築等も行っております。 いずれの作業においても、設定ミスやデータ削除等を行ってしまうと、サービス運営に影響を与えてしまいますので、作業中は気が抜けません。ただし、私の経験から強く思うのですが、人間はどうしてもミスをする生き物なんだなぁと感じる場面が多々あります。 そのため、システム運用の現場では運用業務におけるミスを防ぐ取り組みが色々と組み込まれており、今回はそのような取り組みの一部をご紹介させていただければと思います。 ここで紹介させていただく取り組みは、仕事や日常に取り入れることで、多少なりとも、単純なミスを防ぐことができるようになる可能性がありますので、できそうだなと思ったものは、ぜひお試しいただけると嬉しい限りです。 実際の取り組み 以下の内容は、いずれも目新しいものではなく、皆様もご存知のものだと思います。それでも、改めて見直していただくと、案外に役に立つものがあるかもしれませんので、ぜひぜひご覧ください。 その１：見直し 資料や手順書を作成した際、どうしても 誤字脱字や認識違い 等が発生するものです。本人の自覚や認識の無いところで、想定外の記載をしたり、必要な情報が抜けてしまうことは頻繁に起こります。自分ではそのようなミスは気が付かないことが多いので、作業完了後に見直しを行うべきなのですが、自分の行った作業については疑いを持ちにくいものですし、完成した際の満足感や疲労感から、作業完了直後に見直しを行ってもミスに気付きにくい状態になっております。 そのため、作業完了直後ではなく、少し違う作業を挟んだり、ちょっと休憩するなど、脳に違う刺激や休息を与えてから見直すだけで、自分のミスに気づきやすくなります。 ◆実際の取り組み ・ 手順書の作成や修正が完了したら最低30分は別作業を挟んでから再確認 　過去資料流用時はサーバ名表記等に修正漏れが多いので検索機能で再確認すると効果的 この見直すという行為は、日常生活ですと手続き用の書類記入や手紙など、色々な場面で実践できそうです。 その２：他者レビュー 作業手順書や設定用ドキュメントを作成、修正する際には他者レビューを実施します。 思い込みや認識違いや記載漏れ 等をかなり減らすことができますので、なかなか有効な手段です。 とくに、お客様に提出するドキュメントや本番環境に関する手順や設定に使用するパラメータシート等は重要なので、他者レビューの実施が不可欠です。 先の「見直し」も有効な手段ではありますが、やはり当事者による再確認なので、どうしても 思い込みや願望というフィルター が存在してしまいます。また、人によっても注意が向くベクトルが異なりますので、自分とは違う相手からのチェックというものは、非常に有効です。 ◆実際の取り組み ・ 必ず他者レビューを実施して完了するまで次に進めないというルールを運用 　手順書を２人で分割作成したときに作成者の認識違いで抜けた作業を他者レビューで指摘できました 日常生活ですと、重要書類の記入時に奥さまや旦那さま、ご両親、ご友人、などなど、身近な方に確認してもらうと良いかもしれませんね。 その３：ダブルチェック システム全般に致命的な影響を与えるような作業は必ず２人で操作内容の確認を行います。時間に余裕が無く手順書を作成することができない時や、過去に実施した実績のある手順などの場合にも、ダブルチェックで作業をすることも多くあります。 ダブルチェックは、作業を行う際に２名体制でお互いに作業内容を確認しつつ実施していくというものです。先の「他者レビュー」と同じように、 １人の不注意や思い込みフィルター などのミスにつながる要因を減少させることが可能です。とくに、時間が無い時などは、すぐにでも着手できますので、緊急時にも有効な手段となります。 ◆実際の取り組み ・ 簡単な作業でも影響が大きいものはダブルチェック 　サイトのメンテナンス作業でユーザーアクセスをブロックした場合、作業終了後のブロック解除時刻指定はダブルチェックで行い、必ず予定時間にアクセス再開できるようにしています 日常生活ではお出かけ前に、窓やドアの鍵閉め、水道やガスの元栓の状態確認など、ご家族やご友人とダブルチェックすることができれば閉め忘れや止め忘れなどを確実に防止することができます。とくに長期旅行などで長く自宅を離れる場合などでも、安心して出かけることができますね。 その４：無理しない 夜間作業などを実施している時、やはり人間ですのでどうしても睡魔に襲われる時があります。そのような場合には、我慢して作業を進めても、集中力の欠如による誤認識や不注意による誤操作などによるミスが発生しやすいです。そのため、作業で重要なデータ等を誤って削除してしまい、取り返しのつかない事態に発展する可能性があります 。ですので、そのような時は無理をせず１０分～３０分の仮眠をとるようにしています。※お客様の許可の上で仮眠しています。通常業務時に仮眠しちゃダメです(笑) おトイレや空腹感などもそうなのですが、人間ですので生理的欲求というものが必ず存在します。そして、それらは生きるために必要な機能となりますので、自分で制御することはなかなか難しいです。根性でなんとかしたり、精神力でどうにかしようとするのは難しいです。 ましてや、睡魔に襲われた時などのように、生体リズムに基づいた機能低下状態で作業を続けることは、自分の健康にも良くないですし、作業効率的な面からも有効ではありません。 ですので、眠い時は素直に仮眠する、がベストな対策になると私も考えております。結果的には、その方が効率が上がり、ミスの発生も防げます。 ◆実際の取り組み ・ 深夜作業でどうしても眠いときはメンバー交代と15分の仮眠取得 睡魔を我慢して作業することが無くなり、睡魔による重大ミス（ストレージの初期化など）を防いでいます 日常生活では、資格の勉強をしているような場面で効果があると思います。集中力が途切れ、睡魔に襲われるような時は、時間を決めて休憩したり、仮眠をとるというのは有効な手段ではないでしょうか。 その５：再発防止を考える ここまで色々と書いてきました。有効な手段があるとはいえ、やっぱりミスしちゃう時は必ずあります。 そのような時には、なぜミスが起こったのか原因を考え、再発しないような対策を作り、実践することで、同じようなミスを防ぐことができるようになります。 ただ、再発防止に力を入れすぎると、結果的に作業負荷ばかりが増えることにもなりますので、バランスが重要になります。世間でも時々話題になりますが、不祥事や事故が起きた際、一生懸命に原因追求と再発防止策を検討します。でも、そのせいで手順が煩雑になったり、審査が厳しくなったり、不便になることも少なからずあります。 再発防止の目的は、あくまでミスを防ぐことにありますので、仕組みやルールはできるだけシンプルな方が良いかなと思う次第です。 ◆実際の取り組み ・ 本番作業のミスは原因分析と再発防止策を策定して同じミスは起こさない 　間違って違うコマンドを入力した事例から、その作業は完全自動化バッチを作成することでミスの発生を防いでいます なお、日常生活で発生したミスについては、何故ミスしたのか？どうすれば防げるか？を常に模索することが重要になります。それを踏まえたうえで、実践可能な対策を実現できれば、もう同じミスは発生しにくくなります。 おわりに 以上、取り組みとして５つの実例を紹介させていただきましたが、いずれも使い古された手法であり、全て当たり前だと思うような基本的な事柄です。とはいえ、基本的な事柄を徹底して行い、習慣化することで、ミスを減らすことは必ず可能となります。私の経験からも、上記手法は効果があると考えております。 人間は生き物ですので、もともとミスをしやすい側面があります。勘違い・思い込み・錯覚・物忘れ・不注意・願望などが要因となることも多いです。そのため、そのような側面があることを理解したうえで、作業に取り組むことが有効ではないかと考えております。ただ、どうしても対策のための工数が発生しますので、バランスを考慮して取り入れていくことが重要かと思います。 ミスを減らすという取り組みは、システム運用では安全工学や信頼設計によるアプローチがありますが、今回紹介させていただいた内容は、どちらかというと認知心理学等の範疇となる認識や行動に着目したアプローチになると考えております。ミスを防止するために人間としての特性を意識した対策を考えていくことも有効ではないでしょうか。 最後まで読んで頂き、ありがとうございました。 The post 人間はミスをする生き物なんです ～システム保守運用業務で取り組んでいる5つのこと～ first appeared on Sqripts .

こんにちは。インフラエンジニアのTYです。普段はAWSやAzureなどのクラウドサービスを扱ったサービスの構築及び、検証などの業務を行っています。 システム導入時の検証でAsteriskを使用したPBX環境を構築しました。今回はAsteriskについてご紹介致します。 1.Asterisk概要 AsteriskはオープンソースのPBX（Private Branch eXchange）です。PBXはオフィスやコールセンターなどのように1つの親番号に着信しそこから適切な内線電話機やオペレーターに通話を転送する必要がある際に使用されます。 AsteriskはPSTNやSIPプロトコルによる通信はもちろんのこと、ACDシステムにWebRTCの機能を持たせて、利用することが可能です。   ＊ACD (Automatic Call Distribution)：着信呼自動分配装置   ＊WebRTC (Web Real-Time Communication)：ブラウザから発信される映像や音声・その他ファイルといったデータを優れた処理能力で通信する技術 Asteriskの一部機能となりますが、次項からAsteriskをSIPサーバーとして構築し、SIPによる内線通話を実現する環境を構築したいと思います。 2.構築 AWS EC2インスタンスにUbuntuをインストールし、そこにAsteriskをインストールしてSIPサーバーを構築していきたいと思います。 簡単な構成は以下の図のようになります。   では、構築していきましょう。 2.1 AWS 今回はAWS EC2インスタンスを利用します。もちろんローカル環境で行っても問題ありません。 2.1.1 EC2インスタンスの起動 Ubuntuを選択してセットアップを進めます。インスタンスタイプは小さいもので大丈夫です。 2.1.2 セキュリティグループ 以下のように設定します。 ※ SIPで使うUDPポートはデフォルトでは5060ですが、外部にAseteriskを構築する場合は、5060で空けないようにします。SIPのデフォルトポートを変更することでSIPを利用した攻撃の可能性を低減することができます。 2.2 Asteriskの導入 2.2.1 Asteriskのインストール 作成したEC2インスタンスにSSHでログインします。システムが更新されているか確認してください。 $ sudo apt-get update 今回aptでのインストールではAsteriskで使用を予定している機能が含まれていなかったため、今回はソースをダウンロードし、コンパイル時に使用する機能を含める状態にして ビルドします。 $ cd ~ $ wget　http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-18-current.tar.gz $ tar -xvf asterisk-18[tab] $ cd asterisk-18.[tab] $ sudo su # contrib/scripts/install_prereq install # ./configure --with-pjproject-bundled # make menuselect # make && make install && make config # exit $ cd ~ $ make menuselect はデフォルトのままsave&exitで大丈夫です。 最後に以下コマンドを実行しAsteriskのサンプル設定ファイルをインストールします。 ~/asterisk-18.19.0$ make sample 2.2.2 Asteriskの設定 内線電話番号を2つ設定し、お互いに通話がつながるようにします。この際に設定する必要のあるファイルは”pjsip.conf”と”extensions.conf”の2つです。 /etc/asteriskに移動すると以下のようにたくさんのファイルがあると思いますので、一旦”pjsip.conf”と”extensions.conf”のファイル名を変更します。 $ mv pjsip.conf pjsip_conf_bak $ mv extensions.conf extensions_conf_bak それでは設定していきましょう。 まずはpjsip.confです。SIPサーバーに関する設定や内線電話（SIPクライアント）からの認証情報を設定します。 /etc/asterisk/pjsip.conf を以下のように設定します。 [transport-udp] type=transport protocol=udp bind=0.0.0.0:5070 #デフォルトでは5060 [6001] type=endpoint context=from-internal disallow=all allow=ulaw auth=6001 aors=6001 rewrite_contact = yes # 6001がNAT環境下の場合、必要。 [6001] type=auth auth_type=userpass password=userpassword username=6001 [6001] type=aor max_contacts=10 [6002] type=endpoint context=from-internal disallow=all allow=ulaw auth=6002 aors=6002 rewrite_contact = yes # 6002がNAT環境下の場合、必要。 [6002] type=auth auth_type=userpass password=userpassword username=6002 [6002] type=aor max_contacts=10 “6001”,”6002”の type=auth にある”userpassword” は自由に設定してください 続いてextensions.confです。内線電話（SIPクライアント）からの発着信時のルールをここに記述します。 /etc/asterisk/extensions.confを以下のように設定します。 [from-internal] exten = 100,1,Answer() same = n,Wait(1) same = n,Playback(hello-world) same = n,Hangup() # 6001がコールされたらSIPの6001を呼び出す exten = 6001,1,Dial(PJSIP/6001,30,r) same = n.Hangup() # 6002がコールされたらSIPの6001を呼び出す exten = 6002,1,Dial(PJSIP/6002,30,r) same = n.Hangup() ここまで設定出来たら以下のコマンドでAsteriskを再起動します。 $ systemctl status saterisk ここまででAsteriskの設定は完了です。実際にSIPクライアントを接続し通話を行ってみましょう。 3.実機テスト 3.1 SIPクライアント設定 前章までの設定でAsteriskはSIPサーバーとしての機能を持つことができています。実際に通話ができるか確認する際には設定したAsteriskにSIPクライアントを登録(レジスト)して利用します。SIPクライアントはなんでも大丈夫ですが、今回はSIPクライアントとしてZoiperを利用します。 手元の端末2台にzoiperをインストールしたら起動し右下の歯車マークからAccountsを選択します。次にSIPAccountsを以下のように設定します。 設置画面には以下のように設定します。青枠のDomainの部分にはご自身のAsteriskサーバーのIPアドレスorドメインを入力、Passwordにはpjsip.confで設定したパスワードを入力してください。入力できたらregisterを選択し以下の画像のようにStatusがOKになればAsteriskにSipクライアントがレジストされています。 もう片方のSipクライアントも上記と同様にpjsip.confで設定したSipアカウントの情報を入力してください。本記事の内容通りだと6002のSIPアカウントがあると思います。 3.2 内線番号6001から内線番号6002に発信 ここまで設定ができたらZoiperの左下にあるDialPadから6001のアカウントなら6002にダイヤルし発信してみてください。うまく設定ができていれば6002のクライアントに着信するはずです。 4.まとめ これでAsteriskを簡単なSIPサーバーとして構築し内線環境を構築することができました。この程度の設定で内線通話ができることは始めて構築した際は結構感動しました。 今回は内線の環境ですがTwilioやひかり電話などをAsteriskにレジストすることで、PSTN回線を用いてSIPクライアントと通話することなどもできますし、Asteriskはhttpサーバーの機能もあるため、Websocketサーバーとして運用することでWebRTC-Sipクライアントの通話も構築次第で可能になります。 私もまだまだ勉強中ですが、そのあたりの設定も機会があればまたお話ししたいと思います。 ありがとうございました。 The post Asterisk入門　～SIPフォンで通話してみる～ first appeared on Sqripts .

本連載では、ブロックチェーンの基本的な仕組みを解説しながら、オンチェーンデータを分析するための基本的な手法について、全8回で紹介します。 第7回の今回は、Ethereumのトランザクションに紐づくデータ構造の深掘りや、データ分析でよく用いられる発展的なSQLの構文についての解説をおこないます。 Ethereumのトランザクション詳解 Bitcoinの場合、各アカウントが保持する状態は基本的にビットコインの残高であり、その変更は送金やマイニングといった１つのトランザクションを最小単位として行われます。一方、Ethereumの場合は、各アカウントのイーサ残高のほかに、スマートコントラクト上のさまざまなデータを状態として保持しており、状態変化のアクションはBitcoinほど単純ではありません。また、１つのトランザクションの中に複数のアクションが含まれることがあります。あるトランザクションを起点として、複数のスマートコントラクトの関数を呼び出すといったことも可能です。こういった複雑なアクションを分析するために、TracesやLogsといったデータ構造が存在します。 TransactionsとTraces EthereumにおけるTracesとは、トランザクションを起点としておこなわれるさまざまな状態変化のアクションの最小単位を記録したものです。Etherscan( https://etherscan.io/ )などのエクスプローラーでは、「internal transactions」といった形で表現されることもあります。コード1は、Dune( https://dune.com/ )上で過去24時間以内のTracesデータを100件取得するクエリです。 コード1 . 最新24時間以内のEthereumのTracesデータを100件取得するクエリ SELECT * FROM ethereum.traces WHERE block_time >= CURRENT_TIMESTAMP - INTERVAL '24' hour LIMIT 100 図1. コード1.の出力結果例：ethereum.tracesテーブルのサンプルデータ コード2は、Tracesの種類の一覧とアクション数を取得するためのクエリです。計算量の削減と計算結果の固定のため、対象期間を2023年1月1日から31日までの間に絞り込んでいます。 コード2 . traces.typeの種類ごとにカウントして多い順に並べ替えるクエリ SELECT type, count(1) as cnt FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' GROUP BY type ORDER BY cnt desc LIMIT 100 図2. コード2.の出力結果例 図2に示されるとおり、Tracesの種類には、callやcreate、reward、suicideなどがあります。最も件数の多いcallは、Etherの送金やスマートコントラクトの関数を呼び出す場合に用いられます。createは、スマートコントラクトを新規作成する場合に用いられます。rewardは、ブロック生成時の報酬に関するログに用いられますが、Ethereumの報酬に関する仕様は頻繁に変更されており、現在では使用されていません。suicideは、スマートコントラクトの削除に関するアクションに用いられます。 図3で示すとおり、Etherscan上では、Tracesの内容はInternal Txnsというタブで確認することができます。 図3. Etherscanで特定のトランザクションに関するInternal Transactionsを確認するサンプル画面 （ etherscan.ioの実際の画面はこちら ） 同様の内容を、Dune上でも参照してみましょう。コード3.を用いて、特定のトランザクションに紐づくTracesの情報を取得できます。トランザクションハッシュのみの指定でもデータは取得できますが、データの探索範囲を絞り込むためにWHERE句で期間も指定しています。 コード3 . 指定したトランザクションのTracesを取得するクエリ SELECT trace_address, call_type, "from", to, value, gas FROM ethereum.traces WHERE block_time >= timestamp '2023-10-20 00:00:00' AND tx_hash = 0x7900ef4293837b14cdf8814396e45b9380636cdfb7c55fe05a7343628b8b1ae0 LIMIT 100 図3および図4を見比べて、表記の違いはあるものの、同様のデータが取得できていることを確認してみてください。 図4. コード3. の出力結果例 TransactionsとLogs TracesがEVMの仕様によってほぼ自動的に出力されるログである一方、Logs（Event Logs）はスマートコントラクトの実装者が明示的に定義できるログの種類です。Logsは関数のデバッグ用途や、トランザクション内のイベントをブロックチェーン外のシステムから検知するためなどに用いられます。 コード3のテーブルをLogs用に変更して、さきほど見たトランザクションに関するLogsを取得するクエリがコード4です。 コード4 . あるトランザクションのLogsを取得するクエリ SELECT * FROM ethereum.logs WHERE block_time >= timestamp '2023-10-20 00:00:00' AND tx_hash = 0x7900ef4293837b14cdf8814396e45b9380636cdfb7c55fe05a7343628b8b1ae0 LIMIT 100 図5.コード4.の出力結果例 図6. Etherscanで特定のトランザクションに関するLogsを確認するサンプル画面 （ etherscan.ioの実際の画面はこちら ） 図6に示すとおり、Etherscanなどのエクスプローラーでは、著名なコントラクトについてはLogsのデータもデコードされた状態で表示されます。一方、Ethereumブロックチェーン上の生データやDuneのLogsテーブル上では、データはバイナリ形式でエンコードされた状態であり、そのままでは理解が困難です。また、さまざまなフォーマットのログをデコードするには、そのログがどのようなフォーマットであるかという定義情報が必要です。 Dune上では、それぞれのコントラクトの定義情報を用いてデータをデコードしたテーブルを提供してくれています。さきほどまで参照していたトランザクションであれば、uniswap_v3というDEX（オンチェーン上の分散型取引所）のトランザクションとしてデコードされています。 コード5 . uniswap_v3のトレードデータとしてデコードされたトランザクションを取得するクエリ SELECT * FROM uniswap_v3_ethereum.trades WHERE block_time >= timestamp '2023-10-20 00:00:00' AND tx_hash = 0x7900ef4293837b14cdf8814396e45b9380636cdfb7c55fe05a7343628b8b1ae0 LIMIT 100 図7. コード5の出力結果例 Duneでは、デフォルトでデコードされていないデータであっても、利用者がスマートコントラクトの情報などを登録してデコードの申請をすることも可能となっているので、自身の作成したコントラクトや、比較的新しいコントラクトのデータを分析する場合に活用してください。 データ分析のためのSQL 前半でご紹介したTracesやLogsデータを対象として、データ分析でよく用いられるSQL構文のうち、使用頻度も高いCASE式とWindow関数についてご紹介します。 CASE式と集約関数 CASE式は、条件式にしたがって値の場合分けをおこなうための式です。「CASE WHEN 【条件式】THEN【真の場合の値】ELSE【偽の場合の値】END」という構文を用います。コード6. に、Logsテーブルのtopicカラムの値が存在しているかどうかで0または1を出し分けるサンプルクエリを示します。SQLにおいて、値が存在していないフラグとして「NULL」を用い、NULLであるかどうかは「IS (NOT) NULL」を用います。 コード6 . CASE式で値の場合分けをおこなうサンプルクエリ SELECT topic0, topic3, CASE WHEN topic0 IS NOT NULL THEN 1 ELSE 0 END AS have_topic0, CASE WHEN topic3 IS NOT NULL THEN 1 ELSE 0 END AS have_topic3 FROM ethereum.logs WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' LIMIT 100 図8. コード6. の出力結果例 このCASE式と集約関数を組み合わせてデータ分析を用いるテクニックがいくつかあります。例えば、Logsテーブルにおいて、topic0～3の値がレコード全体のうちどれくらいの割合で存在しているかを集計したい場合を考えます。直感的には、「topicの値が存在しているレコードの数」を「レコード全体の数」で割ることで割合を計算できます。これは、CASE式を用いて「topicの値が存在している場合は1、存在していない場合は0」という変換をおこない、それをAVG関数で平均してあげることでも計算できます。コード7.に、CASE式とAVG関数を用いて割合を計算するサンプルクエリを示します。 コード7 .CASE式とAVG関数を組み合わせて割合を計算するサンプルクエリ SELECT COUNT(1) AS cnt, AVG(CASE WHEN topic0 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic0, AVG(CASE WHEN topic1 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic1, AVG(CASE WHEN topic2 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic2, AVG(CASE WHEN topic3 IS NOT NULL THEN 1 ELSE 0 END) AS have_topic3 FROM ethereum.logs WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' LIMIT 100 図9. コード7. の出力結果例 また、CASE式と集約関数を組み合わせることで、レコードごとに保持していたデータをカラムごとに保持するフォーマットに変換することもできます。 コード8は、uniswap_v3のtradesテーブルから、USDT-WETHとUSDC-WETHという通貨ペアの取引に絞り込み、取引数や取引総額を集計するクエリです。 コード8 . 通貨ペアの取引数・取引総額を集計するクエリ SELECT token_pair, COUNT(1) AS cnt, SUM(amount_usd) AS total_amount_usd FROM uniswap_v3_ethereum.trades WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' AND token_pair IN ('USDT-WETH', 'USDC-WETH') GROUP BY token_pair LIMIT 100 図10. コード8. の出力結果例 コード8の集計結果を、日次の取引数や取引総額に細分化して分析することを考えます。このとき、GROUP BY句にblock_dateを加えることで求める結果は計算できますが、すべての計算結果が別々のレコードとして表示されるため、異なる通貨ペアの同じ日付での取引の比較などが少し難しくなります。そこで、CASE式とSUM関数を用いて、レコードは日付ごとに集約し、カラムで通貨ペアの場合分けをおこなうことで、同じ日付の取引を比較分析しやすいフォーマットに変換できます。 コード9 .CASE式とSUM関数を用いて、異なる分類のデータをひとつのレコードに集約するクエリ SELECT block_date, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN 1 ELSE 0 END) AS usdt_weth_cnt, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN 1 ELSE 0 END) AS usdc_weth_cnt, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN amount_usd ELSE 0 END) AS usdt_total_amount_usd, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN amount_usd ELSE 0 END) AS usdc_total_amount_usd FROM uniswap_v3_ethereum.trades WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' AND token_pair IN ('USDT-WETH', 'USDC-WETH') GROUP BY block_date ORDER BY block_date LIMIT 100 図11. コード9. の出力結果例 Window関数 SQLのベースとなっている関係代数や集合論では、データの順序を扱うために特殊な手順が必要でした。しかし、SQLが時系列データやその他の順序付きデータの分析用途にも用いられるようになり、データ分析に特化した構文の需要が高まりました。そこで導入されたのが、Window関数と呼ばれる関数群です。 コード10は、コード9で計算したuniswap_v3の日次取引データに対して、Window関数を用いたサンプルクエリです。Window関数の多くは、集約関数に続いてOVER句を用いる形で記述できます。 例えば、SUM() OVER()関数を用いると、GROUP BYによるレコードの集約をおこなうことなく、各レコードに対して全体のデータの合計値を付加することができます。また、OVER句の中にORDER BY句で順序を指定することで、先頭からそのレコードまでの累計値を計算して各レコードに付加することができます。LAGやLEAD関数は、現在のレコードの前後のレコードの値を参照するために用いられます。例えば、１月２日の取引数を保有しているレコードに対して、１月１日や１月３日など、他の日付のレコードを参照することが可能です。 コード10 . Window関数でデータの累計や総計を計算するサンプルクエリ WITH daily_trades AS ( SELECT block_date, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN 1 ELSE 0 END) AS usdt_weth_cnt, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN 1 ELSE 0 END) AS usdc_weth_cnt, SUM(CASE WHEN token_pair = 'USDT-WETH' THEN amount_usd ELSE 0 END) AS usdt_total_amount_usd, SUM(CASE WHEN token_pair = 'USDC-WETH' THEN amount_usd ELSE 0 END) AS usdc_total_amount_usd FROM uniswap_v3_ethereum.trades WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-31 23:59:59' AND token_pair IN ('USDT-WETH', 'USDC-WETH') GROUP BY block_date ) SELECT block_date, usdt_weth_cnt AS daily_cnt, SUM(usdt_weth_cnt) OVER(ORDER BY block_date) AS accum_cnt, SUM(usdt_weth_cnt) OVER() AS total_cnt, LAG(usdt_weth_cnt) OVER(ORDER BY block_date) AS prev_daily_count, LEAD(usdt_weth_cnt) OVER(ORDER BY block_date) AS next_daily_count FROM daily_trades ORDER BY block_date LIMIT 100 図12. コード10. の出力結果例 Window関数では、OVER句の中にPARTITION BY句を用いて、集約範囲のグルーピングをおこなうこともできます。コード11では、Tracesテーブルの各レコードに対して、同じトランザクションIDを持つレコードの総数や、同じトランザクションIDを持つレコード内でtrace_address順に並べ替えたときのインデックス番号を付与する例を示します。 コード11 . PARTITION BY句によるWindow関数のグルーピング例 SELECT tx_hash, trace_address, COUNT(1) OVER(PARTITION BY tx_hash) AS trace_cnt, ROW_NUMBER() OVER(PARTITION BY tx_hash ORDER BY trace_address) AS trace_idx FROM ethereum.traces WHERE block_time BETWEEN timestamp '2023-01-01 00:00:00' AND timestamp '2023-01-01 23:59:59' ORDER BY tx_hash, trace_address LIMIT 100 図13. コード11. の出力結果例 CASE式やWindow関数を用いることで、SQLを単なるデータ抽出だけでなく、高度なデータ分析のツールとして活用できます。SQLを用いて計算した結果は、別のSQLクエリの入力に使うこともできるため、分析結果の共有や再利用性も高く、複数人のチームやプロジェクトによる大規模なデータ分析にも有用です。 次回予告 今回の記事では、TracesやLogsといったEVMのデータ構造の深掘り、および、CASE式やWindow関数といった分析用途で頻出するSQL構文について解説しました。次回記事では、本連載の最終回として、より発展的なオンチェーンデータ分析の事例についてご紹介します。 連載一覧 【第1回】ブロックチェーンとは 【第2回】ビットコインの仕組み 【第3回】イーサリアムの仕組み 【第4回】ビッグデータ分析のためのSQL基礎 【第5回】Ethereumデータ分析演習1 【第6回】Ethereumデータ分析演習2 【第7回】Ethereumデータ分析演習3 The post 【第7回】Ethereumデータ分析演習3 first appeared on Sqripts .

はじめまして、QAエンジニアの田中です。今回はアジャイル開発手法の一つのBDDについてご紹介したいと思います。 BDDとは何か？ BDD（Behavior-Driven Development）は、ビヘイビア駆動開発や振る舞い駆動開発とも呼ばれ、テスト駆動開発から派生したものです。ソフトウェアの振る舞いや機能を重視して、品質と要件の向上をめざします。具体的には、ソフトウェアの振る舞いを明確に定義することで、プログラム開発とテストを効率化することができます。 まず初めに、自動販売機の例を通して、BDDを説明していきます。自動販売機では、お客さんがお金を投入し飲み物を購入できます。BDDの視点から、具体的な振る舞いのシナリオを考えてみましょう。 シナリオ1: お客さんがお金を投入して自動販売機で飲み物を購入しようとする もし、お客さんが自動販売機にお金を投入し、飲み物の選択ボタンをクリックしたら、選択ボタンに応じた飲み物が出てくるべきです。 そして、おつりが必要な場合、自動販売機は、必要な金額をおつりとして、お客さんに出すべきです。 シナリオ2: お客さんがお金を投入しないで自動販売機で飲み物を購入しようとする もし、お客さんが自動販売機にお金を投入せずに、飲み物の選択ボタンをクリックしたら、飲み物が出てくるべきではないです。 このシナリオは、ビジネスの視点からソフトウェアの振る舞いを記述したものであり、BDDはこのようなシナリオを通じてソフトウェアの開発とテストを導く手法です。鍵となるポイントは、ビジネス要件とソフトウェアの振る舞いを結びつけ、それに基づいてテストを設計し、ソフトウェアを開発することです。 この自動販売機の例から、BDDが開発プロセスを明確にし、チームが顧客の要件を正確に理解するのに役立つことがわかります。これにより、顧客の期待に応える高品質なソフトウェアを迅速に提供することが可能になります。 BDDについて更に詳しく知りたい方は、本サイトでスクリプターのブロッコリーさんが詳しい記事を書いておりますので、そちらを参照願います。 ■ 【連載】TDDの派生形！BDDやATDDとは何か? 概念からプロセスまで徹底解説！ スクリプター：風間裕也（ブロッコリー） BDDの特徴・メリット BDDの特徴やメリットには、下記のようなものがあります。 振る舞いに焦点を当てる 開発者、テスター、ビジネスステークホルダーが共通の理解を持つために、振る舞いに対する要件や期待値を明確に定義します。非開発者と開発者間の認識齟齬の低減が期待でき、プロジェクトの効率を向上させます。 自然言語で記述 テストのシナリオ（テストケース）において振る舞いや要件を自然言語で記述します。シナリオは様々なフェーズのテストで柔軟に活用でき、開発者が書く自動テスト（ユニットテスト、インテグレーションテストなど）などの開発者テストでも適用可能です。非技術者も理解しやすく、コミュニケーションの質を向上させます。日本語で書かれたテストシナリオがそのまま実行でき、異なるパラメータの入力も日本語で記述されたシナリオ内で表現できます。一般的な文法は「Given-When-Then」で表現され、前提条件（Given）、アクション（When）、結果（Then）を記述します。非開発者による振る舞いや要件の記述(シナリオ作成)が期待できます。後ほど、例を用いて説明します。 テストケースとしてのBDD BDDはテストケース(シナリオ)を自動化するための方法としても使用されます。BDDフレームワークを使用して自動テストケースを記述し、実行することで、振る舞いに関する問題を特定し、外部品質を確保します。また、リファクタリングなどの内部実装変更に対して、テストケースが影響を受けないため、テストケースのメンテナンスが減ります。 テストファースト・シフトレフト BDDは、テストファースト・シフトレフトの原則に基づいています。コードを書く前に振る舞いや要件を明確にし、それに基づいてシナリオを記述します。その後、それに合格するプロダクトコードを書いていきます。これにより、テスタビリティの高い、かつ疎結合なコードが作成されることにより、各部分が独立してテストでき、特定の変更が他の部分に影響を与えにくくなるため、コードの品質向上とバグの早期発見を実現できます。早い段階で問題点をフィードバックすることで、大きな手戻りや未然にバグを防ぐことが可能で、全体のテスト時間を短縮し、コスト低減も期待できます。 QAエンジニアからみたBDDのメリット では、QAエンジニアからみたBDDのメリットには、どのようなものがあるでしょう？BDDを導入することで、QA(品質保証)の観点からは、次のようなメリットがあります。 開発者とQAエンジニアの共通理解の促進 開発者とQAエンジニアの連携が強化されます。開発者とQAエンジニアが共通のBDDの仕様や振る舞い定義に基づいて作業を行うため、コミュニケーションや理解が容易になります。 QAエンジニアによるテストのレビュー・作成が可能 QAエンジニアは開発者テスト段階からテストのレビュー・作成を行えるようになります。BDDの仕様に基づいてシナリオを作成し、テストの品質を向上させることができます。 つまり、BDDを導入することで、品質保証プロセスにおいて開発者とQAエンジニアの連携が強化され、テストの品質向上を実現することができます。 BDDの進め方 では、BDDの進め方について、 ブロッコリーさんの記事 の例を参考に、見てみましょう。 TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング より まず、「#1 ユーザーストーリーを選ぶ」では、システムにおいて実装すべき機能を引き出し、優先順位を付けて行きます。 次に「#2 要件ワークショップ」では、優先順位を付けられた機能に対して、振る舞いの実例を基に詳細な要件を探索し、明確になっていなかった要件を発見していきます。 TDDとBDD/ATDD(5)　BDDのプロセスその1「発見(Discovery)」と実例マッピング より 次に、実例をシナリオに変換する「#3 定式化」を行います。ここでは、振る舞い定義に基づいたシナリオが自然言語(Gherkin ※1 記法など)で記載されているため、開発者はもちろんQAエンジニアにもシナリオの理解が深まり、開発者テスト段階からテストのレビュー・作成を行うことが可能です。これにより、開発の早い段階からQAエンジニアが参画してテストを行うことができるため、テストの品質向上につながります。 Feature: 自動販売機 Scenario: 飲み物を買うと、飲み物代を引いた金額のお釣りが出る Given 自動販売機がある When 550 円を入れる And 120 円の "コーラ" を選択する Then "コーラ" が出てくる And 430 円が出てくる 「#4 レビュー」では、他のチームメンバーからの視点を取り入れることで、潜在的な問題を特定し、誤解や不足を解消し、ソフトウェアの品質を高めます。「#5 自動化」では、BDDのフレームワークを導入により自動テストのコードを書きます。自動化についての詳細については、下記を参考にしてください。 参考： TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 スクリプター：風間裕也（ブロッコリー） TDDとBDD/ATDD(7)　BDDのプロセスその3「自動化(Automation)」 より 次に下記の３つのサイクルを回し、コードを「#6 実装」していきます。 Red：プログラマーがテストを書く Green：テストが成功するのに十分なコードを書く Refactor：コードを整理する テストコードをシナリオに合わせて作成し、それをパスするコードを実装、このプロセスを繰り返します。「#7 補足的なテスト」では、自動テストを補う形で、探索的テスト、侵入テストや負荷テストを行い、ソフトの品質を高めていきます。最後に、出荷可能なインクリメントを生成「#8 リリース」して、次の開発につなげます。 事例(PoCをやってみた) BDDを導入することで、QAプロセスにおいて開発者とQAエンジニアの連携が強化され、テストの品質向上を実現できることが明らかです。しかし、理論的なメリットを持つ取り組みが実際の現場でどのように機能するかは、常に疑問が残ります。 そのため、想定しているQA目線でのメリットが実際に享受できるかをPoCで確認してみることにしました。 PoC事例詳細 プロジェクトの品質向上を目指し、テストに関する課題を解決するために、BDDの導入による品質向上の具体的な効果を実証し、その実現可能性を探ってみました。 難しい要件があるプロジェクトで、下記のようないくつかの課題を抱えており、品質を十分に担保できるかに懸念を抱いていました。 開発者によるテストに十分な時間が確保されていない 開発者だけでテストケースを作成しているため、テストケースを過不足なく洗い出せるか不安 開発者によるアサーション（テストの条件や期待結果）の設定が難しい そこで、BDDを取り入れて、上記の改善を図ることを目指すPoCを実施しました。実際に行った手順は、下記の通りです。（今回のPoCでは、BDDの進め方の「#2 要件ワークショップ」から「#6 実装」のプロセスを実施しています。） 実例を基にした要件整理とテストケース作成 開発者とQAエンジニアは、実際の実例を基に詳細な要件を整理し、ビジネス要件を明確にしました。その後、QAエンジニアはGherkin記法を用いて、テストケースを記述しました。これは、BDDの進め方の「#2 要件ワークショップ」「#3 定式化」に該当します。 テストケースの合同レビュー 開発者とQAエンジニアはテストケースについて「#4 レビュー」を行い、テストケースを明確化しました。 テストコード実装 開発者は、テストケースを基にテストコードを実装していきます。これは、BDDの進め方の「#5 自動化」に該当します。 今回のテスト自動化環境では、テストのフレームワークでは、pytest-bddを使用しました。これは、開発言語としてはPythonが用いられていたこと、元々ユニットテストがpytestで書かれておりユニットテストの資産流用を考慮したためです。pytest-bddは、pytest ※2 で振る舞い駆動を実現するために、Gherkinで記載したテストケースとPythonのコードを紐づけてくれる役割を持っています。 コードの実装 開発者は、pytest-bddで自動化テストを行い、パスするコードを作成しシステムに実装していきました。このステップは、BDDの進め方の「#6 実装」に該当します。 PoCで見えてきた課題と、解決に向けた取り組み 最初は順調に見えたPoCですが、進めていく中で次のような課題が出てきました。 多数のテストケースとテストコードが作成されたため、対応関係を理解しにくく、管理が煩雑 新機能の実装に専念するため、開発者によるテストコードの作成のための時間が不足 開発中に、多くのテストケースを通過させながらコードを実装する際、テスト・実装進捗の管理が難しい そこで、課題の解決のために、次のような対策を立てました。 テストケースとテストコードの関連性を明確に管理するための管理ツールを作成する 高品質のテストを開発と同時に進めるため、QAエンジニアがテストケースだけではなくテストコードも作成する。 コード実装の進捗状況をテストのパス数で可視化するための、試験結果・コード実装進捗の表示ツールを作成する。 BDDの開発プロセスにおいて、QAエンジニアが開発の初期段階で、管理ツールや試験結果表示ツールの対応、そしてテストコード作成をサポートしたことにより、開発者の品質向上に対する負荷を軽減し、ソフトウエアの品質を向上させることができました。 まとめ BDDは、ソフトウェア開発プロセスの品質と効率性を向上させる強力な手法です。現代のビジネス環境は変化し続けており、ソフトウェア開発においては柔軟で迅速な対応が求められます。BDDは自然言語で要件を記述し、シナリオを作成し、迅速なフィードバックを通じて顧客の要求に柔軟に対応するのに非常に効果的です。さらに、開発チームとテストチームが協力し、BDDフレームワークを使用して自動テストを実施することで、生産性の向上、品質の向上、および顧客満足度の向上を期待できます。この記事がBDDを導入のきっかけとなったり、チーム全体で実践を通してソフトウェア開発プロセスの品質向上と効率化を図る参考になれば幸いです。 APPENDIX:用語の説明 ※1 Gherkin： Cucumberなどのテストフレームワークがテストケースを定義するために使用する言語。この言語の目的は、ビジネスアナリストやマネージャを含む開発チーム全体にわたって、BDDの実践を促進することにある。これは、ビジネスマネジメントによる要件定義の初期段階や、開発ライフサイクルの他の段階において、強固で曖昧さのない要件を強制しようとしている。自動テストのためのスクリプトを提供することに加えて、Gherkinの自然言語構文は、テスト対象のコードの簡単な文書化を提供するように設計されている。 ※2 pytest：PyPyプロジェクトから生まれたPythonのテストフレームワーク。ユニットテスト、統合テスト、エンドツーエンドテスト、機能テストなど、様々な種類のソフトウェアテストを書くために使うことができる。その機能には、パラメトリックテスト、フィクスチャ、アサート書き換えなどがある。 The post BDDについて ～ ソフトウェアの振る舞いに焦点を当て、要件を明確にし、コミュニケーションを改善 ～ first appeared on Sqripts .

こんにちは、バックエンドエンジニアのまさです。 最近、開発プロセスを効率化するための取り組みの一つとして、Github Copilotを利用しています。この記事では、Github Copilotを使ってみた結果、開発効率が劇的に向上した経験について共有したいと思います。 Github Copilotとは Github Copilotは、AI（人工知能）を利用してコーディングの補完や提案を行う開発ツールです。このツールは、コードを書く際に、自動的にコードの断片や関数を提案してくれます。また、コードの文脈に基づいて、適切なコードスニペットを生成することもできます。Github Copilotは、プログラミング言語やフレームワークに関係なく使用することができます。 まずは試してみる｜GitHub Copilotの使い方 普段は開発用のIDEとしてVSCodeを利用しています。VSCodeには こちら のGitHub Copilot用の拡張プラグインがありますので、こちらをインストールして使用します。 プラグインをインストールした後、新規にファイルを作成してCopilotを試してみます。今回はGo言語で試してみるため、 main.go というファイルを作成します。 試しにクエリパラメータを受け取り、それをレスポンスとして返却するHTTPサーバーを実装してみたいと思います。 まずは、 main.go に以下のようにコメントで記述します。 // httpサーバーでユーザーからのリクエストをqパラメタで受け取り、それをレスポンスとして返す処理の実装 そして改行すると このようにcopilotが続けてコメント候補を提案してくれます。 今回はそのまま記述を行いたいのでパッケージ文 package main を記述しようと思います。 そのため一文字目のpという文字を打ち込むと 打ち込もうとした package main を候補として提案してくれました。 これはそのまま利用したいためtabキーを押下し、提案を承諾します。 続けて2行改行すると次は import文の提案をしてくれます。以降は改行→提案承諾という形でしばらく進めてみます。 すると最終的には下記のような動作するコードを生成してくれます。 動作を確認するため、以下のようにしてこのプログラムを実行します。 go run main.go コマンドを実行するとサーバー処理が起動し、リクエスト受付状態となります。 別のターミナルから下記のようにコマンドを実行してみます。 curl localhost:8080?q=test 「hello test」のように出力がされると思います。 最初のコメントに記載したとおり「httpサーバーでユーザーからのリクエストをqパラメタで受け取り、それをレスポンスとして返す処理の実装」を達成できました！ テストでの活用 Github Copilotはテストコードの作成にも役立ちます。テストケースやアサーションの生成、モックオブジェクトの作成など、テストに関連するコードの自動生成が行われます。これにより、手作業でのテストコードの作成時間やミスの可能性を減らすことができます。 実際に例を以下に記載したいと思います。 まずテスト対象のコードです。 ファイルは src/common/utils.go として作成してあります。 package common type ItemList struct { IdList []int ItemMap map[int]Item NameConcat string TotalPrice int } type Item struct { ID int Name string Price int } // Item配列を受け取り、ItemListを返す関数 func NewItemList(items []Item) *ItemList { // ItemListを初期化 itemList := &ItemList{ // IdListを初期化 IdList: []int{}, // ItemMapを初期化 ItemMap: map[int]Item{}, // TotalPriceを初期化 TotalPrice: 0, } // itemsを回す for _, item := range items { // IdListにitem.IDを追加 itemList.IdList = append(itemList.IdList, item.ID) // ItemMapにitem.IDをキーとしてitemを追加 itemList.ItemMap[item.ID] = item // NameConcatにitem.Nameを追加 itemList.NameConcat += item.Name // TotalPriceにitem.Priceを加算 itemList.TotalPrice += item.Price } // ItemListを返す return itemList } こちらは、Itemという構造体の配列から集計などを行い、ItemList構造体を返却する関数です。 具体的には、Item配列のIDのリストをIdListに、Idと実体を紐づけた連想配列をItemMapに、Nameを連結したものをNameConcatに、そして金額を合計したものをTotalPriceに格納したItemListを生成する処理となっています。 この関数のテストコードを作成するため、テスト用のソース src/common/utils_test.go を新たに作成しVSCodeで開きます。 まずは冒頭で下記のように入力します。 package common するとimport文の提案をしてくれますので了承します。 package common import ( "testing" ) 続けて以下のようにテストの生成の為のコメントが提案されます。 package common import ( "testing" ) // NewItemListのテスト その後は関数名からテストの実装まで全て提案してくれました。 package common import ( "testing" ) // NewItemListのテスト func TestNewItemList(t *testing.T) { // Itemを複数作成 items := []Item{ {ID: 1, Name: "item1", Price: 100}, {ID: 2, Name: "item2", Price: 200}, {ID: 3, Name: "item3", Price: 300}, } // NewItemListの実行結果を取得 itemList := NewItemList(items) // NewItemListの実行結果のIdListの長さが3でない場合 if len(itemList.IdList) != 3 { // テスト失敗 t.Errorf("len(itemList.IdList) = %v, want %v", len(itemList.IdList), 3) } // NewItemListの実行結果のIdListの要素が1でない場合 if itemList.IdList[0] != 1 { // テスト失敗 t.Errorf("itemList.IdList[0] = %v, want %v", itemList.IdList[0], 1) } // NewItemListの実行結果のIdListの要素が2でない場合 if itemList.IdList[1] != 2 { // テスト失敗 t.Errorf("itemList.IdList[1] = %v, want %v", itemList.IdList[1], 2) } // NewItemListの実行結果のIdListの要素が3でない場合 if itemList.IdList[2] != 3 { // テスト失敗 t.Errorf("itemList.IdList[2] = %v, want %v", itemList.IdList[2], 3) } // NewItemListの実行結果のItemMapの長さが3でない場合 if len(itemList.ItemMap) != 3 { // テスト失敗 t.Errorf("len(itemList.ItemMap) = %v, want %v", len(itemList.ItemMap), 3) } // NewItemListの実行結果のItemMapの要素が1でない場合 if itemList.ItemMap[1] != items[0] { // テスト失敗 t.Errorf("itemList.ItemMap[1] = %v, want %v", itemList.ItemMap[1], items[0]) } // NewItemListの実行結果のItemMapの要素が2でない場合 if itemList.ItemMap[2] != items[1] { // テスト失敗 t.Errorf("itemList.ItemMap[2] = %v, want %v", itemList.ItemMap[2], items[1]) } // NewItemListの実行結果のItemMapの要素が3でない場合 if itemList.ItemMap[3] != items[2] { // テスト失敗 t.Errorf("itemList.ItemMap[3] = %v, want %v", itemList.ItemMap[3], items[2]) } // NewItemListの実行結果のNameConcatがitem1item2item3でない場合 if itemList.NameConcat != "item1item2item3" { // テスト失敗 t.Errorf("itemList.NameConcat = %v, want %v", itemList.NameConcat, "item1item2item3") } // NewItemListの実行結果のTotalPriceが600でない場合 if itemList.TotalPrice != 600 { // テスト失敗 t.Errorf("itemList.TotalPrice = %v, want %v", itemList.TotalPrice, 600) } } このテストは実際にそのまま利用して関数のテストを行うことが可能です。 go test -v ./ === RUN TestNewItemList --- PASS: TestNewItemList (0.00s) PASS ok github.com/agest-inc/example/src/common 0.003s このように、実装に対するテストコードの提案をしてもらえることで、開発の補助ツールとして非常に有用であり、工数の削減に大いに役立っていると考えています。ただし、提案されたコードが100%正しいという保証はありませんので、内容の確認は自己責任で行う必要があります。 それでも、テストデータのコーディングの手間を省くことや、似たようなコードの繰り返しで一部変更を行う必要がある場合には、一定の効果があるのではないかと思います。 開発効率の向上 Github Copilotを使ってみると、開発効率が以前に比べて大幅に向上している実感があります。以前は、コードの一部を手動で入力する必要がありましたが、Copilotを使うと、コードの提案を受けることができます。これにより、時間を節約できるだけでなく、開発のスピードも大幅に向上しました。 また、Copilotは私のコーディングスタイルに合わせて学習していくため、提案されるコードは私の好みや習慣に合ったものが多くなりました。これにより、コードの書き方に一貫性が生まれ、保守性も向上しました。 さらに、Copilotは私の知識の不足を補ってくれる頼もしい存在です。新しいライブラリやフレームワークに挑戦する際、Copilotが適切なコードの提案をしてくれるため、学習の助けになりました。これにより、新しい技術への取り組みもスムーズになりました。 この中でも最もおすすめな活用方法は、テストコードの実装です。効率的に実装できるだけでなく、想定していないテストパターンなども提案してくれる可能性があるという点もメリットだと思います。 一つ気をつけるべきなのはGithub Copilotがコードを作成してくれるのではなく、補助してくれるという意識で利用する必要があるという部分です。あくまでAIによる提案であり、確実に意図しているような実装を提案してくれるわけではないため、最終的な実装は自身の目で確認しながら利用していくということを意識していないと誤った実装をそのまま適用してしまいかねません。 それさえ意識していればとても便利に利用することができると思います。 結論 Github Copilotは、開発効率を劇的に向上させることができる素晴らしいツールです。コーディングの補完や提案により、時間の節約や一貫性の確保、知識の補完といった恩恵を受けることができます。私のように開発プロセスを効率化したい方には、ぜひGithub Copilotを試してみていただきたいです。 The post GitHub Copilotを使ってみたら開発効率が劇的に向上した話 first appeared on Sqripts .

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。 第11回目のテーマは、「エクストリーム・プログラミング（XP）」です。前回は原則と基礎プラクティスを解説をしたので、今回は応用プラクティスを解説します。 この内容はUdemyで公開しているオンラインコース「 現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編 」の内容を元にしています。 XPの応用プラクティス：実顧客の参加 ひとつめは「実顧客の参加」です。第1版では「オンサイトユーザー」でした。 ユーザー VS チームという構図をなくすためには、ユーザーを巻き込んだ開発が必要です。可能であれば、ユーザにもチームの一員として入ってもらうのも手です。 顧客の参加方法もいくつか選択肢があるはずです。たとえば、定期的に開発現場に来ていただくこともできますし、客先にスペースを作ってもらってそこで作業することもできます。 どちらにせよ、顧客と開発を切り離してはなりません。 XPの応用プラクティス： インクリメンタル配置 2つ目が「インクリメンタル配置」です。 配置というのは成果物を環境に配置する「デプロイ」を指しています。当時はデプロイという言葉が一般的ではなかったのだと思います。XPではイテレーションごとに成果物をインクリメンタルにデプロイを繰り返します。 正確に訳すなら継続的デプロイメントですが、今風な言い方にするなら継続的デリバリー（CD： Continuous Delivery）が近い言葉でしょう。つまり、デプロイやリリースの自動化です。 XPの応用プラクティス： チームの継続 3つ目は「チームの継続」です。 XPを続けるチームは、成熟度が高まっていきます。これをリリースごとに解散するのはもったいない話です。可能な限りチームを固定し、継続的に意欲的に開発に取り組んでもらえる体制を作ります。 従来型だとプロジェクトが終わるとチームが解散しますが、アジャイル開発はチームを中心にメンバーが構成され、メンバーをできるだけ固定しながら開発を進めていき、チームの成熟度を高めていきます。 XPの応用プラクティス： チームの縮小 4つ目は「チームの縮小」です。 これはチームをスケールさせる、もともとはトヨタ生産方式のプラクティスだそうです。たとえば、まずアジャイルチームをひとつつくり、生産性や効率性を高めていきます。そして、そのなかの1名をチームからはずし、新しいアジャイルチームの立ち上げで活躍してもらう・・・。このようなやりかたで、チームをスケールさせていきます。 この方法は、今ではアジャイル開発を横展開するときの王道の方法でもあります。 XPの応用プラクティス： 根本原因の分析 5つ目は「根本原因の分析」です。 トヨタがやっていることで有名な「なぜなぜ5回」という方法があります。なぜを5回繰り返すことで、根本原因に辿り着こうとする手法です。なぜなぜ5回と同じように、問題の原因を深堀りしていきます。そうしなければ、上辺だけの解決方法になってしまい、問題がまた再発してしまうからです。 ただ、根本原因にすぐとりかかるのが難しい場合もあります。そういう場合は、まずは短期的な対策を考えて進め、それと同時に長期的な対策をセットで考えるのも手です。 XPの応用プラクティス： コードの共有 6つ目は「コードの共有」です。第1版だと共同所有というプラクティスでした。 現在は、GitHubやGitLabなどのコード管理サービスが広く使われているので、コードの共有はあたりまえのプラクティスと言えます。しかし、XPの書籍がでてきた当時は、共有ファイルサーバにコードを置くなどの運用でカバーしていました（本当に辛かった）。 コードの扱い方については、ブランチ戦略や、プルリクエスト、コミットしたものをわすれずにPushしておく・・・などといったプラクティスへと広がってきています。 XPの応用プラクティス： コードとテスト 7つ目は「コードとテスト」です。当たり前のことですが、コードとテストはもっとも重要な成果物です。 XPでは、これらを使って別に必要なドキュメントを作ることも推奨しています。Javaの世界だと、ビルドツールでJavadocなどさまざまなドキュメントをアーティファクトとして自動生成したりします。 XPの応用プラクティス： 単一のコードベース 8つ目は「単一のコードベース」です。 現在だと、Git flowのように、さまざまなブランチ戦略が使われていますが、XPでは、コードベースを単一にするのを推奨しています。 Googleでも単一コードベースのほうが効率がいいとされています。 単一コードベースだと管理がシンプルになり、マージコストも下がります。ただし、単一のコードベースは複数チームでの開発のように、開発者の人数が増えると運用が大変にもなってきます。それぞれの現場にあわせて選択すると良いでしょう。 XPの応用プラクティス： 日次配置 9つ目は「日次配置」です。第1版では短期リリースと呼ばれていたものです。最近だとデプロイ回数を指標として計測するチームも増えています。 日次配置は、いわゆる日次デプロイです。ただ、これを実現するには「コードとテスト」や「インクリメンタル配置」といったプラクティスが必要になります。 このように、XPのプラクティスはそれぞれがゆるく連携しているので、どれか一つを導入してみて、関係するプラクティスの導入を進めていくといいでしょう。 XPの応用プラクティス： 協議によるスコープ契約 10番目は「協議によるスコープ契約」です。 開発を請け負う場合、契約が重要になります。ただ、従来型のように長いプロジェクトとなると、スコープが大きくなり、契約も長くなり、柔軟性が低くなってしまいます。 よって、契約も短く区切り、スコープを調整していきます。スコープには、スケジュール、費用、品質が含まれるので、それぞれを議論してスコープを決定していきます。 XPの応用プラクティス： 利用分払い 11番目は「利用分払い」です。 ユーザは利用した分だけシステム利用料を払う形の課金方法です。従来型だと見積もりをベースに納品後一括支払いが多いでしょう。しかし、XPではお金じたいもフィードバックの一つとして考えているようで、使った分、いただく・・・という形を提唱しています。 この方法は、現在だとSaaS型のサービスに似ています。SaaS型のサービスは、サブスク型の課金が多いので、毎月や毎年の単位で、特定の額を支払います。そう考えると、20年近く前にでてきたXPが、SaaSのサブスク型支払いをプラクティスとしているなんて、XPの先見性にびっくりしてしまいます。 以上が応用プラクティスです。 特にXPのプラクティスは、現在でも利用できる物が多く、あとで説明するスクラムと組み合わせることで、有効性を高められます。たくさんあるので、まずは概要だけでも覚えていただき、アジャイル開発を実践するときに、思い出しながら導入していただければと思います。 連載一覧 第1回：アジャイル開発の過去、現在、未来を知ろう！ 第2回：声に出して読みたいアジャイルマニフェスト 第3回：従来型開発とアジャイル開発の違い　その１ 第4回：従来型開発とアジャイル開発の違い　その２ 第5回：アジャイル開発のよくある誤解を解いていこう！ 第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発 第7回：わかるようでわかりにくいスクラムチームの責任 第8回：スクラムイベントの実践方法 第9回：エクストリーム・プログラミングとその価値 第10回：エクストリーム・プログラミングの原則と基礎プラクティス 第11回：エクストリーム・プログラミングの応用プラクティス The post 第11回 エクストリーム・プログラミングの応用プラクティス first appeared on Sqripts .

こんにちは。ノウンです。 私が普段対応しているテスト業務の中にWebサイトのテストがあります。テストはPC以外にスマートフォン（以下スマホ）を使って行うこともあります。 今回は、スマホでWebサイトのテストを行う場合に、PCのブラウザの標準機能であるデベロッパーツール（開発者ツール）を使ってテストする方法を紹介したいと思います。 スマホのみでもWebサイトのテストを実施することはできるのですが、デベロッパーツールも使用してテストするメリットがあります。 はじめに スマホを使ってWebサイトのテストを行う場合は、主に表示やサイト内の機能（ボタンなど）のテストを行うことになります。その他にも例えば、Webサイトの要素に記述されているタグがブラウザ上で動作して通信が行われているか？（この動作のことを「タグが発火する」と言います）をスマホのブラウザでデベロッパーツールを開いて確認することも可能なのですが、確認するにはスマホ1台ごとにアプリのインストールが必要で、スマホはそもそも画面サイズが小さいためデベロッパーツールが見辛く操作しにくいです。 PCで設定を行っておけば、スマホ1台ごとにアプリをインストールすることなく、スマホのブラウザのデベロッパーツールをPC上で確認・操作できるようになります。 なお、PCでデベロッパーツールのエミュレート機能（UserAgent偽装）を使えば、PCで「スマホを使用してサイトを閲覧している」という状態を疑似的につくり出してテストをすることもできます。「じゃあ、全部PCでエミュレート機能を使ってテストすれば問題ないのでは？」となりますが、その場合「スマホでサイトを閲覧した時だけ表示が崩れる」等の、スマホ端末のみで発生する不具合を発見できない可能性があります。 私が過去に遭遇した事例もあります。（後に紹介します） スマホで見ているサイトに対してPCのデベロッパーツールを使用することで、PCでWebサイトのテストを行っている時と同じ情報をスマホで確認できることから、タグの発火をリアルタイムで確認できたり、HTML/CSSの確認やJavaScriptエラーの有無等も併せて確認できる様になります。 なお、デベロッパーツールを使用したタグの発火テストについては、以前に下記の記事を投稿していますのでそちらも参考にしていただければと思います。 ■ GoogleAnalytics利用時に組み込むタグのテストについて スマホでPCのデベロッパーツールを使用する手順 今回紹介する方法は、使用するスマホ端末によってUIの違いはありますが、どのスマホ端末でも実行できる内容となっています。 まず「Android & WindowsPC」、次に「iPhone & MacPC」を使う手順を説明します。 Android & WindowsPC（Chromeを使用） 以下の端末を使用した場合で説明します。 Android端末＆Windows10 Pro 1. PCにAndroid Studioをインストールする 以下のURLにアクセスして、Android Studioをダウンロード→インストールします。 Android Developers インストールは、表示される画面に沿って進行すれば大丈夫です。迷う要素は特に無いと思いますが、公式のヘルプがありますので必要に応じてご参照ください。 Android Studio をインストールする 2. Android SDKの設定を行う スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されるようにします 3. 「Tools」メニュー＞「SDK Manager」を選択 4. 「SDK Platforms」タブで、使用するAndroidのOSにチェックを入れる 5. 「SDK Tools」タブで、「Android SDK Platform-Tools」が「Installed」になっていることを確認（「Not Installed」になっていたらチェックを入れる） 6. 「OK」または「Apply」を押下してインストールを実行する（インストールが不要な場合は「Cancel」ボタンでウィンドウを閉じる） これで、スマホでPCのデベロッパーツールを使用する場合に必要となるドライバが適用されます。 7. ADBコマンドを有効にする ADBとは、Android Debugging Bridge のことで、コマンドを有効にするとAndroid Studioを使ってPCでスマホの開発をしたり、コマンドプロンプトからスマホを操作したりと、スマホのみでは行えない操作をPCから行うことが可能となります。 今回はスマホでデベロッパーツールを使用する際、スマホのUSBデバッグが正常に動作するように設定を行います。 設定する際、あらかじめ手順「5」の画像上部「Android SDK Location:」に表示されているフォルダパスを控えておくとスムーズに設定できます。 8. WindowsPCのタスクバーにある「スタート」ボタンを右クリック＞「システム」を選択 9. 「システムの詳細設定」を選択 10. 「詳細設定」タブ＞「環境変数」を選択 11. システム環境変数 の「Path」を選択＞「編集」ボタンを選択 12. 「新規」ボタンを選択＞Android Studioをインストールした時に一緒にインストールされた、フォルダ「platform-tools」のフォルダパスを入力 13. 開いている各ウィンドウを「OK」ボタンを押下して閉じる 【注意】手順13.で「キャンセル」ボタンを押下すると、ここまでの設定が反映されないため、必ず「OK」を押下して各ウィンドウを閉じてください。 14. PCを再起動する 15. ADBコマンドが有効になっているか確認する ここまでの設定が反映されているか確認を行う。WindowsPCの「コマンドプロンプト」を起動する （「スタート」アイコンをクリック＞「 cmd 」で検索＞コマンドプロンプトを選択。または、タスクバーの検索アイコン・検索ボックスから「 cmd 」で検索＞コマンドプロンプトを選択） 16. 「 adb 」と入力してEnterキーを押下する 17.画像の様にコマンドの引数（内部デバッグ[internal debugging:]、USBの接続[usb:] などの情報）が一覧になって出てくれば、ADBコマンドが有効になっている ※ADBコマンドが有効になっていない場合、下記エラーメッセージが表示されます。ここまでの設定や入力した文字列に誤りが無いか確認してみてください。 18. Androidの「開発者向けオプション」を表示する Androidの「設定」＞「デバイス情報」＞「ビルド番号」の部分を連続で7回タップする ※Androidによって「ビルド番号」の表示箇所が異なる場合があります 19. 「開発者向けオプション」を有効にする 「設定」＞「システム」＞「開発者向けオプション」を選択して「開発者向けオプションの使用」のトグルボタンを有効にする 20. 「USBデバッグ」を有効にする 「USBデバッグ」のトグルボタンを有効にして表示されたウィンドウで「OK」を選択する 21. AndroidとWinPCを接続する Android端末のUSB端子形状（Type C）に合ったケーブルでAndroidとPCを接続して、Androidの画面に表示されるウィンドウで「許可」を選択する 22. AndroidのChromeでテスト対象ページを開く 23. WinPCのChromeを開き、アドレスバーに「 chrome://inspect/#devices 」と入力してアクセスする 24. 接続しているAndroidの端末名とブラウザ、テスト対象ページのURLがWinPCのChromeに表示されるので、URLの下にある「 inspect 」を選択する 25. デベロッパーツールが開く WinPCのChromeの左側にAndroid端末の画面、右側にデベロッパーツールが表示される 26. デベロッパーツール内の通信情報を確認 スマホでアクセスしたWebサイトを操作して、デベロッパーツールでWebサイトの通信情報を確認する。画像は「Network」タブに情報が表示されている状態 iPhone & MacPC（Safariを使用） 以下の端末を使用した場合で説明します。 iPhone端末＆iMac 1. iPhoneでWebインスペクタを有効にする MacPCでiPhoneのデベロッパーツール（Webインスペクタ）を表示させるには、iPhoneの設定を行う必要があります。 iPhoneの「設定」＞「Safari」＞「詳細」＞「Webインスペクタ」のトグルボタンを有効にする 2. MacPCのSafariで開発メニューを表示する MacPCのSafariは、デフォルトの設定ではiPhoneのWebインスペクタを開くためのメニューが表示されていないため、設定を行う必要があります。 Safariを起動＞「Safari」メニュー＞「環境設定」＞「詳細」の「メニューバーに開発メニューを表示」にチェックを入れる 3. iPhoneとMacPCをライトニングケーブルで接続する 4. iPhoneのSafariでテスト対象ページを開く 5. MacPCで、接続したiPhoneを選択する Safariの「開発」メニュー＞接続したiPhone＞テスト対象ページのURLを選択する 6. Webインスペクタが開く 7. Webインスペクタ内の通信情報を確認 iPhoneでアクセスしたWebサイトを操作して、WebインスペクタでWebサイトの通信情報を確認する。画像は「ネットワーク」タブに情報が表示されている状態 過去の不具合事例紹介 スマホまたはPC（UserAgent偽装）いずれかのみのテストでは発見できない、または発見が遅れる不具合の事例について、私が過去に遭遇したことがある2つの例を紹介します。 事例1　テキストの改行位置が不自然 PCのデベロッパーツールでUserAgent偽装を使用して確認した場合は問題なかったのですが、同じ文章をスマホで確認したところ、テキストが不自然に改行された状態で表示されていました。 文末の「す。」が不自然に改行された状態になっています。 これは、画面サイズにより改行される位置が変わってしまうこと、フォントの指定を行っておらずWebサイトを閲覧する端末のOS毎のテキストの微妙なサイズ違いによりスマホで閲覧した時とPCで閲覧した時でデザインが異なることが原因でした。 文字欠けがある訳では無く不要な文字が表示されている訳でもありませんが、見た目が良くないため後に修正対応されました。 事例2　スマホのみで発火するタグが発火しない スマホで見ているサイトに対してデベロッパーツールを使用してタグの発火を確認したところ、タグが発火していませんでした。 しかし、PCのデベロッパーツールでUserAgent偽装を使用して確認した場合は、タグが発火していました。 スマホでタグが発火していないのにPCでは発火している、ということは、タグが動いてはいることは間違いないのでタグ設定内容に問題があるのでは？…という推測から調査したところ、その通りでタグ設定に誤りがあったことが原因でした。 （具体的には、タグの記述でUserAgentを指定しており、スマホのUserAgentが指定されていませんでした） スマホとPCを接続してテストを行ったことで、PCでUserAgent偽装でテストをしていただけでは検出できなかったかもしれない不具合を検出することができました。 なお、今回のケースでは「タグの発火確認」がテスト観点として存在したためPCとスマホを接続してデベロッパーツールを適用したテストを実施しましたが、例えばテキストの誤字脱字の確認や、タグの記述にUserAgentの指定が無いことが明確な場合など、UserAgent偽装を使用した方が効率よくテストを行えるケースは少なくないため、常にスマホとPCでデベロッパーツールを使用することが必要ということではありません。 テスト内容によって使い分けることで、テストを効率化できたり質を向上させることが出来ます。 スマホのサイトでデベロッパーツールを使う場合の追加メリット Androidの場合、スマホのWebサイトでPCのデベロッパーツールを使う場合の追加メリットとして、デベロッパーツールにスマホの画面が常時映し出されていて、PCでスマホの画面を操作できるため、マウス・キーボードを使ってスマホサイトの操作が可能になります。タップ操作だけではなくスワイプ、文字入力も可能です。 これにより、入力フォームの項目が多いページや、細かい部分をタップ・スワイプした時の挙動の確認など、スマホでは手間だったり操作しにくかったりする部分が確認しやすくなります。 なお、iPhoneの場合はデベロッパーツールにスマホの画面が映し出されないため、残念ながらPCでのスマホの画面操作は不可能です。 おわりに 今回はPCのブラウザ機能であるデベロッパーツールをスマートフォンで使用する方法を紹介させていただきました。 Webサイトのテストを行う環境の例として、PC・スマホ・デベロッパーツールのエミュレート機能・スマホ＋デベロッパーツールがありますが、どの環境でテストを行うべきかはテストの内容により異なります。 「スマホ＋デベロッパーツール」は他の環境と違い、使用するには準備に手間が必要です。 ただ事前に設定をしておくと、その後はPCと接続するだけでいつでもデベロッパーツールを使用することができますので、スマホ＋デベロッパーツールでテストを行う必要がある場合はぜひ使ってみてください。 The post Webサイトテスト時の便利技・PCブラウザのデベロッパーツールをスマホで使おう first appeared on Sqripts .

テストエンジニアが身につけておきたいスキルの一つに「論理スキル」があります。 この連載では、「プログラムのレベル」「文や文章のレベル」に分けて、論理スキルの基本である「論理の言葉」を徹底解説します。 第1回の今回は、論理スキルが重要である理由、身につけておくべき理由を解説します。 論理(ロジック)の話をする理由 “論理的”とは ビジネスの場でしばしば重要とされることのひとつに、“論理的であること”があります。 「論理的に考える/話す」「論理的な文章」など、耳に(目に)することも多いと思います。 ここでいう“論理的”とは、「矛盾や不整合、飛躍や欠落が見られない」「首尾一貫している（筋道が立っている）」……といった特徴を指していると言えるでしょう。 ソフトウェアは論理の塊 ソフトウェアはその殆どの工程/作業を通して“論理的”に構築されます。とりわけ、以下のような…… AとBで○○を計算する。その結果がCなら、その結果を用いてDを計算する。そうでなかったら、Eを用いてFを計算する αの状況で、利用者がβという操作をしたら、画面をγに切り替えてδという動作をする 処理ができない状況になったら、処理を続行せずに停止する etc. どんな場合に何をするのか(してはいけないのか)といった“条件/場合”に応じた処理/動作は 矛盾や欠落がないように しなければなりません。 また、どの工程の成果物(文書類)でも、その記述内容に 食い違いや不明瞭な箇所があると 、構築したソフトウェアが適切な動作をしなかったり、暴走やフリーズに至ることもあります。こうした意味で、論理(ロジック)はソフトウェア開発の“生命線”とでも言えるでしょう。 テストにとっても論理は大切 テストをする立場にとっても論理(ロジック)は重要です。 テスト対象の振舞いを、自分の解釈を加えたり想像で補ったりせずに、テストベースの記述の 筋道を辿って 理解する （テスト対象を操作しながら理解することもありますが、その場合は「どんな場合にどうなるのか」などを自分の頭の中で整然と組み立てていくことになります） テストすべきことを 当てずっぽうや思いつきではなく 根拠を持って、 筋道を立てて 考える 本記事では、“論理的”に考えるための「基本的な道具」である「 論理(ロジック)の言葉 」をいくつか見ていきます。 以下のような人に読んでもらうことを想定しています。 テストエンジニアとして、読解力、設計力を強化したいと考えている人 論理演算などを復習したい人 （これからテストエンジニアを目指す人にもお勧めです！） （ただし、テスト対象を理解したりテストすべきことを考えたりするのに、「論理の言葉」をひねり回すだけで十分というわけではありません。頭の中で考えるだけでなく、 考えたことを図に表すなど視覚化 してみて理解を確かめたりチェックしたりすることも大切です） 「筋道を辿る/筋道を立てて考える」とは 「筋道を辿って理解する」「筋道を立てて考える」ってどんな感じのことなの？　と思う人もいると思います。かんたんな“例題”で体感してみてください。 “論理パズル” この国のどこかに、正直者と嘘つきが住む村があります。 正直者は常に正しいことを言い、嘘つきは常に正しくないことを言います。村にはこの2種類の人間しかいません。 この村を歩いていたら、二人の住人AとBに出逢いました。Aは言いました。「私たちは二人とも嘘つきだ」 （【出典】『記号論理学　一般化と記号化』(スマリヤン / 丸善出版　問題1.3) A, Bは、それぞれ正直者でしょうか、嘘つきでしょうか。 （ぱっと解答に辿り着けなくても気にすることはありません。ソフトウェア業界人なら誰でもこうした“論理パズル”がすらすら解ける、というわけではありません（筆者も論理パズルが苦手です(´・ω・｀)）） ※この論理パズルの考え方を文末に掲載しています。 どう考える？① ある遊園地のあるアトラクションに、次のような注意書きが掲げられていました。 本アトラクションは以下の方のみ利用できます。 ・身長130センチ以上190センチ以下 ・体重90キログラム以下 ・年齢満15歳以上 このアトラクションを利用できる人/できない人はどんな人でしょうか。 どう考える？② とあるシステムのユーザーアカウント名の仕様です。登録できるユーザーアカウント名には以下の条件があります。 (a) アカウント名に使える文字は以下のいずれかに限ること 半角英大文字(A～Z), 半角英小文字(a～z), 半角数字(0～9) (b) アカウント名は16文字以下であること (c) 既に登録済みのアカウント名は登録できない 新規ユーザーとして登録できないアカウント名文字列はどのようなものでしょうか。 論理的に考えることは、“スキル” 誰でも身につけることができるスキル “論理的”に考えることは、持って生まれた何か特殊な才能やセンスによるものではなく、「論理の言葉」の意味や働きの理解・習得を通して身につけるスキルです。 言葉と言葉、文と文のつながりを把握し、条件や場合とその結果とのつながりを丁寧に結びつけて、文章の筋道を把握する 主張と根拠のつながりを明確にする 才能/センスということでいえば、 誰しも物心ついた時から論理の才能/センスを育んでいる と言えます。誰しも、日々の生活や勉強、仕事などを通して（無意識的にでも）「論理的に考える」ということをいくらかは学んでいるからです（100%徹頭徹尾非論理的に考え、生きる人間は、たぶん一人もいません）。 意識を向ければ、その分(早く)上達する 、というわけです。 誰しも身につけておきたいスキル ソフトウェアやソフトウェアテストを離れてみても、論理のスキルは身につけておきたいスキルです。 “論理的”に考えることは、文章を読んだり話を聞いたりする上でも大切ですし、「報告・連絡・相談」をはじめとするコミュニケーション全般の質を左右するのは、 「話が一貫しているか、整合が取れているか」「言うべきこと、言いたいことを適切に表せているか」 ということだからです。 “裏づけ”を知っておこう ここまで読んで、次のように感じた人も相当数いると思います。 「何を当たり前のことを言っているんだ？」 「特に勉強をした憶えはないけど、全然困ってないぞ！？」 そう感じた人は、自信を持ってよいと思います。意識せずに論理のスキルを身につけているのは素晴らしいことです。 そういう人も、「当たり前のようにできていること」にも基礎や裏づけがあると知っておくのは悪いことではありません。基礎や裏づけは「なぜそう考えるのか」を説明する助けになってくれるからです。 むすび これから何回かに分けて「論理(ロジック)の言葉」をいくつか取り上げ、その意味や働き、注意点などを紹介していきます。 プログラムレベルのロジック……基本の論理演算 文レベルのロジック　……文や文章の筋道を把握するための論理の言葉 （これだけですべて、というわけではないので、タイトルに「入門」とついています） なお、本記事は 「ロジカル・シンキング」を解説するものではありません 。ロジカル・シンキングは主にビジネスコミュニケーションにおける体系的な思考・発想の技術です（本記事で取り上げる“論理のスキル”は、その中の一部として関係はしますが、イコールではありません）。 “論理パズル”の考え方 Aが正直者だとすると、「私たちは二人とも嘘つきだ」はA自身も嘘つきと言っていることになってしまい、矛盾します。 従って Aは嘘つき で、「二人ともに嘘つきだ」は正しくありません。ということは、二人のうちどちらかが正直者ということになります。 （「二人とも正直者」という可能性もありますが、2でAは嘘つきと判明しているので、これはあり得ません） Aが嘘つきなので、 Bは正直者 です。 ※なんでそうなるの！？　と思った人は、「 [第3回] プログラムレベルのロジック (2)解説編・基本の論理演算」をご覧ください！ 参考文献 『入門！論理学』(野矢茂樹 / 中央公論新社) 『新版　論理トレーニング』(野矢茂樹 / 産業図書) 『記号論理学　一般化と記号化』(スマリヤン / 丸善出版) The post [第1回] なぜ、テストエンジニアに(も)論理のスキルは重要なのか first appeared on Sqripts .

こんにちは、QAエンジニアの リキオ です。 ご存知の方も多いとは思いますが、QA業務ではしばしば、テスト設計時における仕様などの質問を「QA管理表」、またはテスト実施時における不具合を「不具合管理表」として、スプレッドシートやExcelなどに一覧化して運用する場面があります。このとき、一覧表に対してテストリーダー等の管理者のみが運用したとき、下記のような問題が生じる可能性があります。 情報の偏在： 記載者及び管理者にのみ情報が偏在するため、他のステークホルダーにまで共有されず、QA業務に影響を及ぼす場合がある。また、重複起票などの副作用も併発してしまう可能性もある。 テストプロセスの遅延： 管理者の記載内容の見落としといったヒューマンエラーが発生する場合がある。例えば、一覧表の不具合をBTSに転記するような運用であれば、見落とした分だけ不具合の修正期間が遅延してしまう。また、不具合の影響度や修正コストによっては、プロジェクト規模で影響を及ぼす可能性もある。 本記事では、スプレッドシートに記載された内容をGoogleAppsScripts（以下、GAS）を使用してチャットツール（テスト関係者のチャットグループ）に通知することで、上記のような問題を解決する試みをご紹介したいと思います。業務の最適化や効率化などに少しでもご活用いただけると幸いです！ ※ </Sqripts> では、以下のようにGASに関する記事もいくつかあるので、ご興味のある方は是非ご覧ください！ 業務改善にはコレ！＼Google Apps Script／ Google Apps Scriptを使ってGoogleスプレッドシートとCloud SQLを連携 GoogleAppsScriptを使ってテスト項目書の体裁を一発で整える 事前準備 1. スプレッドシートを用意する それでは早速解説していきます。まずはじめに、前提条件としてチャットツールへの連携元が必要となるため、スプレッドシートにて下図のような表を作成しました。こちらに記載された情報をピックアップして通知させていきたいと思います。 2. チャットツールにアプリを追加する 次にスプレッドシートの連携先となるチャットツールにアプリを追加しましょう。今回はSlackを例に、付属アプリである「Incoming Webhook」をご紹介したいと思います。 ※GoogleChatでも同様に、「Webhook」というアプリを追加することで連携可能です。 Incoming Webhookの追加方法 1.　対象のグループのチャンネル詳細設定の「インテグレーション」タブからアプリを追加します。 2. 「Incoming Webhook」を追加し、インテグレーションの設定を行います。設定した内容は保存しておきましょう。 各設定の概要は、以下の通りです。 チャンネルへの投稿 ：通知先対象のチャンネルを指定します。（上図では「通知先のチャンネル」というグループを指定しています。） Webhook URL ：アプリのユニークなURLです。GASで連携する際は宛先としてこのURLを指定します。 説明ラベル ：用途などを自由に記載することができます。 名前をカスタマイズ ：投稿時の名前を設定することができます。 アイコンをカスタマイズする ：投稿時のアイコン画像を設定することができます。（今回は「</Sqripts>」のアイコンを設定してみました。） 以上で事前準備は終わりです。 コーディング＜基本編＞ 続いて、スプレッドシートからGASを起動し、コーディング作業に入りましょう。GASは、スプレッドシートの拡張機能タブ ＞ Apps Script から起動することができます。 1. 対象のスプレッドシート・シートを取得する はじめに、実行対象となるスプレッドシートを取得しましょう。関数名は「chatNotice」としています。 function chatNotice() { //対象のスプレッドシートの取得 const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const activeSheetName = SpreadsheetApp.getActiveSheet().getName(); const sheet = activeSheet.getSheetByName(activeSheetName); 「getActiveSpreadsheet」メソッドと「getActiveSheet」メソッドを活用し、アクティブ状態のシート（スプレッドシート上で現在開かれているシート）を実行対象となるようにコーディングしているので、シート名に依存せずに実行することができます（間接参照）。言い換えれば、実行対象以外のシートがアクティブだった場合にも処理が走るので、少し注意が必要です。 2. 記載された内容を取得する 次に、事前準備で用意したスプレッドシートのNo.2（芥川 龍之介）の情報を直値で取得してみましょう。 //記載内容の取得 const info = sheet.getRange(4, 3, 1, 3).getValues().flat(); 「info」という一次元の配列変数を定義し、記載内容を格納させます。（スプレッドシートに対する「4」行目の「3」列目から「1」行単位で「3」セル分取得する　⇒　info[0] = 1915, info[1] = 芥川 龍之介, info[2] = 羅生門　となるイメージです。） 3. 送信内容を設定する 続いて、2で取得した情報を活用し、送信する内容を設定します。 //送信内容の設定 const msg = ( "スプレッドシートに記載された内容を送信してみよう！" + "\\n" + "\\n" + "▼記載情報" + "\\n" + "・発表年　 ： " + info[0] + "\\n" + "・著者　　 ： " + info[1] + "\\n" + "・タイトル ： " + info[2]); このあたりはお好みで加工することができます。今回は下記のような内容になるように設定してみました。 4. 設定した通知内容を送信する 最後に、設定した通知内容をPOSTするメソッドをUrlFetchAppと呼ばれるクラスを用いて記述していきます。 //取得した情報の送信 const message = { 'text': msg } const options = { "method": "POST", "contentType" : "application/json", "payload": JSON.stringify(message) }; const result = UrlFetchApp.fetch('事前準備のインテグレーション設定で生成したURL' , options); } 以上でコーディングは完了です。 実行結果 GASの実行結果がこちらです。 無事に送信されました！インテグレーションの各設定や記載情報も想定通りになっています◎ 以上が基本的な連携方法となります。 コーディング＜応用編＞ 最後に、QA業務での活用事例をご紹介します。QA業務ではしばしば、テスト設計時における仕様などの質問を「QA管理表」、またはテスト実施時における不具合を「不具合管理表」として、スプレッドシートに一覧化して記載する場合があります。 応用編ではこういった場面を想定し、不具合管理表を例に、不具合情報を抜粋して通知する方法をご紹介したいと思います。 対象の不具合管理表 対象の不具合管理表として、下図のような内容を用意しました。 今回は概要レベルで通知する用途を想定しているので、「起票日」「起票者」「タイトル」の3点をピックアップし、チャットグループに送信したいと思います。（「ステータス」や「詳細」は、通知内容としては冗長になりかねないので省略しています。） 送信エリア 上記を実現させるために、B2～C3セルに「 送信エリア 」を設けました。 B2、B3セルの「 No. 」に、スプレッドシートの「データの入力規則」を使って、一覧表で該当するNo.を プルダウンリスト形式で出力する処理を入れています。 また、A列のNo.には「=IF(ステータス=””,””,ROW()-ROW($A$5))」といった関数を記述しているため、未記載の不具合といった不要なNo.を出力しないように制御しています。 C2、C3セルの「 送信ボタン 」ではボタンの図形を描画し、そこにGASを割り当てています。 したがって、不具合が記載されたとき、不具合の起票者が自ら記載した不具合のNo.をB2セルの「No.」で選択し、C2セルの「送信」ボタンで関係者のチャンネルに投稿するような運用を想定した内容となっています。 コーディング内容 基本的には「コーディング」章で紹介したコードとあまり変わりませんが、応用編として少しだけ手を加えています。詳細は下記で解説します。 /** - 新規に記載した不具合をSlackに送信する。 - 送信する情報は以下3点。 - ・起票日[data] - ・起票者[tester] - ・タイトル[title] - / function bugNotice() { //対象のスプレッドシートの取得 const activeSheet = SpreadsheetApp.getActiveSpreadsheet(); const activeSheetName = SpreadsheetApp.getActiveSheet().getName(); const sheet = activeSheet.getSheetByName(activeSheetName); //不具合情報の取得 const bugNo = sheet.getRange(3, 2).getValue(); const bugInfo = sheet.getRange(bugNo + 5, 4, 1, 3).getValues().flat(); //通知内容の定義 const data = Utilities.formatDate(bugInfo[0], 'JST', 'yyyy/MM/dd'); const tester = bugInfo[1]; const title = bugInfo[2]; //通知内容の設定 const msg = ( "不具合が起票されました。" + "\\n" + "\\n" + "▼記載情報" + "\\n" + "・起票日　 ： " + data + "\\n" + "・起票者　 ： " + tester + "\\n" + "・タイトル ： " + title); //確認ダイアログの表示 const confirmdlg = Browser. msgBox("送信確認", "Slackに以下の内容を送信しますか？" + "\\\\n" + "\\\\n" + "▼記載情報" + "\\\\n" + "・起票日　 ： " + data + "\\\\n" + "・起票者　 ： " + tester + "\\\\n" + "・タイトル ： " + title, Browser.Buttons.YES_NO); if (confirmdlg == "yes") { ; } else { return false; }; //取得した情報の送信 const message = { 'text': msg } const options = { "method": "POST", "contentType": "application/json", "payload": JSON.stringify(message) }; const result = UrlFetchApp.fetch('事前準備のインテグレーション設定で生成したURL', options); } 不具合情報の取得 //不具合情報の取得 const bugNo = sheet.getRange(3, 2).getValue(); const bugInfo = sheet.getRange(bugNo + 5, 4, 1, 3).getValues().flat(); 対象の情報を取得するために、はじめに「bugNo」という変数を定義し、getRangeメソッドを使って3行目かつ2列目である「送信エリア」の「No.」の値を取得しています。 続いて、「bugInfo」という一次元の配列変数を定義し、記載内容を格納させます。（スプレッドシートに対する「プルダウンリストで選択した値＋5」行目の「4」列目から「1」行単位で「3」セル分取得する　⇒　「送信エリア」の「No.」で「1」が選択されていた場合は、bugInfo[0] = 2023/10/01, bugInfo[1] = テスト 太郎, info[3] = ○○画面で△△したとき✕✕になる　となるようなイメージです。） 通知内容の定義 //通知内容の定義 const data = Utilities.formatDate(bugInfo[0], 'JST', 'yyyy/MM/dd'); const tester = bugInfo[1]; const title = bugInfo[2]; 「bugInfo」の内容を分かりやすくするために、配列の値をそれぞれ別の変数に置換して定義しました。また、取得した値が年月日の場合は、GASの特性上、文字列に変換する必要があるため、「Utilities」メソッドで日付形式（yyyy/MM/dd）に変換しています。 確認ダイアログの表示 //確認ダイアログの表示 const confirmdlg = Browser. msgBox("送信確認", "Slackに以下の内容を送信しますか？" + "\\\\n" + "\\\\n" + "▼記載情報" + "\\\\n" + "・起票日　 ： " + data + "\\\\n" + "・起票者　 ： " + tester + "\\\\n" + "・タイトル ： " + title, Browser.Buttons.YES_NO); if (confirmdlg == "yes") { ; } else { return false; }; 送信時の誤爆を防ぐために、確認ダイアログも実装してみました。ダイアログで「はい」を選択すると送信され、「いいえ」または「✕」ボタンを選択すると送信されない処理を記述しています。 インテグレーションの設定 インテグレーションの設定も併せて少しだけ変えました。 実行結果 実際に「不具合 No.3」を対象にして送信してみましょう！ 「送信エリア」の「No.」のプルダウンリストから「3」を選択し、 「送信」ボタンを押下すると、、、 スプレッドシート上に確認ダイアログが表示されました！ 確認ダイアログで「はい」を押すと、、、 無事、Slackに不具合内容が投稿されました！スタンプ等も活用するとより効果的に活用できそうです。 以上、より実践的にQA業務を意識した使い方のご紹介でした！ おわりに 「コーディング＜応用編＞」でご紹介した方法であれば、チャットグループ内に所属しているプロジェクトリーダー、テスト設計者やテスト実施者、あるいは開発者などの各プロジェクト関係者に対して、一律で仕様質問や不具合などを概要レベルで通知することができるため、「はじめに」でご紹介した例のような情報の偏在や属人化などが解消できたり、スピード感を持って課題を解消できたりする場合があります。その反面、質問や不具合が頻出するプロジェクトでは、通知が煩わしく感じることもあるので、使用する場合は適切な場面や使い道を見極めることを心掛けましょう。 ※もちろん、使用前にはステークホルダーに事前に確認を取るなどプロジェクト関係者への許可や配慮も必要です！ また、こうしたスプレッドシート × GAS などの機能を上手く組み合わせて、業務の最適化や効率化を図り、よりよいQA業務を実現させていきましょう！ The post スプレッドシートとチャットを連携してQA業務を効率化しよう first appeared on Sqripts .

私は仕事柄、所謂炎上プロジェクトの火消しや、前任PMが胃潰瘍で離脱して…といった「修羅場」をなんとか制御してクローズまで持っていくといった役割を担うことが多くあります。 ここで質問です、プロジェクトを成功させるには 炎上プロジェクトを鎮火する技術 プロジェクトを炎上させないようにする技術 どちらが大切だと思いますか？ １は火消しの技術が求められ、燃えている事や人を助けて、どうにかこうにかプロジェクトを纏めあげるテクニック。対して２はそもそもプロジェクトが炎上しないように先手を打ってコントロールするテクニックです。 炎上案件には社内の関心が集まり、立て直しがフォーカスされ、エース級やカネも投入、うまく鎮火されたなら盛り上がりもする「目立つ」プロジェクトです。他方、比較的スムーズに進むプロジェクトは目立たない存在です。要求事項を整理し、QCDを守って予算通りに納品しても「はい、OK」となって、大きな事象を発生させなかった、という功績はクローズアップされません。ですが、 本当に現場に求められ、プロジェクトが成功したと言えるのは２ です。 火消しは派手で目立ちますし、高難度で重要なテクニックです。同じように、 火を起こさないように見守っては火種を消してゴールすることは、往々にして目立たず疎かにされがちですが、その実践には多様なテクニックと理論・工夫が散りばめられ ています。 本連載ではプロジェクトマネジメントの全体像とプロジェクトを成功させる上で最低限抑えるべき知識と技術はもちろん、プロジェクトを炎上させないための技術やコツをお伝えしたいと思っています。みなさんのプロジェクトが今以上に充実し、笑顔でプロジェクト終結を迎えられるよう一緒に学んでいきましょう。 ＜参考と準拠＞ 本連載はプロジェクトマネジメントの国際規格であるISO21500:2012及びプロジェクトマネジメントの業界標準資格であるPMP ® （Project Management Professional）に準拠しながら、筆者の整理を加えた内容で記載しています。加えて、プロジェクトマネジメント講師としての経験や、プロジェクト現場で実行支援を行う中で得られた「実践的」なノウハウを盛り込んでいきたいと考えています。 プロジェクトとは、プロジェクトマネジメントとは プロジェクトの語源 「プロジェクト」の語源はラテン語で、PRO＝前方に（未来）、JECT＝投じる、投げるという意味があります。仕事でいえば、まさに前にある未来の目標に向かってアクションを投じていく姿そのものがPROJECTという単語のありようになります。 プロジェクトとは プロジェクトは「独自のプロダクト、サービス、所産を創造するために実施する、有期性のある業務」と定義され、特に 有期性・独自性 という点がプロジェクトの特徴と言えます。 独自性とは「新しい要素（過去に経験したことがない要素）が含まれる目的や目標」を指しますが、なにもまったく初めて！という大層なものである必要はありません。有期性とは「開始日と終了日が明確になっていること」であり、その期間において成果物を生み出す活動を行います。この２つの要素が入っていれば、たとえ「XXプロジェクト」と銘打たれていなくてもプロジェクトの性質を持ち、当然プロジェクトマネジメントの知識や技術を適用させることができます。プロジェクトと聞くと大規模インフラ事業やIT業界を想像することが多いですが、日々の業務或いはプライベートの活動の中にもプロジェクトは存在しています。例えば旅行の計画や引越し、就職活動なども独自の目的と期限を持つプロジェクトと言えるでしょう。また近年、企業や組織はその厳しい環境変化から絶えず独自性が求められるようになっており、 規模や業界に関わらず様々な業務がプロジェクト化してい ます。 プロジェクトマネジメントとは だれもが日常的にプロジェクトの参加者であるならば「改めてプロジェクトマネジメントを知る必要なんてあるのか？」「なんとなくできるから（できそうだから）大丈夫」というとそうではありません。プロジェクトを「マネジメント」することは、プロジェクトを 「その技術や経験を適用しながら、適切にヤリクリ（マネジメント）」 する必要があるからです。 プロジェクトマネジメントとは「プロジェクトの要求事項を満足させるために方法、知識、スキル、ツールと技法をプロジェクト活動へ適用すること」と定義されます。つまり、プロジェクトをどのように遂行するか計画を立て、プロジェクトの目的を達成できるようにコントロールしていくことです。またプロジェクト目標は未来にあるため、常に 「不確実性」 が存在します。その不確実性の中でいかに「目的・目標の達成角度を高める」か、その準備をしておきましょう。何のマネジメントもしなければ、プロジェクトは100％失敗します。 またプロジェクト実行時に適切な手法や方法を用いず実現可能性の低い目標設定を行う、適切な計画ができないということも起こりえるでしょう。 適切なプロジェクト実行に関する技術や技法は、プロジェクトの円滑な活動の必須要素 です。 プロジェクトやマネジメントの実務経験がある方でも、さらにその活動精度を高めるために、引き続き意識してそのプロジェクトマネジメントスキルを高めていっていただきたいと願っています。 プロジェクトマネジメントと定常業務マネジメント プロジェクトは「期限」を持つ有期的な活動です。その対の関係にあるのは定常的な業務、つまり無期的な活動です。 企業はこの有期的な活動と無期的な活動、２つの活動の組み合わせにより価値を生み出しながら事業運営を行なっています。 プロジェクト完了後はその活動から生み出したものを「定常業務化」つまり安定的に運用できるように受け渡します。「プロジェクトが終了したけれど、ずるずるタスクが残っている」「定常業務化したはずがうまく回らない」といことをよく耳にしますが、これらの受け渡しがが上手くいっていないケースです。 プロジェクト→定常業務という流れと定着化を意識 して各活動を進めましょう。 プロジェクトにおける制約と不確実性 プロジェクトは独自であるが故に情報や経験が十分でないにも関わらず、期限までに約束した成果物等を完成させなければなりません。プロジェクトが向き合う「敵」とも言えるのはこの不確実性であり、プロジェクトマネジメントの本質は「不確実性の中で活動をヤリクリすること」と言えます。 プロジェクトには多くの制約条件がありますが、中でもQCDが三大制約条件と言えます。この制約条件をマネジメントすることがプロジェクト成功の鍵です。また不確実性も確率論的な不確実性、曖昧さによる不確実性、複雑さによるものなど様々です。残念なことにこの不確実性の検討（洗い出し）や対処が後回しや、行われないことが少なくありません。不確実性の検討は容易な作業ではありませんが、それ以上に「もしこんなことが起きたら大変だ」と想像力を働かせ 「正しいマイナス思考」 を受け入れる体制が必要です。 プロジェクトでは制約や不確実性に対応する「完全な正解やマニュアル」は持っていません。プロジェクトの開始前から制約条件に優先度を付けたり準備することや、時には「実現不可能なプロジェクトを開始しない」という判断も必要になることを覚えておいてください。また、不確実性への対処は「リスクマネジメント」の回で触れていきます。 プロジェクトマネジメントのライフサイクル プロジェクトマネジメントの手法として代表的なのものが予測型ライフサイクルと呼ばれるウォーターフォール型（WF）適応型ライフサイクルと呼ばれるアジャイル型の２つです。そのほかに反復型・斬新型・ハイブリット型などがあります。 ウォーターフォール型は、プロセスやタスクを初期に計画した順番で完了させ、成果物を生み出す手法です。比較的長期のプロジェクトや明確な成果物がある場合に使われます。 アジャイル型は、優先的な機能や成果物を選択しながら２-４週間の短い期間で完成、その繰り返しで成果物を生み出す手法です。日本全体ではまだウォーターフォール型開発がマジョリティとして使われており、「これから」プロジェクトマネジメントを学ぶという方はこれらウォーターフォール型から習得するとよいでしょう。 プロジェクトの環境（組織のプロジェクトマネジメント） 複数のプロジェクトを運営して様々な経営課題の対処や戦略実現を目指す際に、それらを効率的にマネジメントする体制として「プログラム」や「ポートフォリオ」があります。 出典：OPM3を基に筆者が作成 プログラムとは複数の関連するプロジェクトや活動のグループです。ポートフォリオとは一般的に複数のプログラムやプロジェクト、活動のグループを指します。これらのグルーブにおけるマネジメントをそれぞれ「プログラムマネジメント」「ポートフォリオマネジメント」と呼びます。それぞれの効率的なマネジメントとなるように、プロジェクトやプログラム、その他の活動は組織戦略と整合が取れているか、プロジェクトやプロジェクトの成果は戦略目標達成に貢献しているか、作業状態の確認、限られたリソースの状況下でプロジェクトの優先順位を明確にし、整合のとれたリソース配分などを行います。 プログラムの性質 プロジェクトマネジメントが普及する中で、さらに複雑な概念であるプログラムが注目されています。プログラムとは複数の関連するプロジェクトや活動のグループとお伝えしたように、プロジェクトとプログラムは共通点がありますが異なる特徴も持っています。例えば 反復型の活動が含まれる場合があり定常業務に近い性質を持つ プロジェクトは目的の成果物を生み出したらその使命を終え解散するのが原則だが、プログラムはかならずしもそうではない などです。プログラムが解散するのはいつかとういうと、持っている戦略的な部分、目標自体が新しい目標に上書きされてプログラム自体の使命を終えた場合か、目標を達成する仕組みが完全に社会や市場、システムに定着して、これ以上の監視が必要なくなったような場合です。このように 成果の実現だけでなく、その維持・管理にも使命を負うというのがプログラムの特徴 の一つといえます。またそもそもプログラムには有期性が怪しいものがあります。プログラムでも通常は目標達成時期が決められていますが、プロジェクトと比較すると大変緩やかで「期限」と呼べるほど強い制約事項ではないケースが殆どです。 担当するプロジェクトの環境を確認した時、どのプログラムやポートフォリオに属しているか、あるいは属していないか、属している場合はプログラムマネージャーやポートフォリオマネージャーとの連携を図りながらプロジェクト活動を推進することが必要です。 さいごに 今後はリモート環境でのプロジェクトがスタンダードとなりグローバルプロジェクトの割合も増えていく中で、プロジェクトマネジメントという「共通言語としてのフレームワークや方法論」の重要性はより高まります。当然市場や社会情勢の変化の激しさに合わせて、プロジェクトマネジメントの方法論もアップデートが続いていくでしょう。まずは基本を押さえて、日々のプロジェクト、プロジェクトマネジメント活動へ適用しましょう。 今回は初回として、プロジェクトマネジメントとは何か？という大枠をみなさんと共有しました。 次回は、「PMの役割や必要な準備」についてお話しします。 The post 【第1回】プロジェクトマネジメントとは何か？ first appeared on Sqripts .

はじめまして、QAコンサルタントのしろです。 システムのステークホルダーやプロダクトオーナーから「品質ってどうなの？」って聞かれたとしたら、定量的なデータを示した説明をするのが良いですよね。「定量的」とはよく聞きますが、改めてソフトウェアの品質を説明するための定量的な指標をおさらいする意味で、色々なところで使われているソフトウェア品質の指標を一部ではありますが、ご紹介します！ 品質を表すために使われる定量的指標たち ソフトウェア開発の見積などで必要な指標など コスト これは様々な活動に対する必要な金銭、時間などの事です。こちらは品質自身を表す指標として使う事はないですが、コスト対効果など様々な形で登場します。特にシステム開発コストは品質を作るうえでも必要になりますのでしっかりと把握・確認しておくことは必要です。コストに該当するものは金銭、時間以外に心理コスト、認知コスト、肉体コストもありますが、定量指標としては使用することは難しいと思います。 工期 こちらは時間(期間)ですね。これも品質自身を表わす指標として使う事は余りないかと思います。しかしプロジェクトの期間は品質に影響を与える非常に重要な要素ですので明確にしておきたいです。 特に工期の遅れや、延長した。などの場合、品質にも影響を与えている可能性が高いため、その理由を確認しシステムへの影響を把握しておくことは、後の振り返りなどで必要になります。 工数 人時、人日、人月: 実際に作成に関わった時間のことですね。期間、リソースなどの要素をかけ合わせて算出します。1人が1時間稼働すれば＝1人時ですね。後は掛け算です。 勿論、これだけで品質の良し悪しが分かる訳ではありませんが、当初計画時の工数を大きく超えるような場合は、品質に何かしらの課題を抱えていると考えられます。 規模 LOC (Line of Code): お馴染みのコードの行数です。KLOC(キロ:1000行)やMLOC(メガ:100万行)もありますね。これらは測定方法、使用言語、作成者の書き方でかなり行数が異なるので信頼性に欠ける事がありますので、継続的に測定し品質指標として使う場合コーディング規約や測定ツールを整備してこの指標の数値の信頼度を向上させる必要があります。 LOC取得環境が整備されていれば最も使いやすい指標だと思います。是非とも活用することを検討してみてください。 FP (Function Point): 実装する機能に基づいてシステム規模を数値化する、言わずと知れたFP法による規模の測定です。ISO/IEC 20926:2009で規格化されています。FP計測手法として、IFPUG法、COSMIC法、フルファンクションポイント法、フィーチャーポイント法、MarkⅡ法、NESMA概算法、SPR法などがあります。 一番使われているIFPUB法によるFP計測の精度を向上させるには、設計仕様書が明確である必要があります。また更にFP計測を行うには工数もかかる。などもあり利用は簡単ではありません。しかしプログラムに実装される機能を一定の方法で数値化する事は、品質を測る上ではかなり有用な指標となります。 参考までにIFPUG法を使ったFPの計算手順は以下の通りです 扱うデータを外部入力(EI）、外部出力(EO)、外部照会(EQ)、内部論理ファイル(ILF)、外部インタフェースファイル(EIF)の５つのタイプに分類する 扱うデータごとに、「データ項目数」とそのデータに関連する「レコード種類数」を求め、それに従ってそのデータのファンクションの複雑さを３段階(低、中、高)に分ける 各データに、ファンクションの複雑さに応じた重み係数を掛けて合計し、システム全体の未調整FPを求める これまでの計算とは別に、対象とするシステムの特性を14の観点から０～５の６段階評価し、合計する(この合計値をXとする) システム特性係数＝ 0.65 ＋X × 0.01 を計算する FP ＝システム特性係数×未調整FP UCP (Use Case Point): 実装するユースケースから求めるポイントでシステム規模を計測する方法で、UML(Unified Modeling Language)で表されたシステムの機能的要求を利用します。 既にUMLで開発するプロジェクトでは導入は比較的容易だと思います。過去の実績情報などが揃っている場合にUCPと他の指標と比較するなどで色々な角度から表すことができると面白いですね。 作業の主体となるアクターとユースケースを洗い出し、アクターを利用してユースケースとアクターのインターフェースの複雑度を３段階(単純、普通、複雑)で評価します インターフェースとユースケースのポイントを合計して「UUCP (Unadjusted Use Case Point): 未補正ユースケース・ポイント」とします システムの技術的要因係数複雑度と，プロジェクトを取り巻く環境要因に関する複雑度(環境的な複雑度)を評価し、それをUUCPに反映しUCPを決定する 画面数、帳票数、ファイル数、バッチ数 このまま画面の枚数などの数値ですが、画面や帳票に含まれる仕様の複雑度は表せていません。（ゆえにFP法などの利用が必要となる。）単なる表示だけの画面と、他画面/機能と連携したり、入力項目の多い画面や、データチェックが必要な項目の他にデザイン上の複雑さなどは、画面数だけでは表現できていません。指標の一つの参考には使用できるかもしれませんが、品質を説明するための指標としての使用は難しいと思います。しかし実際の見積の段階などで、画面数や帳票数から全体工数やFPの概算試算ができたりします[JUASレポート ※1 ]。実績値との差異などの比較対象や見積参考の利用など使えるシーンも多いので収集する事をお勧めします。 全体工数（人月）＝ 112.97 ＋ 0.81 × 画面数 + 0.42 × 帳票数 FP ＝ 91.54 ＋ 13.41 × 画面数 ＋ 40.33 × 帳票数 JFS (JUAS Function Scale): システムの規模を推定するために JUAS が独自に作成した指標。「画面数＋帳票数×2/3」で算出され、既存の見積もり方法に比べ簡易に規模を推計することができます。 過去、私はこの指標を使った経験はありませんが指標となるものが何もない場合には参考としてみても良いかと思います。 ストーリーポイント: 書籍『アジャイルな見積りと計画づくり ー 価値あるソフトウェアを育てる概念と技法』 ※2 では、「ストーリーポイントとは、ユーザーストーリーやフィーチャー、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような、ひとまとまりの作業に対してポイントを付ける。ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2ポイントを付けられたストーリーは、1ポイントのストーリーの2倍の大きさであり、3ポイントのストーリーの3分の2の大きさとなる。 ストーリーポイントの数値は、ストーリー全体の規模をあらわす。ストーリーの規模を定義するための数式は存在しない。 ストーリーポイントによる見積りが示す値は、フィーチャーを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである」と定義されています。 アジャイル開発にてバックログにストーリーポイントを設定し、スプリントの中で作成できるストーリーポイントの合計をベロシティとして利用をしており、チームのスプリント工数＝ベロシティと理解することもできます。 ソフトウェア開発の作業に関わる指標など レビューに関わる指標 レビューは、どの工程で何をレビューするのか。また何をもってレビューを完了とするのかを決めて実施する必要があります。ただ工程に組み込まれているからといって形式だけ実施しても意味はないでしょう。レビューによって得られる情報を説明します。 レビュー回数、時間: レビューの実施回数、のべ時間です。ウォークスルーレビューなどは参加者の数だけレビュー時間(=工数)は増加します。例えば3人で3時間かけてレビューをすると、9人時のコストを消費します。「レビュー指摘のエラー修正コスト」と、「テストでバグとして修正されたコスト」が比較対象となり、「9人時」より大きなコストが削減されていれば良い訳です。レビューに時間をかけたから良いという事ではなく、「早期に問題を発見することでコスト削減に寄与する」ことが目的となります。 レビュー対象規模: レビュー対象となるドキュメントをページ数で表すことが多かったですが、ここ最近はレビューの対象となるドキュメントもwikiだったり、NotionやMiroなどのSaaSで作成されることも増えておりページ数で表せない事も多くなりました。アジャイル開発では、機能単位でストーリーポイントを使うこともあります。 「設計書」というドキュメントに囚われず、レビューの対象物の規模が適切に指標として利用できればよいと思います。指標を取得することが目的ではないのです。 レビュー品質メトリクス: レビュー実施にて検出した指摘件数を利用して精度を測る指標です。 レビュー工数密度 =  レビュー時間 ÷ レビュー対象規模 (または規模) で算出します。 短いとレビューの不足、長いとレビュー実施方法に課題があると推測されます。 レビュー指摘密度 = レビュー指摘数 ÷ レビュー対象規模 (または規模) で算出します。 例えば、規模が大きいのにレビュー指摘数が少ない場合に、ドキュメントの品質が高いためなのか、レビュー実施で指摘ができていないのかを確認することで、再レビュー判断や後工程での品質予測に利用することができます。 レビュー指摘効率 ＝ レビュー指摘件数 ÷ レビュー時間 で算出します。 レビュー工数に対してどれだけの指摘数の割合があるのかを示しています。レビュー指摘密度と合わせて判断することで、ドキュメント品質やレビュー実施方法の判定をすることができます。 テストに関わる指標 テストにより検出した不具合数は品質を測る上でQAエンジニアにとって非常に重要な要素・指標となります。ただ、いわゆるバグ情報だけではなくそれに属性や検出工程などが不可される事で深く分析することが可能になりますので、ここであらためて説明をします。 テストケース数: 件数で表します。ケース数は内容の粒度によって件数のブレが生じる要因となります。ケースに記載するテスト観点(確認内容)の粒度で合わせることでブレはなくなるでしょう。 開発プロセスで工程が明確に分けられている場合、テスト工程ごとに実行するテストケースが分かれていると思いますので、工程ごとにテストケース数を測定しましょう。それぞれ対象となる開発工程での品質を確認することにつながり、工程ごとに細かく対策を検討できるようになります。 不具合数、不具合起票数: いわゆるバグ数です。テスト実施中に検出したバグの数はプロジェクト内で管理されています。もし管理されていないならバグ起票の登録項目を含めたプロセスを作るチャンスです。後々の分析も考慮して作りましょう。 こちらもテストケース数と同様に工程ごとに検出されたバグ数を計測しましょう。これでそれぞれの工程の分析はより完全なものに近づくでしょう。また起票数＝バグ数ではありません、またテストケース外で検出されるものもあります。これらの理由に品質改善の種が埋まっています。これを上手に使い改善に利用しましょう。 密度 テストケース密度 = テストケース数 ÷ 規模 で算出します。 不具合密度 = 不具合数 ÷ 規模 で算出します。 上記の2つの指標により、開発システムの品質とテスト自体の品質も表すことができます。テスト密度が低く、不具合密度が高い場合に想定されるのは開発システムの品質に疑義がある状態になります。その逆はテスト密度が高く、不具合密度が高い場合はテスト自体の方法に問題がないかを確認する必要があると思います。 まとめ プロジェクトに関わったQAエンジニアやプロダクトオーナー、プロジェクトマネージャーはこれらの定量的指標を上手く使って品質を説明できる様に、どれを使うのかを明確にして、指標の集計や収集を可能にしなければいけません。「品質が良くない」など漠然とした説明ではどこがどの様に良くないのか分かりません。何を改善するべきか分からないですね。定量的指標を知り、どう使うのかを考えてみてはいかがでしょうか。よりよいプロダクト開発のための一助となればと思います。 APPENDIX:参考資料 ※1　一般社団法人 日本情報システム・ユーザー協会 ソフトウェアメトリックス ※2 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29） The post 品質を説明するには(定量的指標編) first appeared on Sqripts .