中小企業情シス稼業

 ※このフェーズは長いので、3つに分けて書きます。


キックオフミーティングは、プロジェクト開始時、
・プロジェクトの目的
・スケジュール
・体制
・意思決定などの基本方針
を明らかにする場です。

できれば社内メンバーだけでも事前にやりたいところですが、ベンダーもキックオフをやりたがるので、2度集めるのは難しいかもしれません。


実際は、ベンダーとの顔合わせ的な意味合いになり、ぬるーい感じになります。

無理やり指名された社内メンバーはテンション低く、役員が形だけ顔を出す、のような雰囲気です。
次に役員が出席するのは、本稼動後の打ち上げの席となります(笑)


情シスとしてはこの機会を利用し、プロジェクトを進める上で伝えたいことや基本ルールを宣言します。

形だけだとしても、一応は役員がいるので、事前に内容を伝えておけば援護射撃してもらえるとは思いますが・・・


以下が情シスとして宣言しておきたい内容です。

システム開発の基本方針

仕様策定の間に何度か立ち返って確認することになりますので重要です。
プロジェクトの憲法的な位置づけです。

大体以下のような内容になるでしょう。

・現状業務の整理・見直し
    未利用、不要機能の削除
    機能の有効利用
    業務の質の向上

・導入コストの削減（限られた予算での更新）
    パッケージソフト標準機能の活用
    ※現行システム機能の全てが、そのままに新システムに移行されるわけではない


前半は教科書的なところなのでどうでも良くて(笑)、
後半が情シスの言いたいことです。（特に※印のところ）

各チームの役割

・業務フローの確認
・仕様確定
・テスト項目の作成
・テスト実施
・マニュアル作成
等の作業責任を持つ。


当たり前のことばかりなんですが、宣言しておかないと、全部情シスの仕事だと思われます。

打ち合わせ時のグランドルール

適当に集まって、適当に打ち合わせをしているだけでは、絶対にまとまりません。
打ち合わせをする際のルールが必要です。


・意見調整がつかない事項については、まず基本方針に立ち返って判断する。

・それでも意見調整がつかない場合は、プロジェクトオーナー（＝役員）による全社的視点での判断を仰ぐ

・時間厳守、話は簡潔・明瞭に

・建設的な意見を出す
    アイデアがないなら不平を言わない

・プランのない意見は進行の妨げになるので排除する
    ※プラン：QCD（Quality：品質、Cost：価格、Delivery：納期）を漏れなく満たしていること

・あるべき論の排除
     正論であるだけに議論が進まなくなります。
      「別の場を自分で設けて下さい」「このプロジェクト発足前に話し合うべき内容です」といなす。       「今は清濁併せ呑み、とにかくプロジェクトを少しでも前進させる時です」と言い切る。

・意見は皆がいる打合せの場で言う
     会議が終わってから情シスに個人的に「さっきのは実は・・・」という人が多いです。
     情シスが厄介ごとを抱え込まされることになるので、予防線を張ります。

・ベンダーに対して「強気に言う」＝「要望を言う」ではない
    全て開発コストに跳ね返るだけです。
    グレーゾーンをグレーのままで放置せず、先回りしてベンダーにぶつけ、
    こちらに有利な条件を勝ち取ることが強気と言うことです。

・欠席時の会議の委任
    欠席時は
    「会議に出られませんので○○さんに委任します、決定には従います」
    とプロジェクトリーダーに伝える。
   
    情シスが苦労してスケジュール調整しているのに
    「○月○日は予定があります」とだけ言ってくる人がいます。何が言いたいんだろう、と思います。
    先に代理を立てるか、素直にプロジェクトリーダーに委任して欲しい。
    大人なんだからそれをこちらに言わせるな、というところです。

    飲み会の日程調整でもいますよね。
    幹事の苦労を尻目に「○月○日はダメ、×月×日も予定あり」とだけ言う人が。
    そういう人に限って来ても来なくてもいい人だったりします。
    「私がNGの日でも構わずやってください。また次の機会に出席します。楽しんできてください」
    と先に幹事に伝えるの普通だと思います。プロジェクトでも同じです。



厳しいように見えますが、これらを守ってももらわないと、以降のフェーズがまともに進みません。
反感を買うのを覚悟で宣言してしまいましょう。

受け入れられないならプロジェクトリーダーを降りても良いと思います。どうせプロジェクト破綻してしまうので。



要するにキックオフミーティングで宣言しておきたいのは、
    「プロジェクトメンバーはお客さん感覚ではなく、当事者意識を持ってプロジェクトに参加しろ」
ということです。

---

上記の内容は事あるごとにしつこく言ったほうが良いです。

普段の仕事や会議でも大事なことだと思うのですが、何故かITの時だけ、明確に意識しなくてはいけないんですよね。


ちなみにグーグルでは以下のルールで会議を行うらしいです。
私はこれも参考資料としてキックオフミーティングで提示しました。

　・意志決定のための会議には、明確な意志決定者が参加すること。そうした者が参加できない場合、会議は行うべきではない。
　・意志決定のための会議は、10人以下の人数で行うこと。
　・意志決定のための会議では、すべての参加者がアイデアや意見を出すこと。意見のない者は参加するべきではないかもしれない。　
　・会議に参加する者は、必ず時間どおりにその場にいること。
　・意志決定が必要な場合は、会議の開催を待ってはいけない。意志決定の前に会議が必要ならば、すぐにでも会議を開催する必要がある。

要件定義フェーズは、プロジェクトの今後を左右します。最初が肝心です。

呼び名は、いろいろあると思います。要は開発の方向性や開発範囲を明らかにする作業です。

私は以下がポイントと考えています。

社内メンバーだけで先に打ち合わせをする

システムを発注するとベンダーは早く自分のペースで進めたいので、同席での打ち合わせをしたがります。
SEをアサインしているので、その稼働の都合があるのです。
要は遊ばせず働かせて、さっさと次のプロジェクトに投入しないといけないわけです。


そこを敢えてベンダーを入れず、社内メンバーだけで話し合うことが大事です。
「まず社内で方向性を決めたい」などと言って、ベンダーからの打ち合わせ要請を拒否します。


ベンダーがいると、その場でいろいろ質問できて、一見良さそうです。
が、彼らに話を振ると、画面のボタンをどうするなど、最初から細かい話に脱線しがちです。

客から振られた話をバッサリ切り捨てるわけにもいかないでしょうし。
情シスが「その辺で・・・」と話を元に戻すのも大変なのです。


現場のユーザ側にも問題があります。
新しいシステムを入れたくないので、わざと細かい話をする輩もいます。

画面や帳票の項目などの細かい内容は、次のフェーズで議論すべきです。


このフェーズでは
「○○の業務ルールは廃止すべきではないか」
「○○業務をもっとシンプルにできないか」
など業務中心の話をするべきです。

業務改善・コストダウンに大きくつながる話は、このフェーズでしかできません。非常に貴重な機会です。大事にすべきと思います。


ただ、大体時間に余裕がないですし、上記の通りベンダーからは早く打ち合わせをスタートさせて欲しい、とプレッシャーも来るので、なかなかゆっくりは話せないと思います。本来はもっと余裕のある段階で話しておくべきだと思います。ベンダーへの発注前に、普段から話し合っているのが理想です。


ベンダーに話を聞いてもらっても、彼らが決断をしてくれるわけではないです。最後に決めるのはこちらです。
その前提となる意思統一を社内で図っておく必要があるのです。

叩き台をもって臨む

打ち合わせをするときに、
「何か改善点を出してください」
「今のシステムの不満を自由に話してください」
というスタンスでは、思いつきで話をすることになるので、抜け・漏れが発生します。
議論も拡散し、まとまらなくなります。


打ち合わせをする際は、手ぶらではなく、必ず何か叩き台となるものを用意します。


具体的には、現行システムの業務フロー図を手に入れるのがベストです。

ベンダーも活用します。フロー図を持っているかもしれないので、もらいます。
古いものでも、何も無いよりは100倍良いです。何か基準になるものがないと効率よく議論できません。


このフロー図を元に現状の業務との差異をヒアリングします。ヒアリングした内容は、部署ごとに色分けして追記します。
以下のような感じになります。小さい図で申し訳ありません。
　　


私は前社では運良くPDFで手に入れられたので、1ページずつPowerPointに貼って、その上からヒアリング結果を追記しました。

※PDFを1ページずつJPEGに出力するには、フリーソフトのPDF-XChangeViewerが便利です。
https://www.vector.co.jp/soft/dl/winnt/writing/se492489.html
[ファイル]-[エクスポート]-[イメージへエクスポート]で出力できます。


フロー全体を俯瞰してチェックすることで、開発範囲の抜け・漏れを防ぎます。

差異・改善・要望をヒアリングし、漏れなく記録する

上記フロー図を見ながらヒアリングした内容は、漏れなく記録する必要があります。


発言してくれた人の顔を立てるのも大事です。
自分の言ったことが記録されていないと、次から話をしてくれなくなります。


記録の書式としては議事録形式ではなく、ヒアリングした内容をExcelシートにずらっと打つ表形式のほうが、後々に生かせる情報になると思います。

議事録は後から見づらいので、このフェーズでは無理に作らなくても良いと思います。
大きな会社で議事録を取る人を立てられるなら別ですが。


ヒアリングシートの書式は私は以下のようにしています。



いくつか項目を説明します。

■区分
ヒアリング内容の区分をします。

    【選択肢】
    ・差異：フロー図と現実の差異
    ・改善：現状非効率なところなど改善したい点
    ・要望：全く新しい要望


■関連部門
非常に重要な項目です。次フェーズで打ち合わせに呼ぶ部門を絞り込めます。

関係の無い部門を打ち合わせに呼ぶと、モチベーションが下がったり、議論が拡散しがちなので、それを予防できます。

「主管部署はどこだか知らないが、ウチも少し関係している」
「この業務は廃止したいが、どの部署に確認したら良いかわからない」
のようなケースも記録し、はっきりさせていきます。

ヒアリングシートはこまめに周知することになりますので、よくわからない場合は「○」をつけておいて、該当部門に本当に関連業務なのかを判断してもらいます。
間違っていれば「－」に修正すれば良いのです。

    【選択肢】
    ・◎：主管部門…業務的にメインとなる部門。仕様策定の決定権を持つ。その代わりテストの責任ももつ。
    ・○：関連部門…業務的に関わりを持つ部門。
    ・ー：関係なし


■ベンダー方向性
ヒアリングした内容を一度ベンダーに投げて、ベンダーの意見を確認します。

新しいバージョンのアプリだと、カスタマイズしなくても、標準で機能を持っている場合もあります。
それがわかれば議論の効率を上げることができます。

    【選択肢】
    ・標準機能利用
    ・運用で回避
    ・カスタマイズ
    ・何もしない


■方向性
ベンダーからの回答を踏まえた、このフェーズで決めたこちら側の方向性です。

詳細な打ち合わせが必要な場合は、「要社内打ち合わせ」「要ベンダー打ち合わせ」を選択します。

次のフェーズへの先送りのようになってしまうこともありますが、要検討のステータスとして認識できるようにしておきます。

    【選択肢】
    ・要社内打ち合わせ
    ・要ベンダー打ち合わせ
    ・標準機能利用
    ・運用で回避
    ・カスタマイズ
    ・何もしない


■実装する場合のメリット、実装しない場合のデメリット
強硬にカスタマイズを主張する人対策です。
予算オーバーの場合は、これを基に経営者に交渉しに行きます。経営者から錦の御旗をもらって、声の大きい現場の人を押さえつけます。
私は書いたことがありませんｗ




上記の項目や選択肢はまだ手探り状態です。これからもブラッシュアップしていきたいと思います。


ヒアリングはシステム利用各部門と最低1回は行います。

複数部門にまたがる業務で不明点が出た場合は、別途関連部門を集めた打ち合わせも必要です。
その際もこのヒアリングシートを見ながら行えば、無駄な時間を減らせます。


ヒアリングシートを更新したら、その都度メンバー全員に周知し、同意を得ます。

同意の意思をはっきり示さない人も多いので、
「同意の場合は返信不要。○月○日○○時までに意見なき場合は、同意したものとみなします」のように記載して周知します。
異論がある場合のみ返信させるのです。

異論がある場合はもちろん「全員に返信」させます。
こっそり情シス一人に「さっきの打ち合わせでは●●でしたが、本当は・・・」と送ってくるズルい人もいます。
打ち合わせできちんと話しているはずなので、この期に及んで異論などないはずです。
異論を言うのはだいたいがやりたくないからです。そういう人の心理的ハードルを上げます。

このフェーズでの頑張りが次のフェーズで生きる

このフェーズで頑張ると、以下のメリットがあります。

  ・開発の方向性について社内の意見がまとまりやすくなる。
  ・開発範囲の大きなズレがなくなるので、見積もり精度が上がる。
  ・成果物（追記したフロー図・ヒアリングシート）をベンダーに渡せば、次フェーズでの作業効率が上がる。ベンダーも助かる（はず）。
※前社にいたときベンダーは思いっきり利用していました。

---

ベンダーとの打ち合わせに入って、社内の人間同士で議論が紛糾することがよくあります。
あれをベンダーはものすごく冷ややかに見ています。「あーあ」という感じです。

ベンダーはパートナーですが、所詮他社の人です。こちらの混乱は相手を利するだけです。恥ずかしいところは見せないようにすることが大事です。

だからベンダーを入れず、最初に社内メンバーだけで話し合うことが必要なのです。
こちらが一枚岩できっちりやっていると、ベンダーも気が抜けなくなります。


あまりに話がまとまらない場合は、以降のスケジュールを延期するなど、経営者に相談することも大事な判断だと思います。

上で書きましたが、大きな方向性については、このフェーズでしか議論できないのです。後で莫大な開発費用を損するよりはマシでしょう（経営者が理解してくれるかが問題ですが）。


本当は、発注前に十分な時間を取りメンバーと何度も議論をして、意思統一を図っておきたいのですが、経営者には「コソコソやるな！プロジェクトとしてやれ！」と怒られます。
プロジェクトとしてやると、成果物や報告の義務が出てきてしまうし、ベンダーも絡んできてしまう。
そもそもITの問題ではなく、業務の問題なんですが。
このあたりも理解があると助かるのですがなかなか難しい・・・


次回は、ベンダーとの打ち合わせフェーズを見ていきます。

基幹システム導入、ベンダーが一番力を入れるところですね。金額が大きいですからね。


でもどうもベンダーとはペースが合わないんですよね。

何故合わないんだろうと考えると、フェーズ認識がユーザ側と違う気がします。

導入スケジュールというと、ベンダーは以下のような線を引いてきます。


 このスケジュールの実際を見てみましょう。

要件定義・基本設計

ユーザ側が、
「要件定義開始まで、まだ○週間ゆっくりできるな・・・」
「ベンダーはプロだから、全部お任せで大丈夫だな・・・」
と思うと、破綻の第一歩です。


中小企業を相手にするベンダーには、ユーザ側が望むような要件定義をする力はありません。
あっても要件定義ができる優秀なSEは中小企業にはアサインされません。

そもそも要件定義せず、いきなり基本設計するベンダーもいます。


「画面どうしますか」的な基本設計が始まります。
彼らは現状のシステムをベースに次のシステムを考えます。
加えてユーザからは、現状システムへのうらみつらみもこめた要望が上がってきます。

だから必ずコスト増になります。


膨らんだ開発費用の見積を見て、経営層からは「コストダウンしろ」と軽く言われます。
画面の項目をちょっと削ったり、帳票を数票廃止する程度では、焼け石に水です。

結果、無理やり機能を削るため、
ユーザにExcelでの手作業など、余計な運用を強いることになります。
「運用で回避」ってやつです。

このフェーズではユーザもまだ新システムでの運用がイメージできていないので、事の重大さに気づいていないです。


・新システムにユーザの要望を盛り込む → きちんと要件定義できている？
・最初から運用で回避 → きちんと実運用のイメージができている？

大きな爆弾が2つセットされた状態となりました。

開発

何とか要件定義・基本設計を終わったことにして(笑)、ベンダー側が開発作業に入ると、打ち合わせ頻度も減ります。
たまに仕様確認をされる程度になります。「プロにお任せ♪」ほっと一息です・・・


これが破綻に拍車をかけます。次のフェーズでしっぺ返しを食います。

前フェーズでユーザ同士の議論が紛糾しているような致命的な状況だと、
一息すらつけず、仕様策定しながら開発を行います。
当然仕様変更による手戻りも増えます。この時点で既に破綻していると言えます。

仮稼働

 「『仮』だからまだ余裕あるな」と思いますよね。そんなことはありません。

ベンダーは既にシステムは動いていると称し、プログラム開発遅れなど、前フェーズまでの自分たちの失敗を棚に上げて、検収を急かしてきます。

ユーザ側は開発されたプログラムに、仕様と違う点やバグがないかを短期間で確認しなければなりません。
　

確認するとなった場合、ユーザに「適当に触って確認してみてください」で済ませられるでしょうか。

無理ですよね。確認が不十分だと、以降のフェーズで「仕様と違う」「エラーが出る」が連発し、まともに運用できない羽目になります。


この期間は新旧システムの並行稼動がなされることが多いです。新旧両方のシステムへのデータ投入が行われ、データの突合せをし、本稼動できるか判断します。

要は二重入力を行うのです。ユーザは同じ伝票を2回打つことになります。この負担の大きさは想像に難くないでしょう。
通常は月次の確認ということで、1ヶ月程度の期間ですが、データの不一致が続くようですと、さらに二重入力期間が続くことになります。

この
・検収を非常に短期間で行わなければならない
・検収と同時に二重入力を行わなければならない
という事実をベンダーは最初の提案時に詳細に説明しないです。本当のことを言うと受注できないからでしょう。汚いですね。


更に本当ならこのフェーズで、マニュアル作成もしなくてはなりませんが、たいていは余力が無いので、「後で作ろう」となります。
こんな余裕の無い状態ですと、本稼動後もトラブルが続き、結局マニュアルがないままズルズル行ってしまいます。

マニュアルがないと異動等で新しい人が来ても正しい使い方がわからず、知識の継承が行われなくなります。
次第に「何故この処理をしているのか」をユーザ自身で説明できなくなります。
そうなると次のシステム更改時に、機能の費用対効果が判断できず、現状維持を選択せざるを得なくなります。
それにより開発コストが膨らみます。
被害がずっと続いていくのです・・・

その他に、マスタ移行・残データ移行など落とし穴はありますが、またの機会にお話します。
このままでもう十分破綻が見えていますから。

本稼働

上記のようなステップを踏んでくると、QCD（Quality：品質、Cost：費用、Delivery：納期）の1つ以上が破綻しているはずです。

本稼働できないです。とりあえず延期で先送りするくらいでしょうか。

皆さんご存じの失敗プロジェクトの状況です。
 

---

この記事の最初に貼った上の図は、ベンダーのためのスケジュールなんです。
ユーザ側の事情は考慮されていません。

ところがこういうスケジュールが書かれた提案書に、経営者も簡単に騙されてしまいます。
経営者にここを理解してもらうのが一番難しいです。


ではどう対処すべきか。
私は以下の図でスケジュールを考えています。


次回以降フェーズを1つ1つ見ていきます。