ソフト開発はアート！？

先日、あるミーティングが脱線して、
ソフトウェア工学についての議論となりました。

その中で、
「ソフトウェア開発はアート、芸術に近い」

との意見が出ました。

全く異論はありません。
むしろ、身近で同じような主張をする人が出てきた事に喜びを感じています。

振り返ると、ざっと25年前ですね。
私は新人教育などで、プログラミングは絵を描くようなもの
と表現してきました。

構図を決めて、色を重ねていく感じが似ていると感じていました。
ソフトウェアはどのように設計しても、コードを書いても
自由なので、このあたりも白いキャンバスに自由に描く事と
似ていると感じていました。

今でも同じように感じています。
当時は同僚も含めて誰も賛同者はいませんでしたが、
今はそんな昔のことは、もう忘れているでしょうね。

世間では、デザイン思考、アート思考などが注目されています。
3，4年前くらいからでしょうか…
イノベーションには、ビジネスのサイエンスにアートを加える事が不可欠
みたいな事がいわれていますね。

これも、まったく異論はありません。
むしろ、今だからというより、今までも必要だったのでは？！
と思います。

これまでも開発者というより、アーティストという著名人は
少なからずいました

これからも、同じような表現をする人が増えるように
たとえ、賛同者がいなくとも、めげずに表現し続けていきたいと思います。

違和感を大事にする

VUCAも聞き飽きましたが、
とにかく、良く分からない今を、堂々と生きよう！
と、これまた良く分からない決意をした年始です。

改めて、ソフトウェア開発は不確実な事が多い気がします。
環境が少し変わっただけで動作しない！
なんてことも良くありますよね。

その原因が品質の問題である事がほとんどかと思いますが、
それで”良し”としてしまう事が、曖昧で不確実で複雑と言えるかと思います。

そう考えると、動くているロジックは触るな！
という考え方も分からなくは無いですが、
この考え方はプロでは無い気がします。

プロとして探求心と違和感を放置しない事は
とても大事かなと思います。

ですが、違和感はとかく放置してしまいがちです。
不思議と違和感は、
一度、放置しても思い出す事が多くないですか？
やっぱり放置してはいけない！
と思い直す事が多い気がしています。

なので、最近はキチンと感じる事が出来ているのだから、
この感覚をもっと大事にしていかないと！
と思うのです。
といいますのも最近は、この感覚を大事にしないと、
この感覚そのものが無くなってしまう！
という恐怖感が出てきたのです…爺さんになったのかな…

弱音はさておき、今年は違和感を大事にして、
リボンモデルを進化させます！

ティール組織

とんでもなく売れているのですね。
なぜでしょうか？？？？？

って感じですね。

『ティール組織』

気になり、購入しちゃいました。
まだ、野中さんの『直感経営』も読んでいる途中なのですが…

読んでみると読み易くて面白いです。
まだ半分くらいですが、夢中になって読んでしまいます。

アジャイルの実践でこれまで感じていた事などが
論理的に整理されていたり、痛快に表現されていたり
で、楽しいです。


ここまでで印象的だったのは、
オランダの地域密着型の在宅ケアサービス組織「ビュートゾルフ」
の例で、とても興奮しました。
この例だけでも、読む価値はあると思います。

成果として、ここまで圧倒的な差が出ると
これまでの組織や管理って何？
と思ってしまいます。

フレデリックさんの言い方では、
進化の過程として必要だったという事になるのかな。

ソフト開発でも圧倒的な成果となると思っていますので、
なんとかソフト開発で分かり易い成果を見える化したいと常々考えていますが…
ティール組織の実現となると、まだまだ先な感じはします。

しかしながら、これだけ売れているという事は、
日本でも、ティールな組織が増えていく可能性はあるのかもしれませんね。

ストーリーの複雑度が鍵？！

先月、久しぶりにセミナーに参加しました。
https://www.ogis-ri.co.jp/event/1273267_6738.html

CI&T社ではA3が定着している！

ソフト開発会社でA3が定着している会社は少ないだろうと想像していますが、
やっているところはやっているんですね。

昨今はスクラムはやっている！　
は当たり前になりつつありますが、
A3やセットベースをやっている！
という方にはなかなかお会いしません。

そして、メインテーマの定着についてですが、
アジャイル、リーンが定着した大きな要因は、
Business Complexity Point　
との事。

Business Complexity Point　

とは、ユーザーストーリーの複雑度との事

もちろん、相対値ではなく絶対値との事

つまり、見積もりの共通言語を作ったという事のようです。

この複雑度で大よその全体計画を作るという事なのでしょう。

対応工数とのデータを取れば比較も出来ますしね。

結局のところ、全体計画や比較が出来ないと定着しないって事ですかね…

この点がどうしても納得出来ないんですよね。
リーンやアジャイルやるなら計画や比較ではなく、提供価値を見ようよ！

って、どうしても思ってしまいます…
納得出来ますが、納得出来ないんですよね…

結局、管理する側の人達がついてこれてないだけって事だよなぁ
管理する側も今まで通りの管理では通用しない！
と気づかせる必要がありそうですね。う~ん…

TOCシンポジウム2019

時間が経つのは早いもので、
もう先週となるのですね。

TOCシンポジウム2019に初めて参加しました。
しかも2日間全て参加しました。

大きな期待を持って参加しましたが、期待以上に得るものがありました。
大満足です。

アラン・バーナード博士のお話は納得しまくりというか
「なるほど！」感じる事が多くありました。

特に2つの点が大収穫でした。

1つ目は、
我々の注意力がボトルネックとなり、判断ミスを引き起こしている
全てに集中して判断するのは確かに無理ですよね…
集中力がボトルネックだったとは！？　　でも確かに！
という感じでした。

2つ目は、
間違った事をするのは避けれないが、
・正しい事をしない
・正しい事を間違った方法で行う
は、回避可能で、その原因のほとんどが惰性か妥協である

更には、無知も原因の1つとして考えられるが、
それは教育すれば分かる。
教育しても変わらなければ、多くは惰性である

この説明は、とてもしっくりきました。
これまでのモヤモヤがすっきり晴れた感じがしました。
なんでやらないんだろう？？？　と感じる事は数多くありますので…

その他事例も身近というか、
同じ取り組み、同じ悩み、同じ考え
な事が多くあり、親近感を感じつつ
言われてみれば！　そういえば！　そうだった！
といった気づきも多く勉強になりました。

職場に戻り、関係者への展開はもちろんですが、
打合せや雑談の際に引用したりと、早速活用しまくっています！

CCPMとアジャイル（その３）

しつこいですが…もう少しだけ。

道具の使い方のような流れになっていますが、
やはり『管理』の考え方な気がしますね。

改めて、私がアジャイルを始めたきっかけとなった
『エクストリームプログラム入門』
を読んでみると、

12章に「管理戦略」という章がある。
ここでは、XPの原則に従って考えをまとめています。

先日のゴールシステムコンサルティングの村上さんのセミナーと同じです！！

やはり極めた人のアプローチは同じなのだと改めて感じます。

話しを戻して、
ケント・ベックは管理として
大きく、コーチとトラッキングの必要性を説明していますが、
随所にプログラマーの邪魔をしない事という感じの説明が出てくるので、

管理＝ケント・ベックは結局のところプログラマーの邪魔をしない事
と読み取れてしまいます。

ある意味では、何もしない事が究極の管理と言えるかも…

管理として何をするかは棚上げして、
ケント・ベックが言いたいのは、
管理＝プログラマーのパフォーマンスを最大限に出す事
なのでしょうね。

となると、村上さんの解説と全く同じになります。
という事は、
私は、何十年も前に管理が何かを知っていた事になりますね…

『エクストリームプログラム入門』
の最後に、またヒントがある気がしました。

27章に「結論」という章があり、
そこで、変化に備えない事が究極の備えである
と言っています。
全てに備えようとするのは無理なので、逆説的に何も備えない。
準備する事を諦める事が完璧な備えである。という事です。

この考え方がCCPMとの大きな違いなのかもしれません。
恐らく、バッファを準備して備える事が、
しっくりこなかったのだと思います。

最後の章を覚えていた訳ではありませんが、違和感の元はここな気がします。

しかししかし、バッファだけを監視して
バッファに問題がなければ何もしない。
バッファが危険になった場合の備えをしない
という考え方を取れば、こちらも究極の備えと言えますね！

ループに入った感じですね…

CCPMとアジャイル（その２）

前回の自問

価値がある事が大前提だと管理が必要？
価値がある事を疑うと、管理は不要？

恐らく、どちらでも無いというか、
単純に価値がある、無いだけの事では無いのでしょうね。

CCPMは、やはり管理が前提な気がしますね。

そもそもなぜ管理が必要か？
管理って何？
という感じです。

アジャイルでは、やはり管理を不要とするプロセスな気がします。
ただ、要求と価値は管理していると言えるかと思います。
しかも、関係者全員で。
そして、それ以外は管理していない。

本来管理する目的は、価値創造を最大限にする事な気がします。
CCPMもここは同じだと思います。

するとやはり、何を管理するか
が問題なのでしょうか？？？

大きくは今の状況を見える化して、対処すべき事を判断する
のが管理な気がしますが、
アジャイルでは対処ではなく、価値創造に集中している気がします。
これが管理となると、対処となり、
元に戻す（正常状態にする）事に集中している気がします。

ここが大きな違和感の元な気がします。

アジャイルでは
何をするかを決めるだけなので、あまり管理している感じはしません。
だから違和感となるのかもしれません。

CCPMもスケジュールやバッファを管理しているのではなく、
バッファにより変化した状況を把握して、価値創造の為に次に何をすべきかを管理する。
とも言えそうです。

そんな事を考えていたら、
本日、偶然にも「管理とは？」の1つの答えを得ました。
これはまた次回以降で紹介するとして、

CCPMでとてもしっくりくる事が1つあります。
それは「フルキットの」考え方えす。
これはアジャイルにとても近いと思うのです。
そして、CCPMのキーとなるのもフルキットだと思っています。

リーンの安価な実験と同じく、
いまある、もしくは近い将来整う最大限のフルキットで、
何が出来るかを考えて、実践する。

という事は、
要するに道具の使い方って事なのだろうか…

まだまだ自問自答が続きます…