
[5月11日に Google Bard が日本語をサポート](https://japan.googleblog.com/2023/05/bard.html)してから、Google Bard (LaMDA) を利用してきました。ChatGPT の代わりを務めてもらった、ということです。

しかし、いくつかの点で不満を感じたため、涙を飲んで ChatGPT へ戻ろうと決意しました。ただいま ChatGPT。浮気してごめんな...。

まず最初にに Google Bard の「良いところ」を挙げてみようと思います。

1. すべての機能が無料で使える
2. 回答の生成が (ChatGPT の GPT-4 モデルより) 速い
3. (ChatGPT と比較して) 新しい情報も教えてくれる
4. 知らないことを「知らない」と伝えられる

`4. 知らないことを「知らない」と伝えられる` について補足します。Google Bard は答えられないことは「それについては答えられない」という旨の返答をします。これはハルシネーション (= 情報を捏造してしまうこと) よりも好ましいです。しれっと嘘をつかれると検証に時間がかかるからです。

とはいえ、これにはデメリットもあります。生成 AI を情報ソースとしてではなく対話相手として利用している場合、「それには答えられない」と返されると、そこで会話が止まってしまうのです。たとえば生成 AI が嘘をついたときに「でも、それだと xx と矛盾するよね」と言える方が **対話** としては面白いと思います。むしろ、ChatGPT はそういう使い方ができるのでウケているのだと思います。また ChatGPT に間違いを指摘すると「自分が間違えていました」と認めることもあります。このような誤りを認識し、認める能力こそ、AI における知性を感じる瞬間だと僕は思います。

さて、次は ChatGPT の方が優れていると感じる点です。

1. 履歴に「質問と回答のセット」が残る
2. (GPT-4 の場合) 生成されるテキストが Google Bard (LaMDA) より信頼できる **(要出典)**
3. スレッド形式で質問可能で、コンテキストをスレッド内でまとめられる
   * 各々のスレッドにタイトルをつけられる (最初のタイトルは ChatGPT 自身がつけてくれる)
   * (Web UI の場合) サイドバーに過去のスレッドのタイトル一覧が表示されている
     * 過去のスレッドから会話を再開することで前提を再入力する手間が省ける
4. iOS アプリがある

「生成されるテキストの質」について、僕は ChatGPT の方が優れていると感じています。しかし、実際には UI/UX に関してこそ ChatGPT を高く評価しています。

僕は技術的なトピックに関するディスカッションの相手として生成 AI を活用することが多いです。たとえば AWS で VPC/Subnet の設計をしているときに「この IP アドレスレンジでサブネットAを運用したいんだけど...」とスレッドをはじめて、一通り満足のいく会話をしたとしましょう。新しい要件が出てきたとき、このスレッドに戻ってきて「ところで VPC ピアリングもしたくなったんだけど...」と続けられるのは便利です。これは Google Bard などでは実現しがたい点です。

また、サービス履歴に「質問と回答のセット」が残っていると壁打ちしてもらった内容を一覧できて便利です。Google Bard は (デフォルトでは) 質問のみが残るようになっています。これは意図的な設計だと思うのですが、その質問から再び回答を得ようとすると時間がかかるし、そもそも同じ内容を得られるとも限りません。やはり、質問と回答がセットで残るメリットは大きいです。

最後に iOS アプリの存在も、地味に嬉しいポイントです。携帯のブラウザで同等のことを行えるものの、やはり専用アプリのユーザー体験には及ばないと感じています。

...というような理由から、Google Bard に一旦の見切りをつけて、また ChatGPT の課金ユーザーに復帰しました。半年くらいしたら、また別の生成 AI にスイッチする可能性は残っているけど、しばらくは ChatGPT を楽しもうと思います。


ChatGPT と Google Bard の比較、または再度の ChatGPT への課金


最近、懸垂ができるようになりました。まだ一回だけだけど。

「懸垂で体を持ち上げられるようになること」は今年の目標の一つでした。[去年の振り返り](/posts/2022-12-23-retrospective)で、次のように書きました。

> 単に体重を落とすという目標だとあまりモチベーションが湧かないので、並行して懸垂の練習をしている。実は懸垂を 1 回もできないのだが、近所の公園でぶら下がることからはじめている。2023 年には 2-3 回くらい自分自身を持ち上げられるようになりたい。

半年かかったけど、ようやくできて一安心。このまま「2-3 回くらい」できるようになるといいな。ところで、現時点では実は「手を伸ばした状態から」は懸垂できていなくて、最初に鉄棒をつかむためにジャンプをして、そのままの勢いで (肘が既に少しだけまがった状態から) ぐぐっと頭を鉄棒より上に出す、ということができる程度です。

道は長い...けど、最初のステップは超えられたな...という感じ。引き続きがんばろう。


「体作り」の進捗、または「初めての懸垂」


唐突ですが「〜だ」「〜である」調での文章をやめて、「〜です」「〜ます」調に転向したいと考えています。少なくともこのブログにおいては。

直近のブログ記事で色々と実験して、いけそうだなという感覚を得ています。

「そんなに大層なことか?」と思われそうですが、確認できる範囲でも [2012
年くらいからずっと「〜だ」「〜である」で文章を書いてきた](https://mahata.gitlab.io/post/page/10/)ので、意識しないとできない変化でした。

[少し前から過去のブログ記事を読み返す生活をしていて](https://mahata.gitlab.io/post/2021-04-01-read-your-own-blog/)、そこで断定調の自分の文体を読んで「この人、ちょっと圧が強いな...」と感じたことがきっかけです。やわらかい雰囲気の人間になりたいので、がんばります。がんばるぞ。


「〜です」「〜ます」調への転向


『[ベタープログラマ](https://www.oreilly.co.jp/books/9784873118208/)』を読了しました。 面白い部分もありましたが、同意できない点も多々ある本でした。

「謙虚な姿勢で、継続的に学ぶ」というメッセージや、「優れたプログラマを目指すということは、心地よい場所にとどまることと対極にある」という主張は納得できるものでした。

しかし、テストに関しては記述が粗いように感じました。

例えば、「単体テスト」の定義について、最小単位のテストであることを強調しながら、「順序を入れ替えて実行しても結果に影響を与えない」という点に関する記述が欠けていました。「（製品コードの他の単位が関係せずに）テストしていないのであれば、単体テストではありません」と書いてあるので、好意的に解釈すれば同等のことを言っているようにも思いますが、明確にしてほしいと感じました。

テストダブルの例として、「ダミー」、「スタブ」、そして「モック」について書かれていますが、ここでのダミーとモックの定義は誤解を招くものだと感じました。より良い定義は [Choosing the Right Test Double](https://tanzu.vmware.com/developer/guides/test-doubles/) に書かれいているものだと思います。つまり、ダミーはコールするとクラッシュするテストダブルであり、モックはスタブとスパイの機能を持ちつつ、そのオブジェクトの中でアサートまでできるものだという定義です。本書では、ダミーを「テストはそれら (= ダミーオブジェクト) を呼び出しませんが、パラメータのリストを満たすために存在しています」としており、モックに関しては要領を得ない説明になっています。

また、第3章の「少ないコードを書く」では、「使っている言語が三項演算子を提供しているなら、三項演算子を使ってください」と、『[リーダブルコード](https://www.oreilly.co.jp/books/9784873115658/)』とは真逆の主張がされていました。三項演算子は可読性を下げることが多いと感じているため、この主張には同意しかねました。



『ベタープログラマ』の感想


『[Reactハンズオンラーニング 第2版](https://www.oreilly.co.jp/books/9784873119380/)』を読了しました。 React 歴の浅い自分には、得るものが多い良い書籍でした。

この本は序盤で [Create React App](https://create-react-app.dev/) でプロジェクトの雛形を作る例を紹介しつつ、付録で Create React App 相当のことを手作業で実現する方法も扱っています。JavaScript まわりのツールチェインに疎い自分としては、Create React App の内側を理解する役に立ちました。React 本体と直接の関係はないけど、あわせて理解しておきたい「Jest」「GraphQL」「ESLint/Prettier」などについてもカバーされており、内容が実用的である印象を持ちました。

[ソースコードが GitHub で公開されており](https://github.com/oreilly-japan/learning-react-2e-ja)、セクションごとに動くサンプルが提供されている点にも好感を持ちました。少し時間をおいて、サンプルを動かしつつ読み直そうと思っています。


『Reactハンズオンラーニング 第2版』の感想


チームメイトへの自己紹介で「B'z のファンです」と話した。再確認のため、自分の B'z ファン歴を振り返ろうと思う。

「[Love Phantom](https://ja.wikipedia.org/wiki/LOVE_PHANTOM)」あたりから存在を意識し、何かの機会に兄が「[B'z The Best Treasure](https://ja.wikipedia.org/wiki/B%27z_The_Best_%22Treasure%22)」を聴かせてくれた辺りから、B'z にハマった。1998~2005 年くらいの間は、ほぼ毎日聴いていた気がする。たぶん 2000 年くらいにファンクラブ会員になった...はず。うっすらした記憶だけど、2001 年の「[B'z LIVE-GYM 2001 -ELEVEN-](https://ja.wikipedia.org/wiki/B%27z_LIVE-GYM_2001_-ELEVEN-)」が最初の B'z ライブ参加体験だったような気がする。

2005 年に社会人になってから、徐々に B'z を聴く機会が減っていった。プログラミングしながら B'z の曲を聴くと注意が散漫になった。B'z だけではなく、歌詞のある曲は集中力を削ぐので、だんだん環境音 (雨音) やボーカルレスの曲を好むようになった。

2011 年にバンクーバー (カナダ) に引っ越したタイミングで、ファンクラブ会員ではなくなった。会報誌を受け取れなくなるからだ。この頃はジョギングが趣味であったので、ジョギング時に B'z を聴いていた。「B'z」と「走ること」は相性が良かった。なお 2012 年にバンクーバーで「B’z LIVE-GYM 2012 -Into Free-」があった際には地元民として参加した。狭い会場で B'z を間近に見れて感動した。

2015 年に帰国した後は、あまり B'z を聴いていない。というか、音楽をほぼ聴いていない。膝を痛めて走れなくなってしまったため、ジョギングしながら B'z を聴くこともなくなった。プログラミング (= 仕事) しながら聴く音楽といえば、環境音や lo-fi 系のものばかりだ。移動時にはポッドキャストかオーディオブックを視聴している。残念ながら B'z の入り込む隙間がほぼない。

とはいえ、ファンクラブ会員には復帰した。新曲がリリースされると、曲を口ずさめるようになる程度には聴いている。「B'z のライブに行きたいから」だ。そんなわけで、今でもツアーには参加している。先日も「B'z LIVE-GYM 2022 -Highway X-」に参加してきた。

B'z はライブがいいな、と思う。ライブに行くために曲を聴く、という感じだ。B'z の二人は僕よりだいぶ年上で、彼らが往年の名曲から最新の曲までカッコよく元気に演奏してくれる様を鑑賞するのがたまらない。自分もかくありたい、という気持ちにさせられる。

一歩ひいて考えると、僕は「生涯現役」的なものに惹かれているんだろうな、と思う。たとえば僕は野球選手ではイチローが好きだけど、その理由のひとつは彼が長く現役選手でいてくれたからだ。彼は 45 才までメジャーリーグで活躍した。日米で 28 年間の選手生活だ。すばらしい。

反対に、名指しは避けるけど、過去に解散したバンドが「再結成」してしょぼい演奏をしたりすると、とてもがっかりする。現役を続けて、続けて、続けた先にあるものを見せてほしい、という気持ちが自分は強い。

そういう気持ちから、B'z のライブには今後とも参加したいと思う。これを書いている時点で B'z の稲葉浩志は 58 才で、松本孝弘は 62 才だ。あと 10 年は元気でやっていてほしい。68 才 と 72 才のユニットが変わらずにカッコよく居続けてくれたら、ファンとしては幸せなことだと思う。


B'z ファン歴


先日 VMware Tanzu Labs の東京オフィスが運営する [Product Run に記事を公開しました](https://medium.com/product-run/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2-tanzu-labs-%E3%81%AE%E3%82%AA%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E4%BD%93%E9%A8%93-ca0599856234)。久しぶりに企業ブログへ寄稿しました。

今でもアクセス可能な、僕が寄稿した企業ブログの一覧をメモしておこうと思います。

* 2023年03月 - [ソフトウェアエンジニア @ Tanzu Labs のオンボーディング体験](https://medium.com/product-run/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2-tanzu-labs-%E3%81%AE%E3%82%AA%E3%83%B3%E3%83%9C%E3%83%BC%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0%E4%BD%93%E9%A8%93-ca0599856234)
* 2018年05月 - [社内勉強会 @ スマートニュース with 寿司](https://developer.smartnews.com/blog/2018/05/internal-meetups-at-smartnews/)
* 2010年06月 - [重たい処理を華麗にスルーして、アプリケーションの体感速度をぐっと向上させる方法](http://tech.voyagegroup.com/archives/495474.html)

これとは別に、自分の仕事が記事になったものは次の通りです (なお、たまたま自分がしゃべっただけで、成果そのものはチームメイトと一緒に作り上げたものです。言うまでもないことだけど)。

* [スマートニュース、動画チャンネルでのMLサービス活用を語る](https://weekly.ascii.jp/elem/000/001/799/1799136/)
* [【後編】６社の事例から学ぶ──ユーザー体験を磨き、サービスを支える技術力とは？](https://techplay.jp/column/988)

また、AWS Summit Tokyo で話した内容を動画にしてもらっています。

* [アカツキ、スマートニュースがご紹介！AWS運用を支えるエンタープライズサポート活用事例 | AWS Summit Tokyo 2019](https://www.youtube.com/watch?v=vtv3fPJaXvo)


過去に記事を書いた企業ブログ（など）


最近は多くのソフトウェアエンジニアが Zenn に記事を書いているようです。[僕も使い心地を試す目的で Zenn を使ってみることにしました](https://zenn.dev/mahata)。技術的でない記事は、引き続きこのドメインでホストしようと思っています。


Zenn に技術ブログを書く話


僕は小学生の頃とても太っていた。そして、肥満児は足が遅い。

足の遅い僕にとって、年次イベントのひとつである「マラソン大会」は気が滅入るものであった。マラソン大会は、男子児童が先にスタートして、5 分後に女子児童がスタートする、という感じで行われた。

僕は少し走ると脇腹が痛み出し、もともと欠けていたやる気も尽き、とぼとぼ歩きはじめた。皆に追い抜かれ、ついには女子児童にも追い抜かれはじめた。

このとき、女子児童の一人が僕を「歩くなー、がんばれー」と言いながら追い抜いていったことを、たまに思い出す。彼女だって、余裕綽々でマラソンをしていたわけではない。自身も顔を真赤にしながら息を切らしつつ声をかけてくれた。思い出すと、少し感動してしまう。

自分は「人に優しく接するためには、自分自身が元気であることが必要だ」と思っている。だから、なるべく元気でいようと思っている。でも、この子のように「自分がきつい状況にあっても、相手のことを考えられる」ことが真に目指すべき到達点なのかもしれない。


マラソン大会の思い出


『[Software Engineering at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』の第三章「Knowledge Sharing」を読んだ。以下は感想文である。

知識共有は重要だ。しかし **善意によって** 知識共有が妨げられることがあるというのは、面白いと思った。たとえば、エース級の人材が難しいタスクを「僕がやっておきます」と手を挙げるのは善意からの行動だ。しかし、知識がチームに根付かないという意味ではまずい行動である。

知識共有のためにドキュメントを書けばいいのだろうか。必ずしも、それが最善の手段ではない。[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)には「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」という節がある。それぞれをあわせて、僕は「**ドキュメントよりも、対話しながらソフトウェアを一緒に動かす**」ことが知識共有にはベストだと考えている。この「**一緒に動かす**」というのは、ペアプログラミングを通じて、である。つまり、エクストリーム・プログラミングが知識共有に最も効くのでは、ということだ。

この意見に反論があるとすれば、スケールメリットに関するものだろう。ドキュメントは一度書いたら何度も読んでもらえる。一方で、ペアプログラミングはペアにしか知識が伝播しない。とはいえ、ペアをローテーションすることもプラクティスに含まれる。ローテーションさせ続けることで必要な人に知識を行き渡らせることは難しくない。なんなら **ペアでドキュメントを書いても良い**。

本章では質問者の無知に対して「feigned surprise (驚いたふり)」をしてはならない、とある。心理的安全性を低めるからだ。スタックについて質問しても「えっ、スタックを知らないの?」と返されてしまうような環境では安心して質問をすることは難しい、という例が紹介されている。もし現職で「スタックを知らない」と同僚から言われたら「ふり」じゃなくて、普通にびっくりしちゃう気がするけど、言葉や態度には出さないように気をつけたい。

ところで、心理的安全性について、若かりし頃の苦い思い出がある。僕は 20 才頃は学習塾でアルバイトをしていた。中学生向けの理科の授業のとき、16 方位を教えるため、まず東西南北について話そうとした。僕が「こっちが北だとすると、反対側は何かな?」と生徒に聞いたら、その子が「東...かな?」と答えた。僕は驚いて「えっ!」と声をあげてしまった。東西南北を知らない中学生がいるなんて...というのは、当時の僕には驚きだった。

その後、彼を塾で見ることはなかった。退塾したとのことだ。

この件に関して苦情を受けたわけではない。彼の退塾の本当の理由はわからない。でも、僕自身はこのときの自分の態度を悔いている。たまに思い出して反省もしている。なんにせよ、僕が彼の心理的安全性を低めたことに変わりはないだろう。

さて、他に本章で面白かったことと言えば「質問をすることで、他の人も質問しやすくなる」という話だ。僕は場が静まり返っているときほど質問をする傾向がある。まさに他の人の質問しやすさのためである。こういう所作を本の中で肯定してもらえるのは嬉しく思う。


投稿記事