ソフト設計にもTOC！

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

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

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

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

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

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

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

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

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

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

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

かと。

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

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

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

考えるツールTOCその2 逆の行動が視点を変える

前回は、クラウドを使った考え方を紹介しました。

その後、いくつか似たようなクラウドを書いていますが、
改めて、逆の行動を考える事の重要性に気づかされます。

行動としては単純に逆の行動を記載するだけですが、
記載した瞬間から視点を変える思考が開始されます。

更にそのニーズ（図のC）を考えるとなると、
視点を切り替えて考える必要があります。

ここでニーズが思いつかない、出てこない事も多いですが、
その場合は、視点が切り替わっていない、思考が切り替わっていない
感じがしました。

思考が切り替わると、多くの気づきが生まれます。
図として完成しなくても、気づきが得られる事も多いのだと
改めて実感します。

今やっている行動から、逆の行動を考える！
単純ですが、協力なアプローチです！


話しは少しそれますが、
ソフトウェア設計でも複数案考えるセットベース設計は、
これと少し似ている気がします。
複数案＝複数の視点
複数の視点で設計を見る（見直す）事で、新たな気づきが生まれる。

複数の視点から見る事が、検証になり、品質が向上する。
こちらも広めていきたいです。