トリ氏の登壇内容
トリ氏：
私は原 トリと申します。同僚からはトリさんと呼ばれています。現在、株式会社カミナシで取締役CTOをしています。キャリアの簡単な説明としては、去年の春までアメリカのパブリッククラウド会社、AWSで働いていました。具体的には、Amazon ECSやAWS Fargateなどのコンテナ系サービスのプロダクトマネジメントのチームにいました。
以前は、AWSジャパンでソリューションアーキテクトとして、またそれ以前には小規模なSIerでソフトウェアエンジニアやSREの仕事、さらには新卒でERPパッケージベンダーで働いていました。
今日は、私がCTOをしているカミナシという会社が何をしているかをお話しします。一言でいえば「現場DXプラットフォーム」という形です。BtoB SaaSを提供しています。
このサービスはWebブラウザで使うアプリと、タブレット、スマートフォンで利用できるアプリを提供しています。
主に使用されている分野としては、一般的に知られているようなホテルや飲食業もありますが、特に多いのは食品製造や製造業です。
コンビニのお弁当を大量に作っている現場で、冷蔵庫の庫内温度チェック表や、食品製造におけるHACCP(ハサップ)のような安全管理のプロトコルに基づいた業務をを紙で記録し、管理者が後で全て確認して印鑑を押します。このような紙での管理をデジタルに置き換えるSaaSを提供しています。
会社は今年の3月にシリーズBを調達できました。いわゆるスタートアップです。現在のサービスは約3年前にローンチされました。社員数は現在90人程度で、そのうちエンジニアリング、プロダクトマネージメント、プロダクトデザインが全体の約3分の1を占めています。
この1年の変化についてですが、去年4月に私がカミナシに入社した際には正社員のエンジニアが5人だったのが、今では20人を超えています。
チーム編成としては、主力プロダクトに関わる5人か6人程度のチームが2チーム存在します。
また、新規プロダクトの開発も進行中で、小規模なチームが3つほど立ち上がっています。
カミナシが目指すエンジニアリング組織の形
前提として、カミナシが目指しているエンジニアリング組織の形について、CTOとして以下の三つの原則をブログ記事で明示しました。
- すべてはオーナーシップ
- 開発チーム自身がシステムを運用する
- SRE、QA、プラットフォームの類を安易にチーム化しない
この三つの原則は、価値ある製品を顧客に届けるためには開発チーム自身のオーナーシップが不可欠であり、そのためには各チームが自らのシステムを運用する重要性、そしてSREやQAなどを単独のチームに分けないことを示しています。
チーム化の理想としては、以下の三点が挙げられます。
- フォーカスによる専門領域のExecution Level 深化
- チームごとの役割分担による組織全体のExecution Level 深化
- 希少な人的リソースの「基盤」化
各個人が専門領域にフォーカスすることでExecution Levelを高め、チームが役割を分担することで組織全体のExecution Levelも高まると考えています。さらに、希少な人的リソース、例えばセキュリティのような分野を、社内で組織として基盤化することが理想的だと思います。
一方で、チーム化にはダウンサイドも存在します。
「これは向こうのセキュリティがやってくれる」（ので、自分たちは関与しない）
「これは向こうのチームが権限持ってる」（ので、自分たちは口を出せない、出しにくい）
といった考え方によって、オーナーシップが曖昧になり、誰も手を出せなくなる状況が発生してしまいます。その結果、「どうせ手を出せないんだったら、口を出すのもやめよう」という気持ちが生まれ、良い結果を生むための協力やコミュニケーションが減少する可能性があります。
この現象は、エンジニアリングだけでなく、他のセクションでも同様です。例えば、セールス活動についても、プロダクトチームが望むコミュニケーション方法と、実際にセールスチームが行っている方法が異なる場合、役割の違いから口出しはしづらいです。
このような状況が生じると、プロダクト開発チームがセキュリティや品質について学び、考慮する機会が失われてしまいます。結果として、プロダクト全体に対するオーナーシップが薄れていくのです。それが影響して、「コードを書きました、あとはよろしく」といった形になりがちです。
私がAWSに所属していた時代に、チームが分割されているが分断されていない効率的な組織も見たことがあります。それとは逆に、分断されている組織も存在します。
この体制の良し悪しはその組織が何を目指しているかに依存するので一概には評価できませんが、個人としては良いとは思っていません。
そもそも、SaaSビジネスモデルで提供しても、ただ開発するだけではお客様に価値は届きません。これは当たり前の話です。
良いプロダクトやバックログ、ロードマップを持っていても、それがサービスとして提供されなければお客様に価値は届かないです。これがカミナシで「プロダクト開発チーム」ではなく「サービスチーム」と呼ぶ理由です。フィーチャーチームという言葉をカミナシで意図的に使わないのもこれが背景です。
あくまでもサービスとして提供することが、自分たちの大きく見た時の仕事なんだっていう捉え方をしたいし、してもらいたいと思っています。
プロダクト開発は重要ですが、全体のサービス提供を考慮すると、それは重要な手段の一つに過ぎません。この点が特に、今日のトピックであるSRE（Site Reliability Engineering）、QA（品質保証）、セキュリティなどのファンクションにおいて顕著です。これらはプロダクト開発だけを行っていると気づきにくいのですが、サービスを運用し、そのフィードバックを得ることで、その重要性が明確になります。
ですので、私がエンジニアリング組織に求めているのは、単なるプロダクト開発ではなく、サービス提供全体です。そのため、これらのファンクションはプロダクト開発チームから独立させずに残す方針です。
まとめです。チーム化を考える上では、オーナーシップがとても重要です。良いものを作る、良いサービスを提供するという意志がなければ、質の高い成果は生まれないと考えています。そして、このオーナーシップは組織が分断されると失われがちです。それがSREやQA、セキュリティなどの役割に特に見られます。
したがって、開発チーム自体がSRE、QA、セキュリティといったサービス提供に必要な能力を持つように、その機会をしっかりと提供したいというのが、私のCTOとしての考えやこだわりです。
チームの独立を考えるタイミングについては、少なくともカミナシにおいては、現段階では考えておりません。
とはいえ、セキュリティエンジニアリングの人員が不足している状況であるため、現在のところチーム化自体はしています。ただし、そのミッションについては以下のように伝えています。
「プロダクトをセキュアにすること自体は、あなたたちのミッション責務ではありません。あなたたちのミッションは、サービスチームが独立してセキュアなサービスを提供できるように支援すること、または企業全体としてのセキュリティ文化を築くことである」
この方針をチームに伝え、サービスチームがオーナーシップを持つ形を保っています。現在のセキュリティエンジニアリングチームも、この方針を理解し、実施方法を考えて努力しています。
質問: 「少し極論ですが、カスタマーサクセスやカスタマーサポートの業務も、サービスチームで対応した方が良さそうに思うのですが、どうお考えですか？」
トリ氏：
確かに、エンジニアリング組織がプロダクトマネジメントや営業も含めて全てを手がける方が、オーナーシップが発揮されると私も思います。ただ、カスタマーフェーシングな役割はエンジニアリング組織にとって難しい能力が要求されると考えています。そのため、コードで解決できない領域まで責務を持たせるのは、ちょっと考え物だと思います。
私の考えとしては、コードで解決できる範囲はサービスチームがオーナーシップを持つべきです。そして、カスタマーサポートはエスカレーションのチケットをサービスチームに直接上げてくる、という形で運用しています。お客様が困っている状況はしっかりとエンジニアリング組織にフィードバックする必要がありますから、サポート専門の技術組織も作っていません。
大谷氏：ありがとうございました。役割やチーム化する部分の境界線に関しては、SREやQA、セキュリティが生み出す価値がプロダクトサービスの価値そのものだと思います。その体制を取り入れている点について、深く共感して聞いておりました。
ここからは、パネルディスカッションに参ります。
大谷氏：和田さんがスタートアップで品質保証や信頼性担保に取り組む場合、どのような手法を選び、どこから始めるのかお聞かせください。
和田氏：品質保証に関する取り組みは、組織内でQAの専門家がいるかどうかに依存します。専門家がいる場合、定期的に来てもらったり、レビューをしてもらうなど、いわゆるレビュワーとして関与してもらうのが良いかと思います。
チームの働き方に関しては、一つのチームが多機能を持ち、QAやサポートもそのチームで行う方が効率的です。チームトポロジーで言うところのストリームアラインドチームがオーナーシップを持って進めていくような形です。
しかし、新しいチームが品質保証の経験が乏しい場合は、学習や研修が必要です。例えば、読書会を開く時間を設けたり、経験者にレビューを依頼するなどしています。
このような品質に対する投資は、長期的にコストパフォーマンスが良くなります。最初は時間の浪費に思えるかもしれませんが、不具合が減ると時間が節約されます。
最初にするべきことは、進捗や機能開発だけでなく、未来の投資に使う時間を確保することです。時間を先に確保しないと、後からは取れないので、少量でも確保しておくことが重要になります。
大谷氏：
この辺りの話を聞いて、トリさんは具体的にどのように進めているのでしょうか。
トリ氏：
まず、カミナシは品質保証が完璧なわけではなく、現在組織を強化しようと多くの試みをしています。例えばQAもその一環で、外部のテスターが手動でテストをしています。この手動テストのおかげで、リリース後の不具合は減っています。最終的な目標はテストを自動化することです。
そのためには、テスターの役割を持った人員をチームに配置し、SDET（Software Development Engineer in Test）など、テストに特化した役割をサービスチーム内に定義し、それらの専門家が設計フェーズから深く関わっていく方針です。
また、先ほど和田さんが指摘された「未来へ投資」は非常に重要だと考えています。例えばスクラムを採用している状況で、チーム全体がただ機能開発やバックログの処理に集中していると、多様なスキルを持つ人々がそれぞれ独立した小集団になってしまいます。フロントエンドのスキルがある人はフロントエンドのタスクを、インフラに詳しい人はインフラ関連のタスクを担当するようになります。
以前に「仕事を通じて学ぶのが最も効率的だ」という話をしたと思いますが、チームとしての全体の生産性が多少下がるとしても、意図的に得意でないタスクを取ること、そしてそれをサポートする文化（例えばモブプログラミングやペアプログラミングなど）が必要です。
「業務外で学べ」という考え方には同意できません。これは倫理的にも問題があり、単に「好きな人は学べばいい」とするのは不適切です。やはり、仕事の中で学ぶことが最も効果的で、長期的に見て非常に良い投資だと考えています。
大谷氏：
なるほど、ありがとうございます。
次のような質問が来ています。「チームを分けない体制において、理想的な運営は各サービスチームが自立して行うべきか、それとも知識を共有しながらチームオーダーのワーキンググループ形式で進めるべきか」とのことですが、和田さんの考えはいかがでしょうか。
和田氏：
理想的な状態としては、各サービスチームが自律的に遂行と学習ができる一方で、かつナレッジシェアリングも両立できる状態です。
専門チームを作るのではなく、専門知識を持つメンバーが各サービスチームに参加する方法で注意すべきは、スキルが孤立したり、チーム間で共有されないという問題があることです。
この問題を解決するためには、チームを作るのではなく横串のコミュニティを作ることが重要です。このコミュニティで、勉強会やプレゼンテーションなどを通じて、スキルや知識を共有・向上する場を設けると、孤立を防ぎつつ組織全体のスキルレベルも向上します。このような横串チームではなく横串コミュニティを形成することが非常に重要だと考えています。
大谷氏：
ありがとうございます、トリさんはいかがでしょうか？
トリ氏：
実際には、カミナシはまだ小さな会社で、いわゆる「超サイロ化」が起きるような組織ではありません。私の前職で働いていた大企業には、和田さんが指摘したような、技術領域に特化した横のコミュニティが存在していました。そこで、新しい知識を学ぶといった活動が一般的でした。
現在、私が会社をマネージしている立場から言うと、重要なのは「社内で勉強会を行う」という行動が、遠くのチームから疑問を投げかけられるような文化を作らないことです。つまり、社内全体で「それは当然の行動だ」と感じられるようなカルチャーを構築する必要があります。
例えば、スプリントの目標を先週達成できなかったチームが、週に2時間も勉強会を開いていると、短期的な視点で批判されがちです。しかし、半年や1年といった長期的なスパンで考えれば、そのような勉強会は有益な投資だと認識できる人々を、社内で増やしていくことが重要になります。
大谷氏：
文化形成が重要なのは確かです。SREやQAがチームに組み込まれた場合、開発のライフサイクルがどう変わるかについては、要求定義からテストまでの各フェーズで、誰がオーナーシップを持つのか、それともチーム全体が品質に対する意識を高めるのか、具体的にはどういった変化があるのでしょうか。
トリ氏：
SREやQAの視点を持つ人がチームにいると、例えばコードレビューで運用やセキュリティの問題を指摘できる人が増えます。これが他のチームメンバーにもポジティブな影響を与えます。ただし、このようなフィードバックを受け入れる文化が必要です。これはコードレビューだけでなく、設計フェーズでも同様です。例えば、デザインの文書でリスクをディスカッションする際にも、コード以外の視点が必要です。
トリ氏：
ライフサイクルについての認識は人それぞれ異なるかもしれませんが、私がチームに求めているのは、サービス提供に必要な機能を内包し、その機能が適切に動作するかを確認する能力です。例えば、コードレビュー時に常駐サービスが適切にシャットダウンできるか、シグターを受け取った際の挙動など、運用フェーズの知識が必要とされる点です。SREのような視点を持つ人がチームにいると、これらの問題点を早い段階で指摘できます。
さらに、他のメンバーがその指摘を受け入れ、理解する環境も求めています。セキュリティの観点からも、例えばSQLインジェクションのリスクなどを指摘できる人がチーム内に必要です。ただ、その指摘を受ける側も、攻撃されていると感じるのではなく、良い方向に進めるための意見として受け取ることが大切です。
このようなコミュニケーションはコードレビューだけでなく、設計フェーズでも重要です。デザインドキュメントでリスクを議論する際にも、プロダクトコード以外の視点が必要となります。それが、良質なプロダクトを提供するための条件だと考えています。
大谷氏：
先ほどのトリさんの発言で、セキュリティが別扱いされているという点がありました。全てをシフトレフト（Shift Left）で統一するのは、特定の技術領域では難しい場合もあると思います。この境界線について、どのように考えていますか？トリさん、お願いします。
トリ氏：
すぐに思いつくのは、「評価が難しい状況」です。企業によっては異なると思いますが、カミナシでは、各チームのマネージャーが半年ごとに自分のチームメンバーを評価します。カミナシのエンジニアリングマネージャーは、ピープルマネージメントと管理業務の両方の役割を担っています。その管理者として、評価を行います。しかし、専門領域が多様であれば、マネージャーが評価をするのが難しい場合もあります。
そのような状況が組織内で混乱や問題を引き起こさないように、うまく組織を構築したいと思っています。会社が拡大していく過程で、評価の問題からSREやQAなどが独立する可能性も考慮しています。彼らはサービスチームと一緒に動いているものの、レポートラインとしては別にする可能性があります。和田さんの視点で、この点についてどう思いますか？
和田氏：
別チームにするのが効果的な場面もあるでしょう。それが、トリさんのLTの最後のページにも関連していると思います。開発組織のサイズが関係しているのかもしれません。
エンジニアリングチームやQAチーム、SREチームを分ける動機の一つは、組織が大きくなりすぎたから、というケースがよくあります。
大きくなった時に、いろんな機能を持つイネーブリングチームを作る方が良いのでは、と思います。その状況やコンテクストは規模も一因ですが、むしろ専門性や人事面、チーム機能の分離などが重要な要素となるでしょう。
大谷氏：
ありがとうございます。次の質問に移ります。「チームの規模が大きくなりすぎて困ることはないですか？もしくはイネーブリングするメンバーを一人配置するのは規模ではない場合、どうしていますか？」とのことですが、いかがでしょうか。
和田氏：
確かに、これは重要な質問です。特にチームサイズと事業規模の関係については考慮が必要です。事業のニーズに応じてチームを組むと、理想的な人数が変わることがあります。例えば、5人から9人のチームで運用している場合、そのチームがさらに拡大する際の対処法は何か、といった問題も出てきます。この点については、実際にトリさんの意見を聞きたいと思っています。
トリ氏：
私が考える理想のチームサイズは、やはり一桁の人数です。前職では時には30人を超える大きなチームになることもありました。そのような状況に対処するため、組織を効率的に分割する努力を常に行うカルチャーも形成しました。しかし、組織を分割すると、プロダクトやサービス全体は大きいままでありながら、多数の小さなチームに分かれてしまい、それがチーム間で望ましくない依存関係を生むことがあります。
前職では、チームサイズを2ピッツァに制限したいと考えていました。それは、ビジネスや組織が拡大するにつれて、組織の分割が避けられないからです。この分割を行う際には、オーナーシップの範囲を明確に区切らなければ、依存関係が強くなり、全体の効率が低下する可能性があります。そのため、マイクロサービスの導入が有用だと考えていました。つまり、システムが大きくなったから分割するのではなく、組織を効率的に分割したいという目的で、明確なオーナーシップの範囲を設定して、各チームが自律的に機能するようにしたかったのです。
結論として、ビジネスが拡大しても、チームを小さく、自律的に運営することが重要だと感じています。前職では、そのためにかなりの努力と工夫が必要でした。
和田氏：
具体的に、どのような努力や工夫を要したのでしょうか。
トリ氏：例えば、AWSのような大規模なサービスでは新サービスが始まるとすぐに膨大なトラフィックが流れることが想定されます。それに対応するためには、初めからスケーラビリティに優れた、一見複雑に見える設計が必要です。この「複雑な設計」とは、システムの各コンポーネントが効率よくスケールできるように工夫されているという意味です。このような設計が可能なのは、AWSの規模と能力による強みです。
しかし、この規模がもたらす困難もあります。例えば、どこかにボトルネックが生じた場面で、システムの一部を分割しなければならない場合、その作業は容易ではありません。何百万リクエストが飛んで来る中で、ダウンタイムなくシステムを分割する必要があるわけです。
また、時には依存関係が複雑になりすぎて分割が難しくなる場合もあります。そのような場合、複数のチームが依存関係を持ったままで並行して作業を進めるしかありません。AWS自体が非常に大きな組織で、どうして全体がうまく動作しているのかを理解している人は少ないかもしれません。そんな中で、システムの分割や統合を行いながら進める必要があります。つまり、我々は常に様々な課題と向き合いながら進んでいるのです。
大谷氏：
ありがとうございます。もう1つだけ質問に答えて、次のテーマに入っていきたいと思います。
質問「QAチームを分けることで一定の品質を担保できるメリットがあるかと思っています。開発チーム内で品質を管理しようとすると、どうしても開発優先となり、品質の優先度が低くなってしまいがちになってしまうと思いますが、それを防止する方法はありますでしょうか？」
この辺りはどうでしょうか？和田さん、お願いします。
和田氏：
品質を下げることで開発スピードが向上するという考えは誤りです。開発チームが品質を担保することもその責務に含まれます。したがって、品質が担保されていないということは、開発が完了していないということです。
この問題は、開発が「終わった」という定義が不明確であるか、または変更されていないことが原因です。QAチームを分けてしまうと、品質保証が「他人事」となってしまいます。「コードは書きましたが、専門的な品質保証はお願いします」という状態になると、最終的な品質保証がチーム全体の責任ではなくなってしまいます。このような状態に陥ると、品質保証が永遠に求められなくなってしまいます。
解決策としては、「開発完了」の定義を見直すことです。
大谷氏：
トリさん、いかがでしょうか？
トリ氏：
チームを区別するモデルの場合、後ろのチームがプロジェクトリリースをブロックする状況が生まれがちです。しかし、全体を見て判断すると、特定の品質を一時的に犠牲にして、次のスプリントで改善するという選択も正当な場合があります。このような判断権がチームから奪われると、それがオーナーシップを損なう一因になるかもしれません。
また、外部品質については、最初から要件を明確にしておく必要があります。そのために内部品質が犠牲にされる場面も出てくるでしょう。これは品質を無視しているわけではなく、エンジニアが顧客に価値を提供することに焦点を当てているからです。その結果、一時的に品質が低下してもリリースを進める選択をすることもあるでしょう。
では、そもそも品質を低下させない対策としてはどのようなものがあるのか。解決策として、例えば3週間のスプリントを終えた後に、クールオフ期間として1週間のスプリントを設けることが有用です。この期間で品質の問題を解決する合意を取るのです。特にスタートアップの環境で有効な手法だと考えています。
大谷氏：
色々な手法があるということですね。ありがとうございました。
次のテーマに移ります。
大谷氏：
品質保証に関して、ソフトウェアエンジニア1人1人がどのような形で関わることが必要になるのか、ちょっとお考えをお聞かせいただければと思っております。トリさんの方からお伺いいたしましょうか。
トリ氏：
確かに、頻繁にクラッシュするアプリは使いたくないですよね。そのため、使いたくなるようなアプリを作ることが、今の時代のソフトウェアエンジニアにとって重要だと考えています。単に指示されたものを作るのではなく、積極的に顧客に価値を提供する姿勢が必要です。このような姿勢を持つと、品質保証も自然と自分の責務になると感じています。もし、そのような価値創造を妨げる組織的な問題があれば、それを変えるための議論も必要だと思います。
大谷氏：
和田さん、いかがでしょうか。
和田氏：
自分ごととしてプロジェクトに関わることが大事だと考えています。この考えが生まれるのは、自分が開発するコードが実際にどう使われ、どう評価されているかに直接つながるからです。この距離が遠くなると、それらが把握できなくなってしまいます。それによって、誰に何の価値を提供しているのかも曖昧になる可能性があります。
そのような状態を避けるためには、価値提供に近い場所で働くことが有用です。自分の行動がどのような結果や影響をもたらすのかを、試行錯誤しながら理解していくことが重要です。そのフィードバックは、例えばシステムログを確認する、カスタマーサポートからの意見を聞く、といった方法で得られます。このような経験から、特に品質に関する設計判断がどのように結果を生むのかを学ぶことが、非常に重要だと考えています。
簡単に言うと、自分がコーディングしている作業がお客様にどう関わるのかをしっかりと体感することが大事ではないでしょうか。
大谷氏：
ありがとうございました。次の質問に移っていきます。
「品質保証の意識を高めるなど個人の意識を変えるというところもありますが、どう学んでもらうのが良いでしょう。またはそうした要素を目標設計に含める場合、どのような目標を設計にするのが良いでしょうか」という質問が来ております。
こちらについてはいかがでしょうか。
トリ氏：
学び方は人それぞれ違うとは思いますが、私自身にとっては、仕事を通じて学ぶ方が最も効率的です。それがモチベーションにもつながっています。
この点に関連して、チーム内で特定領域をリードする人がいることが重要だと考えています。目標設計について話すと、事前に企業が各ジョブレベルでの役割定義があると思います。その定義の中で、ソフトウェアエンジニアとしては品質も重要な責務の一つであるべきです。カミナシでは、そのような要素がエンジニアリングのジョブレベルに含まれています。
また、ジョブレベルの要件を全て満たす人は稀だと思っています。人それぞれ、品質よりもセキュリティに重点を置く場合もあれば、外部品質や機能要件に重点を置いて目標を設定する場合もあります。そのため、ジョブレベルの定義や等級要件には、品質に関する部分もしっかりと言及するべきだと考えています。
和田氏：
学び方にはいくつかの方法がありますが、特に本から学ぶことと、実地での経験から学ぶことが重要だと考えています。また、専門家が存在する場合には、その専門家を活用して学んでいくのも良いと思います。
人事評価については、事業貢献だけを強調する方法も、技術面だけを強調する方法も良くないと感じています。事業貢献だけに焦点を当てた場合、効率的に多くの機能を迅速に開発したエンジニアが高く評価されがちです。しかし、それだと技術面での品質が犠牲になることもあります。逆に、技術面だけで評価すると、その成果が事業にどう貢献しているのかが見落とされがちです。
そのため、評価する際には事業貢献と技術品質の両方を考慮することが重要です。具体的には、見えない部分での品質、たとえばセキュリティやその他の内部品質にも焦点を当て、それを評価に反映させるべきです。
さらに、技術面での評価は、特にビジネス側の人間には難しい場合が多いため、他の社内エンジニアが評価する形が望ましいと考えています。それにより、セキュアなコーディングや品質保証、そしてリファクタリングなど、社内エンジニアが日常的に目にする側面も評価に加えることができます。
質問「QAには敷居の高い領域があると思います。いろいろなチームにQAをイネーブルしていくときにどこから始めると良いとか、入りやすいなどはありますでしょうか」
トリ氏：
私が特に感銘を受けたのは、テスト設計ができるQAエンジニアと一緒にテスト設計をしたときです。そのとき、「なるほど、こんな観点でテストをすると、特定のコードの問題が見つけられるんだ」と気づきました。その時期は、自分でもユニットテストを書いていたんですが、そのようなスキルを持つ人がチームに加わり、新しい観点や方法をペアプログラミングでリードしてくれたとき、非常にインパクトを感じました。
組織を見る立場から言うと、チームの目標に最も直接貢献する部分は何かを特定し、その部分を活性化する方が効果的です。これが最短距離で価値を感じてもらえる方法であり、結果的に「これは役立つ」と感じてもらえるでしょう。その観点から、私もそのようなアプローチを取るべきだと思います。
和田氏：
多くの人が品質保証（QA）をすると仕事が増えると感じがちですが、実は効率的な入り方があります。仕事を減らすこと、つまり、「これだけやれば十分」といった明確なガイダンスが重要です。特に品質保証に慣れていないエンジニアは、テストの範囲に不安を感じることが多いです。その結果、不必要にテストを増やしてしまい、メンテナンスコストが不必要に高まってしまうケースが多いです。
その点で、「ここまでやれば良い」という明確な指針があれば、入りやすさや進みやすさが格段に向上します。短期的にはテスト量が減るかもしれませんが、結局は重要なテストだけに集中できるので、トータルの効率が良くなります。このようなアプローチは、チームに新しく参加する人々にとって非常に響くと感じています。
和田氏：
私が今、セキュリティエンジニアリングのチームに伝えている重要な点が一つあります。専門職である私たちは、よく完璧な状況を目指す傾向があります。しかし、相手がまだ初心者である場合、特にセキュリティのような専門的な領域では、高度すぎるアプローチは逆に心を折ってしまう可能性があります。そのため、私は「1年でこのチームをこのレベルにまで育てよう」といった適切な目標設定を心の中で行い、不必要な情報を投げかけないようにしています。