セットベースアプローチとコンセプト

リーンのセットベース開発を始めるにあたり、
すぐに出来る事

1)複数案を考える
2)複数案から選択する

だと思っていましたが、
意外と複数案をどう考えるか
が難しいようですね。

そこで、以下のように考えてみました。

すぐに出来る事として、

1)現状の設計案、構造案の一番良いところ（拘った点や、アピール点）
2)現状の設計案、構造案のメリット
3)現状の設計案、構造案のデメリット
4)なぜ、そのデメリットを受け入れたか、回避方法はあるか
5)一番実現したかった事
6)これだけは避けたい事
7)いま、いちばん気持ち悪い点、事

これは、先月記載した「簡単な？7つの質問」
と同じです。

以上のステップで
新たな案が生まれる可能性が高まると思ったのですが....

そもそもの設計コンセプトが固まっていないと
メリット、デメリットさえもブレてくる事がわかりました

改めて、コンセプトの重要さを実感しました。

と、いう事で、コンセプトをどう決めるかを考える必要がありそうです。

手書きと開発

本質思考道場を開始して、手書きの機会が増えました。

道場では紙に手書き。
1日中、手書き。
こんな時間がとても貴重な気がしています。

最後には、手書きで作成した資料を提出するので、
参加者の資料を見るのもとても楽しいです。


手書きするだけで、いろいろな感覚が研ぎ澄まされる感じがしています。
配置や大きさ、みなそれぞれです。
決して、同じものはありません。

ですが、みな結果は同じです。

開発ととても良く似ていますね。

設計や、プログラムコードは、各々異なりますが、
結果は全て同じになります。

ある意味セットベース的なアプローチとも言えるでしょうか！？
他人の手書きした資料を見るだけで
セットベースアプローチとなるかもしれませんね。


いやぁぁぁ、しかし、つくづく漢字が書けないですね.....

簡単な？7つの質問

先日、ロボコンの設計をレビューする為に
以下の7つの質問をしてみました。

1)この設計（モデル）の一番良いところ（拘った点や、アピール点）
2)この設計（モデル）のメリット
3)この設計（モデル）デメリット
4)なぜ、そのデメリットを受け入れたか、回避方法はあるか
5)一番実現したかった事
6)これだけは避けたい事
7)いま、いちばん気持ち悪い点、事

この質問は、セットベース思考、セットベースアプローチとして、
「どのように考えていくのが良いのか」
を考えていた中で、
今回のレビュー依頼を受けて、直観的に生まれたものです。


回答するまでには、けっこう悩んだようですが、
その回答を見た感じでは、
そこそこ考えを整理出来るかも！？
って感じました。

昨年から、
インセプションデッキを使い始めていますが、
その設計版みたいな感じでしょうか。

インセプションデッキも各チーム毎にカスタムされてきて
定着しつつあるように感じています。
設計版もここから進化出来たら面白そう！
もちろん、セットベースに繋がるアプローチとして。

セットベース開発アプローチも少し更新しました。

UDEも美しく！？

私はマコネルの「アートな」という表現が大好きになり、
開発プロセスもリボンのように美しく！アートに
というコンセプトで作成しました。

最近、プライベートでアートとの接点があった事もあり、
ぼんやりと、設計とアートの共通点が何かを考えてみました。
といっても私はアーティストでは無いので、
アートは私の勝手なイメージですが....

じっくり考え抜く、追及する、集中する、変換する
なんどもやり直す

といった感じで、
大きくは表現の方法が違うだけかとも思います。

いっぽう、表現方法はもちろん違いますが、
その他の違いは、

1つ1つに命を吹き込む
じっくり思いを込める

など、どの作品にも圧倒されるようなパワーを感じる事が多いので、
何かが込められているのでは　
と感じます。

設計も、最適設計を考える上では、
何が最適かを追求する必要があり、
設計でも、同じように思いがこもっている　とは思いますが、

その設計を見て？　パワーを感じる事はあまり無い気がします。



話は変わって、
本日、今年から始めた「本質思考道場」にて、
間違ったUDE（ウーディー）を修正する100本ノックに挑戦しました。

しかし、どうしても、問題点を否定形で表現してしまい、かなり苦戦しています。
100本などとても無理！
8本でダウン...って感じでした。

しかし、これも考えてみれば、
美しい表現に変える！

って考えると、自由な変換へのチャレンジ精神が湧きあがる気がします。

美しさへの追及というだけで、ワクワクするのですが、
これは私だけですかね.....

言葉のダシの取り方

先週の新聞で
「言葉のダシのとりかた」　という詩が紹介されていました。

これは、「星の王子さま」のサンテグジュペリの
以下の名言と共に紹介されていました。

完璧が達せられるのは、付け加えるものが何もなくなった時ではなく
削るものが何もなくなった時である


昨今のソフトウェアにおいても
付け加えるものもが、次々と増え、削る事は一切していないように感じます。

その影響か、開発に関する様々な表現や言葉も肥満化している気がします。


詩の中で、

「言葉が透きとおってくるまで削る」

という表現があり、背中がゾクっとしました。


透きとおるまで、言葉を吟味していきたいですね。

MVPと特許

リーンのMVPの考え方に感動し、
自分なりの理解で独自に推進してきました。

推進すればするほど、MVPの考え方はすばらしく、
現状のソフトウェア開発業界には必須な事でもあると感じるようになりました。

と同時に、
トヨタのカンバン方式に通じるものがあるとも、強く感じるようになり、
カンバン方式と同じような特許に出来ないかと考えるようになりました。

いろいろ悩み、弁理士さんとも相談しながら
どんな形になるのか、はたまた特許となるのか
などなど、模索してきました。

それが今月なんとか出願まで辿り着き、いちおう形になりました。

今後は、これをどのように広めていくのか
どうしたら、広められるのか
などなど

更なる課題が盛り沢山です。
が、そんな課題を楽しみながら解決というより、
何かの形にしていければなぁ
と思っています。

愛せば見える！？

先日(2015/4/8)の朝日新聞に
「愛さないと見えないモノ　というのがあるんじゃないですか」

という記事がありました。

内容は、研究の話で、
学べば出来る客観的なものではなく
愛のまなざしがあってはじめて見えてくるものがある
愛が無ければ、見えるはずのものも見逃してしまう

と。

ソフトウェア開発は見えないものばかり

ソフトウェア開発でも愛のまなざしで見つめると
見えてくる不具合があったりして！？

複雑な製品も愛があれば、
見えてくるアーキテクチャーがあったりして！


TOCの開発者ゴールドラット博士の4つの信念の1つに

「人はもともと善良である」

とあります。

これも愛に通ずるものかと思います。
愛のまなざしでは、善良な部分が見えるのだろうと思います。


これまでは、開発に必要なモノの大きな要素の1つは
「興味」だと思っていましたが、

この記事を読んで、
見えないモノが多いソフトウェア開発において、
最も必要なものは「愛」ですね！