この記事ではアリババの第一線で活躍する技術者が、一人前の技術者になるまでの経験と考えについて語っています。
著者：アリババ Guo Yanming
ビジネスを行う際には、チームで仕事をする必要があります。チームの中では、他のチームメンバーと密接に協力して問題を定義し、ビジネスの目標と成功を達成し、技術的なスキルを高めていく必要があります。同時に、ビジネスの研究開発に従事するフロントエンドエンジニアが増えていることを考えると、チームワークとビジネスへの理解は、新しく進化する技術空間において、エンジニアに必要な2つのスキルと言えます。ビジネス開発に関わるキャリアを目指すのであれば、ビジネスを理解し、これらのスキルを持っていることは非常に重要です。
今日は、アリババの技術エキスパートの一人として、私がアリババで働いていたときの経験をもとに、どのようにして本格的な技術エキスパートになったのかをお話しします。
ステージ1 生き残るための戦い
アリババのビジネスオペレーションの最前線でサービスを提供するフロントエンドエンジニアの一人として、私はすぐに、ビジネスサポートの仕事がKPIの約50％から60％を占めることを身をもって知りました。この業界では一般的に、フロントエンドがビジネス全体のリソースのボトルネックになることが多いのです。フロントエンドのエンジニアであれば、緊急時の対応をオンラインで行うことが多く、疲弊した経験があるのではないでしょうか。
私は入社1年目に主にTmall Globalを担当しましたが、そこにはプラットフォームと自営の事業部が混在していました。当時、Tmallの輸入ビジネスはまだ成長の初期段階で、競争が激しかったです。年に2回の大きな変化に対応しながら、日常業務をなんとかこなしていくということがよくありました。それと同時に、毎年5つの大きなプロモーションといくつかの小さなプロモーションをサポートしなければなりませんでした。
私にとって、最も忙しい時期のひとつが2017年のDouble 11だったと記憶しています。自営事業やプラットフォーム事業の大幅なアップグレードや、Double 11のさまざまなニーズに直面し、立ち止まって考える時間はありませんでした。しかし、その時を境に、要件管理の重要性、時間管理の重要性、オンライントラブルの回避方法などを深く理解することができました。ここでは、私自身の経験やチームの経験をもとに、この状態を打開する方法をお話したいと思います。
要件管理
まず、要求を完全に満たすことはできないので、どうしてもトレードオフの関係になります。したがって、仕事の価値を最大化するためには、常に中核となるビジネス要件にマンパワーとエネルギーを集中させる必要があります。ですから、もしあなたのチームが分散した多種多様な要求に圧倒されているのであれば、それらの要求を管理するために適切な手段を講じる必要があるでしょう。
隔週のスケジューリングミーティング
例えば、上司、PD、同僚、開発担当者が集まるミーティングを2週間に1回程度開催し、過去2週間のプロジェクトの進捗状況を確認し、次に対応すべき要件を明確にします。
これにより、異なる要件の優先順位を決定し、どのリソースを開発に割り当てるべきか、どのようなトレードオフを行うべきかを決定し、より多くのエネルギーとマンパワーを最も重要なビジネス事項に集中させることができるようになります。
例えば、ビジネスチームが信頼できる、あるいは大きな計画を持っている場合、一般的には年度の目標を段階的に分解し、今年度の最も重要なビジネス上の取り組みを決定します。そして、この全体的なキャンペーン戦略に基づいて、技術担当者が手配をします。このように、ビジネスチームと技術チームは、明確で統一された計画と目標を持つことになります。例えば、アリババでは、様々な重要な取り組みに注力しつつ、日常的な要求にも対応するという、かなり典型的な状況になっています。
1センテンスの要求を却下する方法
本来、コアな要求や優先順位の80％は、隔週で行われる要求スケジューリング会議で決定することができます。しかし、業務担当者やPDは、会議で考慮されなかったことを要求してくることがよくあります。そのような要求は、1つか2つの漠然とした文章で述べられることが多くあります。例えば、「この製品はひどい。1対1のフォーマットを1対2に変えてほしい」とか、「このアイコンやマーケティングスローガンのフォントが気に入らない。変えたほうがいい。」などです。
Coolshell氏の書いたギークコラムやBarret Lee氏のブログでは、このような "1センテンス要求 "を拒否する方法が語られています。彼らのアプローチを見て、また私自身の経験も踏まえて、このような要求を拒否するために使える3つの方法についてお話したいと思います。
なぜ？と問い続ける
1センテンスの要求を受け取ったら、その要求の目的と価値を問います。期待される利益を尋ね、その利益を得るためになぜこれをしなければならないのかを尋ねます。これらの質問をビジネスチームに直接する必要はありません。むしろ、自分自身に問いかける必要があるのではないでしょうか。ビジネスチームの目的と、この要求を解決するためのアプローチが一致しているかどうかを問う必要があります。もし、実装方法が不合理であったり、最適なプランではない場合、その要件は除外することができると分かります。
代替案の提案
理由を聞いた後は、不要な1センテンスの要求を除外することができます。それでも、中には価値のある要求もあるかもしれません。しかし、ビジネスチームが挙げたアイデアは、効果的なソリューションではないかもしれませんし、高額なコストがかかるかもしれません。この場合、代替案を考え、既存のソリューションや、よりコスト効率の高いソリューションを使って、ビジネスチームのニーズを満たすようにする必要があります。このように、本来の要求を満足させるソリューションを提供しつつ、非現実的な要求を間接的に拒否する手段を持つことが重要です。
直接ノーと言えない場合
どうしても断れない場合は、要求は妥当だが、今はそれに対応する時間がないことを認めることができます。重要なのは、ビジネスチームに直接断ることはできないということです。これは、将来的にビジネスチームと一緒に仕事をするのが難しくなるからです。要件は受け入れるが、もう少し時間が必要であるとか、途中までしか対応できないと言うことはできます。あるいは、ビジネスチームのスケジュールに合わせてこの要求に対処しなければならない場合、プロジェクト開始後のパフォーマンスや品質を確保できないと言うこともできます。これにより、ビジネスチームは必要なトレードオフを検討せざるを得なくなります。
開発効率と品質の向上
もちろん、要求管理は技術者の仕事の一部に過ぎません。開発効率や品質を向上させることも必要なことです。質の低い繰り返し作業を極力減らすべきだということは、誰もが深く理解していることだと思います。例えば、統一された技術システムを開発し、再利用可能なコンポーネントや生産性向上ツールをカプセル化することで、自分やチームの生産性を向上させることができます。忙しくても、これらの作業を考え、実行しなければなりません。それを怠ると、将来的に作業量が増えるだけです。
ビジネスチームに貢献するメンバーとして、私は、あなたの業界やグループにある既存の技術的ソリューションを、あなたのビジネスニーズに合わせて迅速にカスタマイズすることに集中することをお勧めします。例えば、国際的なマーケティングシナリオのニーズを満たすために、ShuwenチームのMagic製品の助けを借りて、国際的なプロジェクトのために独自のMagic Stoneモジュールをカスタマイズしました。現在では、主要なプロモーションにおける同様のモジュール要求に対して、良いソリューションを提供しています。
では何が足りないのか？品質にもこだわらなければなりません。オンラインの問題を引き起こすことが多い製品やコードを特定し、その解決策を再設計するために時間をかける必要があります。海外勤務中は、週末に行うことが多いですね。この再構築により、問題を完全に解決することができるので、真夜中にこれらの問題を解決するための電話が殺到することはありません。残りの方法とテクニックは、開発プロセス中の品質保証と必要なオンライン監視を強化することです。
発売後のパフォーマンスに注目し、迅速に結果をまとめる
私たちはしばしば、プロジェクトがテストのためにオンラインになった時点で自分たちの仕事が終わると考えがちですが、これは悪い習慣です。これでは、パートナーの目にはプロジェクトのリソースとしてしか映らず、問題解決にも消極的になってしまいます。本当は、立ち上げた後のビジネスデータや結果を丁寧に分析し、その結果をまとめるべきなのです。実際、これを正確に行うことで、次のようなメリットが得られます。
ビジネスへの理解が深まる
ビジネスデータに注意を払いながら、重要なビジネスの視点を持ち、ある機能の価値が期待を満たしているかどうかを判断することができるようになります。ある機能が期待にそぐわない場合、ビジネスチームと協力してデータファネルを分析し、問題点を見つけ出すことができます。このように、すべての作業の結果は、単発のタスクになるのではなく、それ以上のものになるのです。
結果を要約することも助けになる
結果をまとめることで、プロジェクトでの自分の欠点を確認したり、プロジェクトの進行を妨げる問題点を発見したり、今後の改善策を学ぶことができます。また、その後のプロジェクトのアップグレード効率や品質の向上にもつながります。たとえば、要求を理解できなかったために手直しが必要だったのか。あるいは、チームメンバー間のコミュニケーションがうまくいかなかったり、コラボレーションがうまくいかなかったりして、プロジェクトがうまくいかなかったのか。そして最後に、自分が設計したソリューションは合理的で考え抜かれたものだったか。これらの質問を自問自答することで、次回はより良いソリューションを提供することができます。
データを見て結果をまとめれば、どのような要求が信頼できるのか、どのようなビジネスパーソンが信頼できるのかがわかります。また、いつもリソースを要求してくるが、立ち上げた後に良い結果を出さないビジネスパーソンを特定することができるので、次に何かを要求されたときには、もう少し疑ってかかることができます。
感想
以上は、私が経験したビジネス要件の急増への対応の一部です。一般的に、KPIの大半を占めるのはビジネスサポート業務ですが、そのようなビジネス要件に対応することに没頭することはできません。そのためには、自分の経験を振り返り、より適切な業務支援を行うための時間を確保する必要があります。
ステージ2：発展への道を探る
もちろん、ビジネスチームを積極的にサポートするだけでは十分ではありません。もちろん、ビジネスチームを積極的にサポートするだけでは不十分で、同時に個人的にも成長する方法を見つける必要があります。
この段階では、ビジネスへのサポートや自分の仕事を振り返る時間はあっても、自分自身を成長させるための適切な道筋を見出すことが困難になります。特に、KPIを策定して設定するたびに、ビジネスサポートの目標以外は、何をしていいのかわからなくなってしまうでしょう。私が思うに、ビジネスチームのフロントエンドでは、本当は2つの視点で物事を考えてみるべきだと思います。
ビジネス・エンパワーメントの視点
ビジネスエンパワーメントでは、ビジネスプランに合った技術プランやソリューションを策定することが求められます。そのため、年度初めから、上司やビジネスPD、ビジネスチームと話し合い、その年度のビジネスKPIにおける重点項目や想定される計画・実行アプローチを知ることをお勧めします。さらに、ビジネスチームがKPIを達成するために自分ができることを、自分自身の状況とチームの状況に基づいて考えます。実際、これは単純な作業ではありません。私もまだまだ試行錯誤しています。私がお伝えしたいのは、2つのポイントです。
本質をつかみ、全体像を考える
多くの場合、というよりほとんどの場合、個別の困難やビジネス上の要求を提示されることがあります。しかし、それぞれの課題を単独で考えるのではなく、全体的に考えていく必要があります。例えば、SEOページはパフォーマンスに非常に敏感です。ビジネスの担当者からは、「うちのSEOには問題があるから直してほしい」とよく言われます。しかし、その問題点を1つ1つ解決していっても、ビジネスには何のメリットもないかもしれませんし、自分たちのスキルアップにもつながりません。むしろ、全体を俯瞰して考えてみると、SEOページの最適化の目的は、SEOページのインデックスやランキングを向上させることにあることがわかるはずです。
SEOページのインデックスとランキングを改善するためには、フロントエンドのパフォーマンス最適化以上のことができます。例えば、キーワードとロングテールワードを最適化したり、GoogleのAMP技術を使ってSEOページを改善したり、ページのクロール時間を短縮したり、クロール率を向上させたりすることができます。このように、特定のポイントから、よりハイレベルなソリューションへと拡張することができます。これにより、より効果的で包括的なソリューションを策定し、ビジネスを強化することが可能になります。
困難を解決するために長期的な計画を立てる
多くの場合、目の前のKPIを達成するだけでは十分ではありません。ビジネスチームの長期的な考え方や計画の可能性を理解する必要があります。例えば、私たちは現在、アリババの非常に重要なプロジェクトに取り組んでいます。プロジェクトの納期は非常にタイトです。フロントエンドは300人日分の作業をわずか48営業日で完了させる必要があり、これがプロジェクトのリスクとなっています。ビジネスとテクノロジーの担当者の最優先事項は、プロジェクトを予定通りに立ち上げることです。常識的に考えれば、計画の目的は、いかにして時間通りに立ち上げるかということでなければなりません。将来的には、このモデルに沿って他のサイトにもこのプロジェクトを実施する必要が出てくるかもしれません。そのためには、技術的なソリューションが再現可能であることも必要です。複製可能なソリューションがあれば、新しいサイトでのフロントエンドの作業が軽減され、モジュール方式で海外のサイトにプロジェクトを迅速に立ち上げることができます。これは、私たちが考慮しなければならない第二の次元です。考えられるすべての近・長期的な問題を検討することで、私たちが実際にしなければならないことは、国際的なサイトのための完全なフロントエンドソリューションを作ることだとわかります。このことから、私たちは常に問題を探求し、定義し、適切な解決策を見つけなければならないことがわかります。このようにして、ビジネスを強化するためのより良い方法を見つけることができるのです。
技術的経験の視点
技術経験の視点は、フロントエンド担当者にとって身近な視点です。ビジネスチームの中で、フロントエンド担当者ができることは、R&Dの効率化、パフォーマンス体験の最適化、新技術のテストと実装、技術と端末の統合など、多岐にわたります。この方向性を追求したいのであれば、いくつか注力すべき点があると思います。
再開発をしない
製品ベースのソリューションやツール、フレームワークを開発する必要があるときは、まず自社内や業界内で調査を行い、同僚や仲間が同じような問題をどのように解決したかを確認するのがベストです。再開発をしなくて済むように、すでに他の人が行った仕事を利用してイノベーションを起こしたり、共同建設に参加したりするようにしましょう。会社のフロントエンド委員会の計画やダイナミクスにもっと注意を払い、社内外で共有されている情報にもっと注意を払うことをお勧めします。そして、興味のあるプロジェクトを見つけたり、似たような問題やシナリオに取り組んだりしたときには、共同構築や共有に参加してみましょう。
ソリューションの深さと広さを理解する
フロントエンドのパフォーマンス最適化では、リソースの圧縮やコンボリクエストなどの一般的な操作についてはあまり語られません。その代わりに、Tmallの以前のWebベースのソリューションのように、クライアントと高度に統合された深い最適化に注目します。これは、ディープソリューションの一例です。以前、私が国際的なパフォーマンス最適化のためのGlobal Liteソリューションに取り組んでいたとき、私は包括的な視点で計画と思考を行っていました。これは「広義のソリューション」の一例です。このように、ソリューションの深さと広さは、その効果を左右します。私は、ソリューションの深さと広さを向上させるために、いくつかのアイデアを持っています。まず、もう一歩踏み込んでみましょう。上流と下流のチームやパートナーの視点で考え、他のチームや役割と協力して、可能なソリューションを検討します。次に、最終的に何を達成したいのかを考えます。そして、その解決策を現状でどのように実行するかを考えます。
ソリューションのROIに焦点を当てる
ソリューションの完全なコストとベネフィットを考えてみましょう。これにより、その価値を評価する方法が得られます。コストとベネフィットを評価する際、コストには2つの見方があります。1つ目は、通常のコストの考え方で、作業日数や支出した資金などが含まれます。もう1つは、経済的機会費用を考える方法です。これは、あることをすることで、他のことをするのと比較して、放棄される価値のことです。ベネフィットは、生産性がどれだけ向上したか、ビジネスデータがどれだけ改善されたか、パフォーマンスがどれだけ向上したかなどです。ベネフィットを強調するには、比較法を用いることをお勧めします。
何を持ち込み、何を配るべきかを知る
さらなるイノベーションやカスタマイズを推進するために、既存のソリューションや機能を取り入れたいのであれば、プロジェクトの結果やソリューションを提供し、他の人がそれを基に構築できるようにする必要があります。例えば、このソリューションを社内の他の業界や事業部にも拡大し、同様の問題を解決できるようにすることができます。そのためには、自分の作品をオープンソースにしたり、特許を申請したり、社内外での情報共有にもっと参加したりするといいでしょう。
感想
ビジネスエンパワーメントと技術的な計画は、継続的な調査と実践が必要です。私は、上司やチームの経験豊富な同僚ともっとコミュニケーションをとることをお勧めします。一般的に、彼らは経験豊富で、あなたが物事をよりよく考えるためのアドバイスをしてくれます。実際、このようなやり取りで目が覚めることもあります。
ステージ3：アプローチを練る
新しい方向性や機会を見つけたとき、すでに大まかなアイデアや計画がある場合があります。そのような時は、すぐにでもその道を歩み始めたいと思うかもしれません。しかし、そうすると道を踏み外してしまい、結果的に満足のいく結果が得られないというリスクがあります。ここでは、問題を正確かつ完全に、そして高度に理解するための理論や方法が必要になります。では、そのための方法や手順はあるのでしょうか？その答えは「イエス」です。その答えは、構造化された思考と行動の方法を開発することにあります。
思考の構造化
構造化思考の最初の側面は、コアとなる目的を設定することです。問題や課題に直面したとき、私たちは核となる目的を設定する必要があります。例えば、開発中のプロジェクトのコンパイル速度が遅い場合、プロジェクトのコンパイル問題を解決することが目的となります。もちろん、それだけではなく、開発プロセス全体の効率化を図ることも考えられます。ここでは、「開発プロセス全体の効率化」を目的とします。つまり、仕事の価値を高めたり、解決すべき問題の範囲を広げたりするために、もう一段階上のレベルを目指すのです。
もうひとつは、大まかな目的を分解することです。ここでは、大きくて複雑な目的を、さまざまなシナリオや時間、構造、程度などの論理的な順序に基づいて、小さな目的に分解します。例えば、「開発効率の向上」が目的であれば、「ローカルでの開発・デバッグ」→「共同でのデバッグ」→「リリース前の検証」→「リリースして発売」という開発時間の流れに沿って、この目的を分解することができます。なお、この順序の場合、分解後の新たなサブ目的は、相互に独立した完全なものでなければなりません。
- 時間の順序:目的を実行するための手順やプロセスに基づいて、目的を分解することができます。
- 構造シーケンス:空間、地理的位置、内外の条件などから目的を分解することができます。
- 程度の順序:優先順位に基づいて目的を分類することができます。 さて、次は目的を整理します。やりたいことをすべてやるには、人手も能力も足りないでしょう。したがって、すべての目的が現段階で追求する価値があるとは限りませんし、高額なコストを伴う場合も同様です。最も重要な目的を見極める必要があります。
感想
現在、私自身が勉強している「ピラミッド・プリンシプル」という本や、キャリア開発に関する本などを読んでみるといいと思います。技術的な知識だけでなく、思考法やプロジェクトマネジメント、対人コミュニケーションなどについても理解を深めることができます。もちろん、本や論文は理論的な知識を提供するだけです。その真価を問うためには、やはり職場で実践する必要があり、私も今、それに取り組んでいます。将来、より多くの経験を皆さんと共有できることを願っています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ