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以外にも、チーム横断で進めるRunプロジェクトがあり、多くは中短期の作業目標です。発起人やどの職種のメンバーでもProject Ownerを担当し、任務完了後にクローズします。
文末には Pinkoi の文化がチームメンバーの問題解決をどのように支えているか があり、具体的な内容に興味がない方はページ下部のこの章をご覧ください 。
人数規模と効率の関係
人数規模の成長と作業効率の関係について、10人規模のスタートアップから100人規模のチームまで経験しました（まだ千人規模は経験していません）が、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の間に欠けているのはコミュニケーションのインターフェースです。解決策は多様で、必ずしもツールを使う必要はありません。手作業で管理するドキュメントだけでも構いません。
この部分は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でのProduct Designerとの協力は双方向であり、Developerもより良い方法を提案してProduct Designerと議論できます。
三つ目はカスタマーサービスとのインターフェースです。ショップの評価は製品にとって非常に重要ですが、非常に手作業で繰り返しの紹介やコミュニケーションが必要な作業です。
新しい評価を時々手動で確認し、カスタマーサポートの問題があればサポートに転送して対応してもらう必要があり、とても繰り返しの多い手作業です。
この最適解は、モールの評価を自動的に私たちの作業プラットフォームに同期させることです。既存のサービスをお金を払って利用するか、私が開発した 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の目的は作業効率を上げることであり、長すぎて作業の進行を妨げるべきではありません。単なる作業開始前の議論の場と考えてください。
チーム内のインターフェース共通認識の機能をまとめると、最後に挙げられた 墜落理論 のマインドセットは良い行動基準になると思います。
摘録元：MBA 智庫
チームに応用すると、もし今日突然全員がいなくなっても、現存のコード、プロセス、制度で新しい人がすぐに業務を習得できるかどうか、ということです。
Recap インターフェースの意味として、チーム内のインターフェースはお互いの共通認識を高めるために使い、チーム外の協力では無駄なコミュニケーションを減らすために使います。インターフェースを使ったコミュニケーションは会話を遮らず、要求の議論に集中します。
改めて強調しますが、「インターフェースコミュニケーション」は特別な専門用語やツール、エンジニアリングのものではありません。これは単なる概念であり、どんな職種や場面の協力にも適用できます。単純にドキュメントやプロセスであってもよく、順序としてはまずこれがあってからコミュニケーションを行います。
ここでは、毎回の余分なコミュニケーション時間を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：前述したように、ローカリゼーションのサードパーティーツールです。
-
Testflight：iOSアプリ内テストプラットフォーム
-
Google Calendar：Googleカレンダー、後ほど使用方法を紹介します
-
Asana：プロジェクト管理ツール
テスト版リリースの問題
最初に挙げる繰り返しの問題は、開発段階で他のチームメンバーに先行テストをしてもらいたいとき、従来は直接スマホを借りてビルドしていました。1～2人なら問題ありませんが、チームが20～30人いると、テスト版のインストールだけで一日が潰れてしまい、更新があるたびに最初からやり直す必要がありました。
もう一つの方法は TestFlight をテスト版配布の手段として使うことです。これも悪くないと思いますが、問題が二つあります。第一に TestFlight は Debug ではなく、本番環境に相当することです。第二に 同時に開発中の複数の要件を同僚がそれぞれテストする場合、TestFlight は混乱しやすく、ビルドのパッケージも頻繁に変更されます。しかし、不可能というわけではありません。
Pinkoi の解決策は、まず「App Team がテスト版をインストールする」という作業を分解し、Slack WorkFlow を入力用 UI として利用します。入力が完了すると Bitrise が Fastlane スクリプトを実行し、テスト版の ipa を Firebase App Distribution にアップロードします。
Slack Workflow の活用例については、こちらの記事をご参照ください：Slack が実現する完全自動のリモートワーク社員健康報告システム
Firebase App Distribution
テストするメンバーは、Firebase App Distributionの手順に従って証明書をインストールし、デバイスを登録すれば、そこでテスト版を選んでインストールできます。または、メールのリンクをクリックして直接インストールすることも可能です。
ここで注意すべき点は、iOS Firebase App Distribution は開発用デバイスを使用しており、登録可能なデバイスの上限が100台までで、ユーザーではなくデバイス単位でカウントされることです。
だから、TestFlight（外部テスト1,000人まで）とのバランスを考慮する必要があるかもしれません。
しかし、少なくとも前述の Slack WorkFlow の UI 入力は採用を検討できます。
もしさらに進んだことをするなら、Slack Botを開発して、より完全でカスタマイズされたプロセスやフォームを利用できます。
Recap テスト版リリースの自動化効果で最も実感したのは、全工程をクラウド上で実行できるようにしたことで、Appチームが介入せずに完全セルフサービス化できた点です。
正式版のパッケージングの問題
2つ目もAppチームがよく行う作業で、アプリのパッケージングと正式版の審査提出です。
チームが小さいときは、単一の開発ラインだけで、アプリのバージョン更新に問題はほとんどなく、とても自由かつ規則的に行えました。
しかし、チームが大きくなり、複数の開発・イテレーションのニーズが同時にあると、上図のような状況に直面します。前述の「インターフェースコミュニケーション」がうまくできていないと、それぞれが勝手に進めてしまい、Appチームは対応に追われます。Appの更新コストはウェブより高く、プロセスも複雑であるためです。一方で、頻繁で散発的な更新はユーザーにも大きな混乱をもたらします。
最後に管理の問題ですが、固定のプロセスや日付がなければ、各ステップで何をすべきかを最適化するのは難しいです。
了解しました。翻訳するMarkdown段落の内容をお送りください。
解決策はリリーストレインを開発プロセスに導入することであり、核心となる考え方はバージョンアップとプロジェクト開発を分離することです。
私たちはスケジュールを固定し、各段階で何を行うかも決めました：
-
毎週月曜日の朝に新バージョンをリリースする
-
毎週水曜日にCode Freeze（これ以上Feature PRをマージしない）
-
毎週木曜日にQAを開始する
-
毎週金曜日に正式リリースを行う
実際のスケジュール（QAにかかる時間）、リリース周期（毎週、隔週、毎月）は各社の状況に応じて調整可能です。重要なのは、何をいつ固定して行うかを明確にすることです。
申し訳ありませんが、ご提供いただいた内容が不明瞭なため、翻訳を行うことができません。翻訳したい具体的なMarkdownテキストを提供してください。
Gergely Orosz @ Twitter は次のように述べています：
モバイルエンジニアの皆さん、どのくらいの頻度でアプリをリリースしていますか？（ビルドを作成してApp Storeに公開する頻度はどれくらいですか？）
モバイルアプリの大規模展開に含めるためのデータ収集。
Uberでは、リリースプロセスを開始するために毎週ビルドを作成していました（社内利用 → アプリストア）。
2021-03-01 15:57:38 にツイートされました。
申し訳ありませんが、ご提供いただいた内容が不明瞭なため、翻訳を行うことができません。翻訳したい具体的なMarkdownテキストを提供してください。
これは海外のTwitterユーザーが投稿したリリース周期の調査で、ほとんどが2週間に1回です。
毎週更新と複数チームの例では、上記の図のようになります。
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 Apps Script の活用についても触れています。詳細は以下をご参照ください： 運用 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 のようなもの：
また、長期間マージされていないプルリクエストを自動でクローズすることも、Github Actionを使って自動化できます。
Recap 自動化で正式版のパッケージング効果をまとめると、既存のツールをそのまま連携して使用しています。自動化に加えて固定プロセスを導入することで、作業効率を倍増させています。
元々は手動でのパッケージ作成時間に加え、リリースに関する追加のコミュニケーション時間のコストもありましたが、現在はそれがゼロになりました。スケジュール内にリリース準備完了さえすれば、時間を「議論」と「開発」に集中できます。
これら二つの自動化による効果を合計すると、年間で216時間の作業時間を節約できます。
自動化と前述のコミュニケーションインターフェースを組み合わせることで、これらの作業がどれだけ効率化できるか見てみましょう。
除了剛做的項目，我們還需要多評估 心流切換成本 ，當我們持續投入工作一段時間後就會進入「心流」狀態，此時的思緒、生產力都達到巔峰，能提供做好最有效的產出；但如果被無謂的事(EX: 多餘的溝通、重複性工作)打斷，要重新回到心流，又會再需要一段時間，這邊以 30 分鐘為例。
無駄なことで中断されるフローの切り替えコストも計算に入れるべきです。ここでは1回あたり30分、月に10回発生するとして、60人で年間3,600時間も無駄になります。
フロー切り替えコスト（3,600時間）＋コミュニケーションインターフェースが悪い場合の余分なコミュニケーション（1,200時間）＋自動化で解決した繰り返し作業（216時間）＝年間合計5,016時間の損失。
元々無駄にしていた作業時間を節約することで、他のより価値のあることに投入できるため、実際の生産性はさらに約200%向上すると考えられます。
特にチームの規模が拡大するにつれて、作業効率への影響も大きくなります。
早く最適化すれば早く恩恵を受けられ、遅く最適化すると割引はありません！！
Recap 高効率なチームの裏側、私たちが主に行ったこと。
No Code/Low Code First 既存のツール連携を優先的に選びます（本記事の例のように）。既存ツールが使えない場合にのみ、自動化にかかるコストと実際に節約できる利益を評価します。
文化のサポートについて
Pinkoiでは誰でも問題解決のリーダーになれる
問題の解決や物事の変化には、ほとんどの場合、多くのチームが協力して努力することが必要です。この点で、会社の文化による支援と励ましが非常に重要です。そうでなければ、自分一人で推進するのは非常に大変です。
Pinkoiでは誰もが問題解決のリーダーになれます。LeadやPMでなくても問題を解決できます。前述のコミュニケーションインターフェースやツール、自動化プロジェクトの多くは、チームメンバーが問題を見つけ、解決策を提案し、皆で協力して達成したものです。
チーム文化がどのように変化を促進し、問題解決の4つの段階がPinkoiのコアバリューに結びついているかについて。
第一歩 昨日を超える成長
-
良くても、さらに良くする。問題を見つけたら、規模に関わらず対応する。前述の通り、チーム規模が拡大すると、小さな問題も大きな影響を及ぼす。
-
調査・問題の整理を行い、急いだ最適化は避ける（問題の一部は一時的な過渡期の場合もある）
次に Build Partnerships です
-
積極的に各方面から意見を収集する
-
立場を変えて考える（相手の解決策が最善の場合もあるため、よく判断すること）
ステップ3 自分の役割を超えた影響力
-
自身の影響力を発揮する
-
問題解決の計画を提案する
-
繰り返し作業に関係する場合は、自動化ソリューションを優先的に活用する
-
柔軟性と拡張性を保ち、過剰設計を避けること
最後は Dare to Fail！
-
勇敢に実践する
-
継続的に追跡し、動的にソリューションを調整する
-
成功したら、チームと成果を共有し、部門横断的なリソース統合を促進する（同じ問題が複数の部門に存在する可能性があるため）
以上はPinkoiの高効率エンジニアチームの秘密共有でした。ありがとうございました。
すぐにPinkoiに参加する >>> https://www.pinkoi.com/about/careers
Post MediumからZMediumToMarkdownを使って変換しました。
コメント