00:06
6月14日、火曜日ですね。
地獄は朝9時を回りました。
今日の東京は、ちょっとあいにくの曇り。
途中ながら、雨が降るらしいですね。
はい、おはようございます。ゆめみのキースことくわはらです。
では、本日も朝活を始めていきたいなと思います。
昨日まで、Solid.jsとSplitの比較記事を読んでました。
で、今日何を読むかなというところで、悩んだんですけど、
もう何かいくつか読みためたものを、どんどん紹介していこうかなと思います。
あと、Kさんですね。おはようございます。
今日もご参加いただきありがとうございます。
普通のどんさんもですね。はい、ご参加いただきありがとうございます。
ちょっと今日は、読みためたものを、だらだら紹介していこうかなと思っているので、
今日は3記事まで読めたらいいかなと思っていますので、
ゆるーと聞いていただけば幸いです。
じゃあ、では読んでいきます。
1つ目ですね。1つ目ですけども、
3日前に公開された、CSS設計における全てがコンポーネントであるという語尾、
というタイトルですね。はい。
これを読んでいこうかなと思います。
自分にCSSについて勉強しようかなと思っていたので。
はーい。
今回はひたすら思想とか思考に関する記事っぽかったので、
一行もコードが出てこないですからね。
ちょっとそこを読んでいこうと思います。
じゃあ、いきますね。
ベムによって持たされたコンポーネントベースのアプローチでは、
ページはコンポーネントの集合によって表現されるべきであり、
ページに含まれるのは全てがコンポーネントであると考える。
しかし、これまでCSSを書いてきた経験から、
これではデザイン意図をまともに表現することができないと感じ始めた。
なぜなら、普通デザイナーは、
ページの全てがコンポーネントであるとは考えないからだ。
はい、まあそうですよね。
コンポーネントであるというふうに考えていくのは、
我々、確かエンジニアの方で、
デザイナーは確かに全てがコンポーネントであるとは考えるとは限らないですよね。
もちろん考えていただけたらすごく嬉しいですし、
それに基づいてデザインを起こしていただければ、
デザイナーとの連携も確かに強いとは思いますよね。
ですけど、まあそうでは限らないよということでした。
もちろんそのページの構成要素の中には、
明らかにそれがコンポーネントであると意識して作られたものももちろんあって、
ただしそれは一部であり全てではないですと。
コンポーネントもあればコンポーネントではないものもあるという感覚の方が、
本来は普通なのだと言ってますね。
で、典型的なUIライブラリーにある
ザ・コンポーネントみたいなものだけではページは完成しないと。
例として一貫してBEMに則って実装されている、
BEMの公式サイトにあるメソドロジーのページ、
そんなのがあるんですね。
メソドロジー、初めて聞きました。
ちょっと後ほど見てみたいと思います。
のコードを見てみれば、
これは本当に僕らが頭の中に思い描くコンポーネントなんだろうか、
という疑問が浮かびますと。
全てがコンポーネントであるというのはこういうことだと。
本当に確信を持って、
これこそがコンポーネントであると認識ができるのは一部分でしかない。
僕は以前まではあくまでCSS設計の作法に則って、
03:00
全てをコンポーネントとして表現しようと努めてきた。
デザイナーが作ったデザイン幹部からルールを見出して、
自分なりに解釈し、
ページに境界を引いて、
名前を付けてコンポーネントとして分解する。
これを隅から隅まで徹底した。
その買い合ってか、
この設計はある程度は機能しているかに思えた。
しかしある時、
テンプレートの条件分岐が増えて複雑な仕様になっていくにつれて、
なんとなくうまくいかない感じが浮かび上がってきた。
いくつか出てきます。
例えばそれは、
一つのコンポーネントとして表現していたセクションが分かれて、
別々の箇所に配置されることになったので、
コンポーネントを二つに分解して作り直すことになったりとか、
だいたい同じような感じだけど微妙に違うみたいな。
それも偶然似ているだけなので、
共通ができないパターンが登場して、
個別にコンポーネントを何種類も作ることになったりとか。
また部分的に見ると、
これまで繰り返し何度も登場しているように思えるスタイルなのに、
コンポーネントとしては別物なので、
都度都度新しくコンポーネントを書き足さないといけなかったり、
本当にちょっとした要素を追加するために、
ちょうどいい既存のコンポーネントが存在しなければ、
わざわざそれだけのために新しいコンポーネントを作ることになったりとか。
いろんな条件分岐とかテンプレートのパターンが増えていって、
仕様が複雑になっていくというところで、
要は上手くいかなくなってきたなという感じがある。
というようなわけで、
見た目は大したことない変化なのに、
結果として割に合わない膨大な数のコンポーネントが出来上がってしまった。
これはきっと何かが間違っている。
これはでも僕も経験ありますね。
確かに。
このちょっとの変化のためにコンポーネントを新しく作るかって、
いつも悩みながら、
でも作った方が視認性だったりとか可読性はいいよね、
みたいな思ったりとか。
いろんな先のことを考えると、
分けとくかっていうのを結構やりがちではありますよね。
かといってコンポーネントの中に条件分岐を盛り盛りにするかって、
そんな気持ち悪いコンポーネントを作りたくないですからね。
で、戻りますね。
問題は、
全てがきっちりとコンポーネント化されたデザインができていないことではない。
デザインとコードでルール化の観点がずれていることだということですね。
それは確かにそうかもしれない。
で、この場合、CS設計上のコンポーネントの多くが、
デザイナーの頭の中にあるイメージと非対照的な構造になっている。
エンジニアの頭の中にしかない、
元のデザインを独自に解釈した別物を作り出してしまっている。
つまり、これでは変更に対応できるかという以前に、
現状に対応できていない。
そうですね。
今のデザインが正しく表現されていない。
そうですね。
デザイナーが出してきたものをエンジニアが独自に解釈して、
別物として作り出そうとしている。
それは確かにそうですよね。
はっきり断言されると、本当にその通りだというのを、
改めてちょっと笑っちゃいました。
続きます。
たまたま近くにあっただけのものを、
一つのコンポーネントとしてまとめたり、
偶然そうなっているだけのものに、
06:00
意図を見出して抽象化したりして、
変更が発生してから間違った構造化がなされていたことに気づく。
あるいは、もっと細かなルールが見落とされてしまう。
こうした取り違いが、コンポーネントありきの発想によって誘発される。
コンポーネント化するということは、解釈を加えることだ。
だから、変更に対応するたびに、
間違った解釈を修正するという不必要な痛みが伴う。
CSS設計はコンポーネントというものに、
ちょっと固執しすぎていたというふうに言っていますね。
いや、面白いですね。
確かに固執していた。
そうかもしれないですね。
そもそもコンポーネントにするよねという前提から確かにスタートするので、
CSS設計って確かにコンポーネントですもんね。
いやー、なるほどでした。
つまりこれは、実装技術側の方法論的な問題である。
すべてをコンポーネントにするアプローチ自体に無理がある。
本当にそれがコンポーネントだと言い切ることができなかったとしても、
コンポーネントとして表現する以外にやりようがない。
これが設計を歪ませるのだと。
ではどうしようかというところですけど、
ページはもっと一色多になっていると考えていいと思う。
不可分な要素もあって然るべきであり、
必要を超えた構造化は害になる。
その方が現実に即している。
コンポーネントとは別に、
より植物的な表現方法が必要だ。
そういう意味でもユーティリティファーストなのだと。
いや、ブートスラップでさえユーティリティファーストとまではいかなくても、
大量のユーティリティクラスを取り入れている。
はぁはぁはぁ、なるほどですね。
そうすると、テイルウィンドウって結構それに即しているって話になりそうですよね。
テイルウィンドウCSSは。
めちゃめちゃユーティリティクラスの塊でしかないですからね。
言ってしまうと。
ビジュアル的な観点では、デザインルールはコンポーネントごとに区切られているわけではない。
サイト全体など特定のコンテキストにおいて一貫した印象を与えるために、
意図的に共有している要素はある。
それは例えば、タイプグラフィーだったり、余白だったり、色やグラデーション、形状や影といったものっていうですね。
ページ上のあらゆる要素っていうのは、コンポーネントであるかどうかという依然に、
基本としてこれらのマナーに則っている。
だとすれば、セレクターという観点においても、
これらそのものを直接的に指し示すクラスがあってもいいはずであると。
わざわざコンポーネントのクラスを経由する必要はない。
必ずしもセマンティックなクラス名でなかったとしても、これはまた一つのルールであるというふうに閉じられてますね。
これはこの人の一つの考え方であり思想であって、なるほどっていう感じはありますけど。
まあでもCSSの設計において全てがコンポーネントっていうところに立脚した、
今の開発的思考っていうところに疑問を呈したっていうのは一つの面白い記事だと思いますし、
共感する面はすごくあって、なるほどなと思いはするんですけど、
とはいえコンポーネントのメリットを享受したいっていう我々の思いもあったりはするので、
落としどころをどうするかっていうのは結構大事だと思うんですけど、
09:02
ただ前提として、そもそもの考え方というところですよね。
捉え方、考え方っていうところがデザイナーと僕らでずれているっていうか、
観点が違いますよねっていうのをちゃんと認識した上で、
次どうするかっていうのを考えていくのがすごく重要だなということで、
とてもありがたいご指摘の記事だったなというふうにちょっと思いましたね。
なるほどですね。
はい、というところでした。
じゃあ一旦この記事はここで閉じていこうかなと思います。
とても面白かったし、皆さんも何かしら感じるところはあると思いますけども。
はい。
じゃあ次の記事ですね。
次は何読むかすごく悩んだんですけど、
とりあえずあのTechFeedのランキング上位の中から一つ選びました。
せっかく最近ソリッドばっかり読んだので、
リアクトからソリッドに何か移し替えた記事ないかなっていうのを探してみたら、
たまたまあったのでそこを見ていこうと思います。
リアクトからソリッドに変えましたっていう禅の記事ですね。
いいね120ぐらい来てて、ざっと読んだ感じ良さそうだったので、
改めて読み直そうと思います。
一応ソースコードも出てくるんですけど、
コードは適宜読まないように頑張ろうと思ってます。
じゃあ一つ読んでいきますね。
趣味でプログラミングしていて、
ライブラリをリアクトからソリッドに変えたので、
変えるときに気をつけたことを書きますと言ってます。
まず大前提、クラスコンポーネントを関数コンポーネントにするっていうところですね。
もちろんソリッドにはクラスコンポーネントという概念がそもそもないので、
関数コンポーネントに全部書き直さなきゃいけないってところです。
今、モダンな開発環境でやられている方はリアクトを
基本的には関数コンポーネントに書かれていると思うので、
そこはあんま問題ないと思いますけど、
書き方時はちょっと気をつけるぐらいの感じですね。
続いてフック関数を変えるというところです。
いわゆるリアクトのフックスっていうものが、
ソリッドのいわゆるベーシックリアクティブっていうものに書き変わらなきゃいけないってことですね。
使い方は結構似てると思うんですけど。
1個見ていくかというところですね。
1つ目がやっぱり我々大好きユーズステイトですね。
ユーズステイトはソリッドJSで言うとこのクリエイトシグナルっていう関数になるので、
これを変えますと。
ただですね、クリエイトシグナルの戻り値ですね。
戻り値の1つ目はゲッター関数になっているところがユーズステイトの違いですね。
なので値を取りたい場合はゲッターの括弧で実行しないと値を取れないよっていうところだけ気を付けてくださいってことでした。
使い方はユーズステイトと全く一緒ですね。
クリエイトシグナルの初期値に何かすらの変数、値オブジェクトなんでもいいですっていうのを渡してあげて、
戻り値がもちろん配列で1つ目がゲッターで2つ目がセッターっていう感じになります。
というところでした。
今のが1つ目の書き換えで、2つ目はユーズエフェクトですね。
ユーズエフェクトをソリッドJSに書き換えると、
クリエイトエフェクトもしくはオンクリーンアップを多分一緒に使うことになるのかなと思います。
こちらも特徴としては、使い方は基本的に一緒ですね。
クリエイトエフェクトで中でコールバック関数を定義するというところです。
ユーズエフェクトとの大きな違いは、2つ目の引数がなくなっているというところですね。
12:04
その関数の中で作ったシグナルですね。
シグナルというのは先ほどのクリエイトシグナルのインスタンスの方ですね。
中で作ったシグナルで自動で依存関係を作るらしいというところですね。
また関数の戻り値がリアクトでは、次に呼ばれるときの前に実行されるクリーンアップ関数だったんですけど、
ソリッドでは次に関数が呼ばれるときの引数を戻り値にしてしまう。
ソリッドJSでクリーンアップ関数を作りたい場合は、既存のオンクリーンアップという関数があるので、
それを実行してくださいというところでした。
ここもちょっと特殊ですね。
それはそれでいいんじゃないかと思います。
ユーズエフェクトの場合はもちろん引数、2つ目の引数を足して、これが変化したときに実行するというのを明示的にできたんですけど、
ソリッドJSのクリエイトエフェクトの方では基本的には自動で検知をしてリアクティブに更新をしてくれるような感じになるっぽいですね。
続いてユーズレフですね。
リアクトのユーズレフに変わるものは今回ソリッドJSに実はないんですね。
ありません。
ソリッドっていうのはコンポーネント関数を最初の1回しか実行しないんですね。
なので宣言した値がサイレンダリングのときに変わることもないんですよ。
なのでJSXのレフに渡すときも変数をそのまま代入して使えちゃいますよという感じです。
リアクトの場合はユーズレフでカッコで戻り値を変数に受け取ってそれをレフイコールでアトリビュートとして渡してたんですけど、
ソリッドとしては普通にそのままJavaScriptの変数を定義しておいてそれをレフイコールみたいな感じでアトリビュートにセットして使うことができますよって感じでした。
続いてリアクティブにするっていうタイトルになってます。
ちょっと読まないとわかんないかもしれないんですけど、
ソリッドっていうのはコンポーネント関数を最初の1回しか実行しませんというところで、
なのでコンポーネントの中でシグナルを使った計算値とか関数呼び出しをそのまま書いても値は変更しなかったりとか1回しか実行されなかったりしてリアクティブでなくなっちゃいますよというところですね。
これをリアクティブにするためには値はそれを返す関数にして関数呼び出しはエフェクトの中で行ないようにしますというところでした。
ここだけちょっとコード長くてですね、ここはちょっと見ていただくのが一番わかりやすいかなと思います。
続いてJSXのループや分岐に特別なコンポーネントを使うというところですね。
ソリッドにはループや条件分岐をする特別なコンポーネントがあるのでそれを使います。
リアクトだとコンポーネントの中で波括弧で例えば配列.mapみたいな感じでループ回して、
その中のコールバック関数の中にJSXを書いてループして例えばリストを作ったりとかしたと思います。
15:01
なんですけどソリッドの場合は例えばSHOWとかFORとかっていう独自のコンポーネントがあります。
そのFORの中のコンポーネントでプロップスにE1っていう関数があるのでそのE1の中に配列とか渡してあげるとそのままバーッといけると。
その中の下にJSXエレメントを定義してあげればいいよという感じですね。
基本的にはJSXの中のループとか分岐っていうのはソリッド独自のコンポーネントを使うことをお勧めしてますよと言ってます。
もちろん使わなくて従来の書き方もできますけど、
やっぱりソリッドの本来持ってる機能であったりとかっていうものに乗っかりたい場合はやはり独自のコンポーネントカスタムコンポーネントを使う方がいいんじゃないかなと思います。
続いてプロップスのデストラクチャーをなくするというところですね。
ソリッドJSはリアクティブするためのプロップスのプロパティアクセスをゲット関数いわゆるゲッターにしてますよってことですね。
しかしデストラクチャーをすると関数からただの値になってしまってリアクティブなくなっちゃうと。
もしプロップスを分割したい場合はスプリットプロップスっていう関数があるのでそれを使ってくださいってことでした。
コンポーネントの頭の方でスプリットプロップスっていうのを定義しておいて、第1引数が受け取るプロップスなんですよね。
第2引数で分割したい値を文字列の配列にしてしまいますという感じですね。
受け取りとしてまた配列で受け取っていくって感じですね。
1つ目と2つ目。1つ目が分割したもので2つ目がアザーズなので残りのものっていう感じですね。
こんな感じでプロップスの分割したい場合はスプリットプロップスを使ってくださいってことでした。
続いてプロップスに値を渡すっていうところですね。
JSXの中はリアクティブにあるのでコンポーネント、ココンポーネントですね。
チャイルドコンポーネントには値を返す関数でなくて値そのものを渡していいと思っています。
これも確かにできますね。
チャイルドコンポーネントに例えばカウントイコールで本当にプリミティブな値を渡してあげても別にいいよってことですね。
これは別にリアクティブでも同じようにできると思いますけど、リアクティブの場合は結構変数化して渡すことが多いですよね。
もしくは関数そのものを渡すことも結構あったりしますけどね。
というところでした。
この記事に関しては一旦今ので以上ですね。
他にもいろいろやり方とかパターンはあると思いますけども、
一旦この人ここまでで止まってましたってことでした。
終わりにソリッドにしたらリアクティブの時よりもファイルサイズが小さくなってページ表示も早くなったのでよかったですってところですね。
こちらについてはですね、
昨日読んだ記事の中にあったJS Frameworks ベンチマークっていうサイトがあってですね、
そこのベンチマークの画像を見ましたけど、
やっぱりリアクティブは今結構スピード遅くなってるっていう感じですね。
遅くなってるというと言い方悪いですね。
相対的には遅い部類にランクされてしまったっていうのが正しい言い方で、
例えばバニラJSとかトリッドJS、スベルトもそうですけど、あとはRIT HTMLとかいろんなものがあって、
18:00
そっちの方が明らかに早いよねっていうのは計測結果としてデータが出ているんですね。
リアクトはそのいろんなものの比較の中で結構遅い部類にいたっていう感じです。
別にリアクト自体が遅くなったわけではなくて、
他のものがだいぶ早くなったし軽量になったっていう感じだと思いますね。
やっぱり高発ライブラリなので、その辺とかいろんなものを解決したりとか解釈できるようになったっていうので、
早くなったんだろうなっていうふうに受け取ってますけど。
ただやっぱり大規模に耐えうるかっていうとまだまだそこの辺の検証としては弱いし、
サードパーティーとかエコシステムを考えると結局リアクトが僕らの中にはやっぱりマッチするというか、
僕らの本当に寄り添ってくれるフレームワークなっていう感じはあるので、
結果使われるのはリアクトだと思いますけど、
ただソリッドは結構リアクト勢を食うんじゃないかなっていうふうに僕はちょっと感覚としては思ってますね。
ちょっと余談が過ぎましたので、この記事も一旦以上にしたいと思います。
今日最後に読むのはですね、3つ目、テクニカルライティングの基本っていうところですね。
ちょっとここはあまり技術的な内容じゃないんですけど、どうしても読みたくなったなっていうので、
今後僕らがドキュメントを書いたりとかライティング、何か物書きをするときの基本として知っておいた方がいいという概念っぽかったり、
読んでいきたいと思います。
サイゴーズさんの記事ですね。
開発本部テクニカルコミュニケーションチームの沖田さんという方が書かれた、
今年の5月17日に開運研修2022っていうタイトルの中でやられたものですね。
ちょっとこれを勉強していきたいなと思います。
もし既に読まれた方としては重複するので、ゆるーと聞き流していただければと思います。
じゃあ行きましょうかね。
テクニカルライティングっていうのは、読者や目的に合わせて技術をわかりやすく伝える手法であります。
皆さんはこれからドキュメントを書く機会が多くあるでしょう。今後も多くあるでしょう。
例えば報告書や企画書を書きます。
業務マニュアル書きますとか、製品や機能の解説書を書きます。
作業手順書を書きますとか、製品の仕様書を書きますとか、何やらかんやら書きますと言うんですけど、
ドキュメントはやっぱり多くの人に読まれますと。
それはもちろんそうですね。そのために書いてますから。
もしくは未来の自分が読むために書きますね。
書き手の工夫で多くの人の時間を節約できますと。
この節約ってのは読む人の時間を節約できるっていうことだと思います。
書き方の方法論を学ぶことで書き手の時間も実は節約できるようになりますと。
ここが結構重要ですよね。
確かに僕らは読む人のことを結構考えてドキュメント化することも多いですけど、
僕ら自身の時間も節約できるっていうのが方法論があるので、そこを勉強していこうという感じですね。
チームワークのためには情報共有はもちろん欠かせません。
良いドキュメントを書くことは、非効率者が効率的な情報共有につながりますと。
もちろんそうですね。
テクニカルライティングの適用対象としては、いわゆる実用文が求められるもの。
例えば議事録、報告書、技術書とか仕様書、いわゆるFAQなどだといったところですね。
21:01
1つ目、ドキュメントの前提1ですけど、求める情報が人によって違う。
これはその通りでしょう。コンテキストによって全然求めるものは変わりますからね。
ドキュメントの前提2ですけど、こちらは情報の探し方も違う。
例えば知りたいことが明確になっている人は最初から作業Aの手順書を知りたいというのでアクセスしますね。
知りたいことが曖昧な人とかは、とりあえず入社したばかりでわからないからざっと調べますみたいな感じ。
あとは網羅的に知りたい方っていうのは、作業書ABCとか一通り全部知っておきたいみたいな。
なので探し方がやっぱり違うしコンテキストとかも違いますよねってことですね。
ドキュメントの前提3つ目、1位に伝わる必要がある。
求めたものがあったらその求めたものの情報を得られるようにしておかなきゃいけないってことですよね。
1対1であるようにしてほしいってことですね。
ドキュメントの前提4、ここすごい大事です。
一部しか読まれないですね。これは僕らもそうだと思います。
ドキュメントの隅から隅までガーッと読んでる暇とか時間がなかったり。
欲しい情報って大体そのドキュメントの中でもピンポイントここしかなかったりするってもちろんあったりするので。
一部しか読まれないってことでした。
テクニカルライティングの要素ですね。ここからは方法論に入っていくっぽいんですけど。
3つの要素があって、1つはエフェクティブネスですね。
必要な情報を正しく得られるエフェクティブネスが1つ目。
2つ目はエフィシェンシーですね。
効率よく理解できるっていうところでした。
3つ目がサティスファクション。
不快さがなくて肯定的に受け止められる。
満足するっていうところですね。
この3つの要素がテクニカルライティングの要素でした。
それぞれの要素に対して取る手段っていうのがそれぞれ変わってくるというところですね。
1つ目のエフェクティブネス。
必要な情報を正しく得られるっていうところに取る手段としてはとにかく曖昧さを廃して明確に書きますとか、
できるだけ具体的に書きますとか、誤解なく読める文章で書きますっていうのがエフェクティブネスですね。
2つ目エフィジェンシーの方ですけども、
こちらは情報を適切に整理して構造化してあげますよとか、
どこに何が書いてあるかをわかりやすくする。
簡潔で読みやすい文章で書くとか、
必要な情報だけを書くっていうのがエフィジェンシーですね。
効率化っていうところですね。
最後サティスファクションですね。
こちらももちろん肯定的な表現で書いたり、デスマス調で書きますとか、
過剰な敬語にはしなくていいよとかですね。
とにかく不快さとかなく肯定的に受け止められるようにしようと。
この辺を取りましょうと言ってますね。
テクニカルライティングの進め方というところです。
大きく3つに分かれていて、
1つ目はスタイル情報を整理する。
2つ目はアウトラインを作る。
3つ目はわかりやすく簡潔な文章で書く。
この3つですね。
1つずつ見ていきましょうと。
スタイル情報を整理するというところですけど、
整理の鉄則は概要から具体へ、または全体から部分へというところですね。
マクロからミクロへという感じですね。
これが鉄則だという話でした。
24:01
まずマクロを見るというところが重要っぽいですね。
概要としてはガッと書いていくんですけど、
それを分解して具体化にいっていくと。
全体の場合は構成要素でどんどん分解していくという感じですね。
例えばスタイルテーマ1つドーンとあるじゃないですか。
大テーマがあったときにこれをテーマ1、テーマ2とかで分解していきます。
さらにテーマ1、テーマ2はそれよりさらにテーマ1の1、1の2とかいう感じで分解できますね。
その先も一緒。1の1の1、1の1の2みたいな感じで分解できますよねという感じです。
どんどん分解していきましょう。
書籍とか文章を書く場合はですね、分解の1個目のレイヤー、テーマ1というのが章になります。
さらに分解した1の1とかは節になります。
さらにそれを小さくした1の1の1までいったら項になる。
章節項ですね。というふうに分けますよという感じです。
ウェブの場合ですね。
ウェブサイトの場合は1つ目のレイヤー、テーマ1の場合はカテゴリーになって、
そのもう1個下ですね。テーマ1の1とかに分割するとページになります。
で最後3つ目ですね。3つ目のレイヤーでは見出しになりますという感じですね。
カテゴリー、ページ、見出しというふうに分解をするでしょうというのがウェブページの場合ですね。
というふうにこの人は言っています。
とにかく全体から部分へと分解をしていきましょうというところがとにかく鉄則です。
概要から具体へと分解をしていきましょうというところですね。
今回はちょっと見せられないんですけど、この人は木構造で書いてますね。
左から右への木構造でどんどん分解して書いてあるという感じです。
大事なことも1個書いてます。
分解するといいんですけど、順に説明を展開していくように分解していくことが重要ですよということですね。
段階を追って知識を付け加えていくことが分かりやすさにつながるので、ここが重要ですよというふうに言ってますね。
情報を適切に分解すると読者が情報を探しやすくなるので、ここの分割を気をつけてください。
例えば前提知識がない人は最初から読み興味を持った項目へとどんどん進んでいきますよとかですね。
触りだけを知りたい人は概要だけを読んでいきますとかですね。
特定の知識が欲しい人はその項のほうまで入っていきますよという感じですね。
やっぱり人によって何を求めるか全然違うので、その人に沿った情報にちゃんと分けておくのが大事。
だからどこに何が書いてあるかが分かるように適切なタイトルと見出しをつけましょうとおっしゃってますね。
分解には実は複数のやり方があるという次の話になっていて、
情報整理の例として良いヘルプの要素を分解するというふうに書いてますね。
例えば良いヘルプという大きな一つのカテゴリがあったら、役に立つとか探しやすい、分かりやすい、正しいみたいなふうに分解できますよねと。
役に立つのをさらに分解するとターゲットユーザーの設定だったりとか情報の収集方法だったり、
探しやすいは情報の分類とかタイトルや見出しのつけ方とか、あとは検索の最適化とかですよね。
分かりやすいとかは用語の統一をしたり、読みやすい文章の書き方とかですね、あとは図解をしたりとかっていう感じです。
27:04
まずは良いヘルプの要素をどんどん具体化をしますと。
その要素ごとにどうすれば致されるかっていうのを考察していきましょうという感じですね。
なんかリンクが貼ってありますけど、ヘルプサイトの作り方っていう書籍があるっぽいですね。
これも結構参考になるよっていうふうに載せてます。
では続いて情報整理の例ですね。
説明の構成に反映をするというふうに書いてますけども、
例えばヘルプサイトの作り方って先ほどの書籍ですけども、書の構成としては、
誰に何を伝えるかを整理してユーザーの使い方を意識して構成を設計して、
ユーザーの動線からナビゲーションを設計して、
スタイルガイドと用語集を準備しておいて、記事を書く。
あと文章とか図解のテクニックとかをそこに盛り込んでいくっていうような感じですね。
というのが一つの構成の例でしたというところですね。
こんな感じで、とにかく情報の整理をしていきましょうというのがテストコースの一つ目でした。
二つ目はアウトラインを作るという大きなところに行きますね。
アウトラインを作るんですけど、記事で伝える情報をまず書き出しましょうと言っています。
例えばテーマでは、この細胞さんの記事なので、
均等でアプリを開発する方法を解説するっていうふうなテーマになったとしましょう。
この時に伝えることを書き出した例としては、
アプリ開発を開始する前に必要な準備だったり、開発中のアプリを保存し中断する方法だったり、
保存したアプリを開いてアプリ開発を再開する方法だったりとか、こんな感じですね。
とにかく均等でアプリを開発する方法を解説するための伝えることを書き出した例ですね。
ポイントとしては2つあって、この段階では順番や言葉の表現など細かいことはとにかく気にしないと。
情報を漏れなく洗い出すことがまず重要なので、そこを重視しましょうというところですね。
いいですね。なるほどなるほど。
続いて書き出した情報を今度は整理していくと。
さっきの結構にやっぱり紐づくものはあるなと思いましたけどね。
待って、ダラダラ読んでいったんですけど気づいたら9時半が来てしまいましたね。
日時的にはあともう結構長いな。長いのでどうしようかな。
あと10分くらい?10分いかないかくらいかな?かかると思うんですけど、
僕はこのままちょっとダラダラ読んでいきたいと思います。
時間がオフする方は全然抜けていただいて構いませんので、僕はこのままちょっと続けていきたいかなと思いますね。
何だっけ。書き出した情報を整理するってことですね。
例えば伝える情報を整理した例ですけど、アプリ全体の流れとか、
次に簡単なアプリを例にしたアプリ開発の手順とかですね。
もちろん準備だったり開発手順、アプリのアイコンの作り方だったりとか、
アプリを保存して中断する方だったり、
あとはエラーの対処法だったりみたいなところですね。
どんどん整理をしていきましょうってところでした。
ここでもポイントが述べられていて、まず概要を述べます。
読者がどのように情報を探そうとするかを意識して情報を整理します。
30:02
どのタイミングで必要になる情報かを意識して項目を並べ替えるというところですね。
それに伴った見出しをどんどん決めていきましょうというところでした。
こちらもポイントとしては、読者が次の情報を読み取れる言葉にすることを意識しましょうと。
見出しに続く本文に何が書かれているか、どのような時に読む必要があるのかっていうのを
分かるようにしておくといいよという話ですね。
見出しの構造の例でいきますと、先ほどの続きなんですけど、
スタートにアプリ開発の流れっていうのを見出しで決めてます。
次にアプリを開発しようという見出しを決めておいて、
そのサブの方で開発を始める前にとか〇〇を設定しよう、
アプリのアイコンを作ろう、開発を中断する場合みたいなところですね。
次の章としてアプリ開発中にエラーになったら、最後にアプリにキーを追加しようみたいな感じで
どんどん見出しを決めていくと、
どの人がどの情報を欲しいって時にこの作品から見ていくって感じでやりますね。
続いて分かりやすく簡潔な文章で書くっていうところですね。
書く時の心構えですけども、読者の行動をイメージしながら書くっていうところですね。
どんな人がどんな情報をどのように探すのかっていうところですね。
アクションをイメージしながら書きましょうと。
読者の視点で書くってところですね。
自分ではないっていうのが結構重要らしいですね。
読者の視点で書きましょう。
そして簡潔にかつ短文で書くですね。
できるだけ短い文章で書くってことです。
これはすごく納得感というか共感がありますね。
最後に重要なことから書くっていうところですね。
これ多分人間の脳みそとかキャッシュメモリーの限界があるので、
後から後からどんどん重要な情報を追っていったところで、
多分忘れてしまう可能性があるっていうのもあると思いますけど。
あとインパクトが弱まっていくっていうのもあるかもしれないですね。
重要なことから書く。
ここが一番最初に解説きましたね。
ってことはやっぱりこれが重要なんだ。
before afterが例文としてあります。
beforeはシステムを正常に起動できなくなる恐れがあるので、
アップデート中は電源を切らないでください。
っていうのがbeforeの文章でした。
afterの文章ですね。
アップデート中は電源を切らないでください。
で、システムを正常に起動できなくなります。
めっちゃわかりやすいですね。
確かに。とにかく電源切るなってことは言ってますね。
ポイントとしては、
ドキュメントは一部しか読まれないってことをやっぱり前提に書くと。
で、情報に優先度をつけて優先度が高いことを先に書きましょうって言ってますね。
伝えたいことは確かにそうですよね。
アップデート中にとにかく電源切るなってことが言いたいので、
説明がダラダラだから切らないでくださいじゃなくて、
切るな、なぜならっていう説明のほうがいいよってことですね。
で、1文1義で書く。次の話ですね。
1文1義ですね。
before afterまた聞いてます。
beforeはですけど、
サイボーズオフィスはクラウド型グループウェアで情報を共有する各種機能、
メッセージ機能やワークフロー機能などを備え、使いやすさが特徴です。
のがbeforeでした。
長いな。
33:00
で、afterですね。
afterはもう単文で3つに分かれてます。
サイボーズオフィスはクラウド型グループウェアです。
情報を共有する各種機能、メッセージ機能やワークフロー機能などを備えています。
使いやすさがサイボーズオフィスの特徴です。
こちらは確かに分かりやすいというか、伝わりやすいなって感じがしましたね。
ポイントは1つの文には1つの事柄だけを書きましょうと。
1文に複数の事柄が詰め込まれていると、内容を整理しながら読まなくてはならなくなるというので、
読み手のコストがかかりますよね。
エネルギーを使うことになるので、確かにそれはそうだなと思いました。
続いて、簡潔に書くというところですね。
また同じようにbefore、after、さらに改善って今回3つありますね。
beforeは他のユーザーの連絡先を確認でき、
また他のユーザーにメッセージを送ることもできます。
afterは他のユーザーの連絡先を確認できます。
また他のユーザーにメッセージを送ることもできます。
さらに改善ってことです。
さらに改善はさっきのまたを削ったわけですね。
他のユーザーの連絡先を確認できます。
他のユーザーにメッセージを送ることもできます。
とにかく簡潔かつ短くを常に意識しましょう。
したがってまたはなどの接続詞も不要なことが結構多いよねってことでした。
まあそうね。
使いがちなんですけど別に使わなくても伝わりますもんね。
それはそうかもしれない。
もう既に持っているのがありますからね。
はい、で最後読者の…最後かな?
まだありましたね。
読者の指定で書きますと。
はい、でこちらもですね。
before afterあります。
beforeはニュースレターに登録していただくと、
製品のアップデート情報をメールで送りしますと。
afterはニュースレターに登録すると、
製品のアップデート情報をメールで受け取れます。
というところですね。
読者の指定で書くと、
読みやすさと分かりやすさにつながりますというところと、
システムが主語になっていると、
自分視点に置き換えながら読まなくてはならなくなるので、
ここを結構意識すると大事ですよと言ってましたね。
はい。
続いて受動体と能動体を使い分けましょうと言ってますね。
ほう。
beforeですね。
削除をクリックするとすべてのデータを削除しますと。
でafterは削除をクリックするとすべてのデータが削除されます。
というところですね。
はい。
あーなるほどですね。
そこが結構重要ですね。
確かに。
受動体の方が伝わりやすいですね。
はい。
読者の指定で書くと、
読者の操作は能動体にあるんですけど、
システムの動作は受動体になるよというところですね。
はい。
結構これ細かいけど大事ですね。
はい。
続いてできるだけ具体的に書きましょうと。
はい。
例えばbeforeですね。
メール通知の設定を確認してください。
間隔を少しだけ空ける必要がありますと言うんですね。
でafterですね。
メール通知が有効になっていることを確認してください。
3から5ミリ秒の間隔が必要ですよと言うんですね。
ごめん嘘。
ミリ秒じゃないですね。
3ミリメートルでした。
薄い。
ていうところですね。
はい。
ポイントとしてはとにかく曖昧な表現を書き手の意図通りに
曖昧な表現は書き手の意図通りには伝わらないので
具体的に書く努力をしましょうと。
はい。
さっき読んだ例えばメール通知の設定を確認してくださいと言われると
ちょっと曖昧で
メール通知が有効になっていることを確認してください
36:01
っていうのがより具体的な話ですよね。
ていうところでした。
はい。
あとは工程形で書くというところですね。
はい。
beforeは5名以上の予約は受け付けられませんと言っています。
でafterは4名まで予約できますという風に工程的ですね。
はい。
やっぱりネガティブな印象を招く可能性があるし
理解に時間がかかる可能性もあるので
否定表現はやはりやめましょうと。
で、工程的に書き換えることで
簡潔でポジティブな印象にもなりますよねってことですね。
はい。
さらに二重否定を使わないですね。
はい。
これ結構意識しますけど。
はい。
before afterいきます。
ファイルA以外は削除しないでください。
はい。
でafterですね。
ファイルAだけを削除してくださいっていう感じですね。
はいはいはい。
でですね。
否定表現を使う場合は1つの文章の1つまでというところですね。
で、二重否定というのは文章を分かりづらくして
読者の混乱を招くのでやめましょうという風に言っています。
はい。
確かにね。
で、次。
係り受けを明確にする。
はい。
これはちょっと文章として見たほうがいいですね。
beforeですけど。
消毒液Aのように刺激の強くない消毒液を使ってください。
はい。
こうやって書くと消毒液Aを使っていいのか分からないですよね。
使っていいのかどうなんでしょうってことですけど。
afterの方ですね。
消毒液Aのような刺激の強くない消毒液を使ってください。
または、消毒液Aのように刺激の弱いものを使ってください。
という感じですね。
こうすると一応消毒液Aも使えるってことですよね。
はい。
係り受けが不明確な文章ってのは全く逆の意味に受け取られる可能性があるので。
はい。
ここは意識しましょうってところでしたね。
はい。
ではラスト2つですね。
主語と目的語、述語を近づけましょうと言ってます。
はい。
beforeですね。
データが自動同期を無効にした場合は手動で同期しない限りバックアップされません。
はい。
うんうんうん。
で、afterですね。
自動同期を無効にした場合は手動で同期しない限りデータはバックアップされません。
というところですね。
はいはいはい。
なるほどね。
とにかくデータがバックアップされませんっていうところがbeforeだと遠いんですね。
はい。
で、文が長くなると主語や目的語と述語を近づけると読みやすくなりますよっていう風に言ってますね。
はい。
これは確かに分かりやすいかもですね。
主語同士ですね。
データがバックアップされませんって主語同士が近いとはやっぱりいいですよね。
はい。
で、最後ですね。
列記。
リストのことですね。
列記には箇条書きを使いましょうと。
はい。
beforeですね。
電話番号および誕生日の入力は任意ですと。
はい。
で、afterですね。
afterは次の項目の入力は任意ですって言って今の列がダラダラと並べられてますね。
はい。
まあそりゃそうだよな。
で、項目を並べるときは箇条書きを活用すると並列関係が視覚的にも分かりやすくていいですよねって感じでした。
まあこれはもう一目瞭然って感じですね。
はい。
まあいろいろ言いましたけど最後おまけがついてますね。
で、おまけは例文になってるので。
まあまあちょっとこれ長いので割愛しちゃいますね。
はい。
最後チェックシートですね。
はい。
チェックシートですけど冒頭に概要書いていますか。
39:01
一文一義で書いていますか。
読者の視点で書かれていますか。
重要のことから書いていますか。
文はこれ以上短くなりませんか。
曖昧な表現はありませんか。
係り受け明確ですか。
二重否定になっていませんか。
主語や目的と動詞の位置が離れすぎていませんか。
っていうこの10個ですかね。
のチェックシートがあります。
これにのっとって文章を一個一個書いていくのがいいってことですね。
これに全部のっとるともちろん文章を書くスピードが遅くなるしエネルギーもかかるんですけど
その代わりちゃんと伝わりやすくお互いにまるしい文章になる気はしているので
ここを結構真似していくというのかなと思いました。
はい。
時間40分きたのでちょうどよく終わったのでこれで以上にしたいかなと思います。
結構わかりやすくてテクニカルライティングは基本よかったなと思いますね。
もうちょっと僕もこれ意識しようと思いました。
はい。
では長いことちゃんたらたらとしゃべってきましたけど
これで一旦今日の朝活は終了にしたいなと思います。
お子さんがいた皆さん本当にありがとうございました。
ではまた明日もたらたらと何か読んでいきたいと思いますのでお付き合いいただければなと思います。
じゃあ本日も一日頑張っていきましょう。
お疲れ様でした。
