本記事は READYFOR 株式会社の READYFOR Advent Calendar 2023 の [15日目] です。
※ 本記事の内容は所属会社の公式発表・見解を示すものではありません。
■ 「言葉集め会」とは?
弊社 READYFOR では2年ほど前より DDD に関する取り組みを行っています。
「言葉集め会」とは、そんな弊社にて実施した コンテキストマップの作成や精度向上 を主目的とした 『ドメインエキスパートの皆さんを招待し、仕事で使う「言葉」とその関係性を改めて見出してみる』イベント です。
同僚の方が前職の体験を元に考案したもので、準備を除き全体でおよそ4時間という少し長丁場のプラクティスとなります。
その経験について本日はお話をさせて頂きます。
■「言葉集め会」で期待できること
「言葉集め会」を実施することで、以下の効果を期待することができます。
-
エンジニア目線
- 自社のビジネスについて精通する「ドメインエキスパート」の皆さんが使っている 生の言葉 を理解できる
- DDD で言う「コンテキスト」や、システム整理の切り口を掴める
- → コンテキストマップを作る・精度を上げるための良い材料となる
- より洗練された概念を使って、システムを素早く・保守性高く組み上げられるようになる
-
ドメインエキスパート目線
- 他の部署で使っている言葉や、ビジネス活動の差分について理解が進む
- コミュニケーションやビジネス活動を円滑に進められるようになる
- エンジニアと会話しやすくなる
-
これらを合わせた相互作用
- 現場で使われている言葉の「ユビキタス言語」への昇華
ここから先は、まず「なぜ言葉を集める必要があると考えたのか?」について少しだけ説明をさせていただきます。
■ Why: なぜ言葉を集める必要があると考えたのか?
□ Why.1 なぜ「言葉」を集めたかったのか、集めるとどんな良いことがあるのか?
皆さん、ドメインエキスパートの皆さんが日々使っている「生の言葉」 を知って、理解できているでしょうか?
いえ、エンジニアだけに留まりません。
ドメインエキスパートの皆さんにとっても同じです。
隣の組織、隣のチーム、隣のメンバー・・・彼らが使っている言葉は、本当に あなたの使っているものと同じ単語で、同じ意味を持っているでしょうか?
エンジニアもドメインエキスパートも、どんなときでも使う言葉と意味が完全に一致しているならば最高です。
しかしビジネスの世界は日進月歩。
厳しい現実世界に合わせて、システムよりも早い速度や頻度で変更・改善が行われることも決して珍しくありません。
また従事する仕事やコンテキストごと(= つまり組織ごと) に最適な言葉も意味も少しずつ異なる事も多く、同じ言葉を違う意味で使ったり、違う言葉を同じ意味で使ったり するなど、少しずつ差は生まれ広がっていきます。
どんな言葉があるのか、またその差分を知ることでお互いの距離を縮めよう、というのがこの会の目的のひとつ となります。
□ Why.2「生の」言葉
実はエンジニアの皆さんが日々見聞きする言葉は、普段の実業務の中で使われている言葉とは異なる、いわゆる「お上品な言葉」 である可能性があります。
私たちが自宅ではゆるゆるの服を着ていても、外に出かける時はピシッとしたよそ行きの服を着てるのと似ています。
仲間内でざっくりと意味が伝われば良い状況 と、
外向けにきっちりと意味を伝えなければならない状況 では、使われる言葉が違っても不自然ではないのです。
つまり、日々の仕事の中でドメインエキスパートの方が我々エンジニアへ伝えてくださる言葉は、エンジニアが理解しやすいように慎重に選んでいただいているものである可能性 があります。
または エンジニアが理解しやすいように言い換えて頂いているものである可能性 と言い換えることも出来るでしょう。
その結果、現場で実際に使われている言葉とシステム上の言葉が乖離していて... という課題に繋がることもあります。
「理論上の言葉」ではなく「現場で使われている言葉」を知る。
そこには業務改善やシステム改善、生産性・保守性の向上など様々な可能性があります。
□ Why.3「同じ言葉なのに違う意味」、「違う言葉なのに同じ意味」がある
実は同じような仕事に携わっていても、各組織や各チーム、各メンバーごとに、使っている言葉が違う、または、同じ言葉でも指している意味が違うという事もあります。
例えば「ユーザー」という言葉、きっと皆さんのよく使うシステムでも使われているでしょう。
弊社で言えば、
- クラウドファンディングで 資金調達 を行う「実行者」
- クラウドファンディングで 支援 を行う「支援者」
これら2つはどちらも「ユーザー」と呼ぶことが出来ます。
つまり、同じ言葉なのに違う意味 を持っています。
この時、
- 「実行者」さんとやりとりをする部署やシステム
- 「支援者」さんとやりとりをする部署やシステム
で、同じ「ユーザー」という言葉を使っていたら 何が起こるでしょうか?
例えばコミュニケーションを取る時に「ユーザー」という言葉が指す意味を取り違えてしまい混乱をきたす可能性があります。
それがシステムであっても、そのユーザーが実行者なのか支援者なのかを取り違えてしまってバグを引き起こしてしまう可能性があります。
バグにまで至らなかったとしても、
if user.実行者?
.....
elsif user.支援者?
.....
end
といったコードがあちこちに跋扈して保守性や可読性を著しく下げてしまう可能性もあります。
これは DDD で言うところの「コンテキストの違い」 というものです。
そんな事なんて簡単に気がつくよ、と思った方もいらっしゃるでしょう。
しかしこれは 「ユーザー」という良くある例 を題材にしたからのことだったりします。
ほんのちょっとした、されど致命的な意味の違いや「ルールの違い」がそこにあったとき、気が付かずにコミュニケーションやシステムに爆弾を仕込んでしまう可能性があります。
人間の思い込み後からは想像よりも遥かに強く、「コンテキストの違いによる言葉の違い」に気が付き、意識することはとても難しいのです。
そしてそれを直したり統合したりしていく作業には想像を絶する労力やパワーが必要となります。
だからこその「言葉集め会」 と言うことも出来るでしょう。
□ Why.4 コンテキストマップの精度を上げたい
言葉集め会に先んじて、弊社の中にあるシステムやビジネスの境界を示す「コンテキストマップ」の作成を行っていました。
しかしどうにもしっくりこない。
ビジネスについてのお話を聞かせていただいて、理解した気はする・・・が、どうにもしっくりこない。
図にしてみてもどうにも理解が薄いというか、何か大切な本質が抜け落ちている気がする。
そんな疑念を祓うためにも、ドメインエキスパートの皆様に声をおかけしてイベントを開催することにしました。
■ What:「言葉集め会」の成果物サンプル
ここからは実際に「言葉集め会」についてフォーカスしていきます。
まずは成果物のイメージを御覧ください。
□ 1チーム分の成果物
こちらは 1チーム分のサンプル です。
これがチーム数分並ぶこととなります。
上側にあるのが業務のゴールとその背景・目的、
下側にあるのが業務プロセス・大事なプロセス(星付き)、大事なキーワードとその理由を載せたものです。
□ 弊社で実施した際の全チーム分の成果物
業務機密であるため詳細はお見せできず心苦しいのですがですが、弊社の場合は9チーム分集まったとてもとても大きな成果物となりました(参加頂いた皆様に感謝!)。
■ How/Who:「言葉集め会」のフォーマット
続いて、「言葉集め会」でどんな事をするのかを紹介します。
□ 参加者
- 進行役(エンジニア)
- 2名以上
- 各テーブルを回ってのサポートを行うため複数名が望ましいです。
- ドメインエキスパートの皆様
- 1チーム複数名 * できるだけ多くのチーム
- 普段、一緒に業務をしている人たちでチームを組みます。
- 漏れ・偏りを減らすため1チーム複数名が望ましいです。
□ 使うツール
- オフラインでの開催の場合
- 机で複数のグループが作れる広い会議室
- 大きな紙と付箋、マーカー
- オンラインでの開催の場合
- Gather や SpecialChat などのバーチャルオフィス系サービス
- FigJam などのホワイトボード系ツール
□ 当日の手順
全体を通しておよそ半日4時間程度のプラクティスです。
当日の手順は以下のとおりです。
- 手順1. チームごとに分かれる
- 手順2. チームのゴールを書き出す
- 手順3. ゴールの背景、目的を書き出す
- 手順4. ゴール、背景、目的を全体に共有
- 手順5. 業務プロセスを書き出す
- 手順6. 業務プロセスを全体共有
- 手順7. 業務プロセスを書き出す(2回目)
- 手順8. キーワードをピックアップする
- 手順9. ピックアップしたキーワードの Why を書き出す
- 手順10. キーワードを全体共有
■ How: 当日の手順(ステップごとの詳細)
以下、当日の手順をステップごとに詳しく解説していきます。
□ 手順1. チームごとに分かれる - 5分 (時間の目安)
まずは普段一緒に仕事をしている人たちでチームを組み、席に分かれます。
オンライン・オフラインを問わず、テーブルを分けて座ってください。
※ 参加者の決定段階であらかじめチーム分けを決めておくことを強く推奨します。
□ 手順2. チームのゴールを書き出す - 5分
自部門のゴールを書き出しましょう。
弊社であれば OKR をコピペする形でスタートしました。
例: (図書館の貸出業務の場合) 滞りなく図書の貸出が出来ること。
□ 手順3. ゴールの背景、目的を書き出す - 5分
手順2 で書き出したゴールの背景、目的を書き出します。
他のチームとの違いがはっきりと分かるように言語化するようにしてください。
同じようなゴールであったとしても、その背景や目的によって持つ言葉の意味が変わってくる可能性があります。
次のステップでその差を明確にしていきます。
□ 手順4. ゴール、背景、目的を全体に共有 - 30分
手順2, 3 にて書き出した内容を、チームごとに発表・共有します。
ゴールとその背景・目的がチームごとに異なっていることを認識合わせします。
例: グループXXX の目的は YYY で、その背景として.....
□ 手順5. 業務プロセスを書き出す - 30分
自部門の業務プロセスの流れを図示化します。
弊社の場合は BPMN を活用しましたが、フローチャートなどの手法でも構いません。
特に注意いただくのは、
- どこが重要なプロセスなのか、及びその理由
- 業務を成立させるうえで絶対に欠かせないプロセス
- 非常に神経を使う、注意を要するプロセス
- イレギュラーな異常系プロセスやリスク対応プロセス
- 利害関係者は誰か
を明示することです。
特にこの「理由」が大事になります。
なぜならば「理由を説明する言葉」の中に、私達が把握できていないにも関わらず大切な言葉 が隠れていることがあるためです。
なお図を細かくしすぎると時間がかかる & 重要なポイントが分かりづらくなるため、業務を漏れなく寸分違わず図示化する必要はありません。
このタイミングで、進行役は各チームを回って困りごとの解決や、図の粒度感を揃えるなどのサポートを行います。
□ 手順6. 業務プロセスを全体共有 - 30分
手順5. で作成中の業務プロセスの図をチームごとに全体へ共有します。
図の粒度などを場の全体で目線合わせをするためです。
もしも進みの芳しくないチームがあったとしても、共有の時間を取ることで進め方のヒントを得ることができます。
□ 手順7. 業務プロセスを書き出す(2回目) - 15分
手順5. の続きです。
再度業務プロセスの図示化を進めます。
□ 手順8. キーワードをピックアップする - 手順8と合わせて30分
完成した業務プロセスの図の中から、重要なキーワードをピックアップします。
キーワードとは、「普段の業務で中心的に取り扱っている概念」の事を指します。
例: 図書館の貸出業務であれば...
- 貸し出し
- 延滞回数
- 図書汚損回数
- 紛失回数
- 要注意会員
- 出禁
□ 手順9. ピックアップしたキーワードの Why を書き出す - 手順7 と合わせて30分
手順8 でピックアップしたキーワードが「なぜ重要であるのか」、その理由や背景をキーワードごとに書き出します。
例えば複数の部門で「審査」という言葉を使っていたとしても、部門ごとにその扱い方や目的・背景が異なってくることがあります。
この目的の差異を明らかにすることが「言葉集め会」で最も大切なこと となります。
□ 手順10. キーワードを全体共有 - 30分
手順9 で洗い出したキーワードとその目的をチームごとに発表・共有します。
時間がある場合はチームごとに質問やコメントを募集するのも良いでしょう。
いずれにせよ複数のチームから様々なキーワードと目的が出てくるはずです。
発表に際しては、
- 同じ言葉でも意味が異なるキーワード
- 異なる言葉で意味が同じキーワード
- (存在を知らなかったキーワードもあるでしょう)
に着目すると良いでしょう。
そしてその差分には「目的」がセットになっていますから、目的と照らし合わせたときに同じキーワードであってはいけない言葉や概念であったり、システムで上手く表せていないキーワードが浮かび上がってきます。
こうした差異に気が付かないままでいたことが、コミュニケーションやシステムに悪影響を及ぼしている可能性があります。
発表・共有を通じて、エンジニアにとっても、参加頂いたドメインエキスパートの皆さんにとっても、その差に着目しながらお互いにコメントを返し合う事で自ら・お互いの業務をより深く理解する取っ掛かりとなるはずです。
エンジニア目線で言えば知らない言葉を目的を添えて知る事が出来るだけでなく、
「目的が違うから言葉も違う」、「目的が違うから同じ言葉でも意味が違う」というとても大きな手がかり(匂い) を手に入れることが可能です。
この手がかりを元にコンテキストを分割したり、上手く表現できていないビジネスロジックをリファクタしたり、より目的に準じて洗練された言葉・概念を使ったシステムを作り上げていくことに繋がります。
なお手順10 まで完了すると、チームごとに以下のような成果物を得ることが出来るはずです(再掲)
□ (後日) 「言葉集め会」から得られた成果の共有
まずは忙しい中参加いただいたドメインエキスパートの皆様に感謝の言葉を送りましょう。
また日を改め、成果物の中身から得られた気づきや成果をエンジニアだけでなく、ドメインエキスパートの皆様に展開することも忘れないようにしましょう。
貴重な時間を割いて参加頂いたのですから、そこで得られた知識がどのように活用されたのか/されていくのかをお伝えすることで、継続的に良い関係性を作ることに繋がっていきます。
■ How: 準備フェーズの大切なこと
ここまで大規模なイベントを企画するとなると、その準備も膨大となります。
- 会の設計
- 参加者のネゴ
- チーム分け
- 当日の動き方の設計
- リハーサル
- etc...
となると出てくる疑問として..
■ Q. そんなに沢山の人を集められないよ~~!
□ A. わ か る。
そう、ドメインエキスパートの方々は本当に多忙なんです。
日々業務や顧客の方々と向き合い、数字に追われ、とてもとても多忙な日々を過ごしています。
そんな方々を同じ時間に一度に集めるのはとても難易度が高いことです。
とは言え、複数チームを集めて差分を知りながら空気感を醸成しつつ進める・・と会の特性を踏まえると、1チーム2名以上を複数チーム集められるのが理想 です。
...が、正直なかなか大規模に始めるのは難しいでしょう。
まずは小さな粒度で始めて見るのも良いと思います。
成功するかは正直未知数ではありますが、
- 全社キックオフのような場でのイベントにする
- 開催規模(参加者数) を少し抑えて複数回開催にする
- プラクティスの内容や時間を調節してみる
なども考えられます。
いずれにしても大切なのは、エンジニアの(きっと)苦手とする所謂「ネゴ」です。
そしてこれはとても地味ですが大切な仕事です。
今回で言えば、
- 組織の権限を持つ人に声をかける
- 開催やメンバー招集の許可をいただく
- ビジネスを熟知している適切な人材・人員を紹介いただく
- 組織的に空き時間が生まれやすい曜日や時間帯を探す
そして紹介頂いた方に声をかけて・・・という流れを順次ツリーのように連鎖しながらメンバーとチームを構成していきました。
ビジネス組織とエンジニアリング組織の距離が近く、容易に実現可能な企業もあれば、そうでない企業もあるはずです。中にはこんな動きをしなくてもイベントが開催できる企業もあるでしょう。
『なんか大変そうだな・・』と思うのは当然です。
でもあなたがやらなければ、きっと困りごとは中々解決しないままでしょう。
システムもエンジニアも、どうあがいてもビジネスとは切っても切り離せません。
企業活動としては、どんなにいいシステムを作ったとしても、ビジネスが成り立たなければ何の意味も成さないからです。
ですから「一緒に正解を考えていける環境」を作ることが出来れば、成功に繋がる可能性を格段に高められるはずです。
私はその活路を DDD に見出しましたが、きっと方法はなんでも OK です。
今回紹介したプラクティスは、N=1 の小さな例でしかありません。
業務のことを知らなければ、DDD どころか良いシステムを作ることだって困難です。
ぜひ色々とトライしてみて、また来年のアドベントカレンダー記事などでお話を聞かせて頂けると嬉しいな、と思います。
■ What:「言葉集め会」にて得られたもの
言葉集め会で得られた知識をベースにコンテキストマップを作ることが出来ました。
またもや機密情報の塊なので詳しくはお伝えできなくて申し訳ないのですが、
人とシステム・情報がどのように関わり合っているのかを整理して、あるべき姿の模索にシステムの整理・リファクタにと役立てています。
■ おわりに: わたしの Next Step
言葉集め会を開催したことで様々な学びを得ました。
知りもしなかった様々な言葉や概念達、ドメインエキスパートの方々との関係性など数え切れないのですが、
その最たるものは「業務に飛び込まなくては真の理解にはたどり着けない」ということです。
聞くだけ、教えてもらうだけで理解できることも沢山あるのですが、業務の中に抱えている真の問題に辿り着いたり、その悩みや改善案などを受け止めて自分事としていくためには「自ら参加して情報を集める」こともとても大事です。
言うのは簡単ではあるのですが、なかなか勇気が出ないのも事実です。
例えば商談動画の録画を皆で見る会を実施するなど、少しずつ挑戦を続けていきたいと思います。
本記事は READYFOR 株式会社の READYFOR Advent Calendar 2023 の [15日目] です。
※ 本記事の内容は所属会社の公式発表・見解を示すものではありません。