物を失くす人とリスクマネジメント
物を失くす人は予測ができない人が多い。
私の家族がそうなのですが、ポイポイ物を適当な場所に置く。片付けない。
失くなるというより、置いたときに場所を記憶していないので探しようがない。
さらに良くないのは、これを繰り返す。
常に決めた場所に置くことが、物も片付くし失くすこともないので効率的なことは間違いない。
適当なところに置く場合、失くさないように毎回置いたところの場所を記憶する必要がある。
記憶なんて簡単に定着しないし、そのために毎回記憶能力使うのも効率が悪い。
こういう人たちは基本的に面倒くさがりで、決めた場所に置くという行為自体が面倒くさい。
当然、適当に置いて記憶もしない。
見つからなかったら、あとから探せばいいやという考えをしている。
どちらが面倒臭いのか。
私からすると、あとで探す方がよっぽど面倒くさいと思うのだけど。
仕事もそうで、いろいろなリスクを想定して行動しないと、後々ひどいことになる。
事前にリスクを予測すること、もしリスクの芽が見えたら、すぐに処置することが大切ですよという話。
グループのリーダーが気に入らない
地域のコミュニティ内のグループのリーダーとメンバー間に確執がある。という話を小耳に挟んだので、何が良くないのかなと考えました。
メンバの思うこと
- 現在のリーダーのやり方についていけない
- その人がいるからやりたくない
確かに分からなくもない
現在のリーダーは、私が在籍しているときにもいた人なので、なんとなく想像がつくし、その人と付き合うと考えた場合は、このような意見が出るのも分からないでもない。ただ、コミュニティとして考えた場合、グループの存続やイベント運営に影響が出るのは避けたいところです。
問題
- リーダーのコミュニケーションの取り方や価値観が、メンバーの価値観に合わず不快感を感じている。
- リーダーに不満がある複数のメンバがイベント運営への活動の不参加を検討している。
注) 今年はコロナのためイベントの実施は未定。
考察
理想で言えば、グループ内のメンバは友好的な関係が良いわけですが、価値観などの違いもあるので単純に不満を持たれている個人が悪いというわけではありません。
企業であれば理念というものが存在し、それに向かって企業活動が行われるのですが、地域コミュニティにおいては理念（目的）を明確にしているというところは少ないと思います。ただ、少なくとも、地域コミュニティ内のグループにおいて、イベント運営はコミュニティ内の人たちを楽しませることが目的であり、あえて示さなくても暗黙的に共有されているはずです。
ただ、このような状況では改めて目的を明確にして、違う方向に向いていたベクトルを修正すること。その上で、まだ活動に支障が出るような問題があるのであれば、1つずつ解決していく必要があります。
ポイント
グループの目的は何であるのか？ということが共有されていないため、リーダーも自分自身の目的にベクトルが向いているし、メンバはリーダーと価値観が合わないから楽しくない。という個人的感情に向いていて、ベクトルの向きが正しくないという点です。 そのため、コミュニティの目的を明確にして、リーダーとメンバが目的を共有すること（ベクトルを合わせる）がポイントになります。
個人的な価値観を合わせる必要はないし、そんなことをしようとしたら問題は解決しません。私は個人的な価値観が合うことはない。と考えています。
ただ、今回の件は、このグループのリーダーではなく、コミュニティの関係者が仲介しないと、ちょっと厳しい感じではありますね。
財務3表の基本的な動き方
財務3表とは
それぞれの計算書の役割とつながりがいまいち理解ができていない部分もあり、
代表的な部分についての流れを図にしました。
CSは直接法のみ示しています。
とても参考にさせていただいた書籍です。
ストーリーでわかる財務３表超入門―お金の流れで会計の仕組みが見えてくる
こちらはストーリとしてもおもしろく、単純に続編を読みたくなってしまいました。
この辺も読んでみる予定です。
ダイエット＆腰痛改善のための朝活メニュー
2018~2019にかけて体重増加と腰痛悪化があったこともあり、トレーニングと食事改善を実施した結果、だいぶ改善しました。そのため、普段とちょっと違う内容ですが、そこそこ効果があると思っているので整理しておきます。
ダイエット
体重の推移は以下の通りで、ピークからは5kg、体脂肪も4%程度落ちて安定しています。
Withings Body + フランス生まれのスマート体重計 ホワイト Wi-Fi/Bluetooth対応 体組成計 【日本正規代理店品】 WBS05-WHITE-ALL-JP
使用しているものは型が古いですが、体重・体脂肪測定も朝一の日課です。
腰痛改善
一時期サポーターが欠かせなかった状態だったのが、コロナで座る時間が増えても半年以上サポーターが不要な状態となり改善しています。
体重と腰痛の両方への効果
これを最小メニューとして、朝10分程度の運動を毎日行いました。
腕立てや腹筋は多少アレンジを加えつつ、プランクも20秒程度維持してから足を上げ下げしたり、その日の体調やモチベーションに応じてスクワットやダンベルなど追加で実施していました。
やはり続けることが大事なので、無理のない範囲で継続することです。
現時点で体重は目標値になっていますが、体脂肪は15%台にしたい。
あと、人間ドックのメタボ検診で、今年はウエスト70という結果だったので60台にしたい。
というところで、継続活動中です。
体重への効果
- 子供の残りものに手をつけない
- 朝に炭水化物を取らない
やはり簡単な運動だけで体重を落とすのは厳しいということで、少しだけ変化させましたがかなり効果は出ています。
1つ目は書いた通りですが、日持ちするものはとっておき、そうでないものは諦めて捨てる。
2つ目はごはんやパンを朝に食べないことにしました。
私の朝の食事は1年以上、常に以下の３種類です。
- 運動後のプロテイン
- たまごを入れた納豆
- 牛乳で溶いた粉末スムージ
朝食以外の食事はいつも通りです。
あと、体重を毎日測定しているということで、八分目でやめておこうか。
という感覚にもなるので、よく言われることですが毎日体重を計ることは重要です。
改善期間は、この2つで活動していました。
ボディウイング ホエイプロテイン バナナ (EX版 1kg)
最近はこちらに変えていますが、味の好みでどちらでも良いかなーと思っています。
腰痛への効果
- お腹を引っ込める（お腹を骨盤の軸に合わせるイメージ）
➡️多少の猫背は気にしない - 腹筋を意識してお腹が前に出ないように背筋を伸ばす
➡️幹トレが効果を発揮
反り腰の改善とプランクなどの体幹トレが効果を発揮したと考えています。
私の場合、反り腰は猫背を直そうと腰を入れず（腹筋を意識せず）、無理して背筋を伸ばそうとしていたのが悪影響したと考えています。
やはり体幹トレで腰回りの筋肉を意識（コントロール）することが大切と実感しています。
JSTQB(ALTM) シラバス学習：7 スタッフのスキル（チーム構成）
2020.08.29更新
プロジェクトには様々なものがあるため、テストチームのスキルセットを見える化して各プロジェクトに適応させるための仕組みの構築が必要となります。
7.2 個人のスキル
ソフトウェアテストのためのスキルだけでなく、テストに関わるその他の活動に対するスキルや、そこから得られる情報にはソフトウェアテストに役立つものが多くあります。
テクニカルスキル
ソフトウェアシステム
エンドユーザのシステム要件や運用方法などを理解することは、テストの優先順位やテストケースの作成に役立ちます。
ソフトウェア開発プロセス
開発プロセスで発生する分析結果は、欠陥混入の原因、欠陥の見つけ方、欠陥の防ぎ方などの推察に役立ちます。
ソフトウェア開発
プログラミングや設計に関する知識は、それらの知識が必要なテストツールの作成やレビューへの参加に役立ちます。
テクニカルサポート
ユーザエクスペリエンスやユーザが期待することに関する知識は、テストケースの作成に役立ちます。
プロジェクトマネジメント
プロジェクトマネジメントに関わる作業は、進捗管理やステークホルダへのレポート作成に役立ちます。
対人スキル
チームで行う作業、ステークホルダとの交渉など、テクニカルスキルに加えて、影響力、交渉力、コミュニケーション能力などの対人スキルが業務を遂行する上では大切となります。
スキルアップ
テストチームにはスキルセットや経験値の異なるスタッフが混在しています。プロジェクトごとに最適なスキルセットは異なるため、チームスタッフのバランスを整えること、チームスタッフが自発的にスキルアップを意識する仕組みの構築が大切となります。
そこで、チームが必要とするスキルセットをベースに、チームスタッフのスキルアセスメントシートを作成し、各スタッフの強み弱みを見える化することで、誰が何を強化する必要があるのかを把握しスキル開発計画を立案します。
トレーニングは強み、弱みの両面の強化を行い、チームのスキルのバランスを整えます。
- チームに影響を及ぼす弱みは優先的に強化する
- 強みはより強化する
7.3 テストチームの力学
強力なチームを作るには、テストチームに働く力と、それによってチームメンバに起きる相互作用を意識することが重要です。
チームに働く力
テストメンバはテストに関するスキル以外にも必要な能力があり、それらは環境に対応する能力です。
プレッシャー耐力
以下のようなプレッシャーのかかる状況においても、集中して作業を進めることができる力が必要です。
- スケジュールがひっ迫した状況
- ステークホルダの高い期待
- 非現実的な作業量
チーム貢献への意識付け
テストメンバが自分の価値と必要性について認識することが、チームに貢献するメンバに変化する第一歩となります。そのために、テストマネージャはスキルアセスメントに基づき、強みと弱みを分析して育成・トレーニングを行います。
- 新しいメンバへの適切なコーチング
- 各個人の性格に応じた明確な役割付与
その結果、個人の成功がチームに貢献する結果となり、チームを成功へと導きます。
スキルアセスメント
環境によって違いはありますが、テストメンバに必要な基本的なスキルは以下のようなものがあります。
テクニカルスキル(ハードスキル)は、次の項目で示される。
- 要件ドキュメントからテストケースを抽出する。
- テクニカルドキュメント(要件、コードなど)をレビューする。
- レビューコメントを明確で分かりやすく、目的に沿った形式で記述する。
- 特定のシナリオでさまざまなテスト技法を適用する(たとえば、デシジョンテーブルを使用して一連のビジネスルールをテストするなど)
- 故障を評価し、正確に記録する。
- 欠陥分類情報の理解度をはっきりと示す。
- 欠陥の根本原因の理解度をはっきりと示す。
- ツールを使用して、正常系テストと異常系テストを含む、特定の API をテストする。
- SQL を使用してデータベース情報を検索および変更し、特定のシナリオをテストする。
- 複数のテストを実行して、テスト結果を収集するテスト自動化ハーネスを設計する。
- 自動化したテストを実行し、故障のトラブルシューティングをする。
- テスト計画、テスト仕様を記述する。
- テスト結果のアセスメントを含むテストサマリレポートを記述する。
対人関係スキル(ソフトスキル)は、次の項目で示される。
- スケジュールが遅れているテストプロジェクトに関する情報を提示する。
- 欠陥がないと思っている開発者に欠陥レポートを説明する。
- 同僚をトレーニングする。
- 効果的でないプロセスに関して、問題をマネジメント層に提示する。
- 同僚が作成したテストケースをレビューし、その同僚にコメントを提示する。
- 同僚をインタビューする。
- 開発者を称賛する。
相互作用
テストメンバが貢献を意識するようになると、チームに力学が働き、メンバ間の相互作用が生じます。例えば、自発的にテストメンバによる以下の行動が起きます。
- 非公式のクロストレーニング
- 仕事量の平準化
この状態になると、テストマネージャはテストメンバのトレーニングなどから解放され（マネージャが何もしなくても良いというわけではありません）、ステークホルダなどの対外的な対応に集中できるようになります。ここでマネージャには以下の能力が必要となるため、日頃からのスキルアップが必要です。
- 外部との交渉能力
- 組織内の調整能力
7.4 組織内におけるテストの適合
テストの適合方法は組織によって異なりますが、独立したテストチームを用い、テスト工程を標準化することは、品質に貢献する重要な要素となります。可能な予算とスケジュールの範囲内で、できるだけ品質が向上するようなテストチームを構築する必要があります。
マネージャによる傾向
- 開発マネージャ：品質に重点
- 独立したテストマネージャ：スケジュールに重点
独立性による傾向
- 高い独立性：開発チームからテストチームへの知識の移転が少なくなる
- 低い独立性：テスト内容とプロダクト要件の間に乖離が発生しやすくなる
このような独立性の違いによるテスト環境や重点項目に対する傾向を理解して、複数のテストを混在させるなど、品質の最大化を目的とした活動が必要となります。
7.5 モチベーション
テストマネージャは、何がモチベーションを向上させ、何が低下させるのか、モチーベーションに与える影響を考慮した活動が必要となります。それには、まずは自らが規範となり、テスト担当者の成果を明確なアセスメントリストによって公平に評価する必要があります。
また、テスト担当が成果を出しやすい、貢献を示しやすい環境づくりを行うことも大切です。
モチベーションの向上
成果や貢献に対して正当な評価や報酬が得られることがモチベーション向上につながります。
- 無形要因：周囲からの承認や尊敬
- 有形要因：昇給、昇進、自己裁量権の付与
モチベーションの低下
正当に評価されない場合だけでなく、プロジェクトの実行環境があるべき状況と乖離している場合にもモチベーションの低下につながります。
- 正当な評価や報酬が得られない
- 不可能な日程でのリリース計画
- 品質が優先されないプロジェクト進行
7.6 コミュニケーション
テストマネージャはテスト担当者からユーザまで、広範囲の相手とコミュニケーションをとる必要があります。そのため、さまざまなタイプの人と品質プロセスの改善を目的とし、メッセージが正しく伝わるようなコミュニケーションの取り方やレポートの書き方について考える必要があります。
コミュニケーションの種類
会話だけがコミュニケーションではなく、メッセージを伝える行為をコミュニケーションとして考えます。
テストプロダクト関連文書
テスト戦略、テスト計画、テストケース、テストレポート、欠陥レポート
ドキュメントのレビュー結果
要件、機能仕様、ユースケース
情報共有
開発者間、テストチーム間、マネージャ間とのやりとり
コミュニケーションの客観性
メッセージを伝える際には、客観的に相手が必要な情報の見せ方が大切になります。同じ結果を伝える場合でも、伝える相手が異なれば伝え方も変わるということです。
- テスト担当とステークホルダの間では、専門的、客観的、効果的なコミュニケーションによりテスト担当者に対して敬意が保たれます。
- 他者の成果物に対して建設的なフィードバックを行う場合は、外向性、客観性が必要となります。
貢献をマネジメントする目標設定
ソフトウェアテストに限らずプロジェクトにはステークホルダーが存在します。ステークホルダーはプロジェクトから何らかの価値が生み出されることを期待しています。
価値とは貢献から生まれるものであるということを理解して、自分やチームがどのようにして貢献できるかを常に考え実践していくことが、成果と成長につながるということを理解することが大切です。
プロフェッショナルの条件 はじめて読むドラッカー (自己実現編)
JSTQB(ALTM) シラバス学習：6 テストツールおよび自動化
2020.08.09更新
6.1 イントロダクション
この節では、テストマネージャがツールおよび自動化について考慮すべき点を明確にします。
6.2 ツール選択
テストツールは、ベンダから購入したりオープンソースのツールから入手したりします。どのようなツールを選択するかは、テストグループのニーズとライフサイクル全体にかかるコストから判断します。
6.2.1 オープンソースツール
テストプロセスのすべての局面で使用することができますが、メリットとデメリットを理解した上で使用する必要があります。
メリット
・初期購入コストが安い
・拡張性が高い
デメリット
・正式サポートがない
・特定の問題に対処する作りになっている（ベンダツールと同じ機能がない場合がある）
・拡張時に複雑性が高まる（メンテナンスコストの上昇）
・GNU GPLへの配慮が必要（変更ソフトウェアの配布義務）
・正確性が保証されない
6.2.2 カスタムツール
通常とは異なる環境やプロセスにおいてはカスタムツールによるテストが検討される場合があります。
メリット
- テストチームのニーズに適合し効率的に動作するツールを用意できる。
- 組織の他のプロジェクトで利用することができる。ただし、事前にメリット、デメリットのレビューが必要となります。
デメリット
- 作成者への依存度が高いため、メンテナンスについての文書化が必要
- 当初の利用目的とは異なる要件追加によるツールの品質低下を防ぐため、ソフトウェアプロダクトと同様の設計およびテストが必要
-
6.2.3 投資効果(ROI)
ツールを導入する場合には、以下のようなリスクやコストとメリットを比較して導入すべきか判断します。
また、テストチームが使用するすべてのツールにおける総ROIから、ツールの使用に関して長期的な戦略をとることが必要となります。
初期コスト
- 要件定義
- 評価と選択
- 購入、適用、開発
- 初期トレーニング
- ツールの統合
- ハードウェア、ソフトウェアの購入
固定費
- 所有コスト（ライセンス料、メンテナンス、トレーニングなど）
- ツールの移植
- ニーズへの適用
- 品質とプロセス改善
- テストリソース（実運用するまでの重複テスト）
リスク
- 組織が未成熟
- テスト対象のソフトウェア変更によるメンテナンス困難
- テストアナリストのテストタスクへの関与減少（自動化などにより関与しなくても良くなる）
メリット
- 反復作業の削減
- テストサイクル時間の削減
- テスト実行コストの削減
- テスト実行数の増加
- 人的エラーの減少
- 情報アクセスにかかる時間の削減
- テストタイプの増加（性能テストなど）
- 自動化実現による地位向上
6.2.4 選択プロセス
テストツールは、
- くり返し何度も使用する
- 拡張して使用する
- 複数のプロジェクトで使用する
長期的な投資であるため、候補となるツールをさまざまな観点から検討する必要があります。
検討する観点
以下の観点から、それぞれ長期的な視点で検討が必要となります。
ビジネス観点
ROI（投資利益率）の検討する
プロジェクト観点
全ライフサイクルで検討する
利用者観点
効率的で効果的な作業となるか検討する
ツールの検討
ツールの導入にあたってはロードマップを引いて能力の検討を行います。
分析
- 入力データを正しく分析処理できること
設計
- 要件からテストケースを作成できること
- テストケースを自動生成できること
- テストデータを自動生成できること
データとテストの選択
- テストデータの選択を自動、手動の使い分けができること
- 入力データに基づく選択ができること
- カバレッジ基準の選択ができること
実行
- 自動、手動の使い分けができること
- ツールの停止動作について
- 欠陥の処理時に関連テストケースのステータスを自動更新できること
評価
- 適切な結果であることの判断をどのように行うか
- ログ記録やレポート機能があること
6.3 ツールのライフサイクル
ライフサイクルを通してテストチームがツールを正常に利用できるように、テストマネージャが管理するプロセスが4つあります。
6.4 ツールのメトリクス
ツールを構成するときにツールのレポート要件を定義して実装することで、各種メトリクスをステークホルダが理解しやすい形でレポートすることができる。ステークホルダに理解してもらうために、どのようなメトリクスが必要で、どのように見せるのか、というところが大事です。
ツールごとのメトリクス
テストマネジメントツール
要件やテストケースなどからのトレーサビリティによるカバレッッジメトリクスや、テスト状況のスナップショットによるテストの進捗情報（進捗管理）
欠陥マネジメントツール
欠陥に関する原因やステータス、混入フェーズなどによるプロセス改善に役立つ情報
静的解析ツール
保守性の向上を阻害する問題に関する情報
性能テストツール
期待するシステム拡張に性能が対応できるか判断するため情報
カバレッジツール
テスト消化率によりテストの品質を示す情報
