またまた本になった！

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

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

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

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

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

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

って感じですね！

やっぱり手書きが効率的

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

現在、本質思考道場でも取り組んでいる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でも、なかなか多角的な対策案は出ません。
複数案出ても、一方向のみで、どれも似たり寄ったりな感じがほとんど。
それで、解決すれば目的は達成されるので良いのですが...

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