00:00
国明さん、今日はちょっといつもと違う感じのことを話したくてですね、これまでいろんな話、考え方だったりとか、国明さんの考え方だったり聞いてきたかなと思うんですけど、
今日はそんな国明さんでもですね、こんな失敗いっぱいしてるんだよみたいなのを、これを聞いてる皆さんにですね、知ってもらいたいなと思ってまして、
失敗した話をしていきたいんですよね。で、今までこれ失敗したなみたいなのってあったりしますかね。
もちろんいっぱいありますよ。で、もちろん小さい失敗もあれば大きな失敗もあるんですけど、いずれにしても共通して言えることは、チャレンジしないと失敗しないってことなんですよね。
だから、私は結構チャレンジをいろいろして、今考えるとすごいしょっぱいミスで失敗したなっていうものもあるし、そうじゃないのもいっぱいある。
でも、打席にはずっと立ってたと思っていて、だからこそいっぱい失敗があるんだと思うんですよね。なので悪い言葉とは受け止めてないんですけどいっぱいあります。
なんかめちゃくちゃいい感じのことを言ってる感じがしますね。とりあえずチャレンジをしないと失敗もしないよねっていう話かなと。
そうですね。
じゃあそんな中でなんか、今まででめっちゃ失敗したなみたいなの具体的にどんなのあったりするんですか。
よく鉄板で話すのは、再発防止ミーティングに呼ばれて出てみたら、あのちょっとなんか品色を買ったらしくて出禁になった話がありますね。
なるほど。再発防止ミーティングというと、何らか障害が発生して、それのポストモーティング的なものを決めるミーティングがその後開催されたって感じなんですかね、シチュエーション的には。
そうですね。当時起こっていたのは、あるプロジェクトがすごくインシデントをいっぱい起こしていて、それで経営層から何とかしてほしいっていう依頼が来て、
そこから巡り巡って私にその再発防止ミーティングを出て、ちゃんと再発防止できる状態にしてほしいっていう依頼が来たっていうのがことの発端なんですよ。
なるほど。その当時は社内の基盤的なチームにいたんでしたっけ。
そうです。
だからあの再発防止ミーティング、ある特定のチームの再発防止ミーティングにちょっと出てくれないかみたいな感じになったってことは。
なので、そのプロジェクトに最初から参加してたわけじゃなくて、後から、しかも必要になったタイミングで呼ばれたって感じなんですね。
ただちょっとだけ付け加えておかなきゃいけないのは、全ての人が私に来てほしいと思っていたわけではないということなんですよ。
難しいですね、それは。
それはつまり、経営層の思惑としては誰かが何とかしてほしいっていうんだけれども、チームの中は俺たちで何とかするって思ってたってことです。
あーなるほど。上からはちょっと手こいでをしてほしいと思ってるんだけど、現場のチームからしたらいやいや俺たちで何とかできるのに、他のチームの人渡してきてなんだよみたいな感じになってたってことか。
最初からよくよく考えてみればそういう状態だったなと思っていて、でそこで私がちょっと再発防止ミーティング実際出てみたんですよ。
出てみて、で10分か20分間ぐらいは多分私聞いてたんですよ最初は、様子見してたんですね。
ただ、そこで出てくる再発防止の内容が頑張りますとかダブルチェックしますとかチェックリストしますみたいなことを言ってて、これはダメだなって思っちゃったんですよね。
03:05
なるほど、いわゆる運用でカバーみたいな感じですかね。
運用でさえもカバーできないんじゃないっていう感じでやってて、これ私が大学院の時代の時にこういうふうに人はなぜ失敗するのかっていうことをよく研究室にいたので、
まさにそれと同じ固形が繰り広げられていて、これはダメだって思ったのをよく覚えていますね。
なるほど、そんな時にそういう状況だとは分かってなかったんですかね。
分かってなかったですね。
その時は。
あの時は脳天気に何かいい再発防止策とか出せたらいいなーって思う具合で出てたわけです。
なるほど、自分のミッションに忠実だったってことですよね。
そうですね。なんだけど、情勢はもっと複雑で、再発防止策が再発防止になってなかったっていうのがやっぱりすごく一番深刻だなって思っちゃったんですよね。
私がなんか例えばこういうシステムで開発防げますよとか、リント作ったらここを防げますよとかっていうレベルの問題じゃなかったっていうのが見込み違いのうちの一つだったんですね。
もうちょっと根本的なところが。
つまり再発防止してるつもりなんだけど、それができてないって。
再発防止がどういう風にしたら再発防止になるのかっていう知識を持ってる人がおそらくいなかったっていうのが一番の問題だったんだと思いますね。
前提知識がちょっと揃ってなかったというか。
そうそう。で、再発防止ミーティングって実はすごく難しいんですよ。
これはあまり知られてないことだと思うんですけど、NASAでさえこういう風な大失敗みたいなことをよくやらかすわけですね。
チャレンジャー号とかのやつとかもそうでしたよね。
スペースシャトルが発射と同時に爆発しちゃって、同乗員と一緒になくなっちゃったみたいなものとかってのがありましたけど、ああいう大失敗っていうのをやらかすんですよね。
その時に再発防止とかをいろいろするんだけど、それ時にやっぱり結構難しかったりとかするんで、彼らはすごく強硬な手段を取ったりするんですよ。
だけど、例えばミッションルーム閉鎖されますよね。
誰も逃げ出さない。誰も持ち出せない。隠せない。
なるほど。
そこまで厳密にルール化しないと人間は再発防止ちゃんとできないんですよ。NASAとかでさえそう。
強制力を発生させないといけない。仕組みで発生させないといけないってことですよね。
そうです。なので、そうじゃないと人間どうしても手心を加えてしまうというか、頑張ればなんとかなると思っちゃうんですよ。
具体的にはチェック項目を毎回チェックするみたいな感じだと、何回いいと思うからチェック入れとこうかみたいな感じになっちゃうってことですね。
よくダブルチェックとかトリプルチェックで、前の人がチェックしたと思うからよし!みたいなとかってあるじゃないですか。
ありますね。
ああいうのとかっていうのがやっぱあるわけですよね。なので、ここで言いたかったのは、再発防止っていうのは難しいんだよっていうのがあって、
それがなかったチームにいきなり飛び込んだ時に、その人はどういう言動をすべきかっていう、そういう問題を私は解かなきゃいけなかったんですよ。
私はそれに気づいてなかったんですね。
ちょっと難しいですよね。どっちかっていうと、若干マネージャーみたいな話も入ってきてるのかなと思ったんですけど。
06:02
で、例えば私の性格的に、結構ズケズケ言うというか、まっすぐ、ごまかしなく言うことが多い。
ストレートに行きますよね。
ストレートに行っちゃうんですよね。これがすごく悪い方向に働きました。さっき言った通り。
根回しなくストレートに言うって感じですよね。
まず、チームの中ではチームで何とかしようって、俺たちは何とかできてるっていう気持ちがあった。
だけど、その中に人が入ってきて、しかも外部の人がいて、で、ズケズケそれを物言ってくる。
その状況に中の人が耐えられなかったんですよね。なので、私はできん気になりました。
なるほど。ちなみに、その時、再発こんな形で防止していくといいですよっていう具体的なことを提案したのか、
それとも、いや、そういう考え方自体の話をしたのかどっちなんですか?
まずは考え方自体の話ですね。
まず、我々は再発防止策がちゃんと再発防止できるようになってないと、
ステークホルダーに対しても顔向きができないっていうニュアンスのことをまず話しました。
つまり、再発防止策がちゃんと再発防止になってないといけないんだよと。
なんだけど、この今話されてる再発防止策を聞いていると、再発防止できるにはあまり思えないと。
そういうふうなことを言いましたね。
なるほど。じゃあ、具体的なアイディアというよりかは考え方というか、これだったらちょっとダメそうだから、
もう一回整えないといけないよみたいな話をした。
そうですね。
その時、反応どうでした?
反応、死因ですね。
死因だったんですね。
カメキ、厳しい。
だから、死因は、私はその時に無神経だったんで、みんな考えてるのかなみたいなこと思ってたんですけど、
たぶんあの時の死因は、こいつ何言ってんだみたいな死因だったんでしょうね。
は?みたいな感じですよね。何?みたいな感じですよね。
そうなんです。私はだから、つまり自分の失敗にまず気づいてないっていう大失敗を犯して、
そのまま続行みたいな感じになって、
私自身は最終的に細かい改善提案みたいなのを出せたんで、システム的に防止する方法とか出せたんで、
ぼちぼちうまくやったかなと思ったら、後々ちょっと経ってからDMで、
あなたは再発防止ミーティングにもう来ないでくださいというDMが来ました。
すごいですね。
ちょっともうちょっとそのミーティングの状況というか、何というかなんですけど、
呼ばれたわけじゃないですか、くにわけさんはどちらかというと。
で、そのチームの中のリード的な存在の人は、さすがに呼ぶみたいな感じだったんじゃないですか。
それがですね、どうもそのリーダーを通してない指揮系統から私が派遣されたようなんですよね。
で、もうアウェーじゃん、そのミーティング。
完全アウェーですね。私それ知らなかったんですよ。
で、それで知ってても多分失敗したんじゃないかなとは思うんですけど。
そういうのがあって、つまり特別問題が異常に難しかったことに私は気づいておらず、
09:00
爆弾をいっぱい踏み抜いたんですよね。そうっていうのが起こったことでした。
なるほど。それ1回だけ参加して、もうデキになっちゃったんですかね。
それでデキになっちゃって、でその後、いやいやさすがにちょっとおかしいでしょって私が例えば、
なんか誰かの品質を買ったのかなんだのかわからないが、
何かやばいことをやっちまったのはわかったんだけど、
でもうちも品質が良くないっていうふうなミッションをなんとかしなきゃいけないわけで、
それはちょっとなんとかしなきゃ、結局私をデキにしたところで解決するわけではないっていう趣旨のことを確か言った記憶があるんですよね。
1回のミーティングに参加して、それでデキにDMが来た。
はい、デキにDMが来て。
1回だけなんですね、じゃあ。
1回だけなんですね。
ミーティングをやった。でその後、いやこのデキにされたところで別に品質改善されてないですよみたいな。
そうそうそうそう、それで品質が改善されるわけじゃないから、やっぱり状況としてはまずいですよっていうふうなことを説得して、
でちょっとここは私すごく釈然としてないんですが、その後すぐにデキが解除されました。
なんで?
なんでって思いましたよね。だからデキにする判断も浅いし、そのデキを解除する話も浅いんで、なんでっていうのはちょっと。
難しいですね。
覚えてますね。だから。
多分知らないとは思いますけど、デキに判断した人誰なんですかね。
多分ある人がなんかクレームつけたんじゃないかなって、これはちょっとごめんなさい、座席なんで。
座席さんね。
そう、わかんないんですけど、たぶん強烈になんかそのあの人がいても再発防止が良くならないみたいなことを強行に主張した人はいるんじゃないかなと思って。
まあ意味ないんじゃねみたいな。
そうそうそうそう。
なるほど。そういったのがあって、ちょっとデキになっちゃったっていうのが。
そうなんですよ。で、私がさらに釈然としなかったことが1個だけあって、私と全く同じことを別の人がさらに呼ばれてきた人がいたんですよ。
で、その人はただそのチームの中だと権威がある人だったんですよね。
その人が何やってると思うやらみたいな感じで、その行った時にはみんながうんうんそうだねみたいな感じで、デキにはなりませんでした。
直属の上司みたいな感じですかね。
直属の上司ではないんだけど、よくあの人は腕利きだってことが知られていて、
なるほど、社内で。
そうそうそうそう。ベテランだってことが知られていた人だったんですよね。私はたぶん無名だったと思います。
だからあれですよね、もうその時に信頼関係があったんですよね、そのチームと。
そうなんですよ。それがこんなに結果の違いをもたらすのかっていう風になるので、私はこう勉強になりましたね、とっても。
いやでも、非常に重要なことですよね。どんなに正論なことであったとしても、やっぱり信頼がないと受け入れられないですもんね、人って。
そうなんですよ。
なんかめちゃくちゃいい気づきかなと思うんですけど、ちなみに今だったらどうします?
今、実は最近も似たようなことが1回だけあったんですけど、あの時はまず寄り添うにしましたね。
チームに寄り添って。
チームに寄り添う、まずそう。
12:01
一発目で反発しない、反発というか。
一発目でかまさないってことですね。
手の内で明かすようですごく恥ずかしいというか、サイコパスみがあるんですけど、やっぱり一番自分がこうした方がいいっていう風な意見を受け入れられるためには信頼が必要で、
信頼ってどういう時にできるのかっていうと、やっぱりこの人は自分のことわかってくれるんだって思ったりする瞬間ですよね。
受け入れてくれた瞬間ですよね。
そうそうそうそう。だからやっぱり相手のことをよくまず聞く、置かれてる状況を理解するっていうのがすごく大事で、
なんで私はその似たような状況になった時には、まずあなたの置かれてる状況はこういうことですか?だからこういう決定をしてるんですか?っていう風なことをまず最初に訪ねていって、探り探りに行きました。
結果的に、そう。そんな感じですね。
すごい重要ですね。やっぱり寄り添って、信頼をまずはチームの中の信頼、現場の信頼を勝ち得た上で徐々に提案していくっていう。
そうですね。はい。
めちゃくちゃ非常に重要なムーブで、しかもなんとなくの、これは僕の偏見なんですけど、
強いエンジニアが陥るちょっとしたムーブというか、難しいところとして、やっぱり力でいくところがあるなぁと思うんですね。正論で殴っていくっていうスタイル。
まさかりをね、投げてくるみたいな。そんなことあるかな、結構あるかなと思うんですけど、やっぱりチームの人たち、それを受け入れる側の人たちからしたらね、
ちょっとなんだよみたいな感じになっちゃうんでね。そこはやっぱり信頼を勝ち得てからというか、なんていうか、結構難しいですよね。
そうなんですよね。で、今も昔も変わってないのはフォワットなんですよ。つまり開発部署はこうあるべきだとか、今の状況を打破するにはこうあるべきだっていう思いは変わってないし、
その部分は今も共通してるんですけど、変わったのはハウだけなんですよ。それをどう伝えるかっていう部分だけなんですよね。
そこの部分が大事なんだって気づいたっていうのがその失敗の教訓ですかね。
めちゃくちゃいい気づきですね。他の失敗とかあったりしますか。
他の失敗だと、そうですね、これはちょっとコミュニケーションの話なんですけど、Gulpって覚えてる人います?JavaScriptの、ちょっとこれは老人会みたいになりますけど、JavaScript老人会になりますけど、
当時、JavaScriptって一つにまとめるといいよねっていう話があって、複数のやつになるとHTTPのリクエストがいっぱい飛んじゃって、しかも6並列までしか1ホストできないから時間かかっちゃうよねとかって話があって、
なので一つのJavaScriptにまとめるバンドラーって呼ばれてるものがあったんですよね。その一番初期の頃、一番初期と言うとちょっと語弊があるな。
結構バンドラーとかが流行ってた時期に、グラントっていうものが最初流行って、その時にグラントはダメだ、Gulpだって言って出てきたのが、この成り物入りで出てきたGulpってやつがあったんですよ。
これは今で言うとWebpackみたいな位置にあるようなやつで、ただ役割としてはメイクファイルみたいなことをやろうとしていたようなツールだったんですよね。
15:10
それをJavaScriptで書けるみたいな感じのやつだったんですけど、私はそこにコントリビュートをしたんですね。こういうのに付け加えたいんだけどっていうふうにコントリビュートをしようとして、
で、レビューありがとうって、ここの部分は自分たちのプラグインで実現するからね、ありがとうね、これまでのレビューありがとうってつもりで言ったんですよ。
英語で言うと最後にサンキュー、サンキューってなるわけですよね。で、サンキューって実はありがとうって意味じゃなくて、よろしくって意味になるときがあって、
たしかに。
私がレビューしてくれみたいな感じの意味に捉えられちゃった。
なるほど、逆の意味というかちょっとニュアンスが違いますね。
そうそうそうそう。サンキューに自制がないんですよね。だからこれは過去のことに対してありがとうって言ったつもりなのか、
それとも、よろしくみたいな感じで言っちゃったのかっていうのに区別が私にはついてなかったんですよ。
で、送ったら、は?俺にレビューしろって言ってるのか?みたいな感じで、マジでこんな感じのトーンで言われて。
すごいな。
そう、アガルブの人はマジでそういうトーンできますね。
なるほど。じゃあ、その時どうしたんですかね。それいつ気づいたんですかね。そうやって怒ってきたから、なんで?みたいな感じで。
え?なんで?ってなって。で、なんで気づいたのかな、サンキューがよろしくって意味になったのか。ちょっとよく覚えてないんですけど。
ただその時は必死に拙いなりの英語で、私はまず英語噂じゃないよっていうのを伝えた上で、その拙い英語でなんかちょっと申し訳ない感じのことを言ったかもしれないが、
言いたかったことは、確かI appreciate youみたいな感じのサンキュー以外の言い回しで別に伝えた。
そしたら向こうはそうみたいな感じで終わったんですけど、あの時に言語って怖いなって、ネイティブにその態度で来られるとこっちはすげえ萎縮するっていうのはすごく思いましたね。
難しいですね。ちなみにガルプの作者の方は英語ネイティブなんですかね。
英語ネイティブの人ですね。
難しいですね。
難しいですね。
これが英語ネイティブじゃない動詞で英語だったら多分問題なかったと思うんですよね。
問題なかったと思いますね。はい。
いや、英語ネイティブのそういう難しい細かい表現みたいなところまで求められてもなというのが気持ちかなと思うんですけど。
そうですね。ただ教訓としては、サンキューは怖いって思いましたね。
もうちょっと具体的に書くべきであるっていうことですね。
ちゃんと理性が入るような書き方をした方が誤解が少ないんだろうねっていうのが教訓ですね。
いやでもなんか何となくなんですけど、僕の経験上もギター部で英語のやり取りするときに何となくサンクスとかセンキューとか入れてる気がしますね。
そうそうそう、あれ結構私は危ないなと思うんですよね。
いや難しい。ネイティブにどう捉えられるかこっちは分かんないですもんね。
ただ今だったらセーセーアイとかにこれどういうふうに捉えられる可能性あるとかって質問できますからそうするべきっていうのはきっとあるかもしれませんね。
18:05
文脈ちょっと読み取ってもらってね。
そうそうそうそう。
ちなみにこれはガルプの作者の方にガルプにコントリビュートしていくっていうチャレンジの中で怒りに触れたっていうような感じかなと思うんですけど、
今やるんだったらちゃんとGPTとかGeminiとかにちょっと聞いてちゃんとフィルタリングするみたいな感じなんですかね、じゃあさっき言った通り。
そうでしょうね。それが多分一番簡単で、あとはやっぱり私はサンキューを使わなくなりました英語研で。気軽には使わなくなりましたね。
それは文章でってこと?
文章でってことです。サンキューって言い方をしないで、ちゃんと時制がわかるように、私はあなたに感謝しているとかしたみたいな感じの言い回しをするように変えましたね。
確定させるんですね。
そうそう。やっぱりね、自然英語って複数通りの読み方ができちゃうっていうのがやっぱり結構弱いところだと思っていて、そこをなるべく狭めるっていうのはコミュニケーションのコツだよねって思うんですよね。
重要ですね。特に文章ですよね。音声だったら音声というか、電話とかだったら、電話とかZoomとかだったら、なんとなくわかると思うんですけどね、声のトーンだったりとかそういうので。ただ文章だとそういうのないですからね。
そうですね。ただ、私の拙い英語は向こうも伝わってたんじゃないかなと思うんですけどね。
ネイティブじゃないってわかってるから何か汲み取ってくれよという気持ちも。
そう、それはちょっとある。
なんとなくあるけどまあまあでも。
ただ、向こうも向こうでそれ以外にも取れないじゃんって思ってた気がするんですよ、あのいつの間にか。
それはそれでねえって。
難しいですね。
難しいなって思いますね。
じゃあ今の話は英語での失敗なんですけど、他にも何かあったりしますか。
他にもありますね。これは結構私のその設計に関する現体験のうちの一つなんですけど、私はその学生の頃からテストを書くような珍しい学生で、
で、その時学生当時いろいろ共同開発して作っていたものが1個あるんですね。
それについてもテストいっぱいしていて、カバレッジをなるべく上げるためにいろいろな工夫をしていたんですよ。
ただその時はそのコードの声が聞こえてなかった。私はその設計の時によくテストするときに変だったらコードの声を聞くんだよみたいな話をしたと思うんですけど、その当時は声が聞こえてなかったんですよ。
それの結果何が起きたかというと、Mockとかパッチって呼ばれてるそのメソッドをこう上書きするみたいな感じですね。
とかっていうのを多用したテストを書いたんですね。
なるほど。Mockしまくって。
Mockしまくった。そしたら共同開発者からお前のテストは読めんって言われて怒られたと。
でもちゃんと共同開発者の方、その時同じ大学生ですかね。
もう覚えてないですね。相当何年前?20年前とは言わないけど、でも20年前近いですからね。よく覚えてないっていうのが本当のところですね。
21:03
その相手の人はリアルな知り合いとかではないっていう。
はい。
そんな感じなんですね。っていう方からちゃんと指摘してもらえるっていうこと自体なんかいいことかなとは思いますけどね。
そうですね。個人的にはすごく率直に言ってもらったことは私の助けになっていて、ただあの当時の私は少し反感を覚えていたのも覚えてます。
テストするなってことかよみたいな。
すごいなんかカミソリみたいな感じ。キレキレの。
なるほど。じゃあもうガチガチにテストした方がその時は良かったと思ってたんですよね。
そう思ってたんですよ。
ちゃんと動くというかもうすべからくカバレッジは100%であるべきだみたいな。
まあまあ100%とまだ言わなかったですけど、でもそれでもやっぱりこのメソッドを確かめるためには文句しまくるしかないでしょみたいな感じで思っていたのをよく覚えてますね。
その考えが変わったのはいつなんだろうな。
あの当時は私テスト駆動開発やってなかったんですよ。
これあの苦言を呈されたときには思い直さなかったんですね。
思い直さなかったと思いますね。
その時どうしたんですか。
いやなんで、その時私単にそれがプルリックが回しされなかったんじゃなかったかな。
それが機能追加みたいなのしたつもりなんだけど、そのテスト読めないみたいなので回しされなかったんだと思いますね。
っていう感じで、つまり私のサブは虚空に消えたみたいな。
クローズされたってことですね。
クローズされたっていうことですね。
っていうのがありましたね。
で、その考えがいつからかちょっとずつ誘拐されてて、今逆の立場だったらどう思います。
逆の立場だったら、解決策を私だったら提示しますね。
その当時読めないっていうのだけは、それは現象としてはそうなんですよ。
なんだけど、じゃあそっからどういうふうにしたらいいのかってことを手助けをしてあげると、
よりいいサブが出来上がるまでの時間が短くなりますよね。
だから手助けができるようになったら手助けをした方がいいっていうのは思いますね。
その当時だったら、テストがちょっと過剰だからちょっとずつ削っていってみたいな。
私ですね。ごめんなさい、相手の気持ちになっちゃった。
私だったら設計直しますね。
あれは確実に設計のスメルでした。
今だったらそんなことはしないっていうような感じですよね。
今だったら速攻設計直しますね。
ちゃんと行動の声が聞こえてるからって感じ。
そうなるとテストは自明になるんですよ、ほぼ。
こういう流れのテストでそうそうこうなるこうなるっていうのにしかならないんで、
そうじゃないテストになってるときはやっぱり怪しいっていうのが大事なんでしょうね。
なるほど。
共同開発者の方はそれ以降かなみだったりとか一緒に開発したりとかってあるんですか?
24:03
特にないですね。
じゃあもうその時に、共同開発者っていうかギターオフのオープンなリポジトリでやってるみたいな感じ?
そうそう、まあその時はクローズドだったかな、ちょっと覚えてないですけど。
じゃあまあ何らかのプロジェクトでって感じですね。
そうですそうです。で、それ以降は共同開発その人とはやってないと思いますね。
なるほど。
まあちょっと国明さんのもっくしまくる時代もあったって感じですね。
そういうことです。
なんかそういう時代があるからこそ今の考えに誘いつけてるっていうことでもありますよね、きっと。
一回経験してるっていうのはあるなと思ってて。
あると思いますね。ただ、一番やっぱり私に重くのしかかってたのは、
そういうすごく効率の悪いテストをたくさん書くってことが重りになって、
機能追加がすごく時間がかかるようになっていくフラストレーションがあったんですよ。
その結果として機能追加がすごい時間かかるというか、重いタスクになってしまっていったという経験があるってことですよね。
経験があるですね。
それに白車をかけたというんですかね。つまりそのフラストレーションに白車をかけたわけですよ。
読みにくいってさらに言われてしまったと。
っていうのがあって、何か間違ってるんだってことはうっすらと分かり始めたんですよね。
ただそれがどうしたらよかったのかっていうのは当時は分かってなかったですね。
そこからいろんな経験していく中で今の考えに消化されていったってことですもんね。
そうですね、はい。
いい苦言を呈されたタイミングでありつつその時に訂正できるものでもないっていうような話ですね。
そうですね。もしあの頃に単体テストの考え方って本が読んでいればきっと考え方が変わったんだろうな。
そういう本がまだなかった時代なんですよね。
なるほど。難しいですね。
このテストの話もできたんですけど、他に何かあと1個ぐらい話せればいいかなと思うんですけど、何か失敗あったりします?
そうですね。できるか分からないことをできると言ってしまって追い詰められた話っていうのはあって。
なんか怖い話ですね。
そうですね。ただ多かれ少なかれほとんどのことはできるかできないかが分からないまま引き受けることがほとんどだと思うんですよ。
多分できるだろうなって思うけど、多分できるんだろうなっていうのは不確実なわけですよ。
それは技術的なことですかね。
技術的にもそうだし、農機的にも技術的な部分に含まれるんですけど、この農機で作んなきゃいけないっていう賞味期限ってやっぱりあるわけで。
スケジュール的な問題ですね。
スケジュール的な。その賞味期限内にまだできるかなと思ってやってみたんだけどできなくて。最終的にプロジェクトはポシャったんですけど。
でもこれ、できるか分からないことできると言ってしまうみたいな。ある意味このタスクの見積もりを失敗したみたいなことかなと思うんですけど。
ちょっと理由とは違うかもしれないですけどね。ことかなと思って。で、よくあり得る話なんじゃないかなと思って。
27:07
タスクの見積もりをミスるなんて普通というか。
普通ですね。それは普通、本当に。で、その当時作っていたシステムっていうのは、C++で書かれている、何て言ったらいいんだろう。
ゲームエンジンがあって、そのゲームエンジンにリモートログ機能をつけようとしてたんですよ。
リモートログっていうのは、実際のマシンで動いていたりとか端末で動いているところからログが大量に出てるわけですよね。
それをサーバーに送信をして、それを集計して統計とかを取ったり、こんなエラーが最近出てくるようになったよ、来たよとかっていうのがわかるようにする。
それが目的としてあったってやつなんですね。
なんでそれ自体を聞くと、機能的には単にログのアペンダーとか言われてるものあるじゃないですか。
ログのどこに書くか、ファイルに書くか、それともコンソールに書くかみたいなのを決めるところに1個モジュールを追加して、それをサーバーに送ればいいっていうだけと思ってたんです。
なんとなくそんなイメージは聞きますよね。ちょっと要件次第かなとは思いますけど、なんか外部からの通信があったらログを吸い出すとかじゃない限り、自発的に全部すべて送るみたいな感じだったらそんな感じですよね。
すべて送るっていうつもりで。なんで送るのもそんな難しいことはないしって思ってたんですけど、こっからですね、地獄の旅が始まるんですよ。
これは、私がC++っていう言語を舐めてたっていうのも1つありますね。
原語的な特性もある。
言語的に。まあまあ言うて書けるやろうと思ってたんですけど、まあ言うて書けない言語でしたね、C++。
なるほど。それはエコシステム的に整ってなかったってことですか。
C++やっぱりエコシステム、その当時はエコシステム的にはやっぱり整ってなかったのか、あれはプロジェクトが整いようとしなかったのか微妙なところなんですけど。
環境的な要因もありつつも。
そうです。C++って一応マルチプラットフォームなんですけど、ここで一応って釘を刺したのはどういうことかっていうと、Windowsプラットフォームで動かすためにはMicrosoftのMSVCコンパイラー使ってやったりとか、
Appleの上で動かすにはクラン使って、Androidの上で動かすにはもうやっぱり確かにクランだったかなとか使ってとかっていうふうに、いろんなプラットフォームでコンパイラー違ったりするんですよね。
そうすると、実装依存踏んだりするんです。
それを踏んだんですね。
めちゃくちゃ組みましたね。
なるほど。
あとは、外部に送信するってときにHTTP通信とかが必要になるわけですけど、HTTP通信のライブラリーが当時組み込まれてなかったんですよ。
既存プロジェクトに入ってなかったんですね。
既存プロジェクトに入ってなかった。なので、HTTPのやつを外部依存を加えて、要するにどうにかこうにしかしてリンクして、それをすべてWindows、MacOS、Linux、iOSすべてでうまく認識されるように作る必要がある。
全部今聞いたプラットフォームって、CPUのアーキテクチャも違うし、コンパイラーも違うしっていうような状況なんですよね。
30:02
これが、まずコンパイラーがなぜこっちで通らないのかよく分からないんですよ。
C++のエラーメッセージは不親切なことで超有名ですからね。
なるほど。言語のプラットフォーム側としてアーキテクチャの違いを吸収してくれてなかったがゆえに、いろんな発行する必要性があったんですね。
ありましたね。それもいっぱいあって、もうすっごくそんな簡単なことがなんでこんな難しくなるのかってぐらい、本質的じゃないところで時間をめっちゃ食いましたね。
具体的にはあれですか、isWindowsとかそういう、入れてたとかですか。
そうそうそう、そういうのですよ。とかですね、本当にそういうのいっぱいあって。
いやかなり厳しいなと思いつつも、それはこのログを発揮出すというプロジェクト自体がポシャったという。
そうです、ポシャりました。
なくなってしまって。
賞味期限に間に合わなかったんです。
その機能自体は出すことなくって感じ。
出すことなくですね。
厳しい。
QA期間中にその機能が入っていれば、QAで起こったログのデバッグが楽になるよねっていう体裁で始めたものなんですよ。
なるほど、じゃあ開発、ログだし、そもそも開発の用途のためだと思うんですけど、
そのデバッグ、QA期間中の運用のために必要だったものだったんですね。
そうですそうです。で、QA開始に間に合わなかったってことですね。
なるほど、じゃあその後も別に使うことない、ちょっと単発的な要件だったってことなんですかね。
そうですね、単発的な要件で間に合わなかったんで、もうこれ以上追加、しかもそのプロジェクターかなり牛歩だったってことも上は見てたんで、
これ任せてもいい成果を得られないなって思われちゃったんでしょうね、きっと。
なるほど、結構個人的に厳しいですね、そういう状況に置かれると。
そうですね、ただ引きは良かったと思いますよ。
よくコンコールド効果とかって言ったりすると思うんですけど、
莫大な投資をしてしまったものに引っ込みがつかなくなってズルズルズルズル投資を、追加投資を続けていくという話があって、
それは損失を拡大しているだけなんですよね。だから足切りが早いってことは悪いことじゃないんですよね。
いや、めちゃくちゃいいですよね、だから。
もうスパッと切り上げてしまうというか、もう無理なんだったら辞めるよっていう意思決定ができるっていうのは、
その意思決定した人が結構優秀だなとは思うんですよね。
プロジェクトマネージャーなのかわからないですけど。
私はその時の気持ちは、やっと解放されるでした。
よかったみたいな。
よかった、もうつらすぎたんで。ちょっと私は学んだんですよ。C++っていう言語は難しいってことをよく学びました。
もう辞めとこうと思いました。
辞めとこう、近寄ろんとこうって思いましたね。
厳しい。でもあれですもんね、例えばUnityだったりとかUnrealとかもそうだと思うんですけど、
そういういわゆるゲームエンジンを開発しているような会社だったりとか、
エンジニアの人たちは絶対いじってますもんね、C++なんて。
33:03
ただ、その4つのプラットフォームで、しかもCPUアーキテクチャも全部違ってみたいなクロスコンパイルしてるっていうのは、
そんなに多くないんじゃないとは思いたいですね。
まあまあそうですね。でもかなり厳しかったって。
厳しかったですね、はい。
なるほど。でもまあちょっと楽しそうではありますけどね、そのプロジェクト。
あんまりやることないかなと思うので、C++でしかも。
楽しくはあったんですか、ちなみに。
理不尽さをずっと感じてましたね。
なるほど。楽しくもうなかったんですね。
そうですね。いや、あの、引っかかるところが、私の知識不足で引っかかるっていうのだったらすごくよくわかるし、
こうやるほうがよかったんだみたいなのがわかるんですけど、そうじゃないんですよね。
歴史的経緯とかにやられるんですよ。
それはCPUのアーキテクチャとか、プラットフォームごとの差異ですか。
プラットフォームごとの差異もそうだし、あとはその依存ライブラリをリンクするときのやり方っていうのがあって、
それは具体的には3つか4つぐらいのところに足さなきゃいけなくて、
Xコードプロジェクト、VSコードプロジェクト、AndroidのプロジェクトファイルとCMakeに全部足すみたいなことが必要で、
俺は何をやってるんだみたいな気持ちになったのを覚えてますね。
それはデバッグしづらいですよね、単純に。
地獄でした。デバッグはめっちゃしづらかったですね。
ですよね。難しい。
ちなみに今後の教訓として、それから得られたこととして、
マルチプラットフォームをやるときのタスクの見積もりですからね。
そういったところに影響されたりしてます。
してますね。でもあの時私が一番足りなかったのは、
経験者に見つめる効くという作業が足りなかったですね。
私一人の独断で決めちゃってたんで、そんなにあっさりいくよって、
要するに気づいてなかったんですよ、その難しさのポイントに。
既存のゲームエンジンですかね、開発してるチームの方々に聞いてたわけじゃないんですね。
聞いてたわけじゃなかったです。
じゃあ、なんとなく突っ込んでいって、なんかできそうみたいな感じでいって、
爆発したってことですね。
そういうことですね。これは完全に見積もりを失敗してる。
見積もりですね。
ってやつですね。
それこそプランニングポーカーやったらよかったみたいな感じなんですかね。
そうですね。ただあの時は、期間がそんなに長くないのもあって、
よくその、誰だっけ、岸田さん、岸田総が言ってた気がするんですけど、
早く行くためには一人で行け、長く行くためにはみんなで行けって言うじゃないですか。
あの時は早く行きたかったんですよ。
そのプロジェクトの特性的に。
プロジェクトの特性的に。
なので一人で行くっていう決断をしたんだけど、
有識者の意見は聞いておくべきだったっていう記憶になるんでしょうね、きっと。
でも、すごいうがった見方っていうか、もうちょっと上からの目線でいくと、
くりまきさん一人の失敗で終えられてよかったっていうのがあるかもしれないですね。
そうですね、それはありますね。
みんなでなんかこうやってって、みんなポシャってちょっとテンションダウンしちゃった、
36:02
みんながテンションダウンしちゃったみたいな言うのがあったら、ちょっと最悪ですもんね。
最悪ですね。
そういった面では確かに一人でやってよかった。
失敗しても、特段痛いところではなかったってことでしょうね。
現状より悪くなることはなかったですから、単にコストが無駄になったけど。
ですよね、そのぐらいってことですもんね、リソースがかかったところとしては。
そうですそうです。
じゃあまあまあ、そういうことあったらMQCな感じで終えられてよかったなと感じですね。
ただ、この話はもともとは先ほど言った通り、できるかわからないことをできると言ってしまって追い詰められた話になるわけですけど、
私は結構ね、できるかどうかわからないことをできるっていうことは大事だと思うんですよ。
こんな失敗をしといて、さらにそんなこと言うのもなんですけど。
なんでかっていうと、一番最初に言った通り、失敗っていうのはちゃんとやらせてもらわないと失敗できないんですよね。
リスクがあるから、これダメです、ダメです、ちょっとのリスクあるからダメです、ダメです、危ないでしょっていう風なのとかやってると、
マジで何もできなくなるんですよ。
なんで、やっぱり少なからず危ない端を渡って、危ない端を渡ってるって時はもちろん落ちる時もあるし、端が崩れる時もあるんだけど、
たまたま渡れるとすごくいいことが待っているんですよね。
で、なんだけど失敗をゼロにすることはできないんですよ、本当に。
だから、できるかわからないことをできるっていうことは、そう言わざるを得ないんですよね。
じゃないと何もできなくなっちゃいますから。
だから、私はやっぱり今後もできるかちょっとわかんなくても、多分できると思うんじゃないですか、やってみますよっていう風に言うと思いますね。
いや、すごく大事なことだと思いますね。
とにかく打席に立つっていうところですね。
そういうことです。
チャレンジしてみる。
で、もちろんそれで解釈が傾くような失敗をしてしまったらあれだと思いますけど、
小さく失敗していくってことですよね。
そうですね。
個人としては。
非常に重要だと思いますね。
それをちゃんと手を挙げて、本当にチャレンジしまくってっていうのが、個人のキャリアプラン的に重要になっていくみたいな感じなんですかね。
モチベーションかどうかちょっとわかんないですけど。
やっぱりね、失敗したときに一番得られるものっていうのはモチベーションっていうよりかは嗅覚だと思ってるんですよ。
このままいくとまずいなっていう。
いつもと同じやばい感じだっていうのがわかるようになるんですよ。
その嗅覚ってすごく今のPMOとかやってても大事で、これやばいなっていう兆候がわかるようになるんで。
そこが実は一番嬉しいんじゃないって気はしますね。
それは実際に経験しないとわかんないことですよね。
経験しないとわかんないです。
失敗を。
理屈じゃないんですよ。
理屈は後からつけられるんですよ。
これを一番やばいと思ったんだなっていうのがわかるんですけど、一番最初にこうもやった時よりあのやばい感じみたいな。
わかる。
それが感じられるようになってるのがやっぱり一番でかいんじゃないですかね。
言語化できない感じですね。
そう。
シックスセンスなのかもしれないけども、もうやっとするからちょっとこのままいくとやばいから、ちょっと先に相談しとこうみたいな。
そうそう。
そういえばあの時このままいってこんなことになっちゃったよね。これやばいよな。じゃあちょっと手を打っとこうかって勝手になるわけですね。
39:04
めちゃくちゃ重要な話ですね。
これを聞いているエンジニアの皆さんもあまりこうちょっと思うところあるんじゃないかなと思うんですけど、なんかあのいい感じにまとまったところでちょっと今回はここまでにしていけたらなと思うんですけど、なんかあの最後失敗についてなんかあの話しておきたいことありますか。
いやでも失敗についてね、もうみんながすごくいいこといっぱい言ってるんで、最後はもうみんなが知ってる言葉で締めたいですね。あの失敗は成功の母だということです。
めちゃくちゃ聞いたことある言葉。
ありがとうございます。
ということで今回ここまでにしたいと思います。もっと詳しく教えてください。
ラジオ歴史クワラジではスーパーエンジニアである国明さんに一般エンジニアであるヘンテコが技術的な質問をしていく番組になっています。
今後もですね、いろいろなことを聞いていけたらなと思ってますので、お聞きのプラットフォームで高評価やフォローのほうをお願いします。
またですね、こんなことを国明さんに聞いてほしいみたいなことがありましたらコメントいただけると取り上げますので、ぜひよろしくお願いします。
Xなどでハッシュタグクワラジでつぶやいて感想をお願いします。
それでは今回もありがとうございました。
ありがとうございました。
