プロセス 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)更に掘り下げられる
　出力すると、具体的に何をもっと掘り下げる必要があるのか
　と逆に何が不要なのか
　といった事が明確になりますよね。


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

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

そこから改善していく。

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

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

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