わかりやすいとは何か
学習のアウトプットのために書き始めたブログですが、記事数が50記事を超えました。
読んでくれいているみなさま、いつもありがとうございます。
そして、わかりにくくてスミマセン涙
当初、「頭の整理」が主目的だったブログですが、最近は「わかりやすい」「役に立つ」ブログにしたいという思いが強くなってきました。
どうしたらわかりやすい記事になるのか。わかりやすい記事とはどんなものなのか。
それでまず「わかりやすい」について考えてみたので、私なりの考えを記事にしたいと思います。
私が考える「わかりやすい！」と感じるときとは
- 理解できる「言葉」、理解できる「ストーリー」で説明されて
- 理解したいと思っていることを理解できた(理解できた気になった)とき
です。
（理解、理解、理解、理解、理解。理解を５個も使ってしまった）
以下、解説します。
自分が理解できる言葉
聞いたこともない用語が次から次へと出てくるとその都度用語の意味を調べることになって、調べているうちに最初に調べたことを忘れしまったりします。
githubの使い方を例にすると
（例）githubの使い方
ローカル環境でローカルリポジトリを作成し、アプリケーションをインデックスにaddして、commitします。その後、リモートリポジトリを作成し、pushします。
リポジトリ？インデックス？add？commit？push？
みたいな。
必要な情報がすべて、正しく表現されていることも大事ですが、これを理解するのは中々大変です。
そこで自分（＝記事を読んでくれ人）が理解できる言葉で言い直してみましょう。
（例）githubの使い方 自分の言葉バージョン
自分のPCで作成したアプリケーションの改良が終わったとき、「改良完了！」という状態になりましたと宣言します。この宣言は自分のPC内だけの話なので、「改良完了！」宣言をネットワーク上でも実施します。
自分のPC内での完了宣言・・・commit
ネットワークでの完了宣言・・・push
みたいな感じ。
ちょっとはわかりやすくなったんじゃないでしょうか。
エンジニアとして業務でgithubを使うためには、前者の内容を完全に理解する必要があるとは思います。
ただ、駆け出しエンジニアがとっかかりとして理解するのは後者くらいで十分だと思うのです。
この自分の言葉で説明するという作業は「人にわかりやすく説明する」以外に、自分自身の理解深めることにも役立ちます。
よくわからない単語の羅列を暗記するんじゃなくて、自分が理解できる言葉で説明した方が圧倒的に知識の定着率がいい。ようするに時間が経っても忘れにくいです。
理解できるストーリーの中で説明
ここでいう「ストーリー」とは、背景も含めた全体の流れのことを意味しています。
例えば、チームで開発するときは
- 作業を洗い出す
- 作業分担する
- 作業したら作業結果を誰かにチェックしてもらう
- チェックOKならmasterに反映する
- 次の作業を行う
のような流れを説明してもらって、この流れを実現するための便利ツールとして「github」があって、その要素として「コミット」とか「プッシュ」があることがわかれば、理解しやすいと思うのです。
ストーリー無しでいきなり
commitとは「アプリケーションの変更内容をリポジトリに保全すること」と説明されても
- なんでそんなことする必要があるの？
- それをして意味あるの？
みたいに感じてしまうわけです。
言葉やルールをただ説明するだけでなく、実現したいことの「部分」として説明することが大事だと思っています。
理解したいと思っていることを理解させてあげるということ
たとえ、理解できる言葉でしっかりとしたストーリーを元に説明されたとして
「それ知りたいことじゃないんだよなぁ」
となってしまうと、その人にとって「わかりやすい」にはなりません。
例えば、commitするときのコマンドコードを知りたいと思っている人にとっては
$ git commit -m "コミット名"
されあれば、それ以外の情報は全て無駄なものとなるわけです。
これは先ほどのストーリーの中で説明すると矛盾するように見えますが、そうではありません。
大事なのは「理解できる」ストーリーです。
チーム開発の概要やgithubの概要をストーリーとして十分に理解している人であれば、ストーリー部分を極力排除しても「わかりやすい」と感じてもらえるというわけです。
つまり「わかりやすさ」で大事なのは「誰をターゲットにするか」ということになります。
例えば、駆け出しエンジニアに向けてgithubの記事を書こうと思ったとしても「これが一番わかりやすい記事」というのは無いと思っています。
駆け出しエンジニアといっても
のようにたくさんの背景を持った人がいて、それぞれ知りたいと思っていることも、わかりやすいと感じるストーリーも違います。
誰にとって有益な記事を書きたいかを具体的に想像することが、わかりやすい記事を書く上で重要だと感じています。
理解できた気にさせる
「これは分かりやすい！」と思った記事を読んでも、次の日にはすっかり忘れているということがよくありませんか？
これは「理解できた気にさせる」ことに重点をおいた記事によくあることだと思っています。
説明が分かりやす人というは「理解できた気にさせる」のが上手な人でもあります。
誰にでも理解できる言葉を使って、分かりやすいストーリー仕立てされた説明は確かに分かりやすいのですが、エンジニアが本当にスキルアップするためにはそれだけでは不十分だというのが私の考えです。
「わかりやすさ」について考えていてふと思ったのが、「わかりやすいことが一番いいのか」ということでした。
私の結論は
- わかりやすさは大事
- でもわかりにくくても理解すべきことがある
です。
比喩表現でわかりやすく説明された内容だけでは一人前のエンジニアにはなれないだろうなと感じています（駆け出しエンジニアが偉そうそう思っています）
結論
・わかりやすとは感じるのは
- 理解できる「言葉」、理解できる「ストーリー」で説明されて
- 理解したいと思っていることを理解できた(理解できた気になった)とき
・わかった気になって終わらないように気をつけたい
蛇足
私のブログのスタンスは「１ヶ月前の自分と同じレベルの人にとってわかりやすい記事を書く」で行きたいと思っています。
蛇足の蛇足
もうちょっとスキルアップしたら
を対象に記事をまとめたいとも思っています。その時はwordpress使って独自ドメイン取得するかなぁ。
