ケンブリッジ白川さんがこんなブログを書いていた。SIerのような業態に置いて、営業と開発を分離しても意味がないと。もうちょっというと、プログラミングと要件定義は不可分ではないのか、と。

受託開発における永遠の課題である、要件定義とプログラミングの関係を整理したので、共有しておきます。

ソフトウェアの要件に関心があっても、人の動きに関心がある人は少ない

受託開発は、当たり前だけど特定の顧客のためにシステムを作る必要があります。目の前にいる顧客を理解することから逃げたら、プロジェクトを立ち上げることはできません。

このプロジェクトを立ち上げることに関心があるエンジニアは、無茶苦茶に少ない印象です。関心事の中身が違いすぎる。

• AWSでインフラ設計するのが好き

• パフォチューを考えるのが好きとか

• Kubernetesでコンテナ管理したい

• 技術的負債を解消したい

• 新しいライブラリ使ってみたい

こういうのが、ソフトウェアの動きや仕組みの話だと思っています。

受託開発の立ち上げにおいて、上記の話はまず出てこない。素人さんにヒアリングすることから始めないといけない。この段階では、人の動きを観察することが一番求められます。

• なんでこの方々はこういう働き方をしてるのか・動きになっているのか

• どうして今のあり方を変えないといけないのか

• どこに負荷がかかっているのか

• 認識している問題と言動がズレてないか

ユーザーが欲しいと言っているものと、ハッピーになれるものは、全然違うことも多いので、気づいてもらわないといけない。欲しいと言ってるものより、もっといいものがありますよ、それはやりすぎなんでこっちに行きましょうよ確実ですよ、みたいな。舵取りがとても重要になる。

・・・ソフトウェアの話、出てこないんだよ〜。

こういう人の動きに含めた話をまとめて「要求」ということも多い。要求定義→要件定義と分けたほうがキレイだよねっていう。でも、無茶苦茶な要求だけまとめられても困るじゃん。そこで負けたら、敗戦処理が待っている。

そこも関心があって、実装もできてエンジニアに指示出せる人を育てようというのは、気概としては良いけど、組織的に安定した成果が出るかと言われると、極めて難しいと思う。

まとめると、受託開発を商材にした場合、営業と開発はスキルセット・マインドセットが違いすぎるので、同一人物がいい感じにやることに期待できない。永遠にその日は来ないかもしれない。なので、営業と開発は分離していいと思っている。

どっちもやったことがあるけど、頭の切り替えが本当に大変だった。自分で営業して自分で開発するとなると、面倒だと感じることは蓋をして簡単な仕様に倒したくなる。そうすると、顧客に提案する機能のバリューが下がるので刺さりにくい。

要件を決めるにはITエンジニアでなければならぬが、プロジェクトをデザインして論点を整理して持ち帰るのを営業のタスクとすれば、分業アリ。

プロジェクトのスコープを機械的に絞る技術

白川さんが指摘している「高度な綱渡り」については、ビジネスモデルである程度緩和できる。

プロジェクトの「実際の」難易度は客の言うこともどこまでホントかわからんので見えない。水面はきれいに見えるが明らかに濁ってる。何もわからんじゃ受注できないので、見えているリスクを可能な限り見極めた上で許容する、みたいなや葛藤のことです。高度な綱渡りと表現しているのは。

ここでのリスクは「予算と工数が適切かどうか」に集約される。難易度の多くは技術的なものじゃなく、工数や契約の問題のほうが大きい。

開発の都合は棚上げしてもいいが、風呂敷はたためる大きさにする必要があるので、始めから風呂敷の大きさを固定にすれば良いという話が当然出ててくる。そのため、機械的にスコープを切るためにいわゆる月額定額モデルが爆誕する。

このモデルにすれば、関心事が技術的に可能かどうかに集中できる。予算によって稼働する工数が決まるし、動かせないことをコミットできるため。

プロジェクトのいやらしい点に、有期でありながら段階的に詳細が見えてくるという性質がある。その段階的に見えてくる詳細に対する完成リスクを負うのはナンセンス、それをオブラートに包むのが定額モデルだ。

でも、この定額モデルが受託開発の主流になっているようには、個人的には見えない。多分ならない。受託の場合、案件の性質が様々なので。ゼロベースで中小規模の案件にしか適用できない気がしている。

リビングデッドになっちゃった今のスクラッチのシステムをリプレイスしたいっていう話が来た時に、開発定額なんで可能・・・か？ そうはならない。要件定義以前に必要なことが多い案件にはフィットしない。パッケージ導入支援なんかも当然合わない。

調達コストが定額であることと、定額だからYOUのペインが解決できますよって話は、リンクしにくいと思う。定額にフィットするプロジェクトだけを選別するか転換させるか、そもそも案件母数を集めるマーケティング・パワーが必要になる。それだけの会社に切り替えるって大変なこと。

色々書いたけど、一人が営業と開発を両方やるのは無理だと思っていて、営業なら営業に、つまりプロジェクトの立ち上げと顧客との対話に専念しないといけない。それだけの専門職があってもいいと思っている。

開発が意図した予算と工数で行けるかどうかは、機械的にスコープを切るなど、プロジェクトの立て付けやゴール設定によって、仕組みの中で吸収するのが良さげ。プライシングで啓蒙していく、といえばカッコいいか。