思考の向き

日常的におこなっている思考や想像(妄想)の種類について書く。
ひとつめ、過去の体験や出来事について、なんで? なんでなんでなんで? を繰り返す類のもの。振り返りはここに含まれる。
次に、自分と離れたものごとについて思考徘徊する。時事ニュースや他者の言動や読み聞きしたことに対して脳内議論をして自分を確認する。他には、自分の現状についてああでもないこうでもないと思考する。ぐるぐる考えたり悩んだりする。
最後に、未来についてのあらぬ妄想。自由である。

せっかくなら、未来や前に向かう思考や想像を増やしたい。思考や想像は、自分やなにかを知ろうとしたりわかることに繋がる。
この文章を書きながら「明日」「楽しそうなこと」2点にフォーカスして試したところ、明日の楽しそうな自分について調べたり知ろうとすることがわかった。

  • 例 : 明日の楽しそうな自分 = 明日おいしいものをたべる自分
    • 明日おいしいものがたべたい > なにがたべたい >どこの > 場所やお店を調べ始める > たべたいものとお店を決めはじめる > 自分が明日になにをたべたいのかわかる > たべる

自分がなりたいこと、ありたい姿、ほしいもの、いきたい場所、会いたいひと、やりたいこと、習得したいわざ等々、未来の自分をたくさん思考想像する。するとたくさんのことが知りたくなる。知った中のいくつかは実現に向けて選択をスタートすることがあるだろう。なんだか思考したり想像すること自体が楽しくなってきませんか。かつて元々上司が「イメージしないことは実現しませんよ」と話をされていた。そしてアインシュタインの言葉を思いだす。

  • Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world.
  • The more I learn, the more I realize I don’t know. The more I realize I don’t know, the more I want to learn.

思考想像と知識が正の循環を繰り返すうちに、いつしかこれまでの自分が知り得なかった領域の扉を開けているかもしれない。異なる価値観や今まで知らなかったけど好きになりそうなこと、未知の世界を知ったり理解できるようになるかもしれない。
目の前だけじゃなく、すこし遠くの自分に向けて目を凝らしていこう。インターネットの恩恵に与り情報が簡単に得られ、なんとなく世界が狭く感じたりわかったような気になってしまう。そんな今だからこそ、見えない未来や向こう側の領域について意識的に思考し想像したい。

本を読む会 SRE サイトリライアビリティエンジニアリング #5 ~トイルの撲滅

読み会5章「トイルの撲滅」予習ログです。

#5 トイルの撲滅

Eliminating Toil

  • "If a human operator needs to touch your system during normal operations, you have a bug. The definition of normal changes as your systems grow."

読み解きたいこと

  • トイルとはなにを指すのか
  • Google はどうしてこの内容をあえて章として取り上げるのか
  • トイルとは具体的にどういった作業を指すのか
    • SREに聞いてみたい

読書メモ

5.1 トイルの定義

  • トイル
    • プロダクションサービスを動作させるエンジニアリングに関係する作業
    • 自動化が可能で、戦術的で長期的な価値がなく、作業量がサービス成長に比例
  • オーバーヘッド
    • エンジニアリング以外の作業。プロダクションサービスの稼働に直接関係しない管理上のお仕事
      • e.g. 定例チームMTG, 人事評価作業、目標設定や選考課題考案や事前MTGなど
手作業である
  • e.g. 何らかのタスクを自動化するためのスクリプトを手動で実行するようなこと。確認や実作業にひとの時間を使うようなこと
繰り返される
  • e.g. 3回以上同じ作業を繰り返し繰り返し行うようなこと。もたらされる成果やアウトプットは同じもの
    • 1~2回程度であればトイルと言わない。また新しい気づきや問題解決や解決策に至る作業はトイルと言わない
自動化できる
  • マシンが人と同じように行えるタスク、またそのタスクの必要性をなくすことができる仕組みが作れるようなら、その作業はトイル
    • ひとの判断を要する作業はトイルではない 。ならば選考対応はトイルじゃない。オーバーヘッド
戦術的である
  • 戦略や予測の基づくものではなく、解決にいたるフローの中の作業でもなく、割り込みでスタートして問題発生時の対応作業としておこなわれるもの
    • ゼロにはできないが最小限にはしたい
    • 別のサービスで同じ障害がなんども発生してしまうようなこと?
長期的な価値を持たない
  • タスクを終えた後も、サービスが成長・前進しない
    • 古いコードや設定に踏み込んで整理改善し、サービスにとって恒久的な改善が加えられればトイルではない
サービスの成長に対して O(n) である
  • サービスの成長(トラフィック量、ユーザ数)とともに作業量も増加してしまうようなタスクはトイル
  • 理想的な管理と設計がされたサービスは、そのリソースを追加する作業のみで、他の追加作業なしに1桁程度は成長ができる

5.2 トイルは少ない方がよい理由

この節は Googleの信念を感じる。

  • トイルの作業性質は、SREの戦略・存在意義に反するから
  • SREにとってエンジニアリングとは、サービスをスケールさせる作業であるから

そのためにやっていること

  • SREの目標に、トイルに使う作業は作業時間全体の50%以内に抑えることを掲げる
    • 各SREの作業時間の最低50%は、将来的なトイルの削減またはプロダクト成長に寄与するシステム開発に充てる
    • そういった機能開発は、信頼性、パフォーマンス、利用率の改善目的でおこなうことが普通で、この作業はしばしばトイルを削減してくれる副次効果がある
  • SREの採用時に、いわゆる運用作業チームではないことを明言し約束する
    • そして運用作業チームにならないよう組織チーム全体で取り組んでいく
Googleでのトイルの計算
  • トイルのなかで最も多い作業は割り込み。緊急ではないサービスに関するメッセージやメール、notify
  • その次にオンコール(障害対応)、次にリリースやプッシュ
  • SREのトイルが多すぎる場合
    • 特定のSREのトイルが多すぎる場合は、マネージャがそれぞれに負荷分散できていないことを示す

5.3 エンジニアリングである条件

エンジニアリングとはなにか

  • 人間の判断を必要として新しいものを作ること
  • サービスに恒久的な改善を加え、戦略により導かれるもの
    • クリエイティブでイノベーティブであり、問題や課題を解決するために設計主導のアプローチを取る
  • 汎用的である/横展開が可能である

以下はSREの活動。SREがトイルに割く時間が50%を大きく上回る場合は、何が問題なのかをしっかりと確認しないといけない。

ソフトウェアエンジニアリング
  • SREがコードを書き、新しいツールやフレームワーク、自動化スクリプトを作り出すこと
  • サービスの信頼性やスケーラビリティにダイレクトに働きかけ、サービスに恒久的な改善をもたらすエンジニアリング
システムエンジニアリング
  • プロダクトのシステム設定、設定変更、システムのドキュメンテーションの作成
  • 一度の作業で改善効果が持続できるような作業
    • e.g. モニタリングのセットアップと更新、ロードバランシングの設定、サーバ設定、OSのパラメータチューニング、開発チームへのアーキテクチャ、設計、プロダクト環境に対するコンサルティング
トイル

上述の通り

オーバーヘッド

上述の通り

5.4 トイルは常に悪なのか?

  • 少量であれば悪ではない、中にはトイルを楽しめるSREもいる
    • いち早く達成感をもたらしてくれる類のタスクでもある
  • SREのみならずエンジニアにとってゼロにはできないものであることを認識しておきたい
  • トイルが実業務の半分以上あるいは大量に発生する場合は、問題視したい

トイルが悪になる理由は以下。

キャリアの停滞 (個人)
  • トイルを積み重ねても、サービス・個人どちらの成長にも繋がらない
モラルの低下 (個人)
  • あまりにトイルが多いとSREとして業務をすることが嫌になってしまう ><
    • 切ない
混乱の発生 (SREチーム)
  • SREが発揮する本来の成果/Site Reliabilityやサービスをスケールさせることに時間を割けない。SREの存在意義が自他ともにわからなくなってしまう
    • 切ない
進歩速度の低下 (SREチーム)
  • トイルが多すぎると SREチームの生産性が下がる。火消し作業ばかりに注力し本来のプロダクト機能開発速度の低下=サービス成長の機会損失
    • 切ない
習慣づけ (SREチーム)
  • SREが頑張ってトイルをやっつけすぎるとトイルに対してSREの活躍を期待するように
    • トイル対応はSREの主たるミッションではないのに切ない
摩擦の発生 (SREチーム)
  • トイルが多すぎることによるチーム全体のモラル低下、SRE個々の摩擦
  • 切ない
信義違反 (SREチーム)
  • 大量のトイルは、新規作用されたSRE、あるいは異動者に対する信義に関わる

5.5 まとめ

  • 優れたエンジニアリングで、毎日少しずつトイルを無くしていこうという気概を持とう
  • そのことでサービスをクリーンアップし、SREの労力をスケーラビリティの向上と次世代サービスのアーキテクチャ設計、ツールの構築にシフトしていこう
  • そしてイノベーションを増やし、トイルを減らしたいね

わかったこと

  • SREにとってトイルの存在
  • トイルがもたらす影響
  • トイルを減らすために
    • SREの技術力、DevOpsの対立を生まない体制と仕組みづくり、どれが欠けてもいけない。トイルを削減するという目標を掲げ、削減に必要な材料は同時に進化させるという意思が重要そうだ
      • 自分の職種やチームにもトイルはある。判断を必要としない手作業や繰り返しを「仕方なし」で済ませている。気に留めないといけない

感想

「私たちSREにとってこれはトイルです」と決めて「トイルによりこんな悪影響が及びます」なので「撲滅したい」と発信することで、自分たちのミッションをブラさないとするGoogle SREの信念を感じた。一貫している。
と同時に、"5.4 トイルは本当に悪なのか" の節では SRE の悩みを垣間見せてもらった気がした。

トイルを撲滅するための案として「SREのクリエイティブやイノベーティブマインドを広報し、周辺理解の醸成を進める」を挙げてみたい。SREがパフォーマンスを発揮する対象が浸透すれば、エンジニア全体でトイルを撲滅するあるいは分担できる環境が整いやすくなるかもしれない。
他に、トイルから話が逸れるが、SREのクリエイティブは組織や担当サービスにより異なるイメージがある。一人ひとりのSite Reliability Engineer が、まだ新しい職種であるSREのありようをそれぞれの環境で育てていく、というおもしろさがありそうにも感じた。

SRE本を興味深いな読み返したいなと思える点として、別職種である自分にもあれこれと置き換えて思考できるというのがある。

参加者 : missasanさん, yuukiさん

自分傾向の記録

メモを見返していたらゲーム感覚で回答したアンケート結果が出てきた。それぞれ時期が違うにも関わらず、傾向が似通っているように感じるので記録しておこう。

金はすべて光るとは限らない。放浪する者が皆迷っているとは限らない。年老いても強いものは枯れない。深い根に霜は届かない。
J. R. R. Tolkien

Tolkinの言葉に違和感がない。共通して、理想主義者なのだなあと感じるが自覚はない。こういった結果に引っ張られたくないな〜とも思う。自分のことはわからないものですね。

ストレングスファインダー

2017年

  1. 個別化
  2. 共感性
  3. 収集
  4. 信念
  5. 親密性

16 Personalities

2016年
“仲介者”型の性格 (INFP-A / INFP-T) | 16Personalities
読み返して笑った。現実離れした雰囲気を感じる。

仲介者型の人達は、他の性格タイプよりも、よく思いにふり、楽しみながら物事をあれこれ想定したり、哲学的な事柄について思い巡らせたりします。
放っておくと、まるで隠者のように引きこもったまま連絡が途絶え、友人やパートナーが、多大なエネルギーを費やして、現実世界に連れ戻すことになります。

職業適性

2015年
「哲学者」外向性がゼロに近い。「知覚」と「判断」は半々なのかな。


珈琲美美@福岡 のこと

福岡は大濠公園近くの珈琲美美 について書く。

珈琲美美を知ったきっかけは、珈琲特集雑誌で アクセスが制限されています[食べログ] のマスター 畑さんが語るインタビュー記事だ。
インタビューでは、Elephant Factory Coffee のこだわりや全国の珈琲専門店を巡られたこと、その中で影響を受けた自家焙煎珈琲店を3つ挙げられたいた。尾道珈琲店(名前忘れ)「大坊珈琲店」そして「珈琲美美」。うろ覚えであるが、畑さんのコメントはこうだった。

福岡の珈琲美美さんの珈琲はクオリティが高い。なによりもマスターが30年間店に立ち、切り盛りをしている。かっこいいんですよ。

今は閉店してしまった南青山の名店「大坊珈琲店」は自分も大好きなお店だったので、福岡に出向く機会があれば珈琲美美にきっと行くんだと決めた。

時が経ち、友人が福岡を訪れた際に「落ち着きのあるお店」として店前と珈琲の画像を投稿された、その場所が偶然にも珈琲美美だったのだ。
うおーそこは私が行きたいと思っていた珈琲専門店です!
ずっと行きたいと思っていたお店が一気に身近に感じられてホクホクしたのを覚えている。

それからさらに1年が過ぎて、2016年夏に会社の出張で福岡を訪れることになる。もちろん珈琲美美が脳裏を過ぎるのだった。

出向いた日、博多駅から地下鉄で大濠公園駅で降りるべきがぼんやりして下車し損ねたりした。無事下車して、池のほとりを経由して珈琲美美まで散歩。とても蒸し暑い日で強い日差しに辟易した。池近くのベンチに座って温風に吹かれながら亀と鳥を眺めた。

大濠公園を抜けて左に曲がり、すこし進んだ先に珈琲美美がある。左?右かも。

お店は緑の多い並木道通り沿いにあり、店前には珈琲豆を焙煎した香りがずっと漂っていた。1Fは焙煎に使われる機械が収められた作業場で2Fに案内された。店内はクラシックな色調で統一されており、木の香りと珈琲の香りが半分ずつする。カウンターの向こうにマスターと奥様が並んで立っているのが見えた。
フルーツケーキとマザグランをオーダー。珈琲は奥様の手によってそれはとても丁寧に淹れられた。作業工程の一部始終を観察し、見惚れていた。時々マスターの森光さんが指示出しをされている様子が見えた。
マザグランは氷の入っていないタイプの濃厚なアイスコーヒーで、冷やす工程でシェーカーが使われていた。当時の画像が全て失われてしまい残念。よく冷えたマザグランは綺麗にコーヒーとミルクが分離されて香りはもちろん見た目にも美しかった。
フルーツケーキはたくさんのドライフルーツとナッツが含まれてどっしりだ。上品な甘さが好みで今すぐたべたいとなる。
のんびりとした時間が流れるおすすめのお店です。

今年になって、2016年12月に珈琲美美のマスター森光さんが亡くなられたことを知った。
大坊珈琲店のマスター大坊さんが「僕は珈琲屋だけど、彼は珈琲だった」と森光さんについて語られていた。
ああいいな、これが知己というものだな、と思う。

珈琲美美は森光さんの奥様が引き継がれている。いずれまたマザグランとフルーツケーキをいただける機会があるとうれしい。


大坊珈琲店

大坊珈琲店

珈琲屋

珈琲屋

本を読む会 SRE サイトリライアビリティエンジニアリング #3

読み会予習ログです。

第II部

Google - Site Reliability Engineering

  • SREが仕事を進めるうえでの原則が語られている
    • SREのオペレーション全般
    • SREの振る舞い
    • SREの関心ごと

#3 リスクの受容

Google - Site Reliability Engineering

読み解きたいこと

  • SREのリスクマネジメントのあり方
  • SREのサービス/システム視点、関心

読書メモ

まえがき

  • 信頼性は大切であるが100%を目指してはいない。過度の信頼性はコストである
    • 新しい機能開発やユーザへのプロダクト提供速度が落ちることになる
  • 「リスクマネジメントとデバイスとのバランスを鑑みたうえでユーザの満足度を維持する=信頼性」と定義できそう?

3.1 リスクの管理

  • 信頼性を担保するためにかけるコスト
    • 冗長なマシン・コンピュートリソースにコストをさく
      • 冗長化することで、メンテナンスのやりやすさ、パリティコードブロックを保存するための領域を持てる
    • エンジニア組織が、障害リスクを減らすためのシステムや機能を構築するためにエンジニアリソースを当てる
  • つまり信頼性の担保=リスクを管理することと言える
    • リスクマネジメントをしっかりとおこなう組織とシステム整備が重要
  • リスクへの考え方
    • 連続的なものであり、信頼性を高めるためのエンジニアリングと障害許容レベルの定義を決める
    • それは(おそらく)サービスにより異なる。ビジネスが許容できるラインをしっかりと理解していることが求められる
  • 可用性のラインを理解することでリスクマネジメントを行う

3.2 サービスリスクの計測

  • システム(サービス)ごとにどういったメトリクスを計測すればよいかを見いだすことは信頼性の担保に非常に有益
    • パフォーマンスの改善、劣化の追跡が可能になる
  • 計画外の停止時間
    • リスクの許容度をもっとも単純明快に表す方法。計画外の停止時間は、サービスの可用性が実際のところどの程度求められるのかによる
  • Googleでは時間を基にした可用性は定義していない(世界中で展開するサービスのため、時間を基にしたメトリクスにあまり意味がない)
    • 総リクエスト数に対する成功したリクエスト数を可用性を測るメトリクスとしている
  • 四半期単位で可用性のターゲットを設定。そこから週・日単位にブレークダウン
    • 定量目標の設定は四半期ごとに見直すくらいがちょうどよいのだろうなあ半期だと長すぎる

3.3 サービスのリスク許容度

  • Googleではサービスのリスク許容度は明確に定義していない
  • するなら、SREがビジネス観点(事業側の定量目標やクライアントとの契約内容、パフォーマンス)を把握し、エンジニアリングで解決可能な目標に変換する必要がある
  • SREとプロダクトマネージャーの協働が必要
  • とはいえ簡単なことではない
    • プロダクトや事業サイドの責任構造はあっても、インフラストラクチャサービスの構造がないあるいは一致しないことがしょっちゅう
      • サービス側と人事との難しさと共通しているように感じる
      • (CRE目線なら)クライアント先の事例を集め、サービスやシステム構造によって何をプライマリメトリクスとするかの提案ができるとよいのだろうか

3.3.1 コンシューマサービスにおけるリスク許容度の明確化

  • SREとプロダクトマネージャ(ビジネスやユーザーに対する可用性/可用性をどうみなすかについて議論できるポジション)の目線合わせが重要
    • プロダクトマネージャにはある程度システムやSREの思想がわかっているとなおよい
  • 双方で明確化するリスク許容度
    • 必要な可用性レベル
  • 障害の種類とサービスへの影響
  • 「リスク曲線上にサービスを位置づける上で、サービスコストはどのように利用できるか」 > 日本語の意味がわからなかった
    • How can we use the service cost to help locate a service on the risk continuum?
      • リスクは連続して起こりうるものだと定義した上で、サービスコストをどこまで払うことが可能であるか、と訳せそう
  • 可用性を満たすために考慮すべきメトリクスがなにであるかの合意形成
3.3.1.1 可用性のターゲットレベル

可用性をどう設定するかは、そのサービスがユーザに提供する機能と市場におけるサービスの位置付けに依存。またはサービス機能の開発ステージ(途上なのか過程なのか充足なのか)にも依る。

  • ユーザーが期待するサービスレベル
  • サービスの収入構造
    • ビジネスモデル
  • 競合との差
  • toB or toC
3.3.1.2 障害の種類

「上り一日下り一時」「好事 門を出でず、悪事 千里を走る」を想起させ、SREの役割には頭が上がらない。

  • 障害の種類により、障害レベル、ユーザに対する信頼度、ビジネス影響など複数の影響範囲を知った上での判断が必要
3.3.1.3 コスト

コスト意識を数字で可視化。なんとなくふわっとではなく。

  • 可用性を1桁改善したら収益がどれだけ増すのか?とか
  • その収益増加は、信頼性を担保するためにかけるコストに見合う価値があるか

収益で測れないケースでは、ISPのバックグラウンドエラー率を考えることも有効。はてなでもそういったケースは多そう。

3.3.1.4 サービスの他のメトリクス

リスクマネジメントをやる上で、可用性以外のメトリクスも考えておけるとよいですよというお話。

  • 例、Google Adsにおいては、Web検索機能の速度
    • 数字だけじゃなくて、人の体感速度にまで気を使っているのがさすがー
  • サービスにより(Ads とAdsense) 優先づけができる
    • Adsenseはパブリッシャ側のレイテンシにもよるため、Adsに比べるとほんの少し緩めで設定できますよん、など

3.3.2 インフラストラクチャサービスのリスク許容度の明確化

コンシューマサービスとの基本的な違いはインフラストラクチャのコンポーネントの複雑さ。複数のクライアントを持ち、各クライアントの要求が多様。

3.3.1.1 可用性のターゲットレベル

システムの可用性定義は、複雑かつ大規模な分散システムの特性や働きを理解するところから。どのメトリクスを重視するかもことなりそう。より高い信頼性が求められることが多い。
インフラストラクチャのシステムの要求を理解するには、リクエストキュー の状態を調べてみるのがよい。 https://wa3.i-3-i.info/word14716.html

3.3.2.2 障害の種類

システムたちそれぞれの仕組みと特性の違いについて。

  • 低レイテンシのユーザにとっての成功は、オフライン分析に関心があるユーザにとっては失敗。
3.3.2.3 コスト > 要確認

前半の記載内容がよくわからなかった。
システムに何をさせるか(どんなデータを持たせて、そのシステムにどんな仕事をさせるか)により、何をコストとみなすかは変わるよという話?
システムを分散化し、持たせるデータとシステムの特性により、システムごとの可用性と信頼性を設定していくことが大事よ、と書かれてある気がする。

3.3.2.4 例)フロントエンドのインフラストラクチャ

いくらインフラストラクチャレベルで信頼性可用性が担保されたとしても、サーバサイドの例えばリバートブロキしやロードバランシングが含まれるようなシステムの信頼性が提供されていないと意味がありません、という話。
リスク許容度は、単眼的一役割的に判断するのではなく、複眼的に議論判断する必要があり、それによりリスクマネジメントを敷いてそれぞれの可用性を設定する必要がある。

3.4 エラーバジェットの活用

プロダクトチームとSREの典型的な認識の分断例。

  • ソフトウェア障害の許容度
    • Dev vs Opsのおさらい
  • テスト
    • 開発速度とシステム信頼性のバランシング
  • プッシュの頻度
    • デプロイ作業。たくさんデプロイしたいプロダクトチーム/デプロイ頻度が高まるほど障害懸念を予想できるSREチーム
  • カナリアテストの期間と規模
    • 新機能のリリース時における昨日全体のQAのようなもの?

プロダクト・SREチーム双方にとって最適なバランスで価値のあるサービス・システムを提供するために、双方による交渉ではなく、客観的かつ明確なデータで判断できることが望ましい。そうすることで障害に対するリスクマネジメントをプロダクト/SREチームで合意できるようにしようね

3.4.1 エラーバジェットの形成

Googleのプロダクトチーム・ SREチーム間のエラーバジェットのやり方。

  • プロダクトマネージャによるSLO(サービスレベル目標/Service Level Objectives)を規定。四半期間に期待するサービス稼働時間を設定
  • 実稼働時間は、モニタリングシステムで計測
    • Mackerelの出番か
  • この2つの数値差が、3ヵ月間の「損失可能な信頼性」と「予算」残分となる
  • 稼働時間がSLOを超えた場合は(うれしい)つまりエラーバジェット残分がある場合は、新たなリリースをデプロイできると解釈可能
3.4.2 メリット

適切なエラーバジェットを設定することにより、SLOに対する双方のコミットが高まる。
エラーバジェットの消費が高い場合は、SLOが正しい内容であるかを照らす基準にもなる。その場合はSLOを緩めるなど、サービスの現状に適した選択肢を判断するための材料としても使う。

www.slideshare.net

わかったこと

ふんわりです。

  • サービスの信頼性担保=リスクマネジメントと言えそう?
  • サービスの特性とビジネスモデルにより、優先すべきリスクととってもよいコストを定義しておけるとよい
  • SREはコンシューマ、インフラストラクチャ、両サイドのリスクを理解しておく必要があり、障害時にはリスクの度合いによりどこにコストを割くかを的確に判断する必要がある
  • エラーバジェット=SREとプロダクトチーム間で共同所有する指針
    • エラーバジェットがあることにより、リスクとコストを双方の尺度で判断し、同じ目的に到達することができる

感想

SREチームは技術領域の幅広さだけでなく、サービスについても広く多角的に認識している必要があることを知った。じゃないと、何をメトリクスにするか、エラーバジェットの作成、障害時に即時適切な判断ができない。手術を担当する外科医、症状から病を推測する医師、航空機におけるパイロットに似ている。
「サービスの信頼性を担保することはリスクマネジメントを徹底することである」逆説の考え方が興味深い。いま何をすべきかを決める時に、何をしないか何を捨てるかを考えるのだ。
Googleはその判断基準をデータや数値重視を徹底することで知られるが、そのことを実感できた章だった。

  • 参加者 missasanさん, yuukiさん, tomomii

「道をつくる」その後の思索

昨年末の WSA研#1 縁側トーク「道をつくる」発表から半年が過ぎた。

あの時の私はWSA研に集う皆さんに向けてお話をしながら、心の中で自分はこうありたいのだと自己表明していたように思う。そして参加者皆さんがどうありたいのか聞けるとうれしいとも考えて、ニールス・ボーアの言葉を借りて、このあとの発言は断定ではなく質問です、と伝えた。

発表体験を経て自分の思考フローが少し変化したように感じている。
どう変わったかというと、縁側トーク以降 しんどいなぁなんだか疲れたなぁと感じる時にふと自分の発表内容を思い出すようになった。一人振り返り会の回数が増えて、自分のありようで迷うことが減った。自問自答がスタートし、脳内で一定のフローが流れ、しばらくすると靄が晴れて視界が広がる。こんなイメージ > tired > questioning > observing/deep thinking > for what > action image.
碩学の思想と自身の考えを言葉にして発表するという体験が、ほんの少し自分に変化をもたらしたみたいだ。この実感が興味深い。

脳がトーク内容やいまの実感を都合よく編集しないうちに、未来の自分のために、話した内容のうち「個」を考える際に辿った言葉と思索を書き留めておきたい。

道をつくる:はじめに

以下、トークで使う「道」「研究」「個」はこう定義します。

    • あり方 (being), 道理
  • 研究
    • 研ぎ澄まし究めること。新しい事実や解釈を発見すること
    • なんらかの技術において専門領域をもつ個人
    • 専門領域や研究分野で、新たな価値を生み出すことにチャレンジを厭わない

紀元前後の思想家や哲学者の書籍を読むと「道」の解釈は東洋と西洋でニュアンスが異なることがわかります(下表参照)。東京大学東洋文化研究所 安冨教授の発表でその違いを聴くことができます。 > 安冨 歩「「道」とは何か? :『論語』と『老子』の世界観」ー東洋文化研究所公開講座 2017 「アジアの知」 - YouTube

東洋(老荘思想 西洋
being to be or not to be
一本道の哲学 選択の哲学
全体を捉える、誰しもが行きつけばよい、一本道ひとそれぞれの道、道を間違えても迷ってもよい、間違えて戻ってこないのがアホ、自然派生的で感覚的 全体を分解して個別に理解、よい選択をすれば天国/悪い選択をすれば><、現代社会はこっち(受験、就職、経済、法..)、合理的で論理的
参考資料「論語」「老子など 参考資料「自省録」「君主論」など

縁側トークで使う「道」は、老荘思想で語られる道 (=being) を前提にしています。理由は、自分が傾倒してきた科学者の思想や考え方が、論語老子に書かれている内容と似ていることに気づいたからです。科学者の著書を思想にフォーカスして読むうちに、ノーベル物理学者 湯川秀樹博士は幼少期から漢文や老荘思想に親しんでいたことを知りました。たしかに湯川博士の著書や専門誌では「道」の思想が滲むフレーズを多く見つけることができます。湯川博士は物理学者になる以前から、老荘思想に親しい考えをしてきた方なのでしょう。

・ただ流行を追っているだけというのはつまらない生き方です
・今日の真理が、明日否定されるかもしれない。それだからこそ、私どもは、明日進むべき道を探し出す
・1日を生きることは、一歩進むことでありたい

ノーベル物理学者  湯川秀樹

調べを進めるうちに物理学者 アインシュタインニールス・ボーア、哲学者ヴィトゲンシュタインも東洋的な思想に関心を寄せていたことがわかってきました。このことは偶然ではなく、研ぎ澄ましてものの理を見つめ、新たな価値や解釈を見つけ出す人たちに共通する思想かもしれないと考えています。

道をつくる

私たちがなんらかの専門領域を突めようとするとき、碩学の思想や自分の経験が役に立つかもしれません。上述した「道」「研究」「個」の定義を心に留めて、私たち個のありかたを3つの問いでお話します。

  1. 自分だけの道をつくる、語る
  2. 自分の考えをもつ
  3. 孤独をおそれない

1. 自分だけの道をつくる、語る

自分の時間や考え、生き方において、他者の意見を参考や気づきの材料にしても、引っ張られる必要はないとお伝えしたいです。立場や言葉が強いひとのまねをする必要もありません。科学者をイメージしても、素敵だなかっこいいなと感じるひとも、独自の歩みを進めているように見えます。
自分を見つめようとする点で、キャリアコンサルタント資格取得の学習過程のエッセンスが活きそうです。ひとのキャリアを考えるフローは一本道の考え方が軸であり、老荘思想と重ねて考えられました。自身の強みを考える過程で、自分のストーリーを語ることを重視しています。

  • 過去に見つける
  • 現在を見つめる
  • 未来を見とおす

過去から連続する時間の積み重ねが今の自分を作っているとしたら、じゃあ今まで自分はどんな時に喜びや感動を感じていたでしょう?自分を突き動かしてきた思いや考えは、過去のどの経験や感情と繋がっているでしょう。自分の源泉はもしかしたら過去に見つけられるかもしれません。過去と今を見つめて、これからの自分をつくっていく。そんな考え方を心理学とカウンセリングのアプローチで学びました。

少し話が逸れますが、自分の時間を生きることは脇目もふらず前に進むだけではありません。寄り道をして、時には失敗をして、その道中で、感動・喜び・楽しさを見つけて小さな成功を味わう。そういったことが人生を豊かなものにするのだと思います。
疲れたときは立ち止まって休めばいい。自分のペースでよいのだと思います。先を急ぐ旅ではないはず。立ち止まる時には、そこに意味があるから足元を見て靴ひもを確認したい。ほどけたままの靴ひもでは長い旅は歩けないし、走れば転ぶし、走らなくてもひもを踏んで転ぶかもしれない。もしも転んだら、また立ち上がればよいのでしょう。

自分の経験を無にしない、他者のまねではなく自分の経験から学ぶという姿勢。自分が信じる道を自分の歩調で歩いていきたいものです。

2. 自分の考えをもつ

1. をするためには、自分の考えをもつことが大切です。何かに気づいた時、他者から何らか刺激を受けた時、その事象に対して自分はどう考えたか。事あるごとに自分の中で考える癖づけをしておけると、その事象が自分にとってどんな意味があるか意味付けしやすいように思います。ショウペン・ハウエルが「思索がない読書に意味はない」と書いているのは興味深いところです。著書「読書について」で、多読は迷いのもとで悪本は読んじゃダメと言い切っています。
自分の考えをもつことを意識付けできそうな方法をいくつかあげます。もっといろいろありそうなので、自分のやり方を見つけてみるのも楽しいですね。

  • 問いを立てる
    • 問いを立てる勇気を持つ
  • 論理を上手に使う
    • 全体像から筋道立てて(なんでそう考えるのか?を考えることで)見えてくるものがありそう
  • 言葉を鍛える
    • 自分の考えを整理し、他者に伝えるため
  • 頭の外に出してみる、議論をする
    • 脳は自分の考えであっても言葉や文字にして外に出してみないとうまく理解できないらしい。また、議論をすることで別の視点が得られ、理解が深まる

自分の考えや問いは、他者に伝えようとしたり文章にすることで、やっと形をはっきりさせることができるのかもしれません。

自らの考えを持ったうえで、様々な意見に出会う。いろんな物の見方に出会う。新しい言葉や新しい意味の広がりに出会う。そうしてはじめて、自身のより深い思考に出会えることがありそうです。思ってもみなかった場所に足を踏み入れることができるかもしれない。自分と異なる領域や別分野の考えを取り込むことも意識したいです。

3. 孤独をおそれない

言葉の通りです。
これまでに知った科学者や哲学者で、孤独じゃないひとはいませんでした。アインシュタインはあまりにも未来を見通していたために他者に理解されず孤独であった、と湯川著書に記されています。湯川博士ヴィトゲンシュタインも自身の孤独について語る文章があります。WSA研の皆さんだって、研究者ではない私だって同じだと思います。
研究をする、まだ名前がない技術分野を突めようとする時に、先が見えずわけもわからず一人で苦しいと感じることがあるかもしれません。そんな時は孤独を友だちにしたい。
何かを突めるとき、孤独から逃げない姿というものに美しさを感じます。私はそういったひとの孤独に気づきたいし応援したい。

  • 自分のビジョン、志の舵を握るのは自分
  • 先を見通し、自分の技術や言葉を語ることは孤独。すぐには理解されないことも
  • 他者の同意や期待通りに生きたら、他者の人生になってしまう
  • なにをするか、どう考えるかの決定権は自分

道をつくる:むすび

発表に至った自分のこれまでを記します。

高校1年生の時に読んだノーベル物理学者 湯川秀樹旅人―湯川秀樹自伝 (角川文庫)の一文に魅せられ、科学に纏わる書籍を好むようになりました。

未知の世界を探求する人々は、地図を持たない旅行者である

専門書は理解できないため物理学者の書いた随筆を読み、量子力学のりの字も分からずアインシュタインを知り、科学者の端的で美しい文章をノートに書き留めていました。読んでいると森の中を歩いているような静かな気持ちになれるので。
科学者が棲む世界は、開高健氏の言葉「成熟するためには、遠回りをしなければならない」そのもので、迷うことに対する恐怖が和らぎ、ものの理を突き詰めることの意味を知れたように思います。科学者のものの見方は刺激的でユニークで、物理学者 ファインマン博士の著書はとりわけ笑いながら読んだ覚えがあります。

ものごとの本質を捉えようとする視点や知らない解釈や新しい定義を知るうちに老子論語を読むようになり、いつしか私も自分の道を歩んで生きたいと思うようになりました。道に迷いながらも美しいなにかを見つけられる生き方に憧れがあります。
こんな自分が、技術領域の研究会でお話させてもらう機会をいただくことができた。体験をきっかけに自分が少し変わった実感がある。人生捨てたもんじゃないな〜と思えます。

ある夢が現実化する過程

5月が終わる。年初に書いたエントリを読み返していた。
2018年 - Words fly away, the written letter remains.

抱負を書いたがまだ一歩を踏み出せていない。踏み出す方向も決めかねている。大丈夫?大丈夫じゃない気がする。「途中」で検索してみた。

途中
物事を始めてから終わるまでの間。まだ終わらないうち。中途。

途中で検索をして、中途が出てくるのはおもしろい。次は「過程」で検索。

過程
物事が変化し進行して、ある結果に達するまでの道筋。プロセス。進化の過程

変化し進行して、結果に達するまでの道筋。進化の過程。ほお。

たぶん大丈夫だろうと思えた。自信はない。でも直感にはこれまでの自分の経験や価値観が詰まっているだろうから、今はマイペースに歩みを進めることにする。自分の直感はまあまあの確率で当たるのだし。

情報の波にのまれると不安になるから新しい分野の本をゆっくりと読み進めている。それにより新しい価値を知れることに喜びを感じる。ずっと先の自分像はあるけれど、一気に結果を出そうとは思わない。今日も明日も、毎日は結果ではなく過程であり、トレーニングをしていくように積み重ねて近づいていくのだ。

ここまで書いて、学生のころに図書館で見かけてノートに写した一節を思い出した。事あるごとにこの言葉に救われてきた。
だれのものかご存知の方がいらっしゃれば教えてください。

ある夢が現実化する過程

押し寄せる感情の波をやさしく受け入れ
ひとつひとつの出来事に心を動かしても
奪われることはなく
つらぬく強い意志などとかいうものは
あまり考えないようにして
できる限りのやさしい視線で
遠くの方に静かな見通しを持ち続けること