責任を取る とは？

まだまだ続きます「リーン製品開発方式」 からです。

以下、先月（プロセスorケースバイケース？）紹介した衝撃的な内容に続く
第2弾です。

「責任を取るとはプロジェクト全体の成功に貢献する事」

これはちょっと驚きました。

責任　というと、どっちかというとトラブルが起きた場合の対処や

損害賠償的な事を考えてしまいます。

こう考えてしまうのは、私だけでしょうか？！

しかし、こんな後ろ向きな事ではなく、

必ず成功させる事が責任という事で、認識が真逆な事が衝撃的でした。

そして、こう続きます。

「自分達の専門領域のためだけでなく、

　また言われた通りに行動するだけでなく結果を求める事である。」

つまり、責任を取るとは、結果を求める事

という事です。

確かに、そうですよね。

結果を出さなければ意味が無いですよね。

という事で、最近我がグループでは、

より成果、結果を意識するように「ミッション」を流行語にしました。

まずは、あちこちで、「ミッション」という言葉が飛び交うように

可能な限り、ホワイトボードにミッションを記載する

といった事から始めています。

これが、可能な限り、短い期間でのミッション設定をする事に繋がれば

と思っています。

そして、各自がミッションを達成し、

１つ１つに責任を取る事を積み重ねていく。

その結果は、必ずプロジェクト成功となる筈！

美しく、首尾一貫

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

ビジョンの合意を得る為には、
「ビジョンは方向性を示し、努力を統合し、美しく、首尾一貫している必要がある」

先月から、あまり読み進められていませんが、ここまでで一番好きなフレーズです。

美しく、首尾一貫している必要がある

特にここがお気に入り！

やはり美しさを求めないといけませんね。

リボンモデルも1つのビジョンかと思います。
美しくアートな開発を目指して！


それから、これもお気に入り

製品とバリューストーリームに対して明確で論理的なアーキテクチャーを定義する

アーキテクチャー大事ですよね。
この書籍の中のアーキテクチャーとソフトウェアのアーキテクチャーは
若干異なる可能性はありますが、

構造という意味では、ほぼ同じかと思っています。


常に、美しく、首尾一貫したビジョンを示していきたいですね！

プロセス or ケースバイケース ？

やっとこ「リーン製品開発方式」を読み始めました。

まだ1/4程度でしょうか。
しかしながら、冒頭から衝撃的な事が次々と....

そのうちの1番は、もう少し整理してからじゃないと....
という感じなので、

2番目くらいから。

「最も注意深く詳細まで定められた開発プロセスを持つ会社が
　なぜ一番大きな問題を抱えてしまうか。
　その理由の1つは、
　文書化されたプロセスは開発者に非効率な手法を使う事を強いるためだ。」

文書化されたプロセスは非効率

と、言い切っています。

すごいですね！

それに対して、トヨタでは、

「トヨタ標準プロセスを突き止めようと開発者に聞くと、

　毎回「ケースバイケースだ」との答え返ってきた。」

という事なのですが、

こちらも、「ケースバイケースだ」と言い切ってる事がすごいと思います。

前回の非マニュアルと同じく、要するに

受動的なプロセスではなく

主体的なカスタムプロセスが無駄を無くす。
（リーンでは無駄を無くす、非マニュアルでは感動を生むという感じでしょうか）

という事だと思うのですが、
説得力というか、力強さに圧倒されますね。

しかし、ケースバイケースで、どうやって品質を確保するのか
というツッコミがありそうですが、

それについては、

「トレードオフ曲線に埋め込まれた知識を用い

　知られている問題を設計から除外しながら

　更に問題が発生することを予想して新たな解析や試験を開発していた。」

という事で、
プロセスとは別に、
データに基づいて品質を確保する方法を確立している。

という事です。
すごいとしか言いようがないですね。


で、これをソフトウェア開発に適用出来るのか？！
という事ですが、

トレードオフ曲線はやりたいですが、
ソフト開発では難しい気がしています。

因果関係図くらいは作成出来るとは思いますが、
それと品質を結び付けられるか
という点では、これまた難しい気がしています。


とにかく、A3報告書で知識を蓄積してみる
などと考えましたが、
再利用されなければ無意味ですし、
これまでも文書で残したものが再利用された事など皆無な気がします。
なので、ただ蓄積してもダメな事は明白です。

そこで結びついたのが、
以前紹介した、複数案。
これを蓄積すれば再利用も可能では？
と考えています。

現状でも、デザインパターンは考え方として再利用出来ているので、
これをメリット、デメリット、適応性などと共に蓄積すると
再利用し易くなるのではないか！？

などと日々考えています。

非マニュアル化

先日、新聞で
フジオフードシステム社長　藤尾政弘さん
の記事を読みました。

そこには

「チェーン店を出すにはマニュアルは必要だけど

　マニュアルで感動は生まれない。

　お客さんに

　ゆっくり食べてね

　と話しかけられる距離感が大事。」

これ、ソフトウェア開発でのプロセスも同じかも！？

と思いながら読んでいました。

同じように開発プロセスも必要ではありますが、

そこからは感動は生まれないと思います。

昨今では、プロセスがある故に考えなくなっている

いわゆる思考停止状態でしょうか。
というような事を聞く機会が増えたように感じます。

必要なのは、顧客の要望に合わせて

基本（プロセス）を抑えつつどのように利用するか、

どのようにカスタマイズするか

という事が重要なのだと思います。

更に、記事には、こんな事も

「従業員がマニュアルでなく笑顔になるには

　日ごろのリーダーのコミュニケーションが大事です」

ソフトウェア開発でも同じかと思います。

笑顔だけでなく、モチベーション、ゆとり、などなど　

は日ごろのリーダーのコミュニケーション次第ですよね。

セットベース開発とA3報告書 と 考える時間

本日、ゴールシステムコンサルティングさんに初めてお伺いしました。

もちもん、

最新手法で開発生産性倍増を目指せ！　TOC/CCPM×リーン開発セミナー

を受講する為です。

受講目的は、リーンを学ぶ為はもちろんですが、
今回は特にセットベース開発でA3報告書を残すという改善について
具体的な事例を聞き出す！　です。


最後のQAでは、A3報告書に関する質問も多く
みなさん興味のあるところなのかな　と改めて感じました。

ですが、今回、一番驚いたのは、
セミナーの冒頭に、西原さんから
どこの開発でも「考える時間」が削減されている」
「考える時間」が無いといった技術者の悩みを多く聞く
という事で、
私の取組も、開発現場の問題解決のヒントになっていれば
と改めて感じた次第です。


以下、本日のセミナーに参加して
今後やってみようと思った事。
#まだ聞いたばかりであまりまとまっていませんが...

セットベースのイテレーション毎に（リーンではIE？）

1)まずは、イテレーション開始時に、A3報告書を残す事を合意する
2)各課題や調査事項ごとに、記載の有無を明示
　（LAMDA表みたいなものに、A3を記載する／しないを追加）
　記載項目は、都度検討し、全部書かなくても良いものとする
　また、記載は、手書きや、ホワイトボードもOKとする
3)イテレーション終了時に、記載したA3報告書を整理、追記
　この時間を出来るだけ短くしたい（1日くらい....）

みたいな感じで出来ると良いかなぁ....
と考えています。

しかし、その後、Knowledge Baseとしてそれを整理したりする事も必要
という事も大収穫でしたが、
こちらは、じっくり考える必要ありですね...


また、最後には、稲垣さんと
組込み開発にはセットベースや因果関係図などリーンが適用可能
といった事もお話し出来ました。

プロジェクトと共に成長する

ASDoQ大会2014に参加しました。

そこで、「アジャイル開発の教科書」などの著者である細谷さんと
お話する機会がありました。

というより、お話したくて参加しました。

ASDoQ大会2014を通して、
改めてアジャイル（リボンモデル含む）とは
プロジェクトと共に成長する
プロジェクトの中で各技術者が成長していく為のアプローチだと感じました。
もしかすると、それがプロジェクトを成功に導く為の大きな要因なのかもしれませんね


成長する要因は以下の3点かと思います。

・その１：能動的となる

プロダクトオーナー（顧客　or　もしくは仮想顧客）
と開発チームが一体となって相互理解の元に意思決定していく事が
開発チームを能動的にする。
能動的な事は成長の大きな要素となります。
更には、能動的な事は無駄な事や後戻りが減る事にも繋がります。

・その２：機会が多い

イテレーションや単体テスト、リファクタリングを繰り返すので
失敗しても、改善する機会が多い
更にはもっと良くする為の改善なども可能となる。
プロジェクトで繰り返しが多い事（機会が多い事）
がプロジェクトの進行と共に自然と成長していく

また、意思決定から動くソフトウェア作成
までを出来るだけ小さくする事で、
意思がダイレクトにソフトウェアに反映される。
という実感を得られる。（何の為の作り込みかが分かる）

そして、サイクルが小さい為に、それを何度も経験出来る。
つまりは、価値の確認やフィードバックなどを何度も得る事が出来る。

・その３：一体感

顧客を含めた一体感の中で開発していく事も
成長には大きな要因となると感じています。
楽しい、役に立っている、ワクワクする
といった感情が、「もっと～したい」、「より～したい」を増殖させて
各々もチームとしても成長していく事に繋がる。

考える時間

昨今、ソフトウェア開発で、
考える時間を削減する傾向にある気がします。

複数案もそうですが、
多角的に考えて、メリット／デメリットを共有した上で
一気に作る

のが最も早く作れる気がしています。

これは、つまるところ、

セットベース開発にて
多角的に分析し、
ポイントベース開発で一気に作る

のが最も早く作れるのだと思うのです。
セット・ポイントベース開発についてはこちらも参照してみて下さい。
セット・ポイント開発のススメ

セットベースの段階で
個客と共にいろいろと考え、共有する事が
ポイントベースの速度が上がる最大の要因だと感じています。


昨今は、このセットベースの段階を省略、
もしくは、とても短い期間となり、
ポイントベース開発が出来る状況では無いのに
ポイントベース開発に入ってしまう事が多いのだと思います。


そんな状況なので、
プロセスとか、いろいろな事をリセットして、
「今、本当にすべき事は何か？！」
みたいな事を
議論というより、みんなで改めて考えてみよう！
という感じで社内ワークショップとして開催してみました。

その結果をざっくりまとめて公開しました。
考えよう！

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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

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

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

出力しよう！

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

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

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

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

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

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

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

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

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

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

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

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


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

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

そこから改善していく。

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

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

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

実装時は、複数案を意識せずに考えている？！

前回は、設計において複数案を考える
でした。

今回は、実装時にも有効
という事ではなく、
実装時には意外と、複数案考えていませんか？！

設計時よりも、実装時は、比較的複数案を検討し、
ベスト？なコードを選択している事は多いのでは無いでしょうか？


例えば、デバッグ時です。

原因は分かっても、さてどう対策（修正）するか
といった場面は誰しも体験しているかと思います。

この場合、複数案を検討している事が多いのではないでしょうか？
また、このような場面ではペアプロ（ペアで作業）しているケースも多いかと思います。


例えば、複雑な処理を実装する時です。

タイミングや分岐条件が複雑な場合など
どう実装すれば分かり易いか　など
こっちが良いか、あっちが良いか　などなど
詳細設計まで落ちていても、
細かいところでは、実装案を複数考えている事がある気がしています。


などなど、意外と
実装時には、あれこれ考えている気がします。

実は、設計でも複数案考えているのかも！？
と思ったりもします。

設計時にもいろいろ考えてはいますが、
コードのように実装イメージが明確ではなく
曖昧な状態な気がしています。

なので、設計時は、
複数案をある程度まで形にする必要がある気がしています。

設計の場合は、形に（アウトプット）して見直す事で、
メリット・デメリットを明確にする
という事が必要なのだと思います。

実装の場合は、実装イメージそのものがアウトプット（最終形）になるので、
出力する前に解決可能となり、
複数案を考えている事が分かり難いだけで、
複数案考えているケースが多い！

と思います。

続・複数案で考える

前回の続きとなりますが、

設計では複数案を検討するのは
とても有効だと思っています。

上流設計であればあるほど効果は高いかと

特に重要なアーキテクチャー設計では必須！？

複数案を検討し、メリット、デメリットを比較し
何を、どんな理由で選抜するか

といった事が明確になる

と、いうより、
複数案を検討し、メリット、デメリットを比較し
何を、どんな理由で選抜したか

を明確にする必要がある

という事だと思うのですが、

初期の段階で、これを明確にしないと、

その後の工程で

”どうすべきか”が時間と共に徐々にブレてきます。

このブレが大きくなると、

アーキテクチャーのメリットが最大限に生かされず、

デメリットを克服出来ない

という結果となり、

当初に検討していたアーキテクチャーは
影も形もなくなってしまいます。

明確にしてもブレてしまう問題はありますが、
こちらの対策は、また今度。

まずは、明確にする事が大事かと思います。

少人数のプロジェクトであれば、
明確にするだけで、各自がメリット、デメリットを生かす為に
更に工夫していきます。
そうなると、アーキテクチャーは、より強固なものとなります。

もしかすると、こういう状態にならないと、
アーキテクチャーは維持出来ないのかもしれませんね.....

複数案で考える

昨今、設計やコードが吟味されていないと感じる事が多いです。

吟味されていない原因を考えてみると、
1)どのように吟味して良いのかを知らない技術者が多い
2)論理量の肥大化と反比例して、短納期要求が多い

という事かと思います。

特に受託開発では、2のような状況を理由に
良いものを追及するモチベーションが低下しているような気がしています。

その長年の蓄積により、1となる？
もしくは、いろいろ諦めている間に、吟味しなくなる
のかもしれません。

要するに、
現場の声は、「そんな時間は無い！」
という事なのだろうと思います。

しかし、時間が無いからこそ、良いものを追及する事で
短期間で高品質が実現出来るのだろうと思います。

と、いうのはタテマエで、
良い物を追及する方が結果的に、ラク出来るので
最大限ラクする為に
どーするかを必死に考えているだけです...

そして、ラクする為に
最近お勧めしているのが、複数案を検討する事です。

複数案を検討し、それを選択する事で、

1)多角的な視点が生まれる
2)レビュー時にも、様々な意見が出る
3)漏れ抜け防止にもつながる
4)どうして、この設計にしたのか、このコードにしたのか　が明確になる
5)デメリットが明確になる

インセプションデッキ同様に
やらない事や、デメリットを明確にする事って
重要だと思っています。

デメリットを明確にするには、
この複数案による選択はとても効果的かと思います。

デメリットが分かっていると、
そこで無理をしなくなる　

分かっていないと
デメリットを無理矢理に、強引に力技で突破してしまい
そこから、どんどんコンセプトやアーキテクチャなどが崩れてしまう。

一度壊れると修正は難しく、どんどん汚くなり、
超巨大な関数が作成されてしまう　など
ウィルスのように、あっという間に全てに感染していきます。

このような失敗をしない為に
複数案を検討し、選抜するアプローチ
如何でしょうか？

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

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

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

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

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

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

を「分ける」のです。

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

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

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

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

というのも、

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

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

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

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


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

だと私は思います。


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

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


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

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


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

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

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

10の手強い質問

先日、インセプションデッキ使ってみました。
といっても、私は「使ってみて！」と　お願いしただけですが....

受託開発でも営業的な立場の人を参加させれば
十分使える（効果が高い）と感じたので、
各プロジェクトリーダーにお願いしました。

ほとんど説明はせずに、自分達で調べて使ってみて！
と、お願いしただけです。

そして、その試行第一回目に参加

議論となったのは、
「やらないことリスト」　と
「トレードオフスライダー」

この2つと「夜も眠れなくなるような問題」
の3つは私のお気に入りです。

そのお気に入りの2つで議論となったのは
なんともワクワクしましたね。



やってみて、改めて
インセプションデッキではなく、

「10の手強い質問」

として、次回は、10の質問は以下のタイトルで試行してみようと思いました。

それは、可能な限り、開発で使わない言葉や
極端な言葉を使った質問にする方が
より多角的な視点でプロジェクトを捉えるキッカケになるような気がしたからです。

1　我々はなぜここにいるか？！
2　エレベータピッチ
3　目指すイメージ画像（絵）
4　やらないことリスト
5　ご近所さんを探せ
6　攻撃的な解決策を描く
7　夜も眠れなくなるような問題は？
8　セットとポイントを見極める
9　何を諦めるか
10　何がどれだけ必要か

受託開発に特化する面も多少ありますが、
今後も、このタイトルを模索していこうと思います。

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

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

ですが、

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

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


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

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

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


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

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

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

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

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

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

似て非なるものは分けて考える

前回の続きとなりますが、

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

についてです。

ソフトウェア開発は、「似て非なるもの」だらけでは無いでしょうか。

私もこの業界でいろいろとソフトを作ってきましたが、
ほとんどが似てるけど、ちょっと違うもの　な気がします。

例えば、
ある機能を少し拡張した開発は
変更前とは少し違うもの　になりますし、

例えば、
組込み機器の外部I/Fを変更する開発は
やる事は同じだけど、I/Fだけを置き換える

例えば、
機種Aのある機能を機種Bに移植する開発は
機能は同じでも、機種B用の少し違うものになる

例えば、
以前実施した機能移植作業を新人技術者を入れて実施する開発は
やる事は同じでも、体制が少し違うものになる

などなど

この他にも、視点を変えると
似て非なるものが、たくさん発見出来る気がします。

それらを、分けて考える事って、とても大事だと思うのです。

なぜかというと、

理由その１：シンプルになる

細分化する事で、要求や変更内容など
「非なる点」をシンプルにする事が出来ます。
異なる点がシンプルになれば、対応もシンプルに出来ます。


理由その２：早くなる

上記と関連しますが、対応がシンプルになれば
対応時間が早くなります。
つまり、生産性の向上に繋がります。

理由その３：似てるから「同じ」と決めつけない

本当に同じなら問題無いのですが、
よくある失敗に、
「〇〇と同じだと思ったが、実際は違った」
という事があります。
分けて考える事で、決めつける事の防止と、
「同じ」である事の確認となります。


理由その４：似てるものを共通化しない

似てるものを共通化し、結果的に複雑になってしまい
メンテナンス性を低下させてしまう例があります。
これを回避する為に、分けて考えて
違うものである場合は、共通化せずにシンプルにします。


「似て非なるものは分けて考える」
と同じように、理由やその効果についても
視点を変えると、違う効果、理由がまだまだ見つかる気がしますね....

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アナログ的時間と空間

2月の大雪で新聞が何日かストップしていました。
1週間後くらいでしょうか。

その間の新聞がまとめて届きました。

それがしばらく放置されていましたが、
いい加減、片付けられそうになり、
先日、やっとこ読みました。

すると、2/15　土曜日の「天声人語」に
とても興味のある事が書かれていました。

なんと、関市の岩田製作所という会社では、
「デジタルフリー奨励金」
なるものがあり、
私用のスマホを使わない社員に
毎月5千円の奨励金を出すそうです！

驚きですよね！
ですが、
注目すべきはその目的です。

岩田製作所の社長曰く

「人と話す。本を読む。物思いにふける。
　そんなアナログ的時間と空間が増えれば、
　想像力、表現力、他人をおもんぱかる力がつく。
　10年もしたら相当に差が出て、企業としての競争力がつくだろうと思う。」

という事で、
とても納得しました。

特に「物思いにふける」って大事だと思います。
他人から見ると、「ぼーっ」としているように見えるかもしれませんが、
この時間を大事にするか、しないかの差は大きい気がします。


ソフト開発でも、
「人と話す。本を読む。物思いにふける。」の3つ
いわゆるアナログ的な時間と空間はとても大事ですね。

仕事中に「ぼーっ」としていると、
文句を言われそうですが、そんなの気にせずに
物思いにふけましょう！

私はもちろん、仕事中に良く「ぼーっ」としています。
もしくは、フラフラと歩き回ったしています。

そんな時は、物思いにふけています。

より良い設計アイディアや
原因不明の不具合を調査している時などは、
誰かを捕まえて話をして、しばらくぼーっとする
のを繰り返す事が多い気がします。

社内では、議論しよう！
と様々な場面で呼びかけていますが、
1人で「物思いにふける」事も大事ですね。
これからは、「アナログ的時間と空間」など
使わせてもらいます！

アナログ的時間と空間を増やして、10年後に相当な差をつけちゃいましょう！

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

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

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

組込みでの事例です。

ET2013 プレゼン

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

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

 

 

仕事はじめ

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

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

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