
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
西村賢氏(以下、西村):今日は蓑輪さんこと、ヒゲポンさんということでネットでも知られていますので、ヒゲポンさんでよろしくお願いします。
蓑輪太郎氏(以下、蓑輪):よろしくお願いします。
西村:今日はだいたい大きく二つお話をお伺いしたいのですけれども、ひとつはTwitterに入られて今、どれくらいになりますか?
蓑輪:もうすぐ7ヶ月。
西村:7ヶ月。Twitterのソフトウェアエンジニアということで、その立場からごらんになったTwitter社の開発の風土ですとか、日々の業務のまわしかた、それから技術的な課題だとか、そういったあたりのTwitterに関する話をお伺いしたいのが、大きくひとつあります。
もうひとつは、ヒゲポンさん自身についてです。ご覧になってる方でご存知の方も多いかと思うんですけれども、ヒゲポンさんはOSも作られて、そのうえに言語処理系も作られて、シェルまでつくったんですよね。いわゆるハッカーということで、どうやったらハッカーになれるのか、というところをちょっとふたつ目にお伺いしたいと思います。
ひとつ目、まずTwitter側の話、入って7ヶ月ということなんですけれども、簡単に自己紹介いただけますか。現在の肩書き、役割それから所属っていうところですね。日本、米国の本社、そのへんの関係のところを少し。
蓑輪:はい、わかりました。蓑輪と申します、Twitterの中では「ソフトウェアエンジニア」という肩書きで仕事をしています。
所属しているチームは「インターナショナルエンジニアリング」というチームで、なにをやっているチームかというと、Twitterのユーザーの7割は米国外の国々のみなさんなので、インターナショナルのユーザーさんに快適に使っていただくための、エンジニアリングをやるチームに所属しています。
具体的には、いろんなことをやっているんですけれども、例えば日本の携帯、ガラケー向けのサイト運営ですとか、あとは、アラビア圏の文字を右から左にかくようなところでも、Twitterを快適に使っていただいてもらえるようなふうにしたりとか。
あとは、Twitterっていろんな国用に翻訳されているんですけれども、その翻訳するための仕組みをつくったりとか、あとは私のように主に日本語メインでTwitterのWebを日本人の方々に快適につかっていただけるように仕事している人たちも居ます。
西村:先ほど携帯とおっしゃいましたけど、日本固有の事情というのは、他にどのような。
蓑輪:日本特有の事情、例えばものすごく細かい話で言えば、アメリカ人のエンジニアで日本語がわからない人は、日本語のフォントでどれが美しいか、どれが見やすいかとかわからないので、そういうのとかも僕らが言わない限り絶対改善されないので、こっちのほうがいいよと言ったりだとか、いいっていう証拠を出してあげたりとか、そうして改善をしたりします。
西村:なるほど。日本語は正しく出てるかどうかも、アメリカから見るとわからない。すごく初期のTwitterって、2007年くらいでしたっけ。日本語が最初、ちゃんとでなかったりしましたね。ジャック・ドーシーに「日本語がおかしい」って言ったら「直しとくよ」みたいな、すごい素朴な時代を私は覚えていますが。そのへん、時差とか、一緒にピザ食わないととか、そういうのってないですか?
蓑輪:それはあまりなくてですね、例えば仕事のやり方として、エンジニアなので、ソースコードを書いたらほかの同僚にレビューしてもらうんです。
そういう「ソースコードレビュー」というのがあるんですけど、それをお願いするときも、そのへんはあの人が詳しいからあの人にお願いしてみな、という時に、一度も会ったことないんですけれども、「これこれこういう事情で、こういうことやってるからよろしくね」というメールをした後に、コードレビューをしてもらうんです。
そうすると、そこから仲良くなっていろいろやり取りがはじまって、みんなフレンドリーだし、フラットな感じなので、僕が日本にいるからどうこう、みたいなことは特に感じないです。
西村:ここで、エンジニアの方もご覧になってるのでいきなり細かい話になっちゃうんですけれども、コードレビュー、どんなツール使っているとか。パッチはどれくらいの粒度で投げるとか、秒単位でコメントがかえってくるのかとか、そのへんのことをちょっとお願いします。
蓑輪:ツールはReview Boardというのを使っています。オープンソースのものを使っていて、パッチの粒度は人それぞれです。僕も人のリリースとか見たりするんですけれども、本当に一行変えただけのものなんかもあれば、やっぱりこれぐらいの大きい単位じゃなきゃ出せないよね、っていう大きいものもあります。
あと、レビューがどれくらい丁寧に返ってくるというのは、入って驚いたんですけど、かなり丁寧にかえってきて、一行一行本当に見てくれたな、っていうのを感じました。
例えば本当に、一切気がついていなかった、今までこんなバグは入れたことなかったし、これ気づくのはスゴいなっていうのをさっと指摘してくれる同僚とかがいて、そこはやっぱりエンジニアの質の高さと、あとそのレビューにかける時間とかコストというのをちゃんと考えてるんだなと。
西村:今おっしゃった、例えば気がつかなかったところって、ある条件の不具合というと語弊がありますけど、バグっぽい動作につながる可能性があったということですか。
蓑輪:そうですね、そのとおりです。
西村:そうなると、もしそのレビューで通っていたら、ヒゲポンさん作ったバグが世に出ていた可能性すらある。
蓑輪:それはあります。はい。
西村:結構その、Twitterっていまや巨大じゃないですか。それでも、自分の書いたコードがぽんって出ちゃう。
蓑輪:そうですね。僕も入社して、最初はサンフランシスコの本社に1ヶ月くらい研修で行くんですけれども、最初にやった仕事が、Webでツイートするときにテキストボックスがあって、そこに入力してツイートするじゃないですか。そのテキストボックスの仕様をちょっと変える、っていう仕事だったんですね。
そこって本当に何千万人何億人の人が使うところなんですけれども、そこを変えますと言われて、わかりました変えますってコード書いてテスト書いて、書きましたと。じゃあここの部分はあの人が詳しいから、あの人にレビューもらってって言われて、そこで良いんじゃないってなったら次の日に出る、くらいな感じなので。
なんというか、本当に大丈夫か僕が不安になる。もちろん、誠心誠意すごいテストして、すごい真剣にコード書いたんですけど、それでもこんなに多くの人が使うものをこんなに簡単に出てしまっていいのか、という不安が最初ありました。
西村:なるほど。あとでちょっとご自身のお話を伺いますけれども、かなり長くエンジニアもやってらっしゃって、それだけ経験を積んでもなお、やっぱりある意味大舞台でドキドキするという感じなんですかね。
蓑輪:それはありますね。昨日、同僚のエンジニアとも話していたんですけれども、エンジニアって自分が作ったものに対して「これは完璧です」「バグはありません」とか、絶対言えないんですね。経験はあるかもしれませんけど、なんというか、予期せぬことってやっぱりあったりしますし、自信を持って言える方が危険だと思います。
なので、なんだかんだで完璧にしたつもりでも不安だ、という状態のほうが、エンジニア的には健全かなと。そういうこともあって、今でもリリースの時には緊張しますね。
西村:なんとなくユーザーとして見ていると、Twitterは、サーバー側の負荷でクジラが出たりとかってよくあっても、フロントエンドでバグとか、挙動がへんとかすごく少ない。Facebookと比べてですけど、少ない気がしてるんですけれども。
その一方で聞いた話ですけれども、シップイット、本当に数人が関わって、先ほどおっしゃった、このへんのダイアログは彼が詳しいから彼がオッケーといえばシップしちゃえと。シップイットって二人の許可が出ればいい、そのへんのちょっとプロセスもう一度お願いします。
蓑輪:まず最初に開発するときは、ローカルの開発環境で開発します。テストして、単体テストとかが終わった後に、いわゆる結合テストをサーバー側で流して、すべてのテストを通したよ、という状態にします。
その後に、いよいよ出来たということで、レビューのリクエストをおくります。それはコマンドラインのツールでレビューの詳細、例えば誰にレビューをお願いするのかとか、このレビューはどういうものであるかと内容を書いたり、というリクエストをコマンドラインツールから送ると、リクエストした人達にメールでレビューリクエストが届きますと。
届くとReview Boardってツールで、変更前はこれです、変更後はこれです、この機能はこういうために作りました、みたいな背景が書いてあります。で、レビュアーの人たちはじっくり見て、もしくは気になるようであればそのGitのブランチを……、
西村:ソースコードのレポジトリの1個を機能別に交換するような?
蓑輪:そうですね。もしソースコードを見ただけではわからないような動作であれば、実際にそれをチェックアウトして自分の環境で動かしてみて、どのように動いているのか確認をして、それをレビューに反映させます。
もし問題があるようであれば、ここおかしいんじゃないかなとコメントに書いて、何回かコメントのやりとりをして、お互い納得のするまでそのコメントは続く。
もしレビューしてる人がOKと感じるのであれば、シップイットというボタンがそこについているので、ピッと押すと「シップイットをもらいました」というメールが僕のところに届くと。そのシップイットが二個揃うと、一応リリースという形にできるということになっていきます。
2025.02.20
残業せずに結果を出すドイツ人の働き方 日本の3倍休んで成果は1.5倍のタスク管理と会議術
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.20
部下からミスの報告が上がった時の反応の仕方 逆効果になる上司の対応と心がけたい3つのポイント
2025.02.21
日本の職場にありがちな「指示待ち部下が多い」問題 ドイツのマネージャーに学ぶ、自律型組織のヒント
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.18
「働きやすさ」と「やりがい」で見た4つの職場のパターン 圧倒的に業績の伸び率が高い職場の特徴
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.14
リーダーが「ゴール直前でひっくり返し」をする理由 ソース原理の専門家が語る、指示が二転三転する人の心のうち
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学