Souther による Example 駆動開発ハンズオン に行ってきた #アーキ部

Souther による Example 駆動開発ハンズオン に参加しました。簡単に所感をまとめます。

architect-club.connpass.com

所感

ドメインとなる本質的複雑さをすべて書き出すために Souther を作ったらしいです。

なんとなく BDD のアプローチに似てそうかなと思ったりしたけど、Souther の場合は具体例となる example が言語の一部に組み込まれてて、コンパイルで評価できるところが BDD との違いかしら。モデルと example を行き来して正しい仕様を見つけてドメインモデルを磨いていくアプローチ。

モデリングの手法はいろいろあると思うけど、わりと個人の経験や暗黙知に依存しがちなところを、Souther のようなミニ言語を使うことでより形式的にモデリングができるのかもしれない。加えて、Souther の場合は実際のプログラムまで一気通貫で生成できるのがメリットなんだと思う。(たぶん)

レガシーシステムとか制度の理解に使うの面白い。たしかに制度とか文章で読んでも理解できないもんなぁ...。

実務で Souther を使うことはないかもしれないけど、こういうモデリングの考え方とかアプローチの話を聞けるのがアーキ部のいいところ。

以下、メモから抜粋。

  • Souther
    • ドメインモデル専用汎用言語
  • エージェントがコードを書いてくれる時代
    • ドメインを先に書く
  • ドメインファースト
    • どういうデータを扱うか
    • どういう振る舞いが必要か
  • ドメインではない複雑さ
    • 偶有的複雑さ
    • 例外/トランザクション/非同期/永続化/...
    • AI がうまく書いてくれる
  • 本質的複雑さがドメイン
    • ↑これをすべて書き出したい
    • データ不変条件
    • 振る舞い事後条件
  • 仕様ドメインモデル
    • 仕様の正しさ
    • 正しい仕様からテストを書く
    • example
      • 入力と期待する結果となる具体的な出力
    • モデル/example を書くのを繰り返して正しい仕様を見つける
    • ドメインエキスパート
  • data (データ)
  • behavior (振る舞い)
  • モデルを書く
  • generate オプションで example 生成
    • テスト技法を駆使
  • 正しい仕様を決める
    • 期待する結果と照らし合わせる
  • モデルを変更すると example がコンパイルエラーになる
  • ルールの穴やパターンの矛盾を見つける
    • example が多い
      • 実際にはありえない状態の組み合わせがあったり
      • モデルを変える
  • インサイドアウト開発
    • 業務コアから作る
    • それをもとに外側を作る
  • Raoh
    • https://github.com/raoh-project
    • 外側と Souther のモデルをマッピングしてくれる
    • DB アクセス
      • バインドされない behavior → interface
  • モデルのバージョニング
  • レガシーシステムや制度の理解
    • AI に仕様を Souther で書き起こしてもらう
    • example を生成
      • もとの文章を読むより分かりやすい
  • Souther は分岐を抜き出す

Encraft #26 オントロジー解体新書 に行ってきた #encraft

Encraft #26 オントロジー解体新書 に参加しました。簡単に所感をまとめます。

knowledgework.connpass.com

所感

最近、「オントロジー」をよく見かけるようになった気がする。オントロジー自体はずっと前からあるものだけど、恥ずかしながらこの単語を知ったのも実はここ半年くらい...。具体的なイメージはまだちゃんとできてないけど、全体感はふんわりと分かってきた気がする。とはいえ、今は概要くらいしか追えてないし、実務でオントロジーの構築に関わらないとちゃんと理解できる気がしない...。

オントロジーの構築に、トップダウンやボトムアップのアプローチがあったり、ユースケースからスキーマ設計するかデータからスキーマ設計するかみたいな話に関しては、ちょうど登壇者の方の記事をたまたま見かけたけど、このあたりが参考になるかもしれない。

zenn.dev

あと、オントロジーの活用事例として「ある業界の技術を別の業界に活用/転用できないか」というのは興味深い。関係とか構造を抽象化するとこういうことができるようになるんだろうか🤔

オントロジーとか Palantir 関連の記事をストックしてるので読んでみよう。

以下、メモから抜粋。

オントロジーで新規事業を発想する

  • ナレッジグラフ
  • 新規事業のネタを見つける
    • 同じ構造を持つ別の分野の発見
    • 共通する動作原理
  • 世の中の情報と自社技術のオントロジー
    • FDE
  • 図表などの非テキスト情報のオントロジー化に課題あり
    • VLM
  • 柔らかいオントロジー
    • ユニバーサルグラフ
    • 関係を自然言語文で記述
    • 厳密さを緩和させる
  • オントロジーを作って何がしたいか
    • 人の理解や意思を込めることが不可欠

行動するAIのためのオントロジー:業務の地図をどう作り、権限をどう渡すか

  • AI が安全に業務を動かすための地図
    • 名詞/関係
    • 型付きの操作
    • 権限と統制
  • オントロジーを常に最新に保つ
    • 変化を時系列で追う
    • AI は最新の関係と権限をもとに判断できる

企業の現実世界をグラフで写し取る:1,000万件超の企業・事業所ナレッジグラフとAI-Readyな企業データ基盤

  • 5-Layer Cake
    • Applications
    • 経済価値が生まれる場所
  • AI-Ready
  • オントロジー
  • セマンティックレイヤー
  • 企業の情報を正しく AI に伝える
  • 企業の現実世界をグラフ構造でモデリング
    • Entity/Relationship
    • Semantic Triple
      • 主語-述語-目的語
  • 企業情報のオントロジーでできること
    • AI Agent を正しく動作させる
    • データ品質と運用の向上
      • 表記揺れや名寄せなどのデータクレジング
    • 営業施策の精度向上
  • AI Agent が自律的に動くための基盤になる
    • ハーネス

営業オントロジーの作り方と、エージェントからの辿り方 - ナレッジワークの現場から

  • オントロジー
    • 業務理解のための羅針盤
    • 探索のための索引
  • トップダウン
  • アクションから逆算するスキーマ設計
    • 何をやるか決めてからスキーマ設計する
  • ノードの次数を増やさない
    • ノードに接続しているリンク数?
  • メタデータを厚くする
  • 語彙を固めてグラフをシンプルに保つ
  • 権限
    • 最初から設計に含める
  • コスト
    • どれくらい原価をかけられるか
  • 更新
    • スキーマ変更への追従
    • データソースとの同期

パネルディスカッション

  • 概念をシンプルにモデリングする
    • 正しい状態を AI が活用できる
  • オントロジー活用事例
    • この製品のバグは誰にいくらの影響があるか
      • 不具合/機能/顧客/契約/売上が繋がって初めて答えられる問い
      • 文書検索では出てこない
      • 関係の構造があって成り立つ
    • アカウントの棚卸し/不要アカウントの洗い出し
      • spreadsheet とかで管理しがち
      • 組織図もオントロジーと言える
      • Subject - Predicate - Object
    • ある業界の技術を別の業界に活用/転用できないか
  • オントロジーをどう構築するか
    • トップダウン設計 or ボトムアップ自動抽出
      • トップダウンで設計しつつ自動抽出したものをオントロジーに反映したり
    • usecase → schema or data → schema
  • 壊れたグラフの検知
  • データパイプライン
  • 権限管理
  • マスタデータを整理
    • グラフ構造でシンプルに表現
    • 結果的にオントロジーになった
  • パターンマッチング
    • 検索
    • AI がなくても使えるデータ構造
  • 双方向同期
    • オントロジーと元データに書き込み
    • 失敗したらタスクに積んでリトライできるようにする
  • graph embedding (グラフ埋め込み)
  • ナレッジグラフ/オントロジー
    • Action の有無

なんちゃって AI 活用メモ

前提として (特に周りと比較すると) 自分はそこまでしっかり AI を活用できているかというと怪しい。最新情報もあまりキャッチアップできてないし、モデルの違いとかもあまり気にしたことがない...。

そんな自分のなんちゃって AI 活用メモ。

普段

普段の開発業務では Cursor (Composer 2.5) をメインで使っている。周りは Claude ユーザーが圧倒的に多くて、Cursor ユーザーはわりと少数派かもしれない。あまりにも Claude ユーザーが多いので、自分も乗り換えようと思ったことはある。でも Cursor (Composer 2.5) で特に困ったことがないのよねぇ。とはいえ、時代に乗り遅れてる感もあるし、いつかちゃんと Claude も使えるようになりたい。(いつかと書いてる時点でたぶんならない)

細かい開発タスク

細かい開発タスクは、Cursor にやりたいことや仕様、簡単な設計 (API, テーブル定義, ...) などを渡して実装プランを作ってもらう。実装プランがある程度固まったらコードを書いてもらう。最近は自分でコードを書くことはほぼなくなった。AI が書いたコードはちゃんと読む。これは自分の理解を深めるためでもある。なので、diff を読めるくらいの粒度で開発タスクを分解したり、実装プランのステップを分けたりしている。

少し大きめの開発タスク

少し大きめの開発タスクの場合は、壁打ち相手として Devin をよく使っている。以前はそこまで使える印象がなかったんだけど、この1年ちょっとくらいの間にかなり精度が上がったような気がする。

AI と壁打ちするときは、まずやりたいことや制約事項をざっくりと伝えて、大まかなシーケンスやフローを作成してもらう。それを見ながら仕様を検討したり、設計を詰めたりしている。

というか、AI と壁打ちするためにいろいろと言語化していると、自分の中でもアーキテクチャとか設計がだいたい見えてくる。もちろん、言語化の解像度を上げるために AI と壁打ちすることもある。特に制約事項をしっかり言語化するのが重要。

ある程度内容が固まったら、設計のドキュメントをまとめてもらう。この段階で別セッションを立ち上げて設計レビューをさせることもある。壁打ちの中で余計なコンテキストを溜めていることがある気がするので、クリーンな状態で設計を見てもらう。

その後、Devin には既存機能への影響を考慮しながら、開発タスクを洗い出してもらう。ついでに実装用のプロンプトを作ってもらうこともある。このプロンプトを Cursor に渡す。

Devin から直接 PR を出してもらってもいいけど、なんとなく Devin は余計なことをやらかしそうなイメージ (偏見) があってあまり副作用のある操作をさせたくないのと、PR よりも Cursor の方がコードが見やすいので、実装自体は Cursor でやることが多い。

その他

あと、たまにやるのが、やりたいことや制約事項を一般化して ChatGPT に投げてゼロから設計してもらう。ChatGPT はリポジトリやドキュメントを参照できないので、コンテキストがないクリーンな状態で設計を考えてくれる。

やや規模の大きいアーキテクチャを設計していると、本当にこれで方向性や妥当性に問題がないのかどうかちょっと自信がなくなるときがあったりする。そんなときに ChatGPT が考えてくれた設計と比較することで、答え合わせというか「この方針で進めてよさそう」という自信につなげられる。

問い

AI を使うときは「問い」の質が重要だと思う。

「〇〇を△△に変更してください」ではなく「〇〇を△△に変更するのは妥当ですか?現状の方が適切だと判断できる場合はその理由を説明してください」のように聞いてみる。納得できる回答が来たら実際に変更を指示する。

調査を依頼する際は、解決策としていくつかの選択肢を提示してもらう。また、影響範囲や性能、保守性などの観点でメリデメをまとめてもらう。

AI は設計や実装をするための道具でもあるけど、考えたり判断したりするためのきっかけを与えてくれるものでもあると思っている。こういう問いを繰り返すことによって思考の幅を広げたり判断に必要な力を養うことができる気がする。AI を思考の発散のために使うといいと思う。

学び

あと、AI を学びに使えるかどうかも重要。これまでなんとなくで理解していたことを、AI に伴走してもらうことで以前よりも効率的に理解を深められるし、自分のアイデアや成果物に対して高速にフィードバックを得られるのも大きい。

現場からは以上です。

レビュー どこまでAIに任せられる?AIコードレビューツールの選択肢と実践 に行ってきた #AICodeReview_findy

レビュー どこまでAIに任せられる?AIコードレビューツールの選択肢と実践 に参加しました。簡単に所感をまとめます。

findy-tools.connpass.com

所感

CodeRabbit は会社でも使ってるけど、Greptile や Qodo は初めて聞きました。

AI レビューツールの導入にあたっては、各社の環境や開発プロセス、リリースサイクルなどによって判断軸が変わるんだろうと思います。開発ツール全般的にそうだろうけど。あと、AI レビューツールのベンチマークのように、ツールごとにいろいろ特徴があるっぽいので、自分たちの開発組織では何を優先するのかも判断軸として重要そう。

AI 関連のツールだと、導入したあとに自社に合わせて設定をカスタマイズする以外に、ツール自体が学習することで使い勝手が変わっていくところが他のツールと違うところかもしれない。というか、暫定的に指摘を見送ったケースとかが意図せず学習されないかが気になったけど、そういうのはこちらでコントロールできるものなんだろうか。

CodeRabbit は、最初はポエムがウザくてイマイチだったけど 今は本当に助かっている。ケアレスミスだけではなく、考慮漏れとかロジックの改善案を提示してくれるのがいい。まぁ、もはやコード書くときも AI がほとんど書いてくれるのでケアレスミス自体がもうあまりないけども。

今のチームでは、DB スキーマやドメイン層、ユースケース層の複雑なドメインロジックなどの変更以外は基本的に AI レビューの approve でマージ OK にしている。今回の話にもあったけど、AI と人間で役割を分担するようになったと思う。一方で、個人的にはこれまで PR レビューを通して他メンバーのタスク状況や仕様をキャッチアップしていたところもあったので、コードベースの変更や他メンバーのやっていることを追いにくくなっているところがあるのがちょっと悩ましい...。とはいえ、今後も PR だけで状況をウォッチしていくのは現実的ではないので、マージされた PR をサマリーしてくれる AI bot をメンバーが用意してくれた。今はこれで概要レベルをざっと見て、気になるものだけ見に行くようにしている。

効果測定をリードタイムではなく「指摘採用率」にしているのはなるほど。指摘採用率の数字が小さいとツールがショボい、逆に数字が大きいとコードベースや開発側に何か問題があるかもしれないと判断できるというのが目から鱗でした。

評価体系の話も興味深かったです。ツールの導入ではなく持続的な仕組みづくり、アウトプットではなくアウトカム、おそらくそんなところだと思います。たぶん。

以下、メモから抜粋。

「最後に責任を取るのはチーム」— 人間のPRレビューを最小化してアップデートしたメンタルモデル

  • モジュラモノリス
    • DDD x CQRS
  • Gemini + ADR (レビュー観点)
  • レビュー負荷
    • 上位3名に集中 (テックリードとか)
    • 属人化
  • Greptile
    • コードベースをグラフ化して理解
    • 横断的に見てくれる
  • Claude Code 併用
    • 新機能開発
    • 重めのタスク
  • ツール選定軸
    • PR 量
    • コードベースの複雑さ
    • 内製力 (メンテ)
  • マージ可否を5段階評価
    • 4, 5 になるまで再レビュー
    • セルフレビュー
  • メンタルモデルの変化
    • PR レビューの捉え方
    • AI と人間が分担する
    • 人間は DB 定義/ドメイン設計/レイヤー定義 に集中する
  • AI がコードを書く + 責任はチームで持つ
  • Linus Mode
    • 温度感を持たせる

AIレビューはどこまで任せられるのか?自動化と人が背負うレビューの境界

  • AI が拾える指摘を前段に移す
  • 人間が責任を持つべき判断を明確にする仕組み
  • Qodo
    • 一次レビュー
    • ルールベース
  • AI に任せやすいレビュー
    • ケアレスミス
    • テスト追加提案
    • ベストプラクティス違反
  • 人間に残すレビュー
    • 仕様や設計などの妥当性
    • セキュリティ
    • リスク
    • より本質的な部分
  • 効果測定
    • リードタイム → 指摘採用率
    • 指摘採用率は小さくても大きくてもよくない
      • 2~3割くらいがちょうどいい?
  • ポストモーテム
    • 再発防止策を構造化
    • AI が利用して失敗を減らす
  • 品質学習ループ (個人から組織へ)
  • ツールが変化しても観測/判断/学習の構造を残すことが重要
  • 評価体系
    • 品質学習ループのような仕組みを作れる人を評価したい
    • 仕組みによる効果をどう観測するか
    • チームが安全に変更できるようになったか

チームにCodeRabbitが仲間入りしたらレビュー体験が改善しもう兎なしではいられなくなった

  • レビューがボトルネックに
  • CodeRabbit
    • 一次レビュー
    • 人間は複雑なドメイン知識や設計判断を担う
    • PR サマリー
  • 考慮漏れを拾ってくれる
  • Code Review Bench (レビューツールベンチマーク)
    • Recall
    • Precision
    • F1 Score
  • ノイズ指摘はあるけど見逃しは少ない
  • 設定を育てられる
    • レビュワーとの議論を学習する
    • 設定ファイルのメンテ
  • CodeRabbit CLI
    • ローカル AI レビュー
  • PR 作成後に AI レビュー

Kubernetes 完全ガイド (第2版) を読んだ

会社の輪読会に参加して Kubernetes 完全ガイド (第2版) を読みました。購入履歴を見たらこの本を購入したのが2020年11月頃だったので5年以上積読してたのか...。

5年以上前の本なので、当時は alpha や beta だった機能や、逆に現在は非推奨になっている機能もあったりするけど、基本的な部分はほとんど変わってないので今から読んでも学ぶところはたくさんある。

輪読会の主催が弊社のインフラチームメンバーだったので、本の内容をただ読み進めるだけでなく、自分たちのプロダクトではどのように使っているかとか、逆にこれはこういう理由で使ってないとかの話も聴けた。このあたりはインフラに詳しいメンバーと輪読会できたのがよかった。

Service APIs カテゴリのあたりとかオートスケールのところはわりと重要だと思うけどちゃんと理解できているか不安。あとで読み直してみるか。

あと、読んでる途中で気が付いたけど、本に載っているマニフェストは GitHub で公開されている。(手元にあるのが物理本なので最初は頑張って写経してた。まぁコピペした方がもちろんラクだけどたまには写経もいいよね🙄)

github.com

AI時代だからこそ求められる「セルフマネジメント」の方法 に行ってきた #セルフマネジメント_LTLAB

AI時代だからこそ求められる「セルフマネジメント」の方法 に参加しました。簡単に所感をまとめます。

levtechlab.connpass.com

所感

最近読んでる『静かな時間の使い方』でも、周りからの外圧によって他律的な行動になってしまうようなことが書いてあった気がする。この本ではリフレクションが紹介されてるけど、あれもセルフマネジメントのひとつなんだろうね。

AI 時代のスキルマネジメントの話の中で「学ばなくても動いてしまう」というのはまさにそう。AI を学習や思考の深堀りに使えるようになるといいと思う。個人的にも学習のサイクルがとても早くなったように感じる。だからこそ「問い」の重要性が増してると思われる。

自分もわりと〇〇すべきという思考になりがち。セッションの中で紹介されてた認知行動療法 (CBT) とか調べてみようかしら。

あと、経験上うまくいかなかったことの話で、iwashi さんでもこうなってしまうのかっていうのが分かってちょっと安心した。

slido に投げた AI による余白と越境の質問を最初に取り上げてもらってとても参考になりました。ありがたい。

以下、メモから抜粋。

自分のハンドルを握る〜AI時代だからこそ求められるセルフマネジメントの技術

  • 自己管理入門
  • AI
    • 使うのが当たり前になった
    • あっという間にベストプラクティスがひっくり返る
  • 心理的プレッシャー → 他律的な行動
    • 外部から行動を規定されている状態
  • FOMO
    • Fear of Missing Out
    • 取り残される恐怖
    • ありたい姿を見失う
  • セルフマネジメントの構造
    • モチベーションマネジメント
  • やりたいを取り戻す
  • ジェボンズのパラドックス
    • 生まれた余白が新しい仕事と期待に塗りつぶされる
  • リフレーミング
    • 解釈を変えて感情を変える
  • スキルマネジメント
    • 学ばなくても動いてしまう
    • 深堀りする/問い
    • マイクロラーニング
  • AI に何を任せるか/自分は何を身に付けるか

チームパフォーマンスを高めるための2種類のセルフマネジメント

  • セルフマネジメントはチームにも効く
    • バス係数
    • 超スモールチームが強い現代
      • メンバー減のインパクトが大きい
  • 時間とエネルギー
    • 実際に働いた時間と働いたと感じる時間は異なる
    • どんなタスクでエネルギーを消費しやすいのか
    • カレンダーのデフラグ
  • Getting Things Done
    • 仕掛りを絞る
  • FOMO
  • デジタルデトックス
  • 完璧主義
    • 認知行動療法
    • 認知と行動のクセを見直す
  • 自分が長期的にやりたいことを言語化
    • やらないことや優先度を判断しやすく
  • 心がけはうまくいかない
    • やる気が出たらやるはやらない
  • 行動ではなく環境を変える
    • 積読は見えるところに

自律的にセルフマネジメントできるチームのつくり方

  • 意思決定
  • 挑戦
  • 倫理
  • 事業拡大や市場変化に関わる意思決定/挑戦/倫理
  • チームで決めるのは難しい
    • 経験のある人に依存しがち
    • 長期的に見るとチームで意思決定できるようにしたい
    • ROI
  • 挑戦
    • ものづくりは停滞する
  • 倫理
    • 収支に気を使う
    • ROI (個人/チーム)

パネルディスカッション

  • セルフマネジメント術
  • 気楽に生きる
  • 外に流れる情報に一喜一憂しない
  • カレンダーをデフラグする
    • 1on1 の予定を固める
    • 形骸化したミーティングをやめる
  • ゴールを明確にする
    • 情報収集でもここまでやったら終わりを決める
  • 越境
    • 自領域から出ることを求められる
      • 能動的か受動的か
      • 自分事に落とし込む
    • 越境すると何が嬉しいの?
    • 自分がハンドルを握れるところを探す
    • 大義を理解する

EM ふりかえり

ここ数ヶ月の EM としてのふりかえり。これまでもチームやプロジェクトのリーダーを担うことはあったけど、以前よりも目標設定や評価などのピープルマネジメントの比重が大きくなってきた。このあたりは自分の中でもちゃんと言語化できるほどの明確な基準を持ててるわけではないのよね。

Keep (よかったこと)

  • 1on1
  • プレイヤー
  • コンディションシート

1on1

1on1 を定期的に実施するようにした。「定期的に」がポイント。1on1 の予定があることが分かっていることで、あらかじめ話題を考えるようになる。スポットで実施しているとお互いに十分に準備できないまま話すことになり、結果的に双方がしっかり対話できないまま終わってしまうような気がする。

あと、話題がなさそうなときは、スキップしたり早めに切り上げたくなったりするけど、何気なく話し始めると、実はちょっと気になっていることだったり、なんとなく困っていることなどが意外と出てきたりする。それでもどうしても会話が続かないときは、直近の業務の話だったり、最近読んでいる本とか、仕事で大事にしていることなどを聞いてみたりする。自分の話をすることもよくある。

いずれにしても、継続的に対話してお互いを知ることで少しずつ関係性を深めていけるんだと思う。

プレイヤー

転職してからそれほど日が経っていなかったこともあり、プレイヤーとして何かしら成果を残すことにも注力した。周囲からの信頼を得るには、それなりに成果を残したり、信頼に繋がる振る舞い (言動) を日々見せていくのがいいんだろうと思っている。

あと、メンバーをフォローする際に、自分でも手を動かしてある程度対象を理解しておきたいので、マネジメントだけでなく、プレイヤーとして手を動かせる状態をできるだけキープしておきたいというのもある。

そういう意味では自分のリーダーシップのタイプはサーバントリーダーシップなのかもしれない。

コンディションシート

これは前に読んだ『エンジニアリングマネージャーお悩み相談室』に書いてあったものを取り入れてみた。

自分は notion のデータベースに date, topic, link, who, category, status で管理していた。メンバーごとにトピックやきっかけとなった PR や slack のリンクを記録する。category は本で紹介されていたのと同様に「ポジティブ」「ネガティブ」「気になる点」の3種類。気になる点は、ポジティブでもネガティブでもなく、何気なくふと思い当たって、次に会ったときや 1on1 で聞いてみようと思ったことをメモしたもの。status は、相手に聞いたりフィードバックするのを忘れないようにするためのもの。

コンディションシートは日頃の観察を記録するのにちょうどいい。これのおかげでフィードバックがやりやすくなった気がする。評価の時期にも有用。後述する通り習慣化という課題はあるけど、いずれにしても今後も続けたい。

More

  • 1on1 メモを共有する
  • 1on1 メモの体系化
  • コンディションシートの習慣化
  • メンバーの目標設定
  • チームの変化を知る

1on1 メモを共有する

メンバーごとに 1on1 のメモを手元に残している。メモを残すこと自体はこれまでも続けてきたけど、今後はこれをメンバーと共有するのもありかもしれない。話した内容を記録したり、次に話したいことを適宜メモできるようにしておいたり。

あと、単純に話したことをメモするだけでなく、短期的なふりかえりに使うのもいいかもしれない。次回の 1on1 までに取り組みたいことを書いておいて、実際にどうだったかをふりかえれるようにする。個々人の内省を促すにはちょうどよさそう。日報とかでもいいかもしれない。

とはいえ、1on1 のメモには多少センシティブなことも書いたりするので、使い分けに注意する。

(追記) メモを共有できる形にしておくと引き継ぎにも使えるかもしれない。メンバーの観察には時間がかかるものなので、引き継ぎがあることでメンバーの理解を早くできそう。

1on1 メモの体系化

話しながらメモを取っていると、書き方を迷ったり雑になったりして、あとから読み返したときに何を書いてたかよく分からなくなってしまうことがる。なので、フォーマットやテンプレートを用意しておくといいかもしれない。例えば、自分の発言と相手の発言を分けてメモできるようにしたり、発言以外の感想や相手の反応などをメモできるようにしたり。

今だと自動で書き起こしとか全然できるけど、そのときのお互いの心情は書き起こしには記録されない。

コンディションシートの習慣化

コンディションシートは日頃の観察を記録するのにちょうどいい。ただ、自分もプレイヤーとしてプロジェクトに向き合っていると、あとで書こうと思っていたことを忘れたり、そもそも周囲を観察する意識が薄れてしまうことがある。

なので、できるだけ毎日書くようにしたい。何かしら書くことを意識するだけでも、ポジティブなことやネガティブなことなど、意外と気づきを得られたりする。

メンバーの目標設定

メンバーの目標設定を考える際は、本部や部などの上位の目標からブレイクダウンしていく。このとき、各自の最近の関心事をベースになんとなくでブレイクダウンしているような気がする。

このあたりは『エレガントパズル』の第3章あたりに書いてあったようなことを軸に、個々人の志向やキャリア観を反映できるようになるとよさそう。

  • 成功を最大化するために経験の乏しい分野を伸ばすのか
  • 自分の得意なことを優先して今の環境で局所的に成功するのか
  • 興味とビジネスの交点は何か

特に「興味とビジネスの交点」はとても重要そうだけどなかなかハードルが高い気がする。

チームの変化を知る

1on1 を通してメンバーとの関係性や相互理解は深まったような気はするけど、自分が EM を担ったことで、チームやメンバーの状態はよくなっているのかがあまり実感できていない。アンケートやサーベイなどを実施してもらって、何かしらのフィードバックが欲しいところ。

その他

個人的にファシリテーションをよくしたい。前に読んだ『組織を変える5つの対話』にも「多様性に求めるべきは建設的な対立」というのが書いてあって、チームメンバー同士でも自己開示と他者理解を意識できるとよさそうだなと思った。こういうのを促せるようなファシリテーションができるようになりたい。

あと、『問いのデザイン』を読み直したい。

現場からは以上です。