事実を分ける事に気づく

前回、A3作成に時間がかかっている事を紹介しました。
時間がかかっているのは事実を中心にまとめる事が出来ず
何度も修正する為なのですが、

指摘する前に、事実を中心にまとめる事が出来ない事、
これまで、いかに事実をもとに考える事をしていなかったか
という事に気づく人も出てきました。

こういう瞬間があると、活動を継続して良かったと思います。

そして、不思議な事に、こんな瞬間に閃きも生まれます。
事実を分ける事もせずに、ただただ、やった事を記載してしまうのは
まさしくプロセス思考の強さでは？！　との仮説がふっと湧き出てきました。

プロセスを実施していけば、成果となる。
という思い込みというか、習慣、慣習が、資料にも表れ、
とにかく、やった事を記載する。

やった事（行動、プロセス）は、結果、成果に必ずつながっている筈
というアサンプションだと思うのですが、
最近は、このアサンプションは癖の域となっていて、かなり根深い気がしてなりません。

繋がっている理由や根拠を明示していれば問題無いと思うのですが、
明示している事はとても少ない気がします。

しかし、それがA3を作成する事で気づく人もいる
この事実は勇気となり、モチベーションとなりますね。

恐らく、A3だけで気づいたのではなく、
それまでの布石があっての気づきかと思います。

このような人を増やす為に、もらった勇気を力にして
地道な布石活動を継続しつつ、
気づける仕掛けをもっともっと考えていく必要がありそうです。

やっぱりA3は難しい？！

ふりかえり活動の3ヶ月の結果をA3プロセスとして
A3一枚に記載する各項目をパワポの各スライド一枚にまとめています。

やった事をまとめるだけなのですが、
A3をまとめるのには時間がかかっています。

パワポにした事で、比較的前半（背景から目標まで）
は、比較的早く、順調に仕上がります。
問題は、この後ですね。
一枚になっていないからか、各スライドが繋がらない...

恐らく「やった事」を書いてしまうので、繋がらない気がしています。

アクションした結果（事実）を中心に
ストーリーとして繋げる必要があるのですが、
どうしてもやった事を中心にまとめようとしてしまう...

そう考えるとA3が難しいのではなく、事実を中心にまとめる力の問題？！
なんとなく他の資料も同じ傾向がある気がしてきます...

ですが、A3にまとめる事で3ヶ月が見えてきます。
新たな気づきも多くあります。

ここがA3の魅力ですね。
現状では時間はかかりますが、やる価値は十二分にあります。

慣れてくれば必ず早く書けるようになるので
しばらくは辛抱ですね。

プロセス思考の弊害

本来のプロセス思考とは違うと思うのですが、
ソフトウェア開発において、手順（プロセス）が染みついていると
弊害がありそうです。

問題解決などでは、
How思考から脱却する必要がある事は広く知られていると思います。

ソフトウェア開発では、
そのHow思考が更に手順として積み重ねられ、
開発プロセスとして定義されているように感じます。

もちろん、各プロセスの目的、インプット、アウトプット(成果)や
質に関する指標値などが定義され、それがチェックされていれば問題はありませんが、
ほとんどがプロセスとして、行動や手段だけが分岐の無いフローチャートのように、
ただただ実施されている気がします。

このような状態では何も変わらないし、価値創造は程遠いですよね...

このように行動や手段が独り歩きしている事で、
2つの弊害があると考えています。

１つは、気づきを得れない

TEFCASを活用して、事実(Event)を上げて、気づき(Feedback)を得る
という、ふりかえりを実施していますが、
事実から気づきを得る事が課題となっています。

当初は事実を上げる事が課題となっていましたが、
これは予想していましたし、ある程度対応策は考えていました。
そして、事実が上がれば、気づきは自然と得られ、そこから改善が回り出す。
と簡単に考えていたのですが...

そう簡単には行かないようです。
気づきが無いので、何も変える必要が無く、
ふりかえりの時間がムダに感じる　という悪循環となります。

2つ目は、状態定義が手順になる

気づきを得る為に、How思考から脱却する為に
FRTを活用して細かく状態定義をしていく事をTEFCASと合わせてやっていますが、
なぜか定義した状態が手段や手順となります。

状態が手段や手順なので、
ふりかえりでは、出来た出来ないといった、OK/NGの結果となってしまい、
このケースでも気づきが得れません。

この2つの弊害は、プロセス（手順）ありきの思考によるものでは
と考えています。
プロセスを疑わない、思い込みであり、アサンプションかと思うのです。

こんなところにもアサンプションが？！
という感じですが、さて、このアサンプションをどう打破していくか！？
手掛かりはまったくありません...

事実、気づき、ナラティブ、マインドセット

以下のセミナーに参加しました
『サービスデザインシンキング セミナー 〜最新動向と組織への浸透〜』
今回は講義がメインでしたが、改めて気づく事も多く、
とても有意義で楽しい時間でした。

強く感じたのは、以下の２点。

１つは、事実(Facts)から気づきを得る！

TEFCASも同じアプローチです。
TEFCASに出会ったときに、ソフトウェア開発にもこの考え方は必要！
っと思ったのでTEFCASにて取り組んでいるのですが....

事実(Facts)　と　気づき　の間には、
とても高い壁か、大海原があるようです...
とてもとても、この間が遠いのです。

もちろん、気づける人もいますが、
プロセス思考というかフローチャート思考というか、
手順思考というか、

行動のみで、やる事が組み立てられていると
これが遠い気がします。

一方で、行動と状態が、ある程度分けられていると、
気づき易い気がしています。


それともう１点は、ナラティブとマインドセット

マインドセットは必要ですが、押し付けるものでもないので、
具体的にどうやって作っていくのか、悶々としていましたが、
今回のセミナーで、

ナラティブにより、マインドセットが醸成されていくのだろう

と、ふと繋がりました。

DialogicODでは、
ナラティブから生成的イメージという流れですが、
その間にマインドセットが入る方がしっくりくる感じです。
ナラティブからマインドセットを醸成し、生成的イメージへ

そのためにも、いよいよナラティブを実践する場を作る必要がありそうです。

さて、ナラティブの実践まで考え続ける日々の始まりです。

 

決断の積み重ね

ソフトウェア開発においても
事実を積み重ねようと取り組んでいますが、なかなか積み重なりません...

事実を積み重ねて、中間状態を達成し、３ヶ月後の目標達成する
というシナリオで事実を積み重ねようとしているのですが、
それなりに中間状態を達成していく場合でも、
事実の積み上げになっていない感じです。

イメージの問題かもしれませんが、
現状は、事実を元に決断を積み重ねている感じです。

よくよく考えてみれば、それは当然の事で、
これまで事実を上げる事も
明確な状態定義もする事なく、
大きくはプロセスに従って行動してきた為、
思考錯誤しながら事実を上げたり、明確な状態定義をしている状態です。

こんな状態では、積み重ねるどころではなく、
なんとか、具体化する事で状態を明確にして、事実をひねり出し、
それを振り返って修正している状態です。

修正出来ていれば、積み重なっているとも言えると思いますが、
まだまだ横道に外れる事も多く、重ねるイメージにはほど遠い感じです。

しかしながら、こんな状態でも、決断を積み重ねてはいる気がするので、
決断の軌跡を後から見ても分かるように、かつ簡単に残せないかと考え始めました。

多くは、気づきから決断している筈なので、
この2つをペアにして、分かり易く、かつ簡単に残せるのが良いのですが...

TOCでいえば、アサンプションを疑って得た事、それにより決断した事を残したい。
現状では、アサンプションは書き出しているが、疑った結果は残せていない。
アサンプションを記載するフレームを変更する事で残せるだろうか...

具体的な例を元に考え直す必要がありそうです。

自分の言葉

Dialogic OD　のワークショップに参加して、
ナラティブ(Narrative)を知り、
それ以降、自分の言葉で話す、語る
という事について考えています。

ソフトウェア開発業務の中で
自分の言葉を使っている人
自分の言葉を使ってコミュニケーションしている技術者は少ない気がしています。
誰もが使う、抽象的な表現で曖昧なまま開発が進んでいる気がするのです。

多くの人が自分の言葉で表現するだけで、
認識違いが明確になり、齟齬なく開発が進むのではないかとも思います。

メタファーのように同じ言葉を使う事も重要ですが、
そのメタファーを作り上げる事がもっと重要な気がします。

自分の言葉で表現して、
互いにぶつかりながら、コンフリクトしながら創り上げるメタファーだからこそ、
意味があるのだと思うのです。

「自分の言葉」がなんだか分かり難い気もしますが、　
あまり難しい事ではなく、
具体化する事、細分化する事、詳細なイメージを造る事
で、自分の言葉が創られていく気がします。
はじめは、教えられた言葉、人が使っている言葉を使っていても、
それを少しずつでも具体化していく事で、少しずつ自分の言葉になる気がします。

アジャイルはCool過ぎるぅ！！！！

最近、またアジャイルが凄いと思う。
XPはやっぱりすごい！　と以前も思ったが、

いま、改善を進めていく中で、
アジャイルはとても軽くて確実に成果の出るやり方（考え方）だと
強く感じている。

改めて「アジャイル宣言」を見て納得する（何度も納得している...）

ドキュメントに関する考え方も書く事による弊害を上手に避けている気がする。
ドキュメントが無くても
問題が起こらないように、メリットがあるように工夫をしている。

それが「プロセスとツールよりも個人と対話を」かと思います。
こう考えると、ここのツールにはドキュメントも含まれている気もしてきます。

当然必要なドキュメントは作成するのですが、
「必要なもの」の判断基準が何か？　が問題ですよね。

価値あるソフトウェアを早く提供する為に必要なドキュメントは作成する　
という事ですよね。

常に不要なものは何かを考える。
常に価値あるソフトウェアを早く作る事に集中する。
結果的に、そこ向かわない全ての無駄が排除される。

更に、アジャイルはプロセスやレビューなどの形骸化をも
上手に回避していると思うのです。

形骸化すると、何も考えずにプロセスを実施する事が目的となる。
形骸化とドキュメントは強い関係にあり、
ドキュメントに頼らない事、細かいルールを決めない事で、
無駄の発生源を上手に断っている。

とヒシヒシと感じています。

そして、なんともカッコイイのが、
このような事をウダウダと語るのではなく、
「常に価値あるソフトウェアを早く作る事に集中する」
とシンプルに表現している事！　

多くを語らずシンプルに宣言している事が、
たまらなくカッコイイ！！！