愛せば見える！？

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

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

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

と。

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

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

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


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

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

とあります。

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


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

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

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

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

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

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

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

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

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

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

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

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

Menlo

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

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

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


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

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

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

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

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

やったるでぇ～

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロセス VS チームワークと熱意

2015年一発目も、もちろん「リーン製品開発方式」 からです。

あと最後の8章を残すのみとなりました。
以下が、一番のお気に入りの言葉となりそうです。

「従来の開発プロセスの考え方は膨大なムダを生む。
　プロセスをやめて、代わりにチームワークと熱意を入れると
　直ちに劇的な改善効果を生み出す。」

「従来の」がポイントでしょうか。
前回の通り、ケースバイケースで考えられていれば
プロセスも効果がある　という事かと思います。

最近、チームワークや熱意と品質、生産性には
相関関係があると感じる事が多くなりました。

そして、従来の？プロセスの最大の欠点は
チームに決断させない事ではないかと感じています。

チームで決めた事は
能動的な行動になり易いと思います。
しかし、プロセスとして決められたアクションは
なかなか能動的になり難いのかと思うのです。

逆に、プロセスもチーム内で、目的達成の手段として必要という決断をすれば、
共通認識となり、能動的になるのかと。

「リーン製品開発方式」にも、
具体的な方法の1つとして、プロセスから解放する
といった記載がありましたが、
何かと制約が多いと、熱意があっても徐々に失われますよね。
そうなると、受け身になり、
決断もしなくなるのかと思います。

品質においてもチームで目指す品質や、
その品質を確保する具体的な手段を決める（決断する）事で
能動的になり、達成する事が可能になる気がします。

プロジェクト管理においても、
マネージメントすべきはチームワークや熱意なのかもしれませんね。

本来、プロジェクトが成功すれば
どんなやり方でも良い筈ですから。

まぁ、ソフト開発だと、
それだけ管理しても成果物としてどの程度完成しているのか
などの進捗判断が出来ないので、
そうなっていないのでしょうけど。

そうなると、やはり動くソフトが見える状態を
可能な限り早く作って
チームワークや熱意のマネージメントに注力すべきな気がしますね。