イレギュラーな事態と向き合う
- イレギュラーな事態はどう頑張っても起こる
- 誰も悪くない
- 粛々と対応しよう
私はQAE/SET（以下、QAEと一括りにする）として、これまでスタートアップから大手日系、外資系企業等、様々なソフトウェア開発チームで活動してきた。QAEに与えられるミッションは、ソフトウェアの品質保証活動、特に手動・自動テストの担当だ。日々の業務を品質保証活動に終止できれば幸せなのだろうが、往々にしてそうはいかない。（QAEに限った話ではないが）組織で活動している以上、我々は時としてイレギュラーなイベントに振り回される。例えばプロダクトのドキュメントが整っていなかったり、複数のQAEが短期間に次々と離脱したり。「これってQAEの仕事でしたっけ？？」「なんで自分がこのタスクしなきゃいけないの」「なぜ自分がこんな酷い目に」と思う瞬間はいつだって訪れる可能性がある。この記事では、よく聞くイレギュラーなイベントをいくつか書いてみようと思う。
プロダクトのドキュメントが整っていない
これは特にQAチームの立ち上げを行うときに直面する課題だが、プロダクトの仕様書やユーザーマニュアルといった公式のドキュメントが存在しない場合がある。あるいは、課題管理チケットとして存在してはいるが、ユーザーストーリやアーキテクチャが十分記述されていなかったり、関連チケットとのトレーサビリティが確保されておらず全体像が把握しにくい状態だったり。テストを実施するにあたり、プロダクトへの理解は必須である。そのため、仕様書の整理やユーザーマニュアルの作成がQAEの最初の活動となる場合がある。なお、私が最も戦々恐々としたのは、シニアメンバーがプロダクトの情報を暗黙知のままにして離脱してしまったときだ。
QAメンバーの同時多発的離脱
この課題は、チーム内のエース/リードエンジニアが離脱した場合や社内の評価制度/組織構成が変わったときに起こることが多い。例えばQAチームにコミュニティで有名な人、チームの精神的支柱の役割を果たしている人が所属している場合、彼らの離脱は他のメンバーの離脱のトリガーとなることがある。よくある理由としては「この人がいないんだったらこのチームに居続ける理由がない」「この人が抜けると業務負荷の増大が目に見えている」といったものだ。また、QAEは時としてエンジニアとみなされない場合もある。所属組織からこのような烙印を押されてしまったとき彼らのプライドがそれを許さず、離脱につながってしまう。
いずれにせよ、同時多発的な離脱が発生してしまった状況では、現場がカオスになることが確定する。業務引き継ぎはもちろんのこと、士気が下がったメンバーのフォローや採用活動強化といったチームの建て直しを行う必要がある。ときには、不足したリソースを補うため（一時的に）他部署の方に品質保証活動の一部を依頼したり品質レベルの目標を下げる必要が出てくるかもしれない。このような状況では日々の業務をテストで終止するなんて場合ではなくて、メンバーやタスクをマネジメントするほうにエネルギーを持っていかれることになるだろう。
正直に言うと、エースエンジニアが離脱したときに自分も離脱しようと考えるのはモチベーションが甘いなと思っている。すごい人の隣で色々学びたかったんだろうけど、エースの側からするとむしろ自分を引っ張ってほしいと感じていたりする場合もある。頼ってくれるのは嬉しいけどアテにはすんなよ、あなたも何か面白いとこ見せてくれよ。。と。
リードエンジニアに引きずられて離職が発生する場合については、組織の上層部がこの関係を早い段階で認識しておくと対策が打ちやすい。タフな彼が自分を盾として膨大なタスクからメンバーを守っているのか？攻撃的な振る舞いをするステークホルダーとの議論を（メンバーにストレスを与えないよう）自分が率先してやっているのか？彼が特定の重要なタスクを達成するために必要な特別なスキルを持っていて、メンバーへのスキル継承がされないのか？このパターンは、チーム内外との関係性や業務フローを見直すことで予防できる場合もある。上層部-リードエンジニア間で1on1を実施するのも効果的な方法ではあるが、各チームが保持している業務量/リソースや人間関係を常時観察できる人がいると理想的だ。
QAEがエンジニアとしてみなされなくなる状況も、しばしば発生するのが現実だ。個人的にはポジションにも所属にも拘りはなくて、品質を始めとした各種改善活動に取り組むことができればなんでもいいと思っている。が、そうでない人も当然いる。組織がQAEをエンジニアとして認識しなくなる理由は「デザインと動きをチェックする人だから」「コードの読み書きができないから」といったものが多い。しかし調べてみると、テストはソフトウェアエンジニアリングの一領域であること、コードを書けることがソフトウェアエンジニアの必須条件であるわけではないことがわかる。経営層の方にはぜひともエンジニアの定義を考えていただきたい、と思いつつ、現場の方も「あなた方の考えるエンジニアとはなんですか、QAEに何を期待していますか」くらいは聞いてみても良いんじゃないかと思う。
A software engineer applies the principles of engineering to design, develop, maintain, test and evaluate computer software. This is often a highly collaborative activity that requires teamwork skills. A software engineer uses components of a hardware system to create the tools to develop software and tends to solve issues on a large scale.
"12 Different Types of Software Engineers (With Salaries)" より抜粋
Software development is the process used to conceive, specify, design, program, document, test, and bug fix in order to create and maintain applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through the final manifestation, typically in a planned and structured process often overlapping with software engineering. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.
Wikipedia "Software development" より抜粋
さいごに
組織で活動していれば、想定外の事態はどう頑張っても起きる。そして、それは誰も悪くない場合が多い。ドキュメントの必要性を理解していてもリソースが足りない。リソースを確保したくても予算が足りない。時が経てば会社の方向性や評価制度が変わってメンバーの心が組織から離れてしまうかもしれない。同志とも呼べるほど分かりあえたメンバーと仲違いし、同じチームで働くことにうんざりすることだってある。全て自然なことだ。特定の個人を責めて解決することではない。この記事も、いくつかのイレギュラーな状況を取り上げてはいるが決して誰かを非難する意図で書いていない。私の主張は冒頭に書いた通り、すなわち「粛々と対応する」ことに尽きる。想定外の事態が起きることを自然なことだと認識してさえいれば、少々心が揺らぐ出来事に遭遇しても案外冷静に対処できると思う。
最後の最後にちょっと意識高いこと書いておくと、こういう想定外の事態は経験値をガン積みするチャンスなのでむしろポジティブに捉えてしまってもよい。日常的業務の外側のタスクに取り組むことで、（大変な思いはするけれども）スキルの幅は少し広がるし乗り切ったときには自信もつく。長期的にはキャリアアップの材料になるはずなので、理想的には楽しんで向き合えるようになるとよい。
神よ、変えることのできないものを静穏に受け入れる力を与えてください。
変えるべきものを変える勇気を、そして、変えられないものと変えるべきものを区別する賢さを与えてください。
一日一日を生き、この時をつねに喜びをもって受け入れ、困難は平穏への道として受け入れさせてください。
ラインホルド・ニーバー「ニーバーの祈り」より抜粋
参考資料
https://www.indeed.com/career-advice/finding-a-job/types-of-software-engineer
QAエンジニア求人まとめ2024
そういえば昨年、こんな記事を書いたのを思い出した：
better-software-testing.hatenablog.com
ちょうど時間が空いているので、今年もやってみる。
モチベーションは以下の通り：
- 現在の自分の市場価値を把握したい
- QAエンジニアの給与レンジが平均的にいくら位に設定されているのか知りたい
- 転職市場がQAエンジニアに求めているスキルを明らかにし、キャリアアップの参考情報としたい
収集手順：
-
https://lapras.com/home から「QA・テストエンジニア」にカテゴライズされている求人を探す
- 求人情報から、以下の情報をメモする（正社員ポジションのみ）
- 企業名
- ポジション名
- 年収下限
- 年収条件
- 必須スキル
- 歓迎スキル
-
https://findy-code.io/homeから「QAエンジニア」にカテゴライズされている求人を探す
- 求人情報から、以下の情報をメモする（LAPRASと情報が重複している場合はスキップする）（正社員ポジションのみ）
- 企業名
- ポジション名
- 年収下限
- 年収条件
- 必須スキル
- 歓迎スキル
収集したデータ：
87社、105件の求人情報を取得した。
ポジションの内訳：
- QAマネージャー/リーダー(候補含む)：13件
- QAエンジニア：82件
- テスト自動化エンジニア：7件
- テストエンジニア/テスター：2件
- QAコンサルタント：1件
大多数がQAエンジニアだった。管理職はぼちぼち。テスト自動化エンジニアの求人数は思ったより少なかった。2-3倍くらいに増えても良いんじゃないか？？テストエンジニアの募集がほぼゼロなのは印象的だった。必須/歓迎スキルを読む限り、QAエンジニアとテストエンジニアは区別されていない様子。
年収：
年収の下限値は500万円、上限値は1,000万円が最頻値。
また、中央値はそれぞれ下限値が500万円、上限値が955万円だった。
前回と比較して、年収下限値は横ばい、上限値は若干上昇していると思う。
上限値が1,000万円以上のポジションはいずれもマネージャー職かな？？と思ったが、そんなことはなかった。メンバークラスでも1,000万円超える機会があるというのは希望が持てる話だと思う。
必須スキル：
QAマネージャー/リーダー(候補含む)に求められるスキル/動き方：
- ソフトウェアテストの知識/経験
- QA業務経験
- QAメンバーのマネジメント経験
- QAメンバーの育成経験
- 他部署とのコミュニケーション能力
- 開発組織横断での品質/プロセス改善経験
- 品質保証戦略の立案
QAエンジニアに求められるスキル/動き方：
- テスト戦略の策定
- テスト計画から設計/実行/不具合報告まで実施
- 不具合分析
- 他部署とのコミュニケーション
- 仕様レビュー
- 開発プロセス改善
- ユーザー目線でのテスト/プロダクト改善
- テスト自動化
- 第三者検証会社のタスクマネジメント
- QCDを意識した活動
テスト自動化エンジニアに求められるスキル/動き方：
- QA業務経験
- ソフトウェア開発/ソフトウェアテストに対する知識と理解
- テスト自動化の経験
- CI/CDツールの利用経験
- ソフトウェア開発経験
- 開発やテストを効率化するツールの開発経験
- チームメンバーとのコミュニケーションスキル
- 自動化による業務改善経験
歓迎スキル：
QAマネージャー/リーダー(候補含む)が持っていると歓迎されるスキル/動き方：
- 品質マネジメント経験
- プロジェクトマネジメント経験
- システム開発経験
- テスト自動化の導入/運用経験
- 全社横断でのプロジェクト推進経験
- ISOまたはJIS規格に関する知識
- 第三者検証会社のタスクマネジメント
- QAエンジニアの採用/育成経験
QAエンジニアが持っていると歓迎されるスキル/動き方：
- システムの開発/運用経験
- テスト自動化の経験
- QAチームのマネジメント経験
- 開発プロセスの改善経験
- プロダクト品質の改善経験
- 他部署とのコミュニケーション
- セキュリティ/パフォーマンス/アクセシビリティといった非機能要件に対するテストの経験
- 第三者検証会社のタスクマネジメント
- リスク管理
テスト自動化エンジニアが持っていると歓迎されるスキル/動き方：
- プロダクトの開発経験
- テスト自動化の構築/運用に必要なプログラミング能力
- システム開発経験
- CI/CDツールの利用経験
- QAリードの経験
- 非機能テストの経験
- AWS等クラウドサービスの知識
- サイバーセキュリティの知識
- 不具合分析
所感：
- 前回調査時と比較して求人数が倍以上になっており情報収集が大変だった。QA業界としては好ましいことだと思う
- 転職市場からはテストエンジニア/テスターというポジションがほぼ絶滅しているのが印象的だった。そのかわり、QAエンジニアという名前で募集されている様子。コミュニティ内ではこれらのポジションは明確に区別されているようだが、転職市場では必ずしもそうではないことがわかる。
- 現状、QAエンジニアに対して求められるスキルが非常に広汎であるため、ポジションを細分化するか、求めるスキルセットを絞るかすると企業/求職者ともに幸せになる可能性が高まると思う
- ドメイン知識を求める求人がそれほど多くないのは少し意外だった。門戸を広くするため敢えて書いてないのだと予想されるけど、特定分野のドメイン知識を持つ人はそれだけで貴重なので、歓迎要件には書いておいても良いような気がする
- テスト自動化エンジニアの求人は、各社手探り状態なのかなという印象を受けた。「なんらかのテスト自動化の経験がある人は来て下さい」的な書き方が多く、何かやってほしいけど何を期待したら良いのか分からない（言語化できない）状態なのかもしれない
参考情報：
Prompt Engineering Guideを読んだ
エンジニアやってる限りAIから距離を置いて仕事をするのは難しくなるだろうなと思ったので、Chat GPTに課金して色々触っている。
私の主な用途はスクリプトの自動生成およびデバッグ作業だが、今のところ大変役に立っている。しばらく前に「GitHub Copilotで開発生産性が70%向上した」的な記事を読んだ記憶があるが、あながち嘘ではなさそう。というか、現在コンピュータサイエンスを学んでいる学生は生成AIを使ってソフトウェアを開発するなんて当たり前にやってしまうんだろうし、市場で生き残っていくためには必要な業務知識になるかもしれないとすら感じた。
- 何らかの処理をおこなうコードを書きたいときにはサンプルスクリプトを生成してくれるし
- 出力されたコードに対してわからないことがあれば解説してくれるし
- コードを自分の環境で実行してエラーが出たときは、エラーの原因を推測してくれる
ので、毎度ブラウザでタブを開きキーワード検索をしてそれっぽいページを複数開き一つづつ確認する、、といった手順をスキップしてくれるためちょっと感動した。生成AIを使うのと使わないのとでは生産性に差が出てしまう時代が来たのだと思う。
AIに自分の意図するコードや情報を出力してもらうためには上手なプロンプトを渡して上げる必要があるので、Prompt Engineeringを勉強しようと思った。
Prompt Engineering Guiteはプロンプト作成の基本的なテクニックから上級者向けの技術、関連する資料やアプリなど網羅的に情報がまとまっていて、大変ありがたかった。特に、Adversarial PromptingではAIに対して悪意のあるプロンプトを実行する方法がいくつか紹介されており興味深い（なお、現在ではいずれも対策されているこのこと）。
現時点におけるChat GPTへの所感としては、「自分が求める出力を得るためには生成AIに寄り添った入力を与える必要があるんだなぁ」ということ。この点においてはまだまだ発展途上だと感じた。プロンプト自体は自然言語で書いているが、Prompt Engineering Guideを読む限りは、生成AIに対して意図や文脈や例を与える必要があるし、これはこれでなんだかプログラミングをしているような気持ちにもなった。あるいは、Prompt Engineeringって21世紀のパンチカードっぽいなぁ、とも。
来年にはオライリーからもPrompt Engineeringの本が出版されるようなので楽しみである。
Irasutoya styleで画像を生成してもらうと「日本のイラスト」っぽいテイストになり大変よい
僕はこういう絵柄が好きなので、良い発見ができた。とても嬉しい。
そういえば、DALL-Eで生成された画像の著作権は誰に属するんだろうと思って調べてみたら、OpenAIとしてはユーザーに持たせたい考えらしい。でも法律の整備が足りてない部分もあるから都度最新の情報をキャッチアップしたほうが良さそう。
ChatGPTが考える、GPT Storeで売れるアプリ
GPT Storeが来年はじめにオープンするとのことで、どんなアプリが売れるのか本人に聞いてみた。
what kind of applications will become popular at GPT Store?
The GPT Store, if envisioned as a marketplace for applications powered by Generative Pre-trained Transformer (GPT) technology, could host a variety of innovative and popular applications. Based on current trends and the capabilities of GPT models, here are some types of applications that might become popular:
1. **Content Creation Tools**: Apps for writing assistance, content generation, and creative writing could be in high demand. These could range from tools helping with academic writing to creative story generators.
2. **Language Learning and Translation Apps**: With the advanced language understanding of GPT models, language learning applications could offer personalized tutoring, conversation practice, and real-time translation services.
3. **Personalized Education Platforms**: Interactive and adaptive learning applications could use GPT technology to provide tailored educational content, homework help, and tutoring in various subjects.
4. **Business Productivity Tools**: These could include advanced email composition assistants, report generators, and meeting summary tools, enhancing productivity in the workplace.
5. **Healthcare Advisory Apps**: GPT-powered applications could offer preliminary medical advice, mental health support, and wellness tips, although with necessary disclaimers and professional oversight.
6. **Customer Service and Chatbots**: Enhanced chatbots for customer support, capable of more natural and context-aware conversations, could be widely adopted in various industries.
7. **Coding and Development Tools**: Applications that assist in code generation, debugging, and providing programming suggestions could be popular among developers.
8. **Entertainment and Gaming**: Interactive storytelling apps, role-playing games, and other entertainment applications could use GPT to create dynamic and engaging narratives.
9. **Art and Design Inspiration Tools**: Apps that provide creative prompts, design suggestions, and art critiques could be useful for artists and designers.
10. **Legal and Compliance Assistance**: Applications that help with legal document drafting, contract review, and compliance checks could find a market in the legal sector.
11. **Data Analysis and Visualization**: Tools that help in interpreting complex datasets and generating comprehensive reports or visualizations could be useful in research and business analytics.
12. **Virtual Personal Assistants**: More advanced and personalized virtual assistants for scheduling, reminders, and daily tasks management could become popular.
13. **Social Media Management Tools**: Applications that assist in content creation, trend analysis, and audience engagement strategies for social media platforms.
14. **Travel and Hospitality Services**: Personalized travel planning, virtual tour guides, and hospitality management tools could enhance the travel experience.
As GPT technology evolves, the potential applications are vast and diverse, limited only by the creativity of developers and the evolving capabilities of the underlying AI models.
キャッチアップをすることについて
僕は今まで7回ほど転職をしており、いろんなソフトウェア開発に携わってきた。
小規模なものから大規模なものまで、新規開発からレガシーシステムまで。
会社の規模も様々で、スタートアップ、メガベンチャー、老舗中小企業、SIer、グローバル企業。。
いずれの組織に関わる場合でも共通して必要になったタスクがキャッチアップである。
「転職してきた人材」には必然、即戦力が求められる。初日からコントリビューションすることは求められないが、まぁジョインして2-4週間くらい経つまでには何か小さな1つのタスクを完遂してみようという方針はどの組織でも共通していたように思える。
そんなわけで、僕は少なくとも7回はキャッチアップをする状況に置かれていたわけだが、となると「いかに早くキャッチアップを進められるか」という課題に思考を巡らせることになる。
キャッチアップを別の言葉で表すと「業務知識と業務フローを理解する」ことだと思う。大抵の組織ではwikiやConfluenceにある程度の情報がまとまっている。wikiやConfluenceが存在しない組織もある（多くの情報が暗黙知として存在している状態）。いずれの場合でも分からないことは無数に出てくるので、その分質問をする必要がある。
このとき大切なのは「どんなに小さい疑問でも質問する勇気を持つこと」「効率よく質問すること」だと考えている。
どんなに小さい疑問でも質問する勇気を持つこと
- こんな初歩的な質問して怒られないかな
- 〇〇っていうニッチなケースの場合はどうすれば良いんだろう。でも重箱の隅をつつくような感じで嫌なやつだと思われないかな。。
という気持ちになることがある。でも気にせず質問していいと思う。あなたの質問に対してキレる人がいた場合、それはあなたの問題ではなくキレた人の問題だからだ。それはその人の人格の問題かもしれないし、たまたまストレスが溜まっていたのかもしれない。また、ニッチなケースについて質問することは、組織やシステムに対する未知の課題を発見したということかもしれない（第三者の視点が入ることにより、未知の課題が明らかになる状況はしばしば発生する）。いずれにせよ、キャッチアップをする段階で質問が生まれることは自然なことで、あなたは何も悪くない。キレられたら他の人に質問をしてみよう（可能なら、その人がキレた理由も質問してみよう）。未知の課題を発見したのなら、それは早速組織に貢献できたということだ。
効率よく質問すること
あなたが質問をするということは、あなたの質問に対して回答をする人が存在するということだ。1つ2つの質問ならチャットや口頭でパパッと聞いてしまえばいいのだが、キャッチアップをする場合は一度に10個以上の質問が出てくるなんてことはザラである。上手に質問できないとやり取りが発生して時間がかかってしまうかもしれないし、自分が期待したものとは違う観点から回答が返ってくるかもしれない。できることなら、お互いコストを掛けずに質問し、回答したいものだ。
- チャット/口頭では一問一答の形式で質問をする。1度に2つ以上の質問をしない
- 質問リストを作成する
- 質問事項に対して、現時点で自分が理解していることと考えていること、知りたいことを明確に記載する
これはあくまで私の経験上の話であって科学的なエビデンスは一切ないのだが、人の脳は2つ以上の質問を同時に処理できないように設計されていると思う。よくある例としては、チャットで2つの質問を投げたとき、どちらか一方の質問に対してのみ回答が返ってくるという場面がある。改めて確認すると回答者はもう片方の質問にも回答できる知識を持っているのだが、なぜか1つの質問に対してしか回答が返ってこない。どういう理由でこうなっているかは分からないが、とにかく色々な人がこういう振る舞いをするということだけは観察できている。なので、チャットベース/口頭で質問をするときは一問一答の形式で話をするとよいだろう。
質問リストを作ることの意義は、多くの人が実践していることなのであまり詳しく説明する必要はないかなと思う。僕がやっているプラクティスとしては、「緊急度が高い質問は質問リストに記載の上チャットでメンションします。それ以外の質問はお手すきの際にご確認ください」と伝えることくらいだ。
ただし、質問をする際には、その時点での理解度、知りたいこと、質問する背景はできるだけ詳しく書いたほうが良いと思う。回答する側としては、
「〇〇」って何ですか
と質問されるよりも
「〇〇」について質問があります。こちらについて社内ドキュメント(orインターネット検索で得た情報)を拝見する限りXXXかなという認識をしておりますが、合っておりますでしょうか。背景としては、現在のタスクを進めるために△△△をしたいと思っています。
のように質問されると、「あぁこの人はこういうことをやろうとしていて、この部分までは理解できていて、この部分で躓いているんだな」と状況を正確に把握することができるため、コミュニケーションギャップを減らすことができる。
この他、「大枠から理解を進める」「質問したことは必ずメモする」「回答をもらったあと、自分の言葉で回答内容を説明し理解できていることを確かめる」といったプラクティスもある。これから新しい会社/プロジェクトに参画する人たちの助けになれば幸いである。
プロセスを導入/改善するときに意識していること
既存の開発プロセスに新しいプロセスを導入したり、プロセスを改善したかったりするときがある。
僕はそういうとき、その場の状況によって２つの方法を使い分けている。
①既存のプロセスが存在せず、新規に立ち上げる場合
例えば、１人目QAとしてチームにジョインしQAプロセスを立ち上げがミッションとなっている場合。この場合は、JSTQBのシラバスや専門書を参考にしてフローチャートや図、表を作って数枚のスライドにまとめる。そして、開発チームのメンバーに「こんな感じで進めたいと思うのですがどうでしょう」とプレゼンする。フィードバックを基にして数回ブラッシュアップし、チームの合意を取ってからプロセスの実施を開始する。
形式張っているというかフォーマルというか、セレモニーを経て導入するイメージ。そこそこ大きめのプロセスを導入する場合はチームに与えるインパクトも大きくなるし、そのプロセスに関して専門知識を持たないメンバーもいると思われる。そのため、関係者と事前に打ち合わせて、影響範囲やリスクを把握した上で導入したほうが良いだろうと思っている。
②既存のプロセスが存在しており、これを改善したい場合
例えば、テストデータの作成がボトルネックになっていて、これを自動化したい場合。この場合は、まず個人レベルで実験を繰り返して試行錯誤し、効果が出たらチームメンバーに紹介するようにしている。別にコソコソやる必要はないんだけど、かといってセレモニーを経たり合意が必要な粒度ではないため、まず自分でやってみて効果を実証してからジワジワ広げていくと良いだろうと思っている（このとき、ドキュメントを用意したりハンズオンセッションを開催したりすると、他のメンバーにも伝わりやすくなる）。
逆にアンチパターン的な振る舞いは何かあるかな、、と考えてみたところ、「虎の威を借る狐」「野次馬」は推奨されなさそうだと思った。
①虎の威を借る狐
例えば、
〇〇っていう技術が話題なんです！A社もB社も導入しています！QA界隈で有名なCさんも使ってるって言ってました！私達も今すぐ始めるべきです！！
みたいな、皆がやってるから凄いんです的な説明の仕方は、チームメンバーから理解を得るのは難しいだろうと思う。「チームの課題は何か」「そのプロセスを導入/改善することで何が得られるか」をロジカルに説明すると納得感が得られると思う。
②野次馬
例えば、
この課題解決するためには〇〇っていう技術を使うといいらしいですよ！すごくないですか？さあ始めてください、ほら、ほら！！
みたいな、要は口は動かすけど手は動かさない的な振る舞いも理解を得られなさそうだなと思った。まずは自分で動くことが大事だと思う。
