ソフトウェアエンジニアが書いた文章をレビューするときに考えていること

#juneboku > topics > ソフトウェアエンジニアが書いた文章をレビューするときに考えていること
created: 2022-12-17 / updated: 2022-12-17

(この画像はDALL·Eが想像する「編集者」像であり、著者近影ではありません)

はじめに

エンジニアリング・マネジメント領域のお仕事を担当していると、ソフトウェアエンジニアが書いた文章をレビューする機会があります。それは社内のドキュメントであったり、この文章のように一般公開されるものだったりします。数年に渡って数え切れないほどのレビューを繰り返しているうちに、自分がどういった観点でレビューを行っているのか少しずつわかってきたので、その一部を紹介します。

文脈とスコープを意識する

ぼくは社内では「エンジニア職」という扱いで、社の人々との間では「エンジニアです」と名乗ったり「エンジニアさん」と呼ばれたりしています。ぼくが所属するGMOペパボ株式会社 はソフトウェア開発を生業にしているので、あえて「ソフトウェアエンジニア」と言わなくても、エンジニアといえば基本的にはそれを指すことになります。

この記事のタイトルでは「ソフトウェアエンジニア」という書き方を採用しました。ソフトウェア業界の人だけが読むとは限らないからです。このように、文章の置き場所や公開範囲に合わせて表現を選ぶのは重要です。レビューにおいても「これ、社外の人が読んでわかりますかね?」とコメントをすることはよくあります。

社内に閉じたコミュニケーションばかりしていると、文脈やスコープに意識が向きにくくなると思います。種々のコミュニティに参加してさまざまな文脈をもった人々と接することで、読み手にあわせた文章を書く力も向上していくことでしょう。

表現したいことと言葉のズレを小さくする

リモートワークでは、家族と協力したり、仕事用のスペースを確保したりすることが重要だ。

という一文があったとします。ここでの「リモートワーク」は「在宅勤務」への書き換えを検討する余地があります。なぜなら、就業場所として「自宅」を想定した主張をしているからです。リモートワークが間違いというわけではありませんが、主張したい内容によりマッチする言葉を選べば、読者のスムーズな理解の助けになります。

ぼくが見ている範囲でよく陥る罠は「流行り言葉に吸い寄せられる」です。自分の感覚を素直に自分の言葉で語ればいいシーンで流行り言葉を持ち出してしまって、言いたいことの芯がぶれちゃうことってありますよね。自分にもあります。そういった意味で最近のぼくが使用を控えているものとして「技術的負債」「心理的安全性」「リスキリング」などがあります。

モノの名前に意識を向ける

JavaScriptというプログラミング言語があります。2022年12月現在、世界中で広く使われている言語です。ソフトウェアエンジニアの求人票にもよく記載されています。ところで、ぼくが採集した表記パターンにはけっこうなバリエーションがあります。

  • JavaScript
  • Javascript
  • javascript
  • JAVASCRIPT
  • JAVASCRIPT
  • Javaスクリプト

どれも、前後の文脈も含めて読めば「JavaScriptのことだろうな」と想像はつきます。ただ、自分が慣れ親しんだ表記から外れるほど読むときのノイズを感じてしまうのも事実です。読み手としては、なるべくノイズを感じずに文章の意図を読み取ることに集中したいと思います。

また、固有名詞には名付け親がいて、一般公開する文章であれば名付け親の目に触れる機会もけっこうあると覚えておきたいところです。たとえば、日本で開催される技術系イベントの多くは日本人が命名しています。参加レポート等の記事を書いて公開すれば運営の人々にキャッチされて読まれることも多いはずです。命名者からすれば、意図しない形で名前を表記されたとしてうれしくなることはないでしょう。

いずれにせよ、固有名詞を載せるときには「公式サイト等の信頼できる情報を確認する」を実践すればよいだけです。ぼくは自分の記憶や認識をぜんぜん信用していないので、公式サイトのtitleタグの中身を確認してコピーしてきます。

ソフトウェア開発に通じること

さて、ここまでに3つの観点を紹介しました。ぼくがレビュアーを担当するときは、この3つの観点をよく活用しています。「ぼくはこう感じました」「こう変えると、どうでしょ?」「別の書き方を検討してみてほしいです!」のようなコメントをよく書いています。少しでも多くの人に快適に読んでもらえるよう、書き手とレビュアーで力を合わせるつもりでやっています。

しかし、ぼくのコメントすべてに対応してもらうまで公開させないぞ!とは思っていません。事実と異なる記述のような致命的なものはレビューのフェーズでMustで対応してもらうとして、今回紹介した観点についてはShouldな性質のものです。それでも書き手に話しかけて対話の機会を設けようとするのは、ソフトウェア開発にもおおいに関わる観点だと捉えているからです。

「文脈とスコープを意識する」は、プログラミングにおける「名前空間」と、その空間における「関数名・変数名」の名付けに関わってきます。Fileクラスにおけるsizeというプロパティなら「容量」のことだろうな、と読み取ったりします。

「表現したいことと言葉のズレを小さくする」は、モデリングのときに頭を悩ませるトピックでしょう。ソフトウェア上で表現しようとしていることにぴったりの名前が見つかればその後の設計が一気にスムーズになりますし、微妙にズレを感じる名前を採用してしまうと読み解くのが難しくなります。

「モノの名前に意識を向ける」と、そこから派生した「公式情報を参照する」もソフトウェア開発に役立ちます。そもそも、プログラミングにおいては対象の名前を間違えて記述すればコンパイルできなかったりエラーを生じさせたりします。自分の頭の中にある「たぶん、こうだろう」という認識が誤りで、公式ドキュメントを読んだらすぐに解決した…という経験は多くのプログラマが経験していることかと思います。

おわりに

自然言語で文章を書くことと、プログラミング言語でソフトウェアを書くことには、いくつもの共通点を見い出すことができます。そういった考えがあり、ソフトウェアエンジニアが書いた文章をぼくがレビューさせてもらうときは、お互いの成長にもつながるような観点での対話を仕掛けています。

これは🎄GMOペパボエンジニアAdvent Calendar 2022 - Adventar の2022-12-17の記事でした。今年はうちのエンジニアだけでカレンダーがふたつもあって、ぜんぶで50個の投稿が集まる見込みです。会社全体だと100個以上になるかもしれません。おもしろい記事がたくさんあるのでチェックしてみてください!

Mentioned in days

In 2022-12-24 Sat Read full day →

今日の生活

寝ている間に雪が降っていたようだ。今日の朝散歩、足取りは雪道を行く。

ランチ。妻のリクエストでとらや分店に行ってみるも「臨時休業」の文字あり。そこからかにや麺匠に向かう。とにかく白河ラーメンにありつきたい私たち。ここのところとらや分店チャレンジに負け続けている気がするな。

かにや麺匠はとても気に入っている。今日も大満足でお店をあとにした。ごちそうさまでした。

『ウ・ヨンウ弁護士は天才肌』の第5話を観た。物語の本筋とは関係ないけれど、食堂でのウ・ヨンウさんとチェ・スヨンさんの会話がよすぎて泣いてしまった。このシーンについて調べていたらYouTubeにも公式切り抜き動画があったので貼っておくね。

TAKRAM RADIOのVol.162は、前回に続いて和田夏実さんとのセッション。和田夏実さんが最後に「たのしくて、すこやかで、ゆたかな時間でした」と感想を述べていて、上述のウ・ヨンウさんのふるまいと重なってまた泣いてしまった。くるみの運転中にポッドキャストを聴いて泣いてしまうリスクがあると判明した。運転中は、もっと雑談系のポッドキャストを聴くことにした方がいいかもしれない。

https://open.spotify.com/episode/0idzRNFAv2sJ69xqiYrpxw

数日前にソフトウェアエンジニアが書いた文章をレビューするときに考えていることを書いたとき、ぼくが「言葉」に意識を向けるのは「通信の正確性」「通信時のノイズの少なさ」のためである、といった旨のことを述べた。ただ、今日の自分の涙を見るに、それだけではないともあらためて思う。

ウ・ヨンウさんと和田夏実さんから発せられる言葉は、おおいに曖昧性を許容した上で、自分の心のありさまを、そこにたしかに存在すると感じられるものを、相手との間に見つけていこうとする態度を表しているように見える。自分もそんなスタンスで生きてみたい、と憧れを感じている。身近な人たちが「そこにいてくれること」への感謝を自覚し、それを相手にまっすぐと伝えられるような人になりたい。見習っていこう。

和田夏実さんのお話の中身にも触れておきたい。「内なる言語」である「内言」の話は、自分の中にもずっとあったはずなのにそこにピントを合わせたことがなかったと気付いてハッとした。また、研究活動のアウトプットの形式としての「論文」はきわめて音声言語的であり、視覚身体言語の研究の成果を音声言語で語り直すところにむつかしさがありそうというのは考えたことがなかった。ぼくは「名前重要」「命名重要」というけれど、それはある言語体系の上ではそうかもしれないとして、すべての言語体系において絶対に真というわけではないのだなあ。

ぼくは、今から開発しようとするアプリケーションの名前を仮にでも決めないとそれ用のディレクトリをつくれないくらいの不自由さを抱えているわけだけれども、それは音声言語に根ざしているからだ。ジェスチャーで対象を指し示す場合、それの名前が明らかでなくても扱うことができる。たしかに。これまで自分が、いかに「特定領域」での認識に基づいて生きてきたか気付かされる。

そしてぼくは、視覚身体言語の研究者である和田夏実さんの音声言語の操り方に魅力を感じている。これは、複数のプログラミング言語に通じている人がひとつひとつのプログラミング言語をより上手に扱えるという構造に似ている。音声言語とよりよい付き合い方をしていきたいと願うなら、音声言語以外を知っておくことは重要なのだろう。音声言語を30年以上も使ってきて、ようやくこのことに気付いたのであった。はあ。

最後にこれは余談だけれど。特にCOVID-19が流行してから「わたしは言語化が苦手で」という言説を多く見かけている。ここでいう「言語化」の「言語」は、音声言語のことだろう。であるならば、あまり音声言語に固執せずに、自分が得意な言語やコミュニケーション様式を選択するとよいのではないか。もしテキストコミュニケーションが苦手なら、他の人よりカジュアルに動画を活用するなど、やりかたはあるように思う。なにが苦手かよりも、なにが得意かを考える方が有効なシーンはあるだろう。

Archives : 2,609 days