目的
ITでより国全体の生産性が向上していき、無駄な【作業】(仕事ではなく作業)
をしなくていい。
労働時間や個人の我慢の量といったパラメタの上に成果が成り立つという
社会構造そのものを崩していきたいと考えている。
背景
自分の職場の人々の働き方が兎に角作業量が多いわりには、
さほどクライアントの現在の悩みが解消されたようには見えないこと。
また業界全体で技術的負債といったITそのものがボトルネックになり、
負債を生んでしまっているという、とても嘆かわしい現状に頭を悩ませている。
有志の人たちは業後や土日の時間を使って、リファクタリングなどの
解決手段の質を上げていく活動に取り組まれているので、ここはシンプルに尊敬の念を抱いている。
ただ、一方でどんなに解決手段の質を上げたとしても、
そもそもの取り組む【問い】の設定が間違っていては意味をなさない。
私的には、リファクタリング活動というよりも、そもそものこの問いの設定
のスキルをあげることも同時にやらないとまずいと思っている。
その上でリファクタリングのスキルといった解決手段の質を上げる活動を行う。
でないと、どんなに自分たちが頑張ってリファクタリングの学習をしたとしても、
結果的にその努力が成果を生まず→
「リファクタリングなんてやっても意味がない」という曲解を生んでしまいかねないと
予測しています。
せっかく業後の時間などを使って、負債と向き合おうとする勇者たちがいるのだから、
その者たちの努力が無駄になってほしくないという、
お節介心が今回の記事を書くに至った背景です。
用語の前提
作業っていうのは、問いに対して思考停止して自分が知っている手段で
とりあえず納期あるから前に進めなきゃと手を動かしている状態。
ようは、脳動かしてるのではなく、手を動かしている状態。
対して、仕事はそもそもの問いの設定に時間使って、仮説をたてて
「検証の意味でまずは小さいスコープで手を動かそうか。小さく実装しようか」
と頭を動かし、決して開発のために手を動かしてるのではなく、
これは検証のための擬似的開発なんだというマインドの元で手を動かす状態。
つまり、抽象的な言葉にはなるが価値のために
「何を解決したらいいんだろう？ 何をしないと決断すればいいのだろう」
と仮説検証を通して、問いの設定をしていく。
・そもそも向き合う問いの設定に使う仮説と、
・その問いに対して最も適合している手段は何が適しているかな？
という２つの種類の仮説があるとここではすることにする。
解決手段の適合性
これは勝手に自分の中での用語として定義してしまっているが、
私の中では、問いに対する解決手段の機能適合性として以下の図のように考えている。
黒枠が向き合う問いのスコープを表し、赤枠が解決手段のスコープを表す。
ここで、赤枠の面積を解決するのにかかるコストと見立てていただきたい。
黒枠と解決手段がどのくらいの面積、重なり合っているか？に着目いただきたい。
最悪な例 - 多額を投じたのに一切解決できていない
これは赤枠の大きいわりには、全然問いと重なっていない状況。
つまり、コストかけた割には全く解決できていない事例。
たぶんウォーターフォール案件で全然うまく行っていないっていうのは、
このような状況が多数なんだと思います。検証が前の方の工程にないですからね。
このような状況下で、どんなにリファクタリングをしてもすべて無駄に終わります。
小さい失敗 -最小限の損失
アジャイルや反復型プロセスでは、こんな感じで
「この解決手段なら問いを解決できそうだけども小さくまずは検証しよ」
というように実験してみて、
図のように重なりがない事が分かったら、速やかにその方法はやめようと判断できる。
一部解決できてるけど、無駄も多い
上図の斜線部分が、解決できている領域とする。
たしかに一部解決できているが、赤枠の斜線でない部分に関しては
何も価値を生んでいないことになる。つまりはムダ金を投じてしまった部分。
成果の面積(斜線部分)の割には、無駄な部分がとても多いので、
これは果たして成果を上げたと言っていいのか？微妙なとこである。
そして、これはよくあるあるな現象なのではなかろうか。
もしもリファクタリング活動したい場合には、ここの重複部分のみだけに専念すべきですが、
その前に赤枠の無駄な白い領域の削除などを行った方が賢明でしょう。
理想的に近い状態
無駄も少なく、かつ問いとの重複が多い状態。
ただし、これもまだ無駄が多いと感じる。だってすべてを解決する必要なんてない。
それは【パレートの法則】をご存じの方なら、察しが付くと思う。
そう！問いのすべての領域を埋め尽くそうとしなくていいのだ。
重要な部分は、所詮20%程度しかない！！
超理想的状態
ひとつまえの例では、問いに対して、
ぴったり解決手段が重なっている状態を示したが、
そもそも問いのすべての面積を満たす必要はあったのだろうか？
パレートの法則をここに適用してみると、
「問いの範囲の中で重要なものは20%の範囲だけ」
つまり、
下図のような問いの範囲の中でも特に重要な重心(斜線のコアな部分)を支えれば、
問いの板はバランスを保てるよ、ていう狭い範囲を探し、そこを支える！！
※ 注意
ただし、この問いのコアな部分というのは、固定的ではない。
市場の流れの変化といった外的要因によって、その位置をどんどん変えていく。
ただ、短い期間であれば 【静止している】と近似的に扱える、というだけである。
それを踏まえて、短期間で迅速に問いのコアを発見し、その動きを監視する組織体制とかが重要に思う。
わたしの主張
わたしの主張として、
解決手段の質を上げる努力をしつつも、問いの設定スキルを上げなくてはいけない
ということを掲げます。
解決手段の質を上げるためには、モデリングやリファクタリングなど
努力すればいくらでもスキルを挙げられるものが多々あります。
これらは技術書のワークショップなどで向上させている人が多い印象です。
では、問いの設定のスキルは？
これは技術書でスキル向上させることは、ハッキリ言って無理です。
先程の超理想形の図をもう一度出します。
斜線部分が本当に向き合うべき問いでしたね。(俗にいうイシューてやつ)
そこ以外の問いのスコープの白い部分を支えても、
さほど費用対効果は得られないから、ムダな生産ということに繋がり得ます。
よって、解決手段で支えるのは【斜線の部分だけにする！！】というマインドを持つ。
そのために小さくそのコアとなる部分を探索する活動が大事ですね。
そのために問いのスコープを構造化によって、
SLAP原則を満たし、MECEになるよう小さいマス目に分解していき、
「これを解決したら良さそう！」という仮説の元に、問いのコア(上図の車線部分)を探していく。
ここで必要なスキルが、以下になります。
・「ここが問いの中でも重要な部分だ！」という仮説構築能力
・ラテラルシンキングやクリティカルシンキング
・エフォートレス思考(詳細は調べていただけたらと)
この辺のスキルは、技術書ではなく、ビジネス書などを用いて底上げすることが望ましいでしょう。
仮説構築能力の向上には、以下の書籍をお勧めします。
あとは、その事業の目的や背景がそっくりな場合には、
この上記の探索によって得られた知見は、再利用可能です。
だから「あ！問題のコアはここだと思ったけど違ったか💦」ていう小さい失敗とかにも
めちゃくちゃ価値があるんです。
なのに、目先の成果しか追い求めていない人(上層がそうだと目も当てられない)には、
このアンチパターンの価値がわからないから、
仮説検証の活動をせずに、最初からごり押しで
「ここが問題に違いない！！」「俺たちが進んでいる方向が間違ってるはずはない」
「前提に戻ることは許されない！！ 多額の予算がかかってるから責任があるんだ！
誓約書を守らないといけないんだ！！ 失敗は許されないんだ！！ うお～～～～」
みたいにひたすら失敗を認めず、前に突き進むのみっていう。
こんなことにならずに、本来のリファクタリング活動の目的を再度見据えたうえで
メリハリをつけて行っていかないと、自分たちの努力が成果にならない。
リファクタリング活動などが、質の改善につながるんだと、
数字的な成果で証明できるようにするためにも、
自分たちの努力が、最小限の労力で成果を最大化するためにも、
本質的な問いの設定スキルといったビジネススキルをまずは上げて、
その上でリファクタリングスキルといった技術的スキルを上げていけば、
少ない投資コストで、最大限の成果が生まれやすくなり、さらにさらに仕事の質が上がっていくと思います。