Pinkoi Tech Talk｜高効率エンジニアチームの秘密を徹底解説
エンジニアリングチームの効率化に悩むあなたへ、PinkoiのTech Talkが具体的な方法と成功事例を紹介。チーム生産性を大幅に向上させるテクニックを学べます。
本記事は AI による翻訳をもとに作成されています。表現が不自然な箇所がありましたら、ぜひコメントでお知らせください。
記事一覧
2021 Pinkoi Tech Career Talk — 高効率エンジニアチームの大解剖
Pinkoi 高効率エンジニアチーム大解剖 Tech Talk シェア
高効率エンジニアチームの大解剖
2021/09/08 19:00 @ Pinkoi x Yourator
My Medium： ZhgChgLi
チームについて
Pinkoiの働き方は複数のSquad（チーム）で構成されています：
Buyer-Squad ：主にバイヤー側の機能を担当
Seller-Squad ：主にセラー向けの機能を担当
Exploring-Squad：主にブラウジングと探索を担当
Ad-Squad：主にプラットフォーム広告を担当
Out-Of-Squad：主にサポート、インフラ、またはプロセス改善を担当
各Squadは各機能のメンバーで構成され、PM、プロダクトデザイナー、データ、フロントエンド、バックエンド、iOS、Androidなどが含まれます。長期的かつ継続的な業務目標はSquadが担当して達成します。
Squad以外にも、チーム横断で運営されるプロジェクトがあり、多くは中短期の業務目標です。発起人やどの役職のメンバーでもProject Ownerを務め、タスク完了後にクローズします。
文末には Pinkoiの文化がチームメンバーの問題解決をどのように支援しているか を記載しています。実際の取り組みに興味がない方は、ページ下部の該当章をご覧ください 。
人員規模と効率の関係
人数規模の成長と作業効率の関係について、10人規模のスタートアップから100人規模のチームまで経験しました（まだ1000人規模は経験していません）が、10人から100人に増えるだけで、多くの面で10倍の違いを強く感じます。
人数が少ないため、コミュニケーションや対応が非常に速く、直接話しに行けばすぐに対応してもらえます。「人と人のつながり」が強いため、互いに同期して協力できます。
しかし、多くの人がいる場合、直接コミュニケーションを取るのは難しいです。協力する人が増えると、全員が話し合うだけで午前中が終わってしまいます。また、協力相手も多いため、タスクは優先順位をつけて処理しなければなりません。緊急でないことはすぐに対応してもらえないので、その間は非同期に待ちつつ他の作業を進める必要があります。
より多くの職務の人が参加することで、仕事の分担がより細かく専門的になり、生産能力や品質が向上し、より速い成果を出せます。
しかし冒頭で述べたように、それに伴い人との協力が増え、協力にはより多くのコミュニケーション時間が必要となります。
まだ小さな問題でも倍以上に拡大されます。例えば、もともと1人が毎日10分かけてレポートを貼る作業は許容範囲ですが、これが20人になると、合計で毎日3時間以上余計にレポート貼りに時間を使うことになります。この場合、レポート貼り作業の最適化や自動化は非常に価値があり、毎日3時間節約できれば、年間250日の稼働日で計算すると750時間も無駄を減らせることになります。
人数規模の拡大に伴い、Appチームを例にすると、より密接に協力する職種は以下の通りです。
Backend — API、Product Designer — UI は言うまでもなく、Pinkoiは国際的な製品なので、機能上のテキストはすべてLocalization Teamに翻訳を依頼しています。また、Data Teamがデータ収集と分析を担当しているため、機能開発に加えてData Teamとイベントトラッキングの設置についても協議が必要です。
Customer Serviceも私たちと頻繁にやり取りをするチームです。ユーザーが時々ショップの評価を通じて注文の問題を直接伝えることもありますが、多くの場合、ユーザーは星1つだけを残して問題があったことを示します。その際には、カスタマーサポートチームに詳細な問い合わせをお願いし、どんな問題があったのか、どう支援できるかを確認します。
これだけ多くの協力関係があるということは、多くのコミュニケーション機会があることを意味します。
しかし、私たちはコミュニケーションを避けたり最小限にしたりしているわけではありません。優秀なエンジニアにとってコミュニケーション能力も非常に重要です。
私たちが行うべきことは、クリエイティブな発想や要件内容、スケジュールの議論など、重要なコミュニケーションに集中することです。繰り返しの確認やあいまいなコミュニケーション、誰かに聞いてまた別の誰かに聞くような状況は避けるべきです。
特にパンデミック時代では、コミュニケーションの時間は貴重であり、より価値のある議論に使うべきです。
「私はあなたが私について思っていると思っていた思い込み」 — この言葉は曖昧なコミュニケーションの結果を完璧に表しています。
仕事の話は抜きにして、日常生活でも認識の違いから誤解が生じることはよくあります。生活ではお互いの暗黙の了解があってこそ気楽に過ごせますが、仕事ではそうはいきません。認識が違うままだと、深く話し合わない限り、成果物の段階で思っていたのと全く違うことに気づくことが多いです。
インターフェースコミュニケーション
ここで導入する考え方は、共通のインターフェースを通じてコミュニケーションを行うことで、これはエンジニアリングのオブジェクト指向設計におけるSOLID原則の依存性逆転の原則（Dependency Inversion Principle）に似ています（理解できなくても問題ありません）。コミュニケーションにも同じ概念を応用できます。
第一歩は、どこが曖昧で毎回確認が必要なコミュニケーションなのか、またはどのようなコミュニケーションがあればより焦点を絞って効果的になるのか、さらにはこの成果物だけで追加のコミュニケーションが不要になることを見つけ出すことです。
問題を見つけた後、「インターフェース」を定義できます。インターフェースとは媒介の意味であり、ドキュメント、プロセス、チェックリスト、ツールなどが該当します。
この「インターフェース」をお互いのコミュニケーションの橋渡しとして使用します。インターフェースは複数存在し、シーンに応じて適切なインターフェースを使います。同じシーンの場合は、まずこのインターフェースを使って初期のコミュニケーションを行います。さらに話し合う必要がある場合は、このインターフェースを基にして問題に深く集中した議論を行います。
Appチームと外部協力関係
以下はAppチームの協力を例に挙げた4つのインターフェースコミュニケーションの例です：
最初はBackendと協力する際、インターフェースの共通認識がないと上図のような状況が発生する可能性があります。
APIの使い方について、単にAPIのレスポンス文字列をAppチームに渡すと曖昧な部分が生じやすいです。例えばdateが登録日なのか誕生日なのか分かりませんし、範囲も広く、多くの項目を確認する必要があります。
このコミュニケーションも繰り返しで、新しいエンドポイントがあるたびに再確認が必要です。
これはまさに典型的な無駄なコミュニケーションの例です。
AppとBackendの間に欠けているのはコミュニケーションのインターフェースです。解決策は多様で、必ずしもツールを使う必要はありません。手作業で管理するドキュメントだけでも構いません。
{:target="_blank"}](/assets/11f6c8568154/1*q_MQ6y3RPKeO7q-zxSGqDg.webp)
この部分は2020年のPinkoi開発者ナイトで共有しました — by Toki
Pinkoi は Python (FastAPI) を使って API コードから自動的にドキュメントを生成しています。PHP では Swagger（以前の会社の方法）を使用しています。利点は、ドキュメントの大枠やデータ形式をコードから自動生成できるため、メンテナンスコストを削減でき、フィールドの説明だけを適切に処理すればよい点です。
p.s. 現在の新しい Python 3 はすべて FastAPI を使用しており、古い部分は順次更新していきます。とりあえず PostMan をコミュニケーションインターフェースとして使用しています。
二つ目はプロダクトデザイナーとの協力で、基本的にはバックエンドと似ていますが、問題はUIスペックの確認やフローの確認に変わります。
色コードやフォントがバラバラだと、アプリも非常に困ります。要件がそうであっても、同じタイトルで色は同じはずなのに色コードが違ったり、同じ場所のUIが統一されていない状況は避けたいです。
Solutionの基本は、まずデザイナーにUIコンポーネントライブラリを整理してもらい、Design System（ガイドライン）を作成し、UIを提供する際にしっかりマークアップすることです。
私たちはCode Base上でDesign System（ガイドライン）に基づき、対応するフォントやカラーを設定し、コンポーネントライブラリに基づいてButtonやViewを作成しています。
テンプレート作成時は、これらの既に作成されたコンポーネントを統一して使用し、UIデザイン稿を直接見て素早く整列できるようにします。
しかし、これは簡単に混乱するため、動的に調整する必要があります。特例を多く含めすぎず、拡張を固執しないことも重要です。
p.s. Pinkoiとプロダクトデザイナーの協力は相互的であり、開発者もより良い方法を提案してプロダクトデザイナーと議論できます。
3つ目はカスタマーサービスとのインターフェースです。ショップのレビューは製品にとって非常に重要ですが、非常に手作業で繰り返しの紹介やコミュニケーションが必要な業務です。
新しい評価を時々手動で確認し、カスタマーサポートの問題があればサポートに転送して対応を依頼する必要があり、とても繰り返しが多く手間がかかります。
この最適解は、ショップの評価を自動的に私たちの作業プラットフォームに同期させることです。既存のサービスをお金で購入するか、私が開発した ZhgChgLi / ZReviewTender（2022年新作）を使う方法があります。
デプロイ方法、チュートリアルおよび技術的な詳細は以下を参照してください： ZReviewTender — 無料オープンソースのAppレビュー監視ロボット
このロボットは私たちのコミュニケーションインターフェースであり、評価を自動的にSlackチャンネルに転送します。みんなが最新の評価情報を素早く受け取り、その上で追跡や議論ができます。
最後の例は、Localization Teamとの作業依存です。新機能の追加や既存翻訳の修正に関わらず、Localization Teamが作業を完了してから私たちが後続の対応を行います。
この自社開発ツールのコストが高すぎるため、直接サードパーティのサービスを利用して依存関係を解消しています。
すべての翻訳とキーはサードパーティツールで管理されており、私たちは事前にキーを設定するだけでそれぞれ独立して作業できます。双方は締め切り前にパッケージ作業を完了すればよく、互いに依存する必要はありません。Localization Teamが翻訳を完了すると、ツールが自動的にgit pullをトリガーして最新のテキストファイルをプロジェクトに更新します。
p.s Pinkoiは非常に早い段階でこのプロセスを導入しており、その当時はOneskyを使用していましたが、近年はより優れたツールが増えているため、他のツールの採用も検討できます。
App Team チーム内の相互協力関係
先ほどは外部について話しましたが、今度は内部について話します。
人が少ない、または一人の開発者がプロジェクトを維持している場合は、やりたいことを自由に行えます。プロジェクトの把握度や理解度も高いため、問題はあまりありません。もちろん、優れたセンスがあれば、一人プロジェクトでもここで述べるすべてのことを実現できます。
しかし、協力するメンバーが増え、同じプロジェクトで作業している場合、それぞれがバラバラに作業すると大惨事になります。
例えばAPIを叩いてここでこうして、あそこでああして、といった作業を繰り返し行い、何度も同じことを作り直して時間を無駄にしたり、何も気にせず適当に作ってリリースしてしまうと、将来の保守や拡張性に大きなコストがかかってしまいます。
チーム内では「インターフェース」というよりも、「共通理解」や「共鳴」と言ったほうが、チーム意識がより感じられます。
最も基本的な定番はコーディングスタイルで、命名の習慣や配置、Delegateの使い方などです。業界でよく使われるrealm / SwiftLintでルールを設定できます。多言語対応の文言はfreshOS / Localizeで整理可能です（もちろん、前述のように第三者ツールで一元管理している場合は不要です）。
二つ目はアプリのアーキテクチャです。MVC、MVVM、VIPER、Clean Architectureのいずれでも構いません。重要なのは、クリーンで統一されていることです。流行を追う必要はなく、統一されていれば十分です。
PinkoiアプリチームはClean Architectureを採用しています。
以前StreetVoiceでは純粋なMVCを使用していましたが、コードはきれいで統一されており、協力もスムーズでした。
そしてUnitTestもあります。人数が多いと、今自分が作ったロジックがいつの間にか壊されるのを避けられません。テストを多く書くことで、より一層の保障が得られます。
最後はドキュメントの部分で、チームの作業フロー、仕様、操作マニュアルに関するもので、メンバーが忘れたときにすぐに参照でき、新人が早く習得できるようにしています。
コードレベルのインターフェース以外にも、協力を効率化するための他のインターフェースがあります。
第一に、要件実装の前にRequest for commentsの段階があります。開発担当者が大まかにこの要件をどう実装するか説明し、他のメンバーが意見や考えを述べることができます。
重複作業を防ぐだけでなく、他の人が拡張する際の使い方や将来的なニーズを考慮するなど、意見を集めることもできます。関係者は見えにくいことも、第三者は客観的に見られますから。
第二に、Code Reviewを徹底し、インターフェースの共通認識が守られているかを確認します。例えば、命名規則、UIレイアウトの方法、Delegateの使い方、Protocol/Classの宣言などです。
また、アーキテクチャが乱用されていないか、急いで雑に書かれていないか、今後の方向性として全面的にSwiftに移行する予定がある場合に、まだObjective-Cのコードが送られていないかなどもチェックします。
主にレビューが中心で、その次に機能が正常に動作しているかのサポートです。
p.s. RFCの目的は作業効率の向上であるため、長すぎて作業の進行を遅らせるべきではありません。単なる作業開始前の議論の場と考えてください。
チーム内のインターフェース共通認識の機能をまとめると、最後に「墜落理論」というマインドセットが良い行動基準になると感じました。
{:target="_blank"}](/assets/11f6c8568154/1*QJ8P_HjSvPdYrUmrqsQZXA.webp)
抜粋元：MBA 智庫
チームに応用すると、もし今日突然全員がいなくなったとしても、現存するコード、プロセス、制度が新しい人でもすぐに対応できるかどうか、ということです。
Recap インターフェースの意味として、チーム内のインターフェースはお互いの共通理解を深めるために使い、チーム外の協力では無駄なコミュニケーションを減らすために使います。インターフェースを通じたコミュニケーションは切り分けられており、要件の議論に集中します。
再度強調するが、「インターフェースコミュニケーション」は特別な専門用語やツール、エンジニアリングのものではなく、単なる概念であり、あらゆる職種や場面での協力に適用できる。単純にドキュメントやプロセスであってもよく、順序としてはまずこれがあってからコミュニケーションが行われる。
ここでは、1回あたり余分にかかるコミュニケーション時間を10分、チーム人数を60人、月に10回発生すると仮定すると、年間で無駄なコミュニケーションに1,200時間を費やしていることになります。
効率向上 — 繰り返し作業の自動化
第二章では、繰り返し作業の自動化が業務効率向上に与える効果について共有したいと思います。例としてiOSを挙げますが、Androidも同様の方法です。
技術的な実装の詳細には触れず、原理上の実現可能性のみを述べる。
私たちが使用しているサービスを整理すると、以下の通りです。これには以下に限定されません：
Slack：コミュニケーションソフト
Fastlane：iOSの自動化スクリプトツール
Github：Gitプロバイダー
Github Action：GithubのCI/CDサービスで、後ほど紹介します。
Firebase：Crashlytics、Event、App Distribution（後で紹介します）、Remote Configなど
Google Apps Script：Google Appsのアドオンスクリプトで、後ほど紹介します。
Bitrise：CI/CDサーバー
Onesky：前述の通り、Localizationのサードパーティーツールです
Testflight：iOSアプリのベータテストプラットフォーム
Google Calendar：Googleカレンダー、後で使用方法を紹介します
Asana：プロジェクト管理ツール
テスト版リリースの問題
最初に挙げたい繰り返しの問題は、アプリの開発段階で他のチームメンバーに先行テストをしてもらいたいとき、従来は直接スマホを借りてビルドしていました。1～2人なら問題ありませんが、チームに20～30人がテストする場合、テスト版のインストールだけでその日は仕事にならず、更新があれば全てやり直しになるという問題があります。
もう一つの方法は TestFlight をテスト版配布の手段として使うことで、これも悪くないと思います。ただし、二つ問題があります。第一に TestFlight は Production 環境と同じで、Debug ではありません。第二に 同時に開発中の複数の要件で、同僚が異なる要件をテストする場合が多いと、TestFlight が混乱し、ビルドのパッケージも頻繁に変更されます。しかし、不可能ではありません。
Pinkoi の解決策は、まず「App Team がテスト版をインストールする」という作業を分解し、Slack Workflow を入力用 UI として利用します。入力が完了すると、Bitrise が Fastlane スクリプトを実行してテスト版の ipa を Firebase App Distribution にパッケージしてアップロードします。
Slack Workflow の活用例はこちらの記事をご参照ください： Slack 打造全自動 WFH 員工健康狀況回報系統
Firebase App Distribution
テストするチームメンバーは、Firebase App Distributionの手順に従って証明書をインストールし、デバイスを登録すれば、そこでテスト版を選んでインストールするか、メールのリンクをクリックして直接インストールできます。
ただし、ここで注意すべきは、iOS Firebase App Distributionは開発用デバイスを使用しており、登録可能なデバイスは最大100台までで、人数ではなくデバイス単位でカウントされます。
したがって、TestFlight（外部テスター1,000人）とのバランスを取る必要があるかもしれません。
しかし、少なくとも前述のSlack WorkFlowのUI入力は採用を検討できます。
もしさらに高度なことを行いたい場合は、Slack Botを開発して、より完全でカスタマイズ可能なフローやフォームを利用できます。
Recap テスト版リリースの自動化効果で最も実感できたのは、全工程をクラウド上で実行できるようにしたことです。Appチームは介入不要で、完全にセルフサービス化しました。
正式版のパッケージングの問題
二つ目もAppチームがよく行う作業で、正式版アプリのビルドと審査提出です。
チームが小さいときは、単一ラインの開発だけで、アプリのバージョン更新の問題はあまりなく、自由にも規則的にも対応できました。
しかし、チームが大きくなり、複数の開発・イテレーションが同時に進むと、上図のような状況に陥ります。前述の「インターフェースコミュニケーション」が十分でないと、それぞれが独自に進めてしまい、Appチームは対応に追われます。Appの更新コストはWebより高く、手続きも複雑なためです。また、頻繁で断続的な更新はユーザーにも大きな負担となります。
最後に管理の問題ですが、固定のプロセスや日付がなければ、各ステップで何をすべきかを最適化するのは難しいです。
了解しました。翻訳したいMarkdown段落を送ってください。
解決策はリリーストレインを開発プロセスに導入することで、核心の考え方はバージョンアップとプロジェクト開発の二つを分離することです。
私たちはスケジュールを固定し、各フェーズで何を行うかも決めました：
毎週月曜日の朝に新バージョンをリリース更新
毎週水曜日にコードフリーズ（機能PRのマージ停止）
毎週木曜日にQA開始
毎週金曜日に正式リリースのパッケージングを実施
実際のスケジュール（QAにかかる時間）、リリース周期（毎週、隔週、毎月）は各社の状況に応じて調整可能です。重要なのは、何をいつ固定して行うかを明確にすることです。
これは海外の開発者が投稿したリリースサイクル調査で、ほとんどが2週間ごとです。
毎週更新＆私たちの複数チームの場合、上図のようになります。
Release Train（リリーストレイン）は名前の通り、駅のようなもので、各バージョンは一つの列車のようなものです。
もし乗り遅れたら次の便を待つことになります、 各Squadチームとプロジェクトは自分たちで乗車時間を選びます
これは優れたコミュニケーションインターフェースであり、皆が共通認識を持ち規則を守れば、秩序立ったバージョン更新が可能です。
より詳しい Release Train の技術的な詳細は以下をご参照ください：
プロセスやスケジュールが確定した後、それぞれの段階で行う作業を最適化できます。
正式版のパッケージ作成は、従来の手動方式では時間と労力がかかります。パッケージ作成、アップロード、審査申請の全工程で約1時間かかり、その間は作業状態を頻繁に切り替える必要があり、他の作業がしにくいです。毎回のパッケージ作成でこのプロセスを繰り返すため、作業効率が非常に悪くなります。
既に日程が確定しているので、ここで直接 Google Calendar を導入し、予定している作業をカレンダーに追加します。時間になると Google Apps Script を使って Bitrise を呼び出し、Fastlane で正式版のビルドと審査提出のスクリプトを実行してすべての作業を完了させます。
Google Calendarと連携するもう一つの利点は、突発的な状況で予定を延期や前倒しにする必要がある場合、直接カレンダー上で日付を変更できることです。
Google Apps Script で Google カレンダーのイベント時間に自動実行するには、現在は自分でトリガーを設定する必要があります。迅速に解決したい場合は、IFTTT を Google カレンダーと Bitrise/Google Apps Script の橋渡しとして利用する方法があります。詳しくはこちらの記事をご参照ください。
p.s.
- 現在 Pinkoi iOS チームは Gitflow ワークフローを採用しています。
- 原則として、この共通認識はすべてのチームが守るべきものであり、これを破る要求は望んでいません（例：特別に水曜日にリリースするなど）。ただし、外部との協力プロジェクトの場合、どうしても難しい場合は柔軟に対応します。あくまでこの共通認識はチーム内のものです。
- HotFix の重大な問題はいつでも更新可能で、Release Train のルールには縛られません。
こちらでは Google App Scripts の活用についても触れています。詳細は以下をご参照ください： 運用 Google Apps Script 轉發 Gmail 信件到 Slack 。
最後の一つは Github Action を使って協力効率（PRレビュー）を向上させることです。
Github Action は Github の CI/CD サービスで、Github のイベントと直接連携できます。トリガーのタイミングは、issue のオープン、プルリクエストのオープンからマージまで多岐にわたります。
Github Action は Github がホストしている Git プロジェクトであれば利用可能で、Public リポジトリには制限がなく、Private リポジトリは毎月2,000分の無料利用枠があります。
ここで2つの機能を紹介します：
（左）はPRレビュー完了後に自動でレビュアー名のラベルが付けられ、PRレビューの状況を素早く把握できます。
（右）は毎日決まった時間にメッセージを整理してSlackチャンネルに送信し、チームメンバーにどのPRがレビュー待ちかを通知します（Pull Remindersの機能を模倣）。
Github Actionにはまだ多くの自動化できる項目があり、皆さんの想像力を活かせます。
オープンソースプロジェクトでよく見かける issue bot のようなもの：
{:target="_blank"} [fastlane](https://github.com/fastlane/fastlane){:target="_blank"}](/assets/11f6c8568154/1*64GaqzcldMHwU-HE4yt3_A.webp)
また、長期間マージされていないPRの自動クローズもGithub Actionで自動化できます。
Recap 自動化で正式版のパッケージング効果をまとめると、既存のツールをそのまま連携して使用しました。自動化に加えて固定プロセスを導入することで、作業効率を倍増させました。
元々は手動でのパッケージ作成時間に加えて、リリースに関するコミュニケーション時間のコストもありましたが、現在はそれがゼロになりました。スケジュール内にリリースを確実に行うだけで、「議論」と「開発」に時間を集中できます。
これら二つの自動化による効果を合計すると、年間で216時間の作業時間を節約できます。
自動化と前述のコミュニケーションインターフェースを組み合わせることで、これらの作業がどれだけ効率化できるか見てみましょう。
今回行ったプロジェクトに加えて、フロー切り替えコストも評価する必要があります。私たちが一定時間作業に集中すると「フロー」状態に入り、この時の思考や生産性はピークに達し、最も効果的な成果を出せます。しかし、無駄なこと（例：余計なコミュニケーションや繰り返し作業）で中断されると、再びフローに戻るまでに時間がかかります。ここでは30分を例としています。
無駄なことで中断される心のフロー切り替えコストも計算に入れるべきで、ここでは1回あたり30分、月に10回発生すると、60人で年間3,600時間も無駄になる。
心の切り替えコスト（3,600時間）＋コミュニケーションインターフェースが悪い場合の余分なコミュニケーション（1,200時間）＋自動化で解決した繰り返し作業（216時間）＝年間で合計5,016時間の損失。
元々無駄にしていた作業時間を節約することで、他のより価値のあることに投入できるため、実際の生産性はさらにX200%向上すると考えられます。
特にチームの規模が大きくなるほど、作業効率への影響も大きくなります。
早く最適化すれば早く恩恵を受けられ、遅く最適化しても割引はありません！！
Recap 高効率なチームの裏側、私たちが主に行ったこと。
No Code/Low Code First 既存のツール連携を優先します（本記事の例のように）。既存ツールがない場合にのみ、自動化のコストと実際の節約効果を評価します。
文化のサポートについて
Pinkoiでは誰もが問題解決のリーダーになれる
問題の解決や物事の変化には、大多数の場合、多くのチームが協力して努力することが必要です。この部分では、会社の文化による支援と励ましが非常に重要で、そうでなければ自分一人で推進するのは非常に大変です。
Pinkoiでは誰もが問題解決のリーダーになれます。リードやPMでなくても問題を解決できます。前述のコミュニケーションインターフェースやツール、自動化プロジェクトの多くは、チームメンバーが問題を発見し、解決策を提案し、みんなで協力して達成したものです。
チーム文化がどのように変革を支援し、問題解決の4つの段階がPinkoiのコアバリューに結びついているか。
第一歩 Grow Beyond Yesterday
良い状態をさらに良くするために、問題を発見したら大小に関わらず報告してください。前述の通り、チームの規模が拡大すると小さな問題も大きな影響を与える可能性があります。
調査を行い、問題を整理し、早期の最適化を避ける（問題の一部は一時的な過渡期である可能性があります）
次は Build Partnerships です
積極的に各方面から意見を収集する
立場を入れ替えて考える（相手の解決策が最善の場合もあるため、よくバランスを取ること）
第三ステップ Impact Beyond Your Role
自身の影響力を発揮する
問題解決の計画を提案する
繰り返し作業の場合は、自動化ソリューションを優先的に活用する
柔軟性と拡張性を維持し、過剰設計を避けること
最後に Dare to Fail！
勇敢に実行する
継続的に追跡し、動的にソリューションを調整する
成功したら、チームと成果を共有し、部門横断のリソース統合を促進する（同じ問題が複数の部門に存在する可能性があるため）
以上はPinkoiの高効率エンジニアチームの秘密共有でした。ありがとうございました。
今すぐPinkoiに参加 »> https://www.pinkoi.com/about/careers
ご質問やご意見がありましたら、こちらからご連絡ください 。
Post MediumからZMediumToMarkdownで変換しました。
本記事は Medium にて初公開されました（こちらからオリジナル版を確認）。ZMediumToMarkdown による自動変換・同期技術を使用しています。