2019 ラーメンソン in 横浜
概要
- 2泊3日の横浜出張の裏でひたすら家系ラーメンをすする「ラーメンソン」を実施。
- その結果をSpeaker Deckでまとめ。
※ ラーメンソンとは「ラーメン」＋「マラソン」の造語。
内容
所感
- 初めてSpeaker Deckを使ったが良い感じ。
- 家系ラーメン縛りは辛かった。
「人を伸ばす力 - 内発と自律のすすめ」を読んで
書籍
- 作者: エドワード・L.デシ,リチャードフラスト,桜井茂男
- 出版社/メーカー: 新曜社
- 発売日: 1999/06/10
- メディア: 単行本
- 購入: 9人 クリック: 77回
- この商品を含むブログ (24件) を見る
TL;DR
- 内発的動機づけはGood！統制はBad！
- 内発的動機づけを持って取り組むと個人的な成長だけではなくより良い結果も導く。
- 自立性の支援は内発的動機づけを維持するために極めて重要。
- 上位の立場で成功する人は「自律性を支援する態度」を持っている。
この本を選んだ理由
- 織論や人事関連の話にてこの本がちょくちょく話題になり、気になっていた為。
印象に残った点
動機付けられる際は自律的か統制されているかという区別が重要(第1章)
- 動機づけは2パターン存在する。 1. 自律的=自由に自発的に行動していること。 2. 統制=圧力をかけられて行動していること。 - 統制の中にも2つのタイプがあり、一方が存在すると他方も存在する関係。 1. 服従:権威者の考えが実現されるように従う行動。 2. 反抗:期待されていることと反対の行動。 - 自律的に振る舞う→自らが行為の主体→本当の自分に基づいて行動する。 ⇒ 自律的というのは行動の開始から調整のプロセスが自己に統制されている時だけ。 - 家族という船の「乗組員」であるという認識はあるが、自分の船の「船長」という認識はない ⇒ 組織に属するだけと考え、個人を意識することが欠けている場合もある。
- 動機づけを深く考える機会がなかったので確かに…と感じる内容だった。
- また、大人になり、自分の内なる感情から来るモチベーションを軽視/抑えつけし過ぎていたと感じ、もっと自律的に行動したいと感じた。
報酬によって内発的動機づけを低下させてしまう(第2章)
- 行動主義は人は学ぼうとする意欲がそもそもないことが前提。「動機づけにる方法は行動に応じた報酬を提供すること」という考え。 ⇒ 小さいことは何事に関してもキラキラとした眼で取り組むため、行動主義の考えが正しいとは思えないというのが筆者の考え。 - 内発的動機づけとは？ ⇒ 活動それ自体に完全に没頭している心理的な状態であり、何かの目的(お金を稼ぐ、絵を完成させるなど)に到達することとは無関係。 - 報酬がない状態で楽しんでいたパズルもクリアごとに報酬が貰えるようになると報酬に依存してしまう。 ⇒ つまり報酬が内発的動機づけを低下させる。自由な行為を報酬によって外部から統制される行為へ変わる。
- 小さい子供のキラキラとした眼で取り組む姿。これが内発的動機から来るのか…。
- 大人になっても子供のような眼をして仕事をしている。という例えを聞くが、これは内発的動機づけが出来ているからこそなのだろう。
- 内発的動機づけができているのであれば報酬は与えないほうが良い。というのは子育て中の私には考えさせられる結果。
- 子育てにしろ、メンバーとの関係性にしろ見極めが大事だなぁ。
統制された活動に携わることで熱意や興味を次第に失う(第3章)
- 人を統制するために下記を行うとも内発的動機づけを低下させる。 - 金銭、罰、脅し、締切設定、目標の監視、評価など。 ⇒ 上記のことは人に圧力をかけてしまう。 - ただ、内発的動機づけを弱めないようにするために人々に好きなことを好きにさせるべきではない。 ⇒ 人の精神を抹殺することのない方法を検討すべき。 つまり、組織の在り方や行動を制限しつつ、自律性を高めるためには選択の機会を与えること。 - 制限の設定は責任感を育てる上で重要だが、やり方によって問題となる。 ⇒ 相手を操作する対象と見なすことなく、制限される側の立場に立ち、相手が主体的な存在であることを認めることが大事。 これによって、偽りのない自分であることを損なわずに責任感を育てることができる。
- 現在の職場にて締付け(統制)しすぎだな…だからモチベーション上がらないのか…と感じていたがまさに↑のことをやっていた。
- 好きなことを好きにやらせるという結論でなくて良かった。「制限しながらも選択させる」というのが肝か。なるほど。
- 自律性を支えることは強制することより難しいとのこと。そりゃそうだ。言うだけではなく、相手の状況をを理解し、適切な支援が必要だもんね…。
内発的動機づけは個人的な成長だけではなくより良い結果も導くが、外発的動機づけは悪い結果を導く(第4章)
- 「イキイキとした気持ちになる、興味を感じる、夢中になることを見つけてフローを体験する。いずれも結構なことだが、それがいったい何になる?」とい内発的動機づけを批判する人達がいる。 - この人達は結果だけを重んじており、利益ばかりに目がいっており被雇用者の専門性や個人的な成長には目もくれていない。 ⇒ 実際、内発的動機づけは「豊かな経験、概念の理解度の深さ、レベルの高い創造性、より良い問題解決を導く」という結果も伴う。 - 逆に外発的動機づけは内発的動機づけや課題の遂行を低下や、創造性や概念理解、柔軟性を必要とするような課題の成果に妨害的な効果をもたらす。 - 外発的動機づけ(報酬や罰など)を用いる際は下記3点の注意が必要。 1. 報酬を使いだしたら簡単に後戻りできない。 2. 一旦報酬に感心を向けると報酬の獲得するための手っ取り早い方法を選んでしまう。 3. 報酬は成果とのバランスをみる必要がある(方向付けのためではなく実績に応じて報酬を出す)。
- 「絵を描くことに内発的動機づけられている人は、単に精神の高揚を経験するだけでなく、真の芸術を生み出す」とロバート・ヘンリーの持論がある。これは素晴らしい言葉。楽しく働くことを考えていきたい。
- 外発的動機づけをしないといけない場合もあるとは思うが、その際は注意して扱う必要があるなぁ。
行動と結果のリンクが明らかでないと動機づけが根本から失われる(第5章)
- 良い子でいたらオモチャを買うというのは結果は分かるがどのような行動か不明瞭。 ⇒ このような場合動機づけが効果的にならない。
- なるほど。外発的動機づけは何の対価なのかを明確にしないと効果が出づらいのか。ただ、相手が理解できる状況なのか？にもよるなぁ。
有能感(コンピテンス)と自立性の両輪が大事(第5章)
- 有能感(コンピテンス)とは？ - 「人は環境と効果的にかかわり有能でありたいという気持ちであり、人の基本的欲求という主張」のこと。 ⇒ 人は「有能感への欲求→達成感を得る」ために積極的に活動に取り組む。 - 有能感は「最適の挑戦」のときにもたらされる ⇒ 有能感を感じるのはトップである必要はないし、優秀な成績を取る必要はない。 意味のある挑戦を見つけ、ベストを尽くすだけでよい。 - 有能感から来る内発的動機づけを促進するためのフィードバック(褒め言葉)は統制的にも非統制的にも働く。 - フィードバックが統制的だと内発的動機づけを低下させるので注意が必要。 - 統制的か非統制的か曖昧だと男女による受け取り方が異なりら女性のほうが統制的と受け取りやすい傾向がある。 ⇒ 褒め言葉にせよ、報酬にせよ、制限にせよ、相手を統制させようとするもくろみは極力排除する努力が必要。 - 自律性のない有能感では有能な駒でしかない ⇒ 自らの意思で自己決定できると心から感じないと意味がない。 そのため、自律性と有能感のどちらかが欠けても意味がない。
- 有能感のところ、メチャ良い事書いてあるなぁ。自分にとって意味のある挑戦で達成感を得れば更に有能感を求め…とポジティブなサイクルが回ると感じる。
- 少し古い本なので社会情勢が今とは違うので性差については鵜呑みはできないが面白い結果。
- 「統制」はこの本での重要なワードだなぁ。統制を感じさせないフィードバックが求められることは常に考えていきたい。
否定的なフィードバックは有害であるが、フィードバックする側が見過ごして良い訳ではない(第5章)
- 否定的なフィードバックをしないといけない内容であれば本人は恐らくその事の重大さを理解している。 ⇒ 自立性を支援するならば話を聞いてみるだけでも良い。
- つい反射的に口を出してしまうが、話を聞くことで自律的に考えてくれるのであれば聞くだけでも効果はありそう。
内在化は2つの形態「取り入れ」と「統合」がある(第7章)
- 内在化とは？ - 個人が社会の価値を身につける固有なプロセスであり、発達しつつある子供達が外的な援助を内的な援助へと変換する能動的なプロセスのこと。 - 内在化は本人が行うものであり外から内在化させるのではない。 ⇒ たいていの活動はけっして面白くない。 ただ、社会の役割を果たす上でそういった活動は重要であり、内在化が肝となる。 - 内在化の2つの形態 1. 取り入れ:ルールを噛み砕かずに丸ごと飲み込むこと。 2. 統合:ルールをよく噛んで消化すること。 ⇒ 自己をルールに統合することが最適な形の内在化。
- ルールを守ることが目的となっている人がおり、何を達成するためのルールなのかを意識できていないという状況をたまに見る。まさに取り入れと統合の違い。
自立性の支援は内発的動機づけを維持するために極めて重要(第7章)
- 根の生えたアボカドを大地に植えれば成長してアボカドの木になるのはアボカドの性質であり、これは自然に起きる
- ただ、枯れたり腐ったりすることがあるのは、養分や日光、水が必要であり、アボカドが自ら自然に成長していくために必要なものがある為。
⇒ 人に対しても同じ。発達途上の人が自然に発達するためには、心理的な栄養(自律、有能さ、関係性への欲求という心理的欲求)が必要。
- 内発的動機づけを維持するために自立性の支援は極めて重要
- 自立性の支援とは他者を自分自身の満足のために操作すべき対象とするのではない
- 人間として支援する価値のある能動的なエージェントとして認めながら関わっていくこと
⇒ 自立性を支援する行動(理由付け、承認、および選択)のある状況下で規範を内在化した場合、その規範を統合しすい
- 自立性の支援=自由放任ではない
⇒ 支援する側の「責任」を考えると支援しているのか?自由放任なのか?が見える。
「責任」は立場によって変わるように、支援の仕方も変わる。
- アボカドの例分かりやすい。人は成長する性質は誰しも持っているが、心理的な栄養の良し悪しによって枯れたり腐ったりするのか。
- 統合する上で支援する活動が必要不可欠であり、親、上司といった立場が違えば責任も違うので支援の仕方も違うということか。常に最適な支援をするのは難しいんだろうなぁ。
自我関与は内発的動機づけを低減する(第8章)
- 自我関与(ego involvement)とは？ - 自分に価値があると感じられるかどうかが特定の結果に依存しているプロセスのこと - 例えば、成績に自我関与していると、他のクラスメートのテストの成績をたえずチェックし、そうしてはじめて自分が「まずまずの」できだと知ることができる。 ⇒ より自律的で自己決定的であるためには自我関与から距離をおき、少しずつ自我関与を減らしていく必要がある。 - 自我関与は内発的動機づけの低下だけではなく、別の影響もある ⇒ 学習や創造性を損ない、柔軟な思考や問題解決を必要とするあらゆる課題での作業成績を低下させる傾向がある
- 例え話が身に染みる自分は自我関与から距離を置く必要あると感じた。周りに目を向けすぎず自分の価値とは何か?を考えてたい。
3つの内発的意欲と比較して3つの外発的意欲のいずれかが突出して高いとき精神的健康も低い傾向にある(第9章)
- 3つの内発的意欲とは「意味のある関係」、「個人的成長」、「社会への貢献」 - 3つの外発的意欲とは「金」、「名声」、「美貌」 - 外発的意欲をもち、それを達成できると硬く信じても精神的な健康は低い。 ⇒ 精神的健康の最も重要な要因は達成可能かという期待値の高さではなく、どのタイプの意欲を強くもっているかということ。 - 自律性の支援や関与が十分でないと、取り入れや随伴的な自己の感覚がもらさたらされるだけでなく、より外発的な志向性を促進する - 内発的な人生の目標が強く持てず、精神的な健康のためのしっかりとした基盤が欠けてしまう - 外発的価値の統合(外発的価値と内発的価値とのバランスをとること)は親の養育態度がかなり影響する - また、外発的価値>内発的価値になると、内在化プロセスがうまく行かず外発的価値に合わせて生きようとする
- 子供に対して内発的意欲を支援する親になりたいし、自分や妻の内発的意欲を大事にしていきたい。
- 内発的意欲って本当に大事だな。そのためにも周りの支援がないといけない。
- ただ外発的価値に縛られている自分が子供をうまく導けるのか?とても心配になった、まずは自分から考えを変えないといけない。
自律性を支援する管理者の元で働く従業員はより高いレベルの満足とやる気を示す(第10章)
- 自律性の支援とは？ - 「選択の機会を与えて意思決定への参加を促進させ、活動内容を決定させること」である - 自律性を支援する管理者の元で働くメリット - 従業員は会社をより信頼し、給料や福利厚生のことにとらわれず、より高いレベルの満足とやる気を示す ⇒ 管理者が自律性を支援できるよう訓練することで、彼らの元で働く人達がより優れた成果を上げることができる - 管理されることに慣れている人に対して自律性を支援することは特に難しい ⇒ 対応としては忍耐強く取り組む！
- 相手の立場が分かり、その立場から自律性の支援が出来ることが優れた管理者ということか。そんな人いるのかなぁ。
- 忍耐強く取り組む必要があるのか。なるほどなぁ。管理者の立場でいた時、悪いスパイラルになっていたなぁ。この本を読んだことでもう少し粘り強く対応すればよかったと感じた。
上位の立場で成功するには「自律性を支援する態度を持っている」という共通点がある(第11章)
- 自律性を支援する態度を持っていることが上位の立場で成功するための要素 - 下位の人達の業績や成長、健康に留意し、自律性を支援する態度を持つことが必要 ⇒ 自律性を支援するということは他者の視点から状況が理解できるようにオープンに話を聞くことから始まる。
- オープンに話を聞き、他者の視点から状況を理解し、そして自律性の支援をする。うん、全部難しそう。話を聞き出すスキルが必要だし、他者の視点から考えるのも一筋縄ではいかない。まずは話の聞き方学ぼうかな。
本当に変わろうとしていない場合は、どんなテクニックを用いても失敗する(第12章)
- 自分の抱える問題を別の誰かが成功した際に用いたテクニックを真似るだけでは成功しない。 ⇒ そもそも内発的動機づけがないと成功しないし、テクニックも自分にあっていると感じさえすれば真似ても真似なくても良い。
- 結局は「内発的動機づけ」。全てここから始まる。
ある状況になり、すぐにまわりの人々を支配し始める人は自律的であるとはいえない(第13章)
- 真の自律性には関係性が伴い、他者への尊重を忘れない。 - 何らかの内的あるいは外的な力によって圧力を感じるから、他者を統制しようとする。
- 特定の人を思い浮かべ、妙に納得してしまった。その人は圧を感じ、周りを統制しようとしているのかもしれない。そう考えると優しく接することができそう。
今後
- 話の聞き方を学びたいと感じた。次にテック系ではない本を読むときはそういった題材の本を読みたい。
「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を読んで
書籍
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 作者: 市谷聡啓
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2019/06/14
- メディア: 単行本
- この商品を含むブログを見る
TL;DR
- 不確実性の高い中でのプロダクトづくりには共創によるプロダクトづくり(プロダクト作りの民主化)の開発スタイルが求められる。
- 心理的負荷がかかる時(わからないことが発生した時/境界線の越境時など)の乗り越え方/対処の仕方が書かれている。
- 仮説検証⇒アジャイル開発の流れで開発する上での作業の流れ、ポイントが書かれている。
この本を選んだ理由
印象に残った点
プロダクト作りが上手くいかないのは何故か?を説明している
- プロセスや技術が進歩してもプロダクトを作る苦悩は劇的に変わっていない
- 確かに不思議だと思う。エンジニアとして技術の進歩をキャッチアップするだけでは意味がないということだろう。
- プロダクト/作り手(役割/経験/働き方)の多様性が不確実性を生んでいる
- これまでの不確実性を抑え込む戦い方は下記3点
- 要件定義によって確実性を下げる
- 合意を重視する
- 合意形成を遵守する
- 今の自開発組織はやっと(？)↑の形になりつつある。ただ、それでは上手くイカンということが分かるのはまだ先になりそう。
ユーザストーリーマッピングの要点が書かれている
- ユーザストーリーマッピングはMVPの特定だけではなく、その過程を参加者で作り上げることで文脈を理解する機会でもある。
- 今の組織は分業化されていて、文脈まで意識できていない。個人的には文脈を理解する活動をすべきだと思っていたので納得感がある。
境界線の認識によりプロダクトづくりが上手く行かない
- プロダクトオーナーと開発チームにミッションの境界線(自分達の役割は作るところまで)の認識がある限り、プロダクトづくりはそれ以上進展しない。
- 痛いところをつかれた。境界線があるところには同じ問題があるなぁ。と感じている。自分達の役割を意識しながらも視座を1つ高く持ち、役割の越境をすることを意識したい。
プロダクトオーナーの役割は主に3つある
- 「方向性の番人(なぜこのプロジェクトを作るのか)」「仮説の番人(プロダクトの世界観を実現するために何を備えるのか)」「プロダクトを形にするために必要な運用スキルと知識」
- プロダクトオーナーの求められる役割は幅広く、一人で全てカバーするのは難しい。プロダクトオーナーの強みを活かし、他の役割を他のメンバーでカバーすると良い。
- なるほど。強みを活かし柔軟に対応するのか。プロダクトオーナーが役割を完璧にこなすことが目的ではない。プロダクトを早くユーザに届けるために最適な役割分担も必要だということだろう。
プロダクト作りの民主化
- 独裁的に基準を決めるとボトルネックになり、多様性が生まれない。
- 独裁的に物事を決められるほど全てを把握できるようなスーパーマンは少なくとも周りにはいないと思うし、そのような人を求めるのは現実的ではないと感じる。
- 民主的に物事を決めるには話し合いの労力がかかると思うが、納得感のあるプロダクト作りには欠かせないのではと感じている。
セットベースかポイントベースかの選択はプロダクト作りの状況によって異なる。
- プロダクト作りの状況に応じて適宜セットベースかポイントベースかの選択をする必要がある。決め打ちしてしまうこと自体がリーンの原則に反する。 -プロダクトの特性を考えないで手段を決め打ちすると無駄な作業が発生するということか。
仮説キャンバスの読み方がかかれている
- 仮設キャンバスでは仮説の一本線で構想の筋の良さを判断する
- 課題→代替手段→不満→提案価値→実現手段という一本線の観点でみること。
- なるほど、そうやって読むことで構想の筋の良さを確認できるのか。
- 課題→代替手段→不満→提案価値→実現手段という一本線の観点でみること。
手段に恋してはならない。忠誠を誓う先はあくまで目的である。
- 引き出しを増やす学習は日常的にすべきだが、その引き出しに振り回されては本末転倒ということ。
- 手段に恋しがちな自分には非常に胸に刺さる。なにを達成するための手段なのか？を常に考えたい。
仮説には種類がある
- 課題仮設、ソリューション仮設、インターフェース仮設の3種類
- それぞれ本質、実態、形態にあたる
- 代謝建築論によると、人が対象を認識/理解するプロセスは形態→実態→本質という流れだが、構築のプロセスは本質→実態→形態という順に構想する考え。
- 認識/理解と構築の流れは逆だと覚えておきたい。
仮説検証型のアジャイル開発は精度と頻度の戦略が大事
- 場面に応じ頻度から精度重視への切り替えをする
- どの仮説が確からしいか見立てがついていない状況であれば精度を求めず頻度で学びを得るアプローチをとる
- ユーザからインタビューやハリボテてで得られるものが想像による感想の段階になったら精度をあげる
- 頻度と精度のトレードオフをどのように進めていくかを可視化し、関係者に見える化する
- 利用の現場にチームで出て、イメージを作り手に宿す
わからないことをあえて増やす
- わからないということもわかると同様に「情報」である
- ただわからない状況は気持ち悪さがあり、安易な判断や同調圧力、確証バイアスに負けてしまう
- 気持ち悪く感じるのはよくわかる。ただ、わからないことも「情報」であるとポジティブに捉えていけば気持ちの持ち方も変わると思った。
越境のためのコマンド
- 越境のためのコマンドとは上上下下左右左右過去未来と視座を上げたり下げたり、視野を広げたり、時間軸を変えたりと視座や視野の切り替えのためのフレーム
- コナミコマンドを取り入れた面白い考え!
問いと向き合い続ける共創によるプロダクトづくりになる
- 「役割を中心とした調整によるプロダクトづくり」から「問いと向き合い続ける共創によるプロダクトづくり」へ移っていくはず。
- そうあって欲しい。
今後
- 次はテック系から少し離れる方向の本を読んでみよう。
「ライト、ついてますか―問題発見の人間学」を読んで
書籍
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (188件) を見る
TL;DR
- 昔の本だが問題解決する上で肝となる点が書かれており、現代でも十分に通用する。
- 問題点は何なのか?を考えずに反射的に解答する癖が人間にはある。
- 問題の主語は誰か?を意識するだけで解決策の切り口が変わる。
この本を選んだ理由
- 課長に「オススメ本ありますか？」と聞いたところ、この本をオススメしていただいたから。
- 自分の読みたい本リストに入っていたから。
印象に残った点
ヒトは問題点が何か?を深く考えずに反射的に解答を探そうとしてしまう
- 何が問題なのか?誰が問題と感じているのか?という視点が定まらないと答えが変わる。急いで解答せず、2、3問をしたほうが良い。
- 導入にエレベーター問題があり、本を読みながら解決方法は…と考えながら読んでいた。
- まさに著者の意図どおりに動いていた。意識しないと出来ないな…ということを身をもって体験できた。
問題とは望まれた事柄と認識された事柄の間の相違である
- 相違を減らすような手を打つことが問題解決。
- 問題の本質を捉えるとはこのギャップを見つけることか。問題解決する際は意識していきたい。
問題を持ち込んだ人達の解決方法は問題の定義ではない
- 膨大な組み合わせのある問題を計算パワーで解いて欲しいと依頼があっても、計算パワーで解くことが問題ではない。
- 開発/設計の仕事をしているため、問題だけではなくUserからの要望も同じだなと感じた。
- 解決方法が欲しいのではなく問題解決がしたい。そこが抑えられないためトンチンカンな仕様が生まれるんだろう。
問題理解を破綻させる原因を3つ考え出せないうちはまだ問題を把握できていない。
- 問題定義でも見落としの可能性が何百とあり、そのうちの3つを考え出せないようでは考える力が足りていない。
- 問題定義の時点で破綻させるかもしれない点が3点想像できるくらい問題を理解しろということだろう。
問題の主語は誰か?が大事
- 問題の当事者意識があるかないかがスゴく大事である
- 自分の問題なのか?自分たちの問題ではないのか?と考えることは大事
- タバコの例や飲食店にて財布を忘れた例などはなるほど。と感じた。
- 自分だけではなく、自分たちの問題と常に感じるような癖をつけたい。
- 自分の問題なのか?自分たちの問題ではないのか?と考えることは大事
- 自分の問題を権限によって解決することは反感を買う
- わかりみー。あるあるすぎる。
- 当事者意識を広げることだけではなく、敢えて私自身の問題として捉えると、解決策の切り口が変わる
- 確かに。主語が大きすぎて解決まで時間がかかる場合もある。その場合は主語を変えて自分(達)で出来る方法を考える。
問題の出処はしばじば自分である
- 約53%の確率で問題は問題解決者に起因する
- 入国審査の例があり、厳しくチェックされている側の問題の捉え方によって解決する話があった。
- 「アイツが…」とか「アノ課が…」とかよく聞く。きっとその不満を言っている本人にも問題はあるのであろう。
- 自分も考えを改めないといけない。
- 入国審査の例があり、厳しくチェックされている側の問題の捉え方によって解決する話があった。
今後
- Tech寄りじゃない本も良い刺激を貰える。人にオススメの本を聞いてみて読んでみようと思う。
余談
この本を読むことで知らない文化を学べる
- 「他の人のモカシン靴を履くの法」とはモカシン靴は乾きづらく直ぐに乾くことはないので、同じ気持ちになるまでは時間かかるよ!という意味らしい。
- Never criticize a man until you’ve walked a mile in his moccasins.(人を批判しちゃいけない。その人のモカシンを履いて１マイル歩いてみるまでは)
例題に時代を感じ、文化の違いによって意味がわからない点もある
- 冷戦だったり、PC(計算機)の用途が限定的だったりと例題に時代を感じた。
- 今の若い人が読んだら更に意味がわからなくなりそう。
- また言い回しが独特で文化の違いを感じる。
- 文書として読みづらいと感じることがあり、理解するために時間がかかった。僕だけだと良いが…。
「Webを支える技術」を読んで
書籍
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)
- 作者: 山本陽平
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/08
- メディア: 単行本（ソフトカバー）
- 購入: 143人 クリック: 4,320回
- この商品を含むブログ (183件) を見る
TL;DR
- Webについての概要、基本的な技術(HTTP、URI、HTML)について良く纏まっている。オススメされている本だけある。
- Webサービスの設計の流れ、勘所も書かれており、Webサービス設計のイメージが湧く。
この本を選んだ理由
- Webの最新技術に興味はあり独学中であるが、根底にある基本的な技術について知識が乏しいと感じていたから。
- この本がWebに関する基礎知識を学ぶ上でとても評判が高い為。
印象に残った点
Webについての概要(基礎/歴史/標準化/アーキテクチャスタイルなど)が良くまとまっている
- Webを支えるのは3つの基本的な技術(HTTP、URI、HTML)
- 上記3点についてもかなり章を割いて説明されている。
- RESTは大学院生(Roy Fielding)が考え博士論文として提出した
- RESTはアーキテクチャスタイルであり、クライアント/サーバアーキテクチャスタイルに制約を加えたもの
URIの良い設計(=クールURI)や設計テクニックについて書かれている
- 変わらないURIこそが最上のURIである。
- プログラミング言語に依存した拡張子やパスを含めない、メソッド名やセッションIDを含めない、リソースを表現する名詞にする、という教訓を意識すると良い。
- 設計テクニックとしては拡張子で表現したり(例:言語指定)、マトリクスURI(スラッシュを使った階層化)を使う。
- 複数パラメータの組み合わせであれば、セミコロンやカンマを使う。セミコロンの場合は順不同、カンマは順序に意味がある。
- セミコロンとカンマの違い知らなかった。
HTTPメソッドの種類や役割、性質について記載されている
- 8つメソッドがあるがTRACEとCONNECTはよほど使わない。
- 【GET】最も利用頻度が高く、リソースを取得するメソッド。
- 【POST】GETの次に利用頻度が高く、 子リソースの作成、リソースへのデータ追加、他のメソッドでは対応できない処理(例:URIにキーワードを含めてGETしたいが、キーワードが長すぎる場合にPOSTのボディにキーワードを定義して対応する)の3つの役割がある。
- 【PUT】リソースの更新、リソースの作成の2つの役割がある。
- POSTとPUTの差はリソースのURIをクライアントが決めるか否かになる。PUTだとサーバ側の仕様をクライアントが把握することになり結合が密になる。
- なるほどー!やっとPOSTとPUTの違いがクリアになった。
- POSTとPUTの差はリソースのURIをクライアントが決めるか否かになる。PUTだとサーバ側の仕様をクライアントが把握することになり結合が密になる。
- 【DELETE】リソースを削除する役割があり、一般的にレスポンスにボディを持たない。
- 【HEAD】ヘッダ(メタデータ)のみを取得し、一般的にレスポンスにボディを持たない。
- 【OPTIONS】リソースがサポートしているメソッド一覧を返す。返す際はAllowヘッダを使う。
- POSTでPUTやDELETEを代用することがある。
- HTMLのフォームにGETとPOSTしか指定できないという背景がある(今はAjaxで用いるXMLHttpRequestを使い任意のメソッドが呼べる)
- Ruby on Railsが採用している_methodパラメータを使いContent-Typeにapplication/x-www-form-urlencodedを指定する方もある。
- application/x-www-form-urlencodedが利用できない場合はX-HTTP-Method-Overrideヘッダを利用する。
- そんな背景があったのか。知らなかった。
- HTMLのフォームにGETとPOSTしか指定できないという背景がある(今はAjaxで用いるXMLHttpRequestを使い任意のメソッドが呼べる)
- メソッドにはそれぞれ性質がある。
- GET/HEADは冪等性かつ安全、PUT/DELETEは冪等性だが安全ではない、POSTは冪等でも安全でもない
- PUTとPOSTの違いを表す際に冪等か否かも判断理由になることが分かり、また理解を深めることができた。
- GET/HEADは冪等性かつ安全、PUT/DELETEは冪等性だが安全ではない、POSTは冪等でも安全でもない
Webサービスの設計について書かれている
- リソース指向アーキテクチャのプロセスが書かれている。
- リソースの更新は基本的にはPUT、バッチ処理はPOSTで行う
- バッチ処理のレスポンスはトランザクション化するもしくはどこまで成功したかを送るパターンもある(例:「207 Multi-Status」「D:multistatus」の組み合わせ)
- トランザクション化が一般的かと思っていたがどこまで成功したかを返すこともあるんだ。クライアントにぶん投げてクライアントが頑張るのかな。
- トランザクションをRESTfulで実装する際はトランザクションリソースを使う。
- RESTfulな設計の定石として新たなリソースを導入して解決する。ほぇ～。そもそもトランザクションリソースという考えには至らなかったし、こういう新しいリソースを足して解決するのが定石なのかぁー。
- トランザクションの開始(POST)、処理対象の追加(PUT)、実行(PUT)、リソース削除(DELETE)の手順を取る
- 結構手間かかるんだなぁ。こりゃ大変だ。
- バッチ処理としてPOSTで一括化し、サーバ側で処理を保証する方法もある
- なるほどねぇ～。育ってきた環境なのかサーバ側のほうがしっくりくるなぁ。
- サービス設計はトレードオフ。なるべくシンプルに保つ、困ったらリソースに戻って考える、本当に必要ならPOSTで何でもできるがコツ。
- なるほど～。POSTに頼りすぎないようにしなくては。
リソース設計のコツが書かれている。
- リソース設計は名前(URI)を与えるのが非常に難しい
- 色々と書いたがリソース設計で大事なのはWebサービスとWebAPIを分けて考えないこと！
今後
- 少し昔の本なので得られた知識を更新する必要がある。今の技術動向を常にWatchし、知識のアップデートをしていきたい。
余談
- セマンティックWeb(RDF/microformatsなど)やAtom/Atom Publishing Protocolを話題としてみかけないなぁ。
- 情報感度が足りていないのか、時代が進むにつれてあまり話題にならなくなったのか…。調べて見る限り後者のような気がしている。
- JSONの日付けはタイムゾーン意識したISO8601使うとのこと。
- 医療機器でISO8601のIFを持ってる機種はあまりみかけないなぁ。ええんかしゃん。
「Netlifyで始めるサーバーレス開発」を読んで
書籍
Netlifyで始めるサーバーレス開発 (技術の泉シリーズ（NextPublishing）)
- 作者: 竹本雄貴
- 出版社/メーカー: インプレスR&D
- 発売日: 2019/04/12
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
TL;DR
- Netlifyの概要からFunctionの使い方まで幅広く学べる。
- SlackやLineのURL Hookの方法が学べ、業務や日常生活を改善するための引き出しが増える。
この本を選んだ理由
印象に残った点
Netlifyとは何ぞや？という概要、Netlifyの良い点が書かれている
- Netlifyは開発者が決めたブランチにコミットがされると自動でサイトのデプロイをやってくれたり、PullRequest毎に環境を作ってくれたたりする。
- こんな開発環境憧れるなぁ。今の会社の開発環境との差を痛感。
- NetlifyはHostingだけではなく、FaaSのFunctions、認証サービスのIdentify、フォームサービスのFormsがある。
- Netlifyってこんなに色々できることがあるのか。知らなかった。
- 著者がNetlifyのFaaSを推す理由としては導入/運用のしやすさ。
- Netlify Functionsの実行基盤はAWS Lambda。
LineBotやSlackAPIを学習題材にNetlify Functionの使い方を学べる
- 単純にHello, worldを返すだけのNetlify Functionsの作成から始まり、LineBotやSlackAPIを絡めてNetlify Functionの使い方を学べる。
- LineBotやSlackAPIを利用することになるので、どういった仕組みで開発者にサービスを利用してもらおうとしているのか？も学べて良い。
- どちらも共通してURL Hookできるような仕組みが提供されていた。互いに共生していくスタイルを取りたいのだろう。
- 本記載時からLine Developersのプランが変更になっており、少し焦った。
- プランについて設定画面に出てこないのも納得。(参考にした記事)
- Slack APIを使って投稿する際のメッセージフォーマットはJSON形式。
外部に公開するようなサービスの一般論について教えてくれる
- Tokenのように外部に見せるべきではないものは環境変数として定義するのが一般的。
- Netlifyではプロジェクトの設定画面にて環境変数を設定できる。
- 外部に公開するようなサービスを作ったことがないので、こういう一般論は凄く有り難い。
- Netlifyで環境変数を設定できるのか。公開するようなサービスはどれも同じような事ができるんだろうなぁ。利用時には気にしていきたい。
ちょっとした誤字があった
- 下記は間違っていると思われる。
// Kindle版：位置No.485あたりの「src/game.js」 // 誤り const targetEvent = body.events[0] // 正しい const targetEvent = webhookBody.events[0]
// Kindle版：位置No.511あたりの「src/game.js」 // 誤り import messageData from './gameMessages' // 正しい import messageData from './gameMessage' // jsファイルは複数形ではないので。もしくはファイル名を直すか。
今後
- Firebase Functionについて学習したい。
- TypeScriptちょっと興味が出てきたので学習したい。
余談
- Node.jsってバージョン管理するツール入れる人が多いんだ。知らなかった。Windows環境なのでnodist入れてみた。
- npm init -y ってどういう意味なんだろうか？知らないことが多すぎる。
- 「プロジェクトを新規追加するときに、毎回同じ情報を入力することにうんざりしているなら、-yフラグを使って多くの項目をデフォルト設定にできます。」とあった。そういうことね。(参照)
- NetlifyのFunctionsを使うためにTOMLファイルが必要。TOMLって何？？今まで独学してきたけど出会わなかった。。。
- netlify-lambdaパッケージを使うと動作環境用の開発サーバを立ち上げてくれて毎回Pushしなくても確認できる。
- netlify-lambdaはバンドルツールであるwebpackのラッパーライブラリとのこと。
「改訂新版 Vue.jsとFirebaseで作るミニWebサービス」を読んで
書籍
改訂新版 Vue.jsとFirebaseで作るミニWebサービス (技術書典シリーズ（NextPublishing）)
- 作者: 渡邊達明
- 出版社/メーカー: インプレスR&D
- 発売日: 2018/10/05
- メディア: オンデマンド (ペーパーバック)
- この商品を含むブログを見る
この本を選んだ理由
印象に残った点
(以前に読んだ本よりも)Firebaseについて詳しく書かれている
- Firebaseはスケーラブルだが大量のユーザやトラヒックを扱うとなると運用にかかる費用は自前でバックエンド開発したほうがコストが安くなる傾向があるとのこと
- どこのラインが境界になるのか？は別途調べないと分からないにしてもありがたい情報。
- 本を読みながら実装すればGoogleアカウントでのログイン＆ログアウトも簡単に実装できる。やりおるFirebase。
- Firebase DatabaseはJSONで設定を記述する。認証だけではなくValidateやIndexの設定も出来る。(参照)
- 認証設定はカスケード式なので数珠つなぎで設定が引き継がれるが、Validateはカスケード式ではないので個別に書く必要があるらしい。
- Firestore学びたいのぉ。
- 認証設定はカスケード式なので数珠つなぎで設定が引き継がれるが、Validateはカスケード式ではないので個別に書く必要があるらしい。
- value イベントを使用して変更をリッスンするにはon()またはonce()を使う。(参照)
- on()であれば常に、once()であれば一回だけトリガーされる。
- Valueの対象は指定したDBのパスの子要素が変更されても対象になるとのことで、rootを指定するとめちゃ呼ばれてえらいことになるらしい。
- ただ、Firebase Functionはこの本に記載がないのが心残り。
コラムの「ちょい足しポイント」や「用語説明」があり、私のような初学者にとってありがたい
- 「次にこの内容を学びたい！」「そのワード気になってたんで補足あって助かる～」ということが多く、個人的には凄く良い。
- CircleCIでFirebaseのdeployができると書いてあり、脱線してCircleCIを触るきっかけとなってとてもありがたかった。
フロントエンド開発(JavaScript/Vue.js/CSS等)についても色々と学ぶことができる
- 少し齧ったことがあったので、得られることは多かった。
- 完全に初心者だと少しとっつき辛いかもしれないと思った。
- 下記については知らなかったので良い勉強になった。
- vue-cliのWebpack-simpleテンプレート使うとwebpack-dev-serverが入るのでローカルサーバ立ち上げれる。
- webpackのSourceMapとはなんぞや？ということがわかった。
- marked入れると簡単にMarkdownエディタ作れる。
- 標準のCSSはmargin等が入っていて意図通りのデザインにならないことの原因になるため、一度リセットすることがあるとのこと。知らなかった。
- githubのMarkdown表示用CSSあるんだ。へぇー。
- ロゴフォントの試し書きサイトがあるんだ。へぇー。
- Webサイトの利用規約について書き方が書かれているサイトがあるのか。そのサイトを参考にしつつ類似サービスの規約も見て随時追記すると良いとのこと。規約について触れることもなかったので勉強になるなぁ。
今後
- Vue.jsもう一回勉強したいなぁ。
- (Firebase Function以外でも良いので)FaaSについて学びたいなぁ。
余談
- ブログへのアクセス情報をもっと細かく知りたいと思い、こちらを参考にGoogleAnalyticsを導入してみた。
- もっと早くから導入しておけばよかったと後悔している。
