Software Frontloading and QA

1. ソフトウェア開発における品質の作り込み～フロントローディングの基礎～ SQiPシンポジウム2019 併設チュートリアル3 11th Sept 2019 (Wed) Yasuharu NISHI 電気通信大学大学院情報理工学研究科情報学専攻経営・社会情報学プログラム @YasuharuNishi / Yasuharu.Nishi@uec.ac.jp Also Read: https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation-modified https://www.slideshare.net/YasuharuNishi/ software-frontloading-and-qa

2. Profile • Assistant professor: – The University of Electro-Communications, Tokyo, Japan • President: – Association of Software Test Engineering, Japan - Nonprofit organization (ASTER) • President: – Japan Software Testing Qualifications Board (JSTQB) • National delegate: – ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246) • Founder: – Japan Symposium on Software Testing (JaSST) • Founder: – Testing Engineers’ Forum (TEF: Japanese community on software testing) • Judgement Panel Chair / member: – Test Design Contest Japan, Test Design Competition Malaysia (TDC) • Vice chair: – Software Quality Committee of JUSE (SQiP) • Vice chair: – Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME) • Steering Committee Chair – QA4AI Consortium • Advisor: – Software Testing Automation Research group (STAR) © NISHI, Yasuharup.2

3. 本日の流れ • はじめに：フロントローディングとは何か？ • 製造業におけるフロントローディングの要諦 • ソフトウェアのフロントローディングが目指すべき姿 • デジタル化による上流でのモデルベース検証の考え方 • バグ分析・RCA（根本原因分析）からの水平展開の考え方 • レビューの考え方 • まとめ：フロントローディングとは何か © NISHI, Yasuharup.3

4. フロントローディングとは何か？ • （上面ではなく）前面から作業対象物やメディアなどを出し入れする機構。水平に出し入れする機構は特にスロットイン方式とも呼ばれる。 – 家庭用DVD/BDレコーダーなどでは既に一般的 – 家庭用VTRでは1982年頃から採用された • パナソニック/ナショナルはNV-750（1982年）から採用した – レコードのスロットインプレーヤーも存在する – ドラム式洗濯機もフロントローディングと呼ぶ © NISHI, Yasuharup.4

5. フロントローディングとは何か？ • “Distribute or allocate (costs, effort, etc.) unevenly, with the greater proportion at the beginning of the enterprise or process. “ – (Oxford Dictionary) – 「後ろよりも前でやる」 • 後ろの作業を前でやると何かいいことがある • 四千頭身 – ワタナベエンターテインメント所属・2016年結成のトリオ – お笑い第七世代の旗手 – 代表的なネタ：「たたみかけ方」 • https://www.youtube.com/watch?v=bhCEOSVNSco • キーとなるツッコミ：「前半にたたみかけるな」 – 残念ながら漫才ではフロントローディングしてもいいことはほとんどない • 四千頭身のネタはこの構造を笑いにしている着眼点が画期的である © NISHI, Yasuharup.5

6. 製造業におけるフロントローディング • 開発初期の段階で、より多くの問題解決サイクルをあらかじめ回しておくことによって、開発後半における、より手間のかかる設計変更の繰り返し開発を減らすこと – 「生産マネジメント入門 II」, 第14章“開発期間とその短縮”, 藤本隆宏著, 日本経済新聞社 • 生産マネジメントというタイトルの教科書だが、生産だけでなく開発全体を扱っている – 開発期間短縮はフロントローディングだけでなく、個々の活動の短縮やタスク分割とオーバーラップなどと同時に行われる • オーバーラップ方式はコンカレントエンジニアリングやサイマル開発、承認図方式とも呼ばれる • オーバーラップ方式でも後工程はより早期に実施される – そのため厳密にフロントローディングだけを区別しないで論じていく © NISHI, Yasuharup.6

7. 製造業におけるフロントローディングの代表例 • コンカレントエンジニアリング – 全体設計と部品設計の同時進行や設計と生産準備の同時進行 • （狭義の）フロントローディング – 3D-CADやCAEによる仮想検証やシミュレーションによる試作実験の削減 © NISHI, Yasuharup.7 前倒しするプロセス標準を策定しツールを買えば成功する？

8. 製造業におけるフロントローディングの要諦 • コンカレントエンジニアリングの要諦：工程の前後が本質ではない – ただ工程を前に持ってくるだけでは失敗する • 「…成功のポイントは、簡単に言えば、上流と下流とが互いに『変更含み』の確定情報（例えばスケッチや詩作図の段階の設計情報）を頻繁にかつ小出しに交換し、それを手掛かりに相手の動きを予測し合って相互適用することである。その前提としては、あいまいな情報を処理する能力、（注：上流の）『完璧主義』や（注：下流の）『日和見主義』といった組織風土面での弊害の克服、開発と生産の相互信頼関係の確立、部門間調整メカニズムの発達などがある」（生産マネジメント入門II） – 伝統的な日本企業が得意だった…はず… • ワイガヤ、大部屋方式 • 強い生産部門、強い系列サプライヤ © NISHI, Yasuharup.8

9. 製造業におけるフロントローディングの要諦 • （狭義の）フロントローディングの要諦：ツール購入が本質ではない – 組織的問題解決能力を高めていくことが本質であると理解する • 「（上流における）品質の作り込み」とは問題解決の前倒しに他ならない • DRBFM（故障モードベースレビュー）も実はフロントローディングである – 腰を据えて取り組む覚悟が必要である • 「金井： MDIとして正式に始まったのが96年でしたけど、試作車レスが2005年の『ベリーサ』でまがりなりにも実現するまでに10年かかりました」 – 「マツダ心を燃やす逆転の経営」, 山中浩之著, 日経BP社 © NISHI, Yasuharup.9

11. 時代は変わった • VUCA – Volatile（すぐ変わる） / Uncertain（確信が持てない） / Complex（複雑な） / Ambiguous（曖昧な） – 正解が分からない世界になった • スケーラビリティ – スケールするやり方こそが正義な時代になった • スケールできるツールやサービス、技術が常識になった • デジタルトランスフォーメーション（DX） – 多くのものをコンピュータに処理させることができる世界になった • ソフトウェア開発はとてもDX化が遅れている • DXできるツールやサービス、技術が常識になった • ゆとり – 合理的に思考し納得感を重視し共感を大事にする世代が中心の世界になった • でもこれってゆとり世代特有ですかね？ © NISHI, Yasuharup.11

12. 変われない組織 • 開発部隊レベルの障壁 – 膨大な技術的負債 – 技術ロジスティクスの欠如 – 形骸化・官僚化した品質マネジメント – 受動的で他律的なエンジニア – 丸投げ体質 • 経営レベルの障壁 – 製品の多様性 or 受託ビジネス – ミッションクリティカル性 – 「開発のあり方」を考え抜く役職の不在 – 投資能力の欠如 /イノベーションのジレンマ – 企業レベルのハードウェア開発との融合 © NISHI, Yasuharup.12

13. きちんと考える時間が増えれば、よりよいソフトウェア開発になる • きちんと考える – 高速実験する – みんなの知恵を集める – 良いことを繰り返す – 悪いことを避ける – 抽象化して整理して俯瞰して脳みそをクリアにして合理的に考えて納得感を共有する • （きちんと考える）時間を増やす – 手を動かしているところを機械にやらせる – きちんと考えていない時間を減らす © NISHI, Yasuharup.13

14. イマドキのQAがトライすべき技術の例 • きちんと考える – 高速実験する • 逐次迅速リリース • カナリアリリース/ABテスト/ブルーグリーンデプロイ • シフトライト（リリース後現地自動テスト） – みんなの知恵を集める • ペアxxx/モブxxx/開発成果物の共同所有 • 計画ゲーム/バーンダウンチャート/ソフトウェアかんばん • デイリーミーティング • 振り返り © NISHI, Yasuharup.14

15. イマドキのQAがトライすべき技術の例 • きちんと考える – 良いことを繰り返す • デザインパターンなど • サービス指向でツールや技法も含んだ複合型プロダクトライン開発 – 悪いことを避ける • バグ分析・RCA（根本原因分析）からの水平展開 • ソフトウェアトラップ分析（不具合モード分析） – 抽象化して整理して俯瞰して脳みそをクリアにして合理的に考えて納得感を共有する • TDD（テスト駆動開発） • リファクタリング • 各種モデリング/パターン/ソフトウェアトラップ • QAアーキテクチャ/レビューアーキテクチャ/テストアーキテクチャ • 納得感共感マネジメント © NISHI, Yasuharup.15

16. イマドキのQAがトライすべき技術の例 • （きちんと考える）時間を増やす – 手を動かしているところを機械にやらせる • CI/自動テスト • トレーサビリティ管理 • モデルベース開発/モデル駆動開発/自動プログラム生成 • デジタル化による上流でのモデルベース検証 • 機械学習による不具合分布推測/自動バグ検知/自動バグ修正 – きちんと考えていない時間を減らす • ユーザ価値の追求：UX/USM • 仕様の読み解き・整理・一元化 • 形式的仕様記述 © NISHI, Yasuharup.16

17. イマドキのQAが持つべきスタイル • 開発がきちんと考える時間を増やすことをミッションとする – 開発者自身によるQAが可能になるように戦略を立案し遂行する • 品質を高めるために開発がどうなるべきでQAはそれに対して何をすべきか、を日々とことん考え抜く – 「QAの手が足りない」のではなく、考え抜いていないから戦略が不在で開発が共創してくれないだけ • だから開発の増加に応じてスケールできるQAのプラクティスでなくてはならない – QAは開発者に対する「サービス」の提供だと認識しサービスの改善を日々行う • 開発がいつもQAに感謝し信頼してくれるようになるために何が必要かを常に開発と話し合う • 開発者がすべきことを丸投げされるサービスになってはいけない © NISHI, Yasuharup.17

18. イマドキのQAが持つべきスタイル • QA自身もきちんと考える時間を増やす – レビューやテストの内容を抽象化して整理して俯瞰して脳みそをクリアにして合理的に考える • 「全体としてどんな品質をどこでどのように保証しているのか」をいつも説明できるようにする – QAのプラクティスをデザインするのは、ソフトウェア開発と同じくらい高度な技術である – プロセスやメトリクス、カバレッジといった間接指標だけで判断するのは時代遅れである – 「悪さの知識」を分析し蓄積し展開するのはQAだからこそのプラクティスである • 開発には「どう作るか」の知識が自然に蓄積されていく一方、「どうすると間違えるか」を考えるのはあまり好きでない傾向がある © NISHI, Yasuharup.18

19. イマドキのQAが持つべきスタイル • コンテキストに合ったフォーカスを定めプラクティスをデザインする – コンテキストとは、市場でのプロダクトの存在感やポジション、（母体を含む）設計・ソースコードのサイズや複雑さや質、開発技術や組織能力の程度、などから構成される – フォーカスとは、そのコンテキストにおいてQAが何を向上させるべきか、という定性的目標である • とにかく速く何度もリリースを行って市場で存在感を示したり、市場で学ぶべき時期に行うQA活動は、詳細に一貫性が取れているかや保証のエビデンスを確保することにフォーカスさせるべきではなく、主要な価値やUXが損なわれないことと、開発スピードが上がること、成長できるチームになっていること、などにフォーカスさせるべきである – 「なぜ」そのプラクティスがそのプロダクトや開発チームに有効なのかを常に説明できるようにする • 同じプラクティスであっても、コンテキストが異なればフォーカスが異なるため導入の方法も異なる – プロダクトや開発チームの現状を十二分に理解し、成長モデルを開発と共創する • どの部門もどのチームもいつでもどこでも一律に適用できるプラクティスなど存在しない © NISHI, Yasuharup.19

20. イマドキのQAが持つべきスタイル • 納得感の共感をマネジメントする – ソフトウェアは、測定や手順による品質の保証が根源的にできない • 素材は物性を測定すれば（確率的に）品質や寿命の保証ができる • 作業内容を完全に記述しきれるものは、手順の遂行を確認すれば品質を保証できる – ソフトウェアは究極的に「ちゃんと考える」という作業になるので、作業内容は完全には記述できない – ソフトウェアのQAの本質は、「ちゃんと考えたと皆が納得している」ことを保証することである • 品質が確保できたことをテストで示すこともできるが、全てをテストするのは不可能である • 「ちゃんと考えたと皆が納得した」のに不具合が出たのであれば、それはその組織の技術力の限界であると諦観し、その不具合を源に技術力を向上させるのがエンジニアリングである – 「想定外を想定できる」なんていうことをほざくのは、論理矛盾に気付かない馬鹿か、エンジニアリングを理解していない文系か、机上の空論を振りかざす科学者のどれかである • 「ちゃんと考えたと皆が納得する」ことを保証するために、3x5x3=45種類の保証動作を組み合わせる – （出力/入力/環境 x 内容の理解度 x 最終成果物/ユニット/入力・中間成果物）の組み合わせになる – プロセスやメトリクスは、低い内容理解度を表す集約指標に過ぎない – 全員が納得感を共感している組織は、そもそも強い組織である • QAは、開発もQAもマネジメントも、顧客も発注組織もパートナーも、全員が納得感を共感していく「旅」である • アジャイル開発の原則やプラクティスは、納得感を共感できるようにデザインされている © NISHI, Yasuharup.20

21. 時代遅れのQAの技術 • フェーズゲート型QA • 指差し確認QA（=プロセス重視型QA/ルール監査型QA） • メトリクス「でしか」判断しないQA © NISHI, Yasuharup.21

22. ソフトウェアのフロントローディング • 「イマドキのQAがトライすべき技術の例」はどれも実はフロントローディング的である – きちんと考える • 高速実験する / みんなの知恵を集める / 良いことを繰り返す / 悪いことを避ける /抽象化して整理して俯瞰して脳みそをクリアにして合理的に考えて納得感を共有する – （きちんと考える）時間を増やす • 手を動かしているところを機械にやらせる /きちんと考えていない時間を減らす • ハードウェアのフロントローディングとは何であったか？ – 解決すべき時に解決すべきことを解決すべき範囲で必要十分なだけ最適な方法で解決できるための問題解決能力の向上 © NISHI, Yasuharup.22 「フロントローディング」という謎の言葉に惑わされてはいけない

23. そうは言っても • （特にハードウェアの人たちに説明しやすい）ソフトウェア開発におけるフロントローディングの技術はある – デジタル化による上流でのモデルベース検証 • からの、機械学習による不具合分布推測/自動バグ検知/自動バグ修正 – バグ分析・RCA（根本原因分析）からの水平展開 • ソフトウェアトラップ分析（不具合モード分析） • フロントローディングは目的ではなく手段である、ということを念頭に置く – フロントローディングに取り組むことで、ソフトウェア開発全体がよくなっていく • 技術ロジスティクスを構築することになる – フロントローディングを行うと、それ以外にも高度化すべきQA技術があることが分かる – それ以外のことをやっていると、自然とフロントローディングしたくなる – フロントローディング「だけ」が成功することはない © NISHI, Yasuharup.23

24. 目指すべき姿 © NISHI, Yasuharup.24 「フロントローディングすると嬉しいよね」と皆が自然に思える状態が理想である

26. デジタル化による上流でのモデルベース検証 • 実機/実環境よりも上流で動作する環境 – 様々な環境やツールがあり、ドメインや固有技術、開発環境によって異なる • 開発の上流で動作するモデルベース開発環境 • 開発の上流で動作するモデルベース検証ツール • 実機/実環境がなくても動作する仮想環境 – イマドキはDevOpsやデジタルツインなど実現しやすい技術が進んできている • QAもモデル化や仮想化といった技術を身につけることが必要になる • 上流における検証の設計 © NISHI, Yasuharup.26

27. デジタル化による上流でのモデルベース検証 • 実機/実環境よりも上流で動作する環境 • 上流における検証の設計 – まず上流を「デジタル化」する • Excel方眼紙やテキストボックスだらけのWord、パワーポイントの仕様書は「デジタル化」ではない • 「デジタル化」とは、コンピュータ処理が可能になるよう構造化された情報になっていることである – QAは開発情報のデジタル化も推進していく必要がある – 次に開発全体で、どこでどのQA観点/テスト観点/検証性質を保証するかを俯瞰する • 開発やレビュー、テスト、シミュレーションといった各工程でどのようなQA観点を保証するか、そのためにどのようなQA工程を配置するか、といった「QAアーキテクチャ」をデザインする – 自動化できる検証はモデルベース検証ツールで自動検証を行う • モデルベース検証ツールは限定された検証性質（QA観点/テスト観点）しか検証しない – 自動化できない検証はモデルベース開発環境や仮想環境で手動検証を行う • テスト設計は自動化できないけどテスト実行は自動化できる、といったように完全に自動化できなくても一部自動化できるのであれば、なるべく自動化する • 自動化しやすいように開発してもらえば開発できるところ、はQAから開発に強く投げかける © NISHI, Yasuharup.27

28. デジタル化による上流でのモデルベース検証の例 • 様々な実用例がある – T-VECやPolyspaceなどのMatlab/Simulinkにおける各種検証ツール – TLA+ (Amazon)などの各種形式手法やツール – KML（川口順央氏@ライフロボティクス）のように独自でモデル化を行ってもよい – QACやCoverityなどの各種静的解析ツールも広義のモデルベース検証である – （仮想環境における）テストケースの自動生成から自動実行は MBT（モデルベーステスト）やKDT（キーワード駆動テスト）として普及している • これらがきちんとできるようになると… – Sapienz/SapFix (Facebook)のような自動バグ検出/自動バグ修正技術 – GAFAM-BATHのような機械学習によるバグの多そうなモジュールのリコメンド © NISHI, Yasuharup.28

29. QAアーキテクチャとは？ • 我々は全体として何を品質保証しているのかを把握しているのだろうか？ – 保証したい（プロダクト）品質とは何だろう？ – いつそれらを保証しているんだろう？ • QAアーキテクチャをデザインすることで、全体としていつ何を品質保証しているのかを把握する – 保証したい（プロダクト）品質をQA観点としてモデル化する：QA観点モデル – 各QA観点を保証しているのかをモデル化する：QAパイプラインモデル – ハードウェアのQAにおけるQC工程表やQAネットワーク（保証の網）と呼ばれる技術と同等である © NISHI, Yasuharup.29 SUT

30. Fully-automated VSTeP • テスト戦略立案 – 自組織のコンテキストを把握しフォーカスを定め、開発の自動化とテストの自動化の進度やバランス、投資額や人員アサイン、対象プロジェクトや共通化などをマネジメントする • 「下回り」を構築するSET的職種に腕っこきを配置するのがミソ • テスト要求分析 – テスト観点モデルはエンジニアが徹底的に頭を使う – どの観点群を自動化し、どの観点群は手動に留め、自動化するために開発側に手を入れなくてはならないところなどを決め、反復的に成長させる • テストアーキテクチャ設計 – コンテナやフレームの設計はエンジニアが徹底的に頭を使う – QAパイプラインを組む • まずは、ごく限定され粒度が細かく小さい、自動化しやすい観点やフレームだけを並べて、なるべく早く回るようにする – それに合わせてKDTの下回りやCI環境を徐々に整備する • テスト詳細設計 – 各フレームで用いるテストモデルを開発の仕様書や設計書と紐付ける • 必要なモデルが無ければ開発側に作るよう働きかける – モデルベースドテストでテストケースを自動生成する • テスト実装・実行 – キーワード駆動テストとして（自動生成された）テストケースを自動テストスクリプトに自動変換する – 構築したCI環境で24時間自動実行を行う © NISHI, Yasuharup.30 GUI 機能データ動作環境プラットフォームネットワーク OS ハードウェア OSの種類 OSのバージョン IEのバージョン電子メール

31. デジタル化による上流でのモデルベース検証の注意点 • QAは「エンジニア」であって「管理屋」でも「ツール紹介屋」でもない – 世界中で最新の技術を調べ、触れ、試し、身につけることが必要である • QiitaやSlack、Githubといったイマドキの環境は必須である • QAが社外のコミュニティに参加したり、コーチやコンサルタント、研究機関に有償で支援を依頼したり、経験のある有能な人をリファラル採用する、といった施策も重要である • ツールや環境を整備する人には腕っこきを配置する – イマドキはSETチームと呼ばれ、高い技術とサーバントシップが要求される貴重な職種となっている • くれぐれも「手の空いた人」や「現場で使えない人」に担当させない • 全社一斉導入などは間違っても目論まない – コンテキストをきちんと把握し、フォーカスを決めて取り組む • 既に興味を持っており、高い技術を持った、開発難易度の低い、余裕のある、喜んで協力してくれる、成功しそうなチームと一緒に共創して、まず成功事例をつくる • ツールや環境を導入することが目的ではなく、問題解決の上流化が目的であると肝に銘ずる – 自分たちの問題は何かを明確に答えられない限り、逆立ちしてもデジタル化による問題解決はできない • 問題点をきちんと把握しているからこそ、独自で、しかし必要な分だけモデル化を行うという選択肢もアリになる – コストダウンと納期短縮を目標に設定すると、まず間違いなく失敗する • 問題解決能力の向上や、開発を「あるべき姿」に近づけること、スピードアップ、などを大きな目標にするのがよい • 腰を据える、そのために熱意を持って経営や周囲を巻き込む © NISHI, Yasuharup.31

33. バグ分析・RCA（根本原因分析）からの水平展開 • バグ分析、と言っている人が目的だと思っていることランキング（にしの心の中調べ2019） 1位：よく分からないけどやることになっているからやる • ムダの極み 2位：バグの存在する場所を明らかにしてデバッグのための情報を得る • 必要な作業だが、今日話したいのはこのことではない 3位：経営や管理職、QA部門などが犯人捜しや「仕事してますエビデンス作成」のために行う • 百害あって一利なし 4位：バグの傾向を掴み手を打つ • 役に立ちそうに見えるが… © NISHI, Yasuharup.33

34. バグ分析には大きく分けて2つある • マクロ分析（バグの傾向分析） – 目的 • 組織全体としてどのチームにどんなバグが多いか、を把握する • プロダクトのどの部分にどんなバグが多いか、を把握する • 工程のどこでどんなバグが入りやすいか、を把握する – 代表的な技術 • フォールトプローン技術 • ODC（直交欠陥分析） – 問題点 • 施策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある – 基本的にフロントローディングの技術ではない • バグの中身や開発の中身をきちんと見る習慣が失われる傾向がある – 「QAは時間がない」は言い訳である • 傾向という名の数値が一人歩きする傾向がある – 管理図の統計的意味も分からずに折れ線グラフを描いて「〇〇管理図」とか言い出したりする • よほど注意して実施しないと、形骸化と官僚化の温床になる – マクロ分析からの間接施策（プロセスを決めろ/変えろ、この目標メトリクスを達成しろ）は最悪である • ミクロ分析（バグのパターン化） © NISHI, Yasuharup.34

35. バグ分析には大きく分けて2つある • マクロ分析（バグの傾向分析） • ミクロ分析（バグのパターン化） – 目的 • バグ、もしくはバグの原因をパターン化して水平展開し、再発防止・未然防止を行う • 根本原因分析（RCA: Root Cause Analysis）やなぜなぜ分析として行われる – 代表的な技術 • キーワード分析 • 機能分析 • 現象分析 • 開発者属性分析 • プロセス分析 • 構造分析 • （欧米型）FMEAと呼ばれる一群の何か • ソフトウェアトラップ分析（不具合モード分析） – 問題点 • そもそも水平展開や再発防止・未然防止という用語の理解が曖昧である • 技術（パターンの抽出方法）によっては出来の悪いマクロ分析になる • よほど注意して実施しないと、吊し上げになり形骸化の温床になる © NISHI, Yasuharup.35

36. バグのパターン化の（現場で使われている）技法 • キーワード分析 – 容易だが精度は低い • 例）「日次平均値算出機能」に対し、類似のキーワードを含む仕様や機能にバグが多いと推測する技法 • 機能分析 – 容易だが精度は低い • 例）「日次平均値算出機能」に対し、機能ツリーのうち近い機能にバグが多いと推測する技法 • 現象分析 – 容易だが精度は低い • 例）「日次平均値算出機能」がダウンしたとすると、ダウンしたバグを集めてパターン化する技法 • 通常は意味あるパターンは抽出できない © NISHI, Yasuharup.36

37. バグのパターン化の（現場で使われている）技法 • 開発者属性分析 – 容易だが精度は低いし、やってはいけない • 開発者の体調や心理状態、経歴や出身に着目する技法 • 個人攻撃になったり人事評価につながるので、中長期的に悪さの情報が隠蔽されるので品質は下がっていき官僚化していく • プロセス分析 – 容易だが精度は低い • 「～を読んでない」「～を知らない」「～に従わない」「～を確認しない」「誤った～を読んだ」「～を誤って解釈した」のように分析する技法 • 構造分析 – そこそこ難しいが精度はそこそこ高い • 例）「日次平均値算出機能」がスタックを用いているとすると、スタックや類似した構造を用いている設計部位にバグが多いと推測する技法 • 例）「日次平均値算出機能」がスタックオーバーフローを起こしたとすると、スタックなどオーバーフローを起こしうる構造を用いている設計部位にバグが多いと推測する技法 © NISHI, Yasuharup.37

38. バグのパターン化の（現場で使われている）技法 • ソフトウェアFMEAと呼ばれる一群の何か – 故障モードを機能や現象の抽象概念だと捉えると、精度が低くなってしまう • 欧米型は、ソフトウェアの各モジュールからの機能不動作（演算間違いや遅延など）を故障モードと捉えるため、内部的な現象分析になってしまう • 公表されている事例Aは、内部処理 x 能力 x 現象の3つ組に着目するため、内部的な機能分析や現象分析になってしまう • 公表されている事例Bは、データ間の構造の考慮不足などに着目している • 公表されている事例Cは、瞬断時の異常や他動作中の移動など、発生条件に着目している – 残念ながら、多くの書籍や論文、発表資料はあまり有益でないことが多い • そもそも故障モードはハードウェアのQCや信頼性工学でも議論が分かれる概念である – 電子素材のように固有技術的に確立しているらしい分野もあるようだ • 精度よく使っているハードウェア組織では、故障モードは設計ノウハウそのもののため、外部に公表する資料には掲載されない – だからDRBFMをソフトウェア屋が読むと変化点解析になってしまう – 著者はバグのパターン化ができないのかもしれないし、できるけど有益なパターンを外部に公表できないかもしれないし… © NISHI, Yasuharup.38

39. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から作られる構造や機能にはバグが多いと推測する技法 – ソフトウェアの入力成果物（仕様書や母体設計書）に開発者がバグを作り込んでしまう「トラップ（罠）」が含まれているため、開発者はそのトラップに引っかかってしまい吸い込まれるように出力成果物（設計書やソースコード）にバグを作り込んでしまう、という考え方である • 例）「優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい」 • 河野哲也氏（現DeNA）らが不具合モード分析として確立し、嬉野綾氏（ワークスアプリケーションズ）らがバグシェルジェ（ASTER）という研究グループで議論を進めている – 類似品に注意：水平展開やフロントローディングを行えない類似品もある © NISHI, Yasuharup.39

40. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から作られる構造や機能にはバグが多いと推測する技法 – ソフトウェアの入力成果物（仕様書や母体設計書）に開発者がバグを作り込んでしまう「トラップ（罠）」が含まれているため、開発者はそのトラップに引っかかってしまい吸い込まれるように出力成果物（設計書やソースコード）にバグを作り込んでしまう、という考え方である • 入力成果物は開発者の思考プロセスへの入力なので、プログラミング言語仕様や直前に作成した成果物のこともある – 例） C言語で発生するif文での代入というバグは、混同しやすい=（代入）と==（比較）を同じ場所で使えるようにした言語仕様がトラップになっている » そのためMISRA-Cなどでは規格で禁止することで「フロントローディング」を行っている • トラップによって引き起こされる「人間の思考の誤り」を意識する – 一般的なヒューマンエラーは、実のところ「人間の思考の誤り」は取り扱っていない • 人間系の要因は「ブースター」として分離して取り扱う – 「前の晩に夜更かしして注意不足だった」はトラップではなくブースターである – ブースターを根本原因として取り扱うと、対策が大味になりがちで、バグと施策が結びつかず、効果がでにくい傾向がある © NISHI, Yasuharup.40

41. ソフトウェアトラップ分析（不具合モード分析） • ソフトウェアトラップ（不具合モード）を含む仕様書や母体設計書から作られる構造や機能にはバグが多いと推測する技法 – トラップにはパターンがあるので、そのパターンをフロントローディングする • テストにフロントローディング：ピンポイントテストのテスト観点にする • レビューにフロントローディング：レビューのチェックリストに加える • 開発にフロントローディング：開発ガイドラインに記載する – 水平展開しフロントローディングするために分析するので、水平展開できそうもない/する必要のないバグは分析しない • 本当にうっかりしたために作ってしまったバグは分析しない – 本当にうっかりであれば、トラップに依存せずランダムに発生しているはず – 本当にうっかりではないのに開発者が「うっかり」と答えるのであれば、その組織はバグ分析を始める前にすべきことがある – トラップが全くイメージできないものは無理に抽出しない方がよい • 分析にはスキルや経験が必要である • 分析にはかなりの時間がかかるので腰を据えて行う必要がある – 分析に協力してくれる開発者がいる方が分析もフロントローディングも進む © NISHI, Yasuharup.41

42. トラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 二卵性双生児 • 順序が逆のものが混在すると、混同しやすい – 優先順位の表現で1（高い）～5（低い）と5（高い）～1（低い）が混在すると混同しやすい – リトルエンディアンとビッグエンディアンが混在すると混同しやすい – True/false値（1/0）がハード側とソフト側で異なる • 対称であるべきものが一部非対称であると、混同しやすい – アームの行きの動きのルーチンと帰りの動きのルーチンが一部異なっている – ifdefでコンパイルし分けるコードのCPU使用率が異なるので処理が間に合わない © NISHI, Yasuharup.42

43. トラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 二卵性双生児 • 派生開発で複数のソフトを流用して統合する際に、統合元の前提が成立すると思い込んでしまう © NISHI, Yasuharup.43 I1 M1 I1 M1 I1 M1 M2 I2 I1 M1 M2 cI +H/Wによって初期化処理I1が 1度で済むようになった =1 ≧2 =1 ≧2 =1 ≧2 ユニット1とユニット2を統合した新しいユニットを開発することになった初期化処理I1 に気付いていたがなるべく手を入れたくないためどうせスキップされるからと I1をメインループに残してしまった I1のカウンタは共通初期化処理cI を反映しないので初期化処理が 2回動いてしまった

44. トラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 例外 • 後から追加された例外的な仕様は、設計漏れを引き起こしやすい • 複数ある対となっている条件の両方に必要な正常処理は設計できたが、特定の対の片方の条件だけ例外的に必要となる準正常処理が抜けてしまった – ポットの水位の事例 – 浦島太郎 • 割り込み先から帰ってきたら、割り込み元の状態が変わっていた – オートフォーカスの事例 – 山登り船頭 • 指示側に指示を出さずに、被指示側に直接指示を出すと、指示側と被指示側の状態が食い違う – コンプレッサーの緊急停止の事例 – GCありのプラットフォームからGCなしのプラットフォームへのポーティングの事例 © NISHI, Yasuharup.44

45. トラップの例 • 実際に各社で抽出されたトラップの例（特定できないように一部改変しているところがあります） – 逆向きの予備動作 • ある動作をする場合に、特に動作の準備をしている時に、逆の働きの動作をする – データ圧縮の事例 – 永遠とゼロ • ソフトや仕様では時間が永遠/ゼロという仮定が置かれているが、現実世界では実時間がかかる – 搬送の事例 – 「備考」 • 備考欄に書かれるものは、書かれないと問題が起こるほど重要なのに、本文に入れられるほど構造化されていないものである © NISHI, Yasuharup.45

46. トラップを用いた水平展開 ① 類似のバグを収集する – 水平展開すべきと思われるバグに狙いを付ける – バグ票をよく読み、バグを作り込んでしまった時のことをありありと想像する – 似たような作り込みをしてしまったと思われるバグを収集する © NISHI, Yasuharup.46 ①類似のバグを収集するトラップAとBの親トラップα 抽出されたトラップA 存在が推測されるトラップB 実際のバグa1 実際のバグa2 出現が予想されるバグa3’ 出現が予想されるバグb1’

47. トラップを用いた水平展開 ② トラップを抽出する – 類似した複数のバグのバグ票を同じ構造の記述に書き換えながら、共通のトラップをイメージする – 類似した複数のバグとトラップの記述を、本質的に共通な部分と異なる部分に区別する – 共通な部分を残し異なる部分の記述を代名詞に置き換えることで、トラップのヒントを得る – あーでもないこーでもない、と議論する – それこそがトラップだ、と分析チームが納得感を共感するまで繰り返す • よい名前をつけてあげましょう © NISHI, Yasuharup.47 ②バグからトラップを抽出するトラップAとBの親トラップα 抽出されたトラップA 存在が推測されるトラップB 実際のバグa1 実際のバグa2 出現が予想されるバグa3’ 出現が予想されるバグb1’

48. トラップAとBの親トラップα 抽出されたトラップA 存在が推測されるトラップB 実際のバグa1 実際のバグa2 出現が予想されるバグa3’ 出現が予想されるバグb1’ トラップを用いた水平展開 ③ 同じトラップから生まれると予想される、まだ見つかっていないバグを導出する – トラップを含みそうな入力成果物を探す – トラップが当てはまる仕様や設計などに生まれそうなバグを予想する – 予想したバグを見つけられるようなレビューやテストを設計したり、実際のバグと予想したバグ、元となったトラップを開発ガイドラインに追記する © NISHI, Yasuharup.48 48 ⑤deriving a bug instance from inferred bug classes ③同じトラップから生まれると予想されるバグを導出する

49. トラップAとBの親トラップα 抽出されたトラップA 存在が推測されるトラップB 実際のバグa1 実際のバグa2 出現が予想されるバグa3’ 出現が予想されるバグb1’ トラップを用いた水平展開 ④ 類似のメカニズムを持つトラップを推測する – 人間の思考の誤りをイメージしながら、トラップを抽象化して親トラップを抽出する – その親トラップと同じメカニズムを持ちそうな子トラップを推測する – あーでもないこーでもない、と議論する – あーそのトラップもあるねー、と分析チームが納得感を共感するまで繰り返す © NISHI, Yasuharup.49 ④類似のメカニズムを持つトラップを推測する

50. トラップAとBの親トラップα 抽出されたトラップA 存在が推測されるトラップB 実際のバグa1 実際のバグa2 出現が予想されるバグa3’ 出現が予想されるバグb1’ トラップを用いた水平展開 ⑤ 推測されたトラップから生まれると予想されるバグを導出する – トラップを含みそうな入力成果物を探す – トラップが当てはまる仕様や設計などに生まれそうなバグを予想する – 予想したバグを見つけられるようなレビューやテストを設計したり、実際のバグと予想したバグ、元となったトラップを開発ガイドラインに追記する © NISHI, Yasuharup.50 ⑤推測されたトラップから生まれると予想されるバグを導出する

51. 水平展開の距離と精度 • 水平展開の距離が遠ければ遠いほど精度は下がるが、思わぬ機能や設計で発生する不具合が推測できる – 分析スキルが低いうちは、あまり無理して遠い不具合まで予想しない方がよいだろう – 適切にフロントローディングできると、近場のバグは撲滅でき、遠いトラップやバグを開発者から教えてもらえるようになる © NISHI, Yasuharup.51 トラップAとBの親トラップα 抽出されたトラップA 存在が推測されるトラップB 実際のバグa1 実際のバグa2 出現が予想されるバグa3’ 出現が予想されるバグb1’

52. バグ分析会議/RCAミーティングの運営 • ダメなバグ分析会議 – 犯人捜し/責任追及・上司による責任回避 – 吊し上げ/晒し者 – 根拠のない思い込みと決めつけ、説教と自慢話 – その後の悪い人事評価 – 防御的心理 © NISHI, Yasuharup.52

53. バグ分析会議/RCAミーティングの運営 • よいバグ分析会議 – 「納得感」の「共感」を軸にしてバグの分析を行う • 自分でも引っかかってしまうと納得できるトラップを探す • 適切なパターン化ができた瞬間は、分析会議の参加者が「あーそのトラップにはみんな引っかかるよねー」と納得し、皆が共感するようになる – 開発者への敬意を前面に出す • 悪いのはトラップであって開発者ではない、という姿勢を崩さない – 「スキルの高いあなたで “すら” このトラップに引っかかるんですから、若い連中なんてなおのこと…」 – だからトラップ分析ではトラップとブースターを明確に区別している • バグを作り込んだ人という扱いではなく、トラップの情報を提供してくれる人として尊敬を前面に出すと、前向きの会議になって共感しやすくなる – 効率を求めてはいけない • 分析に時間がかかるのはスキルが低いからだが、時間をかけてよい分析をしない限りスキルは向上しない • 途中でみんな現場に戻りたくなって分析の質が落ちるところをグッと我慢してもらう © NISHI, Yasuharup.53

54. バグ分析/RCAによるフロントローディングの注意点 • 開発者が「腕が上がった」と思える施策を立案する – 開発者の「こんなことやっても意味ないよな」という実感を大事にして、そうならないような施策を立案する – 「腕が上がった」と思ってくれれば、どんどん協力してくれるようになる • そのバグだけを未然防止できる具体的で小さな施策を立案し、少しずつ注意しながら施策を大きくする – 全社一律や部門全体に効きそうな施策は、結局のところ大味で誰の役にも立たない – 大味な施策ほど名前を付けやすいので、「仕事をした感」を出しやすい • 「あーもっと早く気づけたのに」という後悔ドリブンにする – 誰も後悔していないバグはフロントローディングできない – 後悔しているバグはトラップも見つけやすい © NISHI, Yasuharup.54

55. バグ分析/RCAによるフロントローディングの注意点 • フロントローディングした作業のための工数をきちんと確保する – どんなバグが出そうか、を皆で考える会議を開発の最初にやる場合、きちんとプロセス名をつけて見積もりに載せて工数を確保しないと、「いつまでお喋りしてるんだよ、とっとと作れよ」という圧力をはねのけられない • パターン集を買おうとしない – ソフトウェア開発やQAは至るところで抽象化やパターン化、水平展開が必要になる – バグ分析/RCAを上手にやれるようになるのは確かにしんどいが、しんどい原因は自組織に抽象化能力やパターン化、水平展開の能力が育っていないからである – しんどいからと言ってパターン集を買ってきてしまうと、そうした能力が育たないため自組織に特有のバグがパターン化できず、現場に役立つバグ分析にならないし、継続的な取り組みにならないし、他の取り組みでも上手くいかない • 先ほど提示したパターンは単なる例示だと受け取って欲しい • パターンを売らんかなの人たちとは付き合わず、一緒にあーでもないこーでもないと抽象化能力を鍛えてくれる人と付き合う方がよい © NISHI, Yasuharup.55

56. バグ分析のアンチパターンと効果の薄い対策 • Vaporization（その場限りの簡単なミスとして片付けてしまう） – コーディングミス：コーディングスキルを向上するようプログラミング言語教育を行う – 考慮不足：しっかり考慮したかどうかレビュー時間を増やし確認する – うっかりミス：うっかりしていないかどうかレビュー時間を増やし確認する • Exhaustion（不完全な実施や単なる不足を原因としてしまう） – しっかりやらない：しっかりやったかどうかレビュー時間を増やし確認する – スキル不足：スキルを向上させるよう教育を行う – 経験不足：経験を補うためにスキルを向上させるよう教育を行う • Escalation（上位層に責任を転嫁してしまう） – マネジメントの責任：トップを含めた品質文化を醸成する • Imposition（外部組織に責任を転嫁してしまう） – パートナー企業の責任：パートナー企業を含めた品質文化を醸成する • Culturalization（文化的問題に帰着してしまう） – 品質意識／品質文化の欠如：全社的な品質文化を醸成する © NISHI, Yasuharup.56

58. レビューの改善 • レビューの改善はフロントローディングの行き先の一つである – まず会議術の改善と、レビュー固有の技術の改善に分ける • 会議術の改善：モデレータを置きましょう、会議室を確保しましょう、話を聞きましょう… • レビュー固有の技術の改善：レビュー観点の整理、レビューケースの作成、レビューアーキテクチャ – 自分たちの開発のレベルをきちんと把握してレビューの改善を行う • 会議術の改善で効果が出るレベル – 上司に忖度して雰囲気が悪い、準備してきてないのでムダな時間だらけ、など • 一貫性やトレーサビリティをチェックするだけで効果が出るレベル – 「～が揃っているか？」「～がどこから来ているかが明確になっているか？」など • 言語上の特性を考慮するだけで効果が出るレベル – 「この文章は他の意味にも取れるよね？」「この代名詞はどちらを指すの？」など • 開発者の思考のロジックトレースと指差し確認で効果が出るレベル – 「～が書かれているか？」「～が考慮されているか？」など • 悪さの知識を水平展開して（推測可能であるにも関わらず）思わぬバグを見つけたいレベル – 「仕様書にこういうトラップがあるけど、どこでどう気をつけた？」など © NISHI, Yasuharup.58

59. レビュー観点によるレビュー（ケースの）設計 • レビュー観点を明示してレビューケースの設計を行う必要がある – まずレビューには設計が必要だと考え、設計成果物に名前を付ける • レビューで確認したいことや狙いたいことを「レビュー観点」と呼ぶ • レビューで本質的に質問したいことや指摘したいことを「レビューケース」と呼ぶ • レビュアーが発する質問や指摘項目の具体的なセリフなどを「レビュー手順/レビュースクリプト」と呼ぶ – レビューケースを体系的につくりだすことを「レビュー（ケースの）設計」と呼ぶ • テストの設計をしている組織は多くなってきたが、レビューの設計を意識している組織はまだ少ない • チェックリストはレビュー設計のガイド、もしくは参照モデルである • レビューはテストよりもピンポイントで探索的である © NISHI, Yasuharup.59

60. レビュー観点によるレビュー（ケースの）設計 • レビュー観点を明示してレビューケースの設計を行う必要がある – レビュー観点は、個々のレビューケースの意図を示している • レビュー観点は、レビュアーの持つ技術力を示している – レビュー観点を蓄積していない人や組織がレビューすると、誤字脱字チェックなどの重箱の隅レビューや、指差し確認レビューになる – レビュー観点の不明なレビューは、意図の分からないレビューになるため、往々にして時間がかかる割に意味の無いレビューになる • シンプルなレビューであれば、レビュー観点だけでレビューケースになるかもしれない – レビュー観点をきちんと列挙したりモデリングすることが、モダンなレビューでは必須である • ダメなレビューチェックリストはレビュー観点が不明だったり偏っていることが多い • レビュー観点の粒度や関係を適切に把握しレビュー観点を構造化/モデリングすべきである © NISHI, Yasuharup.60

61. レビュー観点によるレビューアーキテクチャの設計 • どのようなタイプやレベルのレビューを行うことによって、どんな品質をどう保証するのか／どんなバグを検出するのか、の全体像を描く活動をレビューアーキテクチャと呼ぶ – マスターレビュープランやレビュー戦略と呼んでもよい – 個々のレビューのアクティビティ（≒レビュー会議）をレビューコンテナと呼ぶ • 例） ○○サブシステムに対する性能レビュー、○○サブシステムレビュー、性能レビュー • それぞれのレビューアクティビティでどのレビュー観点を分担するのか、を明示する – レビューコンテナ間の順序関係や依存関係を明示して、レビューの全体像を描き把握する © NISHI, Yasuharup.61

62. レビュー観点によるレビューアーキテクチャの設計 • どのようなタイプやレベルのレビューを行うことによって、どんな品質をどう保証するのか／どんなバグを検出するのか、の全体像を描く活動をレビューアーキテクチャと呼ぶ – レビューコンテナ内のレビュー観点、レビューコンテナで用いる技術や必要な技術レベル、レビューコンテナの（副次的）役割などをはっきりさせる • レビューレベル：レビュー対象物の種類や粒度、順序関係などによる分類 – 要求レビュー、仕様レビュー、アーキテクチャレビュー、詳細設計レビュー、コードレビュー、サブシステムレビュー、モジュールレビュー、派生部位レビュー、母体レビューなど • レビュータイプ：レビューの意図や観点、技術などによる分類 – 割込処理レビュー、ウォークスルー、インスペクション、性能見積もり、セキュリティ設定確認、形式検証など • レビューサイクル：類似のレビューコンテナを繰り返す際の分類 – ○○レビュー第2回、やり直しレビューなど • レビューの（副次的）役割は組織ごとに色々多岐に渡る – レビューアーキテクチャとテストアーキテクチャを合わせたV&Vアーキテクチャを用いると、開発工程の進捗に合わせてどのように品質が保証されていくのかが可視化できる • V&Vアーキテクチャが無いと、メトリクスやプロセスで「間接保証」せざるを得ず、大味になる © NISHI, Yasuharup.62

63. レビューの（副次的）役割 • 確認の役割 – 仕様との一致 – 標準との一致 – 意図した役割（顧客満足？） • 指摘の役割 – 不具合の指摘 – 弱点の指摘 – 設計考慮事項の指摘 – リスク評価・不具合影響評価 • 設計改善の役割 – よりよい設計の提案 – 問題解決策の提案 – 代替案・回避策の提案 • マイルストーンの役割 – 進捗の報告 – 工程完了の判定 • コミュニケーション・合意の役割 – 開発者同士 – 開発者とリーダ・マネジャー – 開発チームとステークホルダー – 開発者と顧客 • 教育の役割 – 技術の伝達 – 良い設計を見せる – 不具合指摘の着眼点を伝える – トレードオフのバランスを伝える • 監査の役割 • 作業改善・プロセス改善の役割 – 原因の検討と改善 – 申し送り事項（簡易設計ガイドライン）の作成と周知徹底 – 次回プロジェクトへの改善

64. レビュー観点によるレビュー（ケースの）設計 • レビュー観点を明示してレビューケースの設計を行う必要がある – レビュー観点は、個々のレビューケースの意図を示している • レビュー観点は、レビュアーの持つ技術力を示している – レビュー観点を蓄積していない人や組織がレビューすると、誤字脱字チェックなどの重箱の隅レビューや、指差し確認レビューになる – レビュー観点の不明なレビューは、意図の分からないレビューになるため、往々にして時間がかかる割に意味の無いレビューになる • シンプルなレビューであれば、レビュー観点だけでレビューケースになるかもしれない – レビュー観点をきちんと列挙したりモデリングすることが、モダンなレビューでは必須である • ダメなレビューチェックリストはレビュー観点が不明だったり偏っていることが多い • レビュー観点の粒度や関係を適切に把握しレビュー観点を構造化/モデリングすべきである © NISHI, Yasuharup.64

66. ひと昔前にWモデルというのが流行りましてね… • Wモデル – 本来は、テスト要求分析やテスト設計を前倒しすることで、最初から筋のよい設計でバグが少なくテストしやすいソフトウェアを開発すること • まずは筋のよいテスト要求分析やテスト設計、テスト観点を目指すことが大事 • 国内できちんとWモデルを普及しようとしていた人たちはこう言ってました – しかしいくつかの組織では、テストをCPM法にしたままテストケースを書くという膨大な単純作業をそのまま上流に前倒しして、失敗してしまった • CPM法（Copy&Paste&Modify法）：仕様書をコピペしてテストケースを増殖させる最悪のテスト設計 • いくつかの組織では、単価の高い上流エンジニアが膨大な単純作業を行うだけでなく、仕様変更に伴う追従工数が大量に発生し、コストや納期がオーバーしてしまった • なんで失敗したか分かりますか？ © NISHI, Yasuharup.66

67. 現在シフトレフトという単語が流行ってましてね… • 「シフトレフト」が何を指すかを深く考えずに、技術記事やツールの宣伝文句に踊らされている人も少なくない – Wモデルなんて知らない – 当然ながら製造業におけるフロントローディングなんて知らない • 成功すると思いますか？失敗すると思いますか？ © NISHI, Yasuharup.67

69. まとめ：フロントローディングとは何か • 単なる作業の前倒しではない • 単にデジタル化による上流でのモデルベース検証とバグ分析からの水平展開だけを指しているわけではない • 組織的問題解決能力を高めていくことである – 解決すべき時に解決すべきことを解決すべき範囲で必要十分なだけ最適な方法で解決できるようになることである – 「技術ロジスティクス」でもある • 考えるべき時に考えるべきことを考えるべき範囲で必要十分なだけ最適な方法で考えられるようになるために、知恵やノウハウ、技術が循環する仕組みを「技術ロジスティクス」と呼ぶ • （ある側面から見た）QAそのものである © NISHI, Yasuharup.69

70. まとめ：品質保証は組織を賢くするためにあらゆることをする最高にやりがいのあるクリエイティブな仕事である