🪬

「世界一流エンジニアの思考法」要約

2023/12/22に公開

エンジニア

生産性

tech

この記事はミライトデザイン Advent Calendar 2023 の 22 日目の記事です。

はじめに

最近流行った牛尾剛さん著書の「世界一流のエンジニアの思考法」という本を読んだので、メモがてら要約としてまとめました。

自分が感じていたことや思っていたことが言語化されていると感じたのと同時に、新たな考え方なども学べてとても参考になりました。

https://amzn.to/48jvhED

第1章世界一流エンジニアは何が違うのだろう？ - 生産性の高さの秘密

試行錯誤をするのではなく、事実をもとに仮説を立てて検証する

❌ エラー発生 → エラーを調べて試す
- 思いつきで色々なパターンを試行錯誤すると時間がかかり生産性が落ちる
✅ エラー発生 → エラーを見て仮説を立てる → 仮説を検証
- 手当たり次第に可能性を試すコストを減らす

理解することに時間をかける

頭のいい人の理解が早く見えるのは、時間をかけて基礎を積み上げているため、すでに理解していることに関しては頭に入っているから
- 頭が良い人でも理解することに時間はかかるため、時間を掛けて基礎を積み上げている
「理解する」というのは以下 3 つの要素がある
- 人に説明できること
- 即座に実践できること
- 応用可能なこと
プログラミングにおいて、コードは読むだけではなくその意図と背後のアーキテクチャを理解する
「理解は時間がかかるもの」として、急がずに徹底的に理解を深めることを習慣とする

メンタルモデルを作る

メンタルモデルとは、自分の心の中のイメージや理論のようなもの = 脳内イメージ
頭の中で考えたり整理したりしてイメージを作り、問題解決のプロセスを高速化させる
脳内で仮説や動作などをシミュレーションする

1 つのことに時間がかかるようであれば質問や相談をして無駄を無くす

知らないことや分からないことで時間をかけるようだったら、質問や相談をして寝かしておき、その間に他の仕事をやっておくほうが生産性が高い
既存システムがある場合は、あれこれ調べる前に知っている人に頼ろう

「偉大な習慣を身につけたプログラマ」になる

「できる」エンジニアになるためには思考する習慣を身につける
- 特殊なスキルではなく、理解するために時間をかけて基礎を身につける
- どんな人も最初は理解するのに時間はかかる

第2章アメリカで見つけたマインドセット - 日本にいるときには気づかなかったこと

「Be Lazy」というマインドセットを持とう

少ない時間で価値を最大化させる
- "怠惰であれ"
- "より最小の労力で楽をしよう"
- 優先順位をつけるのではなく、より高い優先度のものだけをピックアップして取り組む
- 2-8の法則（パレートの法則）によると、20% の仕事が 80% の価値を生み出すので、全てのことをやらなくても 20% の仕事をしっかり取り組めば価値は生み出せる
そもそもやることを減らす
- 一番重要な 1 つのことに集中して、ほかは何もしない
- 時間を固定化させて限られた時間の中で価値を最大化する
- 持ち帰りはせずにその場で解決する
- 不要なことは減らす

リスク・失敗・不確実性を受け入れよう

Fail Fast を意識する
- 「挑戦 → 失敗 → フィードバック → 修正」のサイクルが早いほど価値が高くなる
- リスクや失敗を受け入れて挑戦のハードルを下げよう
- 失敗を恐れて検討ばかりするのではなく、検証してフィードバックを得よう
変更に柔軟に対応するために、不確実性は受け入れよう
- QCD はトレードオフなので、優先度を考えて柔軟に対応する
- 納期を固定するのであれば品質を下げたりコストを上げたりスコープを変えたりする
- 「楽に達成できる」計画で仕事をする
  - 「なるはや」や「来週までに」などのオーダーは納期を割る可能性が高いうえに、依頼先にも負荷がかかる
  - 無理な計画は断ることもできるようにする
- 計画の変更は「悪」ではない
  - 現実をみて、フィードバックを受けて納期や仕様が変わっていくのはむしろ「善」

「結果を出す」から「バリューを出す」へ

日本式の「結果を出す」とインターナショナルチームの「バリューを出す」は、似ているようで求められることが違う
例えば目標を定め、途中で未知の問題が起きた場合
- 「結果を出す」は、残業や徹夜などをして必死に達成しようとする
  - 目標達成できないと「失敗」という烙印を押されて、次のチャレンジがしづらくなる
  - 一度目標が定められると、予測が誤っていても必ずやりきらないといけないので、全員にプレッシャーがかかる
- 「バリューを出す」は、もっとも優先度の高い最初の 1 ステップのみを目指すように方向転換する
  - できないものはできないと判断する
  - 「KPI は定時で無理なく楽に達成できる程度のものであるべき」という大前提がある
  - 目標はあくまでも目標であるため「やってみて実際どうだったか？改善ポイントやベストプラクティスは？」などに価値があるとしている
取り組みの中で得られた学びこそがバリューであり、会社にとっても価値となる

第3章脳に余裕を生む情報整理・記憶術 - ガチで才能のある同僚たちの極意

コードリーディングのコツは極力コードを読まないこと

コードは端から端まで読むのではなく、実装はちゃんと動くものとし、インターフェースや構造を理解する
- メソッドやクラス、インターフェースの役割やパラメータをしっかり理解する
- 読むことを減らし脳みその負荷を減らすことで、大事な部分にリソースを使う
何もググらずに即実装できるレベルのものを増やす
- 例えば基礎的なループ処理などは、処理内容をすぐに把握することができるので他のもっと重要な箇所に目を配れるようになる
- ググらずに把握できるものを他のコーディングにも広げていけば生産性が上がる

アウトカム（成果）を急がない

コンサルのように具体的なサービスを提供する際のアウトカムではなく、エンジニアは細かい技術の積み重ねが重要
- アウトカムに集中すると短期的には良くても、中長期の生産性が上がらない
例えば既存のコードのコピペや AI にコードを書いてもらうことで、その時にアウトカムを出すことはできても、中身を理解していなければその後何度も調べることになるし応用もできない
- 自分が知らないことや新しいことのキャッチアップができないため「成長していない」ということになる
- 「何かを身につける」というのは即席ではなく、地味な積み重ねによって身につく
基本が身についている人はノウハウがあるし重要なポイントもわかっているので、的確な思考ができ長期的に見れば生産性が高い

マルチタスクは生産性が最低なのでやらない

マルチタスクは生産性が下がるので、手につけている仕事は 1 つだけにし、その仕事だけに集中する
- 1 つのタスクを中断する場合は、次に再開するときにすぐにその状態に戻れるように記録や整理をしておく
- タスクを終えたら、ブラウザのタブなど不要な残骸は気移りしないように消しておく

1 日 4 時間は自分だけの時間を確保する

チャットやメール、質問対応やレビューなどがあると、自分のタスクの時間がなくなっていくので、1 日 4 時間は自分だけの時間とする
- メールやチャットなどは一切閉じて、自分の作業だけをする

記憶力が悪いのは「理解していない」が原因

記憶力がいい人は全てを覚えているわけではなく、メンタルモデルを作って人に説明している
- 記憶は断片的なので、脳内で思い出してシミュレーションをしている
- 説明可能になるということは構造を整理して把握して脳内メモリに乗せているので、理解していないと伝えられない
過去に自分がやったからといって理解しているとは限らない

人に説明する訓練で「書く」ことをしてみる

ブログなどで人に説明できるレベルで記述するということは、自分の理解を深めて記憶に残すということに有効な手段となる
記録するときはただ書くだけではなく、アウトプットを意識した内容で書く

頭の中のみで整理する

議事録はその場でそのまま書かず、記憶・整理してから要点を書く
- その場で記憶するつもりで話を聞くと、理解しないと要点は抑えられないので、明確ではないことはすぐ確認するようになる
話を聞くときは人に説明することを想定して、頭の中で整理しながら聞く
- 後で人に説明するという前提で話を聞くと、集中力や記憶力が向上する
- 理解できていないと人に説明するのは難しいので、聞いているときに理解できなかったら確認する
文章を書くときは書いてから考えるのではなく、考えて整理してから文章に書く

理解・記憶・反復という黄金則

物事をできるようになるには「理解」「記憶」「反復」の要素が外せない
- 時間をかけて基本と構造を「理解」しないとコントロールすることができない
- 頭の中で整理された状態で「記憶」しないと、何回も思い出す必要や調べ直す必要があるので、時間ばかりかかって確信が持てなくなる
- 整理して頭にはいったら、それをいつでも取り出せるよう「反復」に時間をかける
脳の負荷を減らすことで「理解」→「記憶」→「反復」の好循環を生む

第4章コミュニケーションの極意 - 伝え方・聞き方・ディスカッション

「情報量を減らす」大切さ

たくさん情報があっても消化できないし要点が分かりづらくなるので、情報量を減らして脳の負荷を減らす
付加的な情報は聞かれたときに答える

準備は効く

「準備」「持ち帰り」が習慣になると生産性が落ちるので、基本的にはその場で解決することが望ましいが、持ち帰ってしっかりとアイデアを練ったり、理解してもらいやすいように準備をしてからプレゼンするなども悪いことではない

相手が求めている情報を意識する

「相手が本当に欲しい情報は何か？」を普段から意識していくことで生産性を向上させる鍵となる
メモを取るときなどは、「自分用の自分がわかるためのメモ」ではなく、見る人が欲しい情報として整理する
人に伝える・見せることを前提とすると、何か聞かれた際や読む際の工数削減となる

コードを「読み物」として扱う

「コードを書く」意識でプログラミングをするのではなく、読んだ人がどう感じるかを意識してコードを「読み物」としてプログラミングする
プルリクエストでのコメントのやり取りを減らすためには、プルリクエストも読み物として読み手がわかりやすいように意識する
- レビューをする人はコードを書いた人の前提やコンテキストが分からなかったり知らなかったりしたときに疑問が起こりコメントをするので、読み手のことを考えたコードや補足コメントをすることでやり取りを減らす

ミスコミニュケーションのサイン

リモートワークが増えて直接コミュニケーションを取ることが減ったため、お互いの認識の齟齬が発生しそうなタイミングで、オフラインや直接会話する機会を設ける
- プログラミングの仕事で時間がかかるのはコードを書いているときではなく、人とのコミュニケーションによって作業が停止される場面なので、円滑にコミュニケーションが取れると生産性が上がる

クイックコールをする

リモートワークはオフラインと違ってコミニュケーションコストが発生し生産性は下がるので、クイックコールを頻繁に使う
- クイックコールとは予定されていないビデオ通話のこと
- プログラミングの仕事で時間がかかるのはコードを書くときではなく、コミニュケーションを取る時と先述したが、クイックコールを使用することで言葉や画面共有によって円滑なやり取りを行う
チャットより音声のほうが情報量が多く、インタラクティブ性もあり、フィードバックが早い
自分で調べてから聞きなさいと言われることもあり、どの程度のことを聞いていいか疑問に思うかもしれないが、原則として自分にその分野の「メンタルモデル」「コンテキスト」がなければすぐにエキスパートに聞いたほうが良い
- 相手が忙しいかは考える必要が無い。スルーされたら忙しいんだろうなと思えばいいい
- クイックコールが難しいなら時間を決めてお願いすればいい
- ただし、相手が労力を使わずに回答できるかは配慮する必要がある

クイックコールされる側も良いことがある

ちょっとした手助けでプロジェクト全体がスムーズに進むので、結果的に自分の仕事も楽になる
聞かれたことがわからない場合は自分自身の学びの機会にもなる

気軽に聞ける空気の大切さ

「そんなこと聞く？知らないの？今話したばかりだよ」などと思うことでも、気軽に聞ける環境にすることで、調べるよりも聞いたほうが圧倒的に早いこともあるため、組織全体の効率が上がる
「気軽に聞ける環境」と「気軽に断れる空気」をセットにする
- 聞かれてわからないことは「わからない」と気軽に断ることで、聞く方も聞かれる方も気が楽になる

ディスカッションで鍛えられること

ディスカッションはお互いが持っている意見を交換して、知識や考えを深めることなので、知らないことは恥じないで進んで聞くという精神をもつ
- 「間違えたら恥ずかしい」という感覚は一切捨てる
- 知らないものは知らない、間違えてるものは理解が浅いだけなので、それを恥とは思ってはいけない
その場でフィードバックがあるディスカッションは、短い時間で相当高い知識と理解を深めることができる
ディスカッションは「どちらかが正しいか」は関係なく、自分の知識や考えを深めることなので、初心者こそやったほうが良い
ディスカッションはどちらかが正しい・間違えているなどを決めるのではなく、相手の意見を理解する
- 異なる視点からの意見を受け入れて、自分の考えや知識を深めていく
- 相手の意見は否定せずに、自分の意見として伝える
言いたいことを伝え、相手の言わんとすることを理解する「会話力」が育つ

第5章生産性を高めるチームビルディング - 「サーバントリーダーシップ」「自己組織型チーム」へ

主流になりつつある「サーバントリーダーシップ」と呼ばれるマネジメント

「サーバントリーダーシップ」
- リーダーはビジョンと KPI を示し、実際にどの様に動くかはチームが主体的に考えて意思決定していく
「コマンドアンドコントロール」
- リーダーが部下に指示を出し、部下の状況を把握・確認して管理していく
- 従来型のスタイルで、いわゆる「マイクロマネジメント」のこと
日本企業と比べると「サーバントリーダーシップ」のスタイルが増えている
- 「マイクロマネジメント」はオールドファッションと呼ばれている

自己組織チーム/フィーチャーチーム

アジャイル以降のソフトウェア開発現場では、「チーム」が自ら考えて自分で意思決定する「自己組織チーム」というスタイルが主流になっている
自己組織チームは「生産性が高い」「チームのエンゲージメント（満足度）高い」「よりよいソリューションが選択されやすい」といった特徴がある
- 「コマンドアンドコントロール」型では、リーダーの承認、説得、合議、根回しなどの時間がかかるが、自己組織チームではチームを信頼してタスクを与えているので仕事が圧倒的に早く生産性が高い
- やらされる仕事よりも自分が責任を持って楽しいと思える仕事をすることで生産性も高くなる
- 技術の最前線を一番把握しているのはコーディングしているメンバーで、何年も前にプログラマを引退したマネージャでは鼻が利かないので、現場のメンバーに選択してもらうほうが一番質が良くて、より良いソリューションが選択されやすい
  - もちろんリーダーでもキャッチアップしていたりするため、必ず現場で決めるということではない
インターナショナルな職場では、自分の考えや人生に責任を持つのが大人とされている
- 日本では、リーダーが色々と言えば言うほどチームが指示待ち集団となってしまい、組織で我慢できるのが大人とされてしまう

開発者それぞれが責任を持って設計し実装する

各チームは 10 人程度で、それぞれの機能を開発するのは各個人に任される
- マネージャーから渡されるタスクは基本的にふわっとしているため、開発者が仕様を自分で明確にし、デザイン・実装をする

「仕事を楽しんでいるか？」を確認する文化

「仕事は楽しむもの」というカルチャーがあり、それを重要視している
- そういった環境を求める人はどんどん増えていくので採用できる人材に差が出てくる

ボスの役割はサポートすること

ゴール設定などは一緒にやってくれて、困っていることのアドバイスなどもくれるが、「あれをしろ、これをしろ」といった細かい指示はない
困っていたら人を繋げたり、他の人の協力を要請したり、技術的な手助けをしてくれたり、常に「仕事の遂行を助けてくれるサポーター」という姿勢
エンジニアたちの扱いが個人事業主に近い

納期もなくマネージャーも急かさない

急いでいい加減なものをリリースするよりも、自分が自身を持てるものをリリースする
- 「不確実性を受け入れる」
- 世界規模のクラウドのプラットフォームでは、1 週間でできると思ったことが技術的な問題点が発覚して 2 ヶ月ぐらいかかってしまったということもざらにある
- 後で問題になる方が大変
プログラマがきちんと理解して実装できるようになれば、次からは開発が速くなるので「未来への投資」としている
納期はないが、今後のやるべきことリストと大きな予定はある
- 戦略と今期はこれをやろうという計画があり、粗い粒度の要素を整理して開発者にアサインする
マネージャーは一度仕事をプログラマに割り振ったら、あとは信頼するしか無いという考え方がある

自己組織チームをいかに導入するか

ソフトウェアチームだけを変えても自己組織チームは機能しない
- マネジメントが「コマンドアンドコントロール」型であれば、チームを管理しようとしてしまう
- 少なくともソフトウェア開発においては、全社的に自己組織型へとシフトしていかないと機能しない
トップ層への実践
- 導入によって、リードタイム短縮などの目に見える効果を提示し、社の方針としての承諾を取り付ける
- KPI 的には新技術の導入や、様々な変革をするミッションがあるので前向きになりやすい
ミドル層への実践
- 現場マネージャーの不安を汲み取って、会社としての支援体制を作る
  - プロジェクトやサービスごとに数字を持っているので、別の方法で新しいことを始めるのに抵抗がある
- 自己組織型になると管理の負担が大幅に減って、ビジョンや戦略や改善など本質的な部分に注力できるメリットを理解してもらう
チームメンバーへの実践
- 指示待ちからの脱却が課題となるため、「ファシリテーター」を設けて、メンバーたちの行動を促進する質問をし、本人たちに決定させる

チームの上下を無くす

上下関係を感じるとチーム内で指示待ちが発生してしまうため、スキルや経験、年齢に関係なく、全員が同じ責任を持っているフラットな「仲間」として振る舞う
ボスでも仕事を依頼するときは常にお願いモードで対応する

失敗に寛容な職場がチャレンジ精神を生む

チャレンジするのには恐怖感があるが、繰り返すことで実力も向上していくため、誰かが失敗しても寛容であるチームの空気感が重要となっていく
失敗してもポジティブな態度でいるほうが心地が良い

「Be Lazy」を推奨し、休暇を尊重する

「Be Lazy」を推奨し、より少ない工数で多くのバリューを出すことに高い価値を見出す
- ただたくさん仕事をするのではなく、作業量を減らして、インパクトのあるものに集中する
日本では仕事が終わっていないと休暇中でも仕事をしないといけないみたいなプレッシャーがあるが、インターナショナルチームでは仕事が途中だろうが休暇を取ることが尊重される

チームにパワーをもたせることの価値

日本以外の国は「開発者」と「運用者」の人が技術や方法論選定のパワーを持っているが、日本ではマネージャが決めて現場に決定権が無い
新技術導入を推し進めるのに必要なのはそこに鼻の効かない管理職の承認ではなく、現場を信頼して任せることで、各技術者がパワーを持って意思決定していく組織である
「できない人をなんとか管理する」という発想は捨て、大人扱いして「できる人」にするほうが効率が良い

第6章仕事と人生の質を高める生活習慣術 - 「タイムボックス」制から身体づくりまで

生産性を上げたければ定時上がりが効率がいい

生産性を上げる秘訣は「学習」
- 仕事を遅くまでやっていても短期的なアウトプットは上がってように見えて、根本的な生産性は上がらない
仕事は定時で切り上げて、その後に自分のやりたいトピックを勉強したり試したりする
- 同じプログラミングでも、仕事と切り離したものはリラックスしてできる

「タイムボックス」制で、学習の時間を確保する

作業の節目は「アウトカム」重視ではなく、「タイムボックス」制で何時までやるを決める
- 切りの良いところまでやろうとすると、寝る直前まで時間がかかってしまうこともあるし、集中力が長続きしない
時間が来て強制終了にすると、ランニングや読書、学習や自分の趣味に時間を使えるようになる
日々忙しくても決まった時間に仕事は終えるのでストレスもあまりたまらない
予定はあくまでも予定なので、「完了」に焦点を当てずに、区切られた時間で集中する

「脳の酷使をやめる」3 つのコツ

タイムボックス制で仕事の効率が高まったのは、「脳の酷使をやめた」ことである
- デスクワークにおいて生産性を阻む大きな要因は「脳の疲れ」
生活習慣として 3 つの対策を取り組むとよい
- 1. 瞑想
  - 瞑想によって深く脳を休ませることができる
- 1. ディスプレイから意識的に離れる時間をつくる
  - ディスプレイからの光は目の疲れや頭痛や体内時計の変調の原因になったりするので、なるべく就寝の 2 時間前からはディスプレイを遠ざけておくことが眠りの深さにつながる
- 1. しっかり睡眠をとる
  - 睡眠不足は脳の集中力、処理能力、記憶力に悪影響を与えるため、脳を十分に休ませることは、生産性を上げるための絶対条件

違うことをするのがリフレッシュに

脳を休めたかったら全く違うことをするのも効果的
飽きる頃に違うことをやったほうがリフレッシュになるし、視野を広げる機会にもなる

掃除で「人生をコントロールする感覚」を取り戻す

キッチンに置きっぱなしの食器や食材、洗濯だけして放置される洗濯物が増えていくのは、タスクを「完了」していないからである
- 食事は食べた後に食器を洗ってキッチンを掃除してから「完了」となる
- 洗濯は洗濯後に服を畳んで収納してから「完了」となる
何かをしたら「完了」するまでやるように意識することで、仕事にもコントロールする感覚が生まれる

整理の技術

成果を出す人は、あらゆる点で整理が行き届いている
- 「身の回りの整理」 → 「情報の整理」 → 「頭の中の整理」の流れで整理力を高める
パソコンの整理は「必要なものを簡単に取り出せるか」を考える
- 自分がどこに情報を置いたかを記憶する癖をつける
書いて整理する
- 整理してアウトプットすることで記憶の定着にもつながる

エネルギー不足の解消

気力のなさや体力のなさ、イライラや不眠のような更年期特有の症状は運動とテストステロン（男性ホルモン）を増やすことで解消する
- 運動やトレーニングで物理的なエネルギー量を増やす
- 肉類や玉ねぎ、加熱されたにんにくなどテストステロンを増やす効果のあるものを食べると良い
女性の場合でも「筋肉」が増えるような運動と食事を生活に取り入れるのが良い

第7章ＡＩ時代をどう生き残るか？ - 変化に即応する力と脱「批判文化」のすすめ

AI に食われない職業

しばらくは創造的な仕事や、芸術などの分野が食われないのではないか
- 身体的なものや対人的なもの
- 例えば、人間が料理し給仕してくれるレストランや、個性がでる音楽など
エンジニアの分野は完璧であればあるほど良いので、人間は徐々に追い抜かれていく
- 将来的には自分が得意なコンテキストで、 AI とどうやって共存していけるかを見つけ出す

ChatGPT がやってきたときアメリカで起こっていたこと

世間は好意的な反応と、情報流出リスクがあるし人間の仕事を奪いかねないので禁止すべきという反応あった
マイクロソフトでは AI テクノロジーを使って楽をし、それを自分の開発するサービスに統合して活かそうとエンジョイしている
- 漠然と怖がったり嫌ったりして、「禁止」や「排除」をしてしまうとイノベーションが生まれるチャンスは消えてしまう
AI に頼る分野や範囲は今後もどんどん増えていくだろうから、日々使って少しずつ経験を積んでいくと良い

AI 時代には「専門性」こそが強みとなる

AI は既存のデータをもとに学習していくので、誰もがやったことのないものに取り組んでいる専門家は、 AI が取って代わることは原理的にありえない
AI が高度なソフトウェアを作り出すようになったとしても、用途や目的に応じた学習のための AI モデル（データ解析の方法）は人が作る必要がある
- 最終的に AI を統合するのは人間が行うので、少なくともソフトウェアエンジニアの専門性は必要となる
- AI もコンピュータの上で動くので、ソフトウェアエンジニアリングの一部門となる
インテグレーションができる専門性のあるソフトウェアエンジニア、データサイエンスの専門家が今後は取り合いになる

日米の文化の違い

アメリカではスピード重視ではなく、「専門性を高める」という蓄積に価値が置かれる
新しいテクノロジーが出た時のスピード感は日本のほうが早いが、日本の「批判文化」が致命的な足かせとなっている
- SNS での批判や揚げ足取りが開発者の新しいことへのチャレンジ精神を奪っている
アメリカには「コントリビュート（貢献）」する文化があり、自分がどういう貢献ができるかをベースに考える
- バグや不具合が起きないことはないので、失敗しても開発者の心が砕けないような文化となっている
- フィードバックは感謝などのポジティブな言葉ばかりで、どう改善すればよいかのディスカッションが行われる

日本再生への道すじ

日本の産業はハードウェアには強かったが、ソフトウェアが弱かった
- ソフトウェアを軽視していた
大手の企業では「プログラミング」を低レベルの人がやることとみなして外注し始めたことで、平均レベルでいうとアメリカやヨーロッパと比べて低くなってしまった
今後はソフトウェアの技術者を専門家として大切に扱い、技術者が働きやすい職場環境へと刷新していくとよい

自分の人生は自分でコントロールする

どうやったら人生が幸せになるかを主体的に考えて、仕事の仕方を選択する
- 我慢はせずに、自分で選択して実行する

まとめ

日本企業では難しそうなところもあると思いつつ、そういったところでアメリカに一歩先を行かれているのかなとも思ったり。

自分の考えてたこと・思ってたことのいくつかが整理されました。

気になる人は是非、実際に読んでみてください。