システム開発のブログ記事

　最近、支援先企業でよく受ける相談に社内システムのデータを業務分析や業務改善に活用したいとがあります。売上情報や顧客情報、経理情報と様々な情報を加工して、経営判資料や業務資料に使うことはとてもいいことです。

　建設現場でもコンクリートの品質管理資料や様々な材料業者からの納品情報を整理する際に複数のデータからまとめた形にしたいという話をよく受けました。

　このようなときに真っ先に思い浮かぶのがエクセルでのデータ整理です。最初はピボットテーブルや集計機能で、それからちょっとした条件関数や検索関数でデータ整理を行える仕組みづくりを考えます。まとめる頻度が多く、手間もそれなりにあるとなるとマクロを導入するということも少なくありません。４年ほど前に、「自社内開発のススメ」といった話で同じような話をしました。エクセルのマクロは大変機能が豊富であり、簡易な自社システムの開発にはうってつけです。
 

　システムの自社開発と聞いて何を連想されますか。中小企業では、おそらく「自社オリジナルの機能をシステム開発会社に依頼する」こととお考えでしょう。これが少し大きな会社になると、「自社のオリジナルの機能を自社システム部で開発する」となります。

　最近、アウトソーシングとして、いろいろな会社機能を外部委託出来るようになりました。情報システム部、特に開発部門は、最初に外出しのターゲットになっています。しかし、真に強い競争力を持つ会社は、そうではなさそうです。自社の競争力を最大限に生かすためには、自社の業務を熟知している社内の人間が開発するのが最良とわかっているからです。

　

　ＳＬＡ契約も無事に済み、いよいよシステム開発に着手します。あとは突き進むだけ！・・ちょっと待ってください。開発予算の見直しはできていますか？

　「だって、契約はすんだから開発費はわかってるよ」「変更の予算も見てるから、ある程度の仕様変更も大丈夫」とおっしゃるでしょう。
　はい、システム開発の依頼分はＯＫです。では、依頼していない自社部分はどうですか。

　

　前回までで、システム開発の契約完了まで説明しました。今回は、その後、つまり開発時のポイントについて述べます。そのために必要なのが開発版ＳＬＡ（サービス基準契約）です。

　契約といっても、この契約は前回述べた開発前の約束事項ではなく、開発中の約束を決めるものです。実際には、前回の契約と連続して行う場合が多いですが、これを中小企業で締結しているケースは非常に少ないと思います。以前紹介したリンク集にサンプルがありますので、詳しくはそれをご覧いただくとして、今日は契約のポイントをお話します。

　

　前回までにＲＦＰ発行、ベンダー選定までの説明をしました。

  私自身、ＲＦＰとまではいきませんが、システム計画書を策定して何社かのベンダーに見積依頼したことが何回かあります。その際、実績があり仕事を取りにこようとする会社は、必ず経験者を同席させるか知識のある営業を表に出してきます。また、こちらが依頼した以上のものを持ってくる場合が多いです。提示される予算はこちらの希望枠内か＋α程度ですから、こちらもその気になる場合が多いです。逆に、実績獲得のために低価格で提案してくるところもありますが、根拠をきちんと示さない社はあとで必ず追加予算を要求してくるものです。

　中小企業では、多くの場合、機能を満たせばよく、他社との差異化を求めるシステム開発は少ないものです。よって、パッケージをベースにいくつかのカスタマイズ、アドオンを行うことと業務手順を若干見直しすることで目的を達成するのですが、そこまで踏み込んだ提案をするベンダーは稀です。
　

　前回に引き続き、システム開発に必要な知識をお話します。前回は、ＩＴベンダーへの要求であるＲＦＰ(提案要求書)の作成までお話しました。今回は、ベンダーへの依頼と選び方についてです。

　「ベンダー？知らないよ」「どこに行けばわかるの？」という方も少なくないでしょう。
　

　前回の要件定義編では、要件定義する際に行うべき４つのことを書きました。

・画面イメージをつくる
・用語の定義
・利用者の特定と調整
・他システムとの整合性（会社の全体像を意識する）

しかし、これだけではＩＴベンダー（※ベンダーは日本語で売り手という意味）への情報がまだ不足しています。できれば、上記の４つ以外のものもまとめましょう。これらはＲＦＰと呼ばれ、ちゃんとした意味があるのです。

　ほとんどの中小企業では、システム開発を知り合いのＩＴベンダー（現行システム導入会社、知人経営等）に依頼するパターンが多いと思われます。しかし、本当に会社に合っているのか、低コストでできているのか。１社ではわかりません。ましてやＩＴは日進月歩ですから、知り合いの会社が追随しているかも判断できません。よって、複数のＩＴベンダーに見積りと提案書を出してもらうことが重要です。
　ところが、この依頼のために何度も同じ内容を説明するのでは大変ですし、口頭だと同じように伝えられない場合もあります。そこで、ＲＦＰをまとめるのです。

　

　前々回の成熟度の話、その前の業務プロセスの「見える化」において、システム開発や導入の前に行うべきこととその重要性について述べました。簡単におさらいすると、無駄な投資をしないためには無駄なシステムは作らないということ。そのためには

・今の業務手順は、本当に無駄がないのか（業務の「見える化」）
・今の従業員のレベルは、システムに対応できるのか（成熟度）

をしっかり把握しておくべきです。残念ながら多くの企業では、この前準備がほとんど出来ていないままに、開発に臨んでいます。また、システム開発会社（ＩＴベンダーとも呼ぶ）も、企業の要求を鵜呑みにするか、「今の予算では出来かねます」と突っぱねてオーソドックスな仕組みを提供します。つまり、企業要求
そのものがきちんと精査されることは非常に少ない状況になっているのです。

　結果的に、「こんなはずではなかった」「ＩＴベンダーが悪い」などと責任のなすり合いで、プログラマーが懸命に作ったシステムは、部屋の片隅に追いやられるのです。そこまではいかずとも、使わない機能がてんこ盛りで使いづらいとの話も多く聞きます。

　そこで重要なのが「要求定義」です。