JSTQB ALTM v3.0.J01 学習メモ 1.6（48/91）
このメモについて
学習の目的（LO）に対応する自分なりの理解を書くことにする。
シラバス上で重要と感じたところや忘れそうなところを書いておいたりもする。
1.6 テストツール
TM-1.6.1 K2 ツール導入の最良の実践例を要約する。
ツールの評価、選択
- ツールがSDLCにどのように統合されているか理解する
- サポートを受けながらプロセス改善の機会を識別する
- 組織で使用されている技術と互換性のあるツールを選択する
- 明確な要件と客観的な基準に照らしてツールを評価する
- ツールベンダーやツールのサポートを評価する
- 使用に関するコーチングやトレーニングの社内要件を識別する
- 様々なライセンスモデルの長所と短所を検討する
- コンセプトの証明を評価する
ツールの採用と展開における実践例
TM-1.6.2 K2 ツールの種類を決定する際にさまざまな技術的側面とビジネス的側面が与える影響について説明する。
TM-1.6.3 K4 ツールの選択、カバーできるリスク、コスト、および利点を考慮した計画を立てるために特定の状況を分析する。
判断基準
- 経営：プラスのROIが期待できるか
- サポート・運用チーム：チームのキャパシティに対してツールの数や管理コストは許容できる範囲か
- プロジェクトリーダー：ツールが測定可能な価値をもたらすか
- ツールユーザー：使用性が十分か
- 運用スタッフ：保守性は十分か
非経常的な活動およびコスト
経常的な活動およびコスト
- ライセンス費、サポート費
- メンテナンス・移植費
- 継続的なトレーニング
- 実作業機会コスト
ツールの主な利点
- 繰り返し作業の削減
- 実行コストの削減
- ヒューマンエラーの削減
- スピードアップ
- 特定のテストタイプのカバレッジ向上
- テスト情報への迅速なアクセス
ROIに関するリスク
- ツールの非効率的な使用
- ベンダーのメンテナンスポリシー変更
- コストの増大
- 利益の低減
TM-1.6.4 K2 ツールのライフサイクルの各段階を区別する。
- 調達
- サポートとメンテナンス
- 進化
- 廃棄
TM-1.6.5 K2 ツールを利用したメトリクス収集と評価の例を挙げる。
- テストマネジメントツール：テストアイテム、テストケース、実行状況など
- 要件マネジメントツール：要件カバレッジ
- 欠陥マネジメントツール：
- テストアイテムのステータス、重要度、優先度、
- 欠陥密度、欠陥検出率、検出リードタイム
- 静的解析ツール：複雑度
- 性能テストツール：性能メトリクス
- コードカバレッジツール：コードカバレッジ
- その他：テスト効率（実行時間、テスト数など）
感想
ツールに関しては最適な選定と運用をしましょうというのはその通りだが、結局導入できるか・運用できるかは無償ならスキルと根性（人件費）、有償なら事業の財政状況が大きいような。
ROIとあるが本来の目的である売上や顧客満足の変動には様々な要因があるので、品質やテスト要因の厳密な貢献度なんて出せないだろう。
コスト削減なら出せるかもしれない。
DX、AI活用の文脈で「データが集積されることの価値」も出せるかもしれない。
組織やプロセスの成熟度を高め（or その高さを示し）、品質保証に対する内外の信頼を高めるためにいくらまで払えますか、という話だと思う。
JSTQB ALTM v3.0.J01 学習メモ 1.4-1.5（43/91）
このメモについて
学習の目的（LO）に対応する自分なりの理解を書くことにする。
シラバス上で重要と感じたところや忘れそうなところを書いておいたりもする。
1.4 プロジェクトテスト戦略
テスト戦略もテスト計画も様々なコンテクストを考慮して最適なテストを具体化していく活動なのでどう使い分ければいいんだっけ？と混乱したのだが、
テスト戦略～テスト計画プロセスにおけるテスト戦略の考え方～｜ソフトウェアテストのSHIFT
SHIFTの記事によると、テスト戦略を立ててからテスト計画に落とし込むという関係性のようだ。
ALTMのシラバスには以下のようにある。
プロジェクトテスト戦略はテスト計画の主要な成果物であり、通常、テスト計画書または他の文書の一部として文書化する。
プロジェクトテスト戦略は組織的テスト戦略を考慮して立てられるし、テスト戦略は単一のテストレベルやテストタイプに対して立てられることもある、とのことなので階層構造を成しているようだ。
………結局どういうこと！？
TM 1.4.1 K2 テストアプローチの典型的な選択肢を説明する。
TM 1.4.2 K4 組織的テスト戦略とプロジェクトのコンテキストを分析し、適切なテストアプローチを選択する。
K4項目。
- ドメインごとに規制、標準、慣行や重視する品質特性やアプローチが異なる
- 組織によって説明責任・プロセス品質・自動化・テストの成熟度・欠陥検出効率などをどの程度求めるかが異なる
- プロジェクトによってテストに関する制約（予算・時間）やリスク、機会が異なる
- 例えば制約が強ければ厳格なリスクベースドテストを採用する、契約に基づく受け入れ基準をカバーするテストが必要、など
- テストリソースは当然テストアプローチに影響してくる。リソースには使用可能な環境やツール、要員のスキルセットなども含む
- SDLCも当然テストアプローチに影響する
- 開発範囲に他システムとの連携がある場合、適切なテストレベルの選択やリスクベースドテストの適用が必要になる
- テストデータに可用性をはじめとした制約がある場合、モデルベースドテストが役立つことがある
テストデータについて可用性をはじめ深く考えたことがないからあまりピンと来てない。
TM 1.4.3 K3 測定可能なテスト目的と終了基準を定義するために、SMARTの法則を使用する。
- Specific（具体的）
- Measurable（測定可能）
- Achievable（達成可能）
- Relevant（関連性がある、妥当な）
- Time-bound（期限が明確）
プロジェクトのテスト目的は、測定可能または評価可能な品質と量のすべての対象とする側面に対応すべきである。
またプロジェクトのテスト目的とは別に、業回の専門家やステークホルダーによる品質レベルのアセスメントも考慮すべきである。
ちなみにJSTQB FL シラバスにある典型的なテスト目的を例にとると
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。→多分カバレッジ
- 故障を引き起こし、欠陥を発見する。 →終了基準とかあるのか？NG率？
- 求められるテスト対象のカバレッジを確保する。 →カバレッジ
- ソフトウェア品質が不十分な場合のリスクレベルを下げる。 →リスクアイテムに対するテストのPass
- 仕様化した要件が満たされているかどうかを検証する。 →テストのPass、要件カバレッジ
- テスト対象が契約、法律、規制の要件に適合していることを検証する。→テストのPass
- ステークホルダーに根拠ある判断をしてもらうための情報を提供する。→品質レポートの提出
- テスト対象の品質に対する信頼を積み上げる。→ テストのPass（率）、各種統計？
- テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。→テストのPass
って感じなのかな。
- テスト戦略を明確にしておく
- テスト設計を可読性の高い形で残す or 適宜レビューしておく
- カバレッジを出せるようにしておく（ハイレベル=粒度粗めでも）
- テスト結果の集計は見れるようにしておく
あたりをやっておけば概ね対応できそう。
1.5 テストプロセス改善
テストはプロジェクト全体のコストの少なくとも30%〜40%を占めることが多い。
=30〜40%は普通！（？）
TM 1.5.1 K2 特定のプロジェクトにおけるテストプロセス改善のためのIDEALモデルの使用方法を説明する。
- Initiating（開始）：プロセス改善の目的とスコープをステークホルダーと合意する
- Deagnosing（診断）：現プロセスをアセスメントし、改善の可能性を特定する
- Establishing（確立）：アクションと優先順位を具体化した改善計画を立てる
- Acting（行動）：実行にはトレーニングやパイロット実施、チームへの展開を含む
- Learning（学習）：どのような利益が得られたか検証を行う
IDEALモデルは組織レベル、プロジェクトモデル、チームレベルで適用できる。
適用対象が小さくなると各活動の規模は小さくなり、またメンバーとの直接的な関与が多くなる。
TM 1.5.2 K2 テストプロセス改善のためのモデルに基づく改善アプローチを要約し、プロジェクトのコンテキストに合わせて適用する方法を理解する。
モデルベースのテストプロセス改善では理想となるテスト改善モデルを使用し、改善を段階的に進める。
TM 1.5.3 K2 テストプロセス改善のための分析に基づく改善アプローチを要約し、プロジェクトのコンテキストに合わせて適用する方法を理解する。
分析的アプローチではプロジェクトやチーム自体の定量的・定性的データに基づいて問題を識別する。モデルベースアプローチと併用することもできる。
- 根本原因分析、特性要因図
- 尺度、メトリクス、指標（有効性、効率性、予測性などを計測する）
- GQM（Goal-Question-Metric）アプローチ
テスト進捗、欠陥検出、テスト有効性、テスト効率、予測性といったデータは、プロジェクトやイテレーションにのテストに対する客観的な洞察を提供することができる。
あんまりリアルタイムの可視化と活用はできてないんですよね…技術力か根性が足りない。
TM 1.5.4 K3 テストプロセスを評価し、改善すべきテスト領域を発見するためにプロジェクトまたはイテレーションにふりかえりを実装する。
ふりかえりではプロセス、人、組織、コラボレーション、ツールなどのトピックを取り上げる。
ふりかえりはチーム全体アプローチを支援し、継続的な改善を促進する。
ふりかえりの結果を適切に文書化し、組織のメンバーに分かりやすい方法で配布・伝達する必要がある。
- ふりかえりのステップ
- イントロダクション
- データの収集
- 改善策の導出
- 改善アクションの決定
- ふりかえりのクロージング（ふりかえり自体のレビュー）
関連して 『アジャイルレトロスペクティブズ第2版』発刊 | ワイクル株式会社
を最近買って読んだりしてるんですが、この「データの収集」ってのが割と時間かかるのでふりかえりのトピックが事前に定まってないと事前にやるのは難しい→2回開催が必要になり完遂のハードルが上がるなぁ…って思ってます。
事前に計測の仕組みを整えていつでも見れるようにできてたら強い。
感想
結局テスト戦略とテスト計画の違いと関係性って何ですか（誰か教えて）。
JSTQB ALTM v3.0.J01 学習メモ 1.3（34/91）
このメモについて
学習の目的（LO）に対応する自分なりの理解を書くことにする。
シラバス上で重要と感じたところや忘れそうなところを書いておいたりもする。
1.3 リスクベースドテスト
リスクベースドテストはリスク分析（識別、アセスメント）、リスクコントロール（モニタリング、軽減）からなる。
リスクは変動するため、テストモニタリングにはリスクモニタリングも含めるべきである。
テストマネージャーはプロダクト品質の正確な評価のため、品質保証に関連するプロジェクトリスクに焦点を当てたリスクマネジメントへの積極的な関与が必要。
リスクレジスター…リスク管理表のこと
リスクレベル…リスクの脅威の度合いのこと。例えば発生確率と影響度の掛け合わせの高低。
TM-1.3.1 K2 リスクベースドテストにてリスクに対応するために取るさまざまな尺度を説明する。
テスト計画では、リスク分析の結果に基づいてリソース配分を調整する。
テスト分析ではリスクレベルに基づいてテスト条件の範囲・粒度を調整する。
テスト実行ではリスクレベルに基づいてテストの実行順序を決定する。
TM-1.3.2 K2 テストマネージャーがプロダクト品質に関連するリスクを識別するために使用できるさまざまな技法の例を挙げる。
専門家インタビュー、ワークショップ、ふりかえり、過去の経験の参照など。
リスク識別では可能な限り広範なステークホルダーを参加させることが重要。
リスクはテスト対象に一様に分布しない。テストアイテムの個々のリスクを識別する必要がある。（例えば管理画面とエンドユーザー向け画面ではリスクが異なる）
TM-1.3.3 K2 プロダクト品質に関するリスクレベルを決定する要因について要約する。
各リスクアイテムに対して以下を評価し、リスクレベルを判断する。
- リスクタイプ（プロダクトリスクまたはプロジェクトリスク）
- 影響を受ける品質特性
- リスク可能性
- リスク影響
リスク可能性を左右する要因
- システムの複雑度
- 組織の成熟度
- 個人のスキル、モチベーションなど
- チーム内の対立の度合い
- 契約問題
- 地理的分散
- 経営・技術リーダーシップの有無
- リソースの問題やプレッシャーの程度
- 早期の品質保証活動の欠如
- テストベース、プロダクト、人員の変更率
リスク影響を左右する要因
- 機能の使用頻度
- 機能の重要性
- ビジネスゴールの重要性
- 評判、事業収入へのダメージ
- 社会的な損失や賠償の可能性
- 訴訟などの法的制裁
- インターフェースや統合の課題事項
- 回避策の有無
- 安全性のニーズ
TM-1.3.4 K4 特定のコンテキストにおけるリスクレベルに応じたリスク軽減するための適切なテスト活動を選択する。
これもK4だ！
リスクの軽減策として最も重要なものはテスト。
（他は回避策の提供、サードパーティへのリスク移転、リスク受容など）
- 高リスクアイテムには早期に、厳密なテストを行う
- 低リスクアイテムは遅く、厳密ではないテスト技法を用いるべき
テスト計画において、テストマネージャーはコンテキストに基づいたテストアプローチを選択すべき
- テストアイテムのリスクレベルに応じてテストの厳格さを調整する
- 影響を受ける品質特性に合わせたテストタイプを選択する
- リスク対策に必要なテストレベルとテストタイプを選択する
- SDLCを考慮してテスト開始基準を定める
- リスクレベルの高いテストアイテムは最適な担当者を当てる
- 規制要件があれば確実に満たせるように監視する
- リスクレベルに基づいてレビュー要否、開発からの独立性レベル、リグレッションテストの実施範囲を調整する
テスト実装ではリスクレベルに基づいてテストの優先順位付けを行う。
優先順位付けの方法として縦型探索（depth-first）や横型探索（breadth-first）などが考えられる。
前者は最もリスクレベルが高いテストアイテムのテストを優先する。後者は全てのテストアイテムを最低1回テストする。
どちらにするかはリスクの軽減と全体の品質状況どちらを優先するか、またリソースの残り具合によって判断される。
モニタリングとコントロール
テストがすべて実行できないうちにリソースがなくなった場合、テストを延長するか残ったリスクを受け入れるかをマネジメントに提供する。（リスクの文脈で確認することが大事）
TM-1.3.5 K2 リスクベースドテスト技法について重量的と軽量的の例を区別する。
感想
基本的にリスクベースでマネジメントするようにしているつもりではあるが、ちゃんとしたリスク分析技法は使ってない…。
ふりかえりの時に成功度を確認する（確認できるようにデータを取っておく）のはやりたいな。
JSTQB ALTM v3.0.J01 学習メモ 1.1-1.2（28/91）
今年こそAL取った方がいいんじゃないかと思っていたところにJSTQB カンファレンスを聞いて気運が高まったので頑張りたい所存。
今年とは言ったが年内とは言ってない。（何）
ALTMのシラバスJSTQB認定テスト技術者資格-シラバス（学習事項）・用語集-
version 3.0 になって分かりやすくなったっぽい。
学習の目的（Learning Object, LO）と章が1:1対応になったのがすごく助かる。
このメモについて
学習の目的（LO）に対応する自分なりの理解を書くことにする。
シラバス上で重要と感じたところや忘れそうなところを書いておいたりもする。
1.1 テストプロセス
学習の目的（LO）：TM-1.1.1 K2 テスト計画を要約する。
テスト計画はテスト目的を達成するために必要な活動やリソースを識別する活動。計画はプロジェクトの進行に合わせてイテレーティブに更新される。
- （組織・プロジェクト・テストなどの）コンテキストの理解
- プロダクトリスクの分析
- リスク対応アプローチの識別
- テストアプローチの定義
TM-1.1.2 K2 テストモニタリングとテストコントロールを要約する。
テストモニタリングとは、ステークホルダーにとって理解しやすく関連性のある形でテストの状況を可視化すること。
テストコントロールではテスト戦略とテスト目的を満たすように指針を示し（逸脱に対しては是正し）、必要に応じてテスト計画を再検討する。
TM-1.1.3 K2 テスト完了を要約する。
テスト完了は以下の活動を含む。
- 完了レポートの作成・承認
- テストウェアの保管・引き渡し
- テスト環境のクリーンアップ
- テストやSDLC全体に関するふりかえり
1.2 テストのコンテキスト
テストのコンテキストはテストプロセスに影響を与える固有の条件と制約を包含する。
テストマネージャーはテストをソフトウェア開発プロジェクトの特定のニーズと目的に適合させるためにコンテキストを把握する。
TM-1.2.1 K2 さまざまなステークホルダーがテストに関心を持つ理由を比較する。
関心を持つ理由は「己の責務や目的の達成に影響するから」で、責務や目的が人によって異なるということだと思うけども。
テストのどの領域に関心を持つかを理解し、コミュニケーションする必要はある。
- 開発チーム：テスト対象を作る、欠陥を修正する
- ユニットテストに関与し、テストプロセスに貢献する
- テストチーム：テスト活動を行う
- テストプロセスに貢献する
- PjM, PO, ビジネスユーザー：QCDに責任を持つ、方向性を示す
- 要件を仕様化し、品質レベルを定義し、必要なカバレッジを推奨する
- 成果物をレビューし、ユーザー受け入れテスト（UAT）に参加し、テスト結果に基づいて判定を行う
- 運用チーム：システムを動かす、ユーザーを支援する
- 運用受け入れテストに従事し、システムの本稼働への準備を確実にし、非機能要件の定義に貢献する
- 顧客とユーザー：対価を払い、直接使う
- ユーザー受け入れテスト（UAT）に参加する
TM-1.2.2 K2 テストマネジメントにおいてステークホルダーの知識が重要である理由を説明する。
ステークホルダーマトリクス：X軸を関心の高低、Y軸を影響力（権力）の高低でマッピングする。
ステークホルダーに優先順位をつけ、効率的に期待値をマネジメントするための指針とする。
こんなの→ステークホルダーマップとは？作り方のコツと活用例【テンプレート付！】 | ウェブマネジメント・アカデミー | ウェブ担当者スキルアップと悩み解決メディア
- 推進者（関心：高、権力：高）…主要な協力者
- 潜在的協力者（関心：低、権力：高）…高レイヤーの意思決定者
- 擁護者（関心：高、権力：低）…定期報告や特定の議論への関与で関心を維持する
- 無関心者（関心：低、権力：低）…特定の議論への関与で独自の洞察を得られる
TM-1.2.3 K2 ハイブリッドソフトウェア開発モデルで行うテストについて説明する
いわゆる「なんちゃってアジャイル」において配慮すべきことは「アジャイルへ移行する途中」なのか、「最適解としてのなんちゃって状態」なのかによっても異なる。
TM-1.2.4 K2 さまざまなSDLCでのテストマネジメント活動を要約する。
体験と反するものをメモ。
- テストマネージャーの役割は統合され、ファシリテーターやコーチが取って代わる
移行期においては逆にQAがファシリもやる、というのはありそうだが。
TM-1.2.5 K2 さまざまなテストレベルでのテストマネジメント活動を比較する。
TM-1.2.6 K2 さまざまなテストタイプでのテストマネジメント活動を比較する。
- 機能テスト
- 戦略的な計画と進捗の追跡、リソース調整
- 非機能テスト
- ブラックボックステスト
- テストカバレッジ分析とフィードバックマネジメント
- ホワイトボックステスト
- カバレッジの最適化、技術的洞察の活用
TM-1.2.7 K4 テスト計画、テストモニタリング、テストコントロールに重点を置いたテストマネジメント活動を決めるために、特定のプロジェクトを分析する。
これだけK4（分析）なのよな。
下記のようなことが十分に行えるよう、業務を通してプロジェクトを観察（分析）する必要がある。
感想
実際のところそこまでテストレベルやテストタイプをまたいでマネジメントしてなかったり、ステークホルダーマネジメントもやれてないのでそのあたりでピンときてないところはある。
AI議事録とユーザーストーリーマッピングとポスト議事録の妄想
最近職場やネットで「議事録はAIに取らせればいい/取らせている」という意見を見聞きして、同意なんだけどなんかモヤっていたポイントがわかったのでメモ。
結論から言うと、「AIに議事録を任せた結果、参加者のアウトプットの総量が減り、今までよりも認識齟齬に気付きづらくなる or 気付くタイミングが遅れて手戻りロスが大きくなるかもしれない」というのを自分は危惧しているんだなー、と気づいた。
前提
- 今までの議事録はリアルタイムで記載内容が全員に見える形式（例えば Google Docs）で、全員で書くことが多かった。
- AIに議事録取ってもらうのはいいと思う。細かいことまで全部人間が打ち込んだり整形したりするのは大変なので。とりあえず全部記録しておいてもらえる、というのは安心感がある。
議事録をAIに任せる「だけ」じゃダメだと思う理由
とかく認識齟齬とそれによるトラブルが起こりがちなソフトウェア開発においては、会議の場で「共通認識を形成する」というのは非常に重要である。
O’Reillyの『ユーザーストーリーマッピング』（Jeff Patton 著）に掲載されている共通認識に関する図（の引用） を見てもらうと分かるが、共通認識形成に重要なのは、「各自の理解（認識）をアウトプットし、ズレの有無のチェック・是正を行う」ことだ。
そして、「全員で議事録を書く」は「アウトプットの一つ」なのだ。
- 自分は話を聞いてこういう風に理解（認識）しましたよ、という表現
- （仮に記載者が発言していなかったとしても）聞いていましたよ、了解しましたよ、というサイン
他を何も変えずに議事録をAIに任せた場合、アウトプットが減ってしまう。また、AI議事録を読んだ各自の理解が一致しているかどうかは未検証のままになる。
「共通認識を形成する」という目的を自覚できていて、議事録以外の検証手段（例えばファシリテーションやプロセスの工夫）を確保できていればいいのだけど、どうだろうか。
別に書くことだけがアウトプット手段ではない（というか、話すことが会議のメイン手段である）が、
- 通常一度に発声できるのは一人だけ
- 話し言葉は「あれ/これ」「〜な感じ」など、良くも悪くも曖昧な要素を含む
- 一瞬気が散って聞き逃す、短期記憶から溢れて10分前の会話を忘れる、はよくある
- 「あの文書にこんなこと書いてありましたけど」などの参照共有は画面共有やテキストの方がやりやすい
などデメリットはあるので、音声、画像/映像、テキストを併用してコミュニケーションするに越したことはないと思う。
（勿論テキストコミュニケーションにもデメリットはある。使い分けが大事）
AI議事録によって会議におけるアウトプット（表現）形式が進化するかも？
AIが議事録を生成する前提で、それをベースに共通認識を形成しようとしたら、それはもしかして「AI議事録に人間がアノテーションする」という形になるのかもしれない。
- 強調表現
- リアクション
- コメント、補足の書き込み
- トピックの関連性の可視化
- 図の挿入や参照リンクの付与
- 上記から始まるチャット
とかで「会話による会議進行をベースに、視覚（テキスト、画像等）を併用したリッチなコミュニケーションで効率を上げる」的な。
ってことで、議事録生成AIサービスはリアルタイムにアノテーションできてその後アノテーションも含めてマークダウン形式で出力できるようなUIを作ったらいいのかもしれない…。
糖尿病のインスリン注射について自分なりのコツをメモ
残念なことに糖尿病と診断されてインスリン注射することになってしまった...。 何が不満と言って注射以外の手順がとても多い！
- 血糖計測機器の装着（2週に1回）
- 電子的血糖計測（1日8回）
- 物理的血糖計測（1日6回を2週間で3〜4回）
- 食事の記録（3回/日）
- 注射後の待機（3回/日）
- 糖尿病対策メニューのための買い出し・調理
- 低血糖症状への備え
記録結果は通院時に医療スタッフにチェックされるが、漏れがあると「うっかりさん」的な反応をされる...うっかりなのは正しいとはいえ、これを「面倒でない、100%できて当たり前」扱いされるのも納得いかんが？
これに加えて注射の諸々と主業務もあるのだが？
しかもここまでやってなお食べたいものを自由に食べることはできず、「食べるものを選べ（血糖値上がらないように）」と「もっと食べてもっと太れ」を1人の医師から同時に言われるのだ…（血糖値推移は個人の体質や体調、そのときの運動量など変動要因が多いため、この矛盾したTODOをこなすための「具体策」を提示してくれたりはしない。せいぜい軽運動の推奨・食事を小分けにして頻回に摂れレベル）
せめて物理的血糖計測/食事の記録の2つがなければまだ我慢できそうなのだが。
だが、最大の問題は「インスリン注射の痛み」である。
物理的血糖測定や計測機器の装着時の穿刺は一瞬であるため耐えやすく、かつ開始したら中断することはない（できない）ので打つ瞬間だけ覚悟すればよい。
が、インスリン注射は針の差し込み〜薬液注入〜抜くまでに10秒以上かかり（物理的には抜き・刺しを一瞬で行うことはできるだろうが…心理的には厳しい）、刺す場所がまずいとこの間「ずっと痛い」のである。
また、差し込みの途中で痛みのあまり針を抜いてしまうとやり直しである。この「中断できてしまう」=「複数回痛みに襲われうる」というのが痛みに弱い族としては辛い…「どんなに痛くても完遂できる」人種なら苦労しないのだが。
自分的インスリン注射のコツ
病院で or ネットで入手した情報を試した今のところベターな打ち方は以下。 （ネットの情報を信じるのもどうなのよ…と思うが病院では痛みや出血を避ける具体的な方法は教えてくれないし禁忌行為とは言われなかったのでもう知らん）
- 薬液中の気泡は内側の針カバーをつけた状態で注射器を机の角などに打ち付けて動かす（指で弾いても動かないし指が痛くなるだけ）
- 針を刺す前に針の先端で肌をつついて「明らかな痛点」を避ける
- これに時間をかけると針を意識してしまって「どこを刺しても痛い」モードに入ってしまうので「激痛でなければOK」の意識が大事
- 痛点の密度は 1mm 平方あたり数個らしいので、1cm 四方程度の範囲で最初に見つけたマシな点に打つ
- 皮膚を引っ張り上げるように持ち、垂直に打つ（これは多分病院で指導されているだろうが）
- 針を抜いた後の出血や薬液は拭き取らない（拭き取り時にせっかく注入した薬液が吸い出されてしまうことがあるとかないとか。苦労して打っているのに勿体無いので服が汚れる方がマシ）
これだけやっても2日に1回くらいは効いてないような血糖推移を見せるインスリン注射君…せめてうまく打てたのかどうかモニタリングできてほしい。
アリスクローゼット世界考察
アリスクローゼット
alice-closet.jp
キャラデザが種村有菜なので始めました。
マザーツリーから生まれたアリスという人形を着せ替えて美しさを競うクロージーという競技が普及している異世界：ワンダーランドに来てしまった主人公が元の世界に戻る手がかりを探しながら自らが目覚めさせた特別なアリスとの絆を深めていくゲーム。（長い）
ストーリー内ではワンダーランドの仕組みについては詳しく説明されない。まぁ多分関係無いしな...。
- マザーツリーと人間が共生する世界。
- ツリーは人間の「美しい」という感情を主なエネルギー源（=マナ？）として集め、対価として人間に加護を与えている？
- アリスは着飾ることで人間にマナを生じさせ、回収。一部を自分の活動源と成長（アリスはクロージーを通して能力が高まる）に、残りをツリーに送っている？
- 定期的な着せ替えが必要なのはそうしないと人間が飽きる = 感情が生まれないから。
- アリスは成長すると美しくなる = マナを効率的に発生・回収できるように自らを美化している。
- クロージーが強いアリスオーナーが社会的地位を得やすいのはそれだけツリーからの加護の重要性が高いから。
- オリジナルアリス = 原種？
- オリジナルは少数の高適合者（アリスに感情移入しやすく、情動 = マナが大きい）しか開花させられないため、普及に難がある。
- アリスの能力を制限することで適性が低い人間でも開花できるようにした。（能力は低いが数が爆発的に増やせる）
- 通常のアリスが感情・身体表現に乏しいのはその能力を削られているため？
- クロージーテーマをツリーが指示するのは欲しいマナの種類があるのかも？
- アリスのおてつだいは低効率なマナ回収手段？（24hクロージーしているわけにもいかないし）環境調査（何が美しいとされているか）の一環かも。
- 少ないとはいえ少年型のアリスがいるのはやっぱり少年にしか萌えない人もいるからだろう。分かる。
