検証のつもりで見ていた案件で、本番想定の構成図が上がってきた。AWSのどのサービスを使うかまで決まっていて、出来としては悪くない。真面目に考えた跡がある。
ただ、その段階ではまだ要らないものだった。事業部の業務を効率化できるかどうかを確かめるPoCで、効果が出なければそこで止める前提の作業である。捨てるかもしれないものに、本番と同じ設計を積む意味はない。
結局その構成図は使わずに終わった。しかも、検証に使えるレベルのものは、その時点ですでにできていた。
目次
- 検証の段階で、本番の構成図が出てきた
- 見たかったのは、DFDとどこから確かめるかだった
- 作ったものは、事実上捨てた
- 失ったのは設計ではなく、答えが出るまでの時間だった
- 手を抜いた話ではない
- 私にはあまりない感覚だった
- 自主性に任せる以上、これは起きる
1. 検証の段階で、本番の構成図が出てきた
出てきたものの出来が悪かったわけではない。むしろ逆で、よく考えられていた。サービスの選定にはそれぞれ理由があったし、構成としても筋が通っている。
問題は、それを今作る必要があったのかというところだった。
PoCは、やってみて駄目なら捨てる前提の作業である。捨てるかもしれないものに本番と同じ品質の設計を積んでも、効果が確認できなければ全部無駄になる。それに、検証の結果次第で必要な構成そのものが変わることもある。
この段階でそこまで本番レベルのものは要らない、ということはその場で伝えた。
2. 見たかったのは、DFDとどこから確かめるかだった
こちらが期待していたのは、もっと粗いものだった。
データがどこから来て、どこを通って、どこへ出ていくのか。DFDくらいの粒度で全体の流れが追えていれば、この段階では足りる。図として整っている必要もない。
その上で知りたかったのは、どこから確かめるかだった。流れの中で一番怪しいところ、うまくいかないとすればここで詰まるだろうというところ。そこを先に潰せば、この案件を続ける意味があるのかどうかが早く分かる。
検証の設計というのは、何を作るかではなく、何から確かめるかを決めることだと思っている。どのサービスを使うかは、確かめた後の話だ。
3. 作ったものは、事実上捨てた
結果として、上がってきた構成図は使わなかった。事実上、捨てることになった。
本番想定で組んだ内容は、検証で必要になる範囲を大きく超えている。しかも検証の結果によっては前提そのものが変わるので、取っておいて後から使えるかというと、そういう性質のものでもなかった。
そして、ここが一番もったいなかったのだが、PoCとして動かせるレベルのものは、実はすでにできていた。作り込んだ構成図とは別に、確かめるだけなら十分なものが手元にあったのである。案件は、そちらを進める形に戻した。
4. 失ったのは設計ではなく、答えが出るまでの時間だった
すでにできていたものを、そのまま出していればどうなっていたか。
おそらく今頃は、検証結果が出ていた。効果があるのかないのか、あるとしてどの程度なのか。次に何を決めればいいのかも見えていたはずだ。
捨てた構成図にかかった時間そのものより、そちらの方が痛い。検証は、早く回して早く答えを出すことに価値がある。答えが出ないうちは、この案件を続けるかどうかの判断が止まったままになる。止まっている間、事業部側は今のやり方を続けるしかない。
作り込んでいた本人からすれば、手は動いていたし、進んでいるつもりだったと思う。実際、成果物は出ている。ただ、案件として前に進んだかというと進んでいない。進める材料が手元にあったのに出さなかった分だけ、むしろ遅れた。
5. 手を抜いた話ではない
念のため書いておくと、これはサボった話ではない。
むしろ逆で、丁寧にやろうとした結果である。中途半端なものは出したくない、出すならちゃんとしたものを、という方向に振れた末に、求められている水準を追い越した。
新しい技術を試したい気持ちが先に立って要件から離れていくその技術力、ただの自己満足じゃない？に書いたような形とは、動機が違う。あちらは自分のやりたいことが先に来る話だった。今回は求められていることをやろうとして、その水準を読み違えている。外から見える結果は似ていても、直し方は同じにならないと思う。
理由を推測するなら、完璧主義なのだろうと思う。加えて、こうあるべきだという思い込みが少し強いところもある。どちらも見ていての推測で、本人に確かめたわけではない。ただ、指摘したときに「やっちゃった」という反応が返ってきたので、言われれば分かる話ではあったのだと思う。
6. 私にはあまりない感覚だった
こういうとき、自分も昔は同じだったと書ければ収まりがいいのだが、正直あまり心当たりがない。
必要以上に作り込んで時間を溶かした経験がまったくないとは言わない。ただ、これは検証だから雑でいい、という切り替えは、比較的早いうちから自然にできていた気がする。
だから、どう言えば伝わるのかが分からない。自分がつまずいていないところは、つまずいている人に渡せる言葉を持っていない。今回も、この段階ではそこまで要らない、と伝えるだけで終わった。それ自体は間違っていないと思うが、次の案件で同じことが起きないかというと、あまり自信がない。
線の読み方がずれる話は「これくらいでいい」を下限ではなく上限だと思っているにも書いた。あちらは、こちらが下限のつもりで引いた線が上限として読まれる話である。今回は、誰も線を引いていないところで勝手に上まで行っている。
7. 自主性に任せる以上、これは起きる
防ぐだけなら簡単で、先に線を引けばいい。
この段階はDFDまで、構成図は不要、と最初に決めて渡す。そうすれば作り込みは起きない。今回に関しては、そうしておくべきだったという気持ちもある。
ただ、それを常にやり始めると、毎回こちらが範囲を決めることになる。どこまでやるかを自分で判断する余地がなくなって、言われた分だけを出す仕事になっていく。私は基本的に自主性に任せる方針でやっていて、ここまでという線をルールにしていない。任せている以上、読み違いは起きる。
今回のように捨てるだけで済むなら、まだ取り返しはつく。時間は戻らないが、案件そのものは進められる。それを織り込んで任せ続けるのか、範囲を先に切るのか、正直まだ決めきれていない。
今のところやっているのは、フェーズを言葉にして伝える回数を増やすくらいのことだ。今は何を確かめる段階で、何が分かれば次に行けるのか。それを最初に共有しておけば、少なくとも本番想定まで飛ぶ前に一度止まる可能性は上がると思っている。
案件の終わりに何を出すのかを先に見ておく話は最後にやり直しになる人は、最初に納品物の形を見ていないに書いた。あちらは遠くを見ていなかったせいで足元がズレる話で、今回は逆に、足元を確かめないまま遠くまで行った話である。向きは反対だが、自分が今どこにいるのかを一度確認するかどうかで分かれているところは変わらない。