得意な言語は何ですか? ─母語を極めろ……!─
突然ですが質問です。
あなたは何人かのメンバーとともに、ユーザガイドの改訂を行っています。
コミットメッセージに次の一文が記されていました。
メニューバーの写り込みに伴うスクショの差し替えをしています。
この一文、斜め読みをしてパッと瞬時に理解できましたか?
こんにちは、当記事は PHONE APPLI Advent Calendar 2023 (Qiita) の12月5日担当として書いています。
プログラミング“言語”ではなくて、日常生活で使っている“言語”にまつわるお話なので、Qiitaではなく、はてブで更新しております。
さて、冒頭の質問に戻りましょう。
メニューバーの写り込みに伴うスクショの差し替えをしています。
このメッセージ、分かりにくくありませんか?
この一文だけ読んでとくに何も感じない人であっても、別の文章と比較することで「分かりにくいな」と感じるのではないでしょうか。
X: メニューバーの写り込みに伴うスクショの差し替えをしています。
Y: メニューバーが写り込んでいたので、スクショを差し替えました。
Xが分かりにくい文章、Yが分かりやすい文章、です。
もしXでもYでも違いを感じないのであれば……すまないが……君は文章表現能力が低いと言わざるを得ない……。本当にすまない……。この記事を読んで少しでも君の文章表現能力が向上することを願うばかりだ……。
では、XとYにどういった共通点・相違点があるのでしょうか?
私は、次のように考えました。
- 2つの文章の共通点
- このコミットでどんな変更が加えられたのか理解できる。
- 2つの文章の相違点
- 変更した理由が不明瞭か、明瞭か。
- 変更作業はまだ進行しているのか、完了しているのか。
順に見ていきましょう。
共通点: このコミットでどんな変更が加えられたのか理解できる
これは、コミットメッセージを書く上で大切な要素の1つですね。
XもYも、「スクショを差し替えた」ことが明らかです。
恐らくコミットメッセージを書いた人は、コミットの変更対象を正確に記そうという気を配る余裕はあったのでしょう。
あるいは、コミットメッセージを書く時のチームのルールで、変更対象を明らかにすべし、と決められていたのかもしれません。
相違点: 変更した理由が不明瞭か、明瞭か
XもYも「メニューバーが写り込んでいたため」という理由に変わりはありません。
ではなぜ、Xは不明瞭で、Yは明瞭に感じるのでしょうか。
──Xは冗長で、Yは簡潔だからです……!
もしXでもYでも違いを感じない方は、“そういうもの”だと思ってください……。
文章表現の話で頻繁に出てくる考え方として、「一文一義」「ワンセンテンス・ワンメッセージ」というものがあります。
雑に言い換えると「何でもかんでも一文におさめようとするな」ということです。
Xの場合「伴う」という言葉が曲者です。
日本語としては誤っていませんし、たとえば、知人に手紙を書いたりスピーチの原稿を書いたりする時には効果的な言葉といえるでしょう。
ですがコミットメッセージのように状況を正確に伝える必要のある文章の場合は、文章の見栄えや耳馴染みのよい言葉ではなく、あくまでも「一文一義」「ワンセンテンス・ワンメッセージ」のルールを守ることで、役割(状況を正確に伝える)を果たすことを優先したいところです。
手紙や原稿のような、日常で用いる言葉遣いとは異なるポイントに気をつけなくてはなりません。
相違点: 変更作業はまだ進行しているのか、完了しているのか
これは、コミットメッセージを読むタイミングがいつであるかを意識すると分かりやすいかと思います。
恐らくコミットメッセージを書いた人は、「コミットして、PRでapproveになればこのタスクは完了」という意識で書いているのではないでしょうか。
コミットメッセージには、そのコミットがどういった状態であるかを書くべきですので、コミットする内容が一区切りついているのであれば、過去形「差し替えました」と書く方が分かりやすいといえます。
自分がいま着手している作業の一連の流れがどうであるかではなく、後からコミットメッセージを見た人がそのコミットがどういった状態になっているのかという視点を意識できるとよいですね。
さて、色々と見てきたのですが、最後にもう1つ分かりにくさを助長している言葉があります。
「差し替える」という動詞を「差し替え」という名詞扱いしている箇所です。
文章を短く書こうとするあまり、体言止めを多用するケースを時折見かけますが、体言止めの書き方に慣れている人が丁寧な文章を書こうとした時に「動詞の名詞系 + する」といった書き方になることが多い……のかもしれません。知らんけど。
つらつらと見てきましたが、XもYも、実はどちらも私がコミットする時に書こうとしたメッセージです。
とくに何も考えずXを書き、それを推敲してYに書き直しました。
最初から綺麗な文章を書けるに越したことはないでしょうが、それよりも、推敲をして他の人や未来の自分がどう感じるかまで気を配ってメッセージを書くことこそが、手っ取り早く分かりやすい文章を書くコツなのではないかなと考えています。
あとは……そうですね……一文は50〜60文字程度におさめるのがセオリーだとか、漢字3割・ひらがな7割だと読みやすいだとか、巷に溢れるテクニックはあれこれあるのですが……テクニックを使いこなすためにこれだけは覚えておきましょう。
母語だからと思いつくままに書いて書きっぱなしにするのではなく、そこからもう一捻りすることが大切!
一文がよりシンプルになるように、Simple is Best、Less is More、要するにごちゃごちゃした文章を書くのはやめようね、ということです。
ブログの文章も、もっとシンプルに書けたらいいのになぁ。
リモートワーク今昔
はじめに
当記事は Phone Appli Advent Calendar 2020 (Qiita) の担当として書いています。( ≪ prev | next ≫ )
Qiita で何か書けたらなぁと模索していたんですが、どうあがいてもポエムになってしまうので、もうブログを開設してそっちで書けばいいや!という感じで書き始めましたです。はい。
いずれも個人の経験と主観によるものですので、あしからず。
それではスタートです!
リモートワークの移り変わり
「リモートワーク(仮)期」は転職前の、「ひとりフルリモートワーク期」「リモートワーク奨励期」は今の職場の経験です。
いずれもウェブアプリケーションの開発が主たる生業でした。
リモートワーク(仮)期
日曜日に顧客が作業を行う際のヘルプデスク業務を自宅で行えるよう、上司が会社と交渉してもぎ取ったリモートワーク(仮)。
顧客からの連絡が来ない間は、ウェブアプリの開発を進めたりマニュアルを修正したりして過ごしていました。
平日のリモートワークは不可だったため「(仮)」としています。
- 開発環境など
- Eclipse、SourceTree、Git(社内サーバー)、Backlog
- コミュニケーションツール
-
- 社外:電話(携帯電話)、Eメール
- 社内:HipChat、Yammer(途中から MS Teams に切り替わった)
- リモートワークをして良かったこと
-
- 顧客からの電話にすぐ出られる。
(通勤中の電車の中で電話対応ができず申し訳なかった) - 仕事をしながら飲食ができる。
(休憩スペースに移動しないと飲食ができない職場だったため、そういった制約から開放されるのが嬉しかった) - 電車のダイヤを気にしないで良い。
(終電を逃すことがわかっている場合は自動車で通勤することになるのだが、そういった時の駐車場の確保など関連作業を行う必要もなくなり気が楽だった)
- 顧客からの電話にすぐ出られる。
- リモートワークをして困ったこと
-
- 土曜日に40分作業をするという局面があっても労働時間として計上されない。
(これは、うーん、色々とグレーゾーンな話かも) - リモートワーク反対派からのウケがすこぶる悪い。
(知らんがな)
- 土曜日に40分作業をするという局面があっても労働時間として計上されない。
ひとりフルリモートワーク期
転職に伴い、フルリモートワークを開始。
会社自体はリモートワーク環境が整っていましたが、フルリモートワークの人はゼロ人。(多分)
なんやかんやあって「フルリモートワークの人がいても良いのでは?」みたいな感じで働かせてもらえることになりました。
出勤頻度は月0〜2回でした。
- 開発環境など
- IntelliJ IDEA、SourceTree、GitHub、Backlog、Trello
- コミュニケーションツール
- Webex、Eメール
- リモートワークをして良かったこと
- 出勤時間がなくなったため、睡眠時間が増えた。家事に割ける時間や、まったりする時間も増えた。
- リモートワークをして困ったこと
-
- 出不精が加速した。ランチタイムに外食して気分転換を図ることも億劫になった。(そもそもランチする店が近所にない)
- 「私ができていなくて、出勤している人がやってくれている作業は、どれだけあるんだろう」と考え始めると、不安でたまらなくなる。
リモートワーク奨励期
COVID-19 の流行に伴い、リモートワークが奨励されるようになりました。
最後に出勤したのは ?
それ以降はずっと家で仕事をしています。
- 開発環境など
- IntelliJ IDEA、SourceTree、GitHub、Backlog、Jira、Trello
- コミュニケーションツール
- MS Teams、Webex、Slack
- リモートワークをして良かったこと
- 自分の意思で出勤・在宅を選択できてる満足感を得られる。
(衛生観念は個人差がありますので、自由度が高いとストレスなく仕事をできるのだなぁと感じました) - リモートワークをして困ったこと
-
- 月に数回の出勤もしなくなったので、人間と会話したい欲求が溜まる。
- 会社に書類を郵送するという作業が増えた。
----
ここ5年程がこの3つの期に分類されるのですが、開発環境の向上で働きやすくなったと感じたことは、少なくとも私の中ではありませんでした。
もしかしたら Redmine を使ったり Subversion を使ったりしていた頃にリモートワークを開始していたら、また感じ方も違ったのかもしれません。
リモートワークの注意点
私はフルリモートワークがハマったので良かったのですが、もちろん注意点もある訳で。
リモートワークへの移行が難しい(かもしれない)ケース
きっと、考え始めたらいくらでも難しいケースは上げられると思います。例えばこんな具合に。
- 受託開発を行っており、圧倒的に取引先の力が強く、契約書で作業場所を指定されている案件に携わっている。
- 仕事をする上でオシロスコープや試作機、サーバーなどが必要不可欠であり、それらの持ち運びが困難である。
- 見積作成や契約書作成にあたり、封印したり収入印紙を貼付したりして代表印の割印が必要になる--といった具合に、アナログな作業が強いられている。
- 自宅で仕事をすることで同居人の邪魔になってしまう(夜勤の人を起こしてしまう、など)。
ただ裏を返せば、案件以外の作業、人との会話が不要な作業であれば、リモートワークに移行可能な作業もあるはず。
そうなってくると、リモートワーク + α の組み合わせ技を作るなど、就業規則の改訂が必要になってくるかと思います。
(リモートワーク + 時短勤務、リモートワーク + フレックス制、みたいな)
これは--リモートワーク云々というよりも働き方改革とやらの範疇になってきそうです。
もしリモートワークをしたいけれども社内で反対にあっている、リモートワークしてもらいたいのに移行してくれない、という場合には「+ α」の部分に何が入るかを考えてみるのも一案かもです。
リモートワークはただの手段
リモートワークにしたからと言って、そんなに何かが大きくは変わらないのかなというのが率直な感想です。
- 仕事とプライベートが切り分けられなくなりませんか?
→案件によります。パソコンをシャットダウンしようが、チャットの通知を切ろうが、気になる時は気になる。 - リモートワークだと怠けてしまいませんか?
→出勤していたって怠けます。 - 太りますか?
→人によります。
この辺りの Q&A は割とリモートワークあるあるだと思うのですが、もう、その人の性格によるとしか言えないので、考えても答えは出ないかと。
出勤している時の気分転換は○○だけど、リモートワークの時に向いている気分転換は××、といった具合に、その場その場で自分が好ましいと思うやり方を模索していくしかないのではないでしょうか。
さいごに
案の定、とりとめのない散文になってしまった訳ですが、この1年でリモートワークを取り巻く環境が大きく変わってしまったので「あの時どうだったけ?」と5年後10年後に思い返せるように書き出してみました。
「開発環境の向上で働きやすくなったと感じたことは、少なくとも私の中ではありませんでした」とか書いていますが、近い将来、この辺の認識が変わる未来もあるのかも?
おまけ
ふと気になって、直近5〜6年程の電気料金を比較してみました。
フルリモートワークを始めて以降、確実に、でも少額だけ、料金が上がっていることがわかりました。
サラリーマンも家事按分とかできたらいいんですけどね。うーん。
凡例補足
- 一人暮し(30A)
- 「リモートワーク(仮)期」よりも前。在宅時間が著しく低かった頃。
- 二人暮し(40A)
- 「リモートワーク(仮)期」頃。二人暮しのため40A契約に変更。
- 二人+ペット
- 「リモートワーク(仮)期」頃。ペットを飼い始めたため終日エアコンが稼働するように。
- 二人+ペット+フルリモート
- 「ひとりフルリモートワーク期」及び「リモートワーク奨励期」。PC、サブディスプレイが終日稼働し、昼食などもすべて自宅で用意するように。