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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


ポイントは消さない事！

かと思います。

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

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

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

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

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

コーディングの価値

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

決まれば早い！

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

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

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

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

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

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

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

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


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

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


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

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

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

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


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

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

やっぱりセットベースアプローチ！

改めて、複数案から絞り込む事はとても効果的であると感じます。
何が効果的かというと、以下の4点かと思います。

1)自身の考えを整理出来る
2)多角的に客観視出来る
3)セルフレビューとなる
4)後から見直す場合に理解が早い

案を検討する上で、
メリット、デメリットを明確していくのですが、
意外とやっかいなのが、デメリットを考える事です。

すんなり出てくる事もあるのですが、なかなか手強いです。

メリットを返せばデメリットとなる筈！
などと思ってはいますが、
そもそもが、解決策の1つとして考えているので、
ある意味「良い案」だとも思っているところがあるのだと思います。

なので、ちょくちょく固まります....

しかし、固まるので考える必要が出てきます。
これが重要かと思っています。
この時間は無駄ではなく、これこそ必要な時間だと思うのです。

だとすると、単純に複数案をプロセスとして定着させれば
考える時間が必然的に生まれる可能性もありますね。

ものすごく簡単そうですよね。
しかし、現実はなかなか広まらないし、定着しそうでしていないって感じです。

ですが、今は本質思考道場効果で定着する事を期待しています。
さて、どうなるでしょうか？！

議論で開発スピードを上げる！

アマゾンの策略にはまり、
「行為のデザイン思考法」
に出会い、読んでみたところ...アマゾンに感謝です！

考え方がアジャイル的であり、
リーンのセットベースやMVP的な要素も含んでいて、
開発においてやるべき事は共通していて「考える事」であると改めて感じました。

開発関連の書籍とはちょっと違う雰囲気で
とても読みやすく、さらっと読めてしまいました。
とても重要な事もさらっと読めてしまい、印象に残らないかも！？
と余計な心配をするほどです。

ちょっとだけ内容（お気に入りの表現という感じでしょうか）を紹介しますと、

「ズレの原因となるバトンタッチ型フローから時間を共有する円卓型に変える」
＞　瞬間的に、ミッション・リスク分割型から、ミッション・リスク共有型へ
＞　ウォーターフォールからアジャイルへ　の2つをイメージしました。
＞　しかし、ウォーターフォールでも円卓型は可能ですね。

「議論をしっかりしているからこそ開発スピードが上がり、製品化までの時間が短くなる」
＞　具体的な比較データは掲載されていませんが、断言されているので
＞　今後、いろいろと引用させて頂く事になると思います。

「デザインには美しさがなければいけません」
＞　この表現大好きです！

「時間軸で流れる『行為の美しさ』、
「プロダクトやサービスの底にある『考え方の美しさ』」
＞　「考え方の美しさ」大好きです！

開発プロセスも美しく！
リボンモデルで行こう！

本質思考道場と手書き

本質思考道場を始めてから、
現場への活用が能動的に進められている状況が嬉しくもあり、疑問でもあります。

なぜ現場で活用出来ているのか？！
いままでのワークショップや研修と何が違うのか？！

なぜ？？？

ずっと考えています。

もちろん、参加者のモチベーションなどもあるとは思いますが、
それだけでは無い気がしています。

最近は、手書きの時間、考える時間
この2つを提供している事の効果かと思いはじめています。

ワークショップなどに参加しても
ぎちぎちのタイムスケジュールで、意外と考える時間は無い。
ある程度の時間で、打ち切られてしまい、
手書きで何度も作図するとか、書き直すなどのワークショップも意外と無い。

といった事がその理由です。

こう考えると、
何度も書き直すあたりは、A3プロセスのようですね。
本質思考道場そのものが、A3プロセスのようになっているのかもしれません。

そんな事を考えていたら、
最近、「モーニングページ」というものを発見しました。
手書きが重要だとの事ですので、
書籍などでもっと調べてみようと思っています。