MVPと特許

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

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

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

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

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

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

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

愛せば見える！？

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

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

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

と。

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

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

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


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

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

とあります。

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


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

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

美しい設計、美しいコード

みなさんは、
美しい設計となった！
美しいコードが書けた！

といった時に、
どのような見せる化や共有をしているでしょうか？

もしくは、美しい設計、コードが自己満足　or　他の技術者も美しいと感じるか
といった議論などしているでしょうか？

と、いうのも、
美しい設計やコードって、日の目を見ないと思いませんか？

それって、なぜでしょうね？！

ソフトウェア開発において、
美しい設計やコードは、もっとクローズアップされて良い筈だと思うのですが....

まぁ、その原因の一つは、「美しい」の基準が無いからですよね。

基準としては、
ソフトウェアメトリクスだと複雑度は、ひとつの基準と成り得るでしょうか？！

「美しい」という基準作りや、
構造と品質の因果関係など、2015年度も、いろいろと考えて行きたいと思います！

Menlo

またまた「リーン製品開発方式」から

8章の事例5で
紹介されているメンロ・イノベーション

すごいです！！
まさしく目指すところって感じです。


そしてそして、翻訳者の稲垣さんとの交流で
メンロに関する情報をGet！

それがまた、すごいです！！
とにかくすごいです！！

我々もMVPサービスとして、こんな事例がありますが、
メンロのハイテク人類学者は、
このような事を極めた技術者なのだと想像出来ます。

更には、XPのプラクティスもほとんど実践しているようです。

と、いう事で、
新たな目標が出来ましたね。
メンロを超えるチーム、更には組織を作る！

やったるでぇ～

設計コンセプトを共有しよう！

設計コンセプトを共有しよう！

という事で、
実際に記載したコンセプトマニュアルを参考に
何を共有するのかをまとめてみました。

ここにも複数案が登場します。
結果、セットベース開発にも関係してきます。

複数案のメリット、デメリット比較は
インセプションデッキのやらない事リストにも似ていると感じています。

「やる事」という視点と
「やらない事」という視点での
クロスチェックであり、同時にチームの認識が明確になる。

ですが、なかなか「やらない事」視点って難しいですよね。
複数案の方が比較的容易かと思うのですが.....

セットベース開発へのいざない

セットベース開発へのとっかかりとして
複数案を検討する事から始めては如何でしょうか！？

って事で、
セットベース開発アプローチ
としてまとめてみました。

複数案検討している時間が無い
という場合もあるかとは思いますが、

初期段階でどれだけ検討出来るかが
後々のスピードアップに繋がります。

また、レビューも効率的に作用します。

時間も不確実性の非耐性
により、上流工程での工面が難しいのだと思いますが、

ゴールに向けて、今、何にいそしむべきなのか
という本質思考、目的意識は
常に持っていたいですね。

意識も、1人だと難しいので、チームで補いながら。
がベストでしょうか。

セットベース開発と品質データと見えない力

リーン製品開発方式
先日の人間ドックで、やっとこ全て読み終わりました。

前半には、衝撃的な事ばズバズバと書かれていて
とても爽快です。

改めて、ソフトウェア開発においては、
セットベース開発と
品質をデータで示す事と
チームワークや熱意のような見えない力を成長させる事
が
これまで、おろそかにされてきた気がします。

見えない力については、
序章のヘンリーフォードと豊田喜一郎の比較はとても印象的で、
共に学習し成長する意識が、全てを解決に導いてくれる気がしました。

ですが、この意識改革が最も難しい点かもしれません。

セットベース開発については既に取り組んでいますが、
その成果が残せず、模索中です。

セットベースとしての試作はもちろんの事、
複数の設計案、実装案を考える事も、
セットベースの1つとして少しずつ広めています。

これが、最適設計、最適実装を見つける事に繋がる筈ですし、
最適を模索する事が品質向上になる筈ですので。

しかし、複数案についても
何をどのように検討したのかが残せていません...

ここ数年、どのように残すかを検討中で、

現状では、セットベース開発にて
設計技術として解決した課題を一般化し、
品質データと共にドキュメント化したい！

という野望に成長しています。

設計と紐づけした品質データを残す方法については
まったく何も思いつきもしませんが、
とにかく考えてみたいと思います。