私は、外注という立場で働いています。そして、工数がオーバーフローしそうになると、お客様の諒解を得た上で、さらに外注さんに協力を依頼します。最近は、この金額がものすごく膨らんできています。

この「さらに外注さんに協力を依頼」するとき、いくつかの課題が存在するように思います。

・完璧な仕様書のジレンマ
完璧な仕様書を書く → 発注するには良いのだが、過大な工数がかかる
ラフな仕様書を書く → 成果物にあいまい性が出るが、工数はそこそこ

・技術空洞化のジレンマ
全て丸投げする → 効率は最高だが、自社に技術が残らない
全て内製する 　→  技術力はつくが、資金効率が悪い

どう対応するのがベストか分かりませんが、とにかく第一歩を踏み出さなくてはいけません。そこで、次のような仮説を立てました。

「良い設計品質を保てば、たいがいの事はどうにかなる」

一般的と私が思う、作業の流れ：仕様偏重プロセス

私の狭い経験からは、こんなパターンが多いように思います。

（１）発注元が仕様書を書き、発注先に渡す
（２）発注先が設計・実装・テストを行い、発注元に渡す
（３）発注元は、納品後も問題や仕様変更があれば、発注先に修正依頼する

もちろん、途中で発注元がデザインレビューをしたりするでしょうが、基本的なポイントは次の通りです。

「発注先の責任は、仕様書通りのモノを、納期通りにおさめる事のみ」

すごく当たり前ですねー。

おためし中の、作業の流れ：品質偏重プロセス

仕様書通りか？って言われても、その仕様書自体があいまいなのでは仕方がありません。

そこで、次のようなプロセスを試験的にまわしています。

（１）発注元が、そこそこの仕様書を書き、発注先に渡す
（２）発注先が設計・実装・テストを行い、発注元に渡す
（３）発注元が 設計書・ソースを引き取り、以後の仕様変更や不具合対応は、発注元で実施する

ソースを引き取って、こちらで処理するのは、こまごました修正は、自分で対応したほうが速いからです。

仕様の解釈違いはもとより、単なるプログラムミスもこっちで直しちゃいます。

ただし、設計や実装が十分にシンプルなものであることが重要で、この点については、検収前にウザいほどつっこみます。

要するに、「キレイなソースをくれるなら、あとはこっちでやったほうが速い」のがポイントです。

まずは小さなプロジェクトで適用してみましたが、私としてはうまくいっているように思います。まだ半年以上は外注する案件があるため、この方式でどこまでうまくいくか、実験を続けてみます。

具体例

たとえば、幅４、深さ８のFIFOをSimulinkで書いてもらったとしましょう。すると、こういうモデルが出てきたりします。うん。全然悪くない。仕様どおりだし。

でも、思うのです。これ、あとから深さ２５６にして欲しい、なんてお客様に言われたら大変だなぁ、と。そこで、次のようなモデルにしてもらいます。

これなら、幅も深さも、ワークスペース変数で自由に指定できます。

もちろん、理由があってあえて前者のモデルにしている場合もあるでしょう。その時は話をお聞きして、納得すれば私の提案は取り下げます。

改善の方向性

より良い仕様書を書く

今回やろうとしている事は、あくまで過大な工数をかけてまで仕様書の完成度を上げないというものです。

ですから、より少ない工数で、より正確で分かりやすい仕様書を書くための努力を惜しむつもりはありません。

簡単な方法としては、誤解が生じてしまったあとで、「どういう風に書けば、誤解なく伝わったでしょうか？」とお聞きする手があります。たいがい、すごくいいアイデアをいただけます。

ちなみに、仕様書をSimulinkモデルで書いて実行可能な仕様書だ！という話がありますが、あれとは領域が違います。Simulinkモデルの仕様書をSimulinkで書くとか、ジョークとしては面白いですけどね。

仕事仲間全体の技術力を上げる

どれだけ仕様についての理解を深めても、そのプロジェクトが終わったら無駄な知識になってしまいます。しかし、「どれだけ分かりやすいモデルやソースを書くか？」という技術は、今回限りのものではありません。

また、実際にやってみて分かったのですが、今回のような目線で成果物を見てみると、お教えする事より、教わる事の方が多かったりします。

このように、お互いに技を盗みあえば、素早く技術を蓄積できて、競争力が増しそうな気がしています。（そうなったらいいなぁ！）

不安要素

もちろん、不安要素もあります。

まず、本当にこれで品質を確保できるだろうか？というものです。テストの責任があいまいに感じるので、どうしても不安を覚えます。

あとは、本当により良い方向に向かっているのだろうか？という点です。技術が空洞化しようが、仕様書作るのが大変だろうが、とにかく外注さんに全部責任を取ってもらうというのが、企業としては最適解なのかも分かりません。

まとめ

今回のやり方のポイントは、

「こまごまとした仕様を、仕様書に落とす」工数と、「こまかい事は自分でやる」工数と、どちらが重いか？

です。

仕様書を書いた方がラクな部分は仕様書を書く、自分で修正したほうがラクな部分は自分で修正する、というプロセスを作ったつもりです。

良い設計品質さえ保てれば何とかなるはずですが、それでも色々と問題は出てくるはずです。でもまぁ・・・なんとかなるでしょう！