書評「AWSクラウド設計完全ガイド」
みなさんは数多いAWSのサービスから適切なものを選択して、システムを設計できているでしょうか。私はアプリケーションエンジニアなので、AWSなどクラウドインフラは開発環境の設定変更や小さなアプリでLambdaを使うぐらいでした。AWSはある目的において似たような機能を提供するサービスも多く、どれを使えばいいのかやその判断基準を決めるのが難しかったです。そんなこともあり、この「AWSクラウド設計完全ガイド」を読んでみました。 書籍情報 AWSクラウド設計完全ガイド 著者：アクセンチュア株式会社 戸賀 慶/福垣内 孝造/竹内 誠一/浪谷 浩一/澤田 拓也/ 崎原 晴香/浅輪 和哉/村田 亜弥 発行：日経BP 第2章 AWSにおけるインフラストラクチャ選定のアプローチ次のようなXaaSアーキテクチャについて、それぞれのメリット、デメリット、ユースケースがまとめられており、参考になりました。 IaaS (Infrastructure) PasS (Platform) SaaS (Service) CaaS (Container) FaaS (Funtion) CaaSではEC2, F...
書評「心理学に基づく質問の技術」
みなさんは仕事の進捗を確認したり、相手にやってほしいことがあるとき、どんな言葉でお願いしていますか？この本はこういった問いかけ=質問について、心理学に基づいて相手の答えを引き出すためにいい聞き方を教えてくれます。 書籍情報 タイトル：心理学に基づく質問の技術 著者：大谷佳子 出版社：翔泳社 説明を理解してもらえたか確かめたいとき相手に仕事の説明や、商品の紹介をすることがあると思います。自分が説明した後、相手がどれくらい理解してもらえたのか確認するときに、どんな言葉を投げかければいいでしょうか。 「ここまで、わかりましたか？」 普通なら、こんなふうに質問するかもしれません。しかし、こう言われた相手は「はい、だいたいわかりました」とか「うーん、いちおう。。。」という感じで、はっきりと「いいえ」とは言いづらいものです。ここで、この本では次のように質問するとよいと書かれていました。 「ここまでで、分かりにくいと思ったのはどこですか？」（いずれも、本書P.38より抜粋） 最初の質問では前提として「説明内容が分かっている」状態となっていました。なので、「いいえ」と答えてしまうと「分かってな...
書評「スピーチや会話の「えーっと」がなくなる本」
普段話す中で、どうしても言葉につまったり、無意識のうちに「えーっと」とか「あのー」といったフィラーを挟むことがあります。フィラーがあると、話が聞きにくくなったり、自信がなさそうに聞こえてしまいます。この本は、そんなフィラーをなくすための方法が書かれています。 書籍情報 スピーチや会話の「えーっと」がなくなる本 高津和彦 著 フォレスト出版 なぜフィラーがでるのかこの本ではフィラーは「心」「思考」「声」が関係していると書かれています。 心とフィラーは密接に関連しており、自己評価が低い人は出やすい傾向があるようです。だからといって「心を強くもてば、フィラーは出ないんだ！」といった精神論を話したいわけではありません。 その心を「思考」（理性）でコントロールできればいいのです。対策としてこの本では「１文を短く区切って話す」ことを推奨しています。読点「、」で文を長く続けていると、口で話すことに頭の思考が追いつかず、どうしてもフィラーを挟んで思考する時間を作る必要があります。これを防ぐには句点「。」で文を区切って、すこし間をとってその間に思考するとよいと書かれています。 また、自信のある「...
書評「言語化の魔力」
「言語化の魔力」を読んだので、その感想をまとめておきます。 言語化の魔力 言葉にすれば「悩み」は消える 著：樺沢紫苑 幻冬舎 コントロール感悩みについてストレスを感じるのは「コントロール感」がないことが原因だそうです。 自分にはどうしようもない、どうにもできないと思うようなことは、改善できず悩むしかなくなってしまいます。私も、どうあがいても上手くできないことについて悩みを抱えることがありました。自分ではがんばってるはずなのに、どうにもできなくて、改善の方法もわからなくなってしまっていました。 悩みの再設定悩みを解消する方法の1つとして「悩みを再設定する」ことが書かれていました。 例えば、「大地震が怖い」という悩みがあったとして、これは自然現象なので自分でコントロールすることはできません。でも、「地震で命が危険にさらされるのが怖い」と悩みを再設定してみると、家屋を耐震補強したり、保険に入ったりすることができます。このように、コントロールできないことからコントロールできるものへ変えることができます。 言語化頭の中で同時に考えられる対象は3つ程度しかないそうです。これをワーキングメ...
書評「最高の集い方」
「最高の集い方 記憶に残る体験をデザインする」を読んだので感想をまとめておきます。 書籍情報 「最高の集い方 記憶に残る体験をデザインする」 プリヤ・パーカー著 / 関美和 訳 プレジデント社 仕事の定例会議、プライベートでの食事会など、人々が集まる場をどうつくり、主催者としてなにをすべきなのかが書かれています。 なぜ集まるのか人々が集まるにはその理由が必要です。 定例会議などその場に集まることが決まっている場合、その理由を考えることは少ないかもしれません。しかし、人々がそこに集まるのには理由があるはずですし、それを考える必要があります。改めて理由を考えてみると、そこで何を話すべきか、どこで集まるべきかが変わってくるかもしれません。まずは「なぜ集まるのか」を再度考えてみる必要があります。 誰を招かないのか人が集まる場を提供する場合、参加者は多ければ多いほど良いと思うかもしれません。でも、なぜその場を作るのかを考えたとき、この人は招かないほうがいいということがあるかもしれません。親友が集まる場に、親友の友達を招くと友達が中心になってしまいそれまでの関係性では話ができないかもしれま...
日付の期間検索を設計するときに考えたこと
最近、日付を開始日と終了日を指定して検索する機能を設計することがありました。はじめは簡単かなと思っていましたが、少し悩むこともあったのでまとめておきます。 期間検索とは対象とする機能は、日付を持つデータについて開始日と終了日を指定して期間内に入る場合は検索結果に表示するというものです。例えば、データが一覧表示されており、各レコードには作成日時があるとします。検索条件として開始日と終了日を指定して検索すると、条件に合致するレコードのみが表示されます。 考慮すべき事項単純そうな機能ですが、実装においてはいくつか考慮すべき事項があります。 期間のバリデーション検索条件として指定する開始日と終了日には不正な値が設定されてしまうことがあります。 利用するUIライブラリによりますが、日付として不正な値が入力された状態で検索ボタンが押下されることがあるかもしれません。（2025/01/__のように年月のみなど）この状態では条件を確定できず検索できないため、はじめにバリデーションチェックして処理を中断する必要があります。 また、開始日と終了日の大小関係が誤って指定される可能性もあります。例えば、...
前提を確認することの大切さ
コミュニケーションを取るうえでは「前提」を確認することが大切だと思います。そんなことを考えることがあったので、まとめておきます。 前提とはそもそも「前提」とはコミュニケーションを取る関係者間で、あらかじめ持っているべき共通認識と言えるかなと思います。前提があるから話題について全くゼロから伝える必要もなくなり、時間短縮やみなさんの労力をとることも少なくなります。 前提を確認しないとそんな便利な前提ですが、持っているべきであっても、実際には前提が違うことも多々あります。他人の考えていることがすべて分かるわけではなく、それまでの経験により「これくらいはわかってくれているだろう」という思い込みで話してしまうこともあります。 そうして前提が違うまま話を始めると、相手は話のはじめから理解しにくくなります。はじめから理解できないと、その後理解が進むのはあまり期待できません。結局、最初から話してと言われるか、いちから確認という名の多くの質問を投げかけられることになるかもしれません。他人の考えなんてわからなくて当たり前、という認識のもとで相手が少し嫌そうでも、まずは前提を確認すべきかなと思います。...
書評「SCRUM BOOT CAMP THE BOOK」
最近、業務でスクラムをはじめて本格的にやる経験がありました。なんちゃってスクラムをやったことはあったのですが、レトロスペクティブとかやってこなかったので、この本を読んで気になった箇所を書いておきます。 見積もりスプリントプランニングで見積もりする際は、例えばプランニングポーカーでみんなの想定を確認することがあります。なんとなくやっていましたが、これは想定が違ったりする場合にみんなで話し合い認識を合わせるという効果があると書かれていました。これは意味がありそうだなと思います。 デイリースクラム毎日行うデイリースクラムは進捗報告会ではなく、問題を見つける場であると書かれていました。ともすれば「昨日は～～をやって、今日は～～をやる予定です。問題は起きてません」みたいな報告だけをすることになってしまいます。そうではなく、問題があれば共有してみんなで解決していく必要があると思いました。 また、タイムボックスを守ることも大切とありました。実際にやってみると、相談事などがあって時間を守れないことも多かったです。そういう中でも時間を守れるのが実力が高いチームと書かれており、納得しました。 まとめ...
考える時間を減らしてみる
自分は仕事やプライベートでも考えすぎて、行動に移すのが遅いと感じることがあります。例えば、部屋のものが散らかってきたからラックを買ったほうがいいなと思っても先送りしてしまうなど。 ラックを買って整理した方が部屋がきれいになって生活しやすくなるのは分かっているんですが、家具を選ぶのに時間がかかったり、そもそも選びもしなかったり。頭で分かっていても行動できないことが多いです。また、別のときは分からないことを自分でとことん調べたりしてしまいます。Googleで検索しても前提知識が少なくてよく分からなかったりするのでとても時間がかかってしまい、これなら先に知ってる人に聞いておけばよかったとなることも。 こうなってしまう原因はいくつかありますが、ひとつは完璧主義かなと思います。自分ひとりで100%正しいものを作ろうとがんばってしまっている感じです。他の人と協力したり、質問したりすればいいのにそれができないか、できても遅くなってしまっている状態です。もうひとつは、コミュニケーション能力不足だと感じています。自分の困りごとを言語化できないか、できても相手に伝わらないから、それなら自分でがんばろ...
書評「プログラマー脳」
日々プログラムを書く仕事をしていると、「なんかこのコードは読みにくいな」と理解に時間がかかるコードもあれば、「あー、こういうことね！」とすぐに内容がわかるものもあります。それは単純に自分が知らないプログラミング言語や業務知識を必要とするものだから時間がかかるのか、はたまた以前に自分が書いたコードと似ているからもしくは簡単な処理しかしていないからなのでしょうか。 本書は「コードを読む」という、あまり焦点があてられてこなかったプログラミングの領域に、認知科学からアプローチする内容になっています。 3つの混乱コードを読むときによく理解できない原因として、知識不足、情報不足、処理能力不足が挙げられています。 知識不足はそのプログラミング言語の知識がなく構文がわからないというようなときです。また、その言語自体はよく知っているが、処理内容が別の場所に書いてあり内容がよくわからないといった場合は情報不足に当てはまります。処理能力不足はfor文でループさせながら変数の値を変化させる場合などに、頭の中で変数の値を考えながらコードを読む必要があり頭がパンクしてしまうといった場合です。 混乱の原因これ...