キャラ設定がカギ：TOC+全脳思考

未来からの現状把握やってみました。

3ヶ月後の目指す姿、なりたい姿を設定し、
今から、3ヶ月後の目指す姿になるまでの波乱万丈物語を作る！

手法としては、TOCのUDE、DE、FRT(状態を設定するだけの簡易FRT)
全脳思考のフューチャーマッピング（こちらは本を読んだだけですが、ぶっつけチャレンジ）
を使いました。

まずは、毒出し含めたグチ＆UDE出し。
UDEの厳密なチェックはせずに、とにかく吐き出させる

次に簡易FRTの作成
3ヶ月後の「なりたい姿」、「目指す姿」を設定し、
そこから、1ヶ月後、2ヶ月後を設定する

プロジェクトの状態により、1ヶ月後から設定し、
その後2ヶ月後、3ヶ月と設定した方がスムーズな場合もありそう

次に1ヶ月後を目指したTryとその予想結果（仮説、仮説Event）を設定

ここで区切り。
ここまでの結果は1枚の紙に付箋紙でペタペタ貼ってある。

その後、フューチャーマッピングの作成
いろいろ考えましたが、やり方は書籍には従わず、ところどころ変えました
ですが、チームの状態に合わせて、やり方はスタンダードからフルカスタムまで
臨機応変に対応していきたいと思っています

まずは、キャラ設定
例を3つほど提示し各チームでチーム全員が知っているキャラに設定する

次にFRTに設定した3つの状態を
マップの各3ブロックに当てはめて、サブタイトル、概要を記載

次に、記載した概要やタイトルを元に、
ストーリーを考えつつ、予想される波乱万丈の線を記載

次に、変化点に起こりそうな障害や問題を記載

次に、全体ストーリーを作成し、書き込み

ここまでを1枚の紙に書き込み＆付箋

最後に、2枚の図を見直し、調整＆修正

ここまでで、各45分弱ずつで90分弱で全て終了
2チーム合同で実施しましたが、TOCを知っているのは一人だけ
ほぼ全員が、ここで活用する手法は一切知りません。

で、差が出そうなのは、キャラ設定
ここがスムーズに行くと、ストーリー作成は盛り上がる
割り込むのが申し訳ないくらい盛り上がってました。

キャラ設定に難航すると、その後の線も書けない
で、今回は、無理にキャラ設定せずに、
どんな感じで進みそうかを検討し線を書いてもらいました。

振返って考えると、キャラ設定する方が、俯瞰できている感じがしました。
目指す姿になるまでの障害や対策を、
ストーリーとしてあれこれアイディア（意見）が飛び交う感じです。

意見が沢山出た結果、
最後の見直しでは、キャラ設定したチームは2ヶ月後、3ヶ月後のTryが設定されました。
これだけで、かなりFRTっぽくなります。

結果的に、2つの図は補間し合う感じで、好感触でした。
あとは、振返りで足元（現状把握）が定まる事を期待して、2週間後を待ちます。

失敗を達成する？！

先日、GEの「ファストワークス」の話を聞きたくて、
とある無料セミナーに参加してきました。

顧客価値を中心に
MVPなどによる「学び」を生かす為のサイクルが実践されているようです。

Feedbackを得てそれを顧客価値に繋げる仕組み作り。
「仕組み」というより、「考え方」という感じですね。
現在取り組んでいる本質思考道場とまさに同じ考え方なのですが、
取り組み方が徹底していて、その本気度に圧倒されました。

圧倒される中、今更ながらの発見がありました。
「Feedbackを得てそれを顧客価値に繋げる考え方」
を、そのまま人事制度に取り入れている点です。

新たな人事制度といっていますが、
「Feedbackを得てそれを生かす考え方」を
そのまま取り入れているだけだと気が付きました。
なぜ、そんな当たり前の事に気が付かなかったのか？！

考えてみれば当たり前な感じもします。
個人やチームで価値創造する事がミッションとなるので、
価値創造に繋がる学びや気づきを評価しないと、その先に繋がりませんよね。

これまでは、顧客に価値を提供する仕組みと
個人やチームを成長させる仕組みの人事制度が相反していると感じていたような気がします。

ビジネスそのものが不確実性が高い現代では、
チームや個人の成果も不確実性が高く計画出来ないのが実情かと。
それを無理に計画しても、
『リーンスタートアップ』に記載されている通り、
「計画を忠実にかつ的確に実行する事に成功した結果、失敗を達成してしまう」
事になってしまいますよね。

良いものはなんでも取り入れるのがGEらしいですが、
当たり前の事にも気づいて、それも当たり前のように取り入れていく点も流石ですね。

道具とタイミングと...

TOCやリーンには様々な道具があります。
これらを自身で使うの比較的容易ですが、

他人に、これらを提供するタイミングは非常に難しい...

タイミングを間違えると、間違えた使い方となり、
効果が無いなら影響も少ないですが、最悪の場合はマイナス効果となりかねません。
そして、更には、その道具の印象が最悪となります。
正しく使えば、効果はあるのですが....

これらは、全て見えない、見え難い事
が起因して起こるのかと考えてみました。


大工道具で考えると
切る、叩くなどでは大きく間違える事は無いですが、
具体的な「叩く道具」の使い方としては、間違える事はあるかもしれません。

より正確に叩く為に
より綺麗な仕上がりにする為に

など、目的により正しい使い方があると思います。

こちらも目的を明確にしていないと、ただ叩くだけの動作となり、
結果的に、釘が曲がったり、自身の指を叩いたり...
とムダが生じて、最悪は事故となる。

この点は、ソフトウェア開発でも全く同じですね。
見え易い、見え難い、に関係無く、
目的を意識して正しい使い方を考え、動作や考え方を修正していく。

では、見え易い、見え難い
が関係するのは、
他人の動作から学ぶ事が難しい点か！？

とも考えましたが、
これも違いそうです....

匠の動作、及び目的って
動作をまねる事はもちろんの事、理解する事も
とても難しい気がします。

ただ、結果が違う事だけは、見える事で分かり易い。
というより、これ以上の説得力はないですね。

結果が圧倒的なほど、
その結果から、動作、目的を考える事は比較的、容易なように思います。

更に、そこから動作をマネた時に、そのマネた動作を比べる事
も容易に出来そうです。
比較した結果の違いも見えるので、分かり易いですね。

見え難い事が起因して
このような段階を踏む事が難しい！
という事になるでしょうか。

そして何より問題なのは、ソフトウェア開発の「結果」が見え難い点ですね。
ここから始まるのに、
ここを圧倒的な結果として見せる事はとても難しい....

結果が明確で、圧倒的な説得力のあるものとして見せる！
う~ん...また悩む日々が続きます....

また出会いが！

前回のブログを書き終わり、

社内ブログを記載する為に、とある古本屋に行くと、

なんと！？

やはり、前回のネタは体系化されていた！

https://www.amazon.co.jp/dp/4478008361

この中には「TEFCAS」という方法について記載されていて

更にそれを補完する「全脳思考モデル」により強力に結果を出す方法として提唱されています。

私は「TEFCAS」も「全脳思考」も全く知りませんでした。

「TEFCAS」は脳が本来持っている特性を最大限に生かす方法という事なので、

意識している事はほぼ同じですが、TEFCASは想像以上に強力なアプローチのようです。

「TEFCAS」を簡単に紹介すると、

Trials（Try-alls）：思い付く小さな実験を全てやる

Event：小さな実験の結果（事実として捉え、成功／失敗とは捉えない）

Feedback：結果から成功に到達する為のインプット

Check：インプットの信頼性をチェック

Adjust：目標実現に向けての調整

Success：具体的な成功イメージ（脳へのインプットであり、ここが起点）

という感じです。

Eventのところがまさしく悩んでいた事で、

失敗と受け取らせる事が良いのか悪いのかを、今年の4月頃から悩んでいました。

「失敗」の捉え方が人により違うと思うのですが、

TEFCASでは、成功、失敗で一喜一憂するのではなく、

目標達成へのインプットとして捉える事が重要との事ですので、

純粋にインプットとして捉えるには「成功」も「失敗」も言葉としては使わない方が良い

という事なのでしょうね。

サッカーの名将の言葉から「思考」の違いを次のように表現しています。

『名将は未来に勝利することから逆算して現在の事象の意味を自分に問う。

　それに対して、多くは現在の事象の成否を延長して未来を調整してしまう。』

過程（試合中）では、成功も失敗もなく、何があっても

最終的な結果（試合終了時）を成功（勝利）に導く考え方

という感じでしょうか。

これから、これらの事も取り入れて少しずつ実践していく予定です。

この出会いに感謝！

見える化はまず未来にフォーカス！

不確定要素の多く、状況変化の激しいソフトウェア開発
故に、見える化が進化しないのか、
見える化しないから、何も変わらないのか....

2年目となる本質思考道場にて
不確定要素の多いソフトウェア開発での改善方法が見えてきました。

そして、改めてアジャイルやリーンのやり方が理に適っていると実感します。
なので、似たような事が既に体系化されているかもしれませんが...

ポイントは見える化！
しかも、現状の問題をフォーカスするのではなく、
まずは未来にフォーカスをあてます！

不確定要素が多く、見える化が進んでいないソフトウェア開発では
見える化していないので、誰もが見て分かる「事実」が非常に少ない事が多い
これが、現状の問題の特定や原因特定する上で、大きな障害となります。

問題の本質を！　といっても事実が少ないので、とても時間が掛かります。

その為、問題は軽めに共有して
目指す姿や、目指す状態を共有し、定義します。
今のところ、TOCの簡易FRTを作成するのがベストな感じです。
（FRTだと、FRTがそのままスケジュールになります！）

すると、ここから問題が見えてきます。
問題が見えてくれば、あとは目指す姿や状態に向かって行動するのみ！

行動した結果の見える化では悩む事も多くありますが、
目指す姿は共有出来ているので、そこに向かって
能動的に見える化を進める事が出来ます。

問題点の見える化となると、後ろ向きになりがちですが、
この手順で進めると、不思議なくらい自然と見える化を進める方向に流れていきます。

まだまだ事例は少ないですが、
行動喚起のポイントは抑えられている気がしています。

五輪書の水之巻にある
「遠きところを近く見、ちかき所を遠く見る事」
という感じですね。
「遠く」を先にしている点には、重要な意味があったりして！？

見える化と活性化

最近、見える化する事の重要性が、やっと分かってきた気がします。
これまでも、見える化が必要だとは思っていましたが、
恥ずかしながら、その重要性には気づいていなかった気がします。

今頃？！という感じですが、ソフトウェア開発では、見えない事、モノが多いので、
難しいし、ムリな事もある！　と決めつけていました。

ですが、これもアサンプション！
決めつけてはダメですね...

見える化する事で、コミュニケーションが活発になる
というより、コミュニケーションの質が変わる
という印象を受ける場面を何度か体験しました。

主に、本質思考道場で
TOCのクラウドや、未来構造ツリーの作成を支援している時なのですが、
書き出してあると、余計な事を議論せずに、
そこに集中出来る為に、質が変化する感じがします。

疑問や問題点もそうですが、
ちょっとホワイトボードに書くだけで、書かない時より議論が活発となる気がします。

という事は、
見える化した事、モノにより何かが活性化する筈！？
逆に、活性化したいのであれば、見える化すれば良い！？

という仮説を元に
ネットをふらふらしてみると、そんな書籍も多くあるようです。
他の人が実践している、実践してきた「見える化」を
もっともっと勉強する必要あり！

と、今更ですが、気づかされました。

6時に帰る仕事術とカンバン

最近、「6時に帰る」、「定時に帰る」などをキーワードに
書籍をあさっています。

もちろん、図書館を最大限に活用しています。

あさった中の１つ
『フィンランド流　6時に帰る仕事術』

で、なんと「トヨタのカンバン」についての記載がありました！

しかも、ソフトウェア開発に導入した事例の紹介でした。
これが、6時に帰る仕事術の1つとして記載されています！

考えてみれば、当たり前で、
あさったどの書籍も、ムダを省く事で6時に帰る事を実現する内容が多く、
ムダを省く為の具体的な工夫や
時間に対する考え方、取り組み方などの紹介が主なので、
本質的には、トヨタ方針と同じ「現場改善」です。

ですが、このような書籍では、ソフトウェア開発に関する例の紹介は
ほとんど無い印象があるのと
本質的には同じでも、具体的な生産系のトヨタ方式との接点がある事は
全く予想していなかったので、少し驚きました。

しかも、「考える」事から始めて、残業が減ったのはもちろんですが、
職場が活発化された効果の方が大きい　

と紹介しています。

強力なトップダウンで実施されたらしいのですが、
結果的には、やらされ感のある改善ではなく、
活発化したポジティブループ＆反対者にも伝染となる改善となったようです。

数値データよりも、
職場の活性化、活発化は大きな原動力、影響力となる！
って感じですね。

その他、フィンランド流は、共感する事が多くあり、
お勧め書籍の1つになりそうです。

捨てる力＝突破力？！

「捨てる力」を目にしてから
先日、立て続けに「捨てる」との出会いがありました。

「『捨てる仕事』選びがパフォーマンスを高める」（「3人で5人分の成果を上げる仕事術」）
「何を取り、何を捨てるか」（「伝える力」）

いずれの2冊も、本を手に取りぱっと開いたページに
偶然にも「捨てる」があったのです。

このような出会いって本当に不思議ですよね。
この2冊には、「捨てる」を求めていた訳では無かったので、
こんなところに！？という感じでした。

内容はどちらも、捨てるには、
これまでの常識や前提にとらわれる事なく、何が重要かを見極める力が必要だと。
前回の内容と同じですね。

羽生さんの「捨てる力」に戻る感じですが、
これまでの経験や、常識、前提、思い込みが邪魔をするので、
なかなか本質を意識出来ずに、
結果的に捨てる事が出来ない....

面白いのは、捨てる目的というか、捨てる為の意識というかが、
この3冊いずれも成長や進化、新たな発見といった
未来に向かっている点が印象的でした。

それぞれ書籍のタイトルの通り視点が違うので、アプローチというか表現方法が違うのですが、
未来に向けての突破力のようなものを
それぞれで異なる表現をしている気がします。

何を目指すか、どこに向かうか
今に満足する事なく、進化し続ける意識がとても重要なのだと強く感じました。

これこそが本質思考の原点なのかもしれません！？

アサンプションと羽生さん

今年もSWEST参加しました。

今回のSWEST18では、
TOCの可能性をまたまた感じました。
一言でいうと、アサンプションを破壊してイノベーションを創出する！
というアプローチなのですが、
この話を聞いていて、よくよく考えてみると
世の中はアサンプションだらけだな
と感じました。

アサンプションだらけ！
と思うと、TOCの活用範囲が広がるのは必然ですね。


そして、セットベース思考を定着させるヒントがありそう
と思って読んだ『捨てる力』にも「アサンプション」が...

「ある程度の知識や経験はプラスに働く事もあるが、
　反対に先入観なしに物事を見る事が難しくなってしまう事もある」

まさしくアサンプションですよね。
そして、羽生さんは、
このアサンプションを打破する為に何をするのか？！

それは、
「思い切って自分の経験や知識を捨てて考えること」

だそうです。
さらっと書いてありますが、
とても難しいですよね。

ですが、新しい発想得る為に、自分を大きく変化させる為に
未練は残る事もあるが、思い切って捨てる！

との事です。

勝つために変化し続ける
という事なのでしょうが....
ますます難しいぃぃって感じますね。

社内でもアサンプション活用は少しずつ広がっています。
これを打破し続けて、
開発を成功し続ける為にも、深化し続けたいですね！

脳は失敗が嫌い？！

「失敗の理由を学ぶ事は、ほとんど心理的に出来ない

　人間の脳の性質は成功というのは勝手に強化されるが、

　失敗から学ぶ事は非常に難しい」

『考える力』より抜粋

すごく納得しました。

振返りで失敗を認知させる事が難しいと感じていたところに、

偶然、この書籍と出会いとてもラッキーでした！

これで、改めて、

難しい事にチャレンジしている事

出来なくて当たり前だった事

を認識出来ましたので、

改めてチャレンジしていく決意が固まりました。

だから、失敗ではなく、

なんでもかんでも問題解決という表現をするんですね。

なるほど！

で、更に、羽生さんの書籍で面白いのが無いかと探していたら、

『捨てる力』

を発見！

これは、まさしくセットベースの事では無いか！？

という事で、夏休みの読書用として早速購入！

セットベース思考を浸透させるヒントを多く得られる事を期待しています！

ホワイトボードA3の力

事ある毎にA3を書いていますが、
改めてA3の強力さを実感しています。

特に打合せでは、

とにかく話が早い。
話がそれる事が全く無い。
内容が濃い。

デメリットは全く感じません。

強いて言えば紙で配布する事
くらいでしょうか。

プロジェクターなどを使う場合は
全面を映す事が可能であれば、問題無いですが、
部分的に投影する事になるので、
こうなると、効果は半減するかと思います。

ただ、印刷もコピーも最近はそんなに時間もかかりませんので、
紙で配布する事で解決するかと思います。

もう1点のデメリットというか、
A3の問題点として、A3にまとめるのに時間がかかる
という事がありますが、

しかし、これは、「やり方」で解決出来そうです。

その「やり方」は、
最近の本質思考道場では定着しつつあります。
早ければ、2時間くらいでまとまるので、やはり、早いですね。

それは、ホワイトボードでA3を作成する

という方法です。

大きめのホワイトボードがもちろん便利ですが、
2つ使ったり、貼るホワイトボードと合わせて使ったりと
工夫はいろいろですが、
チームやグループで作成したり、キーマン2，3人で作成します。
これが、とても早いです。

後は、写真に撮って、そのまま共有に活用したり、
配布用に電子化する等して活用しています。
電子化も、まとまっている内容を電子化するだけなので時間もかかりません。

私自身は、1人で作成する事が多いですが、
１人でも早い気がします。

ホワイトボードA3お勧めです！

ハカる姿勢

先日、とある本屋でサボっていたのですが、

ハカる力

をぱらぱらと立ち読みして、20ページでグサッ！と来ました。

#アマゾンで20ページは立ち読みできます！

ハカる姿勢について書かれているのですが、

まさしく、本質思考でやっている事と同じです。

しかも、因果関係を示す事が重要との事。

そのままですね。

ソフトウェア開発においては、

計測するモノ、事が圧倒的に少ないと感じています。

工学的な測定値以外も、ハカるべきことが、たくさんある気がしています。

多角的に判断する上でも、データを集める事は重要ですが、

とかく、何かを計測しようとすると、集める事に時間をかけたり

集める事が目的となったり、本末転倒な事が起こります。

そうでは無く、

ハカる姿勢の通り、曖昧にせず因果関係を示して

開発の現状を多角的に把握したいですね。

本質思考道場からハカる事が、

多く生まれる可能性もありそうです。

何が無くてもフィードバック！

最近、フィードバックについて考えています。

常にフィードバックがあれば、失敗開発などない
デスマーチなど無いのでは！？
とさえ、考えるようになりました。

しかしながら、”常に”が問題です。

ソフトウェア開発では特に、
フィードバックが無いに等しい作業が多いですよね。

だから短いサイクルでの振返りが重要！
という事だと思うのですが、

もちろん、アジャイルでは当たり前の事で、
これまでも、そのように取り組んできたのですが、

最近、この振返りが機能していない気がしています。
イテレーションや、スモールリリースしていても
振返りが、今一つな感じがしています。

今一つなのは、
振返りで上がる”問題”が、問題では無く、解決策だったり、
誰が困る問題なのかが不明な問題が上っている事
つまり、問題として上がるべき内容が上げられていない点ですね。

当然、問題が問題で無いのであれば、
改善も的外れとなります。

なぜ、そうなるのか？！

実は、これが受託と深い関係があるのでは？！
と、最近思うようになりました。

オンサイト顧客など、顧客と近くで（場所ではなく意識）
やれていると、比較的常にフィードバックを得られやすいのですが、
顧客との意識が遠くなると、フィードバックが極端に少なくなる傾向にある気がします。

単純には、顧客を意識すれば良い！
という事なのですが、これがなかなか難しく
意識するだけでは、結果的にフィードバックは得られない事も多く、

常に先読みして、こちらから仕掛けていかないと
フィードバックは得られないような気がしています。

常に先読みするのも、疲れますよね....

そんな複雑な事ではなく、もっと単純な事のような気がするのですが....
これって、やはり作るソフトウェアが複雑になり過ぎている為に、
複雑化しているのでしょうか？？？

ちょっとした意識の仕方、共有に仕方で
ものすごく変わる気がするのですが....

う～ん...

フィードバックを常に得る為に何が必要なのか。
悩み続けています。

クラウドは強力だ！

最近、

TOCのクラウドの作成体験をしてもらう活動を始めました。
しかも30分くらいで。

これが想像以上に好評です。

時間が無さすぎる！
じっくり考えらない！
という反感も覚悟していたのですが、
これまで体験した全員が楽しかった！
という反応でした。

ソフトウェア開発を生業としている人は、
想像以上に考えるのが好き？！
現状の開発現場で考える時間が無さすぎるから、
その反響！？

などと妄想しています。

体験の冒頭は、いちおうTOCとクラウドの説明をざっとします。
（ジョナを持っている訳ではありませんが...）

クラウドの説明を何度もしていると、
クラウドの凄さ、強力さをひしひしと感じます。
実際に使う時より、説明する時の方が強く感じる気がします。

ただの5つの箱ですが、この1つ1つはとても強力です。
全体最適に向かう、第一歩であり、
シンプルに本質を捉える、とても強力な図ですね。
改めて、もっと活用していこうと思う、今日この頃です。

またまた本になった！

現在取り組んでいる本質思考道場が
またまた本になりました！

『深く、速く、考える。』

タイトルも、なんとも興味を引きます。

そして、この書籍は序章から「脳のバグ」に触れ、
最後は、日常化する為の方法
と、盛り沢山です。

本質思考道場を実施している我々にとっては、
ほぼ全てが既に実施した内容なので、
我々としては、既に次のフェーズに入っている事になりますね。

「深く、速く」の次の段階って何だ？！

って感じですね！

やっぱり手書きが効率的

暖かく、天気も良いので、散歩がてら
ふと近所の図書館に行ってみると、
『トヨタで学んだ「紙一枚！」にまとめる技術』
が目にとまり、もちろん借りました。

現在、本質思考道場でも取り組んでいるA3用紙1枚にまとめる
方法、アプローチについての書籍です。
前々から知ってはいましたが、手に取る機会はありませんでした。

ざっと見てみると、思わず読みたくなるような目次で、
1つ1つの項目が短いので、とても読み易いです。

ざっと斜め読みするつもりで、目次を開き、
「パソコンと手書きどちらのほうが効率的か？」
という項目に魅かれて読み始め、

「年間400時間の残業をゼロにまで減らした方法」
「一枚で自分の頭の中を見える化する」

などなど、つぎつぎと引き込まれ、あっという間に読んでしまった感じです。

最初に興味を引いた手書きＶＳパソコンですが、
著者の方もパソコンで作業していたが、最終的には手書きになったようです。

そして書籍中の
「脳がデジタル社会に適応して進化を遂げていないのであれば」
という表現が印象的です。
進化していないのであれば、手書きが効率的という説明です。

本質思考道場でも、「脳にはバグがある」というテーマで
根本原因を探らずに対策に走ってしまう原因についての説明がありました。

まったく同じ事だと感じました。

やっぱり手書きですねぇ～

A3はじっくり寝かせる？！

A3文化を定着させようと、奮闘中ですが、
なかなかA3が書かれません。

A3を書く為の訓練はしているのですが、
実際の課題や提案となると、なかなかA3とはなりません。

自身では、途中まででも思いついた事は、A3にしてみます。
なので、中途半端なA3がたくさん出来ます。

でも、これが意外と便利で、
思いついた事をA3にしていると、
時々、以前に書いたA3と同じような内容であったり、関係のある内容であったり
するので、切り貼りするイメージでA3が完成する事があります。

便利というより、私にとっては、
A3を書く上では途中のA3は必要な事なのかもしれません。

A3は寝かせて、一気に爆発させるのがコツ！？

まるで考えのコラージュですね。
その為にも、A3は寝かせる！

じっくりかは分かりませんが、
寝かせるA3お勧めします！

無駄が無駄を引き起こす...

最近、無駄の無い振り返り
について考えています。

私の周りでは、「振り返り」に多くの時間を割いています。
しかし、本当にそれだけの時間を割く必要があるのか？！

という疑問が沸きました。

と、同時に、
その割いた時間の成果が本当にあるのか？

良い事が多くあったプロジェクトについては、良い事は継続し易く、
振り返りも早い傾向にある気がします。
しかし、もっと無駄を排除できる気がしていました。

一方で問題があったプロジェクトが最悪で
永遠と振り返りをやっている事があります。
#やるだけ良いとも言えますが...

という事で、
これまでの振り返りのやり方について、
因果関係図を書いてみました。

すると、無駄が無駄を生んでいるような図が完成しました。
よくある事だとは思いますが、改めて実感する効果は絶大ですね。

改めて、1つの無駄が多くの無駄を生み出す事を認識した次第です。
ちょっとの無駄を排除していく事がいかに重要か！

こつこつと愚直にやっていく事が何事も早くするのですね。
これぞリーンの神髄！という感じでしょうか。

反省反省....

生産性と考える事

開発業務のような考える事が中心の業務において
効率化とは、何を意味するのでしょうか？

同じようにソフト開発では、効率化とは何を意味するのでしょうか？

この2つは同じだと思うのです。
考えなければ、良いもの、顧客価値
は、提供不可能だと思っています。

だとすると、考える事　そのものが効率化なのではないでしょうか？！
ドキュメントを速く多く書くよりも、
コードを速く多く書くよりも、
レビューを速く多くやるよりも、

考えて考えて考える事
多くの事を考える時間を増やす事が
最も効率的な気がします。

つまり、どれだけ多くの事が考えているかが、全体最適に繋がり、
結果的に最も生産性が高くなる気がします。

ソフト開発においても、
どれだけ多くの事を考えて設計したか、
どれだけ多くの事を考えて実装したか、
が、品質及び生産性の向上に繋がると思います。

考えない仕組みやプロセスよりも、
可能な限りの考える時間を生み出す仕組みやプロセスが
今こそ必要な気がします。

現在、取り組んでいる本質思考道場は
いかに多くの事を考えるかという訓練なのだと改めて実感しています。

個人作業の遅れは問題か？！

最近、ふと思うのですが、
個人の作業が遅れている事は問題か？！
と。

不確実な事があれば遅れる。
割り込みがあれば遅れる。
ですが、これは当然で、遅れる事は問題では無いのでは？！

不確実である事や、割り込み入る事が問題であり、
遅れる事は問題では無い！
ですよね。
本質思考道場を始めて、自身でもA3を書くようになり、
更には、多くの人のA3を見るようになり、こんな事を思うようになりました。

話を戻して
遅れが問題と認識してしまうのは、遅れない事が前提である為ですよね。
この前提が遅れを隠す事にも繋がるのかと思いますが...
この前提はまさしく、諸悪の根源な気がします。

作業内容が不確実であれば、遅れてもおかしく無いですよね。
更には、開発はチームで実施すべきで
チーム全体としての遅れに影響が出ないようにチームで調整していくべきだとも思います。

となれば、余計に
個人の作業が遅れる事、そのものは問題では無い気がします。

遅れた原因が問題であり、
遅れた原因を解決しない限り、更に遅れが大きくなるので
原因解決が後になればなるほど、対処不可能な状態へと近づいていきます。
「遅れない」という前提恐るべし！

もしかすると、これがなくなると、どの開発もうまく行く？！
更には楽しくなるかもしれませんね！
というか、この問題を解決したのがCCPMという事なのでしょうが、
この前提がなくなる事で、良い副作用がたくさんありそうですね。


もう少し視野を広げると、
これは仕様が決まらない
とか、仕様変更が多発する、不具合が多発する
といった問題と同じですよね。

どれも、決まらない原因を解決しなければ、何も決まらない。
変更となる原因を解決しなければ、変更は無くならない。

こう考えると、
開発の現場で、解決すべき問題を解決していない事が
ものすごく多くある気がしてきます。

それは、問題の捉え方が間違えているから
という事になるかと思いますが....

しかし、なぜ解決すべき問題が捉えられないのでしょう？？？
多くの前提条件が頭の中に渦巻いているのでしょうか！？
冷静に考えると不思議な気もしますが、
開発していると、そんな事に気がつかないとも思います。
う~ん...

セットベース開発と問題解決A3

問題解決A3を書いていると、
セットベース開発の基盤になると感じてきました。

セットベース開発で重要なのは、どんな試作をするか　ではなく、
何を検証するべきか　だと思うので、

これはまさしく、対策ありきの原因分析ではなく、
現在の状況から原因の分析を行い、何を変えるべきかを突き止める事
と同じかと思います。

また、対策についても
その原因を何に変化させるかを多角的に検証し、
解決となる実施案を選択していきますが、
ここは、まさしくセットベース開発そのものとなるかと思います。

が、しかし、これがまた難しいですね。
何を検証するかが決まっても、
それをどのように多角的な検証するかを考えるのは困難です。

A3でも、なかなか多角的な対策案は出ません。
複数案出ても、一方向のみで、どれも似たり寄ったりな感じがほとんど。
それで、解決すれば目的は達成されるので良いのですが...

とはいえ、
解決策ありきのセットベース開発にならないように
何を検証すべきか
をキチンと分析、共有する事がまず大事ですね。
これが出来ていないと、セットベースの効果も半減という感じがします。

本質思考道場流？A3の書き方

最近、A3を手書きで書いてます。

手書きで書けるようになるとカッコイイと思って始めましたが、
ほどなくして、とても強力で、最速の思考手段だと実感しました。

私は4色が1本になっているボールペンを使っていて、
気分で色を変えて書き出していきます。

まずは、どんどん思いつく事を書き出していきます。
最終的なレイアウトや構成などを考えながら、拡散させていきます。

紙には、どんな形でも素早く加筆出来きますし、
加筆の出力＆確認も加筆した時点で出来てしまいます。
紙1枚なのでページ遷移も、スクロールも不要ですし、

印刷範囲に入れる為の調整や、印刷を待つ事もありません。

しかも消せないので、情報が落ちる事もありません。
（読めない事はたまにありますが....）

汚くなる手前で、新たなA3に書き直していきます。
書き直すというより、
汚いA3を見ながら、新たに書き出していく感じです。

この汚いA3を見ながら、新たなA3を書くという行為が
紙でないと実現出来ない行為かと思います。
これを2，3回繰り返す事のですが、
この繰り返しが拡散と収束を繰り返す事になっていると思います。

漢字が思いつかず、手が止まる事はありますが、
そんな時間を考慮しても、考えを拡散、収束するのは早い気がします。


ポイントは消さない事！

かと思います。

消して書き直すのではなく、
消さないで、加筆するか、まとめていきます。

消さないので、必然的に
書き直す事を繰り返す事になります。

PCなどで、コピーして
新たなページに修正していくのは、
決まりきった事を「修正」するのみで、修正の枠からは出ない気がします。

紙だと、修正から大きくはみ出し、
考えを発散、収束させながら書き出す行為となっている気がします。
また、思考の後戻りを防ぐ事にも繋がるかと思います。

で、いま、新たなツールとして
A4の無罫ノートを使って見開きＡ3ノートとして
活用してみようと考えています。

コーディングの価値

突然ですが、コーディングという行為に価値はあるのでしょうか？！

当然、コーディングしないと動くものは出来ないのですが、
コードを書くだけでは動きません。

コードを書いた後にコンパイルなど、もろもろ環境を整えて、
やっとこ動くものになります。

しかもその動きは、単に動くものではなく、
動作する事で顧客に価値を与えるものである必要があります。


このように考えると
コーディングという行為はとても曖昧な行為ですよね。

コードを書いただけでは動作しないので
何も価値が無いとも言えます。
ですが、コードを書かないと動くものは完成しません。

価値あるものにするには動作させる必要があります。
動作しなければコーディングした時間も無駄ですし、
ゴミを創り出しただけになります。

価値あるものにするには、ゴミの生成を防ぐ必要があります。
つまり、必ず動くコードを書く必要があります。

ですが、これはちょっと難しいので、
ゴミをいかに少なくするか
という事になるかと思います。

その為の有効な手段の1つがテストファーストかと思います。
テストファーストは品質向上の1つの手段として捉えられていると思いますが、
それ以上の効果があります。

テストを先に作成して、確実に動作するコードを書く。
テストがあれば、それさえOKになれば良いのでゴミとなる確立はかなり少なくなりますし、
テストがOKとなれば、その時点で価値に繋がるものが創造された事になります。

で、思うのですが、
これってコーディングなのでしょうか？
コードは書いているかもしれませんが、やっている事は単体テストですよね？！

実はリボンモデルにはコーディングという工程はありません。
上記の通り、コーディングではなく単体テストだと思うからです。

コーディングという曖昧な行為ではなく、
確実に価値創造に繋がる単体テストとリファクタリングを繰り返す
これがリボンモデルの核となります。

価値創造に向けて無駄を無くす為、
動かないコード、無駄なコード、ゴミ生成を避ける為、
コーディングという工程を考え直したらリボンになりました。

決まれば早い！

最近、改めて実感しています。

ソフトウェア開発は、高額で時間が掛かるという印象を持つ人が多いとは思いますが、
それとは対照的にソフトウェア開発は早いと感じています。
特に昨今のソフトウェア開発は早いと実感しています。

但し、条件があり、何を造るかが決まれば早い　
という事です。

時間が掛かるのは、何を造るかが決まっていない場合で、
とにかくどんな事にも対応しようと機能を増やし、
機能が多い為に、誰も把握しきれず、方針も2転、3転する
更には、機能間の矛盾が把握しきれず、もぐら叩き状態の仕様変更も際限ない....

となると、それは時間が掛かりますよね。

仕様の追加、変更に対応する策として、
アジャイルがあります。

しかし、アジャイルも仕様のコンセプトがあって機能するものかと思います。

コンセプトが揺らいでいるようでは
アジャイルも機能しませんよね....


なので、ソフトウェア開発を早くするには、
いかに早く何を造るかを決めるか　

という事になるのですが、
これがなかなか難しいというか、浸透しないというか....


その要因の1つには、ソフトウェア開発の見積もりに時間が掛かり、
かつ高額となりがち
といった事もあるかと思います。

しかし、この見積もりも「何を造るか」が分からない為、時間がかかるのだと思っています。

となると、卵が先か鶏が先かといった議論になってしまいそうですが、
全ては、「何を造るか」だと思うのです。

「何」は機能では無くて、どんな思いで、どのような事を実現する、もしくは課題を解決する
ものなのかといった、いわゆる野中郁次郎さんのいう「熱」なのだと思います。
（「アジャイル開発とスクラム」に「なぜ作るのか」といった熱の共有が必要！
　ってな事が紹介されています）


リボンモデルでも拝借させて頂いていますが、
「何を造るのか」より
「なぜ作るのか」の方がしっくりきますね。

ソフトウェア開発を早くする為にも
ソフトウェア開発技術者として「なぜ作るのか」を追究していく事が必要なのだと思っています。