Next.js にレイアウトに関するドキュメントが追加されました

この記事は個人ブログと同じ内容です

zenn.dev

 

 

Next.js の Layout 周りのドキュメントが新しく追加されました。

単一のレイアウトを扱う場合

単一のレイアウトで十分な場合はカスタマイズした <Layout/><Component /> タグを囲むだけで実装できます。

// pages/_app.js

import Layout from '../components/layout'

export default function MyApp({ Component, pageProps }) {
  return (
    <>
      // Layout でアプリケーションのコンポーネントを囲むだけ
      <Layout>
        <Component {...pageProps} />
      </Layout>
    </>
  )
}

ページごとに異なるレイアウトを扱う場合

ページごとに異なるレイアウトが必要な場合は getLayout でページごとにレイアウトを定義します。 getLayout を使用してレイアウトの切り替えを行うことで、コンポーネントツリーがページ遷移間で維持されるため永続的にレイアウト内の state を保持することができます。 コンポーネントツリーが維持されると React は state を維持しつつ、必要な要素のみ再レンダリングします。

// pages/index.js

import Layout from '../components/layout'
import NestedLayout from '../components/nested-layout'

export default function Page() {
  return {
    /** Your content */
  }
}
// 個別のページごとにレイアウトを定義する
Page.getLayout = (page) => (
  <Layout>
    <NestedLayout>{page}</NestedLayout>
  </Layout>
) 
// pages/_app.js

export default function MyApp({ Component, pageProps }) {
  // ページごとに定義されたレイアウトがある場合はそれを使用する
  const getLayout = Component.getLayout || ((page) => page)

  return getLayout(<Component {...pageProps} />)
}

データフェッチ

Layout 内でのデータフェッチはクライアント側でのみ可能です。 Layout はページではないため、今のところ getStaticPropsgetServerSideProps は使えません。

プレビュー

Next.js 公式リポジトリのサンプルがわかりやすいのでぜひ触ってみてください。

Open in StackBlitz

生活習慣をエンジニアリングする

株式会社ROXX agent bank開発チームのorifujiです。チーム内での取り組み「Rock Activity」の一環で本記事を投稿します。 元々、何かしら新しく身につけたい技術に触ってみてそのコード解説をしようかとも思っていました。いたのですが、ごく最近の自分の取り組みとして最もちゃんとしたActivityだったのはこれだな、ということで、直近の生活改善内容を綴ってゆく方向へ舵を切りました。 生活改善に関わるちょっとしたtipsと、それに対するわたしの所感が書かれています。たぶん、ギリギリ技術ブログなのでは……

ちなみに最近始めた個人ブログで先に公開しています

「これは、ポンコツポンコツによるポンコツのための生活改善案だ。万国のポンコツよ、とりあえず朝起きろ!」

というわけで、生活習慣を見直すための記事を始めます。ここ数ヶ月のわたしの悪戦苦闘の様子が見られます。

TL;DR

  • 意志ほど信用ならないものはありません。良い行動を仕組みや条件反射に落とし込み、自らの身体を傀儡のように扱いましょう
  • 睡眠をコントロールしましょう
  • 適切に休憩するためのフックを用意しましょう
  • 疲れにくくするために身体を鍛えましょう
  • 業務中に自然とできていることは私生活にもだいたい応用可能なので、とりあえずやってみましょう(まずは、スクラム的なふりかえりから!)

序:経緯・動機

なんかうまくいかない日々

冒頭に偉そうな発言を引用しましたが、何を隠そう、誰よりもまずわたしがポンコツだったのです……

具体的には、現職への転職後、概ね下記のような状態に陥っていました。

  • 毎日、業務時間内に体力が尽きる
  • ちょっとしたことで生活リズムが崩壊する
  • 結果、入社2ヶ月目で2回も遅刻
  • 趣味・学習に時間が費やせず、成果もイマイチ
  • 思考が澱み、たいして面白いアイデアも出てこない
  • 何よりも仕事が遅い

前職での心身の疲れが尾を引いていたとはいえ、これはなかなか手痛いズッコケです。 「面倒だけど、どうにかしないとなぁ」などと零しつつ、どうにか挽回するためにさっと簡単にできるとこから始めちゃおうぜ、というポジティブシンキングを開始しました。

そのあたりまえ、あたりまえに出来ていますか?

そこで、簡単にできるNext Actionとして、「問題解決方法・生活改善に関して書かれた本」を多読してみてアイデアを拝借するを案出しました。

のですが、白状すると、実は筆者はこれまで、ビジネス書・自己啓発書をあまり読んできませんでした。正直に申し上げると、「内容が薄い」「あたりまえのことが書かれているだけ」「一面的な思想を煽情的なキャッチコピーとともに押し出している」ような印象を抱いていたのです。そのため、長年に渡り距離を置いていました。

そのため、アイデアとして思いついておきながらも、ちょっぴり及び腰になります。

しかし、昨今の為体から、自身の考えに対して疑問が生じてきます。例えば、「本当にデキるビジネスマンが参考にしているなら一読の価値はあるのでは?」「あたりまえのことって……本当にできてる?」というように。

そんなわけで、とりあえず馬鹿にせずに読みまくってみよう、と決めました。だいたい、2021年6月から7月の出来事です。

読んだ本

書店やAmazonで幾らか見繕います。あまり知識のない領域なので、売れ線や「わたしでもよく聞く本」から選んできました。

  • 安宅和人『イシューからはじめよ』
  • ジム・クウィック『LIMITLESS 超加速学習: 人生を変える「学び方」の授業』
  • グレッグ・マキューン『エッセンシャル思考』
  • Testosterone・久保孝史『超 筋トレが最強のソリューションである 筋肉が人生を変える超・科学的な理由』
  • 樺沢紫苑『インプット大全』
  • 樺沢紫苑『アウトプット大全』
  • 樺沢紫苑『神・時間術』

などなど。時には(神の時間術ってなんだよ……)などと思いつつも、全て読み切りました。結構楽しい体験でした。折を見てジュンク堂書店池袋本店1F, 5F(↑のような本がいっぱい置いてあるところ)とか覗きに行くかもしれません。

生活習慣改善・行動改善の本は少なめかも知れませんが、いずれの本も今回のテコ入れには少なからず役に立ってと思っております。

振り返ってみると、今回採用した改善案には幾らかの書籍に共通して書かれていた事項が多いです。また、著者独自というよりは一般論的な見解も多かったと判断しているため、直接的な引用をしない限りは個別に詳しく典拠を注釈することはしません。上記の紹介に留めます。

本:やったこと、わかったこと

学習効率化や問題解決の本が多めになったのですが、今回はいったん、そういうものよりも生活習慣改善・行動改善にフォーカスして、得た知識をまとめてみようかと思っています。 今回はとりあえず最近の取り組みをまとめるだけですが、後々、プラクティスをより体系化して記事にします。

睡眠改善

ツラミポイント

  • 起きるのが遅いと仕事の立ち上がりが悪い
  • そもそも睡眠時間が短い
  • 目覚めが悪い
  • 昼食後、かなり眠くなる

対処

早寝のための行動

上掲の書籍群の一部を参考にしつつ、下記を行いました。

  • 後述する筋トレ活動で身体を追い込み、疲れで寝てしまう状態をなるべく作るようにした
  • 生活リズム補正が必要なときのために、かかりつけの医師と相談のうえ、メラトニン錠剤を個人輸入した
早起きのための行動と、目覚めを良くするための行動

「意識が覚醒したら意地でも目を瞠ることを習慣とする」は効果的でした。セロトニンが云々……などと説明することもできますが、それ以前の単純な話、目をあけていれば二度寝はしないんです。意識が安定し、立ち上がることができるまで目を開き続けます。 気合いで解決、みたいな方法に見えますが、慣れると条件反射的に目を開けるようになりますし、いきなり起き上がるよりはたぶん楽です。

しばらくして立ち上がることができたら、廊下に出て日光を浴びます。自宅の場合、窓の構造上の問題等で自室に日光を入れることが期待できないため、都度廊下に出ています。日光浴の最中は軽く動的ストレッチなどをすると、手持ち無沙汰感がないです。

それが終わったら、階段昇降または散歩を行い、軽い運動とします。これやるだけで頭の冴え方が違う気がしています。

日中の眠気や集中力低下を抑制するための行動

これは端的に「昼寝」です。30分程度で済ませるのがベストだと思います。

なお、万一の寝落ち防止のため、布団に臥せることは避けます。万年床は危険なのです。朝のうちに畳んでおくと良いでしょう。

布団の代わりに、ネックピローをつけながら椅子で軽く寝ることにしています。目覚ましがなったら確実に起きられる程度の状態で寝る、がちょうどいいですね。

得たもの

  • 過度な夜更かしをしなくなった
  • 毎日コンスタントに7-8時間の睡眠が確保できるようになった
  • 午後も集中してタスクに取り組めるようになった

筋トレ

ツラミポイント

  • 体力がない
  • 気分が沈みがち
  • 音ゲーで疲れる

対処

筋トレする、が対処な訳ですが、具体的にどういうメニューをやっているか、継続するためにどのようなことをしたかと綴っていこうかと思います。

メニュー
  • 拳立て 10 x 3
  • 腹筋 10 x 3
  • 腹斜 10 x 3
  • プランク 30sec x 3
  • 足上げ腹筋 10 x 3
  • 背筋 10 x 3
  • ダンベル(計12kg)有スクワット 10 x 3
  • ハンドグリップ(60kg) 左右 10 x 3
  • ランニング(距離不定 range: 0-8km)

上記を基本として、回復させたい部位は適宜メニューから除外、その分は別のメニューを補填する形で運用しています。例えば腕を重点的に鍛えたいときはダンベルカールを追加しています。

取り掛かる

このメニューをPC画面に大きく表示させて、上から順に

  1. メニュー内容を声に出す
  2. 声に出したら「やらないとな……」という気分になって取り掛かる
  3. 次のメニューに移る

を繰り返します。思いのほかこの声出し法は推進力が高くぶっ続けになりがちです。「続かないしんどい追い込み」を避ける意味でも、適宜休憩宣言(21:50まで休憩! とひとりで叫ぶ)をしています。現状、タスクの区切りごとに叫ぶのは本当に効果的なので、筋トレ以外にも応用したいところです。

続ける

筋トレやダイエットの三日坊主はよく聞くところです。予防的に、以下の対策をしておきました。

  • おいしいと思えるプロテインを購入し、「プロテインを飲みたい→せっかくなら筋トレしなきゃ」のサイクルを確立(プロテイン駆動)
  • 会社のslackに筋トレchを作成し、毎日筋トレ宣言or報告
  • 筋トレのアニメをNetflixで自宅上映し、気分を盛り上げる

得たもの

  • 目覚めが良くなった
  • 体力が戻り、一日中業務に集中できるようになってきた
  • 前向きな気持ちになってきた

氾濫する情報の群れをシャットアウトする

つらみポイント

下記について流石に嫌気がさしていました。

  • 怒り、焦り、そのほか諸々の良くない感情
  • コロナ禍の不安なニュース
  • オリンピックなどの時事にまつわるネガティブなニュース

社会課題が浮き彫りになる事件ではありますし、議論を避けることが現状追認を招いてしまう側面もあるかとは思います。 ただ、あまりにもネガティブな感情が出回っているため、健康を取り戻すまでは離れた方がいいな、と。 行動改善系の書籍でもSNS断捨離的なワードがよく目につきました。 そういうわけでとりあえずTwitterから始める形で、各種SNSと距離を置くことに。 それにしても、インターネット歴約20年にして、ようやくTwitter疲れを検知できたわけです。遅すぎですね。

対処

で、もうばっさりやってしまいました。

  • 手元端末からの公式クライアントアプリの削除
  • 自発的な更新をほぼ停止
    • またその旨を宣言してプロフィールに固定
  • フォロー先全てに対してRTミュートを適用
    • 例外的に見に行く必要が出た場合にも「知らない人の知らない言葉」を表示しないように

ここまでしてやっとTwitterに費やす時間を大幅に減らせました。

得たもの

イライラする契機が格段に減りました。ながら作業的に触って集中力を乱されることもなくなりました。

「独り言を多方面に向けて発信する」欲はslack, discordで代替できています。

スクラム的な考え・活動を私生活に輸入する

弊社開発チームでは一週間スプリントでスクラム開発を回しており、特に毎週金曜日には

  • スプリントレビュー
  • ふりかえり(レトロスペクティブ)
  • リファイメント
  • プランニング

などのスクラムイベントを行っています。このFWをプライベートにも持ち込んでみるのは面白そうだなと思い、同居人と、2週間スプリントで軽くスクラム生活をしてみることにしました。その施策の内容を書き出してゆきます。厳密さよりも手軽さを優先する方針ですので、ここに関してはツッコミご容赦を。

ふりかえり

良かったこと・悪かったこと・生活上の課題などを出してゆきます。例えば、以下のような感じに。

  • Good:仕事に結構集中できた
  • Good:オンラインゲームで遊ぶのに時間を捻出できたのは良かった
  • Good:筋トレ用具を買い足したおかげでモチベUP
  • Bad:ゲームに熱中しすぎて睡眠時間が減った
  • Bad:浪費の傾向がある
  • Problem:玄関先の雑草が邪魔で歩きにくく、雨の降った後はズボンがやたらに濡れる
  • Problem:2人で半日かければ終わりそうだから、来週末にカレンダーを押さえておこう

リファイメント

検知された問題への具体的な対処方法を検討します。例えば先程のProblem「玄関先の雑草が邪魔で歩きにくく、雨の降った後はズボンがやたらに濡れる」「お米のストック追加がギリギリになるから夕飯を食べ逃すことがある」などの困りごとについて、対処法を検討します。 前者は「草むしりとりあえずやろうか」「除草剤撒いちゃう?」などのようなアイデアが出るかと思います。そんな感じで、ブレインストーミング→タスク化→合意形成を進めます。

プランニング

リファイメントで詳細化したタスクがどれだけ時間をかければ問題なくこなせる作業かを見積り、いつ着手するかを計画します。例えば、リファイメント時の結論「玄関先の草むしりを歩くときに邪魔にならない程度にやっておく」というタスクに対して、「2人で半日かければ終わりそう」のような見積もりを行い、「カレンダーに予定を入れておこう」というように計画を立て、アクションに繋げます。

やってみた感想

やってみれば、これもやはり「当たり前の話し合い」に尽きるところはあったかと思います。特別なこともない営みではありましたが、意識的に実行すること自体の良さが存在しました。 「アイデア出しの時間を決めて、付箋に書き出し、ラウンドロビン形式でメンバーに展開する」などのチームである程度慣れていた方法を流用したことで、時間対効率を高められましたし、問題検知が普通に雑談しているよりかは高精度でできるようになった気がしています。 決まった日時に話し合う機会を設けることで、事前に考えておくこともでき、そもそも問題を棚上げにしてなあなあで済ませることもなくなるのが、体験として素晴らしいですね。

跋:成果、つぎにやること

自分に期待しない、という期待の仕方

意志ほど信用ならないものはないですね。頑張るとかどうにかするとか、曖昧な対処ではなく、仕組みに落とし込むことこそが大事。あたりまえですね。繰り返しになりますが、そのあたりまえができていない点に、病因があります。

いまだにポンコツのままですが、幾らかの成果は出ました

生来のポンコツ具合ゆえになかなか思うようにはいきませんが、当初目的は達成できたと認識しています。

  • 仕事内容の質的向上
  • 学習・趣味に費やす時間の増大
  • 生活リズムの安定
  • メンタルの安定

ですね。読書時間が増えたので、積読が高速消化されています。こんなに楽しいことはありません。

今後の予定

「◯◯をエンジニアリングする」シリーズを継続的に投稿してゆこうと考えています。

題材候補

  • 集中力をエンジニアリングする
  • 業後学習をエンジニアリングする
  • 家計をエンジニアリングする

……エンジニアリング、の意味が良くわからなくなりそうですが、小さなことでも「明確な目的意識を持ち」「なるべく技術的に問題を解決しようとする」態度をそう表現するのも悪くないかもなと思い、気軽になんでもエンジニアリングに含める方向でこのまま突き進みます。

感想

全体、気分が良くなったので満足しています。 レベルの低いこと、当たり前のこと、でもできていないこと。そういう見落としを認識する契機としては有意義な時間だったのではないかと省みる次第です。

今後は本記事に載せたような生活改善施策を高精度のプラクティスとして洗練させ続け、生活の質を高めたいなと思っています。引き続き、自己改善を行ったり、身近な人としっかり話し合ったり。生活にメリハリをもつと気持ちいいんですね。ごく最近、気がつきました。

プロダクトを改善するなら自分も改善していかないと、との思いで今後も続けてゆきます。

ROXXに転職して2ヶ月が経ったエンジニアから見た開発チームのあれこれ

2021年6月に開発チームにjoinしたpoisonと申します。これからよろしくお願いいたします。

今回、開発チームのタスク内で自分の価値を発信しよう!という動きがあったので、ブログを書くことに決めました。

はじめに

私はSESで各現場にアサインされJavaScriptFWでよく使われているAngular・Reactを使用したWebアプリケーション製造に携わっておりました。

そしてこの度、Vueを扱っている弊社にjoinすることができ3大制覇したことをきっかけに、その扱い方の違いについて書こうと思いました。

ただ、2ヶ月経った今、開発チームの雰囲気や1週間の流れを入ったばかりのエンジニア視点で書けるのは今しかないと思い、今回はこちらを題材にしました。

(3大制覇に関してのブログは後日書けたら書きます…) 

私のスペック

2017年新卒、ROXXで3社目(1~2社目はSESで現場常駐)

主に扱ってきた技術は、JavaJavaScript(Angular,React)・Redux等

もっと自分の価値市場を上げたい、事業会社に入ってプロダクトを育てる立場になりたいという思いから2020年12月に転職活動を開始し、翌年3月にROXXから内定をもらい今に至る

開発チームの実情

ROXXには「agent bank」「back check」の2つのサービスがあり、私が所属しているのはagent bankのDevチームです。

今は、フルリモートで働いており、業務中は常にDiscordというアプリを使用して、常時通話状態で作業している状況です。

常時通話状態なので、リモートなのに出社している緊張感を感じることができ、家にいるけど職場の雰囲気を感じながら仕事しております。

基本はスクラムチームとして動き、1週間スプリントでタスクをこなし毎週金曜日にスプリントレビュー・振り返り・リファイメント・プランニングを実施しているという流れになってます。

個人的には、この流れがすごく好きで、1週間できちんと終えて、また次の週から始められることでスッキリ週を終えることができます。

チームの人数は執筆時点で12人ほどいて、プロジェクトが複数動いていることから半分ずつチームが分かれ、日々のタスク消化をしている人数は5~6名で回しています。そこから、基本ペアプロを行っているため、2~3レーンで進めてます。

毎日、同じメンバーとペアプロするのではなく、日々シャッフルしながら実施しているためメンバー内で話したことがないというのはないです!日々、和気藹々とやっている反面、真面目に議論するときもあるので個人的にはいい雰囲気で過ごしています。

いろんな現場を見てきた身からすると、技術が強いメンバーもいるため、わからないこととかは気軽に聞くことができる環境となっており、個人的にはとても助かっております。 

おすすめの活動

私がチーム活動の中でおすすめする部分として2点あります。

1つ目は、毎日の振り返りです。

私たちのチームでは、月曜〜木曜までは、朝会・昼会・夕会を実施しており、メンバーの進捗を随時確認してます。

夕会では、「やったこと」「おきたこと」「わかったこと」の頭文字をとりYOWというFWを使用して取り組んでおります。

その日のうちに、実際やったこと・それをしたことで起きたこと・その中で分かったことを振り返りし、週末の振り返りの際にはそれを見返すことで忘れず、1週間の流れを確認することができます。

その後、何がよかったのか・問題点はなんだったのか・今後どうアクションしていくかを決めスプリントを閉じるという流れで実施しております(俗にいうKPTですね)。

デイリーの中でメンバーそれぞれが出し合ったものを確認すると、分かってなかったことその日に起きたことなどを知る機会が増えるので、いろいろと話し合ったりしてお互いに知識を深め合う場としても活用しております。

2つ目は、リファイメントについてです。

スクラムチームの活動は、転職前にも経験していたのですが、その時は、タスクの見積もりをするだけの活動となっていました。

私たちのチームでは、タスクの見積もりはプランニングで行い、リファイメントではPOが何個かの改善点をBizの方々から抽出し、チームに落とし込んで、何をどうすればその状況が解決するかを全員で考える場として使ってます。

これをすることで、受動的ではなく能動的にタスクと向き合えることができる気がしております。

それだけでは終わらず、リファイメントした後に設計タスクと題して、DB構造であったりどんな機能が必要かであったりを複数人で考えるタスクがあり、コーディングだけでなく設計能力も高めることができる場が設けられております。

コーディングだけを主に行ってきた身としてはとても新鮮で、毎度関わることができているので、どんどん価値を出していきたいと思っております!

私が思うチームの課題点

新参者がいきなりチームの課題を出すというものも、大変烏滸がましいと思いつつまだまだここは足りないかもしれないと思う点があります。

それは、属人化についてです。

主に、インフラに関してですが、作業できるレベルの方が少数しかおらず、その方が休んだ暁には、危機的状況になっているのが現状です。

この件に関しては、チームだけでなく開発事業部全体で考えており、属人化を回避するために、2つのサービスの開発チーム合同で勉強会を行ったりしております。そういった行動を積み重ねて、各人が作業レベルで触れるようになるために、まずは基礎知識をつけてその上でわかる方とペアプロする形で学んでいくような体制を作ることができればベストかと思っております。

私もまだまだインフラに関してはど素人なので、とりあえず環境を作ってみようということで、今後触っていこうと思っております。

今後の目標

今後の目標としては、今までは主にフロントエンドしか触ってなく、サーバーエンドやインフラに関してもどんどん積極的にタスクをこなして、自分のものにしたいと考えております。

それを実施することができる、チームにはとても感謝しております。今後も自分の価値を発揮できるように精進していきたいと思います。

終わりに

この記事を読んで、もしROXXや開発チームに興味が出てきた方がいましたら、ぜひご応募ください!お待ちしております!

 

careers.roxx.co.jp

AWS Lambda と API Gateway を連携させてエンドポイントを作成する

この記事は個人ブログと同じ内容です

www.ritolab.com


サーバレスアーキテクチャ構築の第一弾です。

今回は AWS の Lambda と API Gateway を連携させて、エンドポイントを作成していきます。

サーバーレス・コンピューティング

自身でサーバーを運用せずに IaaS 等のサービスを利用して処理のロジックだけをデプロイ。必要な時にだけホストした処理を動作させる一連の仕組み。

例えば、いくつかの処理を行う API サーバを持っているとして、そのサーバは 24 時間 365 日稼働させる必要がある。

サーバレスにすれば処理のロジックをリモートにホストしておき、必要な時にだけ動作させる事ができて、自身でサーバーを運用する手間が省ける。(サーバーに関するセキュリティや可用性をその分気にしなくて良くなる)

さらには動作した時間だけの課金になるので、24 時間 365 日サーバーを稼働させるよりも(大抵は)費用が抑えられる。

サーバーレス・コンピューティングを提供している主な IaaS

余談ですが AWS では、Well-Architected Framework という指針(AWS を用いた設計のベストプラクティスなど)を出していて、その中の「パフォーマンス効率」の章でサーバーレスアーキテクチャを推奨していたりもします。

docs.aws.amazon.com

AWS Well-Architected Framework

wa.aws.amazon.com

AWS Lambda

AWS Lambda はサーバーレスコンピューティングサービスで、サーバーのプロビジョニングや管理、ワークロード対応のクラスタースケーリングロジックの作成、イベント統合の維持、ランタイムの管理を行わずにコードを実行できます。

引用元:AWS Lambda(イベント発生時にコードを実行)| AWS

AWS でサーバレスやるぞってなったらこいつですね。

aws.amazon.com

Amazon API Gateway

フルマネージド型サービスの Amazon API Gateway を利用すれば、デベロッパーは規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護を行えます。API は、アプリケーションがバックエンドサービスからのデータ、ビジネスロジック、機能にアクセスするための「フロントドア」として機能します。

引用元:Amazon API Gateway(規模に応じた API の作成、維持、保護)| AWS

こちらはサーバレス云々というより、API を作成できるサービスです。今回は API Gateway でステートレス API を作成して、アプリケーションからそのエンドポイントを叩こうと思います。

API Gateway で作成したエンドポイントにリクエストしたら、Lambda の処理が動く。という流れです。

aws.amazon.com

開発環境

今回の開発環境は以下になります。

  • Terraform v1.0.2

ちなみに今回、AWS Lambda は Node でやります。

ホストするコードは JavaScript になるわけですが、今回はこれも terraform で管理します。

実運用だと別々での管理が望ましいと考えますが、それよりもとにかく動かしてみたい欲が先行したので今回はその辺は割愛します。

それと、tf ファイル作成していく中で functions へのパスを書いているのでディレクトリ構成を事前共有しておきます。

.
├── functions
├── src
└── terraform
  • functions(Lambda にホストするコード)
  • src(アプリケーション)

Lambda にホストするコード

まずは、AWS Lambda にホストするコードを作成しておきます。

functions/tf-test-node-hello-world/index.js

exports.handler = async (event) => {
    return {
        isBase64Encoded: false,
        statusCode: 200,
        headers: {},
        body: JSON.stringify('Hello from Lambda!'),
    };
};

「Hello from Lambda!」を返すだけの関数です。

また、API Gateway が Lambda からレスポンスを受け取る場合は形式が決まっているため、そちらに倣った形式にしています。

docs.aws.amazon.com

Lambda の構築

Lambda を構築していきます。

CloudWatch

Lambda の実行ログを CloudWatch に流すのでロググループとロールを作成します。

AWS Lambda の Amazon CloudWatch ログへのアクセス

docs.aws.amazon.com

main.tf

variable "function_name" {
  type    = string
  default = "tf-test-node-hello-world"
}

# CloudWatch Logs for lambda
resource "aws_cloudwatch_log_group" "node_lambda_hello_world" {
  name = "/aws/lambda/${var.function_name}"
}

# Lambda Role for logging CloudWatchLogs
resource "aws_iam_role" "lambda_node_logging" {
  name = "${var.app_name}-lambda-role"

  assume_role_policy = jsonencode({
    Version : "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          Service = "lambda.amazonaws.com"
        },
        Action = "sts:AssumeRole"
      }
    ]
  })
}

resource "aws_iam_policy" "lambda_node_logging" {
  name        = "${var.app_name}-lambda-policy"
  description = "IAM policy for logging from a lambda"

  policy = jsonencode({
    Version : "2012-10-17",
    Statement = [
      {
        Action   = "logs:CreateLogGroup",
        Effect   = "Allow",
        Resource = "arn:aws:logs:${var.aws_region}:${var.aws_id}:*"
      },
      {
        Action = [
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ],
        Effect = "Allow",
        Resource = [
          "${aws_cloudwatch_log_group.node_lambda_hello_world.arn}:*"
        ]
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_node_logging" {
  policy_arn = aws_iam_policy.lambda_node_logging.arn
  role       = aws_iam_role.lambda_node_logging.name
}

Lambda へのデプロイ

今回は terraform で Lambda にデプロイするコードも管理するので、ローカルで ZIP を作成するようにしておきます。

main.tf

data "archive_file" "lambda_function" {
  type        = "zip"
  source_dir  = "../functions/tf-test-node-hello-world"
  output_path = "../functions/upload/tf-test-node-hello-world.zip"
}

これで terraform plan ないし terraform apply 時に ZIP が作成されます。

Lambda function の作成

最後に、メインである関数を定義します。

main.tf

resource "aws_lambda_function" "hello_world" {
  filename      = data.archive_file.lambda_function.output_path
  function_name = var.function_name
  role          = aws_iam_role.lambda_node_logging.arn

  handler = "index.handler"

  source_code_hash = filebase64sha256(data.archive_file.lambda_function.output_path)

  runtime = "nodejs14.x"

  depends_on = [
    aws_iam_role_policy_attachment.lambda_node_logging,
    aws_cloudwatch_log_group.node_lambda_hello_world
  ]
}

docs.aws.amazon.com

docs.aws.amazon.com

Lambda 構築実行

ここまで書いて terraform apply を実行すると、Lambda に関数が出来上がります。

f:id:ro9rito:20210720113408p:plain

API Gateway の構築

次に、作成した Lambda 関数を実行するためのインターフェースを Amazon API Gateway を使って作成していきます。

API 作成

API を作成します。インターフェースの大本を作成するイメージ。

API タイプは用途によって最適なものを選択する必要があります。今回は REST API で作成します。

docs.aws.amazon.com

main.tf

# API Gateway
resource "aws_api_gateway_rest_api" "to_lambda_node" {
  name        = "${var.app_name}-to-lambda-node-api"
  description = "REST API for lambda node test"
}

リソース作成

/hello_world のリソースを作成します。

main.tf

## for Function: hello world
### リソース作成
resource "aws_api_gateway_resource" "hello_world" {
  rest_api_id = aws_api_gateway_rest_api.to_lambda_node.id
  parent_id   = aws_api_gateway_rest_api.to_lambda_node.root_resource_id
  path_part   = "hello_world"
}

メソッド作成

メソッドはリソースに対して GET や POST などの HTTP リクエストメソッドを作成します。ここでは GET で作成します。

main.tf

### メソッド設定
resource "aws_api_gateway_method" "hello_world" {
  rest_api_id   = aws_api_gateway_rest_api.to_lambda_node.id
  resource_id   = aws_api_gateway_resource.hello_world.id
  http_method   = "GET"
  authorization = "NONE"
}

lambda 統合を設定

今回は API Gateway で作成したエンドポイントがリクエストを受け取ったら Lambda function を実行するので、API Gateway と Lambda を紐付けます。

API Gateway では Lambda との連携がスムーズにできるようにこういった設定も用意されているので紐付けが簡単に行えます。

main.tf

### lambda 統合
resource "aws_api_gateway_integration" "hello_world" {
  rest_api_id = aws_api_gateway_rest_api.to_lambda_node.id
  resource_id = aws_api_gateway_resource.hello_world.id
  http_method = aws_api_gateway_method.hello_world.http_method

  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.hello_world.invoke_arn
}

ポイントとしては、integration_http_method を POST に指定している点です。

lambda への統合 method は POST で固定となっています。

aws.amazon.com

デプロイメント作成

デプロイメントを作成します。デプロイメントは、REST API 構成のスナップショットのイメージ。作成したデプロイメントを次の、ステージと紐付ける事で API が公開されます。

main.tf

### デプロイメント
resource "aws_api_gateway_deployment" "hello_world" {
  rest_api_id = aws_api_gateway_rest_api.to_lambda_node.id

  depends_on = [
    aws_api_gateway_integration.hello_world
  ]
}

再度デプロイメントを行う場合の注意点

新しいリソースやメソッド作成、もしくは既存のリソースやメソッドの変更を terraform から反映する場合は、再度デプロイメントを作成する必要があります。

単純にリソースやメソッドをコード上で追加して反映しても、リソース上で追加されるだけでそれはデプロイされないからです。

そしてデプロイメントは、リソースやメソッドを追加・変更しても apply 時に変更対象とはなりません。(既に作成済みのため)

そのため AWS コンソールから手動でデプロイしてあげる必要があります。

リソースやメソッドの新規作成や変更を検知する、もしくは毎回の apply 時にデプロイメントの作成を強制する仕組みも作れますが、terraform 上での反映でデプロイメントを作成する場合は現在のものを削除した上で作り直す必要があるため、カスタムドメイン名を設定していない場合はエンドポイントのサブドメイン名が変更になってしまうので注意が必要です。

resource "aws_api_gateway_deployment" "hello_world" {
  .
  .
  .
  lifecycle {
    # 変更に対応するため一度削除して作り直す
    # REST API ID の変更によりエンドポイントの URI が変わるので注意
    create_before_destroy = true
  }
}

また、上記の設定を行わなずにデプロイメントの変更を apply した場合は以下のエラーが出力されます。

Error: error deleting API Gateway Deployment (xxxxx): BadRequestException: Active stages pointing to this deployment must be moved or deleted

どうしても仕組みが必要な場合以外はここは記述しないか false にして手動で API デプロイを行うのが良いと思います。(今回は特段必要としていないので lifecycle については記述しない(=false)で進めます。)

ステージ作成

ステージを作成します。ここでデプロイメントを参照して作成する事で API が公開されます。

main.tf

### ステージ
resource "aws_api_gateway_stage" "hello_world" {
  deployment_id = aws_api_gateway_deployment.hello_world.id
  rest_api_id   = aws_api_gateway_rest_api.to_lambda_node.id
  stage_name    = var.app_name
}

API Gateway 側の設定はこれで終わりです。

Lambda へのアクセスを制限する

最後に Lambda 関数(hello_world)へのアクセス許可を API Gateway に付与します。

main.tf

resource "aws_lambda_permission" "execution_hello_world_for_api_gateway" {
  statement_id  = "test-AllowExecutionFromAPIGateway"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.hello_world.function_name
  principal     = "apigateway.amazonaws.com"

  source_arn = "${aws_api_gateway_rest_api.to_lambda_node.execution_arn}/*/*"
}

source_arn を本 API のみにしたので、今回作成したエンドポイントからでしかこの Lambda 関数は実行できないようになっています。

API Gateway 構築実行

ここまで書いて terraform apply を実行すると、API Gateway が作成され、Lambda 関数にも関連付いた事が確認できます。

f:id:ro9rito:20210720120201p:plain

動作確認

一通りミニマムで作成したので、アプリケーションからエンドポイントを叩いてみます。

f:id:ro9rito:20210720120235p:plain

正常にレスポンスが返ってきました。これで API Gateway 経由で Lambda 関数を実行できました。

今回はここまでになります。作成したエンドポイントはデフォルトの URL であったり制限がかかっていなかったりするので、次回はエンドポイントの設定や制御を行っていこうと思います。

【読書メモ】「成長する企業はなぜ SSO を導入するのか」

この記事は個人ブログと同じ内容です

【読書メモ】「成長する企業はなぜ SSO を導入するのか」

---

最近チームのメンバーが誕生日で、よくバラエティ番組で流れる曲「Happy Birthday - Stevie Wonder」が頭から離れない sekitats です。

今月は個人的に認証について学ぶ月間で、本を3冊読みました。認証周りわからんことばかりだったので。

OAuth については、別記事を書いてみたのでそちらも興味があれば読んでみてください。

ratatatat30.hatenablog.jp

2冊目の Auth0 + Nuxt + Rails のデモも試した。

本記事は3冊目「成長する企業はなぜ SSO を導入するのか」の要約となります。
引用元:日本ヒューレット・パッカード株式会社 (著) . 『成長する企業はなぜSSOを導入するのか 』. 日経BP, 2017

なぜ、この本を読んだのかというと、SSO に関する本を amazon で検索したら、本書しかなかったからです。(あとはミリタリーバックパック

認証はすでに経営課題

以下のような企業における認証の課題があげられている。

  • 社員のパスワードの使い回しによってパスワード盗難リスクが高まる。企業側の危機意識が低い
  • 厳しすぎるパスワードポリシーが返って生産性を低下させる
  • 個々の業務システムの担当者は、自分が担当している業務システムだけを考えて対策を立ててしまう傾向にある → サイロ化
  • サイロ化した中で認証強化してもそれは「部分最適化」でしかない。「全体最適化」とは程遠い。

    ※ サイロ化:企業内にある部門が他部門との連携をすることなく、自らの業務の部分最適化のみを優先するようになった状態をいう。元々サイロとは穀物などを貯蔵するタンクのことだが、英語圏では「窓がなく周囲が見えない」という意味も含んでいる。

出ました。サイロ化。大規模になればなるほどサイロ化の弊害は大きくなっていく。

企業経営にまで影響を与える問題となっているということ。

パスワード認証の課題

ユーザーの本人確認を行う認証にも問題は多い。

  • 他人に知られた場合になりすましが可能
  • 安易なパスワードの場合類推や解読が容易
  • 忘れたり間違えたりしやすい
  • 複雑なパスワードは記憶が困難
  • パスワードの使い回しにより、安全性が低下

パスワード認証は、「知られない」、「推測されない」、「同じものを使い続けない」、「同じものを使わない」といった「努力」をユーザーに強いていて、その「努力」には限界がある。

パスワード認証を強化する他要素認証(ワンタイムパスワード、生体認証)も導入が難しい。

そんな、企業の課題、ユーザーの課題を SSO(シングルサインオン)が解決してくれると言うてます。

SSO 導入メリット

  • SSO とは、業務システムで個別に行っている認証を一元化し、ユーザーがいずれかのシステムを利用する際に認証を一度行えば、連携している全てのシステムが利用できるようになる。ユーザー ID,パスワード、ユーザー属性などのユーザー情報の管理や、問い合わせ対応の負荷が軽減される。
  • SSO が導入されるということは、入口が1カ所で管理されるということ。唯一の入口に防犯対策をを一本化できる。情報漏洩の防止策として SSO は役に立つ。
  • 新規に導入する業務システムだけでなく、既存の業務システムにも SSO は効果を発揮する。既存の業務システムで管理されているユーザー情報に大きな変更を加えないため、導入も用意で短期間かつ少ない労力で導入できる
  • 導入によってユーザーの利便性が向上するだけでなく、認証に関する管理の負荷も軽減される。
  • 今後登場する未知のクラウドサービスの導入と行った変化にも柔軟に対応できる
  • 各業務システム間のサイロ化の課題も、個々の業務システム担当者に大きな負担を強いることなく解決でき、IT 投資を効率化できる。

なんのことはない。一つのユーザーID・パスワードだけ管理できるようになれば問題は解決する。

SSO の 4 つの方式と特徴

方式には「リバースプロキシ方式」、「エージェント方式」、「クライアントエージェント方式」「フェデレーション」の 4 つ紹介されているが、最初の 3 つはオンプレミスでSSOを用意する方式。クラウドサービスを利用するものが「フェデレーション」。SSO = フェデレーションと捉えてしまってよい。

フェデレーションの仕組み

フェデレーションの仕組みの一つとして「SAML」や「OpenID Connect」といった。「標準規約」が用意されている。
SAML とは(Security Assertion Markup Language)の頭文字で、OASIS(Organization for the Advancement of Structured Information Standards)が定めた、クラウドサービスと企業の間で認証の連携を行う標準規格のこと。ほとんどのクラウドサービスがこの SAML に対応しており、クラウドサービスと認証の連携を行う場合は、SAML を利用することが多い。

OpenID Connect つまり JWT を使うこともできるのだろう。が、SSO では SAML を使う。

SSO(フェデレーション) はシンプル

本書では、フェデレーションの仕組みをパスポートの仕組みに例えて説明している。

パスポートは所持する本人の国籍の国で発行され、その発行には比較的厳格な本人確認、つまりユーザーの認証が求められる。 ただし、一旦パスポートが発行されれば、渡航先の国ではパスポート自体が本人確認となる。 入国の際にパスポート以外の本人確認の手続きは必要とされない。

f:id:sekilberg:20210713002050p:plain

  1. IdP(IdentityProvider)で厳格な本人確認をする
  2. IdP がアサーションSAML = パスポート)を発行
  3. アサーションがブラウザを介して SP(Service Provider = アプリケーション)に提示される
  4. アサーションの正当性と信頼した IdP による発行かどうかを SP が確認する
  5. SP がユーザーに利用を許可する

SAMLアサーションがパスポートと異なるのは、一度発行されたアサーションは特定の SP へのログインにしか使えないこと。SP 毎にアサーションを発行することが必要。(これは SAMLの仕様)


IdP による厳格な審査を通過していることとSPとの信頼関係によって成り立っているわけですね。

おまけ

いきなり、IdP(IdentityProvider)、SP(Service Provider)といった用語が出てきました。 OAuth(= 認可)の世界での登場人物は、リソースオーナー、クライアント、認可サーバー、リソースサーバーですが、OpenID Connect や SAML(= 認証)の世界になるとユーザー、SP、IdPといった用語になるところも混乱しがちなところです。(トークン→アサーションとか)

まとめ

そもそも技術書ではないし、SSO導入事例、オンプレ導入方法といった企業の経営者や情報システム担当者向けの内容だったので、OneLogin, okta などの IDaaS に関するお目当ての情報はなかった。
ただ、SSOの概要は理解できました。特にパスポートに例えた説明がわかりやすく、OAuth に比べずっとシンプルに感じました。(どう実装するかは別として。。)SSO=パスポートの仕組みということがわかっただけでも収穫アリですね。

SAML に関してはほとんど説明されていませんが、id token のような個人情報が XML 形式になっただけと捉えれば良いかと思います。

近い将来 SSO による生体認証が当たり前になって、フォームに E メール, パスワードを入力していたことが時代遅れになる未来もそう遠くないのかもしれません。

プロジェクトの振り返りに LeanCoffee を試してみた

back check 事業部開発チームの匠平@show60です。

プロジェクトの振り返りに LeanCoffee を用いてみたので、今回はこちらを振り返ってみたいと思います。

振り返りを行った経緯

back check チームではスプリントの終わりに KPT を用いた振り返りを行っていますが、今回これとは別にプロジェクト単位での振り返りを行いました。

チームではこの1ヶ月ほど新機能の開発を進めていたのですが、進行の障害となる事象が起こり始め、うまくいっていないと感じるようになりました。 何が原因で "うまくいってない" のかを洗い出すため、各自が課題と感じていることを収集し議論する場を設けることにしました。

LeanCoffee の実施方法

LeanCoffee とは

何が課題であるかを探るところから始めるため、振り返り手法には LeanCoffee を用いることにしました。

アジェンダのないミーティング方法です

参加者が集まり、アジェンダを作り、議論を始めます

Lean coffee

メリットとしては以下のことが挙げられています。

  • 広い範囲のトピックを扱うことができる
  • 事前・事後の準備が (ほぼ) 不要
  • ネクストアクションを出すこともできる

LeanCoffee の進め方

準備と進行方法は、こちらのスライドを参考に実施しました。

www.slideshare.net

振り返り会場は miro で作成し、事前に以下のような枠組みだけ用意しました。

f:id:show-hei:20210706205703j:plain

話したいトピックを黄緑色の付箋に書いて左の Ready の枠に入れていきます。出揃った付箋のなかから話す順番を決めるため、緑の●を各自2票ずつ投票します。

話すトピックをピックアップして Doing に移します。トピックについて話す時間を7分間とし議論します。

7分経ったら、このトピックの議論を続けるかを投票します。手のジェスチャーで意思表示しますが、今回 miro で行ったためカーソルアイコンを手の絵文字に乗せることで投票としました。

「議論を継続」に4票以上投票されていたら議論時間を4分追加します。これを繰り返し、4票未満になるまで議論を行っていきます。

やってみた結果どうだったか

良かったこと

ミーティング時間が延々と長引くことがない

議論が白熱したり、煮詰まるとついつい長引いてしまうことがあります。LeanCoffee では投票時間を設けてあるため、ミーティング時間を区切る機会が多く、コントロールがしやすいと思います。

広いトピックを扱うことができる

投票によって議論するトピックが決まります。選出理由に制限はなく、多くのメンバーの興味を引いたトピックが選出されます。個人で抱えている課題も場に出すことができるため、相互理解にも効果があると感じました。

良くなかったこと

トピックが大きい場合、別途切り出すなど工夫したほうがいい

LeanCoffee に議論の制限時間を設けているのは、トピックを速く処理するための仕掛けだと思っています。その特性上、取り扱う課題が大きいトピックや、前後関係の深いトピックの場合は扱いが難しいと感じました。

これらのネクストアクションまで話し合うには、ファシリテーションを含め慣れや訓練が必要そうです。

「◯回の延長が行われた場合、別のミーティングを設ける」など独自ルールを決めてもいいかもしれません。

他の手法を上回るメリットが出てこなかった

課題の収集という点ではタイムライン振り返りのほうが抜け落ちが少ないため、LeanCoffee を課題収集・理解の目的と割り切るには難しいように思います。

また課題を選出して議論するという手法は KPT も同じですが、ネクストアクションを必ず出すという点においては KPT のほうが強力です。

KPT での振り返りに慣れているチームとしては、上記で挙げている「良かったこと」を KPT で享受できており、今回試してみた限りでは大きく勝るメリットを感じられませんでした。

準備の手軽さという点は大きなメリットなので、これから振り返りを導入しようというチームにとっては選択肢としてありなのではと思います。

同じように、普段とは違う部署やメンバーとミーティングするときなんかも上手く機能するのではないかと感じました。

おまけ: 振り返り方法の選定

振り返り方法として LeanCoffee 以外にも KPT とタイムライン振り返りも検討しましたので、不採用理由もそれぞれ記述します。

結果として、今回の目的であればタイムライン振り返りを採用してもよかったなと思っていますので、ぜひ次回チャレンジしてみます。

KPT

スプリントの終わりの振り返りには KPT を用いています。 KPT はチームの課題 (Problem) に対して改善のためのネクストアクション (Try) を決めるという強いメリットを持つフレームワークです。

議論したいトピックを投票で選出することで短時間でネクストアクションを考えられる反面、選出されなかったトピックは議論されないまま、また日の目を見ることを期待してそっと過去に消えていきます。

今回の目的は各自が課題に思っていることを洗い出し、できる限り多くを議論の場に持っていくことが目的であったため KPT の採用は見送りました。

タイムライン振り返り

プロジェクトの始まりから終わりまでを時系列に沿って書き出す、データの収集を目的としたフレームワークです。 今回 LeanCoffee を試してみたかったこともあり採用を見送ったのですが、振り返り材料の収集という点では効果のある手法です。

タイムラインで収集した振り返り材料を KPT に持っていく、という組み合わせでぜひチャレンジしてみたいです。

エンジニアのインプットと読書術

この記事は 個人Qiita と同じ内容です

qiita.com/sekiyaeiji

まえおき

フルリモート時代においてエンジニアの情報インプットのスタイルも様変わりしているように感じます。

2019年までのリアル社会では、競争率の高い勉強会とか海外カンファレンスの招待枠が取れる/取れないのような価値観が、たしかに存在していた気がしますが、物理の制約を解かれたセミナーイベントにはもはや人数制限はなく国境も超え無償になり、エンジニアの情報インプットにおいては劇的に恵まれた時代に突入したと言えます。

また、オンラインが主流になることでイベント内の登壇発表部分には収録動画の配信を活用するケースも増えてきています。

私が新しい技術情報をインプットするメディアの割合は、

  • オンライン文字 > オンライン動画 > 書籍

ではありますが、まさにいまこうして文章を書くための情報インプットなどでは、よくまとまってて精査されている書籍の文章も非常に頼りになります。

オンラインイベントが自由を手に入れ、生まれ変わりつつある一方で、日本の活字媒体の事情も変化しつつあるようです。

活字メディアの動向

新型コロナ影響下の書籍の動向

2020年、日本のコミックの売上が、過去最高記録を打ち出したのをご存知でしょうか。

25年ぶりのコミック売上記録更新という奇跡的な回復には、新型コロナの巣ごもり需要が大きく影響しているそうです。

同様に、新書、ビジネス書、専門書(技術書はこれに含まれる)の売上も前年比でプラスに転じていることから、巣ごもりでできた時間を自己研鑽に投じる意識の現れかもしれません。

自費メディアの浸透

活字メディアの動向で気になっているもう1つのトピックは、技術書典技書博のような自費出版カルチャーの浸透です。

技術書典は、3年前にはすでに盛り上がっていたように感じますが、新型コロナ影響によりリアルイベント中止の代替手段としてオンライン販売を全面展開してから、結果的により身近になり、より多くの読者が参加・購入できるようになりました。

盛り上がりに比例して出品ラインナップの玉石混交感も増しており w 書籍の選択には注意が必要ですが、良書を見つけると、ネット記事と本格的な技術書の中間ぐらいの、知りたいことをピンポイントで知るのにちょうどいいボリュームの良書に出会うことができます。

活字メディアによるインプット

さて、そんな私の活字メディアによるインプット方法ですが、まず、できれば電子書籍よりもリアル本を利用します。

学びを結果に変えるアウトプット大全/樺沢紫苑』や『大人のための読書の全技術/齋藤 孝』で共通する内容で、書籍に線を書き込むという手の運動が脳を刺激し、読書時の記憶を促進するという趣旨の記載があります。

書き込んだり折り目をつけたりメモしたりしながら、本を自分色に染めながら読む習慣のために、紙の本がある場合はなるべく入手します。

また、とくに印象に残したい書籍についてはなるべく読書記録を残すようにしています。

これも『学びを結果に変えるアウトプット大全/樺沢紫苑』にある、自己成長の量はインプットの量ではなくアウトプットの量で決まるという提言に従い励行しています。

インプット速度を上げる

さて、そんな私が昨今課題に感じていたのが、インプット速度の向上です。

限られた時間により多くの情報を扱いたくなったときに、ヒントになる内容が『大人のための読書の全技術/齋藤 孝』の中で触れられていたので、具体的にいくつかの方法を引用してご紹介します。

ちなみに、本書における"速読"とは、◯◯協会が提唱する速読トレーニングみたいな内容ではなく、社会人が書籍の内容を、限られた時間内で素早く把握するための具体的な方法について説明されています。

読書速度を上げるテクニック

大人のための読書の全技術/齋藤 孝』の「第2章 : 読書の量を増やす − 速読の全技術」の中で紹介されている、読書の速度と量を上げるテクニックが実施しやすく役に立ったので、以下の通り7つ、引用してみます。

1.目的と締切を同時に設定する

  • 目次を読む
    • 概要を知り、大事な箇所をはっきりさせる
    • どこをしっかり読めばいいかをあらかじめ把握する
  • 本をさばく
    • 1冊につき20分ぐらいかけて本の内容を人に話せるぐらいまで把握する作業
      • 次に開いたときにすぐ読める
    • 買ったその日に、その本に一目惚れしたテンションのまま一気に中身を把握しておく
    • タイトル、帯、カバー袖、目次、小見出しで全体の趣旨をつかむ
    • 練習すれば新書1冊5分も可能

2.逆算読書法

  • 結論から読み始める
  • 内容を要約できればいい
    • 大事なところから読めばいい

3.二割読書法

  • 全体の二割を読んで全体をつかむ
  • 覚える対象になりそうな箇所だけ精読する
  • 目次から全体把握が大切

4.書店で鍛える

  • 購入に値するか、真剣に見極めるトレーニン

5.サーチライト方式

  • 読む前に大事なキーワード5〜6個を決めておく
  • そのキーワードを見つけたら次々とボールペンで丸をつける
  • 大事だと思う箇所のページの上端を折る
  • まあまあ大事な箇所はページの下端を折る

6.同時並行読書術

  • 複数冊を並行して読めると読書量が増やせる
  • 1冊ごとの読破に重きを置かない
  • そのときの気分によって手にとった本の続きから読む

7.TPOに応じて読む

  • TPOに応じて読み分ける
  • 読みかけの本を自宅のあちこちに散らばらせておく
  • 暇を見ては本を読む習慣が身につく

実践する際の注意点

以上は、各テクニックのポイントを簡潔に箇条書きで引用しましたので、より詳細を知りたい方はぜひ書籍を購入してください。

これらの読み方のテクニックはもちろん、ビジネス書や専門書の読み方として紹介しておりまして、小説の読み方として適さないことは言うまでもありません。

私は上記をビジネス書や技術書の内容を把握する場合に利用していますが、たしかに始まりから終わりまで精読するよりは遥かに時短になり、一度トライしたら辞められない読書法になってしまいました。

最初は筆者に対する罪悪感のようなものを感じなくもなかったのですが、実用書は活用することが目的の書物と割り切って一度試してみると、筆者の言いたいことをよりよく理解しようと努力している、むしろ良いことをしてるかも、という感覚にもなれるかもしれません。

まとめ

紙の本を使い倒すことによる効率的な情報インプットについて、情報を集めてご紹介してみました。

技術書もそうですが、変化に対応し、さらなる変化を求める市場において、ビジネスやテクノロジーに関するさまざまなアイデアが雨後の筍のようにアウトプットされる現在、情報を効率よく取り込むテクニックは、備えていて損はなさそうです。

積ん読(つんどく)本とのつき合い方が変わるかもしれません。