CTO, CTOaaS, Founder: 25 years coding, 18 years hands-on leading, building smart tech products and rockstar teams.
The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.
Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.
写真はDylan GillisによるUnsplashより
10年以上前、私は起業家だけが起業家精神を教えるポーランドのユニークな教育機関であるASBIROで、他でもないAndrzej Blikle氏による総合的品質管理(TQM)コースを受講する機会がありました。
それ以来、私は特にスタートアップの世界で、さまざまな TQM 手法をチームと共にテストし、改良してきました。ここでは、チーム内のさまざまな実際のシナリオで効果があることが証明されている毎週の Kaizen スタイルのセッションを中心に、私が実践した観察とアイデアの一部を紹介します。
アンジェイ・ブリクレ氏は、品質管理の分野での功績と、ポーランドの象徴的で魅力的な「 A.ブリクレドーナツ」(pączki!)の創作で有名なブリクレ家の菓子会社のリーダーとしてよく知られている、著名なポーランドの起業家です。彼は、会社の伝統を守りながら会社を拡大し、現代的で品質重視の組織へと変貌させました。
総合的品質管理 (TQM) は、継続的な改善と長期的な成功に焦点を当てた、組織全体の包括的なアプローチであり、組織の全メンバーが関与します。一方、カイゼンは、TQM 内の特定の手法であり、プロセスを強化して非効率性を排除するために、毎日少しずつ改善を行うことを重視しています。重要なポイントは、組織が繁栄するためには、その全メンバー (経営陣を含む) の貢献により継続的に進化する必要があるということです。
アイデアが次々と湧き、期限が迫るテクノロジー系スタートアップの世界は、ペースが速く、全体像を見失いがちです。コーディングや設計などの日々の業務に追われていると、大規模プロジェクトの管理は手に負えないと感じるかもしれません。製品チームの数は数十に及ぶことも珍しくないため、製品の品質と効率的なソフトウェア制作プロセスの両方を維持するための方法を確立しておくことが不可欠です。
私が毎週のカイゼン形式の会議をすべてのチームに導入したのは、約 10 年前のことでした。私は、シンプルでありながらインパクトのあるものを求めていました。これらの会議は、私たちのプロセス改善の取り組みの礎となりました。なぜでしょうか。それは、一貫したフィードバックが可能になり、放置すると雪だるま式に大きくなる可能性のある問題をチーム メンバーが提起できるプラットフォームが提供されるためです。
やり方はこうです。毎週、製品チームと技術チームの全メンバーを集めます。サイロ化はしません。通常、週の最終日が最もうまくいきます。開発者、デザイナー、製品マネージャーなど、全員です。目標は、不満をぶちまけ、不満を共有し、進歩を妨げる障害を指摘する場を提供することです。そして、これは「上司について不満を言い合おう」というセッションではありません。私たちは、現実的で実行可能な問題に焦点を当てます。
「今週、どんなことに不満がありますか?」のような簡単な質問は、あらゆる種類の洞察への扉を開きます。これは会話を始める最良の方法です。なぜなら、プロセス、コミュニケーションの問題、あるいはオフィスにコーヒーがないといった些細なことであっても、誰もが懸念を表明できるからです。私は文字通り毎週、次のように人々に思い出させていました。「金曜日に改善セッションがあります。皆さん、不満を持ってきてください!」
最初に改善案を尋ねてみてはいかがでしょうか。ここで少し直感に反することになります。改善案の提案を求めると、解決策よりも疑問符が多くなることがよくあります。私の経験では、この質問から得られるアイデアは、実際の問題というよりも「あったらいいな」というアイデアになる傾向があります。チームで数か月このようなセッションを行い、全員が同じ考えを持つようになってから、初めてこの質問を投げかけることができます。その頃には、人々はすでに自分たちで改善案を思いついています。尋ねる必要すらありません。
最初は、率直な議論に参加するよう人々を説得するのは難しいかもしれません。特に、経営陣に対して問題を公然と指摘することが気まずいと感じられる文化ではなおさらです。重要なのは、これらの議論は個人を批判することではなく、プロセスを改善することであると強調することです。解決策に焦点を当てることで、非難ではなく建設的なフィードバックの雰囲気になります。これらのセッションの背後にある「理由」を最初から明確に説明する必要があります。
問題について話し合ったら、次の会議までに解決すべきタスクを割り当てます。開発者がツールに苦労している場合は、それを解決するためのリソースを確保します。チーム内でのコミュニケーションが不足している場合は、新しい戦略に取り組みます。重要なのは、会議をアクション指向にし、解決策を明確にフォローアップすることです。
当初は、オープンに情報を共有するよう説得するのは大変でしたが、今ではそれが私たちの文化の不可欠な部分になっています。こうしたミーティングは、チームが一息つき、懸念を表明し、そして最も重要なことに、問題とその解決策を自らの責任で解決する機会となります。このシンプルでありながら効果的なアプローチは、生産性だけでなく、チームの士気と結束にも長期的な利益をもたらしました。
では、なぜ私は改善会議を信頼しているのでしょうか。それは、それが勢いを維持するからです。締め切りと絶え間ないプレッシャーに満ちた世界では、全体像を見失いがちです。こうした小さな定期的な調整により、私たちは足並みを揃え、問題が障害になる前に解決し、常に改善し続けることができます。そして、正直に言うと、時々少し不満を言うことは、つながりを保ち、物事を前進させるのに最適な方法です。
こうしたミーティングの予想外の利点の 1 つは、時間の経過とともに技術的負債に対する認識を高め、対処するのに役立つことです。定期的なフィードバックを奨励し、問題が発生するたびに対処することで、蓄積された技術的負債をより小さく、より管理しやすい部分に分解して解決できます。
CTO として、私はカイゼン ミーティングが各チーム メンバーの真のオーナーシップを育む最良の方法であることに気付きました。ビジネス、製品、生産プロセスに直接影響を与えていると感じれば、誰もが課題に直面しており、常に改善の余地があることに気づき始めます。これらのミーティングは明確なメッセージを伝えます。チームとして、私たちは毎週仕事の苦痛を軽減する力を持っているのです。
チームの生産プロセスを改善するために、どのような手順を踏んでいますか? あなたのアプローチをぜひお聞かせください。