決める前に、聞ける人がいない

「この進め方で合っているか、一度見てもらいたい」

作ったことがある人に確かめてほしい。 けど、社内にいない。知り合いにも。

例えば、紙と表計算ソフトでやっている業務をシステム化したい。ただ、本当に作る必要があるのかが分からない。既にあるサービスで済むのかもしれないし、一部だけ作れば足りるのかもしれない。開発会社に聞くと、作る案が出てくる。

他には、

詳しい人は社内にいる。でも、具体的な判断を相談できる人がいない。

三年前に作ったものを変えたい。けど、当時の担当者がいなくなっている。

新しい機能を足したい。開発会社に相談すると「何を作りますか」と聞かれる。社内で考えて、要件をまとめて、見積もりをもらって、打ち合わせをして、発注する。数ヶ月後にまた変えたくなって、「なぜこの仕様にしたんでしたっけ」から始まる。

どれも、作れる人が見つからない、という話ではない。作る人は、探せば見つかる。 見つからないのは、作る前や変える前に相談できる相手。

決められない、より手前のこともある。何ができるのかが分からないと、やりたいことを言葉にするところで止まる。

誰に聞くか、から始まる

候補がまったくいないわけでもない。 前に発注した会社。知り合いのエンジニア。提案に来ている会社の担当者。

ただ、聞かれる側にも立場がある。

作る側の人に聞けば、作る前提で答えが返る。 提案に来ている人に聞けば、提案の一部として。 知り合いに聞けば、分かる範囲で答えが返る。

不誠実ではなくて、それぞれの立場では正しい。

どこに発注するかも、まだ決まっていない。発注先が妥当かどうかを、その発注先になりうる相手に聞いてしまう、みたいなことが起きる。

もう一つ、答えが出にくい理由がある。 判断の材料が、二つの場所に分かれていること。

出てきた案が妥当かどうかは、金額が相場の範囲に入っているかだけでは決まらない。その金額を出して何が変わるのか、いつまでに要るのか、どれくらい使い続けるのか。こういう材料は、社内にしかない。

このあたりは「見積もりは何を約束しているのか」にも書いた。

一方で、他にどんなやり方があるのか、あとから変えられるのかは、作れる人にしかない。

作れる人が来ても、社内の材料がなければ答えは出ない。 社内の材料が揃っていても、選択肢が並ばなければ比べられない。

だから、作れる人を一人連れてくれば済む、という話でもない。

社内に詳しい人がいても、この二つが一人に揃うとは限らない。 運用には詳しいけれど、作ったことはない。 作れるけれど、事業のほうまでは見ていない。 揃っていても、一人で決めて背負うには重いこともある。

契約に書かれるのは、やることだけ

発注先は、発注してから決まる。「発注するかどうか」「何を頼むか」を決めている段階では、誰もいない。

作り始めてからも、契約や見積書に並ぶのは、実際にやることの一覧。 なぜそれを作るのか、何を前提にしているのか、どこからは今回やらないのか。 このあたりは、残らない。

書かれないけれど、決まらないと進まない。だから、誰かが決めている。 決めた人がいないなら、誰も決めたつもりのないまま、決まっている。

発注して終わること自体は、悪いことではない。作るものがはっきりしていて、使う期間も読めていて、あとから変えることが少ないなら、それで十分だと思う。

大事なのは、そうでないときのほう。 作ることは頼めても、なぜそう作ったのかは、頼んだ内容の外になる。そこが誰の手にも残らないまま納品されると、変えたくなったときに、背景の理解や説明から始まることになる。 その説明が、変更のたびに要る。

作ることの依頼と、その判断を持ち続けるのは、別のこと。

箱が二つしかない

技術の判断を誰かに頼もうとすると、たいてい二つの形が出てくる。

発注する

作るものが決まってから始まる形。 仕様が固まっているほど、速いし読みやすい。

決めるところから頼む形も、実際にある。 作るものを決めるまでを、別の契約として先に頼む。発注先に配る説明書を書くのを手伝ってもらう。 小さく試して、できるかどうかを先に確かめる。

相談したら提案が出てくる形もある。 提案書と、だいたいの金額が出てくる。 ただ、提案の目的が発注してもらうことなので、なぜそれが要るのかを深掘りして整理するより先に、やるかやらないかのほうが決まりやすい。

どの形も、期間が切られている。 数週間から数ヶ月で終わって、終われば元の状態に戻る。

そのまま作る側になるなら、相談相手は「作らないほうがいい」とは言いにくくなる。決める段階と作る段階を別の会社に分けることもできるけれど、頼んだ相手に立場があること自体は変わらない。

採用する

社内に置く形。常時。日々の実装や運用があるなら必要。

ただ、決めることは、出てくるタイミングが偏る。一つ決まってから、次に決めることが出てくるまで間が空く。
日々の作業が少なければ、常時いても、その空いた時間にやることがなくなる。
日々の作業が多ければ、空いた時間は実装や運用で埋まって、決めることが出てきたときに、考える時間が残らない。

誰も間違っていないのに、うまくいかない

社内に人を置くかどうかは、その仕事がどれくらい求められるかで決まる。毎週なら枠を作る・採用する。年に一度なら作らない。毎月人件費が出る以上は合理的な決め方だと思う。

実際、毎週出てきて、その週のうちに消えていく仕事はある。 問い合わせ、運用、細かい機能追加。 量が読めるものは、頻度で決めていい。

一方で、年に数回、あるいは単発で出てくる決めごとがある。 どの外部のサービスに任せるか。 どこまでを今回作るか。 作り直すか、このまま使い続けるか。

必要になることが少ないから、そのために役割や体制を作ることにならない。

でも、あとまで影響が残るのは、こっちのことが多い。頻度で体制を決めているのに、効いてくるのは頻度の低いほう。釣り合っていない。

誰も間違った判断をしていないのに。

決めなかったことの記録

決める人がいれば決まる、という話でもない。決められる立場にいて、作れる側でいても、決まらなかったことはある。

作り始めたサービスで、何を主な機能にするか、誰が使うかがまだ定まっていない時期。設計から実装まで、自分で決められる状態だった。

ある機能を、外部のサービスに任せるか、自前で実装するか。

自前なら、細かい調整に対応できる。かわりに、動かし続ける手間と、実装の手間が出る。外部に任せれば、手間は減る。かわりに、細かい要望に対処できなくなる可能性がある。

その機能を長く使い続けるか、細かい調整が実際に必要になるかで、どちらがいいかは決まる。当時は、どちらも定まっていなかった。比べようとしても、材料が十分じゃなかった。

結果、定まらない間は選択肢が残るほうがいい、と考えて自前で作った。その判断自体は、間違いだと思っていない。

ただ、決めたのは実装だけで、いつ比べ直すか・何が定まったら検討し直すかは決めていなかった。

そのあいだ、手を入れるたびに余分な手間が必要になった。選択肢を残すために作った仕組みは、ほとんど使われないまま残っていた。

切り替えられたのは、見直す日が来たからではなく、何を主な機能にするか、誰が使うかが、たまたま定まったから。 切り替えたときの判断は「動いていたものを、なぜ止めたのか」に残している。

一度の決めごとが、後々の作業のたびにコストになっていた。

決めきれないことを、決めきれないまま持っておく

決めきれないこと自体は、どんな状況でもあると思う。

ただ、決めきれなかったことを、そのままうやむやにするかどうかは別。

何が定まったら検討し直すか。これを一行でも書いておくと、持ち越したことが記録になって、あとで、そのときの理由と、その後に出てきた手間を比べ直せる。 書いておくことは人を増やさなくてもできる。

もう一つは、抱えている決めごとを二つに仕分けてみること。

毎週出てきて、その週のうちに消えるもの。 年に数回か、単発で出てくるもの。

後者は、契約にも体制にも載らないまま決まっているものの一覧になる。

必要なのは、常勤のエンジニアとは限らない。作業だけをする人でもない。

作る前には、決めごとがある。何を作るか。どう作るか。何を使うか。そもそも作らずに済ませるか。

作った後にも。何を変えるか。どこまで直すか。作り直すか。外のサービスに移すか。このまま使い続けるか。

システムを作るのは一回でも、判断はその一回では終わらない。

その判断に加わる人。作れることと背景を知っていること。 この二つが同じ側に揃っていないと、答えは出ない。

二つが揃っていても、決めきれなかったことを見直すときまで持っておかないと、一度の決めごとが、作業のたびのコストになる。

社内のエンジニアとも限らないし、形も問わない。「判断の空白が生むコスト」にも書いたけれど、必要なのは肩書きではなく、その役割があるかどうかだと思う。

何ができるのか、どこから決めればいいのか分からないとき：https://yoshiakihayashida.com/consulting/