【後編】テックドリブンなチーム作りの秘訣！Microsoft Azure開発チームのエンジニアが開発の裏話を明かす「DIGITAL Decision 2022 “Engineer Night”」
日本のみならず世界で活躍するエンジニアにはどのようなスキルや考え方が必要とされるのでしょうか。これからのキャリアを見据え、エンジニアとしてレベルアップしていくには、最新の技術動向を学ぶことが不可欠です。
船井総研デジタルが主催した「DIGITAL Decsion2022 “Engineer Night”」では、開発現場最前線で活躍しているスペシャリストが登壇。後編では、クルーズ CTOとCROOZ SHOPLIST 技術統括部長を兼任する鈴木 優一氏がテックドリブンな開発チーム作りを解説。トークセッションではMicrosoft米国本社所属のエンジニア牛尾 剛氏を交えたトークセッションを行いました。その模様をお届けします。
⇒イベントレポートの前編はこちら
目次
登壇者プロフィール
CROOZ SHOPLIST株式会社 技術統括部長
その後2012年クルーズ株式会社に入社。入社後は技術統括部門の責任者として全社の開発平準化や採用技術選定、アーキテクト業務に従事のほか、品質管理部門やCS部門、人材育成部門の運営に携わる。2015年に執行役員就任。現在は最高技術責任者CTOとして、グループのIT技術・セキュリティ分野全般を担当。
現場と経営層の意思疎通によるテックドリブンな開発チーム作り現場の課題を集める4つの方法
本イベントの3つ目のセッションでは、EC事業を主力事業とするクルーズのCTOとCROOZ SHOPLISTの技術統括部長を兼任する鈴木 優一氏が登壇。「テックドリブンな開発チームの作り方」と題して、CROOZ SHOPLISTのチームデザインや組織作りに対する取り組みを明かしました。
特筆すべきは、CROOZ SHOPLISTの従業員数の約53%をエンジニアが占める点です。
職種割合としては、サーバーサイドのエンジニアが半数以上を占めます。
同社では、チームデザインや組織作りの一環として「現場から課題を吸い上げてすぐに改善する文化を大切にしている」と鈴木氏は説明します。現場の声を集める方法は、大きく4つに分けられます。
1つ目の「21時フィードバック」は、経営層と開発部のメンバーが新たに導入する技術についてディスカッションする場です。経営層と現場は距離感が遠く、意思疎通がうまくいかないケースもあります。そこで、3ヵ月に1度のペースで「21時フィードバック」をセッティング。経営層は現場の従業員と直接コミュニケーションを取ることができ、従業員は導入したい技術を気軽に提案できるように工夫しているといいます。
2つ目の「デイリーミーティング」では、発生した課題をできるだけ当日中に解決することを目指しています。
3つ目は「開発部内会議」です。CROOZ SHOPLISTはマトリックス組織に近い形態を採用しており、その中で職能のレポートラインとなる「開発部会議体」を作っています。開発部会議体が実施する「開発部内会議」で、現場の課題を吸い上げ、スピーディーに現場に反映させる仕組みを構築しました。
4つ目の「重要プロジェクト制度」は、挙がってきた課題を重要プロジェクトとして現場メンバーがプロジェクトオーナーとして実行していくユニークな制度です。
「当社では、現場の課題を社長やCTO、開発本部長へすぐに報告・相談できる文化が根付いており、課題解決を重要なプロジェクトとして扱っています。こうしたプロジェクトは現場の従業員が主体となって解決に導くため、他企業では得られない達成感を味わえる上、成果に見合ったインセンティブを受け取ることができます」（鈴木氏）
4つのチームそれぞれに5つの役職を設置
CROOZ SHOPLISTは「開発本部」と「技術統括本部」という2つの部門に分かれています。開発本部は事業寄りの組織で、「KPIを達成するにはどうするか」を主に考えるグループ。
一方の技術統括本部は技術寄りの組織で、例えば「開発原価をどのくらい下げられるか」、「製品の品質をどのように上げるか」など、KPIに直結しない要素を主に考えるグループです。
開発本部には、さらに細分化されたチームが存在し、それぞれのチームが異なる性質のプロジェクトを担当しています。開発本部の「第一開発部」は主にフロントエンド、「第二開発部」は主にバックエンドのプロジェクトを扱います。
細かなチームが存在するのは技術統括本部も同様で、「技術統括チーム」と「生産性改善チーム」に分けられます。「技術統括チーム」は、基本的にシステムアーキテクチャの設計を担当し、生産性改善チームはリファクタリングや、メトリクス化した生産性指標に対するCI/CD（Continuous Integration/ Continuous Delivery）などを支援します。
ここまで紹介した4つのチームには、基本的に5つの役職が設置されています。上から順に「開発本部長」「技術統括本部長」「部長/部長代行」「部門職種長」「認定レビュア」です。
鈴木氏は、同社の体制について以下のように語ります。
「特徴的なのは部門職種長と認定レビュアという役職です。サーバー・フロント・ネイティブ・デザイン・インフラといった全ての領域に、1人の専門職種長を配置しています。現場の従業員が困ったときに相談ができ、技術面からフォローしてもらえる存在です。認定レビュアは、ソースコードの品質担保のためにレビューを担います。現在は、クロスレビューの体制をとっています」
テックドリブンな組織運営における3つの取り組み
鈴木氏は、CROOZ SHOPLISTのテックドリブンな組織運営として、直近2年間における具体的な取り組みを紹介しました。
1. 提案されたビジネスツールを即導入
「Slack」導入以前は別のチャットツールを使用していたものの、「添付ファイルをAPIから送れない」などの課題がありました。Slackを導入することで、全社で月150時間もの工数を削減できる見込みがあったことから、21時フィードバックでの提案を受けて即時導入を決定したといいます。
「提案されてから約1ヵ月でチャットツールを切り替えました。スピーディーに意思決定できるため、21時フィードバックは非常に有用だと思います」（鈴木氏）
プロジェクト管理ツール「Wrike」も１ヵ月程度で導入。複数のプロジェクトが絡む場合はスプレッドシートでの管理に負担が生じやすいという課題があったため、導入を決定しました。もちろん細かな費用対効果を検討しますが、大枠で効果が出ることが明らかであれば、同社はすぐにツールの活用や切り替えに乗り出します。
2. 現場の従業員が主体となり重要プロジェクトを推進
重要プロジェクトにおいて、開発部門が主体となり行った取り組みは2つあります。
1つ目は「リファクタリングタイムの導入」です。CROOZ SHOPLISTは売上や利益を追求するあまり、メンテナンス作業を後回しにしたことで、コーディングし直さなければサイトを維持できない状況に陥っていました。
そこで3M社が実践していることで知られる「15%カルチャー（勤務時間の15％を自分の好きなテーマの研究に使うこと）」をヒントに、毎週4時間のリファクタリング時間を設け、ソースコードや仕様書、システムの陳腐化を防ぐ仕組みを導入。結果として、デッドコードを約10％、不要なDBテーブルを約15%削減できています。
リファクタリング時間について、「現場の従業員と合意した上で、品質維持のために必要な時間を確保しています。売上や利益は重視していますが、技術会社としては譲れない部分です」と鈴木氏は語ります。
2つ目は、静止画フォーマット「WebP」の導入です。WebPのフォーマットで画像を圧縮すると、画質を落とさずに容量を約50%減らすことが可能です。SEOの観点では、画像の読み込み速度が非常に重要視されているため、WebPを導入して、画像の変換を自動化しました。
3. 開発言語の統合で開発の生産性を向上
直近で開発部門が着手した大規模な事例として、鈴木氏はモバイルアプリケーションを開発するフレームワーク「Flutter」へのリプレースを挙げました。
「Flutterを使い、アプリケーションのコードを約1年かけて書き換えました。この取り組みも、現場の従業員が提案して採用された事例です。これまでは個別の言語でコーディングされていましたが、Flutterに統合して1つの言語で開発できるように工夫し、開発の生産性を向上させました」（鈴木氏）
これらの事例から分かるように、同社では現場の従業員が非常に発言しやすい風土の醸成に成功しています。
取り組みの統合によるテックドリブンな開発チーム作りに成功
その他、CROOZ SHOPLISTは技術カンファレンスの開催にも取り組んでいます。同社がテックドリブンな組織づくりを目指す過程では、最新技術の活用を求めるたびに常に何らかの壁にぶつかってきました。
そこで同社は、「日本国内であまり情報が出ていないものを、紹介・提供したい」「IT業界全体の発展に寄与したい」という考えに立ち、2010年頃から技術カンファレンスを開催しています。
開発現場からの声を拾い上げていると、どうしても現場の従業員からは技術的な視点に立った要望が多くなってしまいます。そうした中、社長やCTO、開発本部長が現場の意見をうまく拾い上げることでチームをまとめ上げてきました。
「当社では事業活動を主軸に行う一方で、技術者が新しいチャレンジを実施できる環境を整えています。これまでの取り組みを統合した結果、テックドリブンな組織として開発チームを運営できています」と鈴木氏は成功の一因を振り返ります。
Microsoft所属の「普通エンジニア」が明かすAzure開発の裏側
本イベントの最後を締めくくるトークセッションではMicrosoft米国本社の牛尾 剛氏、ゼンアーキテクツの芝村 達郎氏（@shibayan）、船井総研デジタルの執行役員 竹下 圭氏が登壇しました。
登壇者プロフィール
Senior Software Engineer – Azure Functionsプロダクトチームのシニアソフトエンジニア
エンジニア兼ソリューションアーキテクト
執行役員ソリューション事業本部
2018年7月船井総研グループに参画後、船井総研デジタル(※2022年7月1日とより統合・名称変更)にてエンジニア組織づくりを推進。
今の夢はコードを書いてものを作れる人間になること
竹下 : まずは牛尾さんの自己紹介をお願いします。
牛尾 : Microsoftに所属していますが、はっきり言って私は優秀なプログラマーではありません。あくまでも、優秀なプログラマーに「なりたい」人です。IT業界で最初に入社したのは大手SIerでしたが、技術力が無さすぎて営業部に配属された経緯もありました。
ですが、ある人のおかげでどうにかエンジニアになれました。人生がうまく回り始めたと思えたのは、アジャイル開発に挑戦してコミュニティに顔を出すようになった頃です。
エバンジェリストやPM関連の仕事は得意ですが、プログラマーには向いていませんでした。今の夢はコードを書いて、ものを作れる人間になることです。非常に不器用ですので、何回もチャレンジして失敗し続けてきました。
Microsoft Azure（以下、Azure）のサービス「Azure Function」が昔から大好きで、ラッキーなことに開発チームの一員になれました。ただ、主にアジャイル開発の方法論を学んできたので、そういう観点で物事を見ることは得意だと思っています。
日本とアメリカではエンジニアへの「信頼度」が違う
竹下 : 今はシアトルにお住まいなんですよね。エンジニアの働き方は、日本とアメリカで違うものなんでしょうか？
牛尾 : ぶっちゃけ、何から何まで違います。（笑）
まず、日本企業のように物事を決める「お偉いさん」がいないですね。私の職場には、上下関係の厳しさが全くありません。Microsoftの社長とフレンドリーに話せます。
エンジニアとして働くときの主体は常に自分で、上層部にお伺いを立てる必要もありません。ワークアイテムを振られたときは、明確化する、設計するのも自分で、全て自分の裁量なんです。
竹下 : 他にはどのような違いがありますか？
牛尾 : 衝撃的に違うのは納期の感覚ですね。
「半年くらいで、これくらいやろう」と大まかな計画がある程度で、進め方についてもメンバーとディスカッションして決めていきます。そのような進め方なので私の職場では見積は全くしていません。日本同様にアメリカでも工数の見積もりは難しく、見積はもはや星占いのような位置づけです（笑）
ただ、アメリカではエンジニアが主体になって進め方を考えるため、営業や上司からとやかく言われることはありません。ソフトウェア開発後のテスト段階でトラブルが見つかったとしても怒られません。私が1週間で終わると見積もったプロジェクトが結局2ヵ月以上かかったときに、「よくあることだよ。気にしなくていいよ」と言われただけでした。
アメリカではエンジニアが信頼されてるんですよね。怠けるエンジニアはいないし、全員が自分なりに最速で一番いい製品に仕上げようと努力しています。周りもそれを信じているので進捗のチェックはありません。むしろ、困ったときは助けてくれますね。
マネージャーはあくまでもエンジニアのサポーターなんですよ。あれこれと現場で指示を出すことはなく、つまずいたときに助けてくれる存在です。アメリカでは「上司が偉くて、全て上司が決める」みたいな世界線ではありません。
あとマネージャーは、最新技術に精通している人材ばかりです。実際、「Azure App Service」の基盤を作った優秀な方が、僕をサポートしてくれる場面すらありました。
芝村 : なんか納期がないというのはアメリカっぽいと思いながら聞いてましたけど、逆に僕らのようなAzureを使う側はリリースのスケジュールが全く読めないんですよ。
牛尾 : 読めないですよね。アナウンスされても消えていったりしますしね。（笑）
マルチタスクではなく、プライオリティを重視する習慣も違う
芝村 : アメリカはすごいですね。ただ、個人的には異常にKPIが強い一方、自分の職務以外は優先しないイメージがあります。その点はいかがでしょうか？
牛尾 : おっしゃる通りですね。アメリカの文化なのかMicrosoft独自の文化なのかは分かりませんが、プライオリティを非常に重視します。「マルチタスクは生産性が下がる」という感覚をもっていて、全ての業務を並行して進めると失敗しやすいため、どうしてもプライオリティの高いものに注力してしまいます。
例えば、今僕は非常に優先順位の高いSEV2（深刻度レベル2）のインシデントを担当しています。夜中の2時に起きてインシデントに対応することもあります。優秀な人材でも、多くて3つのプロジェクトを担当しているようです。
Microsoft所属エンジニアから見ると、Azureのどんなところがすごい？
竹下 : Azureの開発現場を見ている牛尾さんにとって、Azureは技術面でどのように優れていると思いますか？
牛尾 : いや、皆さんが思っているよりも意外に普通ですよ。
まぁそもそも未だに .NetFramework で動いているところがあったり、レガシーコードも普通にあります。
ただコードベースはすごいですね。
クラウドサービスのコードベースはかなりの規模なので、ビルドするのに128GBのメモリの超強力なマシンを使わないと快適に仕事できない、というのはありますけど（笑）
規模が大きいので、まず一般公開されていないリージョンでデプロイして、本番環境でしか確認できないような検証を通じてバグを発見し取り除いていきます。
あと、フィーチャーフラグ*¹も作っています。僕らはクラウドの小さい単位を「スタンプ」と呼んでデプロイしますが、一部のリージョンを使って、特定のスタンプのみフィーチャーフラグをオンにして運用しています。
*¹ コードを書き換えず，フラグを使って機能を有効化するために設ける仕組み
世界中のリージョンに対して一挙にデプロイするのではなくて、例えば、最初はカナリア*²のリージョンにデプロイして、それから数少ないリージョンにデプロイするといったように、段階的にデプロイを進めています。そういったデプロイで発生した問題は全てダッシュボードで監視しているので、メンバーでディスカッションして原因を調べたりしていますね。
*² カナリアリリース…サービスを一部の利用者のみに公開して反応を見て提供範囲を拡大する方式
その他で僕が面白いと思ったのは、インシデントの解決専用のシステムがあることです。基本的には届いたチケット（問い合わせ）の一次対応は各リージョンの担当者が行いますが、それでも解決が難しいチケットは僕らエンジニアへとエスカレーションします。
2年ほど前、僕がFunctionチームに入ったころにインシデント解決の仕組みができて、それがすごいイケてるんですよ。
そのシステム上で、お客様のサイトの名前を入力すると、自動でサイト全体を解析して、Exception（例外的な使われ方）をしている箇所を一括で検出してくれる仕組みができて、それで対応するようになってからものすごくインシデントの数が減りましたね。
その結果、さらに難しいインシデントだけ来るようになったんですけどね。（笑）
竹下 : やっぱりグローバルなプラットフォームは規模が違うなと思いました。
芝村 : 最近、Azure App Serviceの規模感が公開され、やはりスケールの大きさに驚きました。1日にして、グローバルで160億ぐらいのリクエストを処理しており、運用側にとっては通常のシステム開発よりも断然難易度が高いと感じています。
牛尾 : だからこそ、楽しいのだと思います（笑）
竹下 : 自分のスコープを把握するだけでも、負担が大きいのではないでしょうか？
牛尾 : 自分の知らないリポジトリは複雑すぎるので、コンテキストの理解に時間を要します。当然、分からない点は知見のある人に聞きまくってます。
アメリカと日本は文化が違うのに働きやすい？
芝村 : アメリカでは「クイックコール」という、気軽に質問できる文化があると言われていますね。日本では、誰かに質問すると仕事の手を止めさせてしまうため、どうしてもためらってしまいます。
牛尾 : Microsoftには、ある人からフィードバックを受けたい場合に申請する「フィードバック」という制度があります。周りのエンジニアからフィードバックの活用を勧められたこともあり、実際に使ってみると生産性は劇的に上がりました。聞かれるであろうことをOneNoteにメモとして残すなど、質問されたときにすぐ回答できる用意をしている気がします。
ただ、そういう文化では思った通りに仕事を進められなくなります。困っていたときに、上司が良いアドバイスをくれました。僕が「質問されて何も進まないけど、どうしたらいい？」と聞くと、「シニアエンジニアが全員やっているテクニックを教えてあげる」と。彼女が話していたのは、「1日4時間ブックして、この間は何もレスポンスしない」ということでした。4時間あれば、何かしら業務を進めることはできます。それ以外の時間を使って助けてあげれば、周りからの心象も悪くありません。
竹下 : 日本企業の場合は、何かを実行するときにルールを決めますが、アメリカではルールメイキングと文化のバランスが取れていると感じます。この点はいかがでしょうか？
牛尾 : あまりルール決めはありませんね。本当に必要な部分にだけルールが作られるイメージです。日本のように細かすぎるルールはないので、非常に働きやすいですね。
例えば、日本の会社では、PCの持ち出しやUSBの使用などを禁止するルールがあると思います。しかし、Microsoftでは個人のPCを業務に使用できます。PCに自分のアカウントを入力したらADが作動する仕組みになっており、社内のセキュリティ基準に合わない場合は、社内ネットワークにログインできません。
ソフトウェアのアップデートや多要素認証、暗号化などに対応していない場合も当然ログインできません。個人のPCを使えて、しかもセキュリティ面で個々人が努力する必要はないのです。こうした点は非常に働きやすいと思います。
牛尾 : 昔はパスワード付きのZipがメールで送られてくるみたいなのがありましたね。
芝村 : いや、日本では未だにそれはありますよ。
牛尾 : え、なんでOne Driveとか使わないんですかね。
芝村 : 未だに日本には、クラウドサービスから機密情報が漏れるのではないかと考えている企業もあるんですよ。
牛尾 : それだったら、大変だと思うけど、自社でクラウドサービスを作るしかないですね。（笑）
芝村 : 実際、そういうオンプレのことをプライベートクラウドと呼ぶみたいな流れはありますよ。
竹下 : デジタル庁も最近、国産のクラウドを作ろうと、クオリティクラウドなるものをつくりはじめたとか。
芝村 : 国内にそういった海外での競争力のある企業が生まれるといいのですが、どうしてもスピード感で勝てないですよね。毎週アップデートされる海外のクラウドサービスと戦えるかというと、実際はまずリングにすら立たせてもらえないのが現実かと思います。
10年以上かけて洗練されてきたAzureの技術
芝村 : 僕がPaaSやサーバーレスを使う理由は、僕より優秀なエンジニアが10年以上の歳月をかけて作ったクラウドインフラを利用すべきだと思っているからです。巨人の肩に乗って、知見を簡単に利用できますよね。
牛尾 : Azureを開発していて面白いと感じるのは、中身や内情を知れる点ですね。
例えば、スケーリングやアルゴリズム自体はそんなに難しいわけではありませんが、実用に至るまでは紆余曲折があります。スケールした際にフロントエンドに問題が生じて、それを解決したら別の問題が生じることの繰り返しです。地道な方法で少しずつ技術が洗練されていって、今のサービスがあります。
芝村 : 僕としては、ありがたい限りですよ。アプリケーションのコードを書くことが好きなので、今では手軽にコードを書けますよね。
昔だったらWebサーバーのセットアップが必要で、外部からHTTPにアクセスするまでひと苦労でした。Webサーバーの構築に3営業日はかかったほどです。
最近では必要なときだけサーバーを使えるなど、クラウドのおかげでエンジニアリングは非常に楽になりました。クラウドサービスがあれば、最初の立ち上げは非常に簡単です。
牛尾 : ちなみに僕の頃は、サーバーの調達にすら6月間かかっていました（笑）
一番もったいないのは「日本だからできない」という考え
竹下 : 最後に改めて、エンジニアへのメッセージはありますか？
牛尾 : 日本とアメリカの違いを主に触れてきましたが、今になって振り返れば、特に日本企業では実現できないことではありません。例えばアメリカの「納期がない」文化も、日本に物理的な障壁があるわけではないでしょう。あくまでも周囲が納期を認識していれば済む話です。マネージャーの役割も、時代に合わせて変わっていく可能性はあるでしょう。
一番もったいないのは「日本ではできない」と思い込んでしまうことです。
僕は大したエンジニアではないしセンスはないと思っていますが、Azureの開発メンバーになれているわけです。きちんと準備をして選考を受ければ、エンジニアになることはできます。
Azure App Serviceという大きな括りの中で、唯一の日本人として在籍していた河野さんという方は、周りから「どうしたらそんな良い職場に就職できますか」とよく聞かれていました。河野さんは「みんな選考を受けましょうよ」と答えていました。
しかし、質問した人は誰も選考を受けることはありませんでした。
チャレンジして、受かったのが僕です。
もちろん、僕は内部の事情でたまたま受かっただけです。
ただし、受けなかったら受かることは絶対にありません。芝村さんや僕の話した内容で、いいなと思うことがあったら、行動に移してほしいです。
芝村 : 「海外のエンジニアはすごい」という印象を抱いている方は多いかもしれませんが、実際海外のエンジニアの方と交流してみると、言っていること、やっていることは日本と海外で大差ありません。逆に、日本のエンジニアのほうが細部まで見ています。
日本のエンジニアは技術力で劣っておらず、むしろ勝っている部分もあります。
ただ、海外は実行力やスピード感に優れていますね。そういった部分を私も磨き続けたいと考えています。ためらうことなくチャレンジする精神が大事だと思っています。とイベントを締めくくりました。
フルリモート勤務OK★Azureスペシャリストチーム立上げメンバー募集！
2022年7月に発足した船井総研デジタルでは一緒にAzureでシステム開発日本一を目指すメンバーを募集しています。
会社も事業もアジャイルに成長していく環境で、毎日ワクワクしながら新たな仕事に参加したい方を、歓迎しています。