IT投資発注編の最近のブログ記事

従業員約30名の会社を経営してます。情報システムの企画・開発や管理・運用において、社内でも安心して任せられる人材も特段なく、かといって、外部の企業にアウトソーシングすることも、セキュリティや情報の漏洩などで抵抗感が強くあります。他社さんでも、当社のような現状と似たようなものなのでしょうか?

回答


多くの中小企業の情報化においても、カネやモノの悩みよりも、まず第一に「ヒト」についてお悩みのケースが少なくありません。
人員が少なくやりくりが厳しい中においても、外部の要員に開発・運用を依頼したり、ASPサービスを利用したりする例は、セキュリティや費用の面、さらにはASPサービスなどに至っては知名度の低いことから、十分活用されていないのが実状です。すべて社内のみで企画から開発・運用までを実施する例もありますが、運用だけは社内というケースが多数を占めているようです。

具体的な「ヒト」についての悩みは、ITと会社の業務・経営をリンクさせて考えて企画を出し、それを実施から運用までフォローしてくれる人材には、企業規模の大小を問わず、非常に不足しております。企業の情報システムとして考える、ITに詳しい人材も、なかなか確保できない状況ですので、現実問題として、パソコンやインターネットを趣味で使っている社員が事実上のIT通として見られ、企画や業者との折衝・運用をしている例が多いです。

要員が限られている状況下において、他に業務を行っている若手社員を趣味の延長として兼務で行っている事情も、どこも大同小異とは思います。こうした状況に対して、管理者としてチェックをしていくポイントとしては、以下の内容が挙げられます。

(1)外部の業者の言い分・利害を見極める。
→趣味の延長で社内の情報化を考えてしまう場合、もっとも起こるリスクとしましては、外部の業者などから提案・見積・折衝などを行っても、社内の状況や課題を十分に説明しきれない、好き嫌いやイメージで考えてしまいがちなため、ブランドイメージや華やかさで業者を選定しがちである、といった問題もありますが、最も意識すべき点は、外部業者の言いなりになったり下手をすれば外部業者の応援団になってしまうことだと考えます。
こうした事態にならないよう、「その効果は、見積にあるコストと照らし合わせて明らかに得なのか、仮にすぐ効果が出なくても妥当なのか。」といったことを、必ず聞いて自分の意見や根拠を聞いてみることがポイントになるでしょう。

(2)主張に際し、具体的な根拠を聞いてみる。
→現在のインターネット世代・携帯電話世代は、昨今の「ゆとり教育」の弊害も出ているとは思いますが、物事を「なぜ?」と考える習慣が減少し、直感的なイメージやムードで判断する色合いが高まってきている傾向にあるようです。もともと日本の国民性も、多分に観念的・情念的な部分が色濃くありますが、そうした傾向が情報化社会や「ゆとり教育」によって強化しているようです。
直感的に業務上の判断を処理していては、場当たり主義がより強まり、全体としても好ましいことではありませんので、根拠のあいまいな稟議や報告には決裁しない、評価しないという習慣付けをしていくと良いでしょう。

「情報システムに対して良く分からない。」とおっしゃる場合にも、上記のように業務のあり方やビジネススキルに関連して進めていく方向は、比較的マネジメントしやすくなるものと考えます。

システム開発において、開発業者が見積や提案書を提出する前に、概要設計やコーディングを先行させてしまいました。最終的にその開発業者に作業を依頼しないことになりましたが、数ヶ月たった段階で、その時点までのシステム設計及び開発費用を請求するのです。契約を結ぶ前の段階なのですが、払わなくてはならないのでしょうか。

 

回答

当サイトは法律相談は専門ではありませんが、商慣習上の範囲で分かる範囲でご説明申し上げます。ただし、正確に解釈・対処する場合におきましては、司法書士・弁護士などへのご相談及び、民法にあります、法律行為及び契約の内容をご参照頂けましたらと存じます。

内容に入りますと、実際に業者が作業を先行した時点におきまして、口約束も含みますが、意思表示の合致(申込と承諾)があり、効力を有しているかどうかが問題になってくると考えられます。民法95条では意思表示に際し、何らかの表示行為(例えば業務をお願いしたいということ)が有った場合、効力が生じますが、錯誤の場合には、重大な過失があった場合、無効を主張できない場合があります。

ポイントとなりますのは、相手側が作業を先行した時点で、その時点で契約の成立が今後行われるであろうことを、相手側に想起されるような言質・解釈を与えているか否かということと思います。
本来ですと、正式に契約が成立してからでないと、こうした行為は行うべきでないのが原則ですし、多くの開発業者では見積や事前の商談だけでは、実際に確定となるかは不透明のため、正式な発注を得ない段階での開発にストップをかけている例が大半ですが、今までの打合せ内容に際し、契約は成立していない旨の議事録・メモなどがありましたら、大きなポイントになるのではないでしょうか。

開発業者の側で法的に根拠に足る理由がある場合、事前に内容証明や少額訴訟・ないしは地裁の訴訟など起こしてくることが想起されますが、逆に法的な根拠が薄弱の場合(取引的に曖昧なことを見越し、取れるものは取ろうとする場合)には、何も請求しないケースもあると考えられます。

内容的に押し問答の形になることも予想されますので、当時の議事録などをもとに法的な対応も検討していく必要があるかと考えられます。

システムインテグレータと正式契約する際に気をつけることはどんなことですか?

 

回答

発注先の決定に伴い、契約内容を文書で取り交わしましょう。注意すべき点は以下の通りです。

1.責任の所在
プロジェクトの責任者を明確化することが重要です。

2.途中変更に関する規定
作業開始後でプロジェクトの責任者及びメンバーが中途で交代する場合、進捗状況や品質に影響を及ぼす可能性があります。したがって途中変更に伴う対策及び規定を前もって契約書に盛り込んでおくことが肝要です。

3、支払条件
支払条件は発注先、開発案件により異なります。システム構築中に客先が倒産するケースがあるため、着手金を要求する業者もあります。例えば、基本設計が完了した時点やプロトタイプを納入した時点など、という具合に、進捗を確認しながらそれに見合った形で支払っていく方法もあります。

着手金及び中間金などを支払うことで、スムーズに仕事を進めてくれる場合もありますが初期の着手金は1-2か月程度様子を見て、支払うことが望ましいと考えます。
支払の比率については,場合により異なりますが、契約金は2~3割、精算金は3~4割、それ以外を中間金に割り当てるのが目安になります。中間金の支払いは、時期でみるのか、成果でみるのかを事前に話し合っておきましょう。長期にわたる開発期問や大規模な案件、難易度が高い等の場合には、双方でリスクを負担することを考えて中問金も3ヵ月ごとなどいくつかの段階に分けて支払うケースもあります。

 

開発体制の確認はどのように行なえばよいですか?

 

回答

開発体制の確認は、開発のマネジメントのあり方、人数及びスキルが費用に見合っているのかとの観点で、判断基準になります。

第一に、どのようなスキルを持ったスタッフが何名いて、開発の期間、設計・開発の担当者などを明確にすることが必要です。概要については契約以前の提案書の中で盛り込むケースが一般的ですが、発注時には詳細のジョブアサインを確認する必要があります。

プロジェクトの成功のために、プロジェクトに関与する外部企業のスタッフを、自社の仮想のスタッフとして管理可能な作業体制を考える必要があります。予定通り(進捗管理面及び品質面)において開発の進捗を把握するため、

1.各工程ごとに進捗状況を成果物(納品物・プログラム・画面など)で確認すること。

2.1週間に1度・月次において進捗会議を行い、進捗状況及び現状の課題、それに対する対策について実施するように心掛ける必要があります。

一部の処理について具体的なことが決まっていません。あとで不都合にならないようにするには、どのような点に注意すればよいでしょうか?

 

回答

これは、一部の処理の内容及び業務との関わりにより異なります。単純な機能かつ他のプログラム及びアプリケーションに影響を及ぼさない範囲内の場合、最終段階で織り込まれることはさほど難しくありませんが、システム全体の構成及び処理能力が左右される場合、全体の設計を変更するおそれもあります。

こうした問題は納期及び費用に影響を及ぼす可能性が高いため、よほどの特殊要因がある限り、事前に仕様を決定することが重要です。納期及び費用は最初から契約書で取り交わすことが前提ですが、未決定の契約はその時点での契約になるため、費用追加、納期の延期の可能性を考慮に入れる必要があります。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちIT投資発注編カテゴリに属しているものが含まれています。

前のカテゴリはIT投資発注先検討編です。

次のカテゴリはシステム開発編です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。