ソフトウェア開発での「三現」とは？（その2）

前回に引き続き、

三現主義とソフトウェア開発について、モヤモヤと考えています。

すると、1つの仮設が。

タスクボードやバーンダウンチャートが

現状、今を表しているのであれば、三現主義の考え方が浸透している（実践されている？）

といって良い気がする。（仮設）

であるならば、この場合の三現は…

現場：動作環境（PCや評価基盤、試作機などなど）

現物：ソースコード、バイナリ

現実：いま動作している状況、この後の残りの何にフォーカスすべきかの共通認識

という感じ？

現実が、いまいちな感じがします。

現場：動作環境（PCや評価基盤、試作機などなど）

現物：ソースコード

現実：自動テスト結果（CIや単体）

バイナリは見ても分からないので、現物から削除しました。

現実が曖昧だったので、誰が見ても同じ認識となるテスト結果にしてみました。

現場は、開発環境も含むかと思いましたが、曖昧さは排除出来ないと思うので、

曖昧さは残りますが、いちおう動作環境は定義しますし、

誰もが同じ認識となるので動作環境としました。

しかし、これだと創るものが定義された状態が前提となる気がします。

価値提供を前提とするのであれば、

現場：動作環境（PCや評価基盤、試作機などなど）

現物：ソースコード

現実：価値検証結果

という感じでしょうか？？？

しかし、これだと現実が曖昧かな…

う～ん…

ソフトウェア開発での「三現」とは？

「なぜ？」という質問がNG（NLPではNG）な事と「なぜなぜ分析」を考える上で、

三現主義は「なぜなぜ分析」とセットだと思いますので外せません。

という事で、

三現主義、「現場」「現物」「現実」ですが、

ソフトウェア開発では具体的に、何になるのか考えてみました。

しかし、生産と開発の違いがありすぎて、全く、まとまりません…

まとめようとすると、違いが次々に上がってくるのでフォーカス出来ません…

そんな中、気づいた事が１つ。

ソフトウェア開発でも、事実を掴む、把握する為の手段として三現主義を活用しています。

それは、不具合分析、解析です。

ソースコードデバッグが出来ない場合において、最も効果的に活用されていますね。

不具合分析をする場合、現象を何度も再現させて確認します。

再現させながら、

ソフトウェアがどんな動きをしているかを頭で考えて、想像してシミュレーションします。

つまり、現象から「現実」を掴む為に、ソースコードを見ながら想像します。

ソースコードは「現物」ですね。

「現場」は再現可能であれば、実際の「現場」に行く事はないですが、

再現不可能な場合は、「現場」で分析、解析します。

何度も再現させる事や、不具合の症状や現象から考えるのは、

まさしく、三現主義だと気づきました。

意外と身近で使ってるのだと、改めて感じた次第です。

バッファとゆとりとスモールリリースとFRT

 CCPMのバッファだけを監視する

という考え方はシンプルで誰でも状況把握可能かと思います。

しかし、バッファという言葉が、どうもしっくりきません。

言葉というより「バッファを入れる、付加する」というアプローチがしっくりこない感じ。

自然に入るものであるべきというか…

ゆとりの法則も、何度も読んでいますが、

必要なのは納得なのですが、”ゆとり”という言葉がどうもしっくりきません。

こちらも、言葉というより「ゆとりを取り入れる」というような

敢えて、組み込むような感じがしっくりこない感じです。

こちらも、敢えてではなく、普通に”ある”ものであるべきな気がするのです。

そして、アジャイルのスモールリリースは、”ゆとり”やバッファとは対局のようですが、

同じ考え方だと思うのです。

価値を小さく短い期間で提供していく事が、”ゆとり“やバッファを作り出す。

これでは分かり難いですね。

”ゆとり”もバッファも価値定義の曖昧さに含まれると思うのです。

最初のリリースの価値定義、リリースするモノ（仕様）は、多少なりとも曖昧さがあり、

「まずは、ここまで作ってみましょう。」

というようなスタートになる事が多い気がします。

お互いの認識合わせをしながら形にしていくようなケースが多いかと。

そうなると、いい意味で探り合いしながら進めるので、

最初は曖昧となるが、リリースを重ねる事で、認識も、価値定義も合ってくる。

そして、この曖昧さが”ゆとり“であり、バッファと言えると思うのです。

当然、後半は”ゆとり”もバッファも、少なくなりますが、

後半は何が重要であるかという認識も、作業スペースも掴めている状況なのですし、

全ての認識合わせが出来ている状況で、たとえ、短期間で一気に作り上げるといような

いわゆる“ゆとり”が無い状況だとしても、

士気は最高潮、集中力も高くなるのでミスも少なくなります。

予算の関係から、何回のリリースで完成するのかが明確でないと受け入れられない！

という事も言われますが、

これも、完成品が見えてくれば、その後の回数は分かります。

完成品が見えるまでを試作評価期間と考えるなど、対応方法はいろいろあるかと。

そうそう。こういう時こそ、曖昧な価値定義や仕様を仮説検証FRTですね！

2つのFRT（曖昧なFRTと検証した結果を書き込むFRT）

にする事で、おおよその計画となります！

仮説検証FRTについては、改めて紹介したいと思います。

と、いう事で、

スモールリリースとバッファ監視。

対局のようで、実は同じでは！？

そして、スモールリリースはしっくりきます。

なぜ削れないのか

ソフトウェアを早く作るには

目的を決める事、仕様を決める事

しかも、早く決める事が

大きく影響します。

そして、シンプルにする事

なのですが、

究極までに機能を減らす事

と表現した方が良いでしょうか。

先日、こんな相談がありました。

「余計な機能はいらない。〇〇だけが出来ればいい。そんなソフト作ってよ」

実は、この、〇〇だけが出来るソフト

の企画を数年前にしたメンバーがいたのです！

もちろん、今回のようなユーザーがいる

という仮説を立てて、サンプルを作成しました。

私含めて、周囲は全員賛同し、一気に作成しました。

競合は多くありますが、ここまでシンプルなものは

当時も今も無いのですが、

サンプル作成で終わってしまいました。

今からでも遅くない？！

と、いろいろ考えてしまいます。

競合が機能を削るのは簡単だと思いますし、

製品ラインナップにあっても良い気がします。

なぜ機能を削ったものが世の中に無いのか。

なぜ機能を削る事が出来ないのか？！

幅広いユーザーを獲得するには、機能が豊富である必要がある？

同じ開発費用で多くの機能を盛り込む必要がある？（コスト削減？）

削る理由がない？

削って売れなければ、大目玉？！

多くのアサンプションがありそうですね。

根拠は全く無いですが、ちょっとしたきっかけで変わる気もします。

どうすれば、削る方向に向かうのか。

売れれば問題無いのでしょうが、それは結果ですからね。

創る段階、企画の段階で「削る」決断となる、何かが必要ですよね。

ん？！

そもそも企画にする必要がある？

ある企画の中に潜り込ませれば、イケル？？？

これだと決断にはならないか…

削ってみようと思わせる何か。

何か手はありそうな気がしてきました。

更に考えてみたいと思います。

なぜなぜ分析では言い訳となる？

 「なぜ？」と聞かれると本能的に言い訳を考える。

また、否定的なニュアンスがある。

と。

NLPの本を読んでいて目についた。

（『手にとるようにNLPがわかる本』）

納得するところはある。

つい、言ってしまいがちな「なぜ？」

とても便利な「なぜ？」

では、どうするか。

「どうしたの？」と言い換えるなど、

いくつか言い換えの例があったが、

場面毎に変える必要がありそう。

ソフト開発業務のありそうな場面を思い浮かべると

書籍の例ではしっくりくるものは無かった。

というか、「なぜなぜ分析」はNLPとしてはNGって事か！

ずっと、ソフト開発には馴染まないと思っていました。

不思議な感じはありません。

理由のひとつは、今回の「否定的なニュアンス」かと思う。

ソフト開発での不具合混入原因などに活用すると、

どうしても、担当者を否定する方向になってしまう。

うまく、人ではなく、仕組みやプロセスの方向に誘導しても、

どうしても、担当者を否定している感じが残る気がしていました。

その答えが見つかった気がします。

ソフト開発は人以外の製造工程はないのですが、

製造などでは、人以外にも関係するモノや工程、過程などがあるので

人を否定している感じにはなり難いのだと思っています。

TOCを知ってからは、TOCの方が分析が早かった実績などもあり、

なぜなぜ分析は活用していませんが、

それでも、「なぜ？」は便利ですよね。

日常で、けっこう言ってる気がします。

これを言い換える為には、一回飲み込む必要がありそう。

しかも、場面毎に変えるのも難しそう…

どの場面でも活用可能な言葉はないだろうか？？？

う～ん…

場面毎に変えるしかなさそうですね…

改めて、アジャイル宣言の背後にある原則

 「アジャイル宣言の背後にある原則」って長いなぁ

https://agilemanifesto.org/iso/ja/principles.html

アジャイル宣言も

アジャイル宣言の背後にある原則も

ちょくちょく読み直します。

なぜでしょうか？？？

何か、思うところがあって、読み直すのですが、

そのシチュエーションは様々ですね。

今回は、TOCのフォーカスする事とスモールリリースって狙うところは同じだよなぁ

って想いながら、なんとなく原則を読みました。

すると、

“シンプルさ（ムダなく作れる量を最大限にすること）が本質です。“

が目に止まった。

シンプルにする事は、早いリリースを可能にするだけではなく、

量も最大化する。

つまり、フロー（流れ）も最大化するって事ですね。

リソースを増やすのではなく、

シンプルにする事で、最大化する！

昨今、ますますソフトウェアって早く創れるようになったと感じます。

条件は、目的と手順が決まっている事ですね。

そして、最近は、決める為に必要なのが『シンプルさ』だと思うのです。

複雑にしない。シンプルにして決める！

そして、もう1つポイントだと思う事が、

プロダクトオーナーとソフト開発者を仲介する存在の必要性です。

この存在がシンプルさの実現に大きく寄与すると思っています。

プロダクトオーナー的な思考を持ったソフトウェア開発者が仕様を設計する事で、

仕様もソフトウェア構造もシンプルになる。

改めて、シンプルさが本質ですね！！

FRTとABテストとLAMDA

新たな企画での仮説を検証する為に検証リストを作成しました。

検証する事が、学習する事になるのですが、

ここ、モヤモヤしています。

仮設を立てて、検証して、結果が出る事で学習して、さらなる仮設につながる。

1つ目のモヤモヤ

LAMDAは学習サイクルであり、これまでも有効活用してきました。

しかし、価値検証の学習フェーズではLAMDAは向かない？！

うまく活用出来ていないだけ？

2つ目のモヤモヤ

ABテストもニーズ検証などで、これまでも有効活用してきました。

しかし、価値検証の学習フェーズでは、ABテストは向かない？！

うまく活用出来ていないだけ？

これまで、この3つのツールをごちゃごちゃに使っていたので、うまく学習した事を残せていません...

この3つのツールを適材適所に使うことで、

もっとスムーズに仮設検証が可能になる気がしていますし、学習した事を時間をかけずに資産化できるようにしたいと考えています。

と、整理した結果、

価値の検証の大きな流れはFRTで見える化。

FRTの中の分からない事、曖昧な事は、LAMDAで学習し、共有する。

LAMDAを使って明確になった事、

もしくは、既に明確になっている事の

さらに細かい手段の検証にABテストで共有する。

という感じかなぁ...