CCPMはチェンジ・ザ・ルールの後に

2/5から久しぶりに展示会で東京に4日間も滞在しました。
長野に帰ってまず感じるのは空気の美味さですね。

空気の事はともかく、展示会では、
ザ・ゴール、ザ・ゴール2、チェンジ・ザ・ルール
を、こっそり並べていました。

少しでも反応してくる方がいると嬉しくなりますね。

並べるといえば、ザ・ゴールの並び順というか、
読む順番を聞かれる事がたまにあります。

私は、今回の並び順通りをお勧めしています。
1）ザ・ゴール
2）ザ・ゴール2
3）チェンジ・ザ・ルール
4）クリティカルチェーン

1，2は異論は無いと思います。
問題は3、4番目でしょうか。

なんとなく、3，4番目は逆という意見が多いような気がしますが、
私は、クリティカルチェーンは4番目ですね。

理由は、
「遅れても良い」などのルールの変更を徹底させないと
CCPMが機能しないと感じているからです。

もう一つの理由が
ルールの変更はとても難しいですし、
ルールを変えないと変わらないのは必然だと思うので。

この意味からも「チェンジ・ザ・ルール」
までは読むことを進めています。

通称4箱はグルグル回る

前回、通称「4箱」を紹介しました。

④が難しいのですが、
③も難しいですね。

特に新しい事にチャレンジするとなると、
③を何にするか、想像すら出来ない場合もありますね。

そのような場合は、
1週間後とか2週間後といった感じで、
期間を短く設定して、①と②を考えます。

①と②が具体化してくると、③が考え易くなります。

といった感じで、4箱をグルグル回って考え直していく事で、
より何をいつまでに達成するか
といった事が具体化されていきます。

具体化されれば、あとは「行動する」のみですね。

目標の前に、通称4箱

今年こそは！
と、目標を立てて気持ちを新たにする1月

ちょっと目標を見直してみませんか？！

目標を以下の4箱に当てはめてみると
より確実に目標達成出来るかもしれません！！
#通称、「4箱」です！

タイトルは「仮設を立てよう！！」
となっていますが、これは目標を検討する際に、
このワークシートに記入してチェックする為に活用していた為です。

チェックする為のシートですから、今回のような目標の検証にも活用出来ます。

コツは、まずは、あまり考えずに書き入れてみて
見直す事です。

見直ししながら、１つ１つ変更していきます。

恐らく、最も難しいのが④だと思います。
④には当たり前のような、分かり切った事でも記載する事と、
1つでは無く、思った事を次々に書き入れていくのがポイントです。

是非、活用してみて下さい！

どこに時間をかけるか

最近、ソフトウェアの機能追加をしていて
追加する際の構造をどのようにするかで悩みました。

他の事をしながらではありますが、1週間くらい考えていたでしょうか。

既存のイベント変換機能を利用したいのですが、
現状のイベント変換機能は、
使う人が決まっているので、その人専用に作られています。

イベント返還の内容は全く同じなのですが、
変換後の処理が異なります。

偶然にも処理は変換と変換後の2つに分かれてはいたのですが、
変換後のデータを取得する手段がありません。
変換後の処理に変換後のデータを渡す手段が無いのです。

そんな事は想定外の事なので、
もちろん既存の構造が悪いわけではありません。

だからこそ、悩みます。考えます。

変換後のデータを取得するインターフェースを追加するか
現状の処理に条件分岐を追加して、変更してしまうか。
はたまた、まったく別の方法を考えるか。
などなど。

改めて、ソフトウェアの追加、変更は難しいと感じた次第です。

しかし、この時間がとても大事だと思っています。
考えて、考えて、考えうる手段を全てを比較して決断する。

この繰り返しが大事なのだと。

ここに時間をかける事が
結果的に全体最適になるのだと。
つまり、不具合対応なども含めた開発期間が短縮される。

しかし、この時間による効果の測定はとても困難なのですよね…

LAMDAの活躍

Lean,TOCの活用を進めてきた中で、
開発現場では、LAMDAの活用が馴染みやすいようです。

LAMDAとは、Leanで活用する学習サイクルのツールです。

L：Look（いまどうなっているか）
A：Ask（分からない事は何か）
M：Model（解決案）
D：Discuss（解決案を議論する）
A：Action（議論した結果、実施するアクション）

LAMDAが知らなくても、
質問に答えれば記載出来るように
各チーム毎に質問を工夫した形でフォーマットを作成して活用しています。

その中で、2つばかりの例を、
久しぶりにSlideShareに公開しました。

調査業務や試作段階、など
不確定要素が多い状況やフェーズでの適用や
育成での活用が適しているようです。

テスト熱中症

限られた環境でフィードバックを得る事が難しい為、
今年からABテストを試行しています。

なかなかハマります。

ハマるのは、結果が分かり易いので
際限が無いというか、テストしたい事が積み重なっていく感じです。

ABテストで分かった事を活かす事よりも
次にテストしたい事に思考が奪われてしまいます。

私だけでしょうか…

これは、Unit Testのテスト熱中症と同じですよね。
こんな事になるとは全く想像していませんでした。

ただ、ABテストとしてはユーザー母数がある程度は必要なようですので、
このあたりを注意して結果を捉える必要はありますね。

このまま熱中して研究モードとならないように
ABテストについてももっと勉強しつつ
視野を広くして、成果に繋げなくては！

単純なものはハマり易いって事でしょうかね…

思込み設計からセットベース設計へ

最近、デザインパターンの議論がありました。

Aさんは、△というケースでは、Zパターンの設計が良い
Bさんは、△というケースでは、Zではなく、Yのような設計にすべき
といった議論でした。

こういった議論はとても大事ですね。

重要なのは、「Xというケースでは、Zパターンの設計」
の根拠かと。

設計はそのときの環境や状況にも左右されるので、
何を優先すべきかはケースバイケースとなります。

実現する機能面だけを見て、これがベスト！
というのも、もちろん大事ですが、
これは、ある意味で諸刃の剣となります。

それがいつ、いかなる時でも必ず良い！
と思い込んでしまう可能性も高い為です。
TOCでいうアサンプションですね。

私は思い込みが激しいという事もありますが、
自ら幅を狭くする事になってしまうので、
可能な限り複数の回答を持つように心掛けています…
#実際に出来ているかは別ですが…

△というケースでは、
XかYかZパターンの設計が良いといった感じで、
2つ以上の選択肢をもつ事で
状況や環境に応じて選ぶ事が可能となり、幅広がります。

複数の解決案を持つ事、これはいわゆるセットベース開発ですね。
決めつけるのではなく、複数の解決案を比較する事で、ベストの解決策を決める

自身の幅を広げる意味でも、
セットベース開発（この場合はセットベース設計？）は効果的ですね。

セットベース設計で幅を広げましょう！！