生成AIによって広く浅くでも知識を持つことの価値が高まっているなと思った話

先日、とある時に「自分の知識の引き出しが多いと、AIの可能性が広がるな」と思った話。

その時は判定ロジックのようなものを求めたのだが、普段だったらそのまま「〇〇のような判定ロジックを作ってください」と指示を出していた。だけども直近で自然言語処理について勉強していたので、ふとこの判定ロジックも自然言語処理だと思い「ルールベースの自然言語処理として実装してください。inputは〇〇でoutputは△△のtaskになります。」のように指示を出してみた。

結果としては、ゆらぎをある程度考慮したり、スコア計算をしたり、閾値をいじれるようになっていたりと、自分ではパッと出てこない実装がパッと出てきて驚いた。

AIは広く深く物事を知っている。でもその膨大な知識の引き出しを開けるのは、今のところ人間の役割なのだ。もちろんAIエージェントが自分で引き出しを開けることもある。でも、いい引き出しに当たるかどうかはわからない。ガチャみたいなものだ。

一方でなにかとっかかりのようなものがあれば、その知識を深く知らなくてもAIの引き出しを確実に開けることができる。ハルシネーションの可能性もあるし、出てきたものに対する責任は当然負う必要がある。浅い知識のまま、すべてを鵜呑みにすることはできない。また、具体的にしてしまうことで他の可能性の選択肢を消してしまっているかもしれない。だとしても、AIの知識の引き出しを確実にあけられるメリットは大きい。そして、その引き出しの鍵をたくさん持っていることは、むしろ可能性を広げているのではないだろうか、とも思う。

これだけAIが進化したからこそ、いろんな領域の基礎を習得することにとても価値が出てきそうだと思った。

生成AIによって勉強が楽しくなっているなと思った話

先日、社内で「自然言語処理の教科書」という本の輪読会が開催され、参加してみた。

日頃から生成AIを使うようにはなっているが、その裏側がどうなっているのかというのはあまり理解ができていないので、興味が湧き参加した。

まだ序盤も序盤で、「言語処理とは？」みたいな章で、難しい数式も出てきていないが、それでも専門用語が多くて難しかった。

その場でも質疑応答などが行われ、大変勉強になったのだが、帰り道の電車の中で「あれってこういうことかな？」という風に自分の中で考えが咀嚼されてきたので、Claudeにいろいろ尋ねてみた。

「自分の中でこういう風に理解をしたのだけど、あっているのかな」ということを、いつでも聞ける。どれだけ雑でも聞ける。これはすごいことだ。

ハルシネーションのリスクがあるとしても、理解を深めるのにこれだけ有用なことはない。

自分の理解をLLMに伝えるために文章にする。まず、この時点で「考える」必要があり、これだけでも価値がある。ブログに書くのと同じ。書くことは考えなければできない。

そして、その考えに対して、意見をくれる者がいる。「そういうことか」となる。「つまり、こういうこと？」となる。どんどん考えが深まる。

更にいいのは、このチャットでやり取りした内容は、結構長期記憶に残りやすいのだ。「書くこと」と「読むこと」は、脳みその別の部分を使う。いろんな脳みそを使った方が長期記憶に残りやすいということを、以前に本で読んだことがある。

そしてなにより、このやり取り、楽しいのである。いい時代だ。

「GitLabに学ぶ - パフォーマンスを最大化させるドキュメンテーション技術」を読んだ

なぜ読んだか

最近、技術的な仕様をまとめる機会が多く、もっとわかりやすくドキュメント化できないだろうかと悩んでいた。

この本の前のシリーズに当たる本も読んでおり、「かすれたインクは鮮明な記憶に勝る」という金言を得ていたこともあり、読んでみようと思った。

GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術 数千ページにもわたるハンドブックを活用したテキストコミュニケーションの作法

ただのテクニック集ではなかった

最初に書いたように、わかりやすいライティングの技術が学べる本だと思い手に取ったが、読み進めていくと、どうもそうではなさそうだということがわかった。

小手先のテクニックではなく、下記のような、ドキュメントとの向き合い方を根本から考え直すきっかけを与えてくれる本だった。

• なぜ、ドキュメントに価値があるのか
• 価値のあるドキュメントを作っていくための考え方

プロセス・ロスを減らすドキュメントの力

複数の人間が集まって作業をすることになったとき、パフォーマンスに非効率が生じることを「プロセス・ロス」と言う。ドキュメントにはこのプロセス・ロスを減らす力がある。

人員を増やした割には、さほど成果が変わっていなかったりする原因は、このプロセス・ロスにある。

「互いが互いのタスクだと思って、宙ぶらりんになってしまう」みたいなのもプロセス・ロス。
「Aという方法を進めなければいけなかったのに、正しく問題を理解できていなくてBという方法で進めてしまった」みたいなのもプロセス・ロス。

こうやって挙げていくと多分キリがない。ちょっと考えただけでも、普段の仕事の中にプロセス・ロスはたくさん見つかる気がする。

人間同士がわかりあうことは、難しい

プロセス・ロスが生まれる原因は、つまるところ「認識の食い違い」である。

• 人それぞれが持っているコンテキストの違い
• バイアス

こういったものが複雑に絡み合って、認識の食い違いが生じてしまうと、本書は説いている。

このように整理すると、人間同士がわかりあうことは、非常に難易度が高い問題であるかのように感じます。P.77

この問題を乗り越えるものがドキュメントである、ということなのだが、まずは「非常に難易度が高い問題」だ、ということをちゃんと認識することが大事な気がする。難しいんだ。

共有された現実をつくる

ものごとには、各自が捉えている現実があり、人それぞれ考えが違うことは当たり前である。だから、認識が食い違う。

各自が捉えている現実を、言語化して共有し、共通認識としてドキュメントにまとめる。つまり、ドキュメントに書いてあることは、「共有された現実」なのだ。

この「共有された現実」を積極的に作っていきたい。

自分が考えていることと、あなたが考えていることは、同じかもしれないし、違うかもしれない。これは、現実を共有しない限りわからない。

「共有された現実」をドキュメントに書くことで、お互いの考えがはっきりとわかる。しかも、ドキュメントに書いてあるおかげで、いつでも、だれでも、「共有された現実」を観測することができるようになる。

すべては下書きである

もう一つ、心に残った考え方が「すべては下書きである」というもの。

要は、完璧なドキュメントなんてものは存在しないのだから、どんどん作って、どんどん公開して、どんどん改善していこうぜ、という考え方。

些細な内容でも恥ずかしがらずに、まずはたたき台を作成し、それをオープンにすることで多様な視点を活用しながらドキュメントを育てていく P.179

うまくまとまめられないな、と思っても別にいい。とにかく書く。書くことが大事。書け。

テキストコミュニケーションの難しさ

ライティングの話に付随して、テキストコミュニケーションの難しさについても言及しており、この点も非常に参考になった。

テキストコミュニケーションは、オフラインのコミュニケーションに比べて、声のトーンや表情などの情報が削ぎ落とされている。情報が欠落しているコミュニケーション方法である、ということをしっかりと認識する。

テキストコミュニーケーションは人を傷つけやすい P.31

そして、感謝を伝えることを忘れない。

沈黙や無視は特に何の感情もないと言うメッセージではなく、意図せずに攻撃のメッセージを与えてしまうことすらあります P.158

リモートでの働きが当たり前になったからこそ、大事にしたい部分である。

読み終えて

もちろん、ライティングスキルとして「事実と意見を区別して書く」とか「曖昧さを回避する」とか、テキストを書く上で有効なテクニックの内容も書いてあった。

けれども、そういったテクニックの話よりも、なぜドキュメントを書くのか、という思想に触れることができたのが、とても良かった。

まずは気軽に。下書きだと思って、ドキュメントをまとめ、共有された現実をつくっていきたい。

「岩田さん」を読んだ（1年ぶり3回目）

今年はなるべく本をたくさん読みたいと思っており、新年最初の読書はなににしようかなと考えたけど、やっぱり「岩田さん」かなと思って、3回目の「岩田さん」を読んだ。

岩田さん: 岩田聡はこんなことを話していた。 (ほぼ日ブックス)

人を一番大事にしていた

岩田さんと言えば、MOTHER2のときの作り直しや、「プログラマーはノーと言ってはいけないんです」というような、エンジニアとしてのエピソードが強く印象に残りがちなんだけど、この本に書いてあることは、終始「人と人が働くということはどういうことか」に尽きるような気がする。

例えば、会社の中に評価などの軸を共通認識として持つことが必要だ、と語っている中で、岩田さんはこう言っている。

会社という組織の中でも、みんな、都合よく、自分の得意なことと、人の不得意なことをつい比較してしまう。P.46

だからこそ、軸がないと「不公平」という不満が生まれてしまう。その通りすぎて、うんうんと頷いてしまった。

また、もっと根本的な「働く」ということに対しても、自分が大好きな岩田さんの一節がある。

考えようによっては、仕事って、おもしろくないことだらけなんですけど、おもしろさを見つけることのおもしろさに目覚めると、ほとんどなんでもおもしろいんです。P.58

自分も、仲間も、お客さんも、みんながハッピーであることを願っていた岩田さんは、そもそも自分をハッピーにする術に長けていた。自分がハッピーじゃないと、一緒に働く仲間もハッピーにはなれないから。

岩田さんが人とコミュニケーションを取るうえで、絶対に他人を責めない、という考え方も、人と人が働く上では本当に大事なことなんじゃないかと思う。

プログラムの世界は、理詰めです。だから、もしも完動しないとしたら、原因は全部、プログラムしたこっちにある。わたしは、人と人とのコミュニケーションにおいても、うまく伝わらなかったらその人を責めずに、自分の側に原因を探すんです。コミュニケーションがうまくいかないときに、絶対に人のせいにしない。P.84

良いゲームをつくるためには、良いチームが必要で。そのためには、組織というものがどうあるべきか。自分がどう立ち回るべきか。その人の得意なことは何で、不得意なことは何か。人というものにフォーカスをあてて、岩田さんは働いていたんだなと感じた。

糸井さんに語った仕事観

岩田さんが、ほぼ日（ほぼ日刊イトイ新聞）の糸井さんに仕事観を語ったエピソードがあり、その内容が自分はとっても好き。

自分は、ほかの人がよろこんでくれるのがうれしくて仕事をしている。（中略）まわりの人がしあわせそうになるのが自分のエネルギーなんです P.119

それに対して、糸井さんが「オレもそうだ」と答える。

自分も声を大にして「オレもそうだ」と言いたい。

「できるんだ」っていう希望を与えられる存在

MOTHER2の開発がうまく進んでいないところに、岩田さんがやってきて、ものごとがうまく回りだすようになった。

そのことを糸井さんが、「希望を与えてくれた」と表現したことが、とっても印象に残っている。

そういうふうにうまく回りだしたのは、大きくいえばやっぱり、岩田さんがぼくらに希望を与えてくれたからですよね。「できるんだ」っていうね。P.195

自分は、こんなふうに希望を与えられる存在になっているだろうか。
「プログラマーはノーと言ってはいけないんです」というのは、希望を与えられる存在になれ、というメッセージだと思った。

3回目を読み終えて

やっぱり、何度読んでも素晴らしいなと思った。岩田さんの言葉に、救われるような感覚を、何度読んでも抱くのは、それだけ岩田さんが素晴らしい人だったということだろう。

自分は一時期、ほぼ日で働いていたことがある。岩田さんが亡くなった後だったので、岩田さんに会うことはできなかった。

だけど、糸井さんと働いたことはあるので、この本の中にいる岩田さんのいろんなところに、糸井さんの面影を感じた。あ、これは、糸井さんから学んで岩田さんが実践しているんじゃないかな、とか。あくまでも、自分の憶測だけれども。

岩田さんは、そんなふうに周りからどんどん自分の中に取り込んでいって、どんどん変わっていかれたんだじゃないかなと思った。

自分も、岩田さんを読んで、岩田さんをどんどん取り込んでいきたい。なかなか難しいところもあるけれど。忘れてしまわないように、きっと4回目を読む日がすぐに来ると思う。

MTGの最初にはゴールを宣言する

MTGとは恐ろしい生き物で、すぐにあっちにいったりこっちにいったりする。

なので、MTGの最初に必ずゴールを宣言することを意識していきたい。

「このMTGのゴールを最初にお伝えします！〇〇について自分が疑問を抱いていることを伝え、その疑問を解消するためのアクションと担当者を決めきることです。」

みたいな。

ゴールを意識しながらMTGをしたい

最初にゴールを宣言すると、こんないいことがあるのではなかろうか。

• 進むべき方向が明確になるので、今話している議論がゴールに向かっているのか、別の方向に向かってしまっているのか、判断がしやすい
  • 「今その議論はしなくてもいいはずなので、それは別の時間を取りましょう。まずは〇〇について話したいです。」
• 進むべき距離が明確になるので、時間配分も意識しやすい
  • 「ここまでは決めてしまいたいので、一旦今の議論をまとめて、次の議題にいきましょう。」
• MTGが終わったときに、ゴールに到達できたか振り返りができる
  • 「決めきれていないアクションはありませんか？自分の担当を把握できていない人はいませんか？」

結果を意識してゴールを設定する

MTGで設定するゴールは「説明をした結果、どうなっていてほしいのか」というものにしたい。

「このMTGのゴールを最初にお伝えします！〇〇という機能について説明をし、正しく理解してもらうこと。そして、運用のイメージを抱いてもらうことです。」

みたいな。

そうすれば、MTGが終わったときに「運用イメージを抱けているかどうか」の判断ができる。ゴールに到達できたのか、できなかったのか。

まとめ

あれ、OKRの話と一緒じゃないかこれ。MTGのOKRを設定しようということなのかもしれない。

「どうなっていてほしいのか」のゴールがObjectives（目標）で、それを判断するためのKeyResults（主要な結果）を設定してMTGをすれば、MTG終わりに目標達成したのかがわかるよね。

そういえば「Measure What Matters」の冒頭でも、OKRを説明するプレゼンに対してOKRを設定していた気がする。

tanihiro.hatenablog.com

OKRの本「Measure What Matters」を読んだら、OKRもアジャイルであることを学んだ

なぜ読んだか

XでフォローしているいくおさんというEMの方の考え方がとても好きで、その方がOKRを実践しており、OKRについて学ぶならこの本だと紹介していたので、読んでみようと思った。

Measure What Matters（メジャー・ホワット・マターズ） 伝説のベンチャー投資家がGoogleに教えた成功手法 OKR (日本経済新聞出版)

OKRとは

OKRとは、「Objectives and Key Results」の略称で、目標設定のフレームワーク。

• Objectivesは目標を指し、「何を」達成すべきかを表したもの
• KeyResultsは主要な結果を指し、「どのように」達成しつつあるかをモニタリングする指標

Objectivesで掲げた目標に対して、測る指標（KeyResults）をいくつか設定したものがOKRである。逆に言えば、その指標をすべて満たせば、目標を達成できたと言えるものでなければいけない。

主要な結果

主要な結果は、曖昧なものではなく、明確に定義する必要がある。「満たしているか」「満たしていないか」をはっきりと判断できるもの。

例えば「〇〇を改善する」という主要な結果はとても曖昧である。改善したのか、していないのかの判断がとても難しい。それよりも「〇〇を××%向上させる」という方が、達成の判断は明確に行える。

OKRがもたらすもの

OKRはただの目標設定の話だと思っていたのだけど、読み進めていくとそれだけではないことがわかった。 OKRがどういう効果を発揮するのか。自分の理解をまとめてみる。

フォーカスし、コミットする

OKRは無尽蔵に設定すればいいものではない。リソースは限られているので、無尽蔵に設定したところで、主要な結果を満たすことはできず、どの目標も達成できなくなってしまう。

だから、まずなにからやるべきなのかということを明確にしないと、そもそもOKRを設定できない。これはつまり、今なにをやるべきではないかということを明確にすることでもある。

この四半期で最も優先すべきことはなにか。なぜ、それを優先すべきなのか。 限られたリソースをどこにフォーカスし、コミットさせるのか。

OKRを設定すると、必然的にこの問いに対しての解を得る必要がある。

アラインメントと連携

OKRは設定したら、公開する。公開することが大事であり、透明性が何より重要である。

会社全体のOKRが公開されたら、メンバーは自分たちのOKRを設定する。
当然、自分たちのOKRは会社全体のOKRと結びつかなければいけない。全く関係ないOKRを設定していたら、「なぜこのOKRにしたんだ？」と突っ込みが入る。

会社のメンバーが、会社の目標と結びついた活動を日々行えるようにすることが、アラインメントである。

アラインメントとは突き詰めると、社員に会社は何を期待しているかをわからせることだ。 P.143

そして、この個人が設定したOKRも当然公開する。これはつまり、隣の席の人間のOKRも、別の部署の管理職のOKRも、公開されているので知ることができるということ。

自分以外の人間がどういう目標を定めているのか。その目標を達成するために、どういう主要な結果を設定しているのか。それを知っているからこそ、連携という協力体制がうまれる。

あの人のOKRを達成するためには、自分がこういう動きをした方がいいのではないか。

透明性を持ったOKRは、全員の進むべき方向を定め、全員が目標を達成できるために連携を促す。OKRを設定するだけでは効果を発揮しない。公開して、誰もがアクセスできるようにすることが大事である。

トラッキングし、適合する

OKRに定めた主要な結果は、測定可能なものであるため、日々進捗を追いかけることができる。設定して、期日が来たから振り返る、ということではない。常に、今のOKRの進捗率を測ることができる。

だからこそ、OKRの進捗率を可視化できるツールなどを導入する。

そして、進捗を日々トラッキングし、必要であればOKRを調整する。なぜなら、進捗が悪いということは、そもそものOKRの設定がよくなかった、という可能性があるからだ。

OKRは基本的により多くを達成するポジティブなツールだが、間違った方向に進むのを止める効果もある。 P.176

期日がきたら、OKRをどれだけ達成できたかを採点し、次に活かすための振り返りをすることも重要だ。

ただ、採点は少し難しい。主要な結果をすべて達成できたからといって、良い点数をつけていいとは限らない。幸運な要素が重なって、たまたま主要な結果を達成できただけなのかもしれない。主要な結果はあくまでも客観的なデータとして、そこに目標設定者の主観を混ぜて採点することが大事である。

そして振り返り、次のOKRに活かしていく。

• 目標はすべて達成したか。そうだとすれば成功要因は何か。
• 達成した場合、どのような障害があったのか。
• 完全に達成できた目標を書き直すとしたら、どこを変えるのか。
• 次のOKRサイクルへの取り組み方を変えるような学びはあったか。

P.185

コミットする目標と野心的な目標

OKRを設定するときに、達成することが困難と思われるとても高い目標を設定すると、ものすごいパフォーマンスが生まれることがある。

高い目標を建てたからこそ、その頂に登る方法を考え、登ることができる。そもそも高い目標がなければ、絶対にその頂に到達することはできない。

ただ、設定したOKRがすべて高すぎる目標だと、どの目標も達成することができずただただ疲弊してしまう。

完全に達成するべきコミットする目標と、達成がとても困難な野心的な目標の2つのカテゴリのOKRを区別し、適切なバランスで設定できると、最高のパフォーマンスが生まれる可能性が高まる。

無難なOKRを設定しただけでは、無難な成長しか遂げることができない。

読んでみて

読む前は、OKRという言葉は、目標と主要な結果をただ組み合わせたもので、その設定の仕方のノウハウが学べるものだと思っていた。

だけど、OKRは設定したものをどう運用していくかがとても重要で、その運用は、組織というものをどう強いものにしていくのか、という点にすべて繋がっていた。

• 組織のリソースをどのように有効活用するのか
• 組織の垂直の構造でどうやって同じ方向を向くのか
• 組織の水平の構造でどうやって連携するのか

それができれば、どんどん強い組織になっていく。サイクルの中で振り返りをし、さらに改善していく。どんどん強くなっていく。

これは、目標版のアジャイルなんだと思った。スクラムと考え方が似ている。目標設定も最初はうまくいかないかもしれない。でもOKRは賢く早く失敗することができるとも書いてあった。

OKRの根っこの部分の概念を学べたのでとても良い本だった。

Cypress with TypeScriptにカスタムコマンドを追加する

Cypressには処理を共通化したりするために、独自のCommandを追加できる機能がある。

docs.cypress.io

例えば、ログインの機能をカスタムコマンドとして定義することで、ログインが必要なテストケースの際に毎回ログイン処理を書く必要がなくなる。

このカスタムコマンドを追加する際、Typescriptの場合は型定義ファイルを追加してあげる必要がある。

型定義ファイルの追加

カスタムコマンドは、下記のように追加することで、テストケース側で呼び出すことができるようになる。

// cypress/supports/commands.ts
Cypress.Commands.add("login", (email, password) => { ... });

// cypress/e2e/example.cy.ts
describe('example', () => {
  it("test case", () => {
    cy.login('xxx', 'xxx');
  });
});

型定義ファイルがないと、cy.loginなんてメソッドはないぞと怒られるし、そもそもCypress.Commands.addの第一引数のloginという文字列も、そんな文字列受け取れませんぞと怒られる。

これは、Cypress.Commands.addが下記のように、事前に定義されている値しか受け取らないようになっているからである。

add<T extends keyof Chainable>(name: T, fn: CommandFn<T>): void

なので、型定義ファイルを追加して、loginを含めたInterfaceを定義する必要がある。

// cypress/types/index.d.ts
declare namespace Cypress {
  interface Chainable {
    login(email: string, password: string): Chainable<void>;
  }
}

これで問題なくカスタムコマンドを追加できる。