何かとA3を書くようになりましたが、
と、同時にA3を書いてもらう事も多くなりました。
A3って本当に不思議です。
書いてもらうと、
まさしくプロセスだと感じます。
「トヨタ式A3プロセスで仕事改革ーA3用紙1枚で人を育て、組織を動かす」
のように、まだまだうまくはいきませんが、
それでも、定期的に共有、更新(書き直し?)していく事で、
書いている人はとにかく考える。
書かせる私も同じく考えるので、
お互いに、同じゴールに向かって右往左往しているのが実感出来ます。
この右往左往する事が大事で、これがお互いの成長に繋がるのだと感じます。
一方、A3を書く機会が増えたのですが、
徐々に書き出すまでの時間が長くなっている気がします。
A3を作成し始めた当初は、あまり時間をかけずに作成していた気がするのですが、
最近は、最初というか書こうと決めてから数日は必ず固まります。
なんとなくですが、
作成したA3が増えると、過去に作成したA3を見る機会も多くなるので、
現状では、ぼんやりとした改善点が頭にあり、
モヤモヤした状態でA3作成に入るので、時間が掛かっている気がします。
恐らく、A3にすると悪い点が早期に発見可能で、たとえメンターがいなくとも
ある程度は自身で気づく事が可能なのではないかと思っています。
などなど、モヤモヤは晴れませんが、
想像以上の効果がA3にはあると感じる今日この頃です。
2015年11月13日金曜日
2015年10月26日月曜日
価値共創A3
ソフトウェア開発者は、基本的に受け身である
という仮定から
プロジェクト毎に価値共創A3を作成する
というアイディアが生まれました。
何が価値となるか、何が無駄となるかを
プロジェクトの最初から最後まで自身に問い続ける為のA3
プロジェクトを管理するのではなく、価値を管理する
というイメージで、A3プロセスを通じて、A3を作成していく。
CCPMの余計なところを管理せずに、集中すべきところを管理する。
というコンセプトにも合致していて、
集中すべきところを「価値」として管理する。
実際のところソフトウェア開発では認識の違いが大きな問題となる為、
作業の進捗管理よりも、価値などを管理する方がより効率的になるかもしれませんね。
ただ、価値をどう管理するかはかなり難しいですが....
A3として作成する事で、他者が活用可能となり、
更に、良いA3が作成されていく。
課題はさておき、こうなると良い事ずくめですね!
やっぱりやってみようかなぁ
という仮定から
プロジェクト毎に価値共創A3を作成する
というアイディアが生まれました。
何が価値となるか、何が無駄となるかを
プロジェクトの最初から最後まで自身に問い続ける為のA3
プロジェクトを管理するのではなく、価値を管理する
というイメージで、A3プロセスを通じて、A3を作成していく。
CCPMの余計なところを管理せずに、集中すべきところを管理する。
というコンセプトにも合致していて、
集中すべきところを「価値」として管理する。
実際のところソフトウェア開発では認識の違いが大きな問題となる為、
作業の進捗管理よりも、価値などを管理する方がより効率的になるかもしれませんね。
ただ、価値をどう管理するかはかなり難しいですが....
A3として作成する事で、他者が活用可能となり、
更に、良いA3が作成されていく。
課題はさておき、こうなると良い事ずくめですね!
やっぱりやってみようかなぁ
2015年10月16日金曜日
受託開発のサガ?!ソフトウェア開発のサガ?!
最近、トラブル続きで、
その原因を対立解消図や因果関係図を使って分析しています。
分析の結果、
「受け身だった」
「早く終わらせたいという気持ちから自分勝手なゴール設定をした」
という根本原因が見えてきました。
「ソフトを作っていたい」、「動くものが作りたい」、「早く動かしたい!」
といった”サガ”が、その行動を引き起こす!
という分析結果です。
これってプロフェッショナルのやる事???
これも「不確実性の非耐性」と言っていいのか???
という感じですが、
この”性(さが)”も分からなくは無いです。
ここで、1つの疑問が。
これは、受託開発だからそうなるのか、
それとも、メーカーやツールなどの
製品開発に関わるソフトウェア開発技術者全般に言える事なのか?!
組込み系の製品ソフトウェア開発では、
ハードなどの仕様に合わせて作り込む事が多いと思います。
この場合は、仕様提示者が別にいる事になり、
受託開発と似た状況でもあるかと想像しています。
ツール開発などでも同様に仕様提示者がいる場合は似た状況といえるかもしれません。
大きくは、システムや製品としての上流工程に如何に関わるか、
というより、プロとしてどのように関わるか
といった「関わり方」の問題なのかもしれません。
いずれにしても、プロとしての性(さが)を持つような革命?
が必要なのかもしれないと思う今日この頃です。
その原因を対立解消図や因果関係図を使って分析しています。
分析の結果、
「受け身だった」
「早く終わらせたいという気持ちから自分勝手なゴール設定をした」
という根本原因が見えてきました。
「ソフトを作っていたい」、「動くものが作りたい」、「早く動かしたい!」
といった”サガ”が、その行動を引き起こす!
という分析結果です。
これってプロフェッショナルのやる事???
これも「不確実性の非耐性」と言っていいのか???
という感じですが、
この”性(さが)”も分からなくは無いです。
ここで、1つの疑問が。
これは、受託開発だからそうなるのか、
それとも、メーカーやツールなどの
製品開発に関わるソフトウェア開発技術者全般に言える事なのか?!
組込み系の製品ソフトウェア開発では、
ハードなどの仕様に合わせて作り込む事が多いと思います。
この場合は、仕様提示者が別にいる事になり、
受託開発と似た状況でもあるかと想像しています。
ツール開発などでも同様に仕様提示者がいる場合は似た状況といえるかもしれません。
大きくは、システムや製品としての上流工程に如何に関わるか、
というより、プロとしてどのように関わるか
といった「関わり方」の問題なのかもしれません。
いずれにしても、プロとしての性(さが)を持つような革命?
が必要なのかもしれないと思う今日この頃です。
2015年9月16日水曜日
「和」とアジャイル
ある人からの宿題で「タレント」の時代 読みました。
http://www.amazon.co.jp/dp/4062883031
読み終わって
「和」は、まさしくアジャイルだ!
最後に「和」について記載されていた事もあり、
「和」が強く印象に残っています。
もちろん、人材の考え方、知識労働の考え方、価値の捉え方、ハタラキ
についても、もうその通り!
印象が強い理由のもう1つは、
トヨタのリーン、スクラム同様に
アジャイルも日本発の可能性が多いにあった!
って感じたからです。
それが出来なかったのは、
「堕落した和」「甘えの和」「無責任な和」
という事なのでしょう。
とてもとても悔しい感じです。
とてもとても残念です。
と、後悔しがっていても始まらないので、
日本人の強み「和」を発信していきたいですね!
「和」=全員が一丸となってそれぞれ自分ができるレベルで努力する
http://www.amazon.co.jp/dp/4062883031
読み終わって
「和」は、まさしくアジャイルだ!
最後に「和」について記載されていた事もあり、
「和」が強く印象に残っています。
もちろん、人材の考え方、知識労働の考え方、価値の捉え方、ハタラキ
についても、もうその通り!
印象が強い理由のもう1つは、
トヨタのリーン、スクラム同様に
アジャイルも日本発の可能性が多いにあった!
って感じたからです。
それが出来なかったのは、
「堕落した和」「甘えの和」「無責任な和」
という事なのでしょう。
とてもとても悔しい感じです。
とてもとても残念です。
と、後悔しがっていても始まらないので、
日本人の強み「和」を発信していきたいですね!
「和」=全員が一丸となってそれぞれ自分ができるレベルで努力する
これは、無限大の可能性があると思っています。
1+1=∞=「和」
だとも思うのです。
今は、興奮してまとまらないので、
冷静に、「和」についての発信の仕方を考えていこうと思います!
2015年9月9日水曜日
本質思考道場が本になりました!
今年度から始めた本質思考道場が本になりました!
トヨタ式A3プロセスで製品開発
もちろん著者は稲垣さん。
今回はA3シリーズの続編のような形での出版のようです。
前編の著者である成沢さんとの共著となっています。
実は、内容は既に知っているのですが、
書籍として手にするのが待ち遠しいです。
道場の方は、少しずつ実課題に入っています。
やはり、課題はアナロジー思考となりそうな気配。
ソフトウェア設計では、考え方の流用が有効といわれてからも、
現場では、なかなか進んでいないのが現状かと思います。
デザインパターンもなかなか浸透していないですよね。
このあたりも、アナロジー力というか、
アナロジー思考を鍛える必要があるのだと思うのですが、
まったく異なる物や事から、違う事は目についても、同じ点を見つけるのは
なかなか難しいようですね。
デザインパターンの適用も、着眼点をどこに置くかで、
適用範囲は広がる筈なのですが、なぜか浸透しない。
不思議な気がしますが、誰もそんな事教えてくれないので
当たり前のような気もします。
さて、今後アナロジー力の向上で、考え方の流用が進むまで
どのくらい掛かるでしょうか....
それとも、流用はされないのでしょうか....
いずれにしても、楽しみです!
トヨタ式A3プロセスで製品開発
もちろん著者は稲垣さん。
今回はA3シリーズの続編のような形での出版のようです。
前編の著者である成沢さんとの共著となっています。
実は、内容は既に知っているのですが、
書籍として手にするのが待ち遠しいです。
道場の方は、少しずつ実課題に入っています。
やはり、課題はアナロジー思考となりそうな気配。
ソフトウェア設計では、考え方の流用が有効といわれてからも、
現場では、なかなか進んでいないのが現状かと思います。
デザインパターンもなかなか浸透していないですよね。
このあたりも、アナロジー力というか、
アナロジー思考を鍛える必要があるのだと思うのですが、
まったく異なる物や事から、違う事は目についても、同じ点を見つけるのは
なかなか難しいようですね。
デザインパターンの適用も、着眼点をどこに置くかで、
適用範囲は広がる筈なのですが、なぜか浸透しない。
不思議な気がしますが、誰もそんな事教えてくれないので
当たり前のような気もします。
さて、今後アナロジー力の向上で、考え方の流用が進むまで
どのくらい掛かるでしょうか....
それとも、流用はされないのでしょうか....
いずれにしても、楽しみです!
2015年9月4日金曜日
何をキャッチアップするか
ソフトウェア開発のマネージメントで
何をキャッチアップしていますか?
利益率や進捗などでしょうか?
私は進捗などはほとんどチェックしていません。
バーンダウンチャートなども、たまには見ますが、
あまり当てにしていません。
現状では、ほとんどの開発がトラッキングシステムを使っています。
そのチケットの更新情報は全てメールで来るようにはなっていますが、
中身を見る事はほとんどなく、なんとなく気になったものだけ見ています。
という感じで、
なんとなく、メンバの様子をみている
というのが表現としてはしっくりくる気がします。
そこからアラートをキャッチアップしているつもりでした。
しかし、最近トラブルが続出!
キャッチアップ出来ていなかった!
と反省したのですが、
最近、どうも、そうでは無い気がしてきました。
キャッチアップしてたけど、何もしなかった
という表現が正しい気がします。
ちょっと話を戻して、
では、いったい何をキャッチアップしているのでしょうか?
やはり、各メンバの態度というか、必死度というか、悲壮感
といったところでしょうか。
どんな数値よりも、現場の雰囲気が最も分かり易い気がしています。
ですが、何をキャッチアップしているかはうまく説明出来ませんね....
何をキャッチアップしていますか?
利益率や進捗などでしょうか?
私は進捗などはほとんどチェックしていません。
バーンダウンチャートなども、たまには見ますが、
あまり当てにしていません。
現状では、ほとんどの開発がトラッキングシステムを使っています。
そのチケットの更新情報は全てメールで来るようにはなっていますが、
中身を見る事はほとんどなく、なんとなく気になったものだけ見ています。
という感じで、
なんとなく、メンバの様子をみている
というのが表現としてはしっくりくる気がします。
そこからアラートをキャッチアップしているつもりでした。
しかし、最近トラブルが続出!
キャッチアップ出来ていなかった!
と反省したのですが、
最近、どうも、そうでは無い気がしてきました。
キャッチアップしてたけど、何もしなかった
という表現が正しい気がします。
ちょっと話を戻して、
では、いったい何をキャッチアップしているのでしょうか?
やはり、各メンバの態度というか、必死度というか、悲壮感
といったところでしょうか。
どんな数値よりも、現場の雰囲気が最も分かり易い気がしています。
ですが、何をキャッチアップしているかはうまく説明出来ませんね....
2015年9月1日火曜日
SWEST17
SWEST17参加しました!
参加する度に、すごいワークショップだと思います。
これだけの多様な人が真剣に議論出来る場は、そうそうないですよね。
そして、
会社も立場も違うのに、議論のネタが尽きない事にも毎度驚きます。
なんといっても、
議論する事で得る事がたくさんあります。
失う事は何もありません。
開発現場でも、もっと議論が必要だと感じます。
その為に、あれこれ もがいていますが、
なかなか難しいですね。
ソフトウェアは、創る”もの”が決まって、どう造るかを決めれば、
あとは早いと思うのです。
なので、創るもの と どう造る
を議論しまくる必要があると思うのです。
ですが、現状は、なぜか可能な限り早く造る作業に入りたがる。
まさしく不確実性の非耐性ですよね....
その解消に向けて、悩み続ける日々です....
参加する度に、すごいワークショップだと思います。
これだけの多様な人が真剣に議論出来る場は、そうそうないですよね。
そして、
会社も立場も違うのに、議論のネタが尽きない事にも毎度驚きます。
なんといっても、
議論する事で得る事がたくさんあります。
失う事は何もありません。
開発現場でも、もっと議論が必要だと感じます。
その為に、あれこれ もがいていますが、
なかなか難しいですね。
ソフトウェアは、創る”もの”が決まって、どう造るかを決めれば、
あとは早いと思うのです。
なので、創るもの と どう造る
を議論しまくる必要があると思うのです。
ですが、現状は、なぜか可能な限り早く造る作業に入りたがる。
まさしく不確実性の非耐性ですよね....
その解消に向けて、悩み続ける日々です....
登録:
投稿 (Atom)