企業レベルのMission、Vision、Valueを部門やチームレベルに落とし込む作業が割とむずかしい件・後編
モダンなQAに変わるには vol.5
IT業界では有名なコンウェイの法則。
システムを設計する組織は、その組織のコミュニケーション構造を真似た設計を生み出す。
（Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.）
私も経験上「そうだよねー」と思います。
組織の構造は目的達成のためのカタチであり、うまく組織を設計すれば、自ずと目的達成の近道となる…そういった意味でコンウェイの法則は正しいのです。
Management 3.0 にメドラーズゲーム（Meddlers game）と呼ばれるプラクティスがあります。
私は昨年11月にメンバー変更を伴う組織変更を実施しましたが、マネジャー達と何度もこのメドラーズゲームをしながらシュミレーションと議論を重ねました。（何れこの話はブログに書きたいと思います）
この手の施策に正解はありません。
しかし、COVID-19 対策でエンジニアが全員リモートワークになったいま、コンウェイの法則を思い出してしまうのです。目的達成のためのベストなチーム構造は、マネジャーの責任で「考え続ける」ことがとても重要なのでしょうね。
部門長のみなさん、一緒にメドラーズゲームしてみませんか？（なお、私はManagement 3.0のライセンスファシリテーターです）
前編では組織、チームを強くするには「言葉を分類するためのフレームワーク」を使ってわかりやすい「言葉」を作るのが大事と書きました。
後編は、これを自部門であるSPQIに適応してみます。（やっと「モダンなQAに変わるには」の話題になります）
SPQIは、もとは品質保証部という名であり一般的にはQAと呼ばれる部門です。一見すると、部の名前がそのまま組織目標に聞こえますが果たしてそうなのでしょうか？
「言葉を分類するためのフレームワーク」を使って考察してみましょう。
1. 現状（外部・内部の環境）
まず、昨年FY2019を振り返りながら考えました。次の４つを掲げます。
・ すべての部門間で壁が（まだ）ある
・ SPQIが出荷のボトルネックと思われている
・ 開発エンジニアが自分たちのプロセスを説明できない
・ ひとりひとりの仕事量が多い次に詳細を説明します。
すべての部門間で壁が（まだ）ある
まず、部門間で壁がまだ残っていると感じています。たとえば、我々は他部門の方から稀に「QAさん」と呼ばれます。他意はなくとも、少し壁を感じて悲しいです。
品質に責任を持つのは「一丸となったチーム」であって「QAさん」ではありません。同様に「SPQIはなんでこんなバグを見逃したわけ？」といった声があがるようでは本当の品質保証が出来ていないのだと思います。
また、他部門が何をしているか理解がまだ足りていません。それによる誤解、レッテルが発生し、簡単なコトが複雑になってしまっている様に思います。
ウイングアーク全体のバリューチェーンを、どれぐらいの人が理解できているのでしょう。
SPQIが出荷のボトルネックと思われている
SPQIが、未だに出荷のボトルネックだと思われています。
確かに、プロセスの終盤にまとめて検証作業を行えばボトルネックになります。
しかし、我々も昨年からカイゼンを進めています。QAプロセスのスループットを増やす努力は続けますが、DevとOps、すなわち開発プロセスももっとカイゼンの必要がありそうです。
開発エンジニアが自分たちのプロセスを説明できない
これは弊社に限らず、よくある話しだと思います。日本のソフトウェア業界の問題かもしれません。
「アナタはどんな開発プロセスで仕事をしていたのですか？」
私が中途面接で良く聞く質問です。しかし、キチンと答えられるエンジニアはけっこう少ないです。
ウォーターフォールでもない、アジャイルでもない …じゃあ、それは一体なんなの？
一流のエンジニアは常にアンテナ高く自分たちに合ったやり方（プロセス）を模索していて、それなりに回答が出来るはずなのです。
ひとりひとりの仕事量が多い
SPQIのメンバーは「仕事量がとても多い」と感じています。人的リソースが少ない面もありますし、開発遅延によるしわ寄せもよくあります。
やらなければいけないタスクを厳選していても限界はあります。また、誤解されがちですがテスト自動化は、ムダは減りますが仕事量を減らすことには繋がりません。
現状（外部・内部の環境）のまとめ
図にまとめます。
2. なりたい姿（Vision）
この、Vision が行動の原資となります。上記では「現状」を次のように定義しました。
・ すべての部門間で壁が（まだ）ある
・ SPQIが出荷のボトルネックと思われている
・ 開発エンジニアが自分たちのプロセスを説明できない
・ ひとりひとりの仕事量が多い
上記は、ほとんどが課題です。すると「なりたい姿」はこれを解決できた世界を想像し、それを言葉にすればよさそうです。
そこで、私は次の言葉を作りました。
・ プロダクト間、役割間（開発・QA）の連携を強化する
・ プロダクトの特性、ステージに合った品質保証体制を構築する
・ フィードバック・サイクルを短くし、カイゼンプロセスを早くすることでリリースサイクルを安定させる
3. 社会に提供する価値（Mission）
これは、とても大きな問いに感じました。
プロセス改善や品質改善という業務を、私たちはなぜやっているのか？The Data Empowerment Company としてSPQIが行うべきMissionは何か？を念頭に、次の言葉を作りました。
・ プロダクト、サービスを継続的に高品質で提供する
4. 顧客に約束する価値提供
ここも悩みました。
品質を通してお客様に何を約束できるか、社内のいろんな人と会話して掴んだ言葉がこれです。
・ 品質を守り抜くことで信頼される
・ 品質問題による機会損失をゼロに
5. 戦略、戦術
さて、いよいよ大事な部分です。
その前に、戦略（Strategy）と戦術（Tactics）って言葉はあいまいで分かりにくいので、ここでは以下のように定義します。
・ 戦略（Strategy）はシナリオ。「なりたい姿（Vision）」に向かうための道すじ。What
・ 戦術（Tactics）はアクション。戦略を実現するための具体的な手段。Howまず戦略（Strategy）です。「2. なりたい姿（Vision）」では次のような言葉を作りました。
・ プロダクト間、役割間（開発・QA）の連携を強化する
・ プロダクトの特性、ステージに合った品質保証体制を構築する
・ フィードバック・サイクルを短くし、カイゼンプロセスを早くすることでリリースサイクルを安定させる
この「なりたい姿（Vision）」に向かうための道すじ＝戦略（Strategy）は次の2つです。
戦略
・ 開発とともに品質を作り込む
・ DevとQIがお互いを対等な立場で信頼している次に、この戦略を実現するための具体的な手段＝戦術（Tactics）を挙げてみます。次の５点です。
戦術
・ プロダクトマネジメントを確立する
・ 品質基準の再定義
・ 知恵の集結
・ 開発子会社（中国）へのテスト業務拡充
・ シフト・レフト、シフト・ライト詳細を以下に説明します。
プロダクト・マネジメントの確立
社内のエンジニアと話していると「プロダクト・マネジメント」と「プロジェクト・マネジメント」が、混同されています。これは、似て異なるものです。
書籍「リーン開発の本質」では、次のように言語化されています。
プロジェクト型開発（計画駆動）・ 予算が開始時点に決まっている
・ 成功は、コスト・スケジュール・スコープが満たされるかどうかで計測される
・ 始まりと終わりがある
・ プロジェクトマネージャーによって指揮されるプロダクト型開発（マーケット駆動）・ 予算は各ステージごとに徐々に調達される
・ 成功は、その製品が最終的に得たマーケットシェアや収益に基づいて計測される
・ 始まりはあるが、うまくいけば終わりがない
・ プロダクトマネージャーとテクニカルリードのペアで指揮される
長年、プロジェクト・マネージメントの世界では
・ 始まりと終わりがある
と、言われ続けていました。
「スケジュールを守ってリリースする」がよくあるゴールイメージです。それは、多くのプロジェクトによっては間違いではありません。
しかし、我々は請負SIerではなくプロダクト開発企業です。
スケジュール不安よりも、戦うべきはマーケット不安をどうするかです。何を作れば売れるのか？どんな機能が喜んで頂けるのか？が大事なのではないでしょうか。
「スケジュールは守った。けど製品は売れていない。」
…といった状況だと会社のVisionである「Empower Data, Innovate the Business, Shape the Future.」の達成は難しいです。
もちろん、プロダクト開発においても「約束」を守ることは大事です。ただ、目指す価値（＝アウトカム）はスケジュールとは違います。製品をお客様に届け、課題を解決できてはじめてアウトカムを達成したと言えます。
・ 始まりはあるが、うまくいけば終わりがない
この「うまくいけば」とはプロダクトが認められ「購入頂ける状態」です。製品が売れて価値が届き、お客様の課題が解決されてはじめて企業Visionが達成できるのです。
SPQIのテスト作業においても、よく「テスト計画」を立てますが、上記を踏まえると「フェーズゲート型QA」はプロダクト型開発（マーケット駆動）にはあまり合っていません。テスト計画は、変化に対応させるアジャイルな計画でないと、それこそQAがボトルネックとなります。
なにより重要なのはDevの開発プロセスをアジャイル型へシフトさせなければ、他社との競争に勝てない時代だと思われます。
品質基準の再定義
昨年からの継続戦術となりますが、まだ道半ばです。
品質基準とは、品質の目標です。ウイングアーク１ｓｔの前身は、プロダクトごとに開発会社が分かれていたこともあってか各製品の品質基準がバラバラでした。これを再定義しプロダクトごとの特性にあった品質マネジメントを行う基準作りをしています。
本年度は、クラウド・サービスに重点を置き深い考察をしたいと思ってます。
知恵の集結
プロダクト、サービスを継続的に高品質で提供するには、エンジニアひとりひとりがキチンとした開発手法を手に入れ、アジャイルなマインドセットも身に着けなければなりません。
そこで、SECIモデルを意識したサイクルを回したいと思います。
ウイングアークの強みとなっている暗黙知を表出し、それを繰り返せる仕組みを作るのです。安易に他所からもってくのではなく、ウイングアーク内の知恵の集結させ、ウイングアークに合わせた知識創造プロセスを実行します。
今年度のはじめの一手は、プロダクト開発に必要な知識を体系的に可視化するサイト“GROW”（Genuine Reinventing Organization in Wingarc1st）を立ち上げます。
GROWは、ウイングアーク１ｓｔのエンジニア、プロダクト・マネージャー全員にとっての、Playbook（定石集）を目指します。
開発子会社（中国）へのテスト業務拡充
現状分析の中で「ひとりひとりの仕事量が多い」という課題がありました。業務のカイゼンを進めつつ、人的リソース不足は発生していますので、それを開発子会社で補いたいと思います。
これまではテスト業務の一部しかお願いしていませんでしたが、今期はさらにお願いする業務量を増やし、人的リソース不足を補いたいと思います。
シフト・レフト、シフト・ライト
こちらも、道半ばですので継続します。
昨年度は、昔のエンドゲーム・スタイル（開発の最終工程でテストの合格を目指す）から、シフト・レフト・テスト（Shift Left Testing）に変える戦術を打ち出しました。
シフト・レフト・テスト・ ライフサイクルの早い段階でテストを開始できる
・ 開発完了後に行っているテスト実行を、もっと早い段階でかつ自動的に継続的に実施する
・ 早い段階でテストを実行するために、コンポーネントがそろわない状況でもE2Eテストを実行できるようにする
・ GUI経由の機能テストをAPIレベルで行うテストが実行できるようにする
クラウド・サービスやスマートフォンアプリ（OTA）はリリースサイクルが短く、そもそもフェーズゲート型のQAは合わないということは、すでに現場で体感出来ていると思います。
また、今年度はよりフロントローディングを意識した品質カイゼン活動を行います。
一例を上げれば、サポート情報（お客様からの問い合わせ情報）を分析し、それを元にテスト設計をすることでテスト項目の実行精度を上げる…といった活動です。
そしてさらに、シフト・ライト・テストにもチャレンジしていきたいと思っています。
シフト・ライト・テスト・ 運用中にもテストを行い品質を監視するとで常に品質を保証し続ける
本来、シフト・ライトはDevOpsの文脈でいうとOps側の施策です。
最近ホットな Chaos Engineering や、Canaria Release、A/B テスト、Monitoring など、日常の開発にこれらの「テストを組み込む」ことは先進的なソフトウェア企業なら取り組まれている事です。
これらを実現するためには、我々SPQIメンバーは今よりももっとDevとQAとOpsの距離を縮める詳細な戦術プランとアクションをする必要があります。技術的にも、心理的にもです。
戦略、戦術のまとめ
ここままでの戦略、戦術をまとめます。
6. 理想的な行動
ウイングアーク１ｓｔには、Employee Principlesと呼ばれる行動指針があります。
ここでは、これをそのまま当てはめます。
1． 課題に向き合ってスピード感を持って解決する
Overcome challenges quickly.２． お互いを尊重し共通の目的達成のチームになれる
Enjoy being creative, Embrace the challenge.３． 挑戦し、創造することを楽しむ
Work together, Respect each other, Achieve Common Goals.
7. 大切にしたい価値観、文化、強み（Value）
ウイングアーク１ｓｔとしての Core Value を基本として、SPQIとしてのValue も考えました。
・ Build the Trust
・ アジャイルのマインドセット（Be Agile）
・ スピードと品質の両立
・ 透明性の担保次に詳細を説明します。
Build the Trust
まず、ウイングアーク１ｓｔの価値観である Core Value は、そのまま当てはまります。
我々が事業を成功させてきたのは、お客様やパートナー、社内のメンバーと信頼を築いて来た結果によるものです。それは、相手の期待を超える成果をだし、特別な信頼を得る事が出来るという信頼のループです。
この信頼のループは、これからも繋げ続ける必要があります。
Build the Trust
相⼿の期待を超える結果を出し、信頼される。
アジャイルのマインドセット（Be Agile）
昨年度から「アジャイルの価値観を品質改善に取り入れます」という宣言をしていましたが、今年度も継続します。
ただ昨年度の皆さんを見ていて、もう少し「アジャイル」の解説が必要と感じました。
書籍「エンジニアリング組織論への招待」には、「アジャイル」について次のように記載されています。
アジャイルという言葉を開発方式として捉える人は、「アジャイルをやる」とか「アジャイルをする」といったような表現を使います。
当然のことながら、「agile（俊敏な）」というのは形容詞であって、名詞ではありませんので、「Do agile」とは言うことができません。文法上、「アジャイルになる（Be agile）」とは言うことができます。
これは、アジャイルという言葉が特定の行動ではなく、ある状態を指していることを意味しています。その状態とはまさに「チームマスタリー」を得ている状態であり、「自己組織化された」状態と同じことを意味しています。＊広木 大地 氏. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング Chapter３ より
もともとは状態を指す言葉であり、使い方が近い日本語を強いてあげれば「青春」だと言われています。
「青春だね！」 → 「アジャイルだね！」
本の続きをもう少し引用します。
では、「アジャイルな」状態とは、具体的にどのような状態でしょうか。それは以下のような状態のことを意味しています。 ・情報の非対称性が小さい
・認知の歪みが少ない
・チームより小さい限定合理性が働かない
・対人リスクを取れていて心理的安全性が高い
・課題・不安に向き合い不確実性の削減が効率よくできている
・チーム全体のゴール認識レベルが高い このような状態になれば、チームはチーム自身のもつ生産性を十分に発揮できるだけでなく、よりレベルの高いチームへと自律的に成長していける状態になっていきます。＊広木 大地 氏. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング より
上記のような状態になるには、やらなければならないアクションが沢山ありそうです。
また、もっと自分自身のマインドも変えないと実現できないでしょう。
スピードと品質の両立
これも、前期からの継続戦術です。
昔から品質とスピードはトレードオフである…と言われがちですが、現代のテクノロジーとプロセス改善において、品質とスピードの両立は可能と言われています。
COVID-19が騒がれ始めた今年2月、奇跡的に開催されたデブサミ2020で和田卓人氏の「質とスピード」というプレゼンがありました（これまでも何度かお話は拝聴していますが、数を重ねるごとにプレゼン内容が洗練されていて凄いなぁと思います）。
ここでのお話は示唆に富んでおり、SPQIとしても、まだまだやれるアクションはたくさんあることに気付かされます。
透明性の担保
これも、前期からの継続戦術です。（「担保」は「状態を確保する」という意味で使っています）
「透明性」と聞くと、どうも「上司が部下に隠し事をしないこと」のような捉え方をする人もいるようですが、少し違います。
上手い表現をしているBlogがありますのでご紹介します。
結論から言えば、自分の認識よりも具体性があり、目的まで内在された定義でした。透明性とは、正しい情報が１カ所に整理してあり、次の行動が誘発されることもちろんこれはScrum文脈で出てきた定義なわけですが「人の行動こそ予想できない」という前提に立ち、「チームが現状を把握すること」や「自律的なチーム」を実現することを考えるとまさにしっくりくる表現だなと。Scrumにおける透明性 - Septeni Engineer's Blog
Odd-e Japan アジャイル・コーチの江端さんのお言葉のようですね。（あ！さっきの「青春」の例えは私が江端さんに直接聞いた言葉でした）
「次の行動が誘発されること」の部分がキモかと。
先程の「エンジニアリング組織論への招待」にも次のような記述があります。
そして、しばしば組織において言及されるのが、「情報の透明性」です。情報の透明性というと、「できる限りの情報を公開すること」だと勘違いされがちですが、それは1つの手段です。公開するだけでは、コミュニケーション不確実性のうち、伝達の不確実性をわずかに下げるにすぎません。 「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。 「透明性」とは、つまり、継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態のことをいうのです。＊ 広木 大地 氏. エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング より
よく「うちの上司は会議で決まった大事な事項を教えてくれない」といった嘆きを聞きますが、透明性が担保されていれば、直接聞いてみようという関係性が築けている状態になっているはずです……まだまだですよね？
大切にしたい価値観、文化、強み（Value）のまとめ
ここまでを、まとめます。
これでSPQIの組織づくりの「言葉」が完成しました！
定期的に見直していきます。正直、言葉が細かすぎるかもしれませんが、それでも、実行に移すにはもっと詳細なユースケースに落とし込む必要があります。
それは、SPQIの各グループ、メンバーの皆さんにおまかせしたいと思いますので、どうぞよろしくお願いします。
最後に、上記の「言葉」を踏まえた上で、中期視点のロードマップを作りました。部門目標も記載しましたので、未来への目安にしてください。
今回作った言葉が、メンバー一人ひとりの「思考の羅針盤」になることを期待しつつ、今日はこの辺で。