2024.12.24
ビジネスが急速に変化する現代は「OODAサイクル」と親和性が高い 流通卸売業界を取り巻く5つの課題と打開策
リンクをコピー
記事をブックマーク
牛尾剛氏:あとは品質確保はどうしているの? って思いますよね。だってぜんぜんルールがないんだから(笑)。どうしているかっていうと、一番重要なのは自動化です。人間のやり方を規定するなんてそんなものは面倒くさいし、大危険ですよね。だから僕らの場合は徹底的に自動化します。自動化しないと世界中のサービスなんかとてもとても回せませんみたいな。
あとはめちゃくちゃ普通なことしかやっていません。例えばCanaryリリースとかね。世界中のリージョンにちょっとずつ端っこからデプロイしていくみたいな。ちょっとずつデプロイしていく。そうしたら早めに問題に気づくという感じです。
もしなにかあったらFeature Flagsをターンオフしたら、新しいFeatureをターンオフできるので戻りますみたいなね。そういうものを使って、安全なリリースをします。これは本当に別にうちが特殊ではなくて、もうめちゃくちゃ当たり前のDevOpsのテクニックですよね。
あと重要なのはやはりレビューですかね。人系で重要といったらやっぱりレビューです。デザインのレビューとか、PR、プルリクエストのレビューです。コードのレベルのレビューが一番重要で、次にデザインのレビューです。
デザインもめっちゃドキュメント書いたりはしません。僕らが使うのはデザインドキュメントってWordのやつで、2、3ページから5ページ、10ページ、長くても10ページぐらいのやつです。つまりすごく簡単に書けて短いやつ。それをみんなにシェアできるようなWordとかに書いておいて、それでみんなでコメントを入れてもらえたりするんで、すごく便利ですよね。
自分は経験が足りないんで、イケてる人のbrainを借りて、レビューしてもらったりとか、一緒にそういうのを会議してデザインディスカッションをしてもろたりします。だから彼らのすげー賢い頭を借りて、僕みたいなあほにゃんにゃんでもなんとかやれる感じになるわけですね。
あとは最後にBug Bashですね。別にテストケースがバーッと定義されているわけじゃないけど、いろいろな立場の人が、みんなそれぞれの立場でバグを、システムを使ってみてバグを取る手法です。こんな良い加減でええの? と思うけど、意外とこれは有効ですね。ちゃんとした手法らしいです。
あとイノベーションってどんなふうになっているの? って話です。まぁみんな気になりますよね。これもけっこう地道な話なんですけど、どういうことかっていうと、まず初めはめっちゃ地道な技術的な積み重ねと失敗の歓迎って感じです。
1つの例を挙げると、僕は最近Flex Consumptionっていう新しいSKUのやつをやっていました。それを最初にポールっていうのと2人で一緒にやっていた頃は、どういうことをやっていたかって言うと、Functionsってやつなんで、スケールを速くしてほしいわけです。だからスループットができて、スケールがすごく速くなるために、僕らはバーストスケーリングっていう実験をしていたんですよ。もう何年前かな。2、3年前ですよね。もっと昔かも。
それで、いろいろ2人で考えていろいろ実装してみてテストしてみてやってみたんだけど、ぶっちゃけその時はできなかったんですよ。何年か前にやった時に、考えていたことが、これをやったら速くなるんちゃうか? っていうのができなくて、当時のプラットフォームではできないっていうのがわかりました。
僕はけっこうしょんぼりしましたよ。だって俺がやっていたのは、なんの意味もなかったんかーみたいな。あんなに時間かけたのになって。そしたらそのポールってやつは、逆で、ぜんぜん違う反応やったんですね。「おおー」って、「こうやったらできないってことがわかった」みたいな。「よかったよかった」みたいなことを言っていたんですよ。
それでどうなったかっていうと、その時に、今のプラットフォームではできないっていうのがわかったんで、その後に僕らは新しいプラットフォームを開発したんですよ(笑)。その新しいプラットフォームを開発したら、僕やポールがやっていたことが次は使えるって。
僕らは失敗をいろいろ重ねて、どうやったらいいかってもうわかっているんで、新しいプラットフォームを開発して、その上にそのFeatureを一瞬で実装してやったら、スループット40倍ぐらいになったんですよね。
だからなんていうのかな、失敗って別になんてことはなくて、結局あれもprogressなんですよ。
だからこっちで働いていると、失敗っていうのでネガティブなイメージがあんまりない感じです。失敗したら、ああこういうのができないってわかった、じゃあ次はこうしてみようと。それに対して日本やったらアウト感が何もないって思われるかもしれないですけど、こっちでいうと、「あ、それでやってくれてありがとう」ってなる感じです。こういうのがわかったんで、じゃあ次はこうしてみようみたいな。
だからそういうのは、やっぱり結局のところすごく地道な積み重ね。他にもキーノートでバーンと出るようなサービスもやったことがありますけど、ああいうのもそうでしたね。
あとは明確なビジョンです。やはりトップ層がすごく明確なビジョンを作っていて、本当にすごくいつも感心しますね。ある時は、あるすごいサービス、キーノートになったようなサービスに関わっていた時もありますけど、それも何年前から地道にやっていて。その時に、最初にビジョンを聞いた時に、正直言って、え? そんなんできんの? って思いましたよ(笑)。そんなことできるの? って思ったんですけど、みんながんばって本当に実装しちゃうんですよね。
経営層が思っていたビジョンをほんまに実装して。経営層のビジョンもさすがですね。前から、すんごい前から、みんなが熱狂するようなことを考えているわけですよ。だからそういうビルディングもすばらしいなと思いました。
あとはやっぱり上層部を含む技術力ですかね。だって僕らの一番上のサティア・ナデラもエンジニアですからね。技術力は日本にいる時はすごく軽視されていた気がします。プログラマーが偉いとか言いたいわけじゃないよ。でも、僕はよく言われていたのが、プログラミングなんか誰でもできるからみたいな。そんなことはやる価値がないみたいな。そんなんはもうアウトソースとかってよく言われていましたけど。
プログラミングなんか誰でもできるって、今はもうそんなことはぜんぜん思わないです。ぜんぜん思わないです。プログラミングなんか、はっきり言って、スーパー難しいですからね。そこに時間をかけてやらないと、積み重ねないと絶対できへんものなので。そういうふうにがんばらないといけないから、結局のところ給料が良いわけですよ。
あとは上層部もちゃんとわかっているから、いろいろなマイナス要素がないというか、足が引っ張られる要素がないので、ほんとに技術にフォーカスできる。やっぱり、コンピューターサイエンスもしぃへんのにすごいイノベーションができると思います? 僕はできへんと思いますよ。
やっぱりPh.Dの人はすごいし。だから技術力って目をつぶれないものであるって思いますね。いろいろなイノベーションを起こすためには、ものすごく重要なファクターだと思います。だから思いつきとかじゃなくて、もうめちゃくちゃプランされたものです。
あとはゲームチェンジャーという考え方ですね。これはほんとに最近の話なんですけど、僕がOpenAIのサービスを使って趣味でアプリを書いていて、そうしたらポールがいろいろレビューしてくれたんですよ。僕は自分の目的は、それを書いて、今はムーンライティングで自分の趣味でやっているだけやけど、これがもうちょっと発展したら自分の仕事になるといいなぁと思いながらやっているわけです。
そういうのを書いていたら、ポールがいろいろアドバイスしてくれて。「ああ、なかなかね、これおもしろいなぁ」みたいな。「おもしろい、これができたら確かに便利になるし、今ある仕組みよりもたぶん便利になるやろう」って言っていて。「でもね」って、彼は「でもね、これはゲームチェンジャーじゃないよな」みたいなことを言っていたんですよ。
ああ、なるほどなぁみたいな。みんながびっくりするようなものじゃないよねと。僕やったら今よりずっと改善したら満足しちゃうとこなんですけど、まだまだポールはそういうふうには言っていないですね。「これゲームチェンジャーじゃないよね」って。
でもそこで切るわけでもなくて、「こういうふうなことをやったらどうだろうか」とか「ああいうふうなん試してみようか」とかね、「でもこんだけのやつを1からほんとにend to endで動くように作ってくれて僕はすごくうれしい」って。
「僕は20個ぐらいアイデア考えていたけど、1つも自分ではやってないんで、こういうのを1つでも2つでもやってくれて、一緒に試せてすごくうれしい」みたいなことを言ってくれました。
僕もハッピーやし、そうやってゲームチェンジャーってどんなんか僕もわからんけど、そういうチャレンジする姿勢みたいなのは、けっこうこういうアメリカのイノベーションを生んでいるのかなってすごく思いました。
今日はいろいろ話してきましたけど、ここまで僕が話してきた内容って、僕はたぶん日本人やったらとか日本だったらできへんってことは何一つないと思うんですよ。だってDNAが違うとかじゃないですよね。だから、僕がこういう情報発信をしているのは、別に単なる趣味やけど、なんでかっていうと、やっぱり日本が良くなってほしいなって思っているからです。
自分はたまたまラッキーでアメリカで働いていて、自分が昔夢見たようなチームで働いていて、そんでそういう自分がいろいろびっくりしているので、そういうのがなにか1つでも日本のためになったらいいなと思って、僕は学んだことをいろいろシェアしているっていうふうな感じです。
だからもう1度、日本が技術の国になって、僕のマネージャーのプラグナーがThere is no magicと言っていましたけど、地道なことをしないといけないですけど、それをやっていけば僕らが負ける道理は何もないと思うんで、ぜひ日本でも技術を楽しくやって、できるようになればいいなと思いまして、こういうのを発表させていただきました。ありがとうございました。
関連タグ:
2025.01.09
マッキンゼーのマネージャーが「資料を作る前」に準備する すべてのアウトプットを支える論理的なフレームワーク
2025.01.08
職場にいる「嫌われた上司」がたどる末路 よくあるダメな嫌われ方・良い嫌われ方の違いとは
2025.01.07
資料は3日前に完成 「伝え方」で差がつく、マッキンゼー流プレゼン準備術
2025.01.10
プレゼンで突っ込まれそうなポイントの事前準備術 マッキンゼー流、顧客や上司の「意思決定」を加速させる工夫
2025.01.08
どんなに説明しても話が伝わらない“マトリョーシカ現象”とは? マッキンゼー流、メッセージが明確になる構造的アプローチ
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.01.09
記憶力に自信がない人におすすめな「メモ」の取り方 無理に覚えようとせず、精神的にも楽になる仕事術
2025.01.09
職場に必要なのは「仲良し集団」ではなく「対立」 メンバーのやる気を引き出すチームビルディング理論
2025.01.06
上司からの「ふわっとした指示」に対し、デキる人がやっていること 4タイプ別で見る、仕事を依頼された時に重要なスタンス
2025.01.10
職場にいる「できる上司」と「できない上司」の違いとは 優秀な人が辞めることも…マネジメントのNGパターン