
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
鈴木健太氏(以下、鈴木):(環境など)いろいろ変化をしますよねという話をしてきたんですが、じゃあ、どうすればその変化に気づいて変えられるチームでありうるか。これがやはり、価値を届け続けるためにはメチャクチャ大事なポイントになります。
そこでは、この3つの力が大事かなと思っています。気づく力と、聞く力、それから学ぶ力ということですね。
自分が作ったものがどう使われているか、役立っているかというのを確認するのは、やはりものづくりにとってものすごく大事なフィードバックです。これを受け取れるチームは、長く長くビジネスを続けていける。
サポーターズだってそうです。サポーターズってもともと、オフラインでイベントをやっていたんですよね。みなさんは今、オンラインで自宅とか学校とかから聞いてくれていると思いますが、これもやはりコロナ禍になってビジネスのやり方を変えたんですよね。
サポーターズの中のシステムも、例えば1on1、1つ取ってもそうですが、もっとやり方を変えていこう。リアルな場所にいるのではないんだから、もっとデジタルでやらなきゃいけないとスタイルを変えていったんですね。
というふうに、ここ2、3年でも、気づいて変えていったチームによってサービスがより一層使われるものに変わっていきました。
これをやるために、チームで気づくという話をしていますが、あくまでチームの中の個人がそれに気づかないといけないんですよね。
というのも、チームはあくまで個人の集合体なので、誰かが気づいて変えようとしないと、変わっていかないんですよ。
「それは誰かが気づくからいいや」とほっておいても変わっていかないので、じゃあ、個々人が気づくためにはどうしようということをふだん僕らは開発の中に組み込んでいます。
その方法の1つが、この「フルサイクル開発者」というスタイルです。CARTA HOLDINGSでの開発方法、あるいはスタンスの1つとして紹介しているのですが、開発した人が運用する。つまり作ったものを自分自身で運用していくという話です。
「Design」「Development」「Test」「Deploy」「Operate」「Support」というサイクルでグルグル回っている図があります。
例えば、開発チームが「開発しました」と言った後に、「テストはもう、あとの人でよろしく」とか、「自分はもう作った。パッチを書いたので、あとはデプロイしといて。様子を見といてください」とか、そういうことではなく、自分で作ったものをきちんとテストしてリリースして、実際に使って、お客さんあるいはユーザーが使っている様子を自分たちで見る。
「きちんと使われているかな?」とか「きちんと機能しているかな?」ということを開発チームのメンバー自身がセンサリングするということをスタンスとしてやっています。
これをやっていかないと、やはり開発の質はなかなか上がりません。例えばビジネス上の要望、つまり「こういう新しいクライアントが取れそうだから、この機能を作ってくれ」と言われた時に、それがどうしても優先されてしまう。
けれど、「いや、待ってくれ」と。「今、自分たちは、どういうふうに使われたかをシステム的に取ることができないから、まずそれのログを取って集計する仕組みを先に作りましょうよ」と、エンジニア自身が言えるんですね。
そういうふうに、ビジネス上の要望と同じレベルで優先順位をつけて、決めていく。そういうことをスタンスとしてやっています。
CARTA HOLDINGSが出している『事業をエンジニアリングする技術者たち』という本の中にも出てくるのですが、ビジネスアイデアからお客さんに届くまでを1つのサイクルと見て、それをすべて1人の技術者でやっていく。そういうのが、フルサイクル開発者のイメージだと伝えています。
もちろんスペシャリティを持ったエンジニアのチームもあって、そこにはバックエンドのスペシャリスト、SRE、フロントが得意な人などがいますが、やはりエンジニアの仕事は、コードを書くことだけではなくて、ビジネスにつなげることです。それはCARTAとしてもだし、このフルサイクルエンジニアリングのスタイルとしても大事なことです。
もう1度示すと、このプロダクトあるいは事業には、この改善のサイクルが大事だという話をしました。その中で「広義のプロダクト」を伸ばしていくために、個々人が気づいて機能を追加していく。それにより自身のスキルも伸びるし、チーム自身の改善にもつながります。そういう構造になっています。
事業を作る上で、「大事な力は何かな?」と思った時に、これは「繰り返しの価値」なんですね。フルサイクルエンジニアリングの中でも、実際に使ってもらったものを受け取って作るという話をしていますが、やはりフィードバック、つまり、「どうだったか?」というものを受け取って、それを変えていくということを繰り返すことが、プロダクトのクオリティをどんどんどんどん上げていきます。
これは先ほど話したサポーターズの例もそうだし、fluctでの動画広告の開発の例もそうですが、作って、リリースして、使ってもらった結果どうだったかというのをきちんとシステムに組み込めるか。チームとして価値を出していることをきちんとセンサリングして、それを改善に活かすことがポイントになります。なので、サイクルを回すことで学ぶ力が増えていく。そういうことが構造上重要だということですね。
これは本当に、個人の学習の最初に言ったサイクル。つまり、なにかを試して、ツールを使ってみて、でもここの部分がわからないよねということをさらに深堀って調べて、いろいろなルートを行き来しながら学びを深めていく。そういうことの中で、リリースして使ってもらうことは、チームでも個人でもすごく重要だし、同じ構造です。
だからこそ、これを一人ひとりができるようにするということが、チーム自体の価値提供をさらに改善することにつながるし、プロダクトをさらに良くすることにもつながっていきます。
CARTA HOLDINGSの開発スタイルが、昔からそうだったかというと、事業をガッとたくさん作っていく中で、多くの失敗を重ねて、その中で試行錯誤してきたという歴史があります。
最初からフルサイクルエンジニアリングをしていたわけではないし、これにはもともと名前もついていませんでした。だけど事業を続けていく中で、エンジニア個人個人がそうやってデプロイしたり、価値を届けられる直接的なポジションにいるということがすごく大事だよねということに、みんなの考えが寄ってきて、その結果、こういうスタンスが会社の中でも共通のスタンスになってきたというのが、歴史としてはあります。
これは、「OODAループ」と言ったりするのですが、個々人が意思決定をして行動をすることのメカニズムを解説したループで、もともとアメリカの軍の中で研究されてきた方法論です。
「Observe」「Orient」「Decide」「Act」、つまり観察と状況判断、それから意思決定と行動ですね。この4つのフェーズ、ポイントに分けて意思決定の構造を解説しています。
先ほど話したフルサイクルエンジニアリングの話は、まさにここの構造につながっていて、「Observe」、つまりなにかを観察して、理解して、何が起きているかに気づくということ。
そして、「Orient」、ここが一番大事なんですが、なにが起こっているかを個人個人が適切に判断できることが、その後の質につながるという話を、この構造はしているんですね。
例えば、過去にした経験とか、データとかに基づいて状況を見た時に、いったいなにが起こっているのかというのを正しく理解する、状況を判断することによって、次の意思決定がうまくできますよねということを、ここでは言っています。
「Decide」は、もちろん決めること。そして「Act」は、やることですね。意思決定をして、例えば、この機能を作るかどうか。ラーメン屋のラーメンを運ぶアプリケーションを作るかどうかもそうだし、それに給与計算の機能を入れるかどうかも意思決定ですよね。決定の質を上げるために、こういう構造が背景にはあります。
エンジニアリングとこのOODAループには、すごくつながりがあって、「OODAループにおけるエンジニアリングの価値」というのは、このへんのポイントであると思っています。
やはり、「Observe」できるようにすること。つまり何が起きているかを理解する。現象を理解するために、例えばログを残す、それからモニタリングする。最近だとオブザーバビリティを確保するとか言ったりしますが、そういうことのために、まず仕組みが作れるということ。
それから、知識ですよね。エンジニアリングの知識があるからこそ、何が起きているかを深く理解することができる。これは「Orient」につながる話で、技術の知識を基に事業をやっているからこそ、状況判断の質が上げられます。
意思決定についてもそうなんですが、例えばなにか機能をリリースしようとなった時に、「やはりやめよう」ということもぜんぜんあっていいですよね。
「こう判断して、やることにしたんだけど、戻る」というリスクを最小限にするということも、エンジニアリングのポイントです。実際にやるかやらないかを迷うケースもあると思いますが、実際ちょっとだけやってみる、「Act」までいってみて、戻すということがあっても、ぜんぜんいいんですね。
というふうに、フィードバックを利かせるということができるのは、ソフトウェアエンジニアリングの力ですね。前の図で言うと、このあたりです。
OODAループは最終的にどうなったらいいか。「Observe」、個人が観察してからすぐ行動できることが、「適用を素早くして価値を生み出すこと」の価値が高い状況下においては一番適切だよねと言われています。
先ほどこれは軍の話だと言いましたが、パイロットが相手の機体と遭った時に、上に行くのか下に行くのか、回転するのか、弾を先に撃つのか、雲に隠れるのか、どういう行動を取るのか判断できるといいよねというようなことが、モデルの中だと言われています。
これは、ソフトウェアエンジニアリングの中でもそうで、実際にこういうことが起きている時に何を作ればいいか、もちろん相談はチームですべきですが、判断力が上がっていくということは、けっこう理想の状態だと言えるかなと思います。
なので「Observe」から「Act」へのパスというのを、チームの中に作る。これもソフトウェアエンジニアリングの価値かなと思います。
繰り返しの価値を得られるチームというのは、やはり信頼をベースにしたチームであることなんですね。フルサイクルの開発スタイルにするためには、やはりみんなに期待して信頼して任せなきゃいけません。お互いにわからないことは「わからない」と言いながらやっていくことによって、個人もチームも成長する。そういう構造です。
「Westrumの組織類型」というのがあるのですが、創造的な組織というのは、リスクを共有するし、失敗しても「みんなで調査しようよ」と言うし、積極的に協力してやってみよう(と言います)。そういう組織が創造的だと言われています。
なので、このフルサイクルのエンジニアリングスタイルを実現するためにも、創造的な組織、チームにつなげなければいけないということですね。
これは、ひいては、CARTA TECH VISIONに書いてある「共に信頼し、共に創る」というところにつながっています。
では、まとめです。テクノロジーは事業の競争力そのものですね。「Why Software is Eating the World」というコラムがありますが、やはりソフトウェア自体の強みを事業に組み込むこと。これが事業の生命線です。
その中で、事業のまんなかでエンジニアリングするキャリアに必要なのは、自分自身がこの事業のサイクルのまんなかに身を置いてチームで動くこと。そして、技術以外からも目を背けずに、うまくいくためにできることをフルサイクルで経験しながらやること。それがコアです。それによって、コンフォートゾーンを飛び出て、自分も成長していきます。
これが、事業のまんなかでエンジニアリングするキャリアのあり方だと考えています。
「事業で課題に出会い、スキルを伸ばし、また解いていく」。課題に出会うことによって解決する力がどんどん上がっていきます。
そして、経験を加速させるチームに変えていってプロダクトに対してオーナーシップを持ち、アイデアが生まれる場所から実際に作って届けるまでをやっていく。そういうことによって、自分自身のスキルも上がっていくという構造になります。
まとめると、改善のサイクルに身を置いて、価値提供をし続けることによって自分のスキルも磨いていくというのがキャリアの作り方だと考えています。
ちょうど時間ですかね。将来、信頼し合ったチームを作れるように、ぜひみなさんがんばってほしいなと思っています。そして、たくさんエンジニアリングして、たくさんリリースして学び取って素敵なチームがたくさん生まれることを願っています。
発表は以上です。CARTAからのお知らせで、採用のお知らせも出ていますが、こちらもよろしくお願いします。
司会者:鈴木さん、あと3分ほどお時間があるので、学生さんからの質問などにお答えいただけるようでしたら、質疑応答のお時間などいかがでしょうか?
鈴木:もちろんです。
黒田:ありがとうございます。では、学生のみなさん、鈴木さんになにか聞いてみたいことがありましたら、Zoomチャットにて投稿していただければと思います。いかがでしょうか?
さっそく来ました。「信頼はどうやったら勝ち取れますか?」というご質問がありました。
鈴木:信頼と信用というのがあって、仕事をしっかりやっている、パッチしたり、コードを書いたりして貢献がどんどん増えていくと、信用は増えていくと思うんですね。
でも、信頼は相手が頼ってくれるかどうかなので、やはりそのチームのほかのメンバーに信頼するスタンスがあるかどうかがすごく大事。だから、自分自身が相手を信頼すると相手もそうなっていくんだと思っています。
司会者:ありがとうございます。ご質問をくださった学生さんも、ありがとうございました。
鈴木:ありがとうございます。
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
限られた時間で成果を上げるドイツ式仕事術
2025.01.21 - 2025.01.21
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29