文章の書き方の基本について考えた

こんにちは、デザイナーのはなです。

弊社でデザイナーとして働いていると、何かの説明文を考えることが多くあります。

お客様にわかりやすい表現ってなんだろう…?とその業務のたびに考えます。

私は文章を読むことにも書くことにも、あまり苦手意識を持っていません。

最近文章の書き方について後輩に説明することがあり、その際、実際に自分がノリでやっていることを言葉で説明することの難しさを痛感しました。

なので、「わかりすい文章」というものについての自分の解釈をメモ代わりとして残しておきたいと思います。

骨が何か考える

文章は基本的に「誰」が「何をするか」がはっきりしていれば意味が通らないということはありません。

主語・述語というやつです。

学校の国語の授業と違って、仕事で読んだり書いたりする文章は、主語が省略されていることも多いです。

ちゃんと書かれた文章なら、主語が省略されていても誰がした行動についての文なのかが自然に理解できるはずです。

誰が何をしたのか、誰が何をすべきなのかが一発でわからないなら、それは上手な文章ではないと私は考えています。

主語も述語も書いているのに意味が通りにくいとしたら、余計な要素が邪魔をしている可能性があります。

入れたい要素を最初から全部入れようとすると失敗するので、まずは骨である「誰が何をしたのか」を組み立て、他の要素は補助であるという意識で文章を作るといいと思います。

骨を組み立てるためには、まず書き手である自分が「誰目線の文なのか」がきちんとわかっていることが大切だと思います。

誤解が無い文を心がける

私が文を書く際に心がけているスローガンが、「5歳に見せてもわかる文」です。

読み手が不特定多数のユーザーの場合、読み手の読解力というものに期待をしてはいけないと思っています。

馬鹿にしているというわけではなく、その人の経験や境遇、精神状態が読解力にダイレクトに響いてくるわけです。

読んだ人の100%が誤解をしない文を書くというのは不可能ですが、違った解釈をする人間をできる限り0に近づけることは頑張り次第で可能です。

「5歳に見せてもわかる文」というスローガンは、専門的なことは何も知らず理解力もあまりなく、難しくて長い文を読んだらすぐに飽きてしまう五歳の子供に見せたときにちゃんと最後まで読んでくれるかという、自分の文に対する問いかけのことです。

別の解釈の余地がある文を読んだ頭の中の五歳児は、多分私の想定の動きをしてくれないでしょう。

私が文句を言うと、だってそう書いてあったもん!!と泣きながら駄々をこねると思います。

自分が書いた文にはそういうクレームの余地が一ミリもないかと考えることが大切だと私は考えています。

音読してみる

実際に音読をしてみると、黙読だけではわからなかった違和感に気が付きます。

ただ文字をなぞるように読むのではなく、文を塊として、人に話すようなテンションで読むのがいいと思います。

短い文なら覚えてしまってから空で口に出してみるとよいです。

オフィスで思いっきり音読をすれば結構目立ってしまいますが、脳内で音読しながら口パクするだけならまぁ大丈夫でしょう。

私は完全テレワークなので、このブログを書いている今も、思い切り音読しながら書いています。

悪い文章を反面教師にする

良い文章は、読んだときに引っかかりがないので、無意識のうちにスルッと読めてしまいます。

しかし、読みにくい・意味がよくわからない他人が書いた文章は、ん…?と引っ掛かりを覚えたり、どういう意味なのか他人に聞かなければなかったりします。

そういう文に出会ったときに、何が余計で何が足りないのか、じっくり読み返して添削をしてみるといいと思います。

これが誰目線の話なのかわからないからなのか〜とか、この表現が邪魔なんだな〜とか、自分が書いた文よりも気がつくところが多くあると思います。

それをメモっておいて自分が書くときにも気をつけるようにするだけで、大きく違いが出ると思います。

最後に

文章の練習は、「人の振り見て我がふり直せ」が一番いいです。

一回で理解しきれない文章に出会ってしまった場合、自分の読解力が低いのではなく、十中八九相手の書き方せいだと悪いと私は思っています。

半分逆ギレですが、その時に、じゃあどんな文なら自分でも一発でわかるんだろう?と思考することが文章を書く能力の向上につながっていると思います。

日本人というのはは特に、「違和感のある日本語」に不信感を覚えやすい国民だと思います。

ふわっとした日本語を見て、このお店ほんとに大丈夫かなぁ…?と思ってしまった経験を持っているのは私だけではないはずです。

文章を、正しく誤解なく伝えることで、お客様からの信頼感を得たり、無駄なクレームを防いだりすることができます。

たかが言葉ですが、されど言葉という気持ちで向き合うのがいいと私は思います。

スケッチアプリ「コンセプト」のUIが面白い

こんにちは、デザイナーのはなです。

普段私がイラストを制作するときは主にiPad版のCLIPSTUDIO PAINTとAdobe Illustratorを使用しているのですが、他に面白いペイント系アプリがないか(ブログのネタ作りのために)色々インストールして試したりしています。

(前回試したアプリの記事はこちら

今回は「コンセプト」というアプリをインストールしてみました。

すごくいいUIだなと感じたのが、インストールしてから最初にキャンバスを開いたとき、初期設定がこのような形で自動で開かれることです!

これのおかげで設定のボタンが右上のこの場所にあることがすぐに理解できるし、逆に「設定をすべて完了しなければアプリが使えない」ということもありません。

左利きの私としては、利き手の設定が初期設定の一番最初にあるのが優しいなと感動しました!

他のアプリだと利き手の設定はわざわざ環境設定を開かないといけなかったり、そもそも利き手の設定がある事自体気が付かないことも多いので。

ここから色を選べるようです。

すごい…

「コピック」という文字がある通り、色塗りマーカーであるコピックの色番号が各色に書かれています。

コピックを普段から使っている人だと、実際のコピックで塗った色をデシタルでも使いたい!デジタルで塗った色をコピックでも塗りたい!と思ったときに楽ですね。

ブラシはここから増やすことができます。

レビューを見た感じだと建築関係のお仕事の方がよくこのアプリを使用しているようでした。

そのためか、「外壁」という有料のブラシセットが…!

パステルやエアブラシ、漫画のトーンのようなセットもありました。

この中にあった「Memphis模様」という、パターンが入れられるブラシセットを購入してみました。

このようなかわいい模様がすぐに入れられるブラシが20種類入っていました!

柄物が好きなので、こういうブラシがあるのはとてもいいなと感じました。

設定はこんな感じ。

機能が多すぎないからこそだと思いますが、ボタンが大きくてシンプルでわかりやすい。

キャンバスの背景が変えられたりグリッドに種類があるのも便利でいいですね!

アートボードのサイズ無限って初めて見ました。

ちなみにCLIPSTUDIO PAINTの設定はこんな感じ。

機能の数が違うので仕方がないですが、コンセプトの設定画面がわかりやすいのがわかりますね。

まとめ

たくさんの色を使ったりブラシを使い分けたり…といった本格的なイラスト作品を作るというよりは、ある程度決まったツールやカラーパレットでデザインラフを作るというのに向いていそうだなと思いました!

CLIPSTUDIO PAINTやフォトショやイラレなどのUIに慣れきっているせいで少し癖がつよいなと思ってしまいましたが、設定ページなどはシンプルで基本的に親切なUIだと感じました。

普段から、管理画面の設定周りのUIのデザインがごちゃつきがちになってしまうことに頭を悩ませているので、このあたりは色々と学ぶことが多いなと思いました…!

[Solr]バックアップの置き場をS3にする

Solr には予め設定しておいたレポジトリにバックアップする機能があります。
レポジトリには以下の種類があります。

  • ローカルファイルシステム
  • HDFS
  • GCS(Google Cloud Storage)
  • Amazon S3

ここではローカルファイルシステムとS3の設定例を見てみます。

LocalFileSystemRepository

バックアップレポジトリの設定は solr.xml に書きます。

<backup>
  <repository name="local_repo" class="org.apache.solr.core.backup.repository.LocalFileSytemRepository">
    <str name="location">solr/backup_data</str>
  </repository>
</backup>

LocalFileSystemRepository の場合、設定項目は location だけです。

以下のようにAPIを利用してバックアップを実行した場合、Solr のインストールディレクトリを $SOLR_DIR とすると $SOLR_DIR/server/solr/backup_data/backup1 にコレクション backup_test のバックアップが作られます。

$ curl 'http://localhost:8983/solr/admin/collections?action=BACKUP&name=backup1&collection=backup_test&repository=local\
_repo'

S3BackupRepository

S3BackupRepository を使うためにはプラグインの設定が必要です。
$SOLR_DIR/server/solr/lib を作成し、dist/solr-s3-repository-8.10.0.jar と contrib/s3-repository/lib/*.jar をコピーして
solrconfig.xml に以下を追加します。

<lib dir="./lib" />                                                                                                     

レポジトリの設定はsolr.xmlに追加します。

<backup>
  <repository name="s3_repo" class="org.apache.solr.s3.S3BackupRepository" default="false">
    <str name="s3.bucket.name">XXXX.splout.co.jp</str>
    <str name="s3.region">us-west-2</str>
  </repository>
</backup>

s3.bucket.name でバケット名を、s3.region でリージョン名を指定します。
その他に S3 のエンドポイントを指定する s3.endpoint、プロキシを設定するための s3.proxy.url, s3.proxy.useSystemSettings \
があります。

上記の設定例の場合、以下のようにAPIを利用してバックアップを実行した場合、s3://XXX.splout.co.jp/backup2 にコレクション backup_test のバックアップが作られます。

$ curl 'http://localhost:8983/solr/admin/collections?action=BACKUP&name=backup2&collection=backup_test&repository=s3_re\
po'

10インチの電子ペーパータブレット BOOX Note Air2

数学の勉強をしていると手書きの機会が多くなります。紙と鉛筆で書きながら考えるというスタイルです。本物の紙を使う場合、あらかじめ用意しておくとか計算が終わった後に捨てるとかが面倒になってくるので、タブレット端末を使うようにしていました。

ただ、タブレット端末にはいろいろな使い途があって家の中のあちこちに持ち歩くため、ぱっと手書きしたいときに手元に無かったりします。そこで、読み書きに特化した電子ペーパータブレットを買って使うことにしました。

購入したのは BOOX Note Air 2 という10.3インチの E-Ink タブレットです。
製品の立ち位置としては、電子書籍リーダー&手書きノートといったところです。
価格はおよそ6万円。

Kindle と大きく異なる特徴は以下の通りです。

  • 画面が大きい
  • Android 11 なのでアプリをインストールして複数の書籍リーダーを使い分けられる
  • ペンデバイスを使って手書きできる

普通のAndroidタブレット(+ペンデバイス)との違いは以下の通り。

  • モノクロ
  • 端末自体はそれなりの処理能力をもっているものの、E-Ink なので画面の書き換えはもっさり。ゲームとか動画閲覧とかは実用できない
  • 軽い
  • バッテリーの保ちが良い
  • 目に優しい

普通の液晶画面が見づらいとか見てて疲れるとか感じたことがない人間としては、どうしても E-Ink でなきゃダメという点は正直ほとんど無く、かなりロマン側に倒した選択ではあります。要は使ってみたかったということで。

画面の表示は綺麗で電子書籍リーダーとしての品質は高いと思います。10インチあるのでPDFの書籍や論文も読みやすい大きさで表示されます。

手書きはスムーズで、書いたときのペン先の感触もとても良い感じです。

計算したり図を描いたりするときにいつも手元にあってすぐに書き始められないと紙の代わりにはなりませんが、Note Air 2 はその条件を満たしてくれます。2ヶ月ほど使った段階では思い切って買ってみて良かったなと思っています。

[Solr]分散検索でどのレプリカに検索リクエストを送るのかを制御する

SolrCloud でシャードに複数のレプリカを作った場合、検索リクエストを処理する際にどのレプリカを優先するのかを shards.preference パラメータで指定できます。

以下の形式で優先順を指定します。
shards.preference=属性1:値1,属性2:値2,…
左側にあるものほど優先度が高くなります。

指定できる属性は以下の通りです。

replica.type

レプリカの種類(PULL, TLOG, NRT)を指定します

replica.location

http://hostname:port から始まる文字列でレプリカの場所を指定します。前方一致でレプリカを選びます。

特殊なケースとして “local” を指定した場合、リクエストを処理するサーバと同じサーバにある Solr インスタンスのレプリカが選ばれます。フィールド数が多い、巨大なフィールドがある、などの理由で検索結果のデータサイズが大きい場合に有効です。特定のレプリカに障害が発生した場合の影響範囲を小さくする効果もあります。

replica.base

優先順位が同じレプリカが存在するときに、それらの間でどれを優先するかを決めるためのルールを指定します。

  • random ランダムに1つ選びます
  • stable:dividend:パラメータ名 指定したパラメータに対応する整数値をレプリカ数で割った余りで決定します
  • stable[:hash[:パラメータ名]] 指定したパラメータに対応する文字列のハッシュ値をレプリカ数で割った余りで決定します。パラメータ名が指定されない場合はメインのクエリである q の値が使われます。

node.sysprop

指定したシステムプロパティの値が同じレプリカが選ばれます。
たとえば同じラックに属する Solr インスタンスが同じ rack プロパティの値を持つように -Drack=rack1 のように設定しておき、検索時に shards.preference=node.sysprop:sysprop.rack を指定すると、リクエストを処理している Solr インスタンスと同じ rack プロパティの値を持つ(=同じラックに属する)レプリカが選ばれます。

replica.leader

リーダーレプリカを優先するかどうかを true または false で指定します。たとえばレプリカが6台ある状態で replica.leader:false が指定されるとリーダー以外の5台が分散検索の対象となります。