相談をストロングスタイルで受けてたつ

友人の相談

あれは昨年8月、新日本プロレスの真夏の祭典・G1クライマックス、Aブロック最終戦を観戦した時に、友人から相談を受けました。

友人「転職を考えてるんだが、転職を経験した立場としてどうなのか知りたい」(超意訳)

その時の答えは、

俺「まずは自分のスキルの棚卸しからじゃね?その上で今の会社で出来ること、そうでない事を整理した方がいい」

と言って放置プレーしてました。

そして、半年後

先日、その友人から連絡をもらいました。

友人「内定をもらったけど悩んでるので話をしたい」

その直後、回答した事は、 俺「そこまで行動したのに(=結果ももらったのに)、何に悩んでるの?」

彼とのLINEのやり取りだけでは「深く悩む内容じゃないよな」と思っていましたが、会って話をする事にしました。

彼とのやり取りをクラウドにしてみる

彼が解決したいことが何か、TOCのツールの1つであるクラウドを描いてみたら分かるんじゃないかと思い、話をしながら描いてみました。

その時に描いたクラウドf:id:kabe-aa:20180210192131j:plain

それぞれの箱の説明

今回の対立している行動は「今の会社に残る」と「今の会社を辞める」(図中の右側の上下の箱2つ)。

対立しているそれぞれの行動に対して要望を入れる(図中の中央の上下の箱2つ) 。
今回は、「今の会社に残る」の要望は「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」
「今の会社を辞める」の要望は「仕事の幅を広げたい」とした。

次に、これらの要望を満たす共通目標を決める(図の左側の箱)。
ここでは「自分の将来を考えたい」に落ち着いた。

納得感が得られるまで作り変える

クラウドを作成するときは、本人の話を聴きながら、要望と共通目標を何度も作り変えています。

実際は複数の要望が出ていますが、色んな要望や目標があった中から、自分も本人もしっくりきたものを選んだつもりです。

仮定を作り、矛盾を見つける

それぞれの箱を接続している矢印には、仮定(前提条件)が存在しているので埋めていきます。
その上で、論理的な矛盾を見つけます。

上側

「自分の将来を考えたい」(目標)ならば、「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」(要望)、何故ならば、「スキルが特殊である」(仮定)。
「スキルがあるので、今の会社でうまく仕事(を続けることが)できる」(要望)ならば、「今の会社に残る」(行動)、何故ならば、「今の仕事に慣れているから」(仮定)。

着目するべき仮定は「今の仕事に慣れているから」で、自分の将来を考えてるなら、「今の仕事のその先を考えて実践していかないといけないんじゃない?」と考えることができる。
つまり、「会社に残ろうが辞めようが、先のことを考えてなければ意味がないんじゃないの?」と言えるようになりました。

下側

「自分の将来を考えたい」(目標)ならば、「仕事の幅を広げたい」(要望)、何故ならば、「今の仕事がなくなるかもしれないから」(仮定)。
「仕事の幅を広げたい」(要望)ならば、「今の会社を辞める」(行動)、何故ならば、「今の会社での先が見えないから」(仮定)。

着目するべき仮定は「今の会社での先が見えないから」で「本当にそうなの?」と自分は疑問に思いました。
つまり、そこに、今の会社に残るための意義があるんじゃないかと思いました。

結論

どっちでもいいんじゃね?笑

自分の言葉で誘導しないようにクラウドを作成してたので本人の純粋な考えをまとめたつもりですし、結論も彼が決めるべきだと思うので。
※本人も相談前から「最終的には自分が決める事だ」と認識済み。

自分は、クラウドを描いてみて、彼の考えてたことを理解しましたし、彼にとって必要なものが何か見えたので、勝手に満足しました笑

少し話を発展させる

クラウドを描くだけだと、無責任感は否めないので笑。

俺「もし内定先の業務内容が似てるなら、どんな職場環境か、ある程度想像できるんじゃね?目標を達成できそうな方を選ぶ方が良くね?」 とは話しました。

共通目標が見えた事で初めて、行動を選択するための判断材料になったと思います。

ストロングスタイルな問題解決とは?

ストロングスタイル - Wikipedia

ぶっちゃけ、このエントリーを読んだ後、 「お前が言ってるのは、ストロングスタイルじゃねーよ!」 と思う人もいるでしょう。
解釈は人それぞれあるので許してくださいw

自分にとっての問題解決は「風車の理論」に近いと思っています。
かつてアントニオ猪木が言った「相手の力を9引き出して10の力で勝つ」というやつです。

ただ、ちょっと違う点としては、、、

相手の力を9引き出すのではなく、10引き出す

要は、相手の抱える不安や生の感情やら、全て引き出した上で問題解決できれば良いかな、と思います。

勝ち負け関係なく、ただ前向きに白熱すれば良い

最終的に、問題解決は本人にしかできないんですよね。

そのために、ネガティブな意見が出てこないように、前向きに話し合うことができたら、あとは勝手に問題解決してくれるんじゃないかと思います。

もちろん、答えが欲しいなら、答えを言っちゃうこともできますが。。。 そりゃあ、しょっぱい試合だった時は、そういうこともしますw

最後に

自分が提唱する「ストロングスタイルな問題解決」を、今回事例も踏まえてブログに書いてみました。

それがいつでもできる訳ではないですが、そんな風に意識して今後相談を受けてたちたいと思っています。

『ゆるファシ』体験ワーク、からの今年の抱負

NaITE #26 『ゆるファシ』体験ワークショップに参加してきました。

nagasaki-it-engineers.connpass.com

  1. ワーク体験
    やった事をざっくり、、、

    • グループ内で各個人が抱える問題を1つ説明して共有する。
      その時の背景や細かい状況は付箋にメモする。 話しているうちに別の問題が明らかになったら、新しい問題にする
    • 各人の問題点について、違いを捉えてみる
      違いを見つけるのは難しいので、最初に共通点を見つけてから、違いを見つける方が良いらしい。 
    • 違いや話した内容から、自分が解決したい問題を特定して、解決するためのアクションを決める
      グループ内で解決したい問題とアクションを宣言しました。
  2. 成果物
    自分の成果物はこんな感じ。
    「自分の作業の進捗が思ったように進まない」問題だったのですが、
    グループで共有しているうちに、「自分が始めた仕様のトレーサビリティの改善が定着しない」ことに気づいて、
    最終的な問題は「改善を進めた結果、自分の負荷が高くなっている」になりました。 アクションは、「他の人に任せられるようにする」です*1 f:id:kabe-aa:20180121121541j:plain

  3. 雑感
    自分が問題解決する際、TOCfEのツールを使って自分が感じた違和感を問いかけるように、本当の問題を見つけるようにしていますので「ゆるファシ」は、自分のやり方にしっくりきました。 でも、ゆるっとファシリテーターの、あのゆるさは正直真似できないなぁ(褒め言葉w

  4. 今年の抱負

実は、今年初めにマインドマップに抱負を起こしていたので、便乗して紹介(笑 f:id:kabe-aa:20180121121531p:plain

  • 会社に対する目標
    「業務時間に余裕を作る」の一つに「他人に作業を委譲する」って書いてたw
    あと、今年は勉強会を開催して、社員を向上していきたいかなぁ。

  • 個人の目標
    今年はプロジェクト管理のために、本格的にスクラムを学んでみようかと。 そのために、色々情報を仕入れている最中です。

*1:変えるときは、まずメンバーに合意とろうよ、自分(^^;;

2017年を振り返る

今年を振り返った。けっこう駄文w

f:id:kabe-aa:20171231102424p:plain

  1. 会社への計画

    • 自分の作業に余裕を作る
      6月あたりから、ほぼ上流設計しかしなくなった。けど、システムの要求仕様まとめるだけで今年は終わった。 。。 そもそも工数の都合でやってなかったので仕方ない… 要求仕様作成の経験者がいない、ってのも… まぁ、良い経験させていただいております(^^;;

    • 社員レベルの向上
      詳細設計、実装、(今までのレベルで)のテストは別の人に任せることができた。ただし1人だけど。
      今の問題は、自分に設計が依存してしまうこと。
      「どう設計してほしいか分からない」と言われるので結局自分で設計する羽目に。むー(; ̄ェ ̄)
      設計意図を伝えるような書き方を意識してたけど、自律的に向上させるためには、別の方法でサポートした方が良さそうです…   

    • 開発プロジェクトの改善
      当初やろうとしたことは手付かず…
      というか、グループ内の仕事改革が起きて、仕事の仕方を見直す場ができた。
      前半でキレて良かったかな(よくない笑
  2. 自分の目標

    • テスト力の向上
      今年は、某塾やモデルベーステスト自動化の分科会、他にも色んな勉強会に参加したので、色々学ぶことが多かった。
      (テスト設計ではなく)機能設計にはだいぶ反映されているかなぁ。。。アウトプットできる成果は今のところないけど。。。  
    • 設計力の向上
      機能開発以外は、ほとんど他人に任せた、と思う。 その分、他人の設計を読み取る力も身についた。  
    • 問題解決手法を学ぶ
      今年初めにTOCfEに出会ったのは大きいかも。 あと、エニアグラムの講習を受けた事で、自己理解・受容できるようになった。 自分が感じた違和感を適切な方法で伝えられる、良い方法を一緒になって考えられるようになった事は、今年一番の成果だと思います。  
  3. 当面の業務
    1つは完成して、必要に応じてアドバイスする程度なので、手離れできた。
    もう一つは、システムアーキテクチャごと変更してるので継続中…という言い訳してるけど、やっぱり見積もりは甘かったなぁという感想。
    でも、今一番欲しいスキルは、見積もりというより、メンバーの力をうまく引き出す方法ですかね。

  4. 最後に
    今年は、『ながーいトンネルの中でようやく光が見えた気がする』一年だった
    多くの出会いと学びをいただいて、皆さんに感謝です。
    来年もよろしくお願いします!

9人のテストエンジニア

この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2017」の20日目の記事です。

qiita.com

エニアグラムを使って、テストエンジニアの特徴を考えてみたいと思います。

エニアグラムについて

自己成長とコミュニケーションのための人間学』と呼ばれています。

f:id:kabe-aa:20171218103419p:plain
エニアグラム

詳しく知りたい方は、ググってみてください(許諾を得ていないため、リンクは載せませんw)

テストエンジニアにいそうな特徴を、エニアグラムのタイプ別に考えてみたいと思います。 私自身は認定コースを受講していますので基本的なところについては把握していますが、それでも個人的な主観が入ってしまうことをご了承ください。

業務で自分のタイプに囚われたり、同僚と対立を生まないため、特徴を理解したい想いで考えてみましたので、ご参考程度にしていただけたらと思います。 また、タイプは自分の強く出るところですので、他のタイプの良いところを自分のものにして行けば、今後の成長に役立てられると思います。

※ ステレオタイプに当てはめてしまって行動したり、相手の方を当てはめてしまうことを私は望んでいません。

タイプ1:改革する人(本能:ガッツセンター)

テストを抜け漏れなく確実に実施したり、周りがその通りに行動するような施策を作ることが得意だと思います。

ただ、不要なテストを省略せずに全数実施することで時間が足りなかったり、作った施策を周りが実施しないことにイライラすることがあるかもしれません。 タイプ7のように、自分のタスクを気楽に考えること、周りを楽しませるように施策を考えると良いかもしれません。

タイプ2:人を助ける人(感覚:ハートセンター)

自分の業務に関係なく、テストの準備を手伝ってあげたり一緒に実施するのが好きなのかもしれません。 でも、感謝されないとストレスが溜まる傾向にあると思います。

個人のタスクを達成する事。タイプ4を参考にすると良いと思います。

タイプ3:達成する人(感覚:ハートセンター)

テストアーキテクチャ設計など、先進的な考えを導入することが得意だと思います。 また、効率性が高く、少ないテストケースの実施で、欠陥の検出できるような特徴があると思います。

たとえ、設計が先進的であっても、プロジェクトに適合できるかの検証が漏れてたりします。 効率性を重視するあまり、テストケースに抜け漏れがあるかもしれません。

タイプ6のように忠実にテストを実施すること、十分な検証も必要かもしれません。

タイプ4:個性的な人(感覚:ハートセンター)

個人ワークで黙々とテスト作業することが得意だと思います。 プロジェクトに影響されずに自分で試行錯誤して解決することができますが、一方でプロジェクトの解決するべき課題にならない傾向にあると思います。

単純なテストケースの実施は苦手かもしれません。。。 感覚が優れているので、逆にテスト実施中に別のケースに気づくことがあると思います。 ただ、アドホックにならないようにしたいです(自戒の意味も込めてw

タイプ1のように、プロジェクトの課題として改善に繋げることが必要だと思います。

タイプ5:調べる人(思考:ヘッドセンター)

テスト技法や最新のアーキテクチャ設計方法などを自ら調べ知識にしたり、プロジェクトの問題点を分析することが得意です。 ただ、プロジェクト全体から一歩引いている傾向にあり、メンバーに知識を提供しますが、それが実施可能かどうかまで検討しない傾向にあるかもしれません。

タイプ8のように、プロジェクトの達成のために積極的にチームに入っていくことが成長につながると思います。

タイプ6:忠実な人(思考:ヘッドセンター)

単純なテストケースを実行すること、作業を着実に進めることが得意だと思います。 ただし、難しい課題に直面すると、全体像がつかめず一部の問題解決だけを追求することがあるかもしれません。 テストの網羅性を把握しない、組み合わせテストで全数テストすることがあるかもしれません。

不安を感じたり分からないことがあれば、全体に問題としてあげること。タイプ9のようにチーム全員で協調することが必要だと思います。

タイプ7:熱中する人(思考:ヘッドセンター)

興味を持った技法やテストアーキテクチャ設計をすぐ試したいと思い、周りを楽しく巻き込むことが得意だと思います。 ただ、自分の業務を分析せずに適用しようとしたり、反対メンバーに歩み寄ることを苦手とするため、最終的にグダグダになることがあるかもしれません。

タイプ5のように分析すること、反対メンバーがいたら意見を聞くようにすることが良いと思います。

タイプ8:挑戦する人(本能:ガッツセンター)

プロジェクトや自分のタスク達成のための目的を本能で理解し、周りを巻き込んで実行する力があると思います。 また、不具合が発生した場合にリスクや影響範囲を収集し、いち早く消化する事に優れていると思います。

ただ、実行力に優れている反面、スキルが低いエンジニアを置いてけぼりにする傾向があるかもしれません。 タイプ2のように、一人一人に歩み寄り理解してあげる事が良いかと思います。

タイプ9:平和をもたらす人(本能:ガッツセンター)

プロジェクト自体やメンバー全員がまとまっていて協調することに生きがいを感じ、ファシリテーションが優れていると思います。 比較的ゆったりとしたペースで作業しますが、自分のペースに合わない状況がプロジェクトで起こると、ストレスを感じるかもしれません。。。

タイプ3のように、成功や効率を求める考え方を取り入れると、自分と一緒にプロジェクト全体を成長させることができるかもしれません。

最後に

テストエンジニアとあまり関係ない気がしますね(笑) また、自身のタイプである4は、記述多めです(笑

自分で読み返して思いついたのですが、プロジェクトの各工程の抜け漏れを防ぐためのチェックリストとして活用できる気がしました。

よろしければ参考にしていただけたらと思います。

WACATE2017冬公開のBPP三部作、堂々完結

って、BPP賞をいただいた話から、半年間ブログ更新してなかった(汗

というわけで、WACATEの内容に関する事は他の人に任せて、前回のBPP受賞者が過ごしたWACATEについて書きたいと思います(笑

WACATE2017 冬 ~すべてがTになる~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

第1部:BPPセッション

自己理解をして、自身の日常や業務に役立てましょう』というライフハック方法の紹介です。
公開しているスライドでは、以下の内容をカットしています。 

  • 具体的な業務内容
  • ライフハックの元ネタ(このネタも含めた完全版スライドは来年公開するかも。今は伏せさせてくださいw)

www.slideshare.net

発表でやったこと、工夫したこと

  • 自分の緊張をほぐすため、最初に台本にないことを適当に喋って笑いをとる。
    今回は『初回参加の人を確認して、ベテランの暴走を抑制する』ことをしてみました。
    本当は別の事を話すつもりでしたが、、、(第02回ひとりラジオ BPPセッションで確認)

  • 全体を伝えておいてからの「話しません」で、徐々に本題に絞っていく

    • 1回目
      業務紹介した際。
      一応、BPPセッションの内容として、開発・テストの話も考えていたことを伝えるため。

    • 2回目(発表テーマに対しては1回目)
      だって、セルフコントロールコーチングの方法知らないもんw
      でも、自己理解できれば、最終的には繋がると思っています。

    • 3回目(発表テーマに対しては2回目)
      今回の発表の元ネタ(スライド非公開)なのに、話さないという暴挙に出た瞬間w


      元ネタを話し始めたらキリがなくなるし、そのワークショップを開催するためのアドバイザーの資格を持っていないので。
      でも、それを使わなくても、自己理解できることを紹介したかったのです。
      ライフハック」は、「別の言葉」から置き換えてツイートしてもらっていますw

  • 小ネタの応酬
    一つ目の手がかりにて言ったセリフ

    • 「『ピンときちゃった』ってどう言うことですか?」(某T社のCMの満島ひかりを意識して、人差し指を立てる)
      → 知らない人が多数と思われる(似てないとは思っていないw)。ただ、満島ひかりが好きなだけなので、言えて満足w

    • 「『父さん、妖気です』ってことですか?」(鬼太郎の妖怪アンテナが立った時に言いそうなセリフ)
      → 何人かがクスッと笑ってくれた。

    • 「『姉さん、事件です』ってことですか?」(ホテルの高嶋政伸のセリフ)
      → 語感が似てただけで勢いで言う。もちろんダダ滑りwwww

  • 発表内でのワーク

    • 簡単なケースを試してもらった。
      分かったからって「あいつは、このタイプだから嫌い」って殴り合いの喧嘩はしないでね。

    • 2つ目の手がかりのワークはやめた。
      WACATE実行委員から「時間超えるかも」「初めての人にはワークは難しいので、具体例を出して欲しい」というアドバイスをいただきました。 実際に自分のケースが思いつくだけでも1週間以上近く考えたので、最終的にワークをやめました。この判断は賢明だったかも。

  • 本スライドに影響を受けたもの

    • なそくんの2017夏のBPPセッションのスライド
      社外でよく見るLTのスライドとして参考にしました。

      www.slideshare.net

    • 第37回テストラジオ
      プレゼン資料の作り方は参考になりました。 twitcasting.tv

    • 進入禁止のテープ
      公開されないスライドにある素材だから、検索しても見つからないw なんとかフリー素材を見つけて使用しました。

    • IBM細川さんのプレゼン方法
      「初の社外での発表でインスパイアされてますよ、全く似てないですけどねw」と余談を入れてみる。
      「結果として自分らしいプレゼンが出来上がったし、スライドを作るためのモチベーションにもなりましたよ」って言いたかったの。

  • よかったこと

    • 発表しているときは、案外落ち着いていた

    • 30分ぴったり終わった
      普段は緊張しぃなのに、本番で強いのはなんだろね、とか思いつつw

    • ゴングを鳴らすことができたw

  • 悪かったこと

    • 語尾の癖
      自分でも気になるので、直したいところです。。。

第2部:夜の分科会

WACATEの夜の分科会のオーナーになりました。 やったことは「皆さんで自己理解してみよう」でした。

10人ぐらい集まったかも。嬉しい反面、モデレータとしての責任が。。。

分かったことは、

  • 好プレーって案外出てこない
    自分じゃ当たり前の事だから、案外好プレーは本人からは出てこないですね。。。
    もうちょっと思いつきやすい行動で、引き出し方を考えた方が良いと思いました。

  • 例えは、もっと難しい
    まぁ、承知の上だったので、聞き役になって引き出そうと思ってたけど難しかったw

最終目標として「キミはこの直感を使って、こんなのするのが上手いんだね。」と認識するところまで行きたかったけど、ただの自分語りの会になってしまったような、、、
でも、一人から「自分のことが分かった気がします」という意見をいただけて嬉しかったです。
もっと改善できるよう頑張ります!

第3部:夜の一人ラジオ

テストクラスタお馴染みの「なそとオカウチワニのテストラジオ」の「第02回 ひとりラジオ BPPセッション」のゲストとして参加しました。 今回の発表の裏話が聞けます。

twitcasting.tv

自分の声ってこんなんなんだ笑、しどろもどろだし、恥ずかしいな笑

今回のWACATEの雑感

今回は、セッションあり、分科会モデレータあり、ラジオパーソナリティあり(?)と、幅広く経験させていただきました。
セッションが終わった後は、登壇者の横でずっと聞いていました。特別席かっ!
小学校の授業で騒いで先生の前で座らされた気分にもなりましたがw

WACATEの詳しい感想は内容は後日載せるかも。。。

あと「コミュ力強化」をテーマに掲げていたので、自分の班のファシリテーションや意見の抽出を積極的にやらせていただきました。
6人中3人が初回参加でしたが、それぞれのセッションの目標を達成できるように意見を引き出せたかなぁ、と思います。
次回も参加してくれるといいですね。

WACATEスタッフの皆さん、開催までの間色々とご迷惑をかけてしまいましたが、とても貴重な経験をさせていただき、ありがとうございました。 そして、参加者の皆さん、お疲れ様でした。

WACATEでBPPをもらった話

すでに半月経ってしまいましたが(^^;;

6/17, 18の2日間、マホロバマインズ三浦で行われたワークショップWACATEに参加してきました。

WACATE2017 夏 ~技法はいつもひとつ(とは限らない)~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

そこで、ベストポジションペーパー賞を戴いちゃいました☆

伝わるポジペの書き方

今なら言えますが、自分が参加した過去2回のポジペ集を分析して、本気で狙いに行きました(どや

そんな訳で、とってもレアな、BPPを狙える(かもしれない)ポジペの書き方を載せますw

ポジペ投票メンタルモデルの構築

と大それた事を書いてみましたが、『ポジペを選ぶ時の考え方』を初めに考えてからポジペの内容を決めています。
「何書こう?」で悩んだのではなく、制約を決めてから、ポジペを書くための手札を選んだ感じです。

ポジペを説明する時間がない

3分程度で何を知ってもらいたいのか?印象を残せるか?

ポジペを読む時間がない

自分のグループ以外のポジペも空いた時間で読むので、やはり印象第一。
むしろ、自分グループ以外に伝える方が重要。

ポジペで考慮した事

自分がポジペを書く際に考慮していたのは、次の通りです。

自分がどういう人間かわかること

初めの自己紹介は2 行程度で書き、残りは「それがどんな事か、分かりやすく言い換える」事に注力しました。

言いたいことがたくさんあっても情報を絞る。びっしり書かない。

2016冬は『半年間の成果』を書いていますが、「成果を元に自分を知ってもらう」戦略は、分かる人には伝わるけど、初めて会う人には伝わらないのでやめました。
どんなに「WACATEらしく加速感」があっても、伝わりづらいことは書かない戦略にしました。

専門用語はあまり使わない。代わりに、誰にでも伝わるような言葉遊びを使う。

自分が「システム全体を俯瞰する開発者」と紹介した上で、全員が分かるような例えを使うようにしました。

最初の考えた例えは「山登りで先導する」「ジャングルを探検する」イメージ。
ただ、自分のやっていることがイメージとは完全に結びつきづらく、最終的に色んな言葉が置き換えることができる「 RPGシステム開発攻略」に落ち着きました。

自分が伝わる絵を用意する

RPGシステム開発攻略なので、ドラクエのマップを某サイトを使って夜な夜な作成w
マップもこだわり始めると、ややこしいものが出来るので、あくまで補助的なシンプルなものにしました。

全体が淀みのない文章で、線として繋がるように

自分が感覚で文章を捉える人間なので(笑)、
「目に飛び込んだ瞬間から自然と読んでた」ってところが一番大事かなぁと。

テーマに合致するように意気込みを書く

「2日間、よろしくお願いします」

最後の2つは、いいや(笑)
まとめてみると大したことない、人に伝わる文章の書き方なのですが、改めて意識すると難しかったですね。

閑話休題

ポジペのイメージを固めて書く前に、既存技術がないか調査したという事で。
楽天の川口さんの「ドラクエ風スキルマップ」を見て、自分が表現したいイメージとは異なったので、気にせずに自分の思い通りに表現してみました。
がっっ!!、5/26に行われたJaSST東北で「テストエンジニア版スキルマップ」の発表があり、「ドラクエ風」な部分が類似してて、その週末が〆切だったこともあり、少し頬を赤らめながら提出しました笑

とは言っても、

賞をもらった今だからこんなこと書けますが、実際、当日はもらえる自信はなかったです(^^;;

ポジペを書く時に使った観点で読むと、もっと良いポジペを書いた人がいましたし、実際自分は『意気込み』と『加速感』が一発で飛び込んできたもの(=自分のポジペから外したもの)を選びました(その子はやはりMAP賞でした)。
なので、今回の書き方の紹介は、受賞した1ケースと思っていただければ。

ポジペの書き方にこだわった分、新しい見方が増えて、よりWACATEの醍醐味を味わえると思います。

今回から賞状が小さくなって机上に飾る事ができる!
副賞はELASTIC LEADERSHIP。読みたかった本だったので嬉しいです。 f:id:kabe-aa:20170620233613j:plain

私のTOCfE BCトリロジー

はじめに

1〜3月にかけて、TOCfE BootCampに3回参加しました。

TOCfEとは

教育のためのTOC 日本支部

思考のための3つの道具と、1つの「問いかけ」がTOCfEで、主に3つの道具の使い方の訓練の場がTOCfE BootCampです。

tocforeducation.org

アンビシャスターゲットツリー

tocfebc.doorkeeper.jp

達成できないような目標を達成するために中間目標を設定し、行動を決めるのが「アンビシャスターゲットツリー」です。

「自分の望むソフトを開発したい」という目標に対して、

  1. 障害(緑の付箋)を洗い出して、
  2. 障害をクリアする中間目標(青い付箋)を出し、
  3. それぞれの中間目標の前提条件を決めて、行動(赤い付箋)を出しました。

f:id:kabe-aa:20170320154928j:plain

ブランチ

tocfebc.doorkeeper.jp

起こった問題に対して原因を洗い出して、それぞれの因果関係を作るのが「ブランチ」でした。

この時の演習では、「某外資系企業が開発した金融システムの移行が失敗した記事」からブランチを作成しました(実際は、記事の内容だけでは作れない一番難しい演習らしいので、「なぜ継続したのか?」という観点に変えてブランチを作成しています)

一番下の原因から始まり、一番上の結果に至ったという図になります。

f:id:kabe-aa:20170320155505j:plain

クラウド

tocfebc.doorkeeper.jp

対立する行動から共通目標を見つけ、解決策を見つけるのが「クラウド」でした。

「ウサギとカメ」の演習で、「カメがウサギを起こさずにゴールする」と「カメがウサギを起こしてゴールする」と言う行動からクラウドを作った結果、「カメはウサギに認められたい」と行った共通目標になり、自分の解決策は「カメがウサギを起こして、ゴールした後にウサギを讃える」となりました。

f:id:kabe-aa:20170320154246j:plain

最後に

TOCfEが効果を発揮するのは、仕事や家族で発生する問題におけるコミュニケーションの解決だと思います。

自分は、仕事で意見が衝突しても論破されるのを避け、問題を抱えたままにすることが多いのですが、このツールを知ってから「相手の考えも正しい」と少しずつ思えるようになり、このツールを使って相手の考えの理由を引き出すようになりました。

相手の問題を引き出すことができれば、コーチングのツールとして適切だと思います。

「相手の問題を引き出すためには、相手の気持ちを理解して聞くことが必要だ」と思って、エニアグラムをより深く学習したいキッカケになました。

TOCfE BCでは使い方を学ぶ訓練をする場で、実際に仕事やプライベートでガシガシ使えるようになるにはしばらく時間がかかると思いますが、どんどん使おうと思います。