風来坊@真幸福知

出雲市 福知寺 行事ご案内 坐禅会 日記 テクノロジー English Zazen session technology Korean 한국어 참선 묵조선 텍놀로지

プログラム開発の外注

diamond.jp

ダイヤモンドオンラインにこんな記事.

システム開発(ソフト・ハードを含む業務用のシステム?)の外注は扱っているものがとても論理的で割り切れるモノであるかのように見える(実はかなり泥くさいかも)割に, 仕様を示して発注して製作して納品..と割り切れないものらしく, 結局は成功するプロジェクトでは発注者も受注者もみながひとつのチームとしてできることは何でもやる協力体制が必要というお話のようだ.

研究所に勤めていた時, (学生時代は自分でプログラムを書くのが普通なので)就職して初めてコンピュータのプログラム(流体のシミュレーションのすごくニッチなやつ)を外注するということを経験した. 結果を振り返ると, 上の記事の話に肯いてしまう.

最初の案件は仕様を決めたあとは受注者まかせで失敗.

次に仕切り直して別の会社に発注した案件では, 先方の担当者が途中で病に倒れられたりというハプニングでかなりの部分を自分でやることになり, それでも結果的に成功. (これが今のJASMINE)

3つめは他機関のプログラムを買って改造するつもりで始めたら, 改造するのは困難で最初から作ったほうが良いとなり, 自分で作ることになって結果的に成功. (Kiche)

4つめは緊急的に作ったので自分で突貫工事. 一応使い物になってオープンソースとして公開してある. (HOTCB)

自分でやればできる比較的規模の小さな開発なので, 最終的には自分でやるスタイルになったが, 初めの方の失敗を振り返ると, 小さなプログラム開発でも発注者と受注者という二者の間でやりとりしなければならない情報は, 発注仕様書と実装プログラム製品の間を埋める膨大な量になるということの認識の大事さを身にしみて感じる.

よほど簡単なプログラムか, でなければテレパシーで発注者の意図を組んで適切な実装方法を編み出してくれるようなエスパー的プログラマが受注してくれるのでなければ, 発注者と受注者がひとつのチームとして共同で作り上げるという姿勢がなければ不可能.

自分で全部やるスタイルになってから思うのは, プログラムに関しては, 完璧な発注仕様書ができたらそれは既に製品になっているってことかも. (文書にして人に頼むより同じ内容をプログラムに書いたほうが楽で速くて安い)

しかし, これは小さな仕事の話.

一人では速く行けるが遠くへ行けない, みんなで行けば時間はかかるが遠くへ行ける

という格言(?)の通り, 大きな仕事では上の記事のように全面協力で目的を目指すチームが必要なんでしょう. 日本の官製プロジェクトはこれが下手な気も...