『こんな時だからこそ状況を把握する ~SaPIDでふりかえる~』フィードバック編

この記事は,『こんな時だからこそ~』シリーズです*1

kabe-aa.hatenablog.com

kabe-aa.hatenablog.com

5/27(水)に,↑のエントリーを肴にワイワイする会が開催されました笑

www.kokuchpro.com

出てきた質問やアドバイスを元に,フィードバックを残したいと思いました. ただし,個人的な考えでありますので参考程度にしていただけたらと思います.*2

フィードバック

STAGE1で問題構造を確定してから実施するか,問題構造が出来上がったタイミングでSTAGE2, STAGE3を実施するか?

個人的には,ある程度STAGE1で問題構造は確定してから,STAGE2, STAGE3に移りたいです.

ただし,今回作成した問題構造はリアルタイムで起きている出来事で,対策可能な事象は暗黙的にSTAGE2, STAGE3を実施していると思います. 例えば,以下のことが挙げられます.

引き継ぎ作業に時間が取られている件

今月中の作業で,無事引き継ぎが終わったので問題構造図からは消えます. 代わりに新しい何かが出てくる可能性があります.

仕様書の修正が必要になっている件

スケジュールが遅れている原因の一つが 『開発規約に基づいて作成された開発計画に沿って実施していない』ことだと仮説を立てたので,引き継ぎ作業が完了した後に「仕様書を修正する」「テストを着手する」を実施し始めました.

大事なことは,対策した時に問題構造図を更新する事だと思います.

更新し続けるうちに問題構造図が安定してくるはずなので,そのタイミングでSTAGE2, STAGE3を実施してもいいかなぁと思っています.

今回の方法を使えば,一発で納得できる問題構造を作れるようになるのか?

答えはNoですかねぇ.

問題構造を書くと,新しい考えが出てくることが多いです. 特に,今回は3ヶ月以上前のの出来事をふりかえっているため,忘れていることが多いです. なので,何度も作ってみては,足りないものがないか確認してみることは必要だと思っています.

今回試してみた事を実践すれば,大きく問題構造図を変えずに済みそう,が自分の予想です.

問題構造図の作成で一番辛いのは,問題構造図を一から作り変えることだと思います. 今回実践してみて,一から作り変える羽目になる理由が,グルーピングの仕方にありそうだと仮説しました. なので,初めはざっくりグルーピングすることで,問題構造の変更が少なくて済むんじゃないかと思っています*3

ふりかえりにKPTを使わずにSaPIDを使った理由

こんな理由になります.

  • SaPID bootcamp以降使う場面がなかった
  • 一度ちゃんと教本を使って作ってみたかった
  • コロナ自粛で,自宅で考える期間ができた
  • 自分の業務がテーマにぴったりだった

スクラムみたいに短期間でふりかえるならKPTでいいと思いました. ただ,同じようなProblemが出てくるときは,SaPIDやTOCfEのブランチを使うことになるだろうと思います.

安達さんからも,KPTで出た事象を元に問題構造図を作るとよい,という意見をいただきました.

問題構造を作るのに,嫌な事を突き詰めないといけないのか?

自分の場合,嫌な事はあんまり考えないようにしています.

どちらかというと,自分の行動に興味をもっている感じです. 多くは脊椎反射で行動していることが多いので,その行動の理由を知る(もしくは仮説を立てる)ようにしています.

重要な事は,問題を突き詰める事ではなく全体感を把握する事だと思います.

大体作り上げた問題構造図から「やっぱり,この問題は避けられないよねぇ・・・」って絞られた時に,嫌な事に対してようやく重い腰を上げる感じでしょうか.

ただし,チームでふりかえる場合は,行動の理由の聞き方に注意する必要があると思います.

自分の問題構造から対策型が出てこなかったことについて

今思えば,開発スケジュールを決めるのに『CCPMを使った』が対策型だったのかも・・・

  • どうしてCCPMを使ったのか?(前提,起こった事)
  • CCPMを使った結果どうだった?(考えた事)
  • その結果,自分は何をした?(行動)

に置き換えていたので,結果的に対策型が現れなかったのかも.

自分が考えた対策を,自分自身が一番信用していないのかもしれません笑

クリアしたい問題を最初に定めることについて

クリアしたい問題を最初に定めることは,問題でなかった時にリスクがあるかも

と意見をいただきました.

自分の場合は「問題につながらないのであれば,それは逆に安心できるので成功」と捉えているので,確証が得られるまで集中して考えるイメージです. 初めの段階で,何かしら確証に近いものを感じていることが,そのモチベーションになっているのかもしれません.

ただ,チームで実施した場合は,メンバーが考えている事が出てこなかったり,思い込みに気づかないことが多いので,クリアしたい問題につながらない可能性がありそうです. 個人で実施した場合も,自分の行動をふりかえることに慣れていないと,うまくいかない可能性があることに,この意見で気づくことができました.

今回の方法は,あくまで一手法ということに留めていただけたらと思います.

まずは,問題構造図にしなくても,KJ法マインドマップを使ってグループ化するだけでも効果があると思います.

目標がモヤモヤすることについて

アウトカム(=外に出せる価値)を考えるようにしましょう.

というわけで,こんな感じの目標にしてみました.

信頼できる開発チームであること

こういう目標に変えると,着目するべき事象が変わってきて,問題構造が変わりそうですね.*4

目標の立て方は,TOCfEのアンビシャス・ターゲット・ツリーを使って,戦略的に目標を達成するとよいかも,とも思いました.

最後に

今回初めて,自分が主体的になったイベントを開催することになったわけですが,多くの学びがありました.

(ルールに沿って開発していないのがばれるから),自分の問題構造図を人に見せるのは恥ずかしい

『にわか』なので,自分より作るのがうまい人につっこまれるのが怖い

と思って,自信がなく,内心ドキドキしていましたが,みなさん優しくて安心しました. 逆に,質問をしていただいたり,アドバイスをいただけたりと,懇親会も含めて4時間も自分の問題構造図でワイワイできてお得な時間でした.

今回,企画してくださった安達さんと参加者の皆さんに感謝したいと思います.

また,個人的には,生々しい事例が出ていないという意外な事実を知ることができました. 当初は教本通りに実践してみる事が目的でしたが,最後までちゃんと使ってみようと思いました.*5

*1:なんとなく,シリーズ化されたw

*2:初めてだったこともあり,メモしていなかった事が激しく後悔...

*3:あくまで予想ですが^^;;

*4:次回あたりに,違う目標に変わってるかもしれませんw

*5:ちゃんとやり切れば公式の場で事例発表できるなぁ,って妄想しているw

『こんな時だからこそ状況を把握する ~SaPIDでふりかえる~』を考察してブラッシュアップしてみた

前回は、SaPIDの教本に倣って問題構造図を作りました.

kabe-aa.hatenablog.com

個人的にモヤモヤするところがあったので,その理由を考察して,問題構造図を修正していきたいと思います.

なぜ,モヤモヤするのか?

前回の最後に「なんかきれいにまとまりすぎてる」=あまり納得していない,で締めました.

まずは,なぜそう思ってるのか,個人的な見解を述べたいと思います.

メタ認知的な観点

wikipediaより引用すると,こんな能力らしいです.

現在進行中の自分の思考や行動そのものを対象化して認識することにより、自分自身の認知行動を把握することができる能力

ja.wikipedia.org

自分の場合は,エニアグラムのタイプ4の気質を使って,自分の問題構造図にこう感じました.

f:id:kabe-aa:20200517091640p:plain
「これが自分」ではないと思っている時の自分

自分自身を把握する方法は人それぞれだと思いますが,まずは問題構造図を作ったことで満足せずに,自分に対して,言葉を出して,問題構造図を説明してみるというのが必要だと思います.

ブランチ(TOCfE)との違いが原因か?

SaPIDとブランチのお作法の違いが,違和感の原因になってるのか考えてみました.

ブランチでは,因果関係を厳密に確認するため,次のように読んで違和感を見つけます.

  • もし原因A(,かつ原因B)ならば,結果として結果Cである.
  • もし原因Aならば,結果として結果Cである,なぜならば原因Bだからである.

SaPIDではこの確認を行っていないのですが,SaPIDでもやった方がいいのでしょうか?

自分の答えは否です. 理由としては,全体を把握するための工程だからです.

パズルを解くとき,こんな手順で進めると思います.

  1. 完成形の写真から,それぞれのピースがどこに位置するか大まかに決める.
  2. 範囲を狭めていき,徐々にピースの位置を特定する.
  3. ピースがちゃんとはまるか確認する.

SaPIDのSTAGE1は,パズルの作成工程の1に相当すると考えています. そのため,現段階ではブランチのようなチェックを行わなくてもよいと思っています.

まぁ,ブランチも,最初の段階では大まかに因果関係を決めているはずなので,どちらも同じ手法だと考えてよいと思います.

この問題構造図は失敗したのか?

すべての事象を出していない,この問題構造図は失敗なのでしょうか? 一度に,作りきらないといけないのでしょうか?

いや,そんなはずはないはずだ(反語)(笑.

いったん頭の中にあるモヤモヤが問題構造図に整理された状態で,頭の中はスッキリした状態です. 整理された状況と向き合ったことで、自分の本音や新しい気づきが得られると思います. 逆に,一度に作りきることは難しいと思います. 問題構造図を作ったことに満足せずに,作り変えていくとよいと思います.

不足している事象を追加する

というわけで,問題構造を作り変えていくことにします. 作り変える前に,以下の事を手掛かりに事象を増やしていきました.

行動の変化

最初は「時間がないから異常系はテスト後でもいいや」って思ってましたが,テレワークを実施したタイミングあたりから「やっぱりテスト前に異常系も実装しなきゃ」って変わってました.

どんな事を考えて実装していたか,時系列で出してみました.

まずは,基本的な実装の流れについて
  1. 1機能の正常ケースを試しに実装してみる
  2. ツールを動かしながら,ツールに必要な課題を洗い出す
  3. 1機能にテストコードを追加し,リファクタリングする

これは,自分の判断で進めた作業方法です(チームが決めた方法ではないところがミソ). この作業を,1機能の中で,納得するまで繰り返していったのですが,次のような事が起きていました.

異常ケースという沼
  1. すべて入力しないと,ツールが異常終了する.
  2. 正常ケースだけの実装だと,ツールが使いづらい(と感じた).
  3. 異常終了しないため,異常ケースを追加実装する.
  4. 異常ケースを追加すると,新たな異常ケースとなる条件が見つかる.

という沼に入りました.

機能改善という沼

また,不正に入力されたデータが入力された場合,こんな思考になりました.

  1. 入力データは多量の数値から構成される.
  2. 入力データが不正なのか判断することが難しい.
  3. 不正に入力されたデータは,実行する前にチェックできた方が良い(と思っている).
  4. 入力データに問題がないことをチェックできるように機能を改善する.
  5. 機能改善すると,新たな課題が見つかる.

状況の変化

周りの状況が変化しているので,それらも時系列で増やしていきます.

以下のような事象が出てきました.

  • 協力社員がやめるので,作業を引き継ぐ

この点について,時系列で起きた事を洗い出してみました.

自分が持つ不満

最後に,自分の持つ不満も出してみました. というか,自分の不満が出ていなかったことが,前回しっくりこなかった理由かもしれない笑

  • 職場のコミュニケーションが少ない
  • 自分が正社員で一番年下
  • 自分が仕事の内容が良く分かっていない
  • などなど*1

問題構造図を修正する

新たな事象を出したところで,改めて問題構造図を作ってみます. 今ある問題構造図は捨てて,一から作り直します*2

今自分がクリアしたい問題は何か?

前回は『スケジュールがもっと遅れる(かもしれない)』が知りたかったですが,新たな事象を出していたところで,以下の3つが気になりました.

  • 会社の開発規約に沿って開発していない.(だから,遅れているのではないか?)
  • 自分の責任範囲が増え,開発が進んでいない.(だから,遅れているのではないか?)
  • 自分が職場や人に相談しづらい.(だから,遅れているのではないか?)

1つ目から順番に作ってみることにしました.

問題構造を作るうえで,以下を気にしています.

グルーピングは,最初はざっくり,徐々に詳細化

『パズルのピースの位置を大まかに決める』ぐらいの感覚で,ざっくり決めていいと思います.

因果関係を作りながら,グループ内で細分化したり,グループ同士を大きなグループにまとめればいいと思いました.

グルーピングの名称について

グルーピング名称は,一般名称をできる限り使わないようにし,そのグループが何を表しているか,自分の言葉で示すようにしました.

起きた出来事・自分の考え・行動は区別する

少なくとも,この3つは分けるようにしました.

これらを一つにグルーピングしないように注意することで,ミスリードしないようにしてみました.

『会社の開発規約に沿って開発していない』の問題構造図(前半)は,次の図のようになりました.

f:id:kabe-aa:20200524182747j:plain
前半部

ここから分かったことは以下でした.

  • 開発規模の大きさに対する『悪魔のささやき』と,少しでも良い設計にしようとする『ささやかな良心』が存在したw
  • 設計の変更は,成果物に対する不安などからくる自分の弱い心がそうさせているw
  • いくら異常ケースや改善しても,設計変更はキリがないw

後半部は以下の通りです.

『ささやかな良心』によって作業した結果,『仕様書の修正』と『次工程への着手の遅れ』が発生している事が分かりました.

f:id:kabe-aa:20200524182750j:plain
後半部

次に,『自分の責任範囲が増え,開発が進まない』ですが,以下のような可能性がありそうした.(断定はできない・・・)

  • 今まで引き継ぎ対象が共有されてこなかったのは,職場環境が影響している可能性がある.
  • 自分の業務の改善依頼した結果,仕様書の作成作業などで自分の作業を忙しくなる可能性がある.
  • 自身の後退的な気質が影響してか,他人に無理強いをしないため,自分で作業を増やしている.

最後に,『自分が職場の人に相談しづらい』も入れてみましたが,今のところ,今の作業に影響を及ぼすところが見当たりませんでした*3

追記

レビューの実施の遅れが影響してそう…

感想

今回気を付けた点は,たまたまうまくハマったのかもしれませんが,結果的に前の問題構造図よりしっくりくる図が完成したと思っています.

なんとなーく「規模が大きかったとしても,自分の方針ではなく開発規約に沿ってたらスケジュール通りだったかも」って思っています(根拠はないけどw. 一方で,今回の設計だと成果物の品質は良くなかったと思いますので,その解決方法をSTAGE2で決めることになると思っています.

ただ,今,私が興味を持っていることは『開発スケジュールの遅延』ではなく『責任範囲が広くなってきて首が回らなくなりかけている』ことに作っているうちに気づきました. 実際は,もう少し時間が経てば『引き継ぎ』や『業務の改善依頼』が変わると思っています (引き継ぎは一過性な作業で,一方で,業務の改善依頼による仕様書作成は不要かもしれないと思っている). これらの状況の変化によって,今後の自分の作業内容も変わってきそうな気がします. そのため,その事象を確定させてから,STAGE2をやっていいと思いました.

最後に

安達さんの提案で,こんなイベントを企画しました.

www.kokuchpro.com

本音は,その場でみなさんの質問に答えられるか分からないので内心ドキドキですが,みんなでワイワイ意見を出していくことで盛り上がればいいなぁと思います.

*1:あんまりえぐい内容は省略w

*2:この決断に至るまで時間がかかりましたw

*3:まだまだ本音を隠しているかもしれないw

こんな時だからこそ状況を把握する ~SaPIDでふりかえる~

みなさん,自粛生活,いかがお過ごしでしょうか?

私は転職してから3か月以上,ある案件のツールを開発しているわけですが,コロナ禍の影響により開発スケジュールが不透明になったり,在宅ワークになったりと様々なイベントが発生しています. 同じ部内でもコミュニケーションが疎になり,情報が錯そうしがちです.

解決方法は様々あると思いますが,まずは,自分の状況を把握しておくことが必要だと考えます. 自分の状況を把握しておくことができれば,こういったことができるようになると思います.

  1. 自分の考えのもと,自分の状況を正しく伝えることができる
  2. 自分の部署や外部の,突然の状況変化にも対応する準備ができる
  3. 自分の状況が明確であれば,外部の状況に関わらず,自ら改善を進める事ができる

そこで,転職後から行っている業務についてふりかえってみようと思います.

今回は,SaPID(Systems analysis/Systems approach based Process Improvement methoD)を使います. 「ソフトウェアプロセス改善手法SaPID入門」に書かれている作成順に従っていきます. www.amazon.co.jp

自分のやり方が若干含まれるかもしれません.*1 また,半日でやったこともあり足りない部分もありますので,その点はご了承していただけたらと思います.

STEP0 ビジネスゴール・成果状況/テーマ共有

SaPIDを使って,やりたいこと(=目的)を付箋に書きます. やりたいことを実現した結果,得られる期待も付箋に残すようにします.

f:id:kabe-aa:20200510201310j:plain
STEP0

まずは付箋に書き出す

「あんなこといいな,できたらいいな」

って頭の中で考えているよりは,まずは付箋に書きだします.

書き出した内容を明瞭にする

書き出してから,より具体的でふさわしい言葉に書き直していきます.

初めは,

開発をふりかえる

でしたが,もうちょっと何をしたいのか掘り下げました.

ツール開発案件を進めて,やったこと・起きたこと,をまとめる

して,「『まとめる』ってどうすることやねん?」って考えて,

転職後の開発案件で,起きた出来事をふりかえり,状況を把握する

にしました.

あまり突き詰めない

あまり突き詰めすぎて目的が達成できなくなりますので,,ある程度明瞭になったら,次に進みましょう.

進めていくうちにより具体的になったり,本当に知りたいことに気づくことなんて,よくある事ですので.

また,今回は個人ワークですので,自分が理解できること,あとで疑問にならない程度なら次に進んでも問題がないと思います. 後で人に説明するかもしれないため明瞭にする必要があると思いますが,適切な言語化についても後回しでよいと思います.

STEP1 問題点の洗い出し・引き出し

ここでは,出来事を出していきます. 基本的にはSTEP0の注意事項と同じですが,1つの付箋の明瞭性にこだわらず,書き出すことに集中します.

まずは,大きな出来事から時系列に書き出す

自分以外の人も共通で把握していること

左から右方向に,時系列に貼るようにします. この後,深掘りする出来事の数に合わせて,間隔を調整すると良いでしょう.

f:id:kabe-aa:20200510202648j:plain
STEP1-1

各時系列に対して,出来事を掘り下げる

自分に対して,こんな質問をしてみましょう 自分がやった出来事や感情,他人がやったこと,など思いつくことを出していきます. ※途中で,黄色い付箋がなくなったので,黄緑色の付箋と混在しています.

この時,どんなことが起きたの?

より具体的な出来事を出すために使います. 最初に出した出来事の近い出来事の下あたりに配置しておきます.

どうして,この出来事が起きたの?

その出来事が起こるキッカケを出します.

その結果,何が起きているの?

その結果によって,起きた事や,自分が思ったことを出していきます.

今,何が不安なのか?

現在の状況で,不安があれば出していきます. 重要度を上げて,赤い付箋にしました.

f:id:kabe-aa:20200510202805j:plain
STEP1-2

STEP2 事実確認・要素精査

書き出した付箋の事実確認を,SaPIDの原則や禁則に基づいて修正していきます. TOCfEだとCLRの明瞭性と存在の懸念に該当すると思います.

教本に書かれている原理・禁則に基づいて,見直したことは以下になります.

共通理解の原則

付箋を分けて記載することで,同じ言葉を省略しがちになります.

  • 異常系をすべて想定していない
  • 機能の見積もりが不足する
  • 見積もりしたら,リリーススケジュールを超えている

おそらく,因果関係を暗黙的に含んでいるためだと思いますが,後で見た時に分からないという状況を避けるため,きちんと書くようにしましょう

  • 各機能は,考えられる異常系を洗い出したものになっていない
  • 各機能の見積もりは,異常系を考慮していない
  • 異常系が考慮していない見積もりでも,製品リリースのスケジュールを超過する.

また,

  • 画面を設計しないといけない

も,書き出したときは分かっていても,後でふりかえると意味不明なので見直します.

  • ツールの使い勝手を良くするため,画面を開発する

具体化の原則

抽象的な表現を避け,どのような状態や結果なのかを具体的に把握できるように記載する.

と教本には書いてあります. 実際に,以下の点を気にするようにしていきました.

数量,質に関するもの
  • 本来,必要な機能よりも,機能が多くなる

多い,少ない,良い,悪い,など比較に使われる形容詞は具体性に欠けるので,数量・質を明らかにします. もし,数量・質が具体的に出すことができなければ,何が多い・少ないのか,何が良い・悪いのか書きます.

開発期間,工数に関するもの
  • 製品リリースのスケジュールが短期間 
  • 見積もりしたら,リリーススケジュールを超える
  • 見積もりを半分にする
  • 1ヶ月遅れていることが分かる
  • スケジュールが遅れている

短い,長い,小さい,大きい,遅れる,早まる,など比較に使われる形容詞は具体性に欠けるので,具体的な日時,期間を入れるようにします.

また,どうして,それが発生したのかを具体的にします. 例えば,『見積もりを半分にした理由は何でしょう?』みたいな.

これらを新たに付箋に書き出していきます.

  • CCPMを使って開発スケジュールを計画した
  • 正常系だけならば,半分の工数で間に合うと思った.
  • 異常系は,最悪,一度テストを実施した後でもよいと思った.
思い込みに注意する

事実に反している事,間違って認識していることがないか注意します.

例えば,先ほど追加した付箋

  • 正常系だけならば,半分の工数で間に合うと思った.
  • 異常系は,最悪,一度テストを実施した後でもよいと思った.

は,なぜ『思った』のでしょうか?(イタタタ・・・

思った,かもしれない,(自分は良くないと思ったので)こうやった,などは思い込みの可能性があります.

他にも,こんなのが挙げられます.

  • 仕様書通りに作ったが使いづらい(と思った)
  • スケジュールが遅れている(かもしれない)
  • 使い勝手が良くなるように修正していく(自分が判断して行った)

そこから新たな事実を出しましょう. ただし,すぐに思いつかない場合は,まずは事実と分けて認識することが大事です.

不足型に注意する

『レビュー不足』『テストが不十分』といった内容は,不足の一言で問題を解決しようとしていて,具体的に何が問題なのかが捉えられていないです.

教本によると,このように見直すとよいです.

十分・不十分となっている内容を具体的に示す.不足していることで発生している出来事を明確にする.

例えば,

  • 一部,営業の要望を満たしていない

は,具体性に欠けるため,以下のように変更します.

  • 営業の要望である,暗号化の機能が未対応である
  • 営業が作ったデータの内容が,顧客が見られる可能性がある

本来は,具体的な営業の要望や,作ったデータを見られたらいけない理由を付箋に書きだしても良いですが,ビジネスに関わるためここでは言及しません(笑

対策型に注意する

『~基準が存在しない』のような内容は,その逆の一言で問題を解決しようとしていますが,実際は解決できるのか不明です(新しい問題が発生する可能性がある)

教本では,以下のように記載されています.

それがないために発生している困った出来事や状態を記載する

今回はそれっぽいものがないと思いましたので省略します.

f:id:kabe-aa:20200510202904j:plain
STEP2

STEP3 問題分析・構造化

時系列で出来事を整理したものを,今度は原因→結果の関係に図示していきます.

気になった目的,一つに絞る

すべての事象を因果関係に結ぶこともできますが,複雑な図になり,何を解決したいのか分からなくなるため,気になった事象に絞った方がよいです.

今回は,

  • スケジュールが遅れている(かもしれない)

に絞って,左から右方向に因果関係をつないでいきます.選んだ目的は右上あたりに置きます.

なぜそう思うのか?で繋いでいく

最初に選んだ目的を結果として,原因となりえる事象を置きます.

この作業は,TOCfEのロジックブランチや,CLRの因果・十分性の懸念にあたります. ロジックブランチの作法に従ってもよいですが,それよりもかなり緩めに作ります(個人的な見解.

グループ化し,整理する

因果関係をつないでるうちに,同じレベルっぽい付箋が出てくるので,グループ化していくことで,因果関係の線を少なくするようにします.

例えば『スケジュールが遅れている(かもしれない)』につながる,以下の3事象を『今,直面している事』とグループ化しました.

  • テストに着手できない
  • 仕様書の修正が必要になる
  • 現状のツールと同じ結果が得られるか分からない

ここまでで,こんな感じですね.

f:id:kabe-aa:20200510203111j:plain
STEP3-1

情報が足りないところを補う

一見,グループ化してまとまっているように見えますが,各グループの中身について理解できるでしょうか? いや,これじゃできないでしょ(反語)w.

後で確認した時に,なぜこのグループにしたのか分からなくならないよう,もう一度事象を見直すとよいです.

なんとなく因果がありそう,原因がつながっていない

また,写真の赤の矢印は,間に何かありそうな気がしますので,もう少し突き詰めるようにします.

そうやって,出来上がった結果がこうなりました(料理番組風に)

f:id:kabe-aa:20200510203147j:plain
STEP3-2

まとめ

今回はSTAGE1の現状把握までをやってみました. 問題構造図に起こしてみて,

  1. 今の自分の状況を正しく伝える
  2. 突然の状況変化への対応への準備

は,まぁまぁできたと思いますし,突然の変化にも対応できそうな気がします.

  1. 外部の状況の変化に関わらず,改善が進められる

は,STAGE2以降の課題になると思います.

それ以外にも次の事が分かりました.

時間が経ったものは忘れやすい

最初のころのことなんて,ほとんど覚えてないです. 短い周期で見直すことがおすすめです*3

自分でも何を書いたのか分からなくなる

時系列で並べていた付箋を,因果関係に変えると,付箋の内容が理解できなくなったり,意味が通らなくなったりします. 原理や禁則に従って,注意深く見直すことが大事だと思いました*4

おわりに

ただ,ちょっときれいにまとまりすぎてるなぁ,って思ったり・・・

グルーピングした名前が原則から外れているからなのかもしれないのか,感情がなく生々しくないのか,個人的にはもやっとしていますw.

(いつか)次回は,STAGE2について言及したいと思います.*5

*1:特にTOCfEのロジック・ブランチ,CLRに影響されています

*2:個性化の原則に反しますが,今回は考えませんでした・・・

*3:とか言いつつ,同じことを繰り返すんだろうなあ(^^;;

*4:とか言いつつ,意味が通らない付箋を書くんだろうなぁ(^^;;

*5:今回のSTAGE0とSTAGE1に修正が起きなければ、という条件付きですがw

2020年版・俺のトリセツ

たまには自分が学んできたエニアグラムを通して,自分の今までを振り返り,今の立ち位置について書いてみようと思います.

エニアグラムの理解について間違っているところもあるかもしれません. 私の勉強不足の点もあるので,温かく見守っていただいて,指摘していただけたらと思います.

初めに

エニアグラムは『自己成長とコミュニケーションのための人間学』と呼ばれています. 人の気質は9つのタイプに分かれるとされ,その気質によって性格が形成されると言われています.

私がエニアグラムを好きな点は,動物占いや血液型診断と違って,現在の自分の状態を確認して行動を変えることができる,相手との付き合い方を柔軟にできる点ですかね.

注意

こういう分類するものって、人をステレオタイプに当てはめがちです. 「きみ,B型かぁ(こいつ,めんどくさそうだなぁ・・・)」な事が起こりがちです.

もちろん,9つに分類している以上,エニアグラムでも同じことが起こりえます.

『育ってきた環境が違うから好き嫌いは否めない』ように,同じタイプだとしても両親や育った環境によって他のタイプが色濃く出るし,大切にしている価値観も違う.

エニアグラムを学んでいくと,こういった多様性を体感して気づくことができますが,それをエニアグラムを知らない人に短時間で説明するのは難しいわけで,どうしても他と同じように分類ごっこと勘違いを起こしてしまいます.

間違った理解をして使い方を間違うと,人を傷つける凶器となってしまう可能性があります.

このエントリーでは一般的なエニアグラムは書きません. 自分のことを中心に,気づいた事を書きたいと思います.

3年前のエントリー

ちなみに,3年前のエントリーではテストエンジニアで例えて投稿していました.

kabe-aa.hatenablog.com 今となっては,表面だけなぞって知ったかぶりしている感じで,今となっては恥ずかしいw

自分について

私はタイプ4です. エニアグラムを知らない人に,あえてステレオタイプ的に表現すると「個性的な人」です. こんなパターンが当てはまります.

  • 独特な感覚を持っている(アーティスト気質)
  • 感動に浸りやすい
  • 「きみ,変態だよね?」と言われることに喜びを感じる(笑

だいたい本に書かれている事を要約すると,こんな感じ.

「こんなんでタイプ4理解した気になってんじゃねーよ!」って世界中のタイプ4がきっと思うわけですよ(笑

というわけで,ここからは『タイプ4』としてではなく,『私』として説明していきます.

「あなたの気持ち,よく分かるよ」に心が過敏に反応する

人に悩みを打ち明けて,「あなたの気持ち,分かるよ」って言われると,心の中はこうなっていることが多い.

f:id:kabe-aa:20200417052006j:plain
サイドエフェクトではありません

ハートセンター(2, 3, 4)の中でも,感情が複雑に入り組んでいるらしい(自分自身,他のタイプの感情の傾向が分からないしw). 加えて,その複雑な感情を言語化する事が苦手で,悩みの大半は事象ではなく感情なので,言語化された悩みの部分は少なくなりがちです.

絞りだして言語化された悩みの奥底にある感情の波を察してほしいので,「あなたの気持ち,分かるよ」は,「こんな事象が起きてて,あなたは~な気持ちで,~なくらい辛いんだね.」と解釈しているのですw(気持ちの部分はもっと複雑).

いやー,自分,めんどくさいな(笑 *1

ちなみに,タイプ4に相談した場合,この感情は不思議と起きないのです. 心理的安全性の状況に近いのかもしれないですが,

  • 感情的な部分も含めて理解していると感じている.
  • もしくは逆に理解してくれなくてもいい.

のどちらかなのかもしれないですね.

勘違いされる行動

手順通りに行動することが苦手

決まったプロセスで実行する事が昔から苦手です*2. プロセスがあっても,まずは自分の感覚で進めていくことの方が多いです. 後でプロセスを確認した方が,自分が体感したことと照らし合わせることができて,内容を理解できるのです.

『手順を確認しながら実行してもいいんじゃない?』と思う人もいるかもしれない. 書いている事や聞いている事を,リアルタイムで理解することが苦手なんだと思います.

もし,規律に従わないといけない仕事や,規律に従うことを重んじるタイプ1のような人と仕事をしていたら,自分はストレスを感じるかもしれない.

ただ,協調性がないと勘違いされがちですが,実は目標に向かっている事には一切ぶれていないのです*3

周りと同じ行動をしたくないと思う

同じように,勘違いされる行動です.

全体目標を達成するために,自分が同じことをしてていいのか?

他の人ができるなら任せて,他の人ができない事をやった方がいいのでは?

という考えが,自分の中で常に働いています. そのため,他人があまり気にしていないけど,重要だと思うところを見つけては対応する傾向にあります.

ただ,その必要性を自分の感覚だけで感じていて,言語化が苦手なので,話さずに進めることから,勘違いされることが多いのだと思う.

規律が苦手?

本当は,自己成長のためには必要な事だと思っています.

ある時期,規律を大事にしたときがありましたが, どうやら自分の考える『規律を重んじる』は自己成長につながらない事が分かりました*4

身近なところにタイプ1がいたら相談してみたいです. 一方で,ガチ説教されそうで若干恐れてる自分もいますが(笑.

コンプレックスと嫉妬心の塊

人と同じ行動をしない理由としては『自分には才能がない』と思っていることが根底にあるかもしれない(人はそう思っていないとしても).

どうやら,他の人が考えるコンプレックスや嫉妬心とは違うらしい(自分は他のタイプの傾向を分からないのでw).

  1. 自分は才能がないと思ってるので,他人のどんな才能にも憧れる.
  2. 自分のものにするために,他人の行動をマネすることから始める.
  3. しかし,どうしてもその人の実力にはいつまで経っても達しないと感じて落ち込む. (実際に僅差で,見た目まったく遜色ないとしても).

実は,自分が憧れているのは,その人の行動ではなく才能であり,もっと言うと才能の背景にあるその人の生き方そのものだから当然っちゃ当然なんですけどね.

ただ,今では,私にとってのコンプレックスと嫉妬心は,自分の弱みでも,他人を脅かすものではなく,自分にとっての重要な成長戦略と捉えています.

周りの感情に影響されやすい

子供の時の親との思い出や今までの経験上,どうやら,この傾向にあるらしい.

  1. 「あなたって○○なんでしょ?」と言われる.
  2. 自分では何も思っていなかった事なのに「そうなのかな?」と思い始める.
  3. 不快でなければ,その人に合わせるために,そういう自分を演じるようになる*5
  4. しばらく経つと,自分が本当に感じている事とギャップを感じるようになる.
  5. 結果的に辛くなって演じるのをやめる.周りからは突然変わったように思われることもある.

この傾向に見つけたことで,ある事に気づくことができた.

相手の気持ちや考えに合わせることで,その人に興味があることに気づいてもらいたい,と自分は願っている.

どんなに相手に気持ちを合わせても,相手がそれに気づくわけねーじゃん、なに期待してんだよ(自問自答). 気づく以前に,その人は自分の事にそもそも興味ないんだから,頑張ってもムダじゃん,と.

自由気ままと思われてもいいじゃない. 他人に気遣っている人間だと思われなくて,病んでもしょうがないじゃない. だって,自分はタイプ4だし,みんなもそういう色眼鏡で見てるんでしょ?(笑

実は,これくらいの気持ちで何も求めない方が,ちょうどいいのだと思う.

愛や感謝が苦手?

直接的に表現することも苦手だし,見返りを求められることも嫌いです. しかし,私にこれを求めてくる人もいる.

そんな人から私を見ると『冷たい人間』『私のことを愛してない』と思うらしい. でもね,自分にとってのミッシングピースであり,1つ前にも書いた通り,表現方法が違うだけで相手に愛や感謝を伝えようとしてるのです(照

f:id:kabe-aa:20200419181506j:plain
とっても不器用さんです

ただ,僕だって直接伝えようとするときがあるし,見返りを求めるときがある. だけど,それでも理解*6してもらえないから,だんだん内にこもり始める. 実は,愛や感謝の表現の変化は,自分にとっての精神的な危険信号なのです.

f:id:kabe-aa:20200419181808j:plain
自分の危険信号だから

最後に

今,自分にとっての居心地の良い状態は,こんな感じだと思います.

  • 周りは一定の距離を保っている中,それよりも少し離れた距離がちょうどいい距離.
  • 興味がなく自由気ままのように見えるが,周りの状況は把握しようとしている.
  • 周りに何か危険信号が出たら,(近づいて)助けに行くと思う.

ただし,これがベストだとは思っていないです. みんなと同じ距離にいたいと思うし,みんなと状況を共有したいのだけど,今はこれが精一杯なのです。 また,周りや自分の状況の変化次第なので,囚われないようにしないといけないと思っています.

来年以降,このトリセツをアップデートしていきたいです.

*1:タイプ4の事例が文献に載ることが少ないと思っているけど,もしかしてそういったクレームが多いのかな?w

*2:プロセス改善が好きなのに…

*3:ただし,目標自体を,他の人と違う理解をしていることはよくありますw

*4:セキュリティポイントと呼ばれます

*5:適切な表現が見つからないが,演じるがしっくりする

*6:自分が求めてる『理解』の要求レベルは,直接的な表現じゃないからな!(あぁ,本当にめんどくさい性格だw

試用期間が終わって

4月に入り試用期間が終わりましたが,巷を賑わすウィルスでいつクビにされるか分からない状況を戦々恐々としています笑*1

ご無沙汰しています.

試用期間中に思っていた,入社してみて変わったこと,良かったこと悪かったことをつらつらと書いてみたいと思います.

初めに断っておきますが,あくまで個人の見解であり,所属組織の公式見解ではありません.特定の組織の現状を示すものでもありませんw

今は何やってるの?

社会インフラ全体に関わっている会社で,ソフト開発者をやっています. いわゆる組み込み系ソフト開発者ですが,周辺のソリューションも含めてバーリトゥドですね.

3ヶ月経ったけど,大きな不満も特になく過ごしています. まぁ,試用期間だから責任範囲が狭いからなのかもしれないけど.

無駄な作業、お仕事ごっこが少ない

とにかく自分の仕事に集中できてる感じがします. 「こう感じてる理由って何だろうね?」と考えてみたら、どうやら雑務が少なく,やるべき仕事に集中できているからかもしれない.

メールが使いやすい

「メールは何を使ってますか?」は,入社前手続きで人事に尋ねた質問でもあるw

Outl○○kはそんな好きではないが,過去に使っていたN○tesに比べたらはるかに幸せである. 転職してストレスが減った大きな理由かもしれない。

とにかく,N〇tesが嫌だった思い出しかない.

  • はっきり言って,UIが古臭い.
  • メールが思い通りに編集できない.他からコピペするとメールのレイアウトがおかしくなる.
  • 同じバージョンなのに,マニュアル通りに設定できないことが多い.
  • ネットワークが切断するとソフトが固まる.つまり,WI-Fiで使うことを想定していない.
  • (組織の問題かもしれんが,)スケジューラが使えてなかった

明らかにオワコンなツールで,不便さで仕事の効率を落としていると思うのだが,「N○tesじゃなきゃヤダ!」とか言って置き換えを妨げている古い人間がいたんだろう・・・

N○tesから離れた今は,息するように仕事をする事って,こういうことなんだと実感してます.

どうあるべきだと思っているか?

業務やプライベートの作業を便利にし効率化するために,ツールが存在すると思います. 世の中のトレンドに合わせて,ツール自身も使いやすくなったり,逆にトレンドに対応できず淘汰されたりしていると思います.

業務の妨げになり結果的に会社の貢献に影響しているのなら,使っているツールは見直すべきだし,自分たちの仕事をよくするためには好き嫌いにこだわらず積極的に採用していきたいなぁと思うわけです.

出退勤時刻の入力作業が楽

以前はこんなことをしていました.

紙のタイムカード

紙のタイムカードを打刻してExcelファイルに毎日記入していました.

それだけなら「古い会社だから・・・」と気にしないんだけど,タイムカードの時刻が会社のチャイムと一致していない事が個人的に嫌でな・・・

通勤電車の間隔が長く,定時時刻から数分後の電車に乗らないとその後の予定に間に合わないので,定刻のチャイムとほぼ同時に打刻するのだけど,定時時刻に達しないので,その後の訂正で面倒なことが起こる. 定時時刻に帰ることが悪いみたいだった・・・

Excelファイルに作業内訳を入力

タイムカードの打刻時刻をExcelファイルに転記した上,どんな作業に工数を使ったか内訳を入力していました. ただ,案件別の内訳ならともかく,案件ごとの内訳(仕様書作成,実装,打ち合わせ,など)に時間を入力してました. 予算の出所が異なる案件別ならともかく「そこまで内訳を細かく入力する必要あるの?」って思っちゃうわけで・・・

メトリクス測って改善するなら,実際のプロジェクトでRedmineのチケットでやる方が適切だと思いますし,実際メトリクスを測定することも改善に使われた記憶もないので,やはり無意味な作業だったのかな?と思うわけです.

提出日はタイムカードとExcelファイルの間違い探し大会

提出日は,Excelファイルをプリントアウトして間違いチェックをしてました. この作業って自分だけでなく,上司がグループメンバー全員分,総務の担当が全社員分チェックしてるわけで,無駄の多いし,仕事ごっこなんですよね.

今はどう違うの?

ウェブから勤務時間の入力だけです. 自社開発というのもあるけど,案件別に時間を分けることもしていない. PCの稼働時間と差異があった場合に理由を書くくらいです.

今の状況が究極的ではあると思いますが,こういった日次の作業の蓄積って地味にQoLに効いてきます.

どうあるべきだと思っているか?

ツールと同じように,当たり前のように行っている作業も見直していくべきだと思います.

勘違いした最適化ではないこと

もちろん安易な見直しは良くないと思います.

例えば,目の前のExcelファイルのマクロばかり良くしても,全体的に俯瞰すると,本来解決したい事から考えると改悪しているかもしれない*2

今の会社は,昔がどんな状態だったのかは知らないけど,局所最適ではなく全体最適になるように見直ししてきたんだろう,と感じます.

変えるための強い意志をもった組織であること

また,変えられる・変えようとする強い意志と行動力を持った組織であることが不可欠であると,今の会社で働いてて思います.

以前は,上の方から,同じ職場から,四方八方から,やらない言い訳*3・変えられない理由*4を何年間も聞いてきました.

リソースの制約もあり優先度があると思いますが,いつまで経っても言い訳ばかりで前に進まない組織よりだったら,少しずつでも前に進める組織の方がいいですよね.*5

その他

部活動がある

会社にサッカーグラウンドがあって地域に提供しているのは知ってたけど,まさか卓球部があって,会社に練習場があるなんて思わなかった(笑.

グループ会社に勤めている知り合いに入社を話したら,入社日の入社手続きが完了するより早く入部扱いになっていた(笑*6

社内の勉強会がある

社内にアジャイルの勉強会があった.

今まで社外に出ないと得られなかった情報を共有できるので嬉しい.

社員を大事にして,社員の成長を考えている

まだよくわからないが,そんな感じはする. 前職と比較してという前置きが必要かも.

前回エントリーの『消滅したプロジェクト』で起きた事・感じた事が関係していると思うので,別の機会にでも書こうかな,と…

まとめると

自宅を出る時間が早くなって,平日の疲れ方は前より早いはずなのに,自分のストレスがだいぶ減っていると感じてるので,結果的に転職してよかったと思う.

また,改めて,自分が大切にしている価値観が見えてきたと思っています.

でも,見えてきただけじゃダメですね. ちゃんと自分から実践できるようになっていかないと.って思う次第であります.*7

*1:4/1現在,まだ有給が付与されてないw

*2:本人は改善した気になって,それ以外方法がないように思い込んでるから,余計タチが悪いんですよね(苦笑

*3:何年間も「今は変えるための時間がない」とか・・・

*4:「お上から指摘されて変えられない」とか・・・

*5:そういう組織はいずれ消えると思う

*6:最近は自粛モードなので練習してないけど…

*7:一番悩んでるところ.誰かに相談しようかなぁ…

退職します

今年いっぱいをもって、現在勤めている会社を退職することになりました。 本日が現在の会社の最終出社日で、有休消化なしで次の会社は1月1日付入社になります。

80歳、90歳になったとき、自分のありたい姿に近づいていたい

転職の理由はこんな感じかねぇ。。。まぁ、面接でも話したから間違いではない。

ただ「お前のありたい姿ってなんやねん」って言われたら、残念ながら具体的なイメージはない。 今までの延長で仕事をしてるかもしれないし、田舎に住んで農業をしてるかもしれないし、もしかしたら縁側でぼんやりお茶を飲んで毎日を過ごしているかもしれない。 はたまた、純喫茶のマスターをやってお客さんの悩みの相談されているかもしれない。 でも、案外、アリだと思うんだよ。 コードレビューや設計レビューしてくれる純喫茶のマスターって(笑)。

その時何をやってるかは、その時に近づいたときの自分と周りの状況次第によって決まると思っている。 逆に言えば、今は何にでもなれると思っている。 40歳過ぎてるのに、まだまだとんだ勘違い野郎なのだ(笑)

ただ言えることは、周りの状況は変えられないけど、自分の状況はこの先の生き方次第で変えられると思ったわけで。 気に入らない事や奴らに文句ばかり言って状況を嘆いているだけで過ごすだけだと、この先の可能性は狭まると思った。 だから自分に後悔がないように主体的に行動していきたい。

今はソフトウェア開発者だけど、もしこのまま続けるのであれば、今持っているスキルをもっと伸ばしたいし、必要だと思うスキルを身につけたい。 と思って転職に至った次第である。

転職の決意が決定的になった出来事

転職の理由は必ずしもポジティブな理由だけではない。 今年の4~9月に携わった業務が、転職の決意を決定的にさせた。

チームを成長させながら目標を達成するプロジェクト運営

Crab Inc.が技術書典7で初頒布した"300 Multiple Choices"に寄稿したタイトルで実際の出来事である。 techbookfest.org

4月に今までの開発業務とは異なる、新しい製品開発のプロジェクトリーダーになった。 そのプロジェクトは、開発が1年半近く遅れ、ようやくファーストリリースが済んだばかりだった。 当時はデザイン思考に興味を持ってて、仕事で試してはミーティングで報告していたので、そこに白羽の矢が立った形だった。 開発者が精神的に疲弊している状態の中、親会社のPMが「次の機能は3か月でリリースする」と計画したことから指名されたのだった。

私は指名された時点で、不確実性のあるプロダクトであることから、今までやっていたウォーターフォール的な開発ではなくスクラムで開発することを宣言して、PMからも同意を得ていた。 結果的には、3ヶ月の最初の1ヶ月で機能のプロトタイプが完成していて、残りの期間では機能の充実に充てることができた。 それだけでなく、初めて計画通りに達成できる可能性が見えたことで、開発者たちが開発に対するモチベーションを取り戻していったように感じた。

ATTで運営したプロジェクトがメテオフォールによって消滅した話

ここからの内容は『理想のTOC』でLTした。詳細は非公開。 *1 「おぉ、すげぇ」って声以外にも笑いと悲鳴を5分間の間で聞くことのできた非常に濃い内容(当社比)でしたw。 *2 tocfebc.doorkeeper.jp

結論だけ書くと、開発していたプロダクトは、結局リリースされなかったのだ。 プロジェクトは開発中止となって親会社が引き取る形になり、9月までは納品物を収めるためのドキュメント作業になった。

このブログ読んでいる人には、なぜこうなったのか、意味が分からないと思うの(笑)。 現場で開発していた人間ですら、こんなことが起こるなんて普通思わないくらい、ありえない結末だったんだよ。

結果的に成果を出せなかったのだから、この期間のエンジニアとしてのポートフォリオは皆無と言っていい。 今後の自分にとっての生き方を考えていたこともあり、会社に対する不満が積もり積もった上でこの有様だったので、これ以上働き続けても自分のためにならないと判断した。

退職した今だから言えるけど、6ヶ月の間に、成功と失敗、天国と地獄、プロジェクトのライフサイクルをジェットコースターのように体験することができたのは貴重だったと思うよ。 ウォーターフォールからスクラムに変えた事例なら今どきどこでも聞けるけど、良い結果が出ていたスクラムをやめさせられた事例なんて逆に聞かないからな。*3

やめることが〇〇だった(○○には会社名が入る)

今の会社に入って仕事でやりたいことを比較的自由にやらせくれたことも、この会社に入って、いや、会社に採用してくれた上司の下で働くことができて良かった事だと思う。 *4

かつて、新日本プロレスを一度退団した柴田勝頼「やめることが新日本だった」と言った。 自分の気持ちを説明すると、この一言に集約される。

残り3週間、僕は諦めない

これから自分は自分の思う道を進むわけだけど、残されたメンバーが気がかりであって。

だって、今まで自分が作った開発インフラを理解せずにタダ乗りして「うちのグループは業務改善してるんだぜっ」ってドヤってたんだから、自分がいなくなった後はロストテクノロジーになることは予想ができるわけで笑。 メンバーに必要な事を残していくことが恩返しであり、自分の使命だと勝手に思うことにして、年内の最終日まで対応することにした。

とは言え、自分がやったことは、自分が構築した開発インフラを引き継ぐのではなく、『トレーニング』と称して何人かに開発インフラの一部の再構築を指示しただけ。

それだけで、各々が勝手に進み始めて、分からないところがあったらお互いに情報共有するようになったんだな。 結果として『私が構築した開発インフラ』ではなく『彼らが構築した開発インフラ』として引き継ぎできちゃった。

彼らはエンジニアだし、いい大人なので、やる事さえ示してあげれば、開発インフラなんて構築できちゃうのである。

逆に諦めたこともある

入社以来、TDD(テスト駆動開発)で開発してテストコードを残してきたけど、最後の最後までグループには普及しなかったなぁ。。。 こればっかりは「メンテナンスにコストを払うことになるので、今後やらないなら削除してくれ」とお願いしてしまったよ。

今までの派生開発で、不具合再発防止のためのテストケースの再利用も大きな工数削減が求められてこなかったから、 テストコードを作って開発するような強い動機にならなかったんだろうな。。。

ストロングスタイルという亡霊に縛られないこと

TDDが無駄なものになってしまったのも、彼らを指示待ち状態にしてしまったのも、彼ら自身の『しなければならない』意識と自分の『意見が強かった』ことが原因だったのかもしれない。

『しなければならない』という思考に陥ってることで、その先の価値が安易になっている気がした。 「うまくいったらどうなるの?」と質問しても、回答があまり共感ができないんだよな。。。

また『意見が強かった』ことで、彼らが本音を言えなかったのかもしれないし、実際やりたくないということも薄々感じてはいた。 もし、自分がナラティブアプローチができたら、もう少し状況が変わったかもしれないなぁ。。。

これからは、本来は自分たちで意見を出し合って、納得のいく答えを出していってほしいと思う。 そのためには、彼ら自身が縛られているもの・依存しているものに自分たちで気づいて、そこに囚われることなく意見を出すことができれば、もっと良い状況が作れるのだろう。

自分がいなくなることで、今後は強制的にそんな状況になるのかもしれないし、そうならないかもしれない。 今後は、彼らに直接関与することはできないが、外から彼らを見守りたいと思う。

最後に

って偉そうなこと書いて、何きれいにまとめようとしてるんだろ笑。 *5

次は、この会社で学んだことを新しい会社で活かして活躍していくことが、この会社にとっての最後の恩返しとなると思う。 まずは、研修期間中にクビにならないように頑張るわ。

*1:プロジェクトが成功してたら、TOCfEシンポジウムにプロポーザルしてたな。。。

*2:知りたい方がいたら、会ったときにでも話しますし、なんならスライドも見せますw

*3:2度と経験したくないし、自分の周りにもそうさせたくないけど

*4:当時の役員が、履歴書の写真の印象だけで落とそうとしたところを、上司は面接してくれたらしいw

*5:そして、まったくまとまっていない笑

2018年のふりかえりと2019年(駄文)

2018年は何したっけ?

例年より濃い1年だったような気がするくらい記憶がない笑

エニアグラムアドバイザー3級げと

前から興味を持っていた、エニアグラムのアドバイザー3級を取りました。 最初に一緒に受講した人は1級やファシリテーターになってるというのに、現在は2級取得に向けてのんびり受講しています笑

SaPID bootcamp参加して、以降SaPIDファンに

元会社の同僚から紹介されて、2月にSaPID bootcampに参加しました。 昨年、TOCfEの国際認定プログラムを取ったのもあって、問題解決やファシリテーションが好きになってきた時です。

とてかで初社外LT と 謎のプロデュース業w

5月に「とちぎテストの会議」に行ってきました。 初めて社外でLTを挑戦してみました。 「おもしろいボードゲームの観点」を、WACATE18夏の夜の分科会を、非公式にLTで宣伝するという笑 そして、自分はWACATE18夏に参加しないというw

TOCfE認定ファシリテータげと

8/11~14に渋谷で行われた国際認定プログラムのグループサポーターを経て、認定ファシリテータになりました。

今年は、TOCやTOCfEとの関わりが強かった年でした。
2月にTOCfEシンポジウムに参加、
4月からbootcampのお手伝いをし始めて、
11月はTOCシンポジウム参加と「ハナバナ」での発表しました。

社内での勉強会の開催

2~3月に、会社の所属しているグループを対象にTOCfEの勉強会を開催しました。
6月には、新人研修としてTOCfEを教えました。
7月は会社の改善発表会で、TOCfEと勉強会を発表して一等賞をいただきました。

現在は、新しくグループに入ったメンバーにTOCfEを教えながら、グループメンバーを対象にテストの勉強会をしているところです。

今年は何がやりたかったっけ?

人に任せる

やってるような、やってないような笑
単に人不足なのか、業務に対する影響力が弱いのか、とにかくできない。

少なくとも、他の人にしてほしい業務は、全面サポートしながらやらせるようにしてる。 自分は困りごとを解決するというスタンスで認知されつつあるかなー。

スクラムを勉強し始める

年初に読んだカイゼンジャーニーは良かった。 スクラムではないけれど、TOCfEやSaPIDを使って仕事が進められている状況ではある。

2018年を総括すると、どーなのよ?

TOCfEとエニアグラムを知って見方が180度変わったのが2017年であれば、現実を思い知って迷走したのが2018年なのかもなぁ。。。

  • 自分に対する周りの見方は変わらなかった

この印象が強かったな。。。個人的には結構つらい。。。

  • 自分は人に伝えるのが下手すぎる

自分はエニアグラムのタイプ4な人間で、共感力が強く周りの人の様子から感じ取る事に長けてるのですが、逆に自分が伝えたいことを理解してもらえないらしく。
どうにか伝えようとすればするほど、タイプ4に囚われて自分自身は暗黒面に落ちていく。 。。
昨年末のエニアグラムのワークショップで、暗黒面に落ちる瞬間に気づくことができてよかったと思います。

2019年はどうする?

今年は自分自身が成果を出すことを中心に考えていこうかな。
あとは「人へ伝える事」をどうにかしたいかな。

今年もよろしくお願いします。