7月
29
2005

はまったシステム開発

ふぅ、やっと開発が99.5%まできました。
ソフト全体の量からいうと、90%は比較的早い時期に到達したが、それからが時
間的には半分以上を占めることになります。ことわざにも99%ほど来てから、半
分来たと考えろというのがあったが、そんな感じです。

実は単独でソフトウェア開発を受注したのは初めてで、それまでは会社で受けた
り、自社ソフトウェアを作っていたりしました。その経験の足りなさでこんなこ
とになったかもしれません。

開発システムは登録されたユーザーと会社の間で行う受発注のシステムで、私は
管理画面を任されました。儀中的には、Webインターフェースで言語はPHPとテン
プレートエンジンのSmarty、DBはPostgreSQL 8を使用しています。
Webシステムなので、環境は簡単に用意できるし、場所を問わずにできるという
ところがあります。

最初の打ち合わせは6月10日でした。

設計書を渡されて当初は楽勝と思っていました。
技術的な課題は最初の2週間でクリアしたので、あとは機能的なことを補足的に
追加していけばよい。管理画面は社内で使うので、そんなに複雑なものではない
だろうと思っていました。

そして先方から提示された金額で十分だろうと思い、金額的にも納期的にも了承
しました。ぱーっと早く仕上げて、後は楽ができる。1ヶ月かかるところを3週間
で仕上げて、もっと急げば2週間で仕上げて、同じ仕事を2つもつことが可能か
なと楽観的に思っていました。

ところが90%ぐらいコーディングが済んだ所で、テスト仕様書が送られてきまし
た。6/22でした。テストデータがまだありません。自分で勝手にデータを作っ
て、それに対して動くかどうか確認していました。

そしてテスト仕様書の内容は、最初の設計書に含まれていないものもあります。
えっ、それは追加仕様じゃないの?金額を決めた後に、、、、
追加仕様が、予算内に納まりそうかどうか、テストしながら考えていました。想
定外の仕様だと報告したのが、6/30です。それから7/8に打ち合わせをして、
「仕様が追加されていて当初より工数が半月分増えている。それを考慮して欲し
い。」と伝えました。お金の話をメールでするのは控えたかったので、1週間ほ
ど伸びてしまいました。

冷たい対応だったので、「いっそ納品はなしで、お金ももらわない」という選択
肢も考えました。しかし、双方にとってマイナスのことは非建設的なのでしたく
はありません。それに、お客さまにとっては時間の損失なので、逆にペナルティ
を課されることもあります。

その話があってからも、追加仕様やらなんやら設計の変更などもあっております
が、ある意味で勉強代だと思って割り切っています。それからもお金のことはや
りとりがあって、いまだに決着はついていません。プロジェクトには旧友が入っ
ておりますので、納得にいく結果をもたらしてくれると信じています。

いろいろあって、あるところは仕様追加し、修正し、仕様から外されました。と
りあえずこの日記の翌日になりますが、旅行1日前にとりあえず納品ということ
になりました。

いまはとりあえず終わって、ホッとしています。

打ち合わせ2回と、メールなどでのやりとりに、お客さんはギブアップしまいま
した。私は発注側として慣れていましたが、受注側の立場としては初めてです。
受注側にとっての気持ちも理解できました。双方ともなれていないと難しいです
ね、やはり顔をつき合わせていた方が良いみたいです。言葉できちんと伝えるの
は難しいです。

メールですと、受信側の感情で読んでしまいます。私もある人から貰ったメール
を読んでかぁーっと怒ったことがありますが、後になって冷静に読んでみると怒
るような内容ではなかったんですね。言葉の背景を知っておくことが大事です。
メールを送るときでも受け取る側でも、言葉をとり間違えたりして、文章が完璧
なわけではありません。

——————————————————————–

発注者側でも、自分の意図しているようにやってくれていないと憤懣を感じてい
たと思います。自分の意図が最終目的だと。

しかし、これは相手に伝えるのは非常に難しいところです。

私も発注者側にまわったときがあります。
今回とは性格が異なりまして、仕様がきちんと確定したわけではありませんでし
た。ある程度の自由度があり、一番良い方法でやってもらえばよいという方法で
す。ただこれだけは避けて欲しい、これだけは抑えて欲しいという点だけを指示
しました。

私はあれもこれも細かく注意して、地雷のところだけをたくさん教えていたので
は、開発に関しての自由な発想がそがれると思ったからです。長所を誉めずに、
短所だけを指摘すれば、人は成長しません。同様に、ソフト開発も自由に本人の
納得のいくところでやってもらえればと思います。

それが結局は、商業的な成功を勝ち取ると思います。
間違っているかな?

———————————————————————-

今回も最終的には守備側に回ってしまったと思います。
もし余裕があれば、Ajax的な実装もできたと思います。
そうすると、検索ボタンを押さずして逐次に結果が反映されて、使っていても楽
しいシステムになったのではと思います。本当に時間が余ったら、自分のリスク
でそういうことをしようと思っていました。

友人からは今回の仕事の進め方で貴重な意見をいただきました。

・最初に取り組んで見て、それから予定工数でいけるかどうか早めに検証をとる
・仕様書、設計書に不備があるとき、矛盾点があるときは、指摘する
・仕様追加して複雑な実装になっても、発注者は受注者の責任と思う

今回の教訓としては、以下のような感じです。

・安易に受注するとはいわない。受注した瞬間から、納期に間に合わないとペナ
ルティになりうるし、工数増加になりうる。発注の内容をすべて確認するまで、
明確な返答はしない。

・発注者側はお金を払うので立場が強い。お金はいらないといっても、一度受け
たのを途中で投げ出すことは、評判の問題でいいづらい。発注の内容よりも、発
注を投げ出したということが一人歩きするので。

・発注内容をすべて納得するまで、受注しない。設計書が完備されていなけれ
ば、要求するし、なければ自分でつくる。その設計書作成の時間と労力は、お客
に請求するぐらいのことをする。

・短すぎる期間は注意する。検討するだけで2週間、1ヶ月くらいすぐに経ってし
まう。継続の仕事は可能だが、新規のときは注意する。お互いの背景や考え方な
どの理解を双方に得る時間が必要。

・途中での追加開発は気をつける。場合によってはすべて作り直しになります。
機能を少し追加した場合でも、全面的に作り直しになり、テストを最初からやる
こともあります。一度バグをつぶしても、不注意から再浮上をすることがありま
す。一度完成してから、機能追加しましょう。その苦労を発注側はたいしたこと
はないと考えるかもしれませんが、とても大変です。

・一人でやっていると、ケアレスミスが多い。つまらないミスをする。直したは
ずなのに直したと思ったり、つい単純作業をしわすれることがある。根をつめて
やっていて疲れると、ケアレスミスが増えます。

・同じ職場で働かないときは、上記のことがもっと成熟していないといけない。

幸いにも今回のトラブルは、自分が働いた分が一部受け取れないというところに
すみました。これが他の人を雇っていると、お金はマイナスとなり、仕事をした
ぶんだけ損をするということにもなりかねません。

受注ソフトウェア開発は建築やリフォームとは異なり、手法や手段、納品物はあ
る程度の決まった枠がありません。しかし瑕疵責任がありますし、納品後のトラ
ブルもありえます。ある意味、リフォームなどのトラブルが参考になることがあ
ります。誠意をもってきちんと納品して、お客さまに満足してもらおうという気
持ちでやっておりますが、それでもトラブルが発生しうるんだなと思いました。

Written by in: 楽天日記 |

コメントはまだありません »


コメント&トラックバック




トラックバック URL

コメントのRSS feed