数日前、こんなエントリーが話題になっていたので、零細企業である我々の視点からSIビジネスの流れを書いてみようと思います。ただし、私は業種専門ベンダーの人間なので、そこのところご理解願います。
零細業種専門システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。
- 集客
- 営業
- 要件定義
- 設計
- 製造
- テスト
- 導入
- 検収・請求
- フォローアップ
集客
どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われるかどうかわかりませんがその手法に、無駄に金をかけてSEO対策を施したホームページを利用する、何をやっていいのかよくわかっていないのに世の中の流れだからとTwitterマーケティングやFacebookマーケティングに手を出し担当者が途方にくれてしまうなどがありますが、結局のところ自社のユーザの紹介や人脈による紹介がもっとも集客確度が高かったりします。
最近では「中国」というキーワードでも集客ができるようです。
営業
アポイントの取れたお客様に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様が「ある程度の金額」をかけてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入りますが、「ある程度の金額」にかなりの格差があるので注意が必要です。事前にどの程度の体力がある企業なのかリサーチした方が無難です。
また、決裁権の全くないお客様と話をする場合、興味本位で話だけという場合があるので、新規開拓の場合は、ある程度割り切りを持って臨むことがコツです。
お客様から提案要求があった場合、このフェーズで提案書を作成します。ここでは詳細な要求が引き出せない場合が非常に多いので、見積も「概算で」とお願いされる場合がほとんどで、多くの場合はどんぶり勘定になりがちです。営業系の人間はなるべく安く、開発・運用系の人間はなるべく高く提案したがります。結局は零細、中小ベンダーは提案に金額面のメリットしか出せませんので、役員が大幅な値引きを決断して強引に案件をまとめに行きます。
要件定義
まれに要件定義を営業活動の一環とすることがあるようですが、自滅するので絶対にやめた方が身のためです。上流工程で金を取らないなら一体どこで取るのでしょうか。ここで費用をかけないで片手間にやってしまうと、後続の工程でいわゆるデスマーチに入ります。
案件がまとまると、お客様の要望から実際に開発するシステムの要件を作成します。この段階で、営業中に聞いた話と大きく食い違うことがあります。提案依頼をしたのが情報システム部門で、要件定義にユーザ部門が参加してきた場合、提案時の仕様はほとんど意味をなさなくなります。そのため、「要件が膨らむ」ケースが非常に多く発生します。
最近では、要件定義フェーズを分割してこの成果物で一度検収をあげてしまう準委任契約がトレンドのようです（高井さん談）。確かに。
設計
要件定義後の再見積でたいてい大揉めしますが、それがまとまると設計に入ります。詳細設計、内部設計、外部設計、基本設計、プログラム設計などという単語が乱れ飛びますが、企業によって呼び方、組み合わせ方とその意味するところがかなりまちまちなので、あまり単語に惑わされないようするといいと思います。要するにここでは、要件定義で決まった「何を作るか」に対して「どう作るか」を決めていくことになるのです。ひどい場合は、この工程を飛ばしていきなり製造に入るケースもありますが、このフェーズもドキュメントを残してきっちり仕上げていかないとたいていトラブります。
製造
ひたすらプログラムごりごりごりごり。製造原価を安く上げようとして外注を入れますが、この前の設計フェーズできちんとやれていないケースが多いので逆効果になります。ただし、素敵な設計書がある場合、スムーズに製造が進むことも当然あります。
大事なのは、ここできちんと単体テスト結果を出しておくことです。
テスト
製造が終わるとテストに入ります。この工程も、結合テスト、システムテスト、運用テスト、ユーザーテストなどいくつかの工程に分かれています。製造段階できちんと単体テストされていても、いざ結合テストをやるとまったく前に進まなくなるなんてこともしょっちゅうですので、このフェーズあたりから徹夜モードに入るプロジェクトをよく見ます。
それぞれのテスト工程において、テスト計画とその結果報告が要求されますので、捏造せずにきっちり仕上げましょう。後悔するのは自分たちです。
導入
この工程でもまだテストしながらなんてことが非常に多いです。本稼働前に並行稼動をやる場合もあるのですが、下手をするとここに来て仕様が現場の運用にマッチしないとか、これじゃ使えないとか言い出す現場の方々が現れますので、徹夜モードでとにかく本稼働に間に合わせるために仕様書、設計書度外視でプログラム修正に入るなんていう最悪のケースがあります。契約なんて糞食らえです。これがあとで火を見る序章になったりします。
検収・請求
上記までの通り、プロジェクトは往々にしてトラブりますので導入は大抵の場合遅れます。しかし、導入が完了しようがしまいが、ベンダーは自分たちの都合で検収を上げてくれとユーザに懇願に行くことになります。そうしないと、キャッシュが回らなくなるからです。ユーザもある程度事情を理解していることが多いので、ある一定の条件のもとに検収を上げてくれることも多いです。そうやってベンダーはユーザに対してどんどん負い目を作っていくのです。
フォローアップ
最近はIT全般統制などでドキュメントの整備を非常に厳しく要求されるのですが、導入時にその場その場で対応した突発的な回収などは要件定義書や設計書に残っていないことが多く、担当したSEはそのフォローアップでしばらくの間、手が離れない状態になります。そうこうしているうちに当初の契約でどこまでがシステム化範囲だったのかというのも不明確になり、瑕疵担保期間まで縛り付けられるのをよく目にします。それどころか、保守契約を盾に瑕疵担保期間後も縛り付けられているなんていうのまで見たこともあります。
そうやって赤字は垂れ流されていくのです。
以上、零細SIビジネス上から下まで。
0 件のコメント:
コメントを投稿