コーディングの価値

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

UDEも美しく！？

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

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

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

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

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

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

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

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

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



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

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

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

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

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

なぜアーキテクチャーが語られないのか？！

最近、アーキテクチャーが語られない気がしていますが、
みなさんの回りではどうでしょうか？

私の回りでは一部ではされていますが、
社内でみると、決して多くは無い気がしています。

では、どうすればアーキテクチャーが語れるようになるのか？！

いっぽう、フレームワークやプラットフォーム
という言葉は話の中で登場する事はあるようです。

しかし、その内容に
アーキテクチャーが無い（検討されていない）のでは？！

と感じる事が多く、
私がそう感じるのはなぜなのか？！
なぜ、アーキテクチャーが語られないのか？！

アーキテクチャーって
全ての中心にある事な気がしています。

細かい機能や性能を考える前に、
アーキテクチャーをどうするか
が無いと、極端には全てが無駄になる事もあると思うのです。

なぜ、アーキテクチャーが中心に無いのだろう？


弊社でも派生開発、保守開発が多いので
それが原因の1つであろうとは思います。

しかし、アーキテクチャーを語っても
周りの反応も今一つなのは、やはり意識されていない
言葉に馴染みが無い

という事なのだろうと思います。


といった事がモヤモヤしていました。


そこで、一大決心し、
SWESTからちょくちょく議論させて頂いている大先輩に
突然の連絡をしてみる事にしました。

すると、快諾を頂き、いろいろと議論をさせて頂きました。

議論すると、そこから発展して、視野が広がり、
付随する思わぬ情報まで得る事が出来て、とても楽しいですね。

やっぱり議論する事って大事ですねぇ

出力しよう！

今年もSWEST16に参加しています。

今年で3年目になりますが、
3度目でもこのような場は貴重だなぁ　とつくづく実感します。

オープニングセッション、夜の分科会
と参加し、
「分ける」と「分かる」と「分かち合う」を再考する事が出来ました。

最初の難関である「分ける」為には、
言うまでもありませんが、考える必要があります。

以前も多角的な視点で考える事で
「似て非なるものを分ける」といった内容で投稿しましたが、
この多角的な視点を持つ事が難しいですよね。

その為に具体的に何をするか！？

それは「出力」ではないかと思っています。

文章でも絵でも　出力する事で、

1)自身の考えが整理出来る
　これは恐らく、みなさんも実感した経験があると思います。

2)もう一人の自分になれる
　出力したものを改めて見ると、もう一人の自分が必ず現れませんか？！
　「けっこーいけてるじゃん！」とか「ぜんぜんダメじゃん！」
　というような、もう一人の自分が突然出現しませんか？！

3)分かっていない事が分かる
　いざ、出力しようとすると、出力出来ない！
　という事ありますよね。
　つまり、”分かっていない”　という事ですよね。

4)更に掘り下げられる
　出力すると、具体的に何をもっと掘り下げる必要があるのか
　と逆に何が不要なのか
　といった事が明確になりますよね。


などなど、つまるところ、整理されるのだと思いますが、
出力するだけでも、こんなにも分かる事がある
と改めて感じた次第です。

なので、この出力を「早め」に実施する事が重要なのだと思います。
自分の状態を知る為にも、まず現段階の考えを出力してみる。

そこから改善していく。

つまり、リボンモデルですね！
小さな改善の繰り返し！！

考えるだけでなく、出力して、小さな改善を繰り返す事で、
「分ける」事が可能となり、「分かる」と「分かち合う」となります。

と、いう事で、出力しましょう！

簡単に分けて見積もりしましょ！

ソフト開発現場では
各作業の見積もりから、顧客に提示する見積もりまで
常に様々な見積もりをしていますよね。

そして、みなさん見積もりで苦労していますよね。
その多くは、見積もり通りに行かない事でしょうか。

私は見積もりのコツは、ずばり！
「見積もらない事」だと思っています。

「見積もらない事」がコツであり、
その為に、まずは「分ける」という事です。

見積もれるもの
と
見積もれないもの

を「分ける」のです。

そして、分けた後が更に重要で、
見積もれないものは「見積もらない！」事です。

見積もれないものまで、
無理矢理見積もる事が、ダイレクトに失敗（デスマーチ）に繋がります。

とは言っても見積もらない訳には行かない事が殆どかと思います。
では、見積もらないでどーするか！？

と、その前に「分ける」という点について、
もう少し考えてみたいと思います。

というのも、

見積もり可能なもの
と
見積もり不可能なもの

の間には、似て非なるものが満載です。

この似て非なるものを
1つ1つ分けて考える事が必要となります。

似て非なるものを「分けず」に「可能」と判断してしまうと
当たり前ですが、見積もり通りには行かなくなります。


見積もりで失敗しない為には、
「分けて」考える事で、見積もれないものを見極め、
見積もらない！

だと私は思います。


世の中には
見積もり手法などもいろいろありますが、
それらのほとんどは、
「見積もれるもの」の精度を上げる為のものです。

そして、
失敗要因のほとんどは「見積もれないもの」にあります。


では、改めて見積もれないものを
見積もらないでどーするか！？

答えを一言でいうと、リーンのセットベース開発です。
その詳細は、また改めて....


見積もりに関連して、
私はマコネルのこの言葉が大好きです。

「予測の研究から分かったもっとも永続的で役に立つ結論の一つ。
　一般に簡単な手法は複雑な手法と同じくらい正確だ！」

簡単に分けて考えましょ！

「分かる」まで「分ける」と「分かち合う」？！

「分ける」と「分かる」と「分かち合う」

ですが、

実は、「分かる」まで「分ける」と「分かち合う」
場合と
「分ける」と「分かる」と「分かち合う」

の2つのケースがある気がしています。


それは、受託開発では、見積もりや、アーキテクチャーは
「分ける」と「分かる」と「分かち合う」

だと思うのですが、
設計や実装、リファクタリングなどは
「分かる」まで「分ける」と「分かち合う」

な面があると思うのです。


例えば、受託開発の見積りのポイントの1つに
「やってみないと分からない事」や
「曖昧な事」、「変動する可能性のある事」
は見積もらない。

というより、そのような場合は
「分けて」、セット・ポイント開発のようなスタイルを取る
というのがベストだと思います。

つまり、「分けて」考えて「分かる」状態にして
関係者にて「分かち合う」必要があります。

いっぽう、実装については
１つの処理は可能な限り小さく、他との関係が無く、
完結していると、分かり易く、品質も必然的に高くなります。

その為には、可能な限り分けていく事がベストとも言えます。

「分かる」まで、というより、
より「分かり易く」する為に、「分ける」
という感じでしょうか...

「分ける」と「分かる」と「分かち合う」

2014年度、AVASYSとしては35期のスタートです。

4/4 の全社キックオフでは、
中竹竜二さんの講演があったのですが、

その中に、今期のRibbonModel推進テーマがずばり！

というのも、
2014年度は「分割」をテーマにする予定でした。
（キックオフ会場の成果展示には、いちおう掲載していましたが....）

すると講演の中で、
曖昧な問題の解決策として、

「似て非なるものは分けて考える」
と
「分ける」と「分かる」

というキーワードとお話を聞いて、
胸に突き刺さりました。
これだ！　と言う感じです。

そして、これに、共有の要素を追加すると、
まさに、リボンモデルです！

「分ける」と「分かる」と「分かち合う」

いったいどーいう事？？？

と感じるかもしれませんね。

簡単に説明すると、
リボンモデルの特徴である
「単体テストとリファクタリング」

は、「分ける」事から始まります。
というより、分けないと不可能、もしくは困難になります。

そして、当然ながら「分かる」から
「単体テストとリファクタリング」
が可能となります。

「単体テストとリファクタリング」が可能となると
属人性や担当依存が低くなり、共有に繋がっていきます。
これが「分かち合う」ですね。

もう一つの特徴である
「小さな改善を繰り返す」
も同じです。

改善するには、問題や課題を「分ける」事が重要となります。
「分ける」事で、解決すべき問題がシンプルとなり、
「分かる」となります。

すると、チーム、顧客含めた情報共有がし易くなり、
「分かち合う」が可能となります。

そして、いずれも「分ける」事による
単純化（シンプルにする事）は、
開発スピードを劇的に向上させる事に繋がります。

但し、単純化の為には、
「似て非なるもの」を「分ける」事が大前提となりますが。

大前提となる　ソフトウェア開発での
「似て非なるもの」を「分ける」については、また改めて！

セット・ポイント開発のススメ

リーンのセットベース開発的なアプローチをした事例をまとめてみました。

セット・ポイント開発のススメ

組込みでの事例です。

ET2013 プレゼン

今更ですが、ET2013でのブース内プレゼンの動画をアップします。

リボンモデルを簡単に紹介しています。

 

 

仕事はじめ

AVASYSは6日が初日でしたが、
私はサボりました....
7日が仕事はじめです。

今年もリボンモデル実績を増やして、更に進化させていきます！

まずは、昨年の実績をちゃんと整理しなくては....