今日もお家で休養中。
次回出社は明後日 水曜日でほぼ確定しました。
それまで暇～。
この前、客先作業と、自社作業を比較し、客先作業の方が優れていると書きました。
客先作業が自社作業に勝る点について、もう少しだけ書きたいと思います。
客先作業の最大のメリットとして、「仕様の認識違いが防げる」というのがあると書きました。
これは非常に重要なことなんですよ。
システム開発をする場合、一般的にはざっくりと以下のような流れになります。
１．設計
↓
２．プログラミング・単体テスト
↓
３．結合テスト
↓
４．総合テスト
よく、「プログラムをお客さんに納品できた。やったー。」なんて言いますが、
だいたい２．までの作業を指すことが多いです。
でも、システム開発には３．結合テスト、４．総合テストというのが待ち構えています。
自社開発で恐ろしいのは何といっても、３．４．で仕様認識違いが露わになり、
プロジェクトが火を噴くところです。
私が以前名古屋でやっていたプロジェクトは、
１．設計 ３か月
２．プログラミング・単体テスト ５か月
３．結合テスト ７か月
４．総合テスト ３か月
ぐらいで、それぞれの期間作業をしていました。
よくシステム開発のメインはプログラミング（コーディング）と思われる方がいらっしゃい
ますが、実はそれ以上に、３．４．のテスト期間の方が長くなることがおおうにあるのです。
仕様認識違いのまま突入した結合テストは本当に悲惨なものです。
お客が作った結合テスト仕様書の期待値通りに、ものが作られてないのですから。
ここで
お客：仕様通りに作ってない。今すぐ直せ！
自社：設計書やQ&Aのやり取り通りに作った。仕様変更だ。金よこせ！
と泥沼状態突入！
キャ～～、いやだーー。
ちなみに仕様変更とは、設計書等の内容が書き換わり処理が変更になったり、機能が追加に
なったりすることで、もちろんこれはお金がもらえることになります。
一番ネックになるのは仕様変更でもなんでもなく、ただの内部のゴダゴダなので、
お客さんのお客さん（クライアント）からは一切お金がでないこと。
どこからもお金が出ないわけで、お客さんも強硬姿勢で修正を迫ってくるのは当然です。
これで名古屋の時は何度地獄を味わったことか…。
ホントに地獄だったんですよ。
いやホントに（しつこい）。
もうそれこそ本当にお客さんと闘いになるんですよ。
１．あのQ&Aでこう書いてあったから、こう作った！
２．あの打ち合わせだれだれが、こういったからこう作った！議事録も残っている！
３．この設計書にはそんなこと書いていない。だからすべて仕様変更だ！
て感じで、お客さんにお金を要求しなくちゃなりません。
全部バグ(瑕疵)扱いされて、無報酬でプログラムを直していったら、プロジェクトは赤字を
垂れ流し続けます。
それを少しでも食い止めるため、お客に対しひたすら仕様変更を要求。
名古屋の時はこれをやり過ぎて、お客様からたいそう忌み嫌われたものです。（妖怪人間か）
それがあつれきとなり、名古屋の現場でずっと指揮を取っていた私、及びメンバーは
死ぬ思いをしてきました。
事業所で離れて作業しているマネージャ達は気楽なもんなんですよ。
「お客のいいなりにならず、仕様変更取ってこいよ！」みたいな感じで私に要求してくるん
です。
中には「確かにこれは仕様変更だ」と言い切れるものあります、ただそれ以上に
「これはうちの会社が悪いんじゃねえのか～？」と思えるものの方が多いんです。
そうなると、
ふくたま
離れた場所で作業しているマネージャ
の図式になるわけです。
私も自社が潤うようにやりたいです。でも、技術者としてそんなの気づいて当然だろ～、
てか絶対に要求通りません、みたいなものまで仕様変更として要求してくるからタチが悪いのです。
まぁ結構つっぱねましたね、私…。
これで私は自社からさんざん悪者にされるわけですが。。。
おっと話がずれているような気がしますが、とにかく誰だってこんな泥沼嫌だから、
開発段階からお客と綿密にやり取りはしているんですよ。
でも、やはり自社作業では限界があるのです。
今のプロジェクトは客先作業だから（これだけが理由ではありませんが）、
結合テスト、総合テストでどの沼のやり取りってのは発生しなかったんですよ。
プロジェクト全体としてもコストがかからないし、
予定通りスムーズに進むし、余計な管理作業に手間をかけることもないしと
いいことづくめなのです。
滞在費を浮かせることだけを考えていると、私の名古屋の時みたいに、結合テストで
その何倍、いや何十倍のコストがかかることになるかもしれません。
何より、泥沼状態になった時、お客さんとの関係にヒビが入るのが最大のデメリットだと
思います。
そうなったら、100%誰もいい思いをしません。
みんなで仲良く
やっぱストレスなく、楽しく、真剣に仕事したいですね！
次回出社は明後日 水曜日でほぼ確定しました。
それまで暇～。
この前、客先作業と、自社作業を比較し、客先作業の方が優れていると書きました。
客先作業が自社作業に勝る点について、もう少しだけ書きたいと思います。
客先作業の最大のメリットとして、「仕様の認識違いが防げる」というのがあると書きました。
これは非常に重要なことなんですよ。
システム開発をする場合、一般的にはざっくりと以下のような流れになります。
１．設計
↓
２．プログラミング・単体テスト
↓
３．結合テスト
↓
４．総合テスト
よく、「プログラムをお客さんに納品できた。やったー。」なんて言いますが、
だいたい２．までの作業を指すことが多いです。
でも、システム開発には３．結合テスト、４．総合テストというのが待ち構えています。
自社開発で恐ろしいのは何といっても、３．４．で仕様認識違いが露わになり、
プロジェクトが火を噴くところです。
私が以前名古屋でやっていたプロジェクトは、
１．設計 ３か月
２．プログラミング・単体テスト ５か月
３．結合テスト ７か月
４．総合テスト ３か月
ぐらいで、それぞれの期間作業をしていました。
よくシステム開発のメインはプログラミング（コーディング）と思われる方がいらっしゃい
ますが、実はそれ以上に、３．４．のテスト期間の方が長くなることがおおうにあるのです。
仕様認識違いのまま突入した結合テストは本当に悲惨なものです。
お客が作った結合テスト仕様書の期待値通りに、ものが作られてないのですから。
ここで
お客：仕様通りに作ってない。今すぐ直せ！
自社：設計書やQ&Aのやり取り通りに作った。仕様変更だ。金よこせ！
と泥沼状態突入！
キャ～～、いやだーー。
ちなみに仕様変更とは、設計書等の内容が書き換わり処理が変更になったり、機能が追加に
なったりすることで、もちろんこれはお金がもらえることになります。
一番ネックになるのは仕様変更でもなんでもなく、ただの内部のゴダゴダなので、
お客さんのお客さん（クライアント）からは一切お金がでないこと。
どこからもお金が出ないわけで、お客さんも強硬姿勢で修正を迫ってくるのは当然です。
これで名古屋の時は何度地獄を味わったことか…。
ホントに地獄だったんですよ。
いやホントに（しつこい）。
もうそれこそ本当にお客さんと闘いになるんですよ。
１．あのQ&Aでこう書いてあったから、こう作った！
２．あの打ち合わせだれだれが、こういったからこう作った！議事録も残っている！
３．この設計書にはそんなこと書いていない。だからすべて仕様変更だ！
て感じで、お客さんにお金を要求しなくちゃなりません。
全部バグ(瑕疵)扱いされて、無報酬でプログラムを直していったら、プロジェクトは赤字を
垂れ流し続けます。
それを少しでも食い止めるため、お客に対しひたすら仕様変更を要求。
名古屋の時はこれをやり過ぎて、お客様からたいそう忌み嫌われたものです。（妖怪人間か）
それがあつれきとなり、名古屋の現場でずっと指揮を取っていた私、及びメンバーは
死ぬ思いをしてきました。
事業所で離れて作業しているマネージャ達は気楽なもんなんですよ。
「お客のいいなりにならず、仕様変更取ってこいよ！」みたいな感じで私に要求してくるん
です。
中には「確かにこれは仕様変更だ」と言い切れるものあります、ただそれ以上に
「これはうちの会社が悪いんじゃねえのか～？」と思えるものの方が多いんです。
そうなると、
ふくたま
離れた場所で作業しているマネージャの図式になるわけです。
私も自社が潤うようにやりたいです。でも、技術者としてそんなの気づいて当然だろ～、
てか絶対に要求通りません、みたいなものまで仕様変更として要求してくるからタチが悪いのです。
まぁ結構つっぱねましたね、私…。
これで私は自社からさんざん悪者にされるわけですが。。。
おっと話がずれているような気がしますが、とにかく誰だってこんな泥沼嫌だから、
開発段階からお客と綿密にやり取りはしているんですよ。
でも、やはり自社作業では限界があるのです。
今のプロジェクトは客先作業だから（これだけが理由ではありませんが）、
結合テスト、総合テストでどの沼のやり取りってのは発生しなかったんですよ。
プロジェクト全体としてもコストがかからないし、
予定通りスムーズに進むし、余計な管理作業に手間をかけることもないしと
いいことづくめなのです。
滞在費を浮かせることだけを考えていると、私の名古屋の時みたいに、結合テストで
その何倍、いや何十倍のコストがかかることになるかもしれません。
何より、泥沼状態になった時、お客さんとの関係にヒビが入るのが最大のデメリットだと
思います。
そうなったら、100%誰もいい思いをしません。
みんなで仲良く
やっぱストレスなく、楽しく、真剣に仕事したいですね！