書籍「初めてのアジャイル開発」
◎気になったキーワード
人はプロセスに勝る（P3）
ソフトウェアは新製品開発である（P3）
たとえ開発が進んだ後であっても要求の変化を歓迎する（P33）
情報を伝えるために最も効率的かつ有効な手段は、直接の対話である（P33）
壊れていないなら直さなくてもいい（P59）
スプリントバックログ（P150）
・タスクごとの残作業時間を日別に見積もったもの
・個人が責任を持って、タスクの推定残作業時間を毎日更新する
「共通のビジョンを打ち立て、重ねて強調せよ」（P344）
ムーワ式ビジョン記述（P346）
ユースケースを使ってもよい（P350）
・アジャイルな手法とは「要求を詳細に記述しない」ことだと考えるのは間違いである
テスト駆動型開発（P356）
新しいものを素直に受け入れ、過去とはきっぱり決別すべきである（P373）
全工数の見積は、詳細なタスクのスケジュールより先に、それに依存せずに作成する（P381）
必要性にもとづいて、どのようなドキュメントを作成するかを決める（P398）
以上
28
書籍「インターフェースデザインの心理学」
利用者が使いやすいインターフェースデザインをするために役立つ100の事柄の紹介本。
例えば「画面上に点滅するものがあると、なぜ気になるのか」感覚としては分かっているのですが、なぜ人がそう思うのかまではあまり考えないのではないでしょうか？ この本ではそれらを膨大な心理学関連の論文を元に、分かりやすく解説されています。
◎気になったキーワード
以上。
例えば「画面上に点滅するものがあると、なぜ気になるのか」感覚としては分かっているのですが、なぜ人がそう思うのかまではあまり考えないのではないでしょうか？ この本ではそれらを膨大な心理学関連の論文を元に、分かりやすく解説されています。
◎気になったキーワード
それを使って何ができ何をすべきなのか、見ただけですぐわかるものにしなければならない（P15）
意味のある表題や見出しを付けてください。これはとても重要です（P36）
情報は少ないほどきちんと処理される（P66）
重要なのはクリックの回数ではない（段階的開示）（P68）
人が信じ込んでいる考えを変えさせようとして、多くの時間を費やしても無駄でしょう（P77）
人は物語を使って情報をうまく処理する（P84）
ある情報に注目してもらいたい場合は、自分で必要だと思う提示方法よりもはるかに目立つ方法で強調しましょう（P112）
目標に近づくほど「ヤル気」が出る（P132）
報酬に変化があるほうが協力（P135）
外的報酬ではなく内的報酬がないか探してみましょう（P145）
笑いは絆を生む（P185）
データよりも物語のほうが説得力がある（P194）
牧歌的な風景を見ると幸せな気分になれる（P202）
「信用できない」という理由で拒絶されたウェブサイトについて、被験者の意見の83%がデザインに関連していました（P204）
達成が難しいことほど愛着を感じる（P207）
顧客の反応はプラスであれマイナスであれ、おそらく本人が思っているほど強いものではないのです（P209）
エラーメッセージの書き方（P215）
・発生した問題を説明する
・修正方法を指示する
・受動態ではなく能動態を使い、平易な言葉で書く
・例を示す
エラーはすべてが悪いとはかぎらない（P221）
人は自分の処理能力を超えた数の選択肢や情報を欲しがる（P234）
「お金」より「時間」（P238）
グループによる意思決定は必ずしも的確ではない（P242）
他人は自分より影響を受けやすいと考える（P248）
意味のある表題や見出しを付けてください。これはとても重要です（P36）
情報は少ないほどきちんと処理される（P66）
重要なのはクリックの回数ではない（段階的開示）（P68）
人が信じ込んでいる考えを変えさせようとして、多くの時間を費やしても無駄でしょう（P77）
人は物語を使って情報をうまく処理する（P84）
ある情報に注目してもらいたい場合は、自分で必要だと思う提示方法よりもはるかに目立つ方法で強調しましょう（P112）
目標に近づくほど「ヤル気」が出る（P132）
報酬に変化があるほうが協力（P135）
外的報酬ではなく内的報酬がないか探してみましょう（P145）
笑いは絆を生む（P185）
データよりも物語のほうが説得力がある（P194）
牧歌的な風景を見ると幸せな気分になれる（P202）
「信用できない」という理由で拒絶されたウェブサイトについて、被験者の意見の83%がデザインに関連していました（P204）
達成が難しいことほど愛着を感じる（P207）
顧客の反応はプラスであれマイナスであれ、おそらく本人が思っているほど強いものではないのです（P209）
エラーメッセージの書き方（P215）
・発生した問題を説明する
・修正方法を指示する
・受動態ではなく能動態を使い、平易な言葉で書く
・例を示す
エラーはすべてが悪いとはかぎらない（P221）
人は自分の処理能力を超えた数の選択肢や情報を欲しがる（P234）
「お金」より「時間」（P238）
グループによる意思決定は必ずしも的確ではない（P242）
他人は自分より影響を受けやすいと考える（P248）
以上。
18
書籍「リーダブルコード」
「読みやすいコード」をテーマにした本。今まで自分が書いたコードにつくづく反省です。(^^;)
◎気になったキーワード
スコープが小さければ短い名前でもいい（P23）
長い名前を入力するのは問題じゃない（P23）
一貫性のあるスタイルは「正しい」スタイルよりも大切だ（P53）
読み手の立場になって何が必要なのかを考える（P56）
ライターズブロックを乗り越える（P68）
ネストを浅くする（P93）
説明変数／要約変数／ド・モルガンの法則を使う（P100）
無関係の下位問題を積極的に見つけて抽出する（P130）
汎用コードをたくさん作る（P135）
一度に1つのことを（P143）
おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない（アインシュタイン）（P158）
問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということだ（P165）
コードを小さく保つ（P170）
まずは新しく書くコードが読みやすいコードだけになるようにしよう（P226）
コミットメールのススメ（P228）
実践してみよう。
◎気になったキーワード
スコープが小さければ短い名前でもいい（P23）
長い名前を入力するのは問題じゃない（P23）
一貫性のあるスタイルは「正しい」スタイルよりも大切だ（P53）
読み手の立場になって何が必要なのかを考える（P56）
ライターズブロックを乗り越える（P68）
ネストを浅くする（P93）
説明変数／要約変数／ド・モルガンの法則を使う（P100）
無関係の下位問題を積極的に見つけて抽出する（P130）
汎用コードをたくさん作る（P135）
一度に1つのことを（P143）
おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない（アインシュタイン）（P158）
問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということだ（P165）
コードを小さく保つ（P170）
まずは新しく書くコードが読みやすいコードだけになるようにしよう（P226）
コミットメールのススメ（P228）
実践してみよう。
09
| h o m e |
