Joi本「テクノロジーが予測する未来」を読んだ
表題の通り。
全体的な感想はブクログに書いて放流済みだが、こちらにも編集して残しておく。
対象の書籍はこちら。
全体的な感想
購入したのは9月くらいだろうか。発売が5月なので少し読むのが遅くなってしまい半年ちょっと寝かしてしまったことになる。 この業界だと半年も前だと一昔前と思えるほど過去の出来事に感じてしまい、内容によっては古くなることもあるだろうが、タイトル通り未来に向けての考察、特にまだ方向性が定まっていないNFTのユースケースやDAOに関する言及がメインと思うので特に問題なかった。
全体的にはここ2年くらいの間に見聞きして大まかに知っていることが7,8割といった感じなので全く知らなかった、というものは少なかったけど、改めて定義や著者の思うあるべき姿を言語化されたのを読むと自分の頭の中にも定着しやすくなるという点で良かった。
コンパクトにまとまっているので自分が言語化したり誰かに話したりする時に参照しようと思える点でも良書だと思う。
メタバースについて
メタバース言及は少なめだったが、現時点ではまだメタバースは黎明期といってもいいくらいの状態だと思うので仕方がない。
メタバースに関しては 佐藤 航陽さんの世界2.0 メタバースの歩き方と創り方 や 國光 宏尚さんのメタバースとWeb3 などがあるのでそちらを読み込んだ方が理解が深まりそう。（後者は未読）
メタバースついでに言えば、こちらも近いうちに読んでおきたい。
読書メモ
以下、付箋つけたところ。
あまり付箋は貼らなかった。
序章
- P.55『オンライン上でのコミュニケーションを前提として、何らかの価値の交換が行われている空間というのが、本書で考えようとしているメタバースの姿としてふさわしい』
第4章
P.162 （オードリー・タンさんの話してたこと）『これからは「目的」から始まる学び＝「パーパス・ベース・ラーニング」に力を入れる必要がある』
P.163 『プロジェクト・ベース・ラーニングでは、何をプロジェクトの起点としたら子どもたちの意欲が高まるかが課題でした。...（略）一方、パーパス・ベース・ラーニングでは、まず先に「社会に貢献したい」という大きな目的があります。』
P.164 『「インターネットは役に立つものですか？ それに対する僕の答えは、「あなたは、何に興味がありますか？特に何にも興味がないのなら、インターネットはあなたの役には立ちません」でした。 これはつまり、インターネットは知識や情報を得る新しい手段だから、得たい知識や情報がない人にとっては無用の長物である。「役に立つか」どうかの答えはテクノロジーそのものではなく、自分の中にあるんだ、ということを伝えたかったのです。』
P.168 『やはりweb3の分散化（非中央集権化）という点に大きな意義と可能性を感じているので、技術的にもスピリット的にもweb3化していく未来を選びたい。 そのためにも、本物のアントレプレナーシップを育てることが不可欠であり、これまで話してきた「パーパス（目的）」「パッション（情熱）」「クリエイティブ・コンフィデンス（自分の創造性に対する自信）」を育んでいけるかどうかが重要な鍵になってくる』
”テック企業はアジャイルなんてやっていない”とは（「ユニコーン企業のひみつ」読書メモ）
タイトル通り、前から読みたかった「ユニコーン企業のひみつ」をようやく読んだので、気になった部分をメモがてら残しておく。
脈絡もなく引用しつつ取り上げていくだけなのでまとまりが悪いことを先に断っておく。
気になったところメモ
以下、本書の前から順に読んで気になった、印象に残った部分を取り上げていく。 たくさんあるので逐次更新。
1章 スタートアップはどこが違うのか
1.1 スタートアップは「火星」から来た
- スタートアップは他人から時間を借りて生きている。
- 金を借りている場合もあるだろうが、調達した資金が尽きる前までの間に迅速に価値を出すというプレッシャーの方が強く感じるのだと伝わる表現。
1.2 「学習する機械」
- テック企業は従業員に財務情報を公開する。あらゆるデータを信じてゆだねる。開発者に自分のマシンへの管理者アクセス権限を与える。そして常にチームにこう問い続ける。「どんな支援があればもっと速く進める？」
- 開発者全員に初日から本番環境へのadmin権限を与えるということの意図が伝わる背景。
- 当然、チームの成熟度は考慮すべきでエンタープライズ系企業が明日からやってうまくいくわけじゃない。
1.6 "Think Different"
2章 ミッションで目的を与える
2.1 プロジェクトの問題点
ユニコーン企業がプロジェクト方式を採用しない理由として、プロジェクトの問題点が挙げられている。
- 期間があまりにも短い
- フィードバックの機会がない
- プロジェクトはあまりにも融通が利かない
- プロジェクトは力を奪う
- プロジェクトは間違ったことにフォーカスしている
特に4つ目の「力を奪う」で説明されているこの一文が強い。
プロジェクトは考えることをやめさせてしまう。
2.2 これが「ミッション」だ
2.6 ミッションの例
ミッションの原則に従うと、ミッションの予算とはチームの人数のことだ。以上。
- トップダウン的な施策で「見積もりは？必要な人員は？」と言われることに対して絵にかいた餅で説明して承認をとるのは違うよ、と。
- 決まった人数＝予算でミッションを進めるので実現時期も今年度中とコミットできるようなものではないと言える。
ミッションを設定するのは経営リーダーだが、そこにどうやって到達するのかを決めるのはチームだ。（略）
チームは自分たちで自分たちの仕事を生み出す。何を作る必要があるのかを決めるのはチームだ。チームに渡すミッションは...
- 会社にとって必要なものにしよう
- そのチームで責任を果たせるものにしよう（他への依存を少なくしよう）
- どうやって達成するかの計画はチームが協力して考えられるものにしよう
- 表現はシンプルだが、すごく難しい。
3章 スクワッドに権限を与える
3.1 スクワッドとは？
- スクワッドとは、少人数で、職能横断（Cross-Function）の、自己組織化されたチームだ（多くの場合、8名以下で編成される）。スクワッドは同じオフィスに席を並べて、自分たちが作ったプロダクトの隅々まですべてに責任を持つ。
- ちいとぽでいうところのストリームアラインドチームに近い定義。
- 「自律した小さなテックチーム」
3.2 スクワッドはどこが違うのか？
- スクワッドは（略）普段から、MVPを出来るだけ早くリリースすることが奨励されている。どうしてかって？スクワッドは最初のバージョンは「正しくない」と心得ているからだ。だから顧客からフィードバックを得たい。しかしフィードバックを得るにはリリースしなければならない。
3.8 Q&A
- 「結論を出す」という行為自体はチーム自身にやってもらうことが望ましい。なぜなら、あなたがチームの領域に踏み込んで何をすべきかを指示すればするほど、チームに与えられている権限や信頼は減ってしまうからだ。
4章 トライブでスケールさせる
（特になし）
5章 ベットで方向を揃える
5.2 カンパニーベットとは
- カンパニーベットとは、会社が取り組みたい重要事項を、終わらせたい順に並べたリストのことだ。
- 通常、小さい目標はカンパニーベットにはならない。ベットは「大きな岩」だ。
- 全社リソースの30%は常にカンパニーベットに取り組んでいる状態にしておく
- カンパニーベットはチームが常に取り組むべきものを示す指針にもなる。
5.3 カンパニーベットの仕組み
- DIBBはやるべきだと考えているを系統立てて検証するための意思決定フレームワークである
- Data, Insight, Belief, Bet のそれぞれの頭文字
5.5 やり抜くためのコツ
- 反直感的ベットとは、当初は誰も信じてくれないのだが、後から考えると実に見事で明白に思えるようなベットのことだ。コーヒー１杯で７ドルも取ろうなんて正気か？誰がお金を払って私のソファで寝たいと思うわけ？
- 念を押しておくが、自分たちの時間を何に費やすべきかの最終的な決定権はあくまでスクワッドにある。
6章 テック企業で働くということ
6.2「何をすべきかを指示するつもりはないよ」
- （スクワッド解散に伴い既存プロダクトの所有者がいなくなり）新しい2つのスクワッドは、どちらが既存のプロダクトを引き継ぐのかを合意できなかった。そこで彼らは、トライブリードである私の上司に決めてもらおうとやって来たというわけだ。ところが上司はそれを拒否した。
- 「情報が足りないとか、文脈がわからないとか、全体像に疑問があるとか、そんなときは私のところに来てほしい。だけど、これはあなた方が自力で解決すべき問題だ。」
- 本当に現場でよくある話で、決まらないものはトップダウンで決めるしかないのだと思っているが、これはあくまでも「よく話し合って両チームで決めてほしい」という回答を出すのだということ。これができる組織の強さよ。
6.3 お金の使い方が違う
- これまでの職業人生で、スピードのためにお金を使えなんて言われたことは一度もなかった。
- もし「資金を投入すれば競争に勝てる」というのなら、喜んでそうする。細かいことにこだわっている場合じゃない。
6.4 「信頼してないの？」
- 従来型企業は従業員を信頼していない。そのため、数え切れないほどの手段を用いて、あらゆる物事の進みをものすごく遅くさせている。
- （大手テック企業の場合）開発者は自分のマシンへのフルアクセス権限がある、すべてのチームが本番環境にアクセスできる
- テック企業ならこれはせめて同じ水準にしたい...が、そんなチームに所属していた経験は未だにない。
7章 生産性向上に投資する
7.3 ハックウィークを開催する
- 「ハックウィーク」とは、エンジニアが通常業務を脇に置いて、自分の好きなことをなんでもやれるイベントだ。（略）Googleはこれを「20%ルール」として実践して、同種の発想の有名な先駆者となった。
- ハックウィークに参加するのは単独でもいいし、チームを組んでもいい。内容は基本的に、やりたいことなら何でもいい。ただし一つだけルールがある、ハックウィークの最終日には必ずステージに上がって、自分の時間をどう使ったのかをみんなに示さねばならない。
- ハックウィークでは何かをリリースすること、何かをデモすることが強く推奨されている。
7.5 品質に高い期待を持つ
（コラム）新機能なしの2年間
- SpotifyのCEOであるDaniel Ekは取締役会で、CEOなら誰もやりたくないメッセージを伝えた。（略）「Spotifyは来年まで新機能を一切追加するつもりはない。その代わり、インフラストラクチャとスケーリングに取り組むことにする」
- CEOがこれを宣言するというのはどのような心境なのだろうか。想像を絶する。。
7.8 フィーチャーフラグを活用する
- フィーチャーフラグは（略）ソフトウェアの特定機能を本番環境上でオンにしたりオフにしたりできる。（略）理由は2つある。未完成の作業の統合と、実験だ。
- （フィーチャーフラグは）チームが未完成の作業をコードベースにマージしても、それをフィーチャーフラグで隠せるのだ。ソフトウェアの実際の利用者には影響を与えることなく、開発を続けられる。
- これはインテグレーションプロセスをシンプルにするので、マージが後回しになっているせいで修正が遅れているバグの数を最小限にできる。
7.9 リリーストレインでリリースする
- リリーストレインとは、完成した機能のまとまり（バッチ）を、あらかじめ決められた間隔で定期的にリリースするプラクティスだ。
（定期的なリリース継続の2つの重要な効果）
- 期日に間に合わせるために期限ギリギリまで機能を詰め込もうとするストレスから解放される
- プロダクトを小さなバッチで継続的に改善できるようになる
- バッチが小さくなれば、テストやデバッグも容易になる
リリーストレインとフィーチャーフラグを組み合わせると、継続的にリリースできる実に見事な仕組みが実現する。
8章 データから学ぶ
8.3 A/Bテストで実験する
- こうした疑問に直面したとき、テック企業はどちらかを選ぶようなことはしない。どちらも試す。
9章 文化によって強くなる
9.4 核となる信念
- 慎重で思慮深い要件収集よりも、学習と実行のスピードを重視する
（エンジニアリングについての信念）
9.5 行動は言葉に勝る
- （重要なシステムを壊してしまいトライブ全体に向けて謝罪のメールを出したメンバーに対して上司がかけた言葉）
「気にしなくて大丈夫です。よくあることですから。（略）壊したのはあなたが最初ではありませんし、最後にもならないはずです。それに、あなたに壊せてしまうような本番環境だという事実は、私たちのシステムにはまだ改善の余地があることの証拠です。」- これを一片の曇りもなく伝えることができる責任者はどれだけいるだろうか...
- 自分にも多分できない（言いながら表情が濁ってしまう気がする）。。
10章 レベルを上げる：ゆきてかえりし物語
10.10 「言い訳」を取り除く
- こんな奇抜なアーキテクチャにしたのは私じゃないし。他の誰かの仕業だし。
- すでに運用中のプロダクトを引き継いで障害が起きたりすると喉元まで出かかる言葉。これを乗り越えるのが第一歩。
訳者あとがき
ポッドキャストの聴き方、よく聴いてるエンジニア向けポッドキャスト
はじめに
少し前に、聞いているポッドキャストの公開をしているブログをいくつか見かけたので、自分もよく聴いてるポッドキャストを、エンジニア向けのものを中心に書き出してみようと思う。
またその前に、改めてポッドキャストのメリットや、自分がどんな環境で聴いているのかをまとめておく。
ポッドキャスト（音声コンテンツ）のメリット
- ながらで聴ける
- が、集中度合により適する番組が変わる
- Youtubeもそうだったが、ブログなどでしか知らなかった人の話を聴けるのが新鮮。
- 「あ、こんな声だったんだ」「こんな話し方する人だったんだ」と印象が変わる・惹きつけられる体験が得られやすい。
- 「顔出しが嫌」「動画編集が面倒くさい」がないのでハードルが下がり配信しやすい
いつ聴くのか
- 家事
- 台所での食器洗いをしてる時はわりと集中して聴きやすい
- 外出時
- 特に子供と公園に行く道中、及び遊ばせている最中
ただし、どちらの場合も、家族・子供の声や周りの音がある程度聞こえるような状態にしておく配慮が必要。
そこで、使うデバイスが重要になる。
使ってるデバイス
プラットフォーム
Google Podcasts
だいたいこれで済む。鉄板。 以前はApple Podcastをなんとなく使っていたが、PCで聞いたりスマホで聞いたり、ということがあるので登録している番組と、どこまで聞いたかをデバイス間で共有できないとつらい、と思っていたところに安定のGoogle先生のサービスを発見し、以来ずっとこれ。 登録している番組の新着エピソードなどをダウンロードしておけば、外出時に便利。 ダウンロードしてオフライン再生しているにも関わらず、Googleアカウントに繋いでいるためかそこそこモバイル通信量がかかってしまうのが気になるがまぁそこは仕方ない。
Spotify
あんまり使わないが、Podcastの紹介などがあったときにリンク先がSpotifyということが結構ある。 Google Podcastsで配信されている限りはそちらで登録するが、されていない場合は仕方なくこちらで登録する。 こちらはダウンロード可。
stand.fm
スマホ限定の配信プラットフォーム。配信やコンテンツ販売が気軽にできる。 なんか若者、女性向けっぽい感じがするな...と思ったら、ライブ配信と収録配信の両方が可能ということで「TikTokの顔出さない版」みたいな位置づけを狙ってるからだと理解。 リスナーとしてはダウンロード不可のため在宅時にしか聴けない。 アプリ仕様的になんとなく感覚合わない気がするのもおっさんだからだろうか。
e.g.
- 番組一覧を表示する導線が悪い
- エピソード詳細を見ようとタップしたら即再生される
- そのせいで再生中の誤タップで違うものが再生されてしまう事故が多い
- 1つ前に再生してたものに戻る手段がない
Voicy
今日本で一番勢いがあるだろう音声プラットフォーム。 2020年から使ってるが、去年あたりから配信者（パーソナリティ）がめっちゃ増えて爆発的に伸びた感がある。 使い始めた頃はインフルエンサー中心で審査基準も厳しかったらしいが、かなり素人っぽい人も増えたので最近は少し変わったのだろうか。
Audible
...はまだ使ってない。
ポッドキャストで聞きたいエピソードに困ったら考える。
エンジニア向けの番組紹介
EM.FM
- EMによるEMのためのポッドキャスト
- 組織論の話などは当然多い
広木さんのあまりに広範な知識量と、新しい知識を既存の知識を応用して要点を掴む能力の高さにただ驚く
印象に残ったエピソード
fukabori.fm
- 技術の話、マネジメントの話が両方聞けて楽しい
インタビュー形式で気になるところを深堀りしていくスタイルで1on1のコツみたいなものも垣間見える
- が、深堀り力とまとめ能力が高すぎ
- どんだけ予習してるのというくらい理解しているインタビュアーの鏡のようなファシリ
印象に残ったエピソード
Rebuild
- 老舗の技術系ポッドキャスト。これを聴いてアニメが趣味になったエンジニア多数。
”テック担当”（実際はテックとマネジメント担当）のnaoyaさんが出演してた頃のが好き。
- Fateは観たことないがサーバントリーダーシップの話は印象に残ってる。
今だと ひげぽんさん、及川さん、川口さんあたりが出る回は比較的面白い気がする。
- 前は集中して聞きたい話題も多かったが、今はホントにラジオ代わりに流し聞くのに良い感じ
mozaic.fm
- Monthly Web として各ブラウザのアップデートの内容とその周辺の話をするのが通常回、時々テーマを絞った回がある
- あまり分からない話も多いが、流し聞きしてると勉強になる話題がいくつか拾えたりして面白い
- 最近ではMSのIEの中の人をゲスト話してた回とWeb3の回（テーマ回）がとても面白かった
engineer meeting podcast
- 現場リーダー層くらいのエンジニアが飲み屋で仕事の話をしてる感じで流し聞きに良い
- 「30代のWebエンジニアが何か喋ってたら誰かの役に立つんだじゃないかと思って始めたPodcast」だが、vol.180 40歳になってしまった そうなので話題が少し変わってきたかも？
しがないラジオ
- SIerからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ
- Web系のコミュニティからできた人脈でゲストを呼ぶところから始まったと思うが、知名度上がるに連れ大物も来る来る。
- 最近更新なし。
hidekのエンジニアと長話
- メルペイVPoEのhidekさんがゲストを呼んで雑談がてら色々聞く形式
- しがないラジオのgamiさんがアシスタントに回ってる
- これもやってたらしがないラジオまで手は回らないよなーと納得
アジャイルラジオ
- アジャイルに関する話題を数名で語る番組
- 最近聴き始めたが、音質が他と比較して少し悪いのと、ゆずっぽいノリのテーマソングを乗り越えるのに少し時間がかかった
- 音質マジで重要
- RSGT 2022の話 や チームトポロジーの話は聴いて少し参考になった（が、もうあまり覚えてない）
Voicy ITビジネスニュース
Web3.0 もとい Web3
はじめに
2021年はビットコイン、NFTなどのキーワードが一般向けのニュースにも登場し、暗号資産取引所のTVCMが流れるほど仮想通貨（やっぱり暗号資産より合ってるように思うので以降こちらで統一）が盛り上がっている。
個人的に昨年頃から仮想通貨に興味を持ったということでバイアスが働いていることは否めないが（事実、2017年の仮想通貨バブル時は全くと言ってよいほど興味がなかったのではっきり言ってバブルと気づいてすらなかった）、仮想通貨のことはもちろん、エンジニアの端くれとしてブロックチェーンそのものの知識をもっと学びたいと思い、ちょいちょいニュースを拾ったり、いくつかのYoutubeで情報収集をしているので、学んだことについて時々メモとしてアウトプットすることで知識定着をさせたい。
・・・と言いつつ、この記事自体会社の勉強会ネタの下書きとして書いてから80日以上寝かせてしまって今に至る。。
寝かせている間にいつの間にかWeb3.0、というかWeb3がめっちゃバズワード化していて、今この記事を上げると完全に乗っかっただけにしか見えないという始末。まぁ自業自得なのだけれど。 とはいえこのまま寝かせるのはあまりにもったいないのできちんと晒すことにする。
ブロックチェーンというよりWeb3.0
仮想通貨やブロックチェーンのことを学び始めると、Web3.0というキーワードを目にする。 ブロックチェーンのことに興味がなくても、IT業界に関わる人間にはピクっとする言い回しだろう。 Web3.0と聞いて当然のように想起されるWeb1.0やWeb2.0を含めて、Web3.0とは何かを解説されている記事は数多あるが、この記事でも10分程度で人に説明できる程度の内容にすることを目的にまとめてみたいと思う。
【前提】Web1.0、Web2.0 とは
Web1.0
Web2.0という言葉ができてから勝手にそれまでの時代を1.0と命名されてしまい、どんな時代だったかを後付けされた格好だが、一般的には ティム・バーナーズ=リー によって考案されたワールドワイドウェブが始まった1989年から2000年代初期までの、インターネット黎明期におけるウェブ構造をWeb1.0と呼んでいる。
特徴としては以下のようなところ。
- HTMLのみのシンプルな静的サイト（「ホームページ」）
- 一方向性の発信であり、利用者にとってはRead Only
- ダイヤルアップ接続による低速サーフィン （ピーーーーーガーーーーー）
特に最初の方は一部の人の趣味の領域にとどまっていた時期が長かったように思う。
ちなみに、ティム・バーナーズ=リーが以下のように考えていたことは改めて興味深い。
彼は初期のウェブコミュニティを「分散型（Decentralisation）」、「無差別（Non-discrimination）」、「ボトムアップ設計（Bottom-up design）」および「普遍性（Universality）」などと形容しており、「ウェブ上の投稿にはいかなる中央組織の許可も要らず、（中略）見境のない検閲および監視からの開放を意味している」述べています。
（Web3.0で何が変わる？ ブロックチェーン技術が実現させる新しいインターネット より）
Web2.0
今もなお続いている現代のインターネットがこの状態。2005年にティム・オライリー（Tim O'Reilly）によって提唱され、言葉としては2年ほど流行った。
↓日本語訳
特徴は上記日本語訳記事中にある、この"ミーム・マップ"と呼ばれるものに全て詰め込まれているが、
おそらく当時をよく知っている人でもその頃は表面的な理解しかできなかったのではないかと思うが（自分もそう）、今1になって改めて眺めると未来予想図を振り返るようで面白い。 「単一デバイスの枠を超えたソフトウェア」「データは次世代のインテル・インサイド」などは2005年当時に明言しているは凄い。
「ソフトウェア・リリースサイクルの終焉」で言及されているソフトウェアがモノではなくサービスとして常にアップデートされ続けるという概念については、SaaSが普及してコンシューマ向けゲームでさえアップデートされ続けるのが普通となる現状を見ると、「永遠のベータ版」という言葉が死語になったとはいえ、なるほどよく言い当てられている。
ただ、SaaSを提供している企業の開発現場からすれば、リリースサイクルはなくなったどころか短期化されてより厳しくなったという方が正しい。
既に成熟されていると言っても良い、Web2.0がどんな時代であるかを挙げるならこんなところ。
余談
ティム・オライリーが提唱してから約1年半後（遅い）の2007年4月に DoCoMo2.0 という広告が登場して以降、2.0、いや x.0 という数字が完全にキャッチコピー化していろんなところで使われるようになった。
この「なんとか2.0」ブームもとうの昔に下火になったかと思っていたが、こんなまとめもあり結構最近まで乱用されていたのだなぁというのを再認識。
Web2.0での課題
Web2.0によってインターネットは社会のインフラになり、シームレスに生活に浸透したといえる。しかし、Web1.0時代にはなかった問題が現実社会に投げかけられることになる。
Web3.0で何が変わる？ ブロックチェーン技術が実現させる新しいインターネット にあった以下3点を取り上げる。
個人情報・プライバシー問題
個人情報がGAFAMなどのプラットフォーマーに集中し、年齢・性別・職業などの基本属性はもちろん、友人関係や個人の興味・嗜好などのデータが蓄積され、分析・売買されてこれら巨大企業の収益の源泉となってきた。これはGoogleやFacebookを始めとして多くのWebサービスが無料で利用できる背景ともなっているわけだが、言い換えると個人情報を対価として支払っているということである。
もちろん、マーケティング利用としての分析・売買は基本的に個人の識別などできない状態にして統計的に処理するのが一般的なので、たとえターゲティング広告に追われていても心配をする必要などないのだが、政治利用されているという事実がこの問題の深刻度を物語る。
例）
- スノーデン事件（2013年6月）
- ケンブリッジ・アナリティカ問題（2018年）
そもそも、大手プラットフォーマーは望んでいなくてもその国の政府に協力しているのが当然と考えるべきである。
単一障害点
AWSやGCPなどのIaaSを使うことで一般企業にも耐障害性の高いシステムを構築するのは一昔前と比べて遥かに容易に、低コストで実現できるようになり、大抵のSaaSプラットフォーマーのインフラもIaaSで構築されるのが普通になった。
ただ、自前で構築するのに比べたらもちろん耐障害性は高いはずだが、IaaSやSaaSプラットフォーマーに依存している企業が多ければ多いほど、そのプラットフォーマー自身がサービス障害を起こした場合のビジネス・社会への影響が甚大であることが浮き彫りになる。
また、ある日突然そのプラットフォームでアカウントが停止された場合、単なる障害対応では済まない。 ビジネスの場合の深刻さも容易に想像しうるが、個人としてもGoogleアカウントをBANされたら本当に困るし、ハックされてアカウントデータが流出した、と言われたら青ざめる人は大量にいる。
ネット検閲
ここはそのまま引用させてもらうと、
インターネットが中央集権的で、一部の組織によって管理されているということは、その中央組織の承認がなければ、インターネット上での活動に制限が生まれ#しまうということを意味しています。例えば、あるSNS運営企業が、自社プラットフォームに書き込める内容に制限を設けた場合や、国や政府が閲覧できるウェブサイトを限定した場合、それは表現の自由に抵触する可能性もあります。
実際21年1月にトランプ元大統領のTwitterアカウントが永久凍結された際には、これはTwitter社による人権侵害であるという主張と、特に元大統領の発言を危険とみなした場合、Twitter社が利益追求のために元大統領のアカウントを永久停止するのは当然の権利だという主張が対立し、議論が巻き起こっています。
(Web3.0で何が変わる？ ブロックチェーン技術が実現させる新しいインターネット より)
これらの問題の根幹は共通しており、Web2.0が「中央集権型のWeb」であることに他ならない。
ではWeb3.0とは
こうした課題を受けて、ではWeb3.0とはどんなものなのか？
手っ取り早い概要理解はこちら
以下の動画（（5つに分割されているが、1〜3あたりまでが特に参考になる））がすごくわかりやすいので、これを観るだけでいいかも。
自分のための説明
Web3.0の明確な定義はないが、以下、Web3.0で何が変わる？ ブロックチェーン技術が実現させる新しいインターネット にまとまっているものをもとに紹介する。
Web3.0は先述したWeb2.0のデータ関連の課題を解決するものとして構想された。
中央集権型であるWeb2.0に対し、Web3.0は非中央集権型で自己主権型のWebであるとされる。
(出典：Web3.0で何が変わる？ ブロックチェーン技術が実現させる新しいインターネット ※画像の著作権は Fracton Ventures株式会社))
インターネットはもともとデータを管理（管理＝状態管理、検証）するようにはデザインされておらず、あくまでやりとりを前提としていたものだったため、複製・改ざんなどにより検証できなかったり、中央管理組織によって管理する必要があったりした。
これが、ブロックチェーンなどの分散型技術によってインターネットに検証可能性という特性を持たせることができ、中央管理組織を介する必要がなくなるというのがWeb3.0で実現される世界観である。
(出典：Web3.0で何が変わる？ ブロックチェーン技術が実現させる新しいインターネット ※画像の著作権は Fracton Ventures株式会社))
Web3がもたらすもの
Web3.0では、以下のような利点が得られる。
- ユーザー自身がデータ所有権を掌握
- 単一の中央管理者が存在していないため、ユーザーが自身のデータ管理権を掌握でき、データがユーザーの許可なく利用されることがない
- P2P取引による仲介組織の排除
- 単一障害点の排除
- 分散的な方法でネットワークが構成されてることで技術的により堅牢なシステムになる
- ビットコインは2009年1月3日に運用開始されてから今まで停止したことがない
- 検閲耐性
- いかなる組織及び機関の承認なしに誰でも参加可能
- 検閲・制限する組織も存在しないため地理的条件や思想などで差別されず利用可能
Web3.0のトレンド
Web3.0領域ではいくつかの大きなトレンドが起きている。
特に前者2つについては2020-2021年に大きく盛り上がりを見せており、ニュース記事等で目にした方も多いことと思う。
※ スマート・コントラクト ある契約・取引について「特定の条件が満たされた場合に、決められた処理が自動的に実行される」といった、契約履行管理の自動化を指す
Web3.0のプロジェクト・組織
Web3.0を実現するべく取り組んでいるプロジェクトは数多あり、どんな分野があるのかを把握するのすら大変。 こちらは少し古いカオスマップ（2018年）。
https://medium.com/cryptoage/%E3%81%AA%E3%81%9C%E5%B7%A8%E5%A4%A7%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%BC%E3%83%8D%E3%83%83%E3%83%88%E4%BC%81%E6%A5%AD%E3%81%AFweb3-0%E3%82%92%E6%81%90%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%81%AE%E3%81%8B-35d849fa1300medium.com
いろんなプロジェクトがあるが、まずは Web3 Foundation という組織があることを知っておいた方がよいか。
- Web3 Foundation
- 分散型ウェブ用アプリケーション開発を促進する世界最大級のブロックチェーン財団
その他、Technical分野で見ていきたいところ。
- Ethereum
- IPFS（InterPlanetary File System）
- ICP（Internet Computer Protocol）
- 世界中の独立したデータセンターから提供される計算リソースを使って分散型”インターネット・コンピューター”を作りAWSやGCPのような特定企業のクラウドコンピューティングサービスからの脱却を目指す
所感
Web3.0という言葉を最初に聞いたときは2.0のマーケティング的な使われ方を連想して十中八九バズワードだろうと想像していたが、すごくしっかりした、かつ妄想ではない現在進行系の未来予想図を積極的に実現しようという取り組みだった。
この分野は新しい用語、技術が多く、覚えるのが非常に大変だが、動きが活発で面白い。 個人的にはこれまで巨人の肩に乗っかってきたコンピューティングリソースが、Web3.0でどういう形で確保されるようになっていくのかなどに興味があるので、上に挙げたプロジェクトについては今後もう少し理解したい。
参考にしたもの、なりそうなもの
https://prsarahevans.com/page-548/web-3-0-2/prsarahevans.com
「アジャイルなチームをつくる ふりかえり ガイドブック」を読んだ
少し前に読んだ本のメモ。
動機
- チームで開催されるスプリントレトロスペクティブ（以下、レトロ）に何となく参加してる気がする
- レトロというよりKPTに参加している気がする
- レトロの目的・進め方を自分はちゃんとわかっているのか
- ふりかえりをすべきとよく言われるが、何ができりゃいいのか
- KPT以外にも色々やり方があるらしい、興味があった
一言で言えば、「よく分からず惰性でふりかえっていた」ので、少し学んでみたいと思っていたところ、ニーズど真ん中の本が出たのでポチった。
（白状すると、発売後すぐではなく、Kindleの半額セールに入るのを今か今かと待ってポチった）
読んだ本
また、この本の著者がQiitaにめっちゃふりかえりの記事書いてるのでそのあたりも参考になる。
ところでなぜ「ふりかえり」？
なお、アジャイル開発で用いられることが多い中、なぜ「レトロスペクティブ」でもなく「振り返り」でもなく「ふりかえり」なのだろうと思って本を読み始めたところ、途中の解説コラムで以下の様に説明されていた。
- 「振り返り」＝「後ろを振り向く」という動作や「反省会」のようなイメージを払拭し、やわらかい印象を与えるためにひらがなで表記
- ふりかえりを専門的な難しい活動だと思われてしまうこともあるため、誰でもできる活動だということを知ってほしいという著者の思い
確かに「レトロスペクティブ」と表記されたら非アジャイル勢には敷居が高いし、ふりかえり自体はウォータフォールだろうと営業だろうと製造業でも学生の集まりでもできる。なるほど。
ということで、この記事でもひらがなで「ふりかえり」と表記することにしている。
ふりかえりのあれこれ
ふりかえりの目的
今回読んだ本ではふりかえりの大きな目的を「チームを『アジャイルなチーム』へ近づけていくこと」とした上で、以下3つの段階的な目的を定義している。
立ち止まる
- 心と時間の余裕が無いときほど場当たり的な対応になる、一人ひとりの視野が狭くなる、チーム内コミュニケーションが希薄になるなど負の循環が続くので強制的に立ち止まれる時間を設ける
チームの成長を加速させる
- 成果を出し続けられるパフォーマンスの高いチームは、日々のコミュニケーション（会話・議論・情報共有）と コラボレーション（協調作業）が自然に行われている
- 朝会やふりかえりなどの会議イベントが無くても毎時・毎分・毎秒という高い頻度で必要十分なコミュニケーションとコラボレーションが取れるようにする
- お互いのことを知ることが重要なので、価値観を共有するワークをするのもよい
- 信頼関係を高めるために、感謝を伝え合ったり、抱いている不安を開示し合ったりするのも効果的
プロセスをカイゼンする
- うまくいっていない部分や問題の解決に加え、うまくいっている部分をより強化していく活動
- これが3番目なのは、チームの信頼関係が十分に構築されている状態でプロセスを変えようとするのを避けるため
- 問題発生時に原因責任の追求が行われてしまい問題を隠す行動に繋がる
- チームの信頼関係が高まっている状態であれば「チームとしてのアクション」へと考えがシフトしやすくなる
手法とやり方だけを真似して「手法を行うこと」が目的となってしまい、何のためにふりかえりをするのかが見えなくなってしまうと、ふりかえり自体が行われなくなってしまうことにも繋がる。 効果が実感できなくなったときなど、一度目的に立ち戻ると良い。
手法
KPT
言わずもがな、Keep, Problem, Try の3つの質問に答えることで、次のアクションを決めるためのフレームワーク。
- Keep：「よかったこと、つづけること」
- Problem：「問題、課題」
- Try：「トライ（次に行うこと）」
が、やっていると気づくのが「Keep少ないなぁ、Problemばっかりだなぁ」ということ。 KPTが悪いわけじゃないのだけど、負の側面に焦点が当たりがちなので、もっとポジティブな雰囲気が勝るふりかえりができないものだろうか、と。
その場合はYWTを試すと良いのかもしれない。
YWT
Y（やったこと）、W（わかったこと）、T（次にやること）のローマ字の頭文字を取ったふりかえり手法。
- やったこと＝事実、経験
- わかったこと＝解釈、学び、気づき
- 次にやること＝アクション
WはKPTのPのようなネガティブイメージがないため、前向きな議論に繋がる気がする。 また、Wは他のメンバーの「やったこと」「わかったこと」を元に色々な意見を加えていくと良い。
ちなみに、YWTはポジティブな言い方をしただけかと思っていたが、そもそもKPTで陥りやすい「Keepの前に何が起こったのかを思い出す」のを最初に行うようにできる手法とも言える。KPTの良い回し方も含めて↓は大変参考になる。
DPA
ふりかえりのルールを全員で作る手法。 - どんな雰囲気でふりかえりを進めたいか - その雰囲気を作り出すために何をするか
この2点について意見を共有し全員が合意できるものを選ぶ。 チームメンバー入れ替わりのタイミングや、1−3ヶ月くらいでルールを作り直すと良い。
タイムライン
チームに起こった事実と感情を両方合わせて書き出して全員で共有するための手法。 付箋を2色用意し、ポジティブな出来事とネガティブな出来事で分けて記入していく。
質問の輪
チームが輪になって1人ずつ「あなたは、私達が次に取り組むべきことは何だと思いますか」という質問に答えていく。2周以上（必要に応じて3周、4周）行う。
信号機
現在の心境を信号機の色に見立てて表明する手法。 ドットシールを使って、ふりかえりの最初と最後に心境を信号機の3色で表す。 チームの心理的な健康状態を知ったり、ふりかえりの効果を実感するのに有効。
その他
著者の作成されたスライドに「ふりかえりカタログ」として70もの手法が紹介されている（随時追加されているとのこと）
なお、紹介されている手法は組み合わせて使うものなので、チームの状態やふりかえりの目的に合わせてどれを組み合わせるか、というテンプレのような紹介も書籍ではされている。
印象に残ったところ、参考になりそうなところ
感情表現
手法を見ているとやったことや気付きを書く際に必ず「どう思ったか」を書くようなものが多い。ふりかえりの目的を踏まえると合点がいく。
まずはプラスに目を向ける
一度マイナスを見つけるモードに入ると、プラスを見つけるのが難しくなる。禿同。 意見が出にくくなっている状態の打開策としても使える。
主語は「チーム」
アクションのアイデアなどを考える際の最初の主語は「チーム」
小さいアクションにする
大きなアクションにすると実行されない
ふりかえりのふりかえり
毎回のふりかえりの最後に、ふりかえりのふりかえりをして次回以降のふりかえりに活かす。この活動が抜け落ちるとふりかえりが徐々にチームの現状に合わないものになっていき、ふりかえりが形骸化していく。
問題が出てこないのは良いのか悪いのか
問題が全然出てこない場合にそこはかとない不安を感じる場合があるが、それは問題なのか？ 本書によると、問題が無いのは本来素晴らしいことなのでまずは全員で祝いましょう、とのこと。 そして上手く行っている部分をより伸ばすことを検討する。 それでも毎回ふりかえりの際に問題が出ないことに違和感があれば、チームの理想像を話し合ってみて理想と現状のギャップを確認してみるというのも勧められていた。
まとめ
ふりかえりを何となくやっている、ふりかえりをしているというよりKPTをしている、という心当たりがあれば本書で紹介されている手法やその組み合わせ、進め方などを参考にして「ふりかえりのふりかえり」をしたい。
参考にしたもの、なりそうなもの
https://www.kikakulabo.com/tpl-reflection/www.kikakulabo.com
