会話⇒やらない事が決まる⇒早く作る

 早く作るには技術はもちろん必要ですが、

要求や目的がシンプルである事が大きい！

と、今回、改めて実感しています。

そして、要求や目的をシンプルにする

とは、

こちらも改めて、やらない事を決める事

と改めて。

やらない事が多く確認出来れば

いや、違いますね。

やらない事を、チームで多く、たくさん、常に、都度、話す事で、

フォーカスが絞られていく。

という感じでしょうか。

もしかすると、この　”たくさん話をする”　事が

フォーカスを絞る事、やらない事を決める事に、

大きく作用するのかもしれません。

結果的に後戻りになったり、余計なものが作られてしまうのは、

やらない事についての話が少ないのかもしれません。

話をしていると、「そこまでいらない」といった言葉も

よく出ていたような気もします。

とすると、チームでどんな話をしているかで、

早く作れるチームかが分かるのかも？！

これって、既に分かっている事だったりして…

ソフト開発と目指す状態

ソフト開発者だからなのか、
目標やゴールを設定すると、手段になる事がほぼ100％

状態を設定しましょう！
と説明すると、今度はとても曖昧なものか、またまだ手段になります。

ソフト開発者だけではないのかなぁ…

先日、チームで1つの3年後のゴールを設定する為に
各自で段階的なゴール設定をしてみよう！
という事になりました。

というのも、1人1人が違う事をやっているチームなので
各自のゴール設定する事で共通点を見出そうという狙いでした。

段階的なゴール設定とは、つまりFRTを作れば良いのですが、
FRTといっても全員には通じないので、
今回はちょっと目先を変えて
ソフト開発者には馴染みのある「状態遷移図」を作ってみよー！
と言ってみました。

すると…

結局、状態遷移図は作らずに済んでしまいました…
ワイガヤしているうちに
各自の状態遷移図を作る事なく、
チームで1つのゴールが設定出来てしまったのです…
しかも、1時間もかからずに。

これ、意外とすごいと思う。

状態について議論しているうちに、
とあるキーワードから、あれよあれよと目指す状態が決まってしまいました。
しかも、明確な数値入りです。

こんな事もあるんですね！
驚きました。

多くのケースで
その手段の結果、どうなる事を期待している？　どうなってほしい？
といった質問を繰り返して、で引き出してきました。
あまり質問を繰り返すと、全員が納得しない事もあり、
振りだしに戻る事も…

その為、今回は
「状態遷移図」という表現がイメージし易いかと考えて使ってみました。

ソフト設計やデバッグでは状態を意識する事が多いので
FRTはイメージし易いと思っていたのですが、
説明の仕方が悪いのか、いまひとつな感じでした。

ソフト設計やデバッグでの状態は、CPUやチップの中の事なので
見えるものとして存在しない、ある意味で想像、空想の世界です。

現実と空想では、脳が違うものとして捉えてしまう？！
などと妄想しています。

本質思考道場という場で、いろいろと訓練してきましたが、
「状態」の表現で止まる事も多く、ここが壁でもあり、
ここが大きな変化点なのだろうと考えています。

ソフト開発的には、ただの状態遷移図なんだけどなぁ…
とも思いますが。

しかし、今回はなぜ、あっさりと決まったのだろうか…
あっさり決まる事もあるという事を経験出来た事は嬉しい限りですが、
どうすれば、こんなにうまくいくのだろうか…
何かヒントがある筈…

と、悶々としています…

ソフト設計にもTOC！

昨今は、何をするにも正解を求めようとする傾向がある気がします。
ツールを使うにも正しい使い方で、正解を求めようとする。

正解とは何？
という感じですね。

ソフト開発の世界では、正解が無い事の方が多いですよね。
もっと良い設計、もっと良いコードと求めればキリがありません。

その為、目的により何かを選択していく事の繰り返しになるかと思います。

品質基準や品質目標に従い、設計コンセプトやアーキテクチャーを選択する
設計方針やコンセプトに従い、抽象化する対象を選択する
などなど

正解という言葉を使うと、
目的により、正解を選択していく、
正解を変化させていくイメージでしょうか。

そして、TOC思考ツールは
選択や目的達成に向けた考えを整理する為、再認識する為に活用出来ます。

設計などでモヤモヤする事があれば、
クラウドが活用出来ます。

UDEには品質目標とのギャップや
現状のメトリクスなどを設定すれば良いかと思います。
現状のメトリクスよりも上げたいのであれば、
現状のメトリクスの値がUDEとなりますので。

新規であれば、前バージョンや似たシステムのメトリクスや
予想される（見積もった）テスト時間や開発期間などでよくある
顧客要求（予算）と見積りとのギャップをUDEにすると、
考えが整理されると思います。

よくあるモヤモヤは、
リファクタリングする／しない
新たな手法や技術にチャレンジする／しない

かと。

それぞれのニーズを考えるだけでも
考えが整理されます。

そして、結果的に考えが視覚化されます。
ツールとして中途半端であっても、使い方が間違えていても
考えが視覚化されるので議論が可能となります。
この効果はとても大きいかと思います。
議論出来る事も収穫であり、議論した結果が収穫となる事もあるかと思います。

TOCは、正しく使えなくても、
収穫が得られる素晴らしい思考ツールですね！
ソフト開発でモヤモヤしている時にも活用してみましょう！