「コーチングマネジメント」を読みました

テクニックや知識的なところだけでなく、人と対峙する面も求められる今の役割・立場的に必要そうとは思ってた「コーチングスキル」。いくつか推薦してもらった本の中から、まずはこれを読んでみました。

コーチング・マネジメント

PART1 : 今求められるマネジメント革命

ゴルフを教えないゴルフコーチ

ここで取り上げられてたやり取りが印象的でした。なるほど、こういうのがコーチングの基本形なのかなと感じました。

「目標に対する集中度は1から10で何点？」
「自分の体や動きに対する気づきは1から10で何点？」
「今のショットから学んだレベルは1から10で何点？」

みたいな感じで、コーチが特に技術的なアドバイスをするわけではなく、現状を気づかせる問いかけをするだけ。けれど、それによって、自分自身で考えて行動するようになる、という話。

ミスショットのときも、それを責めるとかではなくあくまで気づきを与えるような問いかけが、例に挙げられていました。

「どうやってあんなふうにボールを曲げたんだね？」
「打つ前から曲がるような気がしたし、・・・頭が混乱していたし、腕も緊張していた」
「そう、それでどんなことを学んだ？」
「混乱しているときは、仕切り直しだな」
「今までだって仕切りなおしのチャンスはあったと思うんだけど、それができなかったのはどうしてなんだろう？」
「一緒にプレーしている人の目を気にしていたのかな？」

PART3 : コーチング・スキル

クローズド・クエスチョンとオープン・クエスチョン

「なぜ？」って言葉は、オープンクエスチョンに見えて、実はクローズドクエスチョンに近いという話。「なぜ」と聞くと相手を萎縮させてしまって、結果的にクローズドクエスチョンになりがちだということです。

「なぜできなかったんだ？」
「なぜそんなことをやってしまったんだ？」

そのかわり、「HOW」や「WHAT」を使うとのこと。一般的には、HOWがアイディアを発展させて、WHATが問題をはっきりさせると説明されています。

「どうやったら、同じ失敗を繰り返さないですむと思う？」
「次はどういうふうにやる予定？」

「何が足りなかったんだろう？」
「何か気がついたことはなかった？」

効果的な質問のためにすること・実際のコーチングクエスチョン

コーチングの質問に際して考えておくべきことや、質問リストがきれいにまとまってました。ちょくちょく見直すことになりそう。

選択の幅を広げる質問

クローズド・クエスチョンの「Yes / No」「やるか、やらないか」は選択ではなくて脅迫らしい。コーチは、必ず3つ以上の選択肢を見つけ出して、自発的に選択できる状態をセットしなければいけないって。

結構難しい気がするけど、頑張ってみる。

アクナレッジメント

「賞賛」などの評価を含む言葉ではなく、事実を事実として伝える。評価が入ると、意見なので受け取りにくくなるということらしいです。「You」「I」「We」の視点があり、一番効果的なのは「We」のアクナレッジメント。

具体例をあげるのはやめておくかな。意識的か無意識的かにせよ、これと同じ言葉を誰かが聞いたとき、わざとらしく感じるかもなので。

エコロジカルチェック

何か変化があったときに、質問しながらその変化によって生じた歪みを見つけること、らしい。例えば、こんな状態になってるとして、

「頭では分かっているんだけどしっくりしない」
「何か違和感がある」
「最初はいいと思ったけど、今はちょっと」

これらの心理的な違和感や歪みを、こんな質問であらためて確認する感じ。

「今やっていることは、やる前に考えていたことと一致していますか？」
「やり方を変えて、気分はどうですか？」
「思ったような成果が上がっていますか？」
「ストレスはどうですか？」
「何か違和感はありませんか？」
「体の変化どうですか？」
「生活のバランスはとれていますか？」

要はやりっぱなしでなくて、ちゃんとアフターフォロー的なところも意識してってことかな。こういった「継続的な取り組み」ってのは、最近のマイブームというか、自分・組織に対して根付かせていきたいと思ってます。ふりかえりにしろ、例の本で学んだ見積もりと計画づくりにしろ、ここでのエコロジカルチェックにしろ。

---

一通り書いた後に見返してみると、ちょっとコーチングのスキル的なところばっかり目についちゃったかな。また適当なタイミングで見返してみて、そのときはどう思うかを感じてみたいです。

「アジャイルな見積もりと計画づくり」を読みました

名著と言われながら、今まであまり興味がなくて読んでなかった分野。もっと早く読んでおけばよかったなと思う反面、おそらく以前の自分では消化できなかった＆活かせなかっただろうなと思ってはいます。

アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?

1章：計画の目的

1. なぜ見積もりや計画づくりが必要なのか？

しょっぱなにあるこの問いかけ、最初からすごいためになる文章です。この本を読むまでは、見積もりや計画って、やりたくないけどやらざるを得ないといった、どちらかというと消極的な理由しか思い浮かびませんでした。でも、それだけでないよという話。具体的には、以下の5つが挙げられています。

• リスクを軽減する
• 不確実性を減らす
• 意思決定を支援する
• 信頼を確立する
• 情報を伝達する

この中で太字にしたものが、消極的な理由ではなく、計画作りをしていくことによってもっと前に進めるための理由かなと感じました。開発者・チームにおいても、いやいや計画づくりをやっていくのではなく、チームが計画づくりをやっていくことによって、ビジネス面での意思決定を支援したり他チームとの信頼を確立していくことを意識する。それが結果的に、開発チームだけでなく全体のサービス・プロダクトにいい影響をもたらしていくというのは、自他共に意識づけていきたいなと強く思いました。

あとは、これかな。

3. アジャイルな計画づくりとは？

本書で扱うのはアジャイルな「計画づくり（planning）」だ。アジャイルな「計画（plan）」ではない。
...
アジャイルな計画づくりで重視するのは、計画よりも、計画を作る過程そのものなのだ。

プロジェクト初期のみ「計画」を作成するだけじゃだめで、ちゃんと日々の活動の中で計画を更新していく「計画づくり」が大事だよということ。これって、プロセス改善の文脈でのメトリクスとかでも同様だよなーというのを思い描きながら読んでました。

11章：「望ましさ」による優先順位づけ

狩野モデルについての説明。このモデルについてはどっかで見たことがある気がするけど、本の中で出たので改めて見なおしてみました。守備範囲的にはプロダクトオーナーの領域っぽいけど、スクラムマスターとしてもさらっとでも知っておいて損はない領域だし、参考になりました。

モデルの説明については、先人のブログを参考に。
d.hatena.ne.jp

16章：ベロシティの見積もり

ベロシティは常に固定になるわけではなく当然幅があるけど、その幅をどう扱うかの話。3イテレーション（スプリント）以上取れる場合、以下の方法が挙げられていました。

• イテレーション毎のベロシティをそのまま幅として扱う
• 不確実性コーンを活用する

前者は単純。3回のイテレーションのベロシティが (12, 15, 16) ポイントだった場合、見積もり幅は 12~16 ポイントと扱います。

後者は、不確実性コーンと呼ばれる、プロジェクトの状況に応じて不確実性の幅が変わる図を流用しています。ここで、3回イテレーションこなした後の平均ベロシティが20ならば、下限が20*0.85=17, 上限が20*1.15=23 で、17~23 の幅に収まるだろうと推測する感じ。

実施したイテレーション数	下限の係数	上限の係数
1	0.60	1.60
2	0.80	1.25
3	0.85	1.15
4以上	0.90	1.10

ちょっと計算式は複雑になるけど、不確実性コーンをもとにした方が、今のうちのチームにとってはいいかなと思いました。理由としては、ベロシティの平均が基準となってるから。

うちのやり方として、1イテレーション内できれいに終わりきらないことがあるのですが、その場合各イテレーションのベロシティは変動しやすくなるんですよね。ただ、各イテレーション毎の変動はともかく、移動平均をとっていくと中長期的には問題とならないことが多い*1。なので、平均を考慮した方がより精度が高いものが出せるかなと思っています。

22章：なぜアジャイルな計画づくりがうまくいくのか

11. ゆとりを残す

チームメンバー全員の時間を100%使い切るような計画を立てないこと。特にイテレーション計画では気をつけること。高速道路の限界100%まで車を詰め込むと、誰も身動きの取れない渋滞になってしまう。開発チームもこれと同じだ。メンバー個々の時間を限界まで使ってしまうと、プロジェクトの進みは遅くなってしまう。

はい、やってしまってました。イテレーション計画ミーティング時は作業時間見積もりをしてるのですが、このとき全時間を詰め込もうとして結局計画したものが全部終わりきらない。終わらないものを計画時に話すのムダだし、終わらなかったという事実はチームメンバーのモチベーション的にもいい影響を与えない。

なので、最近ではベロシティ（実績）ベースで考えるようにしようとしてます。普段大体これぐらいポイント消化できてるのだから、（作業時間はもうちょい余裕あるけど）計画するのはここまでにしておこう。で、おかわりできるならばそのとき考えよう、という方針にしてます。

チームがもっと成熟して毎回安定して計画したものを終わらせられるようになってきたならば、その次はいかにベロシティを上げていくかを考えていく感じ。もしかしたらその中で、作業時間のムダに着目していって、より効率的にタスクに取り掛かれるようになるかもしれないなーとは考えています。

---

いつもより長くなった。それだけためになる内容が多かったです。特に1章の「1. なぜ見積もりや計画づくりが必要なのか？」は常に意識しておきたいです。

あと、タイムリーなことに、先月の WEB+DB PRESS でちょうど見積もりの話がでてました。こちらも参考に。

WEB+DB PRESS Vol.93

*1:この辺は「7章：再見積もり」の「4. 部分的に完了したストーリーの再見積もり」も参考に。

「ピープルウエア」を読みました

事務所にあったやつをひっぱってきたので、最新でないちょっと古いやつ。名著と言われてたけど読んだことなかったし、今の立ち位置的に読んでおいて損はないと思って。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

第 II 部：オフィス環境と生産性

騒音、特に電話の話。電話という点では、うちにはそこまで影響がないとは思ってます。が、（別チームの）ミーティングがうるさい問題は以前ちょっと感じてたので、その辺を頭に思い浮かべながら読んでました。

なお、つい先日事務所引っ越しして、ミーティングルームが増えたので、今はかなり改善されてるのかなと思ってます。

第 III 部：人材を揃える

採用における「能力テスト」についての説明が気になりました。

その人物は、能力テストで測られた作業を2年間で終え、他の作業を20年間やることになるかもしれない。

採用の際には、今できることという短期的な視点だけではなく、長期的にどうなりそうかを重視するのがよさそうだというのを、改めて考える機会となりました（もちろん、今までも無意識的にそういう風に考えていたとは思いますが、改めてということで）。

第 IV 部：生産性の高いチームを育てる

組織のビジネス的な目標、例えば「今期の利益を2倍にする」といったものが、ダイレクトに個人やチームの目標と結びつくかは分からないという話。この点も、うちではある程度解消されているのかなと感じています。というのは、自分たちが作ってるサービスを自分たち自身でも使ってるので、「サービスをよりよくすること=自分たちも楽になる」というのが分かりやすく実感できる目標なためです。

とは言っても、「自分たちのサービスをよりよくする」だけじゃ足りないところももちろんあるので、やっぱりその他やれることはやっておく必要があります。という点では、この辺かな。

チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。

このチームの目的は満たされたとき、チームのメンバーはずっと効率よく働く。一体になったことでベクトルが合ったからだ。

これを達成するためにも、チームの目標が何なのかと、それを各チームメンバーにも意識付ける取り組みに注力しようとしてるところです。

---

全般的に、名著と言われるほどには自分が読み解けない点が多かった気がしました。もっと経験を積んだ後に読み直すと、また違ったものが見えてくるのかなあ。

「リーン開発の現場」を読みました

前回のカンバン仕事術でカンバンが気になってきたので、もう一冊カンバン系の本を読んでみました。少し昔の本ですが、カンバン仕事術が最近の本だったので、敢えて古めの本を手にとってみることに。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

第3章：デイリーカクテルパーティーに参加しよう

30人から60人の大規模チームにおける、デイリースタンドアップミーティングの効率的なやり方について。

こんな感じで、3段階に分かれてそれぞれデイリーミーティングを行ってるようです。

• 第1段階：機能開発チームのスタンドアップミーティング
• 第2段階：スペシャリティ同期ミーティング（テスター同士のミーティングや、開発リーダーミーティングなど）
• 第3段階：プロジェクト同期ミーティング（プロジェクト全体に関連するミーティング）

今の自分のチームの状況と照らし合わせると。規模がここまではないので3段階はやり過ぎ感があるけど、2段階で各チーム + 開発リーダーミーティング的なのはありかなと思いました。というのも、今は自分がハブになる感じで各チームとのミーティングを個別にやってるけど、それだとどうしても自分がボトルネックになりがちなんですよね。持続可能じゃない気がするので何とかしたいところ。

第16章：僕たちが学んだこと

「実験しよう」「失敗を抱擁しよう」とか、色々いい言葉が書いてます。時々、この辺の言葉を思い出したいです。

いくつか気に入った言葉をピックアップしておこう。

完璧な解決策を探そうとしてはダメだ。そんなものを期待して待ってもたぶん仕方がないだろう。
...
その代わりに、小さく少しずつできる改善点を探して、改善を実験だと考えてみよう。

失敗への恐怖が、改善の最大の敵だ。「なぜ俺達は失敗したんだ？誰がやらかしたんだ？」と問いただす代わりに、「僕たちは何を学んだんだろう？そして、次に何を試そう？」と聞いてみよう。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

たいていの人は変化を好む。でも、他の誰かに変えられるのは好まない。だから変化を起こすときは、影響を受ける人々をまず主体に巻き込まなければならない。

第20章：因果関係図

カンバン仕事術でも紹介されてたし、「なぜ5回」とかも呼ばれてるよくあるやり方だと思うけど、この本は説明が多く例が分かりやすかったです。これやらないと、何か気持ちモヤモヤしたままになったり、ひとまず一番最初に思いついた問題に対して（結果として表層的な）解決策を実施しようとかなったりするので、大事なことかなと思ってます。結構時間使うのでいつでもできることじゃないとは思いますが、ふりかえりと合わせて、自分も取り入れ始めてみました。

翻訳者の一人の@papandaさんのスライドも合わせて。

因果関係図で現場課題を捉えようワークショップ from toshihiro ichitani

www.slideshare.net

おまけ：5分で理解するリーンな「かんばん」

本書でもとりあげられてますが、このサイトのマンガ、カンバンやWIPの制限の紹介に便利なのでよく引用させてもらってます。

lean-trenches.com

「カンバン仕事術」を読みました

ちょっと読むのに時間かかってしまった、カンバン仕事術。最初読んでるときは、カンバンもよさげな開発手法だなとは思いつつ、実業務の中で活かしどころがイメージできてなかったのですが、読んでるうちにちょっと霧が晴れてきた気がしたので、2周読んだ感じ。

カンバン仕事術

カンバン3原則

• 見える化
• WIPの制限
• 流れの管理

カンバンって何となく、最初の「見える化」したものって思ってたのですが、それだけでなく「WIPの制限」とそれによる「流れの管理」も必須なんだなと理解できました。見える化だけでもある程度は解決するものもあるでしょうが、カンバンから継続的な改善を引き出すには後ろ二つが重要になってくると。

「流れ」対「リソースの稼働率」

WIPとリードタイムについて疑似体験するゲーム、コイン渡しゲームの結果を受けての一言。

逆に、最後のイテレーションでは、リードタイムは短くなりましたが、それぞれの作業者の作業時間は長くなりました。効率が落ちたのです。ですが、チーム全体としては一番でした。

「WIPを小さくして流れを早くすると、個々のリソース（開発者）の効率は落ちる」ってのは、目からうろこでした。ついリソースの稼働率を気にしちゃうけど、稼働率が max なのがそのままユーザにとっての価値につながるわけじゃないですもんね。ならば、稼働率にとらわれ過ぎるのではなく、リードタイムを短くして流れを早くし、より早くユーザに届けることを意識するのは理にかなってると思いました。

そのままキャプチャで抜粋させてもらいますが、同様のことを言ってるやりとりがこちら。これはがつーんときましたね。意識改革が必要なんじゃないかと思ったところ。個人個人がそれぞれで動くのではなく、チームとして動くべき一つの理由になると思いました。

デイリースタンドアップ

他の手法でのスタンドアップミーティングとは違って、「個人の作業ではなくてチーム全体の作業・流れについて着目する」ってのはなるほどなと思いました。

多分、この辺のことを意識せずに普通にスタンドアップを開くと、「昨日やったこと」「今日やること」「困ってること」をそれぞれ個人に聞く形式をしそうだなと思ってました。だけど、カンバンでは「ボードを右から左に歩く」つまり完了に近い方から見ていって話し合うというやり方がいいようです。

---

ほかにも色々実運用を考える際に参考になるところはあったのですが、大きく揺さぶられたのはこの辺ということで。カンバン使えそうな気がするので、もうちょい追ってみようかと思ってます。

「アジャイルコーチの道具箱-見える化実例集」を読みました

カンバン仕事術を先に買ってたのですが、京都遠征したときに@yohhatu, @posauneと話した際、まずはこっちを読んだほうがいいとアドバイスもらったので。

leanpub.com

いつでもさくっと確認できるように、iPhoneにPDFを入れておいた上で、気になるやつをブックマーク付けしておきました。ブックマークしたやつはいくつかに分類分けできそうなので、記憶の定着がてら、簡単に紹介します。

モチベーション上げる系

ちょっと反省点なのですが、ふりかえりなどでどうしても悪い点ばかり目について指摘しがちになってしまってます。言うべきところでは言わないといけないと思いますが、そればかりだとモチベーション的にもあーあーってなっちゃうので、悪い点を指摘するのではなくいい点を取り上げてうまくモチベーションを向上できるような仕掛けもやっていかないとなと、改めて思いました。

• 成果ポスター
• 時間通りのスタンドアップ + ハイスコア
• 遅刻はケーキ
• ごほうびビン
• 失敗ボード
• レース場

なお、偉そうなこと言ってる割に自宅でのモチベーション管理がまったくできていないので、家でも導入しようかしら・・・

仕事上チームのモチベーション管理も仕事の一つだと思うけれど、家ではうちの人に怒られてばかりで自分を全然モチベーション管理できずに生産性が上がらないので、どうしたものか

— ikikko@リアルJenkinsさん (@ikikko) 2016年5月7日

チームのコンディション確認系

↑のモチベーション上げる系にも関連しますが、チームのコンディションを手軽に見える化できると面白そうかなと思いました。口で「ツライわー」とはなかなか言いにくい人もいるけど、こんな感じでアイコンちょっこっと動かすぐらいなら朝会の前にでもぱっとできそうなので。

• 自信のニコニコマーク
• ストレスレベルのメーター
• チームのムードメーター

情報共有系

うちは拠点が分散してるのもあるので、通常以上に情報共有を意識しておかないといけないんですよね。その辺を見える化するためのやつもいくつか気にかかりました。

• サーバンドマネージャーのドア
• 私の学びたいこと

アジャイルレトロスペクティブズを読みました

スクラム現場ガイドに引き続き、今回はアジャイルレトロスペクティブズです。日本語では「ふりかえり」ですね。

スクラムでもいくつかスクラムイベントが定義されてますが、その中でもこのふりかえりが一番大事なんじゃないかなと思ってきました。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

レトロスペクティブの基本は、以下の構成に従ってるようです。

1. 場を設定する
2. データを収集する
3. アイデアを出す
4. 何をすべきかを決定する
5. レトロスペクティブを終了する

以下、それぞれ気になったことを簡単にピックアップ。

1.1 場を設定する

チームの約束（ワーキングアグリーメント）を最初に定めておいた方がいいと書かれてました。同時に、なぜワーキングアグリーメントが必要なのかの説明も。

基本的にはワーキングアグリーメントはチームそれぞれに特有のものになるから、他のチームがこうだからうちも真似しよう、というのはあまり意味がありません。とはいっても、どんなものを設定していいか、最初はよくイメージできないと思います。なので、うちのチームでは、下記のサイトを参考にさせてもらい、その上で自分たち特有のルールを話し合って決めました*1。

blog.guildworks.jp

3.2 集団ダイナミクスの管理

「集団ダイナミクス」と言われるとちょっと分かりづらいですが、「集団力学」もしくは「グループダイナミクス」と言われることが多いみたい。詳しくは、グループ・ダイナミックス(グループ・ダイナミックス)とは - コトバンクとかを。

集団ダイナミクスを管理する際の一つのアドバイスとして、「あなたが言葉」ではなく「私が言葉」を使っていこうとあります*2。例として、

OK：あるチームメンバーがビルドを壊したメンバーを非難した。「お前がちゃんとやってれば目標を達成できたんだよ！」
NG：「私が怒っているのは、目標を達成できなかったことだ。あのビルドを修正するのはとても厄介なんだよ」

な感じ。相手を一方的に決めつけるのではなく、自分がどう感じたかをもとに話を進める。ファシリテーションの文脈でも結構大事な要素だと思います。

その他にも、参加者の感情の変化について、注意が必要な状況とその対処方法についても述べられてます。具体的には、下記のような行動を参加者が取った場合。

• 涙
• 怒鳴る
• 部屋を出て行く
• 不適切な笑い・おどけ

自分も心の準備なくこういう状況に遭遇するとすぐにテンパるので、予めシミュレーションしておくことは効果的だと思いました。

5.1 タイムライン

ここからは、レトロスペクティブを構成する各アクティビティの紹介。

タイムラインは、チーム内のイベントを思い出して、年表形式に洗い出していくもの。割りとイメージしやすいしGWで少し区切りができるので、さっそく使ってみました。

毎スプリントレトロスペクティブでやるというよりは、ちょっと長めの区切りでやった方がいいかなと思います。実際、うちのチームでやったときも1月から4月末までを思い出す目的で行いました。

6.6 ドットによる優先付け

出てきたアイデアのうち、どれを選択するかを決めるときに使う手法。参加者が、決められた数の投票権をドットとして持ち、アイデアにドット投票していくやり方です。

これもさっそく採用しました。うちは基本的に拠点が分散してるので、あまり複雑な手法は取りづらいのですが、これはドットを書いていくだけでいいので、シンプルに導入できました。

7.2 SMARTな目標

• Specific （明確な）
• Measurable （計測可能な）
• Attainable （達成可能な）
• Relevant （適切な）
• Timely （タイムリーな）

の頭文字をとって、SMARTらしいです。

まあ個々はさておき、「計測可能な」というのが一番重要だと思ってます。計測できないと、達成できたかどうか分からなくて、結局流されてしまいますしね。

というわけで、何か目標を立てる際は「計測可能かどうか」を常に意識するようになりました。常に「計測可能なこと」が一番ですが、たとえ「計測可能かどうかちょっと曖昧」な状態でも、それを踏まえて次のふりかえりで問題があったかどうかを考えるようにしています。その結果、やっぱり計測可能にした方がいいと判断したら、改めて考えなおすことに。

7.4 短い話題

ここで、ふりかえりの手法として有名なKPTも挙げられています。

ただ、ここで触れられていたのは、こればかりやってると飽きがくるよとも言われてます。

イテレーションごとにレトロスペクティブを開いていると、1~2週間のインクリメントなどの短いイテレーションのときは特に、毎度おなじみのアクティビティにチームは飽きてしまう。

あまり色々やって、チームが新しいものに疲弊してもあれなので、飽きがこない程度にちょっとずつ新しいものを取り入れるなり、区切りでは別のアクティビティをやるなりを考えようと思います。

付録B 感想を聞くアクティビティ

ふりかえり中に問題を深堀りしていくことや、（ポジティブ・ネガティブ問わず）何かしらの意見を聞きたいことがあります。けど、「何で？」ばかり連発してても、聞いてる方は萎縮するときがあります。

このときのうまい質問方法について、少しだけ紹介されてました。何も意見が出てこないときに「何か一つだけ感想を述べるとしたら？」とか、まったく別の考え方をしてもらうために「もしも〜だったら」とか。

と、この辺のを読んでたときに、グッドタイミングで目に入ってきたので、また紹介しておきます。

blog.guildworks.jp

---

最後に、ファシリテーションについての参考資料として、- プロジェクトファシリテーションTOPが紹介されていました。今更ながらちゃんと読んでみて、そういやKPTの正しいやり方も知らずに亜流でやってたのがかなり凹む・・・。ちゃんと読んでおきます。

*1:厳密にはグランドルールとワーキングアグリーメントで適用されるスコープがちょっと違うみたいですが、まあ目的は大体一緒だから参考にするのはありかと思ってます。

*2:英語では"You language / You message"と"I language / I message"と呼ばれてるみたい。日本語より英語の方がカッコいいですねｗ