2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
川口耕介氏(以下、川口):今日はカルフォルニアからお届けしています。僕はなんだかんだ言ってアメリカに20年ぐらい住んでいて、その内15年間ぐらいはずっとソフトウェア開発の生産性について取り組んできました。
さらに直近の10年ぐらいはCloudBeesという会社でJenkinsとか、そういう感じでいろいろソフトウェア開発をしているみなさんを助ける機会に恵まれてきました。その中でいろいろ考えることもあって、Launchableという会社を作ったのですが、みなさんテストを書いているからわかると思いますが、「テスト時間掛かる問題」というのがあるじゃないですか。
ここ1年はそれに取り組んでいます。Launchableでは、日本で技術者のチームを募集しているので、もし興味がある人はメールアドレスとかにご一報いただければと思います。
それで僕の中ではずっと、ソフトウェア開発はどんどん大事になっていって……。ちょうどあれですよね。以前、東京証券取引所のシステムが落ちていましたね。ソフトウェアが回らないとそのうち本当に人死にが出るなと思っていたんですけど、どうやってそのソフトウェアの品質を保つか、みなさん苦労されていると思います。
特に僕の中ではCloudBeesでもLaunchableでも、メインの部分の主戦場はアメリカとヨーロッパですが、日本のソフトウェア開発についても何か手助けしたい・手伝いたいとずっと思っています。特に、故郷に錦を飾りたいなと思って。CloudBeesのときはいろいろやっていたのですが、なかなかうまくいかなくてそれがどうしてなのかな? といろいろ考えていたんですね。
その中で1つ最近思うようになったのは、ソフトウェア開発というのは文化であるということ。なぜ「文化で」と言っているかというと、文化というのはいろいろお互いにつながりあった習慣から成り立っている1つの巨大なシステムなので、その文化の一部だけを取り出してどこかに移植しようとしてもあまりうまくいかない。そういうことが起こっているなと思ったんですよ。
僕が子どもの頃は日米自動車貿易摩擦というのがあって、アメリカの自動車会社が日本に「どうしたの? アメリカの車をもっと買え」と、「うちらの車が売れないのはおかしいだろ」みたいな話をしていました。でも、日本に住んでいると、「こんな大きい車はそもそも日本の道路では走らないし、停めるところないからうちじゃ売れないよ」とか思うわけですよ。
これが良い例だなと思います。車だけ見ていると「これが売れないはずないじゃない?」と思うんだけど、それを取り囲む全体の文化がシステムの一部だと思うと、例えば道路事情とか住宅事情とかそういうのをセットで考えたら、これだけ取り出してもうまくいかないよなと、なんとなく納得できると思うんですよ。
そういうことがソフトウェア開発の世界でも起こっているような気がして、僕はこの20年間アメリカのプロダクト開発に関わってきたので、ある種のソフトウェア開発文化みたいなのが存在すると感じています。幸いそれを近くで見ているので、それをお伝えできるんじゃないだろうかと。
逆に僕は日本であまりソフトウェア開発をした経験がないんですけど、それでもやっぱり日本には明らかに違うソフトウェア開発文化が存在しているなというのもわかる。文化が違うので、その一部の習慣だけを取り出して模倣しようとしてもうまくいかないということが現に起こっていると思っています。どちらがいいという話ではありません。
そういうことを言いたいわけではないんですけど、その「違う」ということをわかってもらうのと、アメリカ的なソフトウェア開発文化がどうできあがっているのかというのは、僕がお伝えできることなんじゃないかと思ったわけですね。
先ほど言ったようにその文化はいろいろなものから成り立っているので、どこを最初に説明するかが難しいところなんですけど、僕の中では便利どころをProduct Mindsetと呼ぶんですけど、ソフトウェアは生き物みたいなそういう感じの視点があって、それが一番の根幹なんじゃないかなと思うんですよね。
例えばサービスを作っている会社だと、たぶん生き物感がわりとあって、毎日ちょっとずつお世話をして少しずつ成長していくみたいなのがわかっていくのが感じられると思います。最近はビデオゲームとかもそうだという話を聞きました。リリース初日はむしろ戦いの始まりで、そこからユーザの反応を見てゲームをどんどんいじっていくのが、ゲームのビジネス上の成功の秘訣であるみたいな話を聞いて「そうかそうか」と。
それも生き物ですね。その昔のファミコンとかの時代はカートリッジだったのでリリースしたら終わり。あるいはCDに焼いたら終わりだったんですけど、そういうのじゃないんだなと。オペレーティングシステムだって今は毎日・毎週パッチが上がってくるわけですから、それもいわば生き物みたいなものだし。
そう思うと最近こちらで僕はProduct Mindsetと、ソフトウェアを作るというのは子どもを育てるような感じの活動で、そのために家事をしている。そんなふうに捉えている方が多いかなと思いました。それがたぶん一番大事な根底だと思うんですね。そうするとソフトウェアは1か所に留まることがないし、動かしておくだけだってコストと手間がかかるし、ちょうど人間が毎日ご飯を食べないといけないのと同じようなものです。
常に変化し続けるということになるので、そうするとその変化こそが本質だという話になるじゃないですか。ここのみなさんに僕はアジャイルなんて偉そうに語れることは何もないわけなんですけど、その辺がたぶんアジャイル的な考え方の根幹につながってくるんだと思うんです。できるだけ小さい、できるだけ小さなループの反復でソフトウェア開発を捉えるという、そういう考え方ですね。
そうしたほうがソフトウェア開発におけるリスクが小さくなるという知見があって、あまりに広く共有されているので、もはや僕はこれは「ソフトウェアの行為」と呼んでいいんじゃないかと思うんですけど、こういう考え方に自然と育児と結びついていくと思うんですよ。
その次の一歩をどうするかということに集中していて、それによる目先の変化はなんなのかと考えるというのがProduct Mindsetから生まれる自然な発想ということになると思うんですね。
このProduct Mindsetを体現する育児の総責任者みたいな人の職種があって、プロダクトマネージャーというんですけど、これも僕の印象ではずっとアクティブなソフトウェア開発における中核的な役割を担うようになったのは、ここ10年ぐらいの話なんじゃないかなと思うんです。
だから一方で明日のご飯も食べないといけないし今日の宿題もやらないといけないしという短期的なゴールと、その一方で5年後はどこかの高校に受かっているとか、どこかのいい大学に入っているとか長期的な視点もあるじゃないですか。
それをどうやったら両方ともバランスしていくのかということを考えていかないといけなくて、明日の宿題も大事だけど5年後のことも大事。そのトレードオフをするみたいな。そういうことをやる仕事だと僕は思っているんですね。あとはお客さんへのインパクトを先に考えて、そのためにどういう順番で何を作っていったらどれだけビジネス上の大きなインパクトを出せるか、そういうことを考える必要があるじゃないですか。
それから、子育てというのは子どもも育つんですけど親が育つというのもあるじゃないですか。要するに子どもの5分先を行っているような感じで、昔は「大人って立派だな」と思っていたんですけど、実はそんなことなくて本当にちょっと先を行くだけなんですよ。
ソフトウェアプロダクトもそれぞれのプロダクトがぜんぜん違うし個性があるし、挙動とかもぜんぜん違いますよね。だからその子どもが、ソフトウェアが育つ周りで親が育っていくというのがとても大事で、だからその子どもに特有の、ソフトウェアに特有の知識の蓄積みたいなのが進まないといけない。その蓄積された知識に非常に価値がある。その知見があるから次のソフトウェアの改善ができていくということがあるんですよね。
それはやっぱり技術についても育児と同じようなことが言えると思っていて、だからそう考えているのでプロダクトマネージャーとか技術者とか、社員で雇用しようと基本的にはずっとやってもらうための役割みたいになっていて、だから教育とかそういう投資の対象にもなるし。
なぜ日本ではエンジニアの多重下請構造とかになるのかなとずっと気になっていて、いまだに僕はそれに興味を持っていてその答えを探し求めています。よく解雇規制がという話をする人も多くて、それもそうなのかもしれないですけど、じゃあこっちでそんな簡単にエンジニアの首をバサバサと切れるかと言ったら、まあそんなことはないですよ。
だから本当にそれだけなのかなというのが、僕としては今ひとつ納得しきれていないです。でもその契約形態とか雇用形態とか育児の関わり方みたいなのが違うというのが大きな違いかもと僕は思っている。それからあとは社員や働く人のインセンティブが何かというと、親のインセンティブが何かというと、必ずしも働く時間ではないんじゃないかなと僕は思っている。
むしろその結果へのインパクトだから、育った子どもがどれだけ大きなインパクトを社会に起こしてくれるかとか、あるいはビジネスに起こしてくれるかに興味があります。プロダクトの成功が次の社内の商品につながっていくというのが、時間で表れるとか成果物に対してお金を払うみたいなものとはちょっと違う文化を生む1つの理由になっているのではないかなと思うんですね。
なので「子どもが」「子育てが」という話をずっとしているんですけど、ソフトウェアプロジェクトというのはうまくいけば成功してけっこう長生きするじゃないですか。この辺でも10年、20年続いているプロダクトがいろいろあるわけですけど。でも親のエンジニアたちやプロダクトマネージャーたちはフルタイムの従業員で、そんなに長くは同じ会社にはいないですよね。
だから親のチームとしては長生きするんだけど、それを構成する個人個人はけっこう出入りが激しい。でもチームとしての一貫性というか一体性というか、それが一続きに続いていかないといけないという現実があるので、自然と属人性というか、その人にしかできない何かを排除していかないといけないなということになりますよね。
だからそういう論理のつながりで、知識あるいは知見を「集団的知性」と書いたんですけど、学んだこととかを個人の頭の中に留めるんじゃなくて、チームの中にどんどん還元して共有化していく必要がやむを得ず生まれるということなんじゃないかなと思うんですよね。
(次回につづく)
関連タグ:
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05