top of page
システム開発
システム開発は費用が高く、完成までに思ったより長い期間がかかる
そこにはProject Plan（業務改善計画）とExecution Plan(実行計画)の差を見極めないままに
Run(開発)に至ってしまう悲劇をお伝えしました。
もう一つの要因が「伝言ゲームの壁」です。
最短距離を最速で走るシステム開発には、余計な書類や設計書はありません。
なぜなら、関係者全員が同じ意識を持つチームがあるからです。
システム開発の落とし穴
その１ 伝言ゲームの壁
プロジェクトの規模が大きくなるにつれて、関係者・参画者は増えていきます。
ことシステム開発というと、必ずしも目に見えた成果物が出来上がらないケースもあり
なんだか高額な投資をして時間を割いたのに、最初にこちらから依頼した内容と違うものが出来上がってきたぞ。
というようなお叱りを頂戴する例も見てきました。
このページの冒頭に書きましたが、関係者・参画者が増えるほどにシステム開発現場では「伝言ゲーム」の壁が生まれます。
「情報システム部, A部長の指示はこれだ」
「営業部のB部長とは意見が違うような・・・・」
「たぶん、こういう意味で発言されたのかな・・？」
「あの会議の際に、たしかC専務がこう指示されていた」
「じゃあ、このプログラムソースでいいか」
このように、お客さま内での伝言ゲーム、システム開発者同士での伝言ゲーム、至る所で仮説が仮説を呼ぶスパイラルが生まれます。
その2 役割分担とは？
プロジェクトの規模が大きくなるにつれて、関係者・参画者は増えていきます。当然、それぞれの役割分担が必要になってきますが、「分担作業」と「チーム作業」を同じ意味で使用しているプロジェクトは、非常に危険です。
分担作業とは
「この作業はAさん、この作業はBさん」といったように、仕事をカタチで分けて進行します。
部署や係で分けたり、ここまでは営業担当の仕事、ここから先は技術担当の仕事というように職種で分けたりします。分担した仕事のそれぞれは、形式的なまとまりの状態で存在しています。
チーム作業とは
「この役目はAさん、この役目はBさん」と、仕事の役割の分担を行います。
役割で分担すると、それぞれが自己完結した単独のパーツでなく、お互いに有機的なつながりを持った状態で存在します。
どちらが良いという話ではなく、高度なシステム開発現場では、開発者はもちろん、お客さまにも役割を担っていただき、それぞれ「分担作業」と「チーム作業」を組み合わせます。この「分担作業」と「チーム作業」を称して「役割分担」という風に呼びますが、特に「チーム作業」について曖昧な分担をしてしまうと、後から開発修正の山になります。
その3 システム開発の目的は「業務デザイン」。
システム開発を進めていく中で陥りやすい最大の落とし穴です。
開発者側も依頼元のお客さまも、特に開発期間が長いほどに、システムの開発がゴールになってしまいます。
「当初想定よりも大きく時間超過してしまう」
「システム開発に追加の予算が必要になってしまった」
これらの最大の原因は、Project Plan（業務改善計画）を忘れ、Execution Plan(実行計画)ばかりに目をとられてしまうからです。
全体を俯瞰しながら、システム開発の現場ががゴールから逸れないように軌道修正しつつ、攻める時（開発・プログラミングする時）は一気に攻めて、短期決戦でコストを圧縮する。これが業務デザインであり、システム開発の方向だと考えます。
成功事例
弊社にシステム開発をお任せいただいた事例の一部をご紹介します。
現場の声から生まれた為替管理システム
■お客さまの課題
これまで電話とメールで回していた為替予約業務のシステム化したいお客さまからのご依頼。
「為替の予約は経験要素が強いから、すべてをシステム任せにはできんが・・・」
「為替の予約・決裁（決済）システムはいっぱいありすぎて、どれがいいんだか分からん」
「結局、エクセルで手作業が無難なんですよ」
「銀行とのやり取り（done）は相場を見ながら電話だから、消し込み作業が大変なんですよ」
つまり
ご依頼主の貿易部さまでは、何十年と同じ作法・手順化された業務に加えて、独自の「経験値」を組み合わせながら差益・差損を生じぬようにエクセルで管理台帳を作られ、日々、レートを睨んでいるものの、業務の効率化は図らないと、これ以上の取引拡大は難しいが、今までのオペレーションは極力変えたくない！というご依頼でした。
■解決のアプローチ
こちらのケースの場合、市販のパッケージソフトでは賄いきれない、「既存オペレーションを崩さないことが前提」にあり、必須条件でした。
そこでExecution Plan(実行計画)は「為替業務の効率化」となり
Run Control(開発管理)は「為替管理システムの構築」となりました。
為替管理というと範囲が広く、ビッグプロジェクトのようですが、本質的には業務効率化のためのシステム化です。完全に手順化された工程をIT化し、経験値で回す工程には一切触れない設計でRun（開発）に入りました。
■納期
システムに求められているポイントは、端的に言うと
・銀行含むコミュニケーションの円滑化を図る事。
・作業履歴をデータベース化すること。
この2点でした。（実際にはもっと細かい要求はたくさんありましたが。）
このように整理すると、なるほど。市販の為替ソフトで実現したいこととは大きくかけ離れていることが分かります。
業務の分析から新しいシステムの導入（プロジェクト完了）まで、4.5ヶ月で完了しました。
■プロジェクト管理のポイント（成功への分岐点）
このページの冒頭にも書きました「チームワーク」＝「役割分担」が、非常に円滑に動いたケースです。プログラミングや画面開発は「開発側の分担作業」、「業務上の影響範囲」や「どこまでをITで担うかを決めるのはお客様とのチーム作業」といった風に、作業分担とチーム作業が有機的に作用したことが最大の要因でした。
■費用・効果
非公開
※当初お客想定の開発予算比80％,納期予定通りで完了しました。
■使用した環境
お客さまご利用の物理サーバ, salesforce.com Platforlm, EAI設定,VBA
20ヶ月のBig Project! 電子申請システムの構築
■お客さまの課題
お客さまのセクションで大規模に利用できるミドルウェアの導入
これまで何種類もの業務申請や書類作成を実施していた業務プロセス。
これらのプロセス自体のスリム化を、IT支援頂きたいというご依頼でした。
「Aの工程が完了した事を確認し、Bの工程に進むというルールの、けん制機能が必要だ」
「Aの工程開始時に必要な申請書類とBの工程を開始する際に必要な申請書類が個々に必要」
「Bの工程が、どこまで進んでいるか、Aの関係者は知る術がない」
つまり
ご依頼主の経営管理部さまでは、ガバナンスやコンプライアンスを重視しつつも、現場の作業改善を求められており、かつ、全体俯瞰できる仕組みを作りたい
というご依頼でした。
■解決のアプローチ
こちらのケースの場合、「改善」というよりも「改革」の要素が強く、IT主体ではなく業務主体の長期ビッグプロジェクトです。
ポイントは、「事前Project planの共有と、ガバナンスの強化」でした。
ここで重要な点は、解決までのアプローチです。
①プロジェクトマネジャーとして、最適なゴールを設計し、お客さまと合意を得ること。
②今ない価値（Value）
例えば、今以上にガバナンスを強化しなければならないといった「must」や「more」といった要素
は、現場作業工数の削減ではなく、追加になる事もある点を理解頂くこと。
③その上で、ITによる効率化支援とエビデンス管理体制の強化案を複数ご提案し、ROI（投資対効果）
に優れた案と納期を、お客さまと合意を得ること。
このように３ステップを踏むことで、システム開発の領域を決めつつ、全体のアーキテクチャ（設計図の作成）と、業務・工程に応じた最適化のためのプログラミングの検討に入れます。
Run Control(開発管理)は「為替管理システムの構築」となりました。
為替管理というと範囲が広く、ビッグプロジェクトのようですが、本質的には業務効率化のためのシステム化です。完全に手順化された工程をIT化し、経験値で回す工程には一切触れない設計でRun（開発）に入りました。上記にも書きました3つの落とし穴すべてに気を配る、大変な、それでいてとても勉強になるご依頼でした。
■納期 このようなビッグプロジェクトの場合、Execution Plan（実行計画）自体を、複数準備します。
①全体俯瞰するための基盤作り（いわゆるサーバの設計です。）のタスク
②①の基盤作りタスクが予定通り進む前提で、アプリケーションの開発計画を複数同時に行います。
③納期に関しては、いわゆる「段階的リリース」となります。つまり
全体を支える基盤の納品
基盤上で動くアプリケーションを支えるミドルウェアの納品
ミドルウェア上で動くアプリケーションの納品
といった形で、当初設計の全てを問題なく稼働させるまでには、実に20か月以上を要しました。
■プロジェクト管理のポイント（成功への分岐点）
文中にも書きましたが、プロジェクトの規模が大きくなればなるほど、3つの落とし穴に気を配る必要があります。特に「役割分担」については、個々がプロ意識を持って取り掛からないと、全体に影響が出てしまいます。成功への分岐点は、システム開発会社だけでなく、お客さまにも当事者意識を持って参画頂いたことが最も大きな要素です。
加えて、システム的な成功への分岐点で言えば
（かなり無理をしましたが）アプリケーションの複数同時開発をやり遂げた。という点が大きな要素になっています。
例えば
「Aという業務に関するシステム化」と
「Bという業務に関するシステム化」という2つの案件
同時に開発する事自体は、なにも難しくありません。それぞれ独立したアプリケーションとして開発・納品すれば良い訳です。
しかしながら今回の場合は、「全体の工程管理」と「部分最適化」を同時に改善・改革したい！
というのがお客さまのニーズです。
よって
個々の業務に対しIT支援をするのではなく
全体設計に基づきながら
「Aの工程開始時の申請業務もBの工程開始時の申請業務も同じレベル感で改善したい」や
「全体俯瞰した際に、なぜ遅れているのか？や全体工程上のボトルネックはどこか？」といった
複合的な要素を個々のアプリケーション開発時に意識する必要がありました。
プログラミング言語の統一はもちろん、コーディングの仕方やデータ構造、正確に大量のジョブを処理させながら、日々の業務には全く支障をきたさないバッチ処理など。。。。
思い出すだけでも気が滅入りそうな仕事でした。。。
しかし、その甲斐あって、システム稼働後のエラー検知や軽微な改修、あるいは機能の追加など、いわゆるランニングコストについては劇的に圧縮することができました。
■費用・効果
非公開(億単位のビッグプロジェクトでした)
※当初お客想定の開発予算100.3％,納期予定通りで完了しました。
■使用した環境
お客さまご利用の物理サーバ, 仮想サーバ,⇒salesforce platformに統合
サブシステム７個とのEAI連携
新規アプリケーション作成数12（salesforce API,Web<css>,バックアップ環境含む）
bottom of page