銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

当ブログではアフィリエイト広告を利用しています

【技術書まとめ19】アジャイルな見積もりと計画づくり

技術書 アジャイル開発

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第19弾です。

 

今回は アジャイルな見積もりと計画づくり を読みました。

アジャイル開発について詳しく解説をしている名著です。

 

アジャイルについて全く知識・経験がなかったですが考え方がとても合理的で面白かったです。

この記事を読めばアジャイルについての概要がつかめると思うので、興味ある方は是非読んでみてください。

今回は学ぶことが多かったので少し長めです。

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

Amazon
 

f:id:ysk_pro:20190126103827p:plain

まえがき

  • アジャイル開発者の主張は次の通り。「私たちは今ここで分かっていることを元に計画を立てる。顧客にとって一番大切な目標を達成するために私たちは計画を変更する。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させる。私たちから顧客への願いは、ビジネスの変化へ柔軟に適応することと当初の計画を死守するとことは矛盾した要求だと、きちんと理解してほしいということである」
  • 多くのプロジェクトマネジメント手法は「計画ー計画ー計画ー実行」であるのに対し、アジャイル手法は「計画ー実行ー適応」の繰り返しである。プロジェクトの不確実性が多ければ多いほど、成功するためにはアジャイル手法が必要となる
  • プロダクトマネージャやプロジェクトマネージャに、専門的スキルを持つ人の仕事の進め方と仕事内容を決定する権限を与えてしまうのは、ビジネス的自殺といってもよい
  • アジャイルな見積もりと計画づくりの手法が従来型の手法よりも効果的な理由は、価値を提供することとビジネスとプロジェクトチームの間に信頼関係を築くことに注力しているためである。どんなことにも透明性を保ち、いかなる変更でもビジネス側に伝えることで、ビジネス側も素早く適応し、最善の判断を下すことができる
 

第1部 問題とゴール

1章 計画の目的

  • プロジェクトが進むにつれて見積もりは正確になる。「不確実性コーン」によれば、初期のプロジェクト定義の段階では見積もりには60%から160%に及ぶ誤差が生じる
  • よい計画とは、ステークホルダーが信頼できる計画である。信頼できるとは、その計画を基にして意思決定できるということである
  • アジャイルな計画づくりを定義すると以下のようになる
    • 計画よりも計画づくりを重視する
    • 変化を促進する
    • 計画そのものは容易に変更できる
    • プロジェクト全体にわたって繰り返される
  • アジャイルな計画は、「変更されても構わない」ではなく「積極的に変更したい」と考える。なぜなら、変更が起きるということはすなわち、なにか学習したり過ちに気づいたことを意味するからである 

2章 なぜ計画づくりに失敗するのか

  • 仕事の量は、完成のために与えられている時間をすべて満たすまで膨張する。これはパーキンソンの法則と呼ばれており、私たちは作業完了までの期間が決まっていると、許される限りの時間をすべて使ってしまう
  • マルチタスク化は生産性に甚大な悪影響を与え、遅れを助長する。個人が3つ以上の作業を並行して進めると、作業の切り替えにかかる時間がの増加が目立ち、価値を生み出す作業に使える時間が大幅に減少することが分かっている
  • 不確実性に対処する最善の方法は、繰り返すことである。プロダクトがどうあるべきかという不確実性を低減させるには、短いイテレーションで作業して、計画を修正していくとよい
 

3章 アジャイル手法

  • アジャイルチームの基本的な仕事の進め方
    • 1つのチームとして働く：すべてのプロジェクト参加者が、共通のゴールを持った1つのチームに参加している意識を持つ
    • ビジネス上の優先度を重視する
    • 検査と適応：計画は、立てた時点での推測に過ぎないので、全ての変化を機会と捉え、最新の状況を計画に反映していく。イテレーションを開始するときは、直前のイテレーションで得た知識を元にして、新たな状況へ適応する
  • プロジェクトというものは新たな機能と知識を生み出し続ける活動であり、単に決められた手順を実行するだけではない
  • アジャイルチームは3つのレベルで計画づくりをする
    • リリースプランニング：リリース全体についての計画であり、3ヶ月から6ヶ月という期間がよく使われる。ゴールは、プロジェクトのスコープ、スケジュール、リソースについて回答を出すこと
    • 今日のプランニング：日々のスタンドアップミーティングでメンバーがその日に何をするか決める1日単位の計画
  • リリースプランニングとイテレーションプランニングには、プロダクトオーナーの満足条件を理解することが必要
  • ユーザーストーリーは、ソフトウェア要求を表現するための簡単な手法
    • よく使われるフォーマット：「＜ユーザーの種類＞として、＜機能や性能＞が欲しい。それは＜ビジネス価値＞のためだ」
    • 例：「本の購入者として、ISBNで本を検索したい。それは探している本をすばやく見つけるためだ」
 

第2部 規模を見積もる

4章 ストーリーポイントによる規模の見積もり

  • ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさを表す単位である。ストーリーポイントを使った見積もりでは、ひとまとまりの仕事に対してポイントをつける。ポイントの数値そのものは重要ではなく、他の作業との相対値が重要である
  • ストーリーポイントによる見積もりの始め方には2種類ある。これから取り組むストーリーの中で最も小さいと思えるものを基準としてそれを1ポイントとする方法と、中くらいと思えるストーリーを決めて、それに見積もりで使う数値範囲の中央に近い値をつける方法である
  • ベロシティとは、チームの進む速度を表す単位である。ベロシティの値は、チームが1回のイテレーションで完了させたユーザーストーリーのストーリーポイントの合計値である。チームが前回のイテレーションで10ストーリーポイント分の作業を完了させたのであれば、次のイテレーションでも10ストーリーポイント分の作業をこなせると予測できる
  • 必要なすべてのフィーチャのストーリーポイントの見積もりを合計すれば、プロジェクト全体の規模を見積もれる。また、チームのベロシティがわかれば、規模をベロシティで割ると必要なイテレーションの回数が見積もることができる。イテレーション数とは期間なので、カレンダーに当てはめればそれがスケジュールとなる
  • アジャイルな見積もりでは「規模を見積もり、期間は導出する」
  • プロジェクトが進捗するということはユーザーストーリーをこなしていくことなので、数イテレーションも実施すればチームのベロシティがわかってくる。ポイントによる見積もりの素晴らしい点は、ベロシティを適用することで計画時の見積もりミスが自動的に補正されることである
 

5章 理想日による見積もり

  • ユーザーストーリーの開発にかかる時間は、現実日で見積もるよりも理想日で見積もる方が簡単である。現実日による見積もりでは、ストーリーの完了までに起こりうる、あらゆる割り込みを考慮しなくてはならない。理想日による見積もりなら、ストーリーに必要な時間だけを検討すればよい
 

6章 見積もりの技法

  • わずかな時間で考えた見積もりと、長時間悩んだ末に出した見積もりがほとんど同じになるのはよくある。ある程度以上の労力を費やしても、見積もりの正確さには寄与しないことが多い（収益逓減(ていげん)の法則）
  • 見積もりはチーム全体で出した方がよい。アジャイルプロジェクトでは誰がどの作業をするのか事前に決めていないことが多く、全員が作業を担当する可能性がある全員が関与した方がいいため
  • 人は10倍以内のものならうまく見積もれるという研究結果がある。見積もりのスケールには「1, 2, 3, 5, 8」というフィボナッチ数列をよく用いる（対象が大きくなると不確実性が増える様子にうまく対応しているため）
  • 必要かどうかまだわからないフィーチャや、近い将来には開発予定のないフィーチャは、1~8よりも大きな単位で見積もるユーザーストーリーを作りたいことがある。このような大きなユーザーストーリーはエピック（epic）と呼ばれる
  • プランニングポーカーは、専門家の意見、対比、分割の全てを組み合わせ、楽しみながら迅速かつ信頼できる見積もりを出すことができる。プランニングポーカーの参加者はチームの開発者全員である
    • まず最初に、全員に一組のカードを配り、そこにはチームで使用できる見積もりポイントが1枚につき1つずつ書かれている
    • 進行役となる人が、見積もり対象のユーザーストーリーやテーマを1つずつ読み上げ、見積もり担当者からの質問にはプロダクトオーナーが回答する
    • 見積もり担当者は、自分がこうだと思う見積もりポイントのカードを選ぶ。選んだカードは全員が選択し終えるまで人には見せないようにし、全員の見積もりが決定したら一斉にカードをオープンする
    • 人によって見積もりが大きく異なることは、見識の相違から学ぶチャンスである。高い見積もりを出した参加者と低い見積もりを出した参加者に、見積もりの根拠を説明してもらう。この時、見積もった人を非難しているように見えないよう留意する
    • 議論を終えたら、見積もり担当者はそれぞれ再び見積もりポイントカードを選んで、一斉にオープンする
    • 多くの場合、見積もりは第2ラウンドで収束するが、収束しなければここまでの手順を繰り返す。ゴールは、全員が合意することにある
  • プランニングポーカーがうまくいく理由
    • 複数の専門家の見解をまとめた見積もりを実現するため
    • 活発な対話を引き出すため。見積もりについて説明を求めると、情報の不足を補った良い見積もりとなるため
    • 個人の見積もりを平均した方がよりよい結果を残す傾向があるという研究結果があるため
    • 楽しいため
 

7章 再見積もり

  • 再見積もりが必要となるのは、ストーリーの相対的な規模に変化があったとチームが判断した時（例えば、あるシナリオだけがより時間を要すことがわかった場合など）である。あるストーリーが想定よりも長く時間を要したというだけでは再見積もりはしない
  • イテレーションの終了時点でストーリーが部分的に完成している場合、ストーリーを分割して再見積もりしたくなるが、そのようなことはしない。この場合、今回のイテレーションのベロシティは少し下がり、次回のイテレーションのベロシティは少し上がるが、ベロシティの目的は長期間でのチームの平均速度を図るためであり、特定のイテレーションのベロシティには特別な意味はないので問題ない
 

8章 ストーリーポイントと理想日

  • ストーリーポイントは純粋な大きさのみを測定する値だが、理想日はそうではない。開発者のスキルが変化すれば理想日の見積もりも変化してしまうが、ストーリーポイントではこうしたことは起きない
  • 理想日は人によって異なってしまうが、ストーリーポイントは人によって異なることはない
  • 「これはあれと近い」と相対的な大きさで見積もる方が、絶対的な大きさで見積もるよりもよい結果になることが研究でわかっている
 

第3部 価値のための計画づくり

9章 テーマの優先順位づけ

  • 新しいフィーチャの優先順位づけに必要な4つの要素
    • フィーチャの金銭価値
    • フィーチャの開発（サポートも含む）にかかるコスト
    • フィーチャの開発を通じて学べる知識の量とその意義
    • フィーチャの開発によって低減できるリスク
  • 4つの要素を総合して優先順位をつけるとき、第一に考えるのはフィーチャの価値とそのフィーチャを開発するのにかかるコストである。コストに対して最も高い価値を持つテーマが、最初に着手すべきテーマとなる。さらに、他の優先順位づけの要素を検討してテーマの優先順位を上下する
 

10章 金銭価値による優先順位づけ

  • 財務的に分析することは優先順位づけに役立つ。利益と業務改善の効果を予想するのは2年先までが一般的である
  • キャッシュフローの評価には、正味現在価値、内部収益率、回収期間、割引回収期間の4つの指標を利用する
 

11章 「望ましさ」による優先順位づけ

  • 顧客満足度の狩野モデル
    • 当たり前、または必須のフィーチャ：フィーチャをどれだけ幅広く用意して、品質に磨きをかけても、当たり前のフィーチャであれば顧客満足度にほとんど影響を与えない
    • 線形、一元的なフィーチャ：あればあるほどよいもの。線形、一元的というのは、フィーチャの量に比例して顧客満足度が線形に高まることに由来する
    • 魅力的な、わくわくするフィーチャ：大きな満足をもたらしたり、わくわくする気持ちになったりするもの。このフィーチャは無いからといって顧客満足度が悪くなることはない。ユーザーは体験してみるまで、そうしたフィーチャが必要だということに気づかない
  • 当たり前のフィーチャを備えたら、線形のフィーチャをできるだけ多く完成させることを重視する。魅力的なフィーチャはこれらの機能を実装した後に、時間の許す範囲で対応する
  • ユーザーからアンケートを取ることで、フィーチャを簡単にカテゴリに分類することができる
 

12章 ユーザーストーリーの分割

  • 1つの大きなストーリーを見積もるよりも、分割して見積もった方が正確な見積もりになる
  • ユーザーストーリーを分割するタイミング
  • 代表的な分割方法
    • 扱うデータによって分割する
    • CRUD操作それぞれで分割する
    • 横断的な機能（ロギングやエラーハンドリングなど）を別のストーリーへ分割する 
    • パフォーマンス要件を別のストーリーへ分割する
    • サブストーリーの優先度で分割する
  • 分割しづらいタスクに出くわしたとき、ついストーリーをタスクに分割したくなるが、タスクへの分割は避ける
  • 分割したストーリーに、関連する変更を追加しない。分割した意味がなくなってしまう（よくある例：ついでに同じ箇所にある既存のバグを直す、というのは避ける）
  • チームのイテレーション期間が2週間であれば、2日から5日で完了できる大きさにストーリーを分割するのが適切な大きさである
 

第4部 スケジュールを立てる

13章 リリース計画づくりの基本

  • リリース計画の役割は、いつどれだけの成果が出せるかを判断すること
  • 想定されるベロシティを予定しているイテレーションの数とかけて、その結果を超えない範囲でユーザーストーリーを選択すればよい
  • 一般的には、3ヶ月から6ヶ月の周期でリリースを繰り返すことが多い
  • リリース計画は定期的な見直しと更新が必須である。多くのプロジェクトがイテレーション終了時点でリリース計画を見直すようにルールを定めている
 

14章 イテレーション計画づくり

  • イテレーションプランニングではタスクの担当者は決めない。タスクの担当者を決めるのは、イテレーションが始まってからである。また、一度に担当するタスクは1つであり、新しいタスクに着手するのは、前に担当したタスクを完了させてからである。イテレーションが始まる前に、全てのタスクの担当者を決めてしまうと、イテレーションのゴールに向かってチーム全員が一丸となって取り組むという参加意欲に水を差してしまう
  • イテレーション計画は新しいイテレーションを始めるタイミングで実施するので、プロジェクトの中でチームが得た新しい知識を使ってリリース計画よりも詳細な計画を立てられる
  • リリース計画では見積もりにストーリーポイントを使うが、イテレーション計画では計画の精度が高まっているのでタスクの見積もりに時間を使う
  • 多くのチームでは、次のイテレーションでは、現在のイテレーションで達成したベロシティを使う。これは「昨日の天気」と呼ばれ、最も効率よく今日の天気を当てる方法は昨日と同じ天気と答えることに由来している
  • イテレーションプランニングの手順
    • 残りのユーザーストーリーの優先順位を調整する（事前にやっておくと、よりスムーズ）
    • 前回のベロシティ等を参考に目標ベロシティを決める
    • イテレーションゴール（イテレーション終了時に到達していたい状態）を決める
    • イテレーションゴールを実現させるためのユーザーストーリーを選ぶ
    • ユーザーストーリーをタスクに分解する
    • タスクを見積もる
  • イテレーション計画には、ユーザーストーリーをプロダクトに統合して動作させるために必要な全てのタスクを含めるべきである
  • タスクのサイズは、開発者が平均して1営業日に1つ完了できるくらいの大きさが適切である
 

15章 イテレーションの長さを決める

    • 不確定要素の高さ：プロジェクトの不確実性が高いほど、軌道修正の機会を増やすためにイテレーションは短くすべき
    • フィードバックの得やすさ
    • 優先順位が安定している期間
    • 外部からのフィードバックの必要性
    • 切迫感を感じ始めるまでの時間
 

16章 ベロシティの見積もり

  • ベロシティの見積もり方法としての選択肢で望ましい順に以下がある
    • ベロシティの見積もりを出す前にイテレーションを1回でも実施できるなら迷わずそうする。実績値にまさる見積もりはない
    • 同じメンバーが携わった、今回のプロジェクトに関係のあるプロジェクトでの実績値を使う
  • いずれの方法を採用するにせよ、ベロシティの見積もりには幅を持たせる
  • どのやり方で見積もったにせよ、ベロシティの実績値を使えるようになったら、すぐそちらに切り替える
 

17章 不確実性に備えるバッファの計画

  • バッファの持たせ方でよく使われる方法は、フィーチャバッファとスケジュールバッファの2つである。
    • フィーチャバッファは、プロダクトに対する要求が優先順位づけされていて、その全てが必ず提供されるわけではないと合意できている場合に用意するバッファである。時間が足りなくなったときは、フィーチャバッファにあるフィーチャを削ることでスケジュールを守る
    • スケジュールバッファは、全体のスケジュールに対して適用するバッファである
 

18章 複数チーム編成プロジェクトの計画づくり

  • アジャイルプロジェクトは、大規模なプロジェクトに対しては、1つのチームを大きくするのではなく、複数の少人数チームを編成することが多い。チーム間で共有できる見積もり基準の確立、ユーザーストーリーの早い段階での詳細化などが必要となる
  • 次回以降のイテレーションの準備作業の中で一番有用なものは、次回以降のイテレーションで開始することになっているストーリーについて、プロダクトオーナーの満足条件をはっきりさせること
 

第5部 トラッキングと情報共有

19章 リリース計画のモニタリング

  • リリースバーンダウンチャートは、各イテレーションの開始時点でプロジェクト全体としてストーリーポイントがどれだけ残っているか把握するためのもので、プロジェクトの完了見込みがいつになるかを教えてくれる非常に強力なツールである。縦軸が残りのユーザーポイント、横軸がイテレーションになっている
 

20章 イテレーション計画のモニタリング

  • イテレーションのトレッキングに使う2つのツール
    • タスクボード：どのタスクが作業中で、どのタスクがサインアップ待ちなのかが一目でわかるツールである。タスクボードの列にはそれぞれラベルをつけておき、作業の進行に応じて対応するタスクカードをチームメンバーが順番に右側の列に動かしていく
    • イテレーションバーンダウンチャート：タスクボードに残っている、縦軸に未完了タスクの見積もり所要時間の合計を、横軸にイテレーションの何日目かをとる折れ線グラフである
 

21章 計画とコミュニケーション

  • 見積もりと計画のコミュニケーションは、正直で頻繁な、双方向のものであるべきである。これはアジャイルな計画とは頻繁に更新されるものであり、フィードバックと新しい知識を繰り返し反映させることで洗練させていくためである
 

第6部 なぜアジャイルな計画づくりがうまくいくのか

  • アジャイルな見積もりと計画づくりのための12のガイドライン
    • 1. チーム全体を巻き込む：見積もりはチーム全体で出すなどチーム全体の参加とコミットメントを引き出す
    • 2. 複数レベルの計画を立てる：リリース計画、イテレーション計画、今日の計画それぞれに狙いがある
    • 3. 大きさの見積もりと期間の見積もりを区別するために別々の見積もり単位を使う：作業の大きさにはストーリーポイント、期間にはベロシティを使うとよい
    • 4. 不確実性はフィーチャか日付のいずれかで表現する：追加するフィーチャが決まっていて動かせないなら計画の不確実性は日付の幅で表現し、日付が固定されているなら提供予定のフィーチャに幅を持たせて不確実性を表現する
    • 5. 頻繁に計画を見直す：新しいイテレーションを始めるタイミングは、現在のリリース計画を見直すいい機会である
    • 6. 進捗をトラッキングして情報を共有する：プロジェクトの進捗をあらわす手段には、バーンダウンチャートなどの一目でわかるグラフを使うのがベスト
    • 7. 学習することの大切さを受け入れる：プロジェクトは、プロダクトにフィーチャを追加するのと同じくらい新しい知識を生み出すものである。新しく得た知識があれば、必ずそれを計画にも反映する
    • 8. フィーチャは適切な大きさで計画する：数イテレーション以内の近い将来に開発予定の機能は、比較的小さなユーザーストーリーに分割する。ユーザーストーリーのサイズは1、2日から10日位までの大きさが一般的である
    • 9. フィーチャを優先順位づけする：フィーチャの価値とコストだけでなく、フィーチャから得られる知識と、フィーチャを開発することで軽減できるリスクも考慮に入れる
    • 10. 現実に即した見積もりと計画を立てる：見積もりと計画は、測定した実測値を根拠とすべき
    • 11. ゆとりを残す：メンバー全員の時間を100%使い切るような計画を立てない。高速道路の限界100%まで車を詰め込むと誰も身動きの取れない渋滞になってしまうのと同じ
    • 12. 複数チームの連携には「移動する先読み範囲」を使う：チーム間で依存関係が生じるフィーチャについては、ある程度先を見越して、あらかじめ実装するイテレーションを決めておく
 

おわりに

ここまで読んでいただきありがとうございます。
アジャイルの合理的な考え方に共感し、是非一度やってみたいなーという気持ちになりました。
本書では具体例を多く取り入れながら一つ一つ詳しく解説してくれているので、アジャイルに興味を持った方は是非読んでみてください。
アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～

Amazon

以下の記事を合わせて読むことでアジャイル開発、アジャイル開発の1つであるスクラムについての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。

エンジニアがMac購入後にやっておきたい設定・環境構築・便利なツールまとめ

Mac

（2024/3 更新）

注文していたMacBook Airが昨日届きました。

同時にMacBook Air注文して、先に届いていた妻が参考にしたURLをまとめてくれており、設定・環境構築がすぐ終わりました！

そんなツイートをしたところ、参考にしたURLを教えて欲しいと2人の方からリプをいただいたので簡単にまとめてみます。

せっかくなので僕が使っている便利なツールも紹介しています。

初めてMacを購入した方、MacからMacへ買い替えた方の設定・環境構築の参考になれば嬉しいです。

ちなみに、僕はRuby on Railsを使って開発をしていて、使用しているエディタはVimです。（Vim大好き！）

Macのバージョン：macOS Mojave 10.14.1 

f:id:ysk_pro:20190101115249p:plain

1. 必要なアプリのインストール（デスクトップアプリ）

まず必要なデスクトップアプリをApp Storeでインストールします。

  • Google Chrome : インストールするだけで同期してくれるので楽々
  • slack
  • LINE

 

2. 必要なソフトのインストール

 

3. 基本的なPCの設定

 

4. 開発環境構築

 

おわりに

みなさんが知っているものばかりだったでしょうか。

「こんな便利なツールあるよ！」など教えていただけるととても嬉しいです！

 

2018年に僕がエンジニアになって作ってきた個人開発webサービス 12個や書いてきたnoteなどをこちら↓の記事で紹介しているので、合わせてご覧いただけると嬉しいです！

また、使っているキーボードや椅子などの物理的な環境についてはこちら↓の記事に書いているのでご興味あればご覧ください！

エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り

1年の振り返り サービス開発

もうすぐ2018年おわりますねー！

ということで、2018年にやったことを書き出して、KPTで振り返りをしてみました！

あー、楽しい1年だった。 

（KPTというのは僕の会社で使っている振り返りのフレームワークです）

f:id:ysk_pro:20181231220832p:plain

（↑の画像は今まで作ったサービスの画像を適当にくっつけてみました。めっちゃごちゃごちゃしてる 笑）

1. 2018年にやったこと

  • ブログ 41記事
  • note 3記事
  • LT・登壇 4回
  • エンジニアのコミュニティに 3つ参加（もくもく会などは多数参加）

 

2. KPT

2-1. Keep（良かったこと / 今後も続けること）

  • インプット→アウトプットの習慣が作れたこと（学んだことをブログ・Twitter等でアウトプット）
  • 学習する習慣が作れたこと（技術書・個人開発での新技術等をほぼ毎日学習できた）

 

2-2. Problem（悪かったこと / 今後はやめること）

  • 勉強会などにあまり行けなかった（もっと人脈を広げたかった）

 

2-3. Try（次に挑戦すること）

  • 勉強会などに月1回以上参加する

※ 一応3つとも定量化したので、月1回以上は振り返って絶対達成するようにしたい

 

3. おまけ（1. の詳細）

ここからは長いのでご興味ある方はご覧ください。

作ってきたサービス、note、技術チュートリアル、LTを簡単に全て紹介していきます。

3-1. 2018年にリリースしたサービス

3-1-1. Jobmiru

渾身の処女作です...！

このサービスのおかげでDEMODAYというオリジナルサービスを発表するイベントに登壇できたり、エンジニアへ転職することができました。

最も思い入れのあるサービスです。

業種特化などして何とか使われるサービスに育てていきたい。

このサービスに込めた想いなどはこちらのブログに書いています。


3-1-2. Powertweet

 

3-1-3. BigTweet"1"（後に "2"を開発します） 

 

3-1-4. アイデアtweet


3-1-5. 今日雨降るよちゃん（LINE bot）

僕が一番気に入ってるLINE botです。

開発のきっかけなどをこちらの記事に書いています。


3-1-6. お買い物メモ君（LINE bot）

こちらのサービスについてはこの記事に書いています。


3-1-7. Tweet Searcher（LINE bot）

自分で毎日使っているLINE botの一つです。便利！

 

3-1-8. BigTweet"2"

 

3-1-9. Blog Reader（LINE bot）

 

3-1-10. いちにちをシェア


3-1-11. いちねんをシェア


3-1-12.  いちねんのさいてん

いちにちをシェア、いちねんをシェア、いちねんのさいてんについてはこちらのブログに書いています。


3-2. note

3-2-1. 僕はなぜ銀行を辞めたのか、なぜITエンジニアになったのか （+ 実際の転職活動について）


3-2-2. プログラミング歴6ヶ月の僕が自社サービスRailsエンジニアになりました！〜実際の転職活動について〜


3-2-3. 【資格試験勉強法】大量の資格を取得する銀行員時代に身につけた、そこそこの資格に「1ヶ月」で合格してきた超実践的勉強法


3-3. 技術チュートリアル

3-3-1. 【Big Tweetチュートリアル】Ruby on Railsで簡単なサービスを作ってみよう！（初学者向け）


 3-3-2. LINE botチュートリアル【初学者向け】 〜Ruby on Railsでアイデアtweetを作ってみよう〜

 

3-3-3. 「今日雨降るよちゃん」を作ってみよう！【初学者向け】〜Ruby on RailsによるLINE botチュートリアル②〜 


3-3-4. 【初学者向け】Ruby on RailsでのLINE botチュートリアル第３弾〜Amazon API・楽天APIを使ってお買い物Botを作ってみよう〜


3-3-5. 【BigTweetチュートリアル２】Ruby on Rails / JavaScriptで簡単なサービスを作ってみよう！（初学者向け）


3-4. LT・登壇

3-4-1. DEMODAY


3-4-2. 勉強会でのLT

 

3-4-3. DIVE INTO CODE（プログラミングスクール）のイベント


3-4-4. Ebisu.rb


4. おわりに 

ここまで読んでいただきありがとうございます。

こうまとめるとなんか色々やってきたなーという感じがします。

 

色々とやってこれたのは週末一緒に勉強 / 開発に付き合ってくれる妻（妻もエンジニアです！）のおかげであり、本当に感謝してもしきれないです。

 

エンジニアになってまだ半年、ここからさらに加速していきますー！ 

【技術書まとめ18】Web API The Good Parts

技術書

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第18弾です。

今回は Web API The Good Parts を読みました。

Web APIの設計、開発、運用について解説しており、Web APIの開発者は必読と言われている本です。

今後のAPI開発で活かせそうなところ満載の良書でした。

Web API: The Good Parts

Web API: The Good Parts

 

f:id:ysk_pro:20181230095506p:plain

1章 Web APIとは何か

  • Web APIとは、あるURIにアクセスすることで、サーバ側の情報を書き換えたり、サーバ側に置かれた情報を取得したりすることができるwebシステムで、プログラムからアクセスしてそのデータを機械的に利用するためのものである。機械的にと言うのは、ブラウザを使って人間が直接アクセスすることを目的としたURIではないことを意味している
  • 新しいシステム、サービスを公開する力を持った開発者にAPIを公開することで、彼らがサービスに付加価値を与えてくれ、コアとなる自分たちのサービスがより発展する可能性がある
  • サービスにある機能を追加したいと思った時、デファクトとなっているサービスがすでに存在し、APIを公開している場合にはそこに繋いだ方が有利であることが多い。APIを用意することで様々なサービスと共存共栄することができるようになる
  • スマートフォンのアプリケーションがサーバと通信する必要がある場合、Web APIが利用されるのが最も一般的である
  • 設計の美しいWeb APIは変更しやすい。モバイルアプリケーションの場合、アプリケーションのアップデートのタイミングはユーザー次第であり、バージョンアップをしたとしても古いバージョンを使うユーザーは存在し続けてしまう。APIの仕様を急に変化させるとそうした古いバージョンのアプリケーションは動かなくなってしまうので、APIの変更をいかに利用者に影響なく行うかは重要である
 

2章 エンドポイント設計とリクエストの形式

  • Web APIにおけるエンドポイントとはAPIにアクセスするためのURIのことであり、一般的なwebページのURIの設計の考え方がそのまま適用できる
  • 良いURI設計の原則は、覚えやすく、どんな機能を持つURIなのかが一目でわかることである
  • URIに大文字は使わず、すべて小文字を使うべき。HTTPにおいてURIは、スキーマとホスト名を除いて大文字と小文字は区別されるため、大文字を使うと別のURIとなってしまう
  • HTTPメソッドのPUTとPOSTの使い分け：どちらもサーバ側の情報を変更するためのメソッドであるが、Web APIではデータを修正する場合にPUTを用い、新しいリソースを生成する場合はPOSTを用いるのが一般的である
  • データの集合と個々のデータをエンドポイントとして表現し、それに対する操作をHTTPメソッドで表す考え方は、Web API設計の基本であり、多くのAPIがこれに沿った設計となっている
  • エンドポイントには複数形の名詞を用いるのが基本である。また、エンドポイント内で単語を2つ以上繋げる必要がある場合はハイフンを利用することが多い
  • クエリパラメータとパスの使い分け：一意なリソースを表すのに必要な情報はパスに入れた方が良く、省略可能な情報はクエリパラメータに入れる方が良い
  • ホスト名とエンドポイントの共通部分は「api.example.com」が主流であり、わかりやすさ、簡素さの観点から適切であると言える
  • 「１スクリーン１API、１セーブ１APIコール」という言葉があり、何度もAPIへのアクセスを繰り返すことは、速度の問題だけでなく、データの一部だけが表示されてしまう状態や、保存の際に一部のデータだけが保存されて整合性が保たれなくなってしまうといった問題を引き起こす可能性もあるので極力避けるべきである
  • 良い設計を見極めるには様々なAPIの実際の設計を調べ、比較してみることも重要である
 

3章 レスポンスデータの設計

  • JSONがXMLよりも広まった理由は、JSONの方がシンプルで同じデータを表すのにサイズが小さくて済むこと、webの世界においてクライアントのデフォルト言語であるJavaScriptとの相性がとても良いことがあげられる
  • JSONPを使うと、JSONをscript要素を使ってJavaScriptとして読み込み、ドメインを超えたアクセスが可能となる。JSONPに対応しているAPIは多く存在するが、必要がないのであればセキュリティの観点からはなるべく対応しない方がよいとされている
  • クエリパラメータを使って、レスポンスの内容をユーザーが選択できるようにすることも有用である
  • レスポンスデータをフラットにするか階層化させるかについてGoogleのJSON Style Guideでは「なるべくフラットにした方がいいが、階層構造を持った方がわかりやすい場合もある」とされており、それに従うのが良い
  • レスポンスで配列を返したい場合に、配列をそのまま返すことも、オブジェクトに包むこともできるが、セキュリティの観点からオブジェクトに包んだ方がベターである。トップレベルが配列であるJSONは、JSONインジェクションという脆弱性に対するリスクが大きくなる
  • 各データ項目（JSONのキー）の名前のつけ方のポイント
    • 多くのAPIで同じ意味に利用されている一般的な単語を用いる
    • なるべく少ない単語数で表現する
    • 複数の単語を連結する場合、連結方法はAPI全体を通して統一する：JSONではキャメルケースを使うのがよいとされているが、スネークケースなどを使っているAPIも多数存在する
    • 変な省略形は極力利用しない
    • 単数形／複数形に気をつける：そのキーで返るデータが複数なのか単数なのかで使い分ける（データを配列で返すときは複数形に、それ以外は単数形にする）
  • サーバがエラーを返す際に真っ先に行うべきことは、適切なステータスコードを使うことである。エラーの詳細を返す方法は、HTTPのレスポンスヘッダに入れて返す方法と、レスポンスボディで返す方法があるが、多くのAPIはレスポンスボディにエラーメッセージを格納する方法をとっている
 

4章 HTTPの仕様を最大限利用する

  • HTTPのキャッシュの仕組みをAPIでも利用する。HTTPのキャッシュは、2つのタイプがある
    • Expiration Model（期限切れモデル）：あらかじめレスポンスデータに保存期限を決めておき、期限が切れたら再度アクセスをして取得を行うもの
    • Validation Model（検証モデル）：今保持しているキャッシュが最新であるかを問い合わせて、データが更新されていた場合にのみ取得を行うもの
  • Content-Typeヘッダを使ってメディアタイプを指定するのは非常に重要であり、すべてのAPIは適切なメディアタイプをクライアントに返すべきである。クライアントの多くは、Content-Typeの値を使ってデータ形式を判断しており、その指定を間違えるとクライアントが正しくデータを読み出すことができないケースが出てくるためである
  • 独自のHTTPヘッダを定義して利用することも可能である
 

5章 設計変更しやすいWeb APIを作る

  • 一度公開したWeb APIの仕様を変更する場合は、新しいAPIを別のエンドポイント、あるいは別のパラメータをつけたURIなど、何らかの新しいアクセス形式で公開するのが良い。つまり、古い形式でアクセスしてきているクライアントに対してはそれまでと変わらないデータを送り、新しい形式でのアクセスには新しい形式のデータを返すといった複数のバージョンのAPIを提供するということである
  • APIのバージョンを表す方法は、URIのパスに”/v2/“のようにバージョンを埋め込む方法が最も一般的である
  • バージョニングのルールとして広く知られている手法にセマンティックバージョニングがある。Rubyなどでも基本的な考え方が導入されている。”1.2.3”という表記でそれぞれの数値はメジャー、マイナー、パッチと呼ばれ、以下のルールが適用される。（APIのURIのバスにはメジャーバージョンのみを含める場合が多い）
    • メジャーバージョン：後方互換性のない変更が行われた際に増える
    • マイナーバージョン：後方互換性のある機能変更、あるいは特定の機能が今後廃止されることが決まった場合に増える
    • パッチバージョン：ソフトウェアのAPIに変更がないバグ修正などを行ったときに増える
  • 自社のアプリ向けAPIなどの場合には、あらかじめAPIの提供が終了した際の仕組みをクライアント側にも組み込んでおくべきである。一番簡単なのは強制アップデートで、アプリケーションを立ち上げた際に、現在のバージョンと最低限サポートされるクライアントのバージョンを比較し、サポートの切れたバージョンを使っていた場合は「サービスを使い続けるにはアップデート」してくださいと表示して、AppStoreなどを開くことである
 

6章 堅牢なWeb APIを作る

  • 本来アクセスできないはずの情報はサーバ側できちんとチェックをし、アクセスを禁止しておくべきである
  • パラメータなどを修正してリクエストを送ってくる場合もあるので、クライアントから送られてきた情報を信頼せず、サーバ側でも整合性をきちんとチェックする必要がある
  • 同じリクエストを再度送信される場合もあるので、そのような場合を想定したサーバ側でのチェックが必要となる
  • 一度に大量のアクセスをされてしまう問題を解決するための最も現実的な方法は、ユーザーごとのアクセス数を制限することである。つまり単位時間あたりの最大アクセス回数（レートリミット）を決め、それ以上のアクセスがあった場合にエラーを返すようにする
  • XSS、XSRFなど通常のwebと同様のセキュリティだけでなく、JSONハイジャック（APIからJSONで送られてくる情報を悪意ある第三者が盗み取ること）などAPI特有の脆弱性に気を配る必要がある
  • セキュリティ強化につながるHTTPヘッダをきちんとつけるべきである
 

おわりに

ここまで読んでいただきありがとうございます。

Web APIの開発に関わっていて本書をまだ読んでいない方は是非読んでみることをおすすめします！

Web API: The Good Parts

Web API: The Good Parts

 

やっぱり年末年始は読書が捗りますね。

来週も頑張ります！

【年末年始に読みたい！】2018年に読んでよかった本５選

技術書

2018年も終わりますね。

個人的に2018年は、人生で一番かもしれないくらい激動の１年でした。（そんな１年のことはこちらの記事に書いていますのでご興味ある方はご覧ください。 エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り - 銀行員からのRailsエンジニア ）

銀行員からエンジニアになったこともあり、今年は技術書を多く読みました。
（合計28冊の本を読んで、内18冊が技術書でした。）

その中で特に良かったなーと思う５冊を紹介します。

年末年始はTVを見るのもいいですが、ゆっくり読書して過ごすのも素晴らしいです。

f:id:ysk_pro:20181228074105p:plain

1. チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

 2018年で一番衝撃を受けた本です。

「チーミング」という概念をもとに、学習する強い組織の作り方について書かれた本です。

最近よく耳にする「心理的安全性」についてもこの本の中で詳しく解説されています。

マネジメントに関わる人は必読、そうでない人も読んでおいて絶対に損ではない本だと思います。

リーダーが、管理ではなくエンパワーメントをするようになったら、適切な答えを与えるのではなく適切な質問をするようになったら、そして規則の遵守を主張するのではなく柔軟性に着目するようになったら、メンバーはもっと高いレベルで仕事を行えるようになる

心理的安全とは、関連のある考えや感情について人々が気兼ねなく発言できる雰囲気をさす。簡単なことに思えるが、同僚が見ているところで支援を求めたり失敗を許したりできるというのは思いのほか難しい場合がある。しかし、チーミングによって様々な意見の違いを超えて協働できるようになると、率直に会話したり失敗を隠さず話したり出来るようになる

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

 

 

2. お金2.0 新しい経済のルールと生き方

 「お金」というよりも「経済システム」の作り方について書かれており、僕が新しいwebサービスを作る際の考え方に大きな影響を与えてくれた本です。

この本はブログにまとめていないので、一部を引用にて紹介します。

 持続的かつ自動的に発展していくような「経済システム」にはどんな要素があるかを調べていった結果、５つほど共通点があることに気がつきました。 ①インセンティブ、②リアルタイム、③不確実性、④ヒエラルキー、⑤コミュニケーション、の５つです。

実際に社会で広く普及した経済システムは例外なくヒエラルキーが可視化されていて、明確な指標の役割を担います。 　世の中には、偏差値、年収、売上、価格、順位のような数字として把握できるものから、身分や肩書きのような分類に至るまで、階層や序列に溢れています。

「世界を変える」とは、前時代に塗り固められた社会の共同幻想を壊して、そこに新しい幻想を上書きする行為に他なりません。国家、通貨、宗教、偏差値、学歴、経歴、年収、資産、倫理、権利など、私たちの精神や行動を縛る概念のほぼ全てが人工的に作られた幻想ですが、これらの効力が薄れ、時にはまた別の幻想が誕生し、人々の新たな価値判断の基準になっていきます。

これからは価値という観点から、自分なりの独自の枠組みを作れるかどうかの競争になります。枠組みの中の競争ではなく、枠組みそのものを作る競争です。そのためには自分の興味や情熱と向きあい、自らの価値に気づき、それを育てていく。そしてその価値を軸に自分なりの経済圏を作っていきます。

お金2.0　新しい経済のルールと生き方 (NewsPicks Book)

お金2.0　新しい経済のルールと生き方 (NewsPicks Book)

 

  

3. 漫画 君たちはどう生きるか

おいおい、オススメの本と言いながら漫画じゃねーか、と思った方もいると思います。

そうです、漫画です。

漫画なのでサクッと読めるのですが、学ぶこと・感じることがとても多かったです。

ベストセラーにもなっていたのでお読みになった方も多いかと思います。

少し長いですが、一部を引用にて紹介します。

悲しいことや、辛いことや、苦しいことに出会うおかげで、僕たちは本来人間がどういうものであるか、ということを知る。身体の痛みは、正常でないことを僕たちに知らせてくれるなくてはないのと同じように、心に感じる苦しみやつらさは、人間が人間として正常な状態にいないこと僕たちに知らせてくれるものであり。僕たちはその苦痛のおかげで、人間が本来どういうものであるべきかということを、心にとらえることができる。人間は、お互いに愛し合い、好意をつくしあって生きてゆくべきであり、誰だって自分の才能を伸ばし、その才能に応じて働いてゆけるのが本当なのに、そうでない場合があるから、人間はそれを苦しいと感じるのだ。僕たちは、自分の苦しみや悲しみから、いつでも、こういう知識をくみ出してこなければいけない。僕たちが、悔恨の思いに打たれるのは、自分はそうでなく行動することもできたのに、と考えるから。それだけの能力が自分にはあったのに、と考えるから。人間である限り、過ちは誰にだってある。そして、僕たちに苦しい思いをさせる。しかし、この苦しい思いの中から、いつも新たな自信をくみ出していこう。正しい道に従って歩いてゆく力があるから、こんな苦しむのだと。僕たちは自分で自分を決定する力を持っている。だから、誤りから立ち直ることも出来るのだ。

漫画　君たちはどう生きるか

漫画　君たちはどう生きるか

 

 

4. Webを支える技術

ここから２冊は技術書です。

エンジニア界隈では超有名なので説明するまでもないかもしれませんが、こちらはHTTP、URI、HTML、RESTなどのWebの基礎となる技術を解説している本です。

エンジニアとして働くにあたってWebの基礎知識は、知っていることが前提となる必須の知識であり、僕はこの本を通算４周読んでいます。

Webの基礎知識の概要を掴みたい方は必読だと思います。

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus

Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus

 

 

5. 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

Webアプリケーションの脆弱性に関する名著です。

最近の話題に対応するべく第2版が2018/6に発売されました。

言うまでもないですがセキュリティはwebサービスを運営するにあたって超重要事項であり、僕の会社でこの本は勉強会の題材になりました。

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

 

 

番外編 マンガ キングダム

今アツいマンガはやっぱりキングダムではないでしょうか。

もしまだ読んでいない方がいれば正月に一気読みしちゃいましょう！

（まだ読んでいない人はこれからこのマンガが読めると思うとうらやましい 笑）

キングダム 1 (ヤングジャンプコミックスDIGITAL)

キングダム 1 (ヤングジャンプコミックスDIGITAL)

 

  

おわりに

今年はエンジニアになったばかりということもあって、ベテランのエンジニアの方に聞いたおすすめの本を読むのが中心で、素晴らしい本にたくさん出会うことができました。

業務、書籍などから少しずつ知識がついてきたと感じているので、来年は自分に必要な本を自分で選んでいくことも行い、エンジニアとして知識の幅をどんどん広げていきたいと思っています。

来年も素晴らしい本、人生の幅を広げてくれるような本に出会えるのが楽しみです。

是非みなさんのおすすめの本も教えてください！

Twitterにグラフをシェアできるサービスを３つ作りました！〜サービスの紹介、作った背景、使った技術など〜

サービス開発 Ruby on Rails

今月は久々にwebサービスを開発していて、似たようなサービスですが３つリリースすることができました💪 

サービスの紹介、作った背景、使った技術などをまとめたのでご興味ある方は是非ご覧ください！

いつも僕がどんな感じでサービスを作っているのかも書いています。

（記事は読まなくてもいいので是非サービスだけでも触ってみてください(> <)）

f:id:ysk_pro:20181224204243p:plain

作ったサービスの紹介

1. いちにちをシェア

自分の１日をかんたんにシェアできるサービスです。


2. いちねんをシェア

いちにちをシェアの１年バージョンです。

 

3. いちねんのさいてん

レーダーチャートで１年を振り返れるサービスです。
１年を振り返る以外の用途でも、レーダーチャートでステータスを表示して遊べます。

 

なんで作ったの？

仕事の１日のスケジュールや、休日の１日のスケジュールをTwitterでシェアしたい、また他の人のスケジュールを見てみたいなー、と思ったことが開発のきっかけです。
 
余談ですが、webサービスのアイデアは思いついたらすぐにEvernoteにメモをするようにしており、もう既に開発したものを合わせて現在64個のアイデアがたまってます。作り切れない、、、笑
 
いちにちをシェアを作った後に、年末なので1年を振り返れる機能をつけたいなーと思って、いちねんをシェア、いちねんのさいてんを開発しました。
 
手書きのデザイン案が残っていたので一応載せます。

いつもこんな感じで手書きでざっくり書いてます。f:id:ysk_pro:20181224192909j:plain

 

どんな技術を使っているの？

当初予定していた構成

バックエンド Firebase × フロントエンド Vue.js でいこうと思っていました...
 
理由はモダンでかっこいいから！
 
どちらも使ったことはなく、本やチュートリアルで勉強したりしながら頑張りましたが挫折してしまいました、、、
 
やっぱり一気に新しい技術を使いすぎるのは良くないですね...みたいなことはこの記事に書いているので是非読んでみてくださいー！

 

採用した構成

結局はいつもの構成に落ち着きました。
 
バックエンド Ruby on Rails × フロントエンド jQuery
 
jQueryをまだ使いこなせていないレベルだったので、今回はjQueryをたくさん使って使いやすいサービスにすることをテーマとしました。
 
例えば、
値を入力したら自動でグラフが生成されたり

1つ前の時間以降しか表示させなくしたりしました（触ってみてね！）

 
チャート生成は chart.js というJavaScriptのライブラリを使っています。
このドキュメントはもう暗記するぐらい読み込みました 笑
ドキュメントが日本語でしっかりまとまっているのでとてもやりやすかったです。
 
サーバーは、いつも通り Heroku です。
使いすぎて無料枠の月1,000時間をオーバーするようになってしまったので、現在は苦肉の策としてアカウントを2つに分けて運用しています。
 
画像の保存は Amazon S3 を利用しています。
 

どれくらい時間がかかったの？

Rails × jQuery で作り始めてからは土日を5日くらい使って完成させました。
 
僕の開発の仕方は、自分で書いたチュートリアルを組み合わせてベースを作り、そこからやったことがないことに挑戦していくスタイルです。
今回であれば、このチュートリアルを見ながら進めました。

 
僕が技術チュートリアルを書いているのは他の人の役に立てばいいなというのが一番ですが、このように将来の自分のためでもあります。
過去に作ったものも、コードしか残っていないと自分のコードであっても分からなくなってしまうことがありますが、チュートリアルであれば他人でもわかるように書くので自分で後から理解できておすすめです。
 
今回もできればチュートリアルにまとめたいと思ってます。
（コードがぐっちゃぐちゃなのでリファクタするのが面倒ですが、、、個人開発はどんなにコードが汚くても動けばOK、テストコードも書かない派です）
 

おわりに

みんな是非遊んでみてねー！！！

【読書まとめ17】説明がなくても伝わる 図解の教科書

デザイン

毎週１冊本をを読んでブログでアウトプットすることが目標で今回が第17弾です。

今回は、説明がなくても伝わる 図解の教科書 を読みました。

会社でデザイナーの方にオススメしてもらった、図解の仕方を実例を交えながら分かりやすく解説している本です。

ノンデザイナーの僕でもすぐ実践できそうな内容ばかりでとても為になったのでおすすめです。

説明がなくても伝わる 図解の教科書

説明がなくても伝わる 図解の教科書

  

f:id:ysk_pro:20181223171216p:plain

Chapter1 「図」がすべてを語ってくれる

  • 資料やスライド画面を見たときに、人が最初に目にするのはタイトルでも見出しでもなく、図解や写真といった「視覚イメージ」。人は生理的に図やイラスト、写真を見て、その資料や文書が自分にとって重要かどうかを判断し、重要であれば文章を読み始める
  • 抽象的・概念的な内容は、文字に頼らなければならない場合が多いが、文字を視覚イメージと一緒に示したり、分類方法を変えて整理したりすることで、伝わりやすくなることが多い
  • 図解をつくる基本手順は、基本原則を身につけて、伝えたいメッセージを図解の型に流し込むことである
  • デザイナーはまず手書きで始める。図をつくるときには、事前のアイデア出しやラフスケッチづくりが、最終的な品質に大きな影響を及ぼす
  • 図解のプロセスは頭文字をとってDTMと呼ばれる
    • Discovery（発見）：参考となる事例を見つける
    • Transformation（変形）：課題に合わせ、事例に手を加える
    • Making（形成）：スケッチをもとに図を仕上げる
 

Chapter2 伝わる「図」の5つのポイント

  • 図解の5つの基本機能
    • 一瞬で伝える
    • 親しみやすくなる
    • 不安を解消する
    • 真剣に受け止めてもらう
    • 誤解やミスを防止する
  • 図解づくりの目標
    • 伝えたいことを、受け手が予想できるようになる
    • 受け手が困らないように道案内をする
  • 「すでに広く使われていること」は、誰にでも理解されるための重要な要素である。すでにみんなが慣れ親しんだものを使う方が、手間もコストもいらず、人の役に立つことができる
  • どのようなプロセスで手続きが進み、どうすれば終了できるのかを、全体・部分・流れを示して提示すると読み手に安心を与えることができる。ステップを踏みながら説明するステップバイステップ技法が有用である
  • 重要部分を赤文字にすると、むしろ見えづらくなってしまうことがある。赤文字は黒文字よりも視認性が悪い。色を使わずに文字を強調するには、下線を引く、大きな字を使う、単語を囲む、太字を使うことが有用
  • 良い例と悪い例など相反する２つの例があることで、情報がより明快になる
 

Chapter3 「主題」「見せ方」「仕上げ」の３つの山を超える

  • 整理されていない情報は、情報とは言えない。つまり、整理されていない情報から価値は生まれない
  • 「立場」「作業内容」「時間軸」の３つで情報を分類すると伝わりやすい
  • 同じ分類内容に一貫して同じ形式（文字や線などの形式）を使う
  • 写真とイラストの使い分け
    • 写真：リアリティが重要で、雰囲気や広く詳細な情報を伝えたい時に役立つ
    • イラスト：焦点を絞り、必要なことだけを伝えたい時に役立つ。イラストは不必要な情報をあらかじめ省いておくことができる
  • グラフにはそれぞれ機能がある
    • 円グラフ：全体に占める割合を伝えるだけ。ある割合と別の割合を比較させる目的では使わない。また、円グラフの分割は最小限に留めるべき
    • 分割棒グラフ：割合の違いを伝えるだけ。円グラフの弱点を補う一方で、全体に占める割合は伝わりにくい
    • 折れ線グラフ：時間軸に沿った動向を伝えるだけ。時間軸は必ず等間隔に表示する
    • 棒グラフ：数値の差を伝えるだけ。必ずゼロを基準値として、バーの長さを省略しない
    • 数値一覧表：具体的な数値を伝えるだけ。大量の数値情報を１箇所に示す場合に役立つが、受け手の読み取りに大きな労力を強いるので、他のグラフによる提示方法があればそちらを優先した方がいい。使うのであれば、グリッド（格子状の線）を消し去り、平均値を示し、数値を縦に並べ、キリのいい数値で示すと理解しやすくなる
  • 図解の仕上げのポイント
    • インパクトを弱める：情報を全て強調してしまうと逆効果であり、主題に関わらない部分のインパクトは弱めるべき
    • 多様性を否定する：異なる情報は全く異なっているように見せ、同じ種類の情報は同じもののように見せる
    • 自分を信じない：自分はバイアスのかかった状態にあることを自覚し、実際に人に見てもらう
  • ポイントは箇条書きにし、可能なら図解化する。長い文章よりも箇条書きの方が目に入りやすい。文章から図解化する手順は、文章を要点ごとに分解し、それを箇条書きにして要点を絞ってから図解をする
 

Chapter4 「図」を変えれば全て伝わる

  • テキストで1行足らずのシンプルな情報でも、枠で囲んで並べるだけで図解となり情報が読み取りやすくなる
  • 手順を説明するときは、イラストと説明文を近くに配置すると、受け手の誤解や見落としが少なくなる
  • 数値は右揃え、単位は左揃えを原則とする
  • グラフは凡例を分離せずに、グラフ内に直接書き込んだ方が伝わりやすい
※ Chapter4では、50個の事例（それぞれ悪い図解と良い図解の比較）を分かりやすく解説しています
 

おわりに

ここまで読んでいただきありがとうございます。
 
会社でよく先輩に図解を交えて教えてもらっていて、言葉で説明してもらうよりもスッと入ってくる図解の威力を感じているので、本書を読み込んで図解力UPしていこうと思います。
このブログには掲載できませんでしたが、当然本書の中でも図解を多用しておりとっても分かりやすかったので是非お手にとってご覧ください。
説明がなくても伝わる 図解の教科書

説明がなくても伝わる 図解の教科書

 

最近はサービス作りに夢中で本を読めていませんでしたが、またここからどんどん本を読んでいきますー。

来週も頑張ります。