なぜ削れないのか

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

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

しかも、早く決める事が

大きく影響します。

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

なのですが、

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

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

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

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

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

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

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

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

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

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

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

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

今からでも遅くない？！

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

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

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

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

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

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

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

削る理由がない？

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

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

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

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

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

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

ん？！

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

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

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

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

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

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

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

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

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

と。

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テストで共有する。

という感じかなぁ...

早く創る為の5箇条？

早く創る（ソフト）為の5箇条を考えてみました。

本当は八策にしたいのだけど...  5の方がシンプルですね。

価値定義が出来ている前提で、どうすれば早く創れるのか。

今回のプロジェクトではチームとして連携できて、

各ピースがうまく噛み合って早く創れたと思いますので、

早く創れたポイントをまとめてみました。

その①：分ける

価値と目的（機能）と手段を分けて考える事がまず第一歩かと。

価値を提供する為に、どんな機能（目的）が必要か。

その目的達成の為にどんな手段が考えられるか。

それぞれシンプルに必要な事を小さく列挙して、

カテゴリ分けするのが良いかと思います。

その②：流れにする

分けたものを繋げます。

可能であれば、提供する順番、検証する順番に繋げるのが良いです。

私はここでFRTを活用しました。

提供する機能、期待する状態（行動）、アサンプション（前提など）

の3つで流れを作りました。

これで方向性が定義されます。

その③：目的が達成される手段を組み込む

流れに手段を追加していきます。

手段で目的が達成される事を確認しながら追加します。

最短手段にこだわり、目的達成を忘れない事が重要です。

見た目が目的達成において重要な要素であるならば、見た目も含めて検討します。

また、目的に対して1つの手段であれば、その②の流れに記載すれば良いのですが、

目的の為に必要な手段が複数ある場合もあります。

その場合は、目的に必要な手段をグループ化して、そのグループで流れを作ります。

操作手順や時間軸で流れを組み立てます。

目的が達成される事を何度も確認する事が重要かと思います。

その④：「なぜ？」ではなく、「こうすると？」

手段を検討する上で、最も早い手段を検討する上で

なぜ時間がかかるのかを聞くのはタブーかと思います。

「なぜ？」と聞くより、次々提案する方が結果的に早い気がしています。

もちろん、時間がかかると思い込んでいる可能性もあるのですが

「こうすると早くなる？」といった議論の方が推進力が上がる気がします。

そして、議論する事で思い込みが解消される事も多いと感じています。

その⑤：とことんバトルする

早さを実現する為には、建設的なバトルをする事が欠かせないと思います。

「なぜ？」のバトルではなく、

「これは？」「こうしたら？」「このほうが」というバトルです。

チームでお互いに目的を達成する為の手段の案をぶつけ合うバトルです。

ときに、「そもそも」といった確認もよくあった気がしますね。

具体的な作り方、実装方法を議論するというより、目的達成のためのアプローチを議論する方がチームとして盛り上がる気がしています。

具体的な実装方法は実装する人（アサインされた人）に任せるというスタンスも重要かと思います。

バトルする上で①、②を共有、合意している事がとても重要になると思っています。

合意している事で、余計な発散を防ぐ事ができます。（と思っています）

もう少し整理する必要はありますが、この5つは重要かと思っています。

もう1点、「絵を描いて議論する」を入れようかと迷いましたが...

やっぱり、この5つかなぁ...

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

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

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

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

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

とは、

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

と改めて。

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

いや、違いますね。

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

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

という感じでしょうか。

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

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

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

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

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

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

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

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

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

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

仮説定義VS早く試す

リーン、リーンスタートアップやアジャイルでは

顧客に価値を早く届ける為に

短いサイクルで継続的に顧客に動くものをリリースします。

しかし、動くモノ、リリースしたモノ

に価値が無いのでは意味がありません。

リリースするモノの価値について考えてみました。

リーンスタートアップでは価値があるかを検証する

という事になり、検証して学ぶことが目的なので、

検証する事、そのものに価値がる。

だから、検証する為にリリースする。

一方アジャイルは、ユーザーストーリーに価値がある事が前提かな？

と思ったのですが、

こちらもリーンスタートアップと同じ考え方が出来ますね。

ユーザーストーリーが仮説であれば、

こちらも検証する事を目的とすると、仮説であっても価値がある事となり、

価値がある事が前提でなく、検証する事が目的であれば、

リリースする動くものに価値がある事になる。

結局、価値定義が重要という事ですね。

価値定義の合意形成の中では、

考えても分からないから、とりあえず作って、試しに使ってもらう。

という葛藤があります。（ありました。）

価値定義を曖昧にしたまま、とりあえず動くものを作るとどうなるか。

定義が曖昧なので、シンプルで明確なユーザーストーリーにならない。

恐らく、仕様化、具体化のところが遅くなるのでしょう。

単純な比較は出来ないので、正確には分かりませんが。

今回、価値定義が重要だと実感する機会があったので、

再度、考えてみました。

オンラインとオフライン

オンラインミーティングが増えています。

初対面の方とのオンラインミーティングも慣れてきました。

しかし、久しぶりにオフラインで顔を合わせると、ほっとしますね。

なんでしょうね。この感覚は…

オンラインミーティングは慣れてきたとはいえ、

オンラインミーティングのやり方というか、進め方は

まだまだ試行錯誤な感じです。

どうしてもオンラインでもオフラインと同じようにやろうとしてしまう。

オフラインの時のホワイトボードと同じように

オンラインのホワイトボードを使ってみますが、同じようにはいきません。

考えてみれば、明らかに違うものなので、

そもそも同じように使う事に無理がある気もします。

頭を切り替える必要があるのだとは思うのですが…

オンラインの良いところ、悪いところをピックアップして

じっくり考えた方がイイのかな？！

いや、そもそも何が問題なのか。

あれ？！

つまり、

何を変えるのか

何に変えるのか、どのように変えるのか

って事ですね！

いつものとおり、TOCを活用しろって事ですね。

設計コンセプトはシンプルに！

 SWEST22に参加しました。

昨年は参加出来なかったので、今年は楽しみにしていました。

ですが、今年はオンライン開催！

どうなるのか不安いっぱいでしたが、

スタッフのみなさんの頑張りで

SWESTらしいオンラインワークショップとなった気がします。

スタッフのみんさんに感謝です！

今回の目的は、いつも通りの議論する為はもちろんですが、もう1つあり、

社内検証中のサービス（今までに無い気づきがあるGrowth Mirror）を社外でも検証する為の参加でもありました。（※リンクをクリックすると無料でお試し出来るWebサービスです。IEでは動作しません。）

毎度、SWESTでは勉強となる事が多いのですが、

今回も勉強になりました。

最も印象に残ったのは、あるセッションでの安全性に関する議論です。

設計思想、コンセプトは大事だと常々意識し、実践してきましたが、

何を優先すべきかを1つにフォーカスする事がとても重要だと改めて感じました。

今回は、プログラムの実行速度を最優先としたうえで、

どのように安全性を担保するかという内容でしたが、

実行速度を優先するという設計思想があった上での安全性の確保

相反する事でもありますが、バランスを取る事が重要で、

そのバランスを保つためにも、シンプルなコンセプトが重要となると感じました。

実行速度を犠牲にせずに実現できる最大限の安全性の担保。

担保の仕方はいろいろです。

臨機応変に対応し、進化させる必要があると思います。

進化させる為に、議論を深める為にも思想、コンセプトはシンプルである必要があるのだと思います。

なぜ、Howに夢中になるのか？！

LAMDAやTEFCAS、FRTを使って仮設検証を進めていますが、
やっぱり作り込みに夢中になってしまいます…

おっと、はっきり認識しないとダメですね！
どんなHowがイイかを常に考えてしまい、
仮設検証の意識は、どこえやら…

How思考に陥るなんてダメダメですね。

FRTも作ってるのに！

なぜでしょうね？

作る事に夢中になると、
作るモノを
　意識してしまう。
　想像してしまう。
　もっと良くしたいと思ってしまう。
　etc...

作る事に夢中になってはいけない？？？

仮設検証にフォーカスすべき？！
う~ン

そう意識していたつもりなのですが…

いつのまにかHowの呪縛に…
How思考、恐ろしや…

じゃくて、なんとか対策を考えなければなりませぬ…

改めて抵抗の６階層を考える

先日、合意形成の議論となり、

改めて抵抗の6階層を考えてみた。

1. 問題の存在に合意しない
2. ソリューションの方向性に合意しない
3. ソリューションが問題を解決できるとは思わない
4. ソリューションを実行するとマイナスの影響が生じる
5. ソリューションの実行を妨げる障害がある
6. その結果起こる未知のことへの恐怖

議論は、1．を合意した筈なのに…
という相談というか、雑談から始まったのですが、
6階層を意識して合意形成を試みたという事ではないので、
合意を得られないというより、
2.3．についてのツッコミがあったという印象です。

こういう事はよくある気がします。
いわゆる、よくあるケースをよくよく考えてみると

2.3．での抵抗は、やっぱり1に合意していない気がしてきます。

相手は、合意したフリをしているだけというか…
方向性として反論ないだけというか…
世界平和には合意という感じというか…

合意の度合いというか、熱量が全くない合意な気がします。

問題とその背景など、
1の問題をどう表現するか、どう説明するかで、
合意の熱量が変わる気がします。

だとすると、何が必要か、どんな説明をすれば良いのか…

関係者が身近に感じられる表現が必要そう

伝える人毎に表現やフォーカスを変える事も必要そう

取り組むべき問題と思う熱量を上げる事も必要そう

などと、考えていると、

「6段階目で抵抗されるのは、結局1が合意出来ていない」

と、聞いた事を思い出しました。

やはり、1番は重要ですね！！

ですが、合意の定義が必要な気がしてきました。

合意＝問題意識の熱量が同じ

という事になるのでしょうか…

LAMDA＋TEFCAS

学習サイクルで得た事を記録する為に
チームで参照する為に、

LAMDAにTEFCASのEFCAを足してみた。

L：Look：観察する（いまどうなっている？）
A：Ask：問いかける（分からない事は何？）
M：Model：モデル化する（視覚化して解決策を探る）
D：Discuss：話し合う
A：Action：行動する

これに、アクションの結果をEFCAとして記載する

E：Event：行動した結果、起きた事、事実のみを書き出す
F：Feedback：Eventから何が分かったか
C：Check：分かった事をチェック（今回は書き出す事でセルフチェック）
A：Adjust：分かった事から修正する

ちょっと前から、この形で学習サイクルを記録しています。
自分の頭の整理としては、イイ感じです。
チームで共有するのも、いまのところ悪くない感じ。

記録として良いかは、まだ分かりません…

学びの早さも現状把握から？

リーンやリーンスタートアップでは、
ムダを作り込まない為にMVP/S で顧客から学ぶ
安価な実験で検証する

要するに仮設検証を早く回す　という事だと思うのですが、
最近、この早く回すスピード感がしっくりこない。

なぜか？！　を考えてみる。

そもそもなぜ、しっくりこないのか？

これまでのスピード感と比べると遅いと感じている

からです。

これまでは特定顧客の課題解決で実践していたので
フィードバックを得易い環境であった。

先日受講したセミナー
「不確実な時代に勝ち残るものづくりのデザイン力を探る」
の内容が頭に浮かびます。

『TOCが機能した「環境」と「前提条件」を明らかにする』

環境も前提条件も大きく異なります。

環境も前提条件も大きく異なるので、やり方、アプローチは変えています。
アジャストするように都度考えて都度変えていますが、
どうしても同じようなスピード感を求めてしまう。

という感じでしょうか。
同じスピード感を求める事は悪い事では無い気がします。

では、どうするか？！

やり方はともかく、
大事なのは、

現状がどうなっているか
どこに向かっているのか

を見える化して、見誤らないようにする事でしょうか。
すると、やり方はおのずと見えてくる？？？

あれ？　これって、TOCの3つの質問「何を」「何に」「どのように」
と同じですね！？

MVPとFRT

実用最小限の製品、サービス（MVP/MVS）を構築して、
検証していこう！

という事で、
少ない時間で構築する為に
学習サイクルを早くする為に
検証する仮説や、何を学ぶのかを明確にする為に

MVPキャンバスなども書いてみたのですが、
なんとなくしっくりきません。

なぜか？！

定義している価値提供までに、
いくつかの中間状態を経る必要があるからでした。

つまり、条件があるという事ですよね。
いくつかの条件が満たされた上で提供すると価値がある
という事になります。

この気づきを分かり易く表現出来ずに悶々としていました。

段階的に検証していく必要があるのであれば、
TOCのFRT（未来ツリー）だよなぁ。
と、試しに書いてみたところ、
なかなかイイ感じです。

想定している仮説をアサンプションとして書き入れると
とても便利です。

アサンプションが入ると少し複雑な図にはなりますが、
そのまま、共有したところ、ばっちりでした。

FRTは強力なツールだと改めて実感しました。


プロトタイプやモックは顧客との認識合わせが目的の事が多いので、
あえて目的を明確にする事は少ないかもしれませんが、
目的を明確にしないと作り過ぎる傾向はある気がします。

プロトタイプ作成前にFRTを作成すると、作り過ぎも防げそうです。

FRTの活用範囲が広がりそうです！

VAKモデル

最近、知りました
VAKモデル

Visual（視覚）、Auditory（聴覚）、Kinesthetic（身体感覚）
の頭文字をとったもの。

人は情報を5感で処理していて、5感を大きく3つに分類したものが
上記の視覚、聴覚、身体感覚
という事です。

目標設定について、ネットを彷徨っている時に出会った「NLP」
目標設定方法の1つとしても紹介されていました

NLPの手順の中で、
目標を達成した時の状況、状態をVAKモデルで表現する事で
より目標を具体化していく
という事でした。

目標やゴールの数値化のアプローチとして
ヒントになるような考え方や方法が無いものかと、彷徨っていたので、
探していたいものにかなり近い印象です。

これまでは、因果関係を明確にするアプローチで、因果関係を書き出す事で
具体化、数値化を進めてきましたが、
因果関係を書き出す事、
そのものが難しいというか、慣れが必要というか…
簡単では無い事が分かっていたのですが、
そんな簡単な方法なんて無いだろうと諦めつつ、彷徨っていました。
諦めずにもっと早くに彷徨うべきでした…

このままでは数値化までは、まだ少し遠い気がするので、
補助策を考えつつ、機会を見て試してみようと思っています。

　

アナロジー？

久しぶりに小説を読みました。

ついつい、仕事関係の本に埋もれてしまうので、
意識して、仕事とは関係無い小説や絵本を読むようにしています。

というより、ちょっとした行き詰まり感を感じると、
仕事とは関係ない書籍に逃げる感じでしょうか。

ずっと気になっていて、読みたかった『蜜蜂と遠雷』
2016年の直木賞受賞作です。もう4年も経ってしまったのですね…

冒頭から引き込まれ、一気に読んでしまいました。

読みながら、ところどころで、
音楽とプログラミングの共通点、
音楽と仕事との共通点に
思考が飛びまくります…

この感覚は表現するのが難しいですが、
「同じだ！」、「これだ！」という思いと同時に
他の書籍のあるページのイメージが浮き出てきます。

小説を読んでいる途中で、他に思考がいくような表現となってしまいますが、
そうではなく、小説の世界に入ったまま、
別の自分が、隣にもう一人突然現れる感じです。
だから、小説への没入感は維持したままなので、中断する感じではありません。

中断もしないし、もう一人の自分の中では、
理解が深まる感じがして、とても気持ち良い感覚です。

いつもは一人の自分が分身して、それぞれが違う事をするような得した感じがします。

これまでは、これぞアナロジー！って勝手に思っていましたが、
こういうのもアナロジーっていうのかな？

今回とても印象に残った分身発生表現は

『音楽は常に「現在」でなければならない。博物館に収められているものではなく、「現在」を共に「生きる」ものでなければ意味がないのだ』（『蜜蜂と遠雷』より）

これと、

お世話になっている村上悟さんの著書『ものづくりの教科書』
の『起点は「今」に置く』でした。

2年ぶり？のフューチャーマッピング

先月、3年後のゴールに向けて、
フューチャーマッピングをやってみました。

久々でしたが、出来るもんですね。

しかも、思わぬ気付きもあり、
使わない手は無いなと改めて感じました。

ついでに、
同じように3年後のゴールに向けて
計画づくりをしている方にも勧めてみました。

同じようにブランクはあるのですが、
こちらも、いくつか気づきを得たようで効果ありです。

使い慣れている感じはしませんが、
それでも、効果を感じる事が出来るツールという事になるでしょうか。

こういうツールは、なかなか無い気がしますね。

どのツールも使い方次第だとは思いますが、
フィーチャーマッピングは、
お手軽で効果を感じやすいツールかもしれません。
ただ、もしかしたら、私のような人には。かもしれません。

A3はイメージ？！

作業場所のちょっとした移動があり、
断捨離とまではいきませんが、整理しながら　
ぷち引っ越ししていました。

すると、4年前に作成した「問題解決A3」が発見されました。
しかも大量です。

2015年に活動した本質思考道場の成果として
道場参加者に作成してもらったA3でした。

社内に展示したので、ほぼ展示した状態で残っていました。

懐かしいというより、その時の状況がすぐに思い出せるのが
やっぱりA3の力だなと思うのですが、

これまでのイメージとは少し違います。

何が違うのか？！

と考えてみると、
A3の内容ではなく、A3の見た目、ビジュアルなイメージが
記憶として残っているのです。

そのイメージと内容が記憶として結びついている感じです。

A3ってイメージとしても記憶されるのか！

と、新たな発見でした。
これもA3の紙一枚にまとめるからこその効果ですね。

恥ずかしながら、全てに私のコメントが入っていて、
その画像（イメージ）もなんとなく記憶しているので、
これがまた状況を思い出すのに一役買っている感じでした。

A3には、もっといろいろな力があるかもしれませんね！

Powerpoint はやっぱりダメですね…

久しぶりにA3描きました。
大好きな問題解決A3ではなく、企画A3なので、
ちょっと物足りなさを感じるのですが、それはさておき、

改めて、A3の力は絶大だと実感します。

記載する内容が選択される。
というより、
フォーカスすべき事を考え、洗礼する。
という感じでしょうか。

だから伝わるのだと思います。

たしかに、描くのは大変ですが、
時間をかける価値のある、効果の大きいツールだと思います。

フォーカスする事を考えて、
あれこれ悩みながらも、フォーカスすべき事が明確になっていくので、
頭の中もとても整理されます。
（机の上は、いっこうに整理されませんが…）

パワーポイント（スライド）だと、ここまで整理出来ないですね。

というのも、今回もパワーポイントでまとめていたのですが、
なかなか全体像が見えないというか、
伝わらないというか、噛み合わないというか…
という感じでした。

結局、自分も整理が出来ていない事も良く分かりますし、
何が足りないのかも見えてきます。
これもフォーカスした結果、フォーカスすべき点が見えたから
見えてくるのだと思います。

自分自身でフォーカスすべき点が見つけられる

という点がとても重要だと思いますし、
A3一枚にまとめる事の大きな効果だと改めて感じました。

夢を語ろう！

今年になってから、
夢を語っていないなぁと思い、少し意識し始めるたところ
偶然も重なった事もあり、夢を聞く機会が増えた気がします。

こういう時って偶然なのか、意識した事による必然なのか
と考えたりもします。

こうなると、もっと夢を語らなくては！
と更に前向きになります。

これまで叶った夢も、叶わなかった夢も
いろいろありますが、
夢って原動力の1つですよね。

心の中にそっと秘めていてるのも悪くはないですが、
もっと語らなくてはと思います。
語る事で、力になる気がするし、
語る事で、夢を聞く機会が増えて、これもまた力になる気がします。


一方で、昨年を振り返ると
昨年は、あまり夢を語っていなかった気がします。
その為か、周囲でも夢に関する事を、
あまり聞かなかった気がします。
なぜ、夢を語らなくなったのかは分かりませんが、
徐々にそうなった気はします。

それよりも、
これだけ違う事、変わった事がまた不思議です。

何が大きく作用しているのでしょうか？

とてもとても不思議ですが、
この良いサイクルが続くように夢を聞き、語り、
気づきを得て、更なる夢へと繋がればと思います。

ソフト開発と目指す状態

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

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

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

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

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

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

すると…

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

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

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

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

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

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

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

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

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

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

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

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

と、悶々としています…

セールスイネーブルメント

先日、営業のセミナーに参加してきました。

昨今の営業事情を知る為に、
顧客にどのようにアプローチしているのかを知る為に参加しました。

最近の主流はインサイドセールスなのは
なんとなく、分かっていましたが、
やはり、主流なのだと実感しました。

更には、インサイドセールスは電話やメール対応となるので、
件数や対応時間などデータ化し易いという点が
なんでも効率という名目でシステム化されていく感じがして、
とても気持ち悪い印象を受けました。

開発者と営業マンの共通点もいくつか発見し、
また、泥臭いお話も聞けたのがとても収穫でした。

開発者同様に営業マンも属人化しているようです。
その現状を底上げする為の育成方法として、
「イネーブルメント」という体系化された取り組みが紹介されていました。
一言でいえば、現状を把握して、成績の良い人のマネをする
という事でした。

考えてみれば、共通点があるのは当たり前な感じはしますが、
改めて、昨今の問題点を認識出来ました。

営業では成績の良い人は、
開発では品質の良い人？　作るのが早い人？
でしょうか。

このあたりも開発だと個人の能力の見える化が
ほぼ不可能な部分ですね。
だから、余計にややこしいのですが…

いずれにしても、どちらもいわゆる出来る人は
考えて行動している
だけですよね…

マネをすべきは、ここだと思うのですが…

ソフト開発はアート！？

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

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

との意見が出ました。

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

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

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

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

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

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

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

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

違和感を大事にする

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

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

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

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

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

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

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

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