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

「懸垂で体を持ち上げられるようになること」は今年の目標の一つでした。[去年の振り返り](/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 方位を教えるため、まず東西南北について話そうとした。僕が「こっちが北だとすると、反対側は何かな?」と生徒に聞いたら、その子が「東...かな?」と答えた。僕は驚いて「えっ!」と声をあげてしまった。東西南北を知らない中学生がいるなんて...というのは、当時の僕には驚きだった。

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

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

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


Software Engineering at Google: Chapter 3 - Knowledge Sharing


この記事は『[Software Engineering at Google](https://learning.oreilly.com/library/view/software-engineering-at/9781492082781/)』の第二章「How To Work Well On Teams」を読んだ感想である。

(以下、本書の主張と自分の意見をあえて混ぜて書いている)

## コードを隠したくなる気持ちと、その悪影響

まだ [Google Code](https://code.google.com/) が稼働していたころ、機能要望には「コードを隠す手段」に関するものが多かった。「コードを見られる "不安" は根深い」と本章の著者は主張している。なお、著者の Brian Fitzpatrick さんは [Subversion](https://subversion.apache.org/) の作者の一人である。

Linus Torvalds や Guido Van Rossum などの偉大なプログラマーが「またたく間に、たった一人で世界を変えた」というのは誤解である。ソフトウェア開発はチームプレイだ。彼らでさえ、コミュニティの力がなければ、ここまで広く使われるソフトウェアは作れなかった。

本章には「多くのエンジニアは "天才" と思われたい」とある。そして「おそらく、あなたは天才ではない」とも書かれている。

コードを隠したい気持ちは、未完成の仕事を見られたくない気持ちと一緒だ。未完成の仕事を見られると、自分が天才ではないことがバレる。しかし「自分は正しい方向に進んでいるのか?」「同じようなことをしている人はいないのか?」という疑問は、仕事を衆目に晒さないと答えを得られない。

## 謙虚、尊敬、信頼

次の言葉は Richard Hamming さんのエッセイからの引用である。

> The moral is this: do not underestimate the power of playing the social game.
> 
> (抄訳: ソーシャルゲームの力を見くびらないことです)

彼は秘書に対して愛想よく振る舞う「努力」をしていた。のちに彼が仕事でトラブルを経験したとき、その秘書は身を粉にして彼を助けるべく動いてくれた。この人間関係の力学を「ソーシャルゲーム」と表現している。情けは人の為ならず、ということだ。

また、同氏による「カジュアルな服装のせいで重要人物だと認知してもらえない」エピソードも紹介されている。ソーシャルゲームにおいて「外見」は重要である。ソーシャル「ゲーム」なのだから、ルール内で自分が有利になるような装備をすれば良い。

この「友好的に接することで、相手の協力を得られる」ことや「適切な格好をすることで、相手からの評価を得られる」ことを Richard さんは「システム」と呼んでいる。

> By realizing you have to use the system and studying how to get the system to do your work, you learn how to adapt the system to your desires. Or you can fight it steadily, as a small, undeclared war, for the whole of your life.
> 
> (抄訳: システムを使わなければならないことを自覚し、システムに仕事をさせる方法を研究して、システムを自分の要望に適合させる方法を学びましょう。そうしないと、一生をかけて些細な戦争を繰り返すことになります)

まったくその通りだ。

ところで、本章では [Team Geak](https://www.oreilly.co.jp/books/9784873116303/) にも登場する「Humility (謙虚), Respect (尊敬), Trust (信頼)」の 3 つの言葉が登場する。エンジニアリング文化の根幹である。

これをコードレビューに反映させるとどうなるか、という話は面白い。つまり「自分が正しくて、相手が悪い」という態度は謙虚ではないし、「(自分には無駄に思えるコードだけど) 相手はドメインに対する造詣が深いから、そう書いているのかもしれない」という態度は尊敬である。

そのような態度をコードレビューに反映すると、次のようなコメントになる。

> “Hey, I’m confused by the control flow in this section here. I wonder if the xyzzy code pattern might make this clearer and easier to maintain?”
> 
> (抄訳: ここの制御フローで混乱してしまいました。xyzzyのコードパターンを使えば、この部分がより明確になり、メンテナンスが楽になったりしないでしょうか?)

攻撃的ではないし、フィードバックも与えられている。`I'm confused ...` の辺りは「あなたのコードが読みづらい」ではなく「わたしの理解が追いつかない」という感じで謙虚さを感じる。

正しければ何を言っても構わない、という考え方もあるだろう。しかし、それはソーシャルゲームにおけるシステムを無視しており、損をしている。何より、そういう人とはチームメイトとして一緒に働きたくない。


投稿記事