このエントリーをはてなブックマークに追加LINEで送る

3.3. 開発側

ハッピィ・エンジニアリング表紙

 過去のシステム開発では、効率化・生産性の向上の観点でシステム化が行われたため、経営層からは効率化・自動化・省力化による人件費削減をはじめとするコストダウンが実現できれば喜ばれた。また、エンドユーザからは使いやすいシステムであれば喜ばれた。

 

 しかし、現在のシステム開発は、中・長期的な経営戦略から、それを実現するための事業戦略へ、そして事業戦略を実現するために行われる。生産性を向上するための機能を持ち、エンドユーザにとって操作性のよいシステムを提供すればそれでよかった時代は終わった。今、システム投資の重要な判断基準となるのは、そのうえでさらに経営戦略が具現化されたシステムかどうかである。その結果、事業戦略をシステムとして具体化するために、一般的なビジネスマンが話す言葉を理解できる人材が開発側にも広く求められている。

 

 ビジネスシステムの開発にあたっては、要件定義から設計・プログラミングに至るまで、無数の判断、意思決定がなされる。その大部分は「承認手続き」という形で、最終的に発注側が行うことになる。ただし、開発側がその業務の背景や前提にある考え方を知っているか否かで、設計作業の効率や成果物の精度は著しく異なる。

 

 例えば、近年コンプライアンス(Compliance:企業が法令・経営倫理・社会的な規範を守り、社会からの信頼を得ること)が非常に重視されているが、コンプライアンスという概念を知らなければ、設計作業に大きく影響を及ぼす。個別の業界についての常識的な知識の欠如も影響は大きい。発注側の業種が物流に関係するならば、当然、技術者には3PL(3rd Party Logistics:企業の物流業務全体をアウトソーシングするサービス)の概念ぐらいわきまえていてほしいと思っている。しかし今の開発現場では、上場クラスのSIベンダであるにもかかわらず、企業会計原則もろくに知らない自称SEが大企業の経理システムの開発で無知丸出しの設計を行い、発注側を激怒させた多数の実例があるというのが実態である。

 

 ところが、開発側は、元請け・下請け・ツールベンダによらず、常識的な経営戦略について学習をせず、個々のシステムという各論・詳細のレベルでしか考えることができない。ゼネコン構造により自分自身のポジションが決まりきってしまうことが、学習しない大きな原因のように感じられる。悪い意味での職人根性から、そこに踏み込もうとしていないようにも見受けられる。

 

 もちろん同情の余地はある。業務の「におい」が感じられるのは、せいぜい詳細設計程度まで、企業戦略となると、それを多少なりとも実感できるのは、基本設計段階がいいところだろう。プログラム設計以降の下流工程の作業ばかり繰り返していると、目先の開発環境や各種ツールだけに関心が集中してしまいがちである。ただ、そうなると、これはもう悪循環である。経営という観点からシステムを語ることのできない技術者を、発注側はカウンターパートとして求めることはしない。プログラマ以前の単なるコーダとして接するにとどまる。

 

 さて、このような現状では、SIベンダに戦略性を求めるのは無理である。しかし、それにもかかわらず提案型営業などという本末転倒の進め方が行われているため、ソリューションという名称で同業他社のシステム構造がパッケージングされた提案書がまかりとおっているのである。元請けとなるSIベンダには、これからの競争に向けて、経営戦略をふまえた判断ができる人材の育成が必要不可欠となるだろう。

 

営業

● 元請け営業

 

 前述したとおり、日本のユーザ企業の企画部門には企画力がない。そのため、受託開発型のビジネスにおいて日本のビジネスをリードしてきたともいえるのが、元請けとなるSIベンダの営業マンである。彼らが提案書に記した「ソリューション」こそが、日本のシステムの姿そのものである。彼らが行ってきたシステム提案活動がなければ、日本の事業会社が多くのシステムを利用する環境を持つことができなかったのも事実である。

 

 元請け営業の学習の基本は「耳学問」である。そこそこの能力がある営業マンが、ある業界を3社も回れば、その業界が抱えている共通の問題点を把握できる。場合によっては、解決策すら教えてもらえるだろう。

 

 SIベンダの提案書は、まったく表面的な理解(場合によっては誤解)と、他社に導入したシステム事例に基づいているが、それなりの戦略性を持っている。しかし、それは、表面的な浅薄な理解によるものにすぎない。

 

 ユーザ企業側では、日本国内のみならず、常に他社動向に目を光らせ、その業界がどのような動きになっているかについて、統計情報を含め十分に把握している。業界内部にいるのと、システム屋としてその業界を見ているのでは、その知識や本質的な問題のとらえ方の差は歴然となる。システム屋の知識では、問題が詳細なレベルになったときに、根本的な正しい解決策を導くのは不可能であると言わざるを得ない。

 

 しかし、ユーザ企業内では、正しく問題点を把握し、効果的な解決策を考えついたとしても、それをシステム実装にまで持っていくには、まったく別個の能力(社内の根回し、説得などなど)が必要となる。その意味でも、SIベンダの提案書というのは効果のある「ソリューション」のひとつであった。

 

 ところが、現在のシステム開発は、競争優位性を確保するために、経営戦略に立脚することが中心となる。そして、元請けのSIベンダは、企業の根幹となるシステム全体のアーキテクチャを決定する立場にはない。実態としては、ITガバナンスを失い、システム・アーキテクチャすらSIベンダに依存している企業は少なくない。しかし、それらの企業は、そもそも経営陣やシステム部門が果たすべき役割を果たしていないのであり、本来の姿を失っている。あくまで原理原則に従えば、「企業の根幹となるシステム全体のアーキテクチャ」はその企業自体が決定するものである。

 

 経営戦略に基づいたシステム開発の主導権を持つのは、あくまでもユーザ企業であり、経営戦略に基づいたシステムはROIの評価が難しいという点から見ても、システム駆動型の「ソリューション営業」などあり得ない。

 

 SIベンダに求められていることは、ユーザ企業の要件に基づいたシステム開発である。ITガバナンスを意識し始めたユーザ企業が、元請けの営業マンに求めていることは、RFPに対する最適解を提案することである。要求をシステムモデルに置き換えること、すなわち、WhatをHowに適切に変えていく提案が求められている。

 

● 下請け営業

 

 ボリューム勝負で開発現場に技術者をアサインするのが下請け営業、あるいは案件ブローカの仕事である。抱えている技術者の仕事が空かないように、スキルシートにひと山いくらの値段を付けて配って歩くことが、その仕事である。自分が扱う「商品」である技術者がどのようなスキルを持っているのか、どのような人間性なのか、などについて知っていることはほとんどないといって過言ではない。まさにひと山いくらで売るのである。

 

 ただし、技術者をアサインした責任は残るため、技術者の勤怠が悪かったり、成果が出なかったりすると今後の取引に大きく影響する、というリスクも同時に背負っている。そのため、年功のある人間が管理職として営業に回ることが多い。

 

 元請け側が技術者を判断する基準は時期により変化している。一時期は、情報処理技術者の認定資格を持っているかどうかが重視された。その後、業務知識の有無を重視した時期を経て、現在では過去の経験による保有スキルを重視する傾向にある。

 

 しかし、アサインした技術者が仕事のできる人材かどうかは、実際の業務に就いて初めて評価できることであり、スキルシートから判断するのは現実的に不可能である。つまり、技術者採用の判断基準の変化は、それぞれの基準をもってしてもハズレをつかまされてきたことからくる防衛反応である。判断基準については、いまだに決め手を欠く。

 

 下請け営業は、実質的な価値をなんら作り出さないことから、元請けが見いだせる価値は低い。手配師や奴隷商人などと差別的に評されるゆえんである。しかし、元請けの立場に立つと、手配師が紹介してきた者が使いものにならなければクレームを入れて差し替えてもらえば済み、責任問題も生じず、契約ベースでビジネスライクに扱えるというメリットがある。

 

 元請けから見た場合、技術者のアサイン方法として一番有効なのは、信頼できる人からの紹介である。しかし、これは紹介する側、紹介を受ける側双方に、それなりのリスクが発生する。

 

 アサインした技術者が「(元請けの)担当者Aさんが(下請けのBさんの紹介で)採用した技術者のCさん」ということになった場合、Cさんが相応の成果を出せないとAさんの評価に影響する。簡単にいうと社内での立場が悪くなる。このようなときは、Bさんには何も言わず、よほどのことがない限りは契約期間が終わるまではCさんを使い続ける。しかし、その後にはAさんはBさんとは距離を置くことになる。

 

 Aさんからすれば「いいかげんなやつを紹介しやがって」ということになるが、Bさんからすると、自分自身は悪くないのに、知らず知らずのうちに疎遠にされてしまう。どちらの立場であっても、このようなことを何度か経験すると、人の紹介に恐れを抱く人が出てくる。手配師の存在理由は、このような点にもある。

 

 結局は、技術者が開発現場でどれだけ能力を発揮しプロジェクトに寄与したか、という結果によってのみ下請け営業の存在価値が発生すると言える。

 

開発

 開発において特筆すべきことは、日本ではプロジェクトマネージャとプロジェクトリーダの役割の区別はあいまいで、共通認識が存在しないということである。

 

 日本では、ITガバナンス復権を目指している一部企業を除けば、ほとんどの企業がシステムをSIベンダに丸投げしているため、プロジェクトマネジメントのほとんどが元請けにゆだねられている。さらに、元請けのプロジェクトマネージャは発注側との交渉だけ、プロジェクトリーダは要員のアサインだけしかやっていないに等しい。

 

 両者ともに本来果たすべき役割をまったく果たしておらず、管理者不在の状態である。実質的には下請けがなんとか動くシステムを開発したにすぎない。当然、下請けにも管理の概念などは存在せず、「プログラムが動けばよい」という考えがあるのみである。

 

 元請けは、下請けに丸投げすることで責任を放棄している。だから、それぞれが本来やるべき仕事の像が見えなくなっている。しかし、大半のプロジェクトマネージャとプロジェクトリーダにはその自覚すらない。

 

 その一方で、プロジェクトマネージャとプロジェクトリーダの役割に関する一般的な考え方はほとんど存在しないことが、さらに両者の役割を不明確にしている。ITSSの中ですら、プロジェクトマネージャとプロジェクトリーダの役割は区別されておらず、プロジェクトリーダはプロジェクトマネージャの知識体系の中に包含されている。明確な役割分担の規定もなく、知識体系として分離していないにもかかわらず、現場ではプロジェクトマネージャとプロジェクトリーダが置かれている。

 

 プロジェクトリーダとプロジェクトマネージャの活動が相互作用を生み、また相互にそれぞれの業務に対して牽制可能な状態を作ることが、プロジェクトマネジメントを考えるうえで重要な点である。この観点で両者の役割を考えた場合、PDCAサイクルにより役割を分担することが望ましい。

 

 PDCAサイクルとは、ISO9000やISO14000などのマネジメントシステムに取り入れられているマネジメント手法である。PDCAサイクルは、計画を立て(Plan)、その計画を実行し(Do)、実行結果を評価し(Check)、実行と結果に対して改善(Action)していくプロセス改善のためのサイクルである。改善策を計画にフィードバックしていき、品質の維持と向上、業務プロセスの改善などをスパイラルに継続することが目的である。

 

Plan、Check → プロジェクトマネージャ
Do、Action → プロジェクトリーダ

 

 プロジェクトマネージャはプロジェクト全体、あるいは工程ごとの計画の立案を行い、プロジェクトリーダがその計画を実施する。計画に不備があると、実施に支障をきたすので、リーダはマネージャの作った計画を十分にレビューすることが必要となる。プロジェクトマネージャは実施結果を評価し、その評価を基に、プロジェクトリーダはさらなる改善策を講じる。これがプロジェクトマネジメントをプロジェクトマネージャとプロジェクトリーダに分けるうえでの理想的な姿である。

 

● プロジェクトマネージャ

 ユーザ企業の視点では、元請けのプロジェクトマネージャは、SIベンダそのものである。ユーザ企業と対峙している担当者として、自社への評価を背負っていると言ってよいだろう。プロジェクトマネージャがきちんとプロジェクトを運営し、きちんとしたシステムを納品できなかった場合、顧客は往々にして「あの会社はまともなシステムを作れない」という評価を下すことになる。

 

 単なるシステム開発プロジェクトとして見た場合でも、あるいはユーザ企業まで含めたIPTとして見た場合でも、その役割が大きいことに変わりはない。ユーザ企業のユーザ部門・システム部門と多くの関わりを持ち、顧客まで含めたプロジェクト全体の調整、リスクを見越した作業見積もりと計画、開発チームに対するマネジメントなど、多くの重要な役割がプロジェクトマネージャに集中する。

 

 しかし、現実的にはプロジェクトマネジメントはKKD(経験、勘、度胸)などと称されるように、今までのプロジェクトマネジメントに確実性はまったくなく、単なる経験則のうえでなんとなくうまくいったにすぎない。ただし、なんとなくうまくいったのは、一次下請けに丸投げし、連鎖した下請けのSE、プログラマの力量があったからという重要な側面がある。一括受注した一次下請けが受注者としての責任を果たすことさえ可能であれば、丸投げしている元請けのプロジェクトマネジメントに対する期待など誰もする必要はない。まともなマネジメントができないプロジェクトマネージャが中途半端にプロジェクトに介入することは、プロジェクトメンバの邪魔になるだけである。

 

 さて、多くのプロジェクトでは、受注金額が先に決まり、要求仕様が漠然としか定まらない状態の中でスタートする。だからこそ、工程が進んでからの仕様変更や要件の追加をなんとか避けたいがために、開発側は「顧客に同じ船に乗ってもらうことが成功の鍵だ」という理論を展開する。しかし、ほとんどの場合、その要求が企業の経営戦略上必要不可欠な内容なのか、それとも担当者の趣味的なものなのか、優先順位を下げて対応が可能なのか、という判断がなされることはない。そこには、開発側の被害者意識のみが存在し、本質的に顧客への要求に応えて高いサービスレベルを実現するために顧客とともに考えていく、という姿勢は感じられない。

 

 ただし、商慣習が欧米のように厳格な契約を順守するスタイルではなく、落としどころを見つけて合意する形であることや、システム開発全般をユーザ企業から丸投げされている現状においては、理想論をそのままに展開するのには無理がある。

 

 工程が進むに従い、ユーザ企業のシステム部門から丸投げされたあいまいな要件が、機能の追加や仕様の変更を生む。そのまますべてを受け入れていたとしたら、プロジェクトの予算がいくら潤沢にあったとしても、利益を食いつぶしてしまうことは明らかである。スコープ管理の教科書通りにユーザに優先順位をつけてもらい調整を行う場面だが、それが日本ではほとんどうまくいかない。交渉相手の調整能力が低ければ、順位づけなどそもそも不可能である。そのうえ、丸投げが当然のユーザ企業の担当者は、優先順位づけなどという行為に慣れていないため、「全部必要な機能だ!」と言い放ったり、全体の要件の9割に「優先順位:高」をつけたりする。

 

 逆に交渉慣れした相手だと、最初から手の内を明かすようなことはせず、どうしても通したい要求のほかに「譲歩用」、つまり「俺もこれはあきらめるから、これは頼む」といった駆け引きに使うための機能要件を積んでいることがある。どちらにせよ、現実的に優先順位づけはあまり効果が期待できないのである。

 

 つまり、現状においては元請けのプロジェクトマネージャが所属する企業から求められていることは、自社の利益を最優先に考え、ユーザ企業とのネゴシエータになることである。プロジェクトチームという集団のリーダとして、あるいは技術者として、はなはだ頼りない人間でもシステム仕様の交渉の場では本当にタフな交渉者となる必要がある。ネゴシエータとして、ユーザ企業のシステム担当者と十分にミーティングを重ね、そして言葉の端々から伝わってくるニュアンスで、交渉相手が腹の中で望んでいることは何なのかを引き出すのである。そして、引き出した内容からどこに落としどころを見つけるか、という合意形成を行う。

 

 ただし、ユーザが望んでいることを把握しても、それを全部実現するわけではない。コスト・納期のソロバン勘定はもちろんのこと、この相手はどこまでなら妥協するか、あるいは強硬に臨んでくるかを見極める必要がある。交渉相手が誰かによって、プロジェクトマネージャは異なる反応をする。ユーザ企業の経営層から言われたのと、ひとりのエンドユーザから言われたのでは、当然妥協するラインを引く場所が変わる。さらに、交渉相手に対して「どこまで貸し借りが通用するか」も計算に入れる。

 

 相手が借りを返してくれる相手なら、恩を売る手もある。逆にそういう感覚のない相手なら、かたくなに仕様追加を否定する。交渉ごとは決して一筋縄でいくものではなく、このような腹芸ができないと、日本のシステム開発の現場ではプロジェクトマネージャはつとまらないのである。

 

 これがプロジェクトマネージャの現実である。しかし、これはプロジェクト管理のあるべき姿から遠く離れたものであることは明らかであろう。経営者が決定した経営戦略、そこから発生するシステム戦略、そういうものを一切無視して、現場の人間の駆け引きでシステムの姿が決まっていくのである。PMBOKの体系に立ち戻るまでもなく、プロジェクトマネージャが果たすべきプロジェクト管理の項目は多数ある。それらをろくに行わず、ソロバン勘定で駆け引きをするのが、プロジェクトマネージャのあるべき姿であるはずはない。

 

 上述したようなネゴシエータの観点からプロジェクトマネジメントを説く本を、目にしたことがあるだろう。しかし、現在では下請けの業務遂行能力が下がり、下請けに丸投げしても顧客の納期・品質に対する要求を満足させたシステムが完成する可能性が著しく下がっている。また逆に、ユーザ企業の品質・コスト・納期に関する要求水準は著しく上がっている。そのため、ユーザ企業からは単なるネゴシエータとしてのみならず、経験・勘・度胸・見よう見まねのプロジェクトマネジメントから、プロジェクトの状況が可視化されたプロジェクトマネジメントスタイルの転換が強く求められている。

 

 元請けとなるSIベンダは、プロジェクトマネージャに求められていることが、QCDというプロジェクトへの要求に応えプロジェクトをコントロールすることにほかならないということを、あらためて認識する必要があるだろう。プロジェクトの全体計画や戦略を固め、プロジェクトメンバに周知徹底し、しかるべきマネジメントを行っていくことが、元請けの競争力のひとつである。

 

● プロジェクトリーダ

 プロジェクトマネージャと開発メンバとの間のパイプ役として機能するのがプロジェクトリーダである。また、プロジェクトメンバの業務がスムーズに進むようにサポートすることも大きな役割のひとつである。具体的に行う業務は以下のようなものになるだろう。

 

  • プロジェクトマネージャが決定した計画の実施
  • 実施プロセスの管理
  • 作業中の課題に対する解決策の検討
  • チーム内で完結しない課題の関係者への引き継ぎ
  • 各サブチームの進捗状況のフォローアップ
  • 反省点、改善点の洗い出し

 

 また、プロジェクトの開始時点では、プロジェクトリーダには、それぞれのチームへのプロジェクトメンバのアサイン能力が求められている。

 

 実際のプロジェクトをコントロールすることが難しくなっている一因として、経験・勘・度胸のプロジェクトマネジメントによって、開発者であるSEやプログラマは、それぞれがその場しのぎに勝手に仕事を進めていくことが習慣化しているという側面がある。

 

 このようなコントロールしにくい状態を回避するには、適切なスキルを持った人間を必要なだけアサインすることが鍵となる。つまり、システム基盤であれば、データベースやネットワークなどの技術領域ごとに、アプリケーションであれば、それぞれのサブシステム・機能・利用技術ごとに、人を集め、適切なチームにアサインするのである。

 

● 設計者(システムアナリスト、システムエンジニア)

 たいていの場合、システムアナリスト、システムエンジニアとして基本設計に関わるのは、プロジェクト参加者の中で元請けに一番近い位置にいる技術者である。設計者として重要な仕事は、顧客の要求を分析しシステムモデルに置き換える作業と、基本設計書通りのシステムになっているかを検証する作業の実施である。

 

 設計者は、必要とされる知識が非常に多く、継続した学習の必要性が強く求められている。学習の対象となるものには、顧客の業務、開発方法論などのソフトウェア工学、ネットワークやシステムの方式、インフラ面などのアーキテクチャ、データ構造やアルゴリズムなどプログラミングに関することまで多岐にわたる。また、成果物として残すもののほとんどが仕様書や設計書となるため、論理的で一貫性のある日本語の記述スキルが非常に重要である。

 

 現実に目を向ければ、これだけ広範囲にわたるスキルを持ち合わせたシステムアナリストやシステムエンジニアはほとんど存在しないにもかかわらず、システムは完成する。結局は、同じような仕事を何度も繰り返していることで、「学習効果」をもたらすのである。だから、ろくに学習しなくても、かろうじて動くシステムを開発することは可能である。しかし、それゆえに、自分の狭い守備範囲を超えたときは、もはや無力である。

 

 当事者たちは、自分が無力であることを認めたくない。そこで、自分の守備範囲以外のことを低く見ることで、自分の守備範囲の仕事、そして自分自身に価値があると主張しているのである。時代の流れとともに、この枠組みからこぼれ落ちると悲惨である。よい例がCOBOLプログラマである。彼らの業務知識やスキルは評価に値するものだが、実装の核にあるCOBOLが否定されてしまうとまったく自信を喪失してしまう。

 

 設計に関わる者は、学習しなければならないものが膨大にあるということを認識し、学習を継続する意思を持たなければならない。すべての学習分野の専門家になる必要はないが、基本的な知識を身につけ、時代とともに消えてなくならないように努力すべきであろう。

 

● プログラマ

 プログラマの主な作業範囲は、詳細設計〜プログラミング〜単体テスト〜結合テストである。テスト要員としてシステムテストに関わることも一般的である。

 

 プログラマの現状は、有象無象・玉石混交である。しかし、最近は元請け・下請けのゼネコン構造の中で、プログラマの力量の差があまりなくなってきたように感じられる。これは、プログラマの技術習熟曲線が原因だと考えることができる。

 

 プログラミングをゼロから始めたとして、最初の1〜2年は急激に力をつけていくが、そこからは単に同じことの繰り返しで技術力の伸びが頭打ちになっていく。以前ならプログラマを数年経験すれば、プログラマ卒業となるのが当然であったが、今は「生涯一プログラマ」なので、頭打ちレベルのプログラマがごろごろいる状況になっている。そうすると、プログラマの技術力は、(低いレベルかもしれないが)狭い幅の中で収まっていることになる。したがって、均質でひと山いくらというプログラマ市場が形成されてきても不思議ではない。

 

 プログラマには、ゼネコン体質、もしくは下請け根性による「言われたことだけやる」「その場しのぎ」の考え方が横行している。プロジェクトへの帰属意識の希薄さが周囲に与える悪影響には、見すごせないものがある。しかし、わけのわからない、謎だらけの「仕様書めいた」ペーパーからものづくりをする仕事では、単なるボリューム勝負のやっつけ仕事にならざるを得ない。

 

 謎の仕様書でプログラムが開発できない場合は、まだ救いがある。質問して仕様を明確にせざるを得ないからだ。しかし、謎の仕様書でとりあえずプログラムが書けてしまう場合はタチが悪い。日本においては、仕様の不備の指摘はプログラマの仕事となる。中国やインドのオフショア開発の黎明期には、「インド人や中国人は仕様書通りにそのまま作るからダメだ」という見当外れな論調があったほどである。現在では、このような背景を経た結果として、設計の軽視が当然のこととなっている。正しく設計されていたとしても、自分自身の勝手な解釈による、設計と相違したコーディングが横行している。

 

 開発会社自体も、「ひと山いくら」で薄利多売のボリューム勝負が板についてくる。価格面での競争が熾烈で、技術者教育を行うコストがないうえに、企業価値の創出すらできず、人材の流動性は非常に高い。これを回避するには、企業としての価値の創出と、その価値を評価できるよい顧客が必要であることはいうまでもない。

 

周辺にいる人々

● 運用担当

 

 運用担当者なくして、企業のシステムが動くことはない。開発のみならず、運用の世界にもITILに代表されるライフサイクルサポートの概念が取り上げられ始め、システム運用の重要性が再認識されている。常にシステム運用の扱いは地味だが、企業の根幹となるシステムを支えている重要かつ責任の大きな役割を持っている。

 

 システム運用は、本番稼働しているシステムに対するさまざまな作業のすべてを行う業務である。その作業内容は定常的なオペレーション業務や障害への対応だけにとどまらず、以下のように多岐にわたる。

 

  • 運用の中・長期/単年度計画の策定
  • セキュリティ管理
  • 運用基準の策定
  • 新システムの開発に対する支援作業
  • 保守対象となるシステムに対する支援作業

 

 システムの停止が社会的に大きな影響を与える昨今、これらの業務の中で特に重要視されるものがセキュリティ管理である。最近のシステム監査業界でも顧客からの要請によりセキュリティに対するさまざまな取り組みが行われていることが表すように、ユーザ企業の経営陣が運用セクションに最も大きな期待を寄せていることでもある。

 

 今やシステムの障害は、単なる機会損失となるだけではなく、顧客サービスの低下、社会的信用の低下など、企業に多くの影響を与える。つまり、セキュリティというと難しそうに感じられるが、安全かつ安定してシステムを継続的に運用していくことが、今まで以上に求められているのである。

 

 天災や人災による業務停止を避けるための工夫、不正侵入や持ち出しなどによる情報の盗難や改竄の防止、ウイルスによる被害の防止など、可用性・機密性・保全性を維持し続けなければならない。

 

 被災時のBCP(Business Continuity Plan:業務継続計画)の策定は、米国の同時多発テロ以降、日本でも普及しつつある。BCPとは、なんらかの大きな影響のある不慮の事態が発生したとしても、できる限り業務を継続し、また業務停止した場合にも、極力短時間で通常業務に戻ることが可能な仕組みを作ることである。長期的な観点で考えた場合、たとえ大きな災害が発生した場合でも、事業を継続し顧客へのサービスを提供し続けることで、顧客の信頼を得ることができるという発想がある。災害時の損害額の試算、ビジネ
スに与える影響、業務リカバリプランの策定、運用設備や体制の整備などを行い、災害対策をしていくことになる。ところが、災害時の被害を試算するのは不可能であり、その計算が正しかったかどうかは結果が証明する以外にはないという大変皮肉な側面がある。とはいえ、公共・通信・金融など、社会活動の基盤となっているような事業では、災害に対する事前対策は必要不可欠である。

 

 一般的なセキュリティ対策の対象となるものとして、物理的な設備、システムのリソース、文書などが挙げられる。物理的な設備に対するセキュリティ対策とは、システム関連設備を設置している場所が、耐震・免震・耐火対策された設備となっているか、出入りに対する監視が行われているか、などである。システムのリソースに対するセキュリティ対策とは、障害・災害時のリカバリ、代替・縮退運用対策、障害監視、データバックアップ、アクセスコントロール、リリース管理などである。文書もデータと同様に、常に正確であることが求められると同時に、それが不正に持ち出されてはならないものである。

 

 情報管理の意味合いでは、アクセスコントロール・暗号化・バックアップなどがセキュリティのキーワードである。アクセスコントロールは単なるシステムへの認証機能のみならず、物理的な入退室の管理も含まれる。入退室管理には、ICカードや指紋認証など、本人確認のための物理的なデバイスと併用される場合が多いが、形式だけの導入にとどまり、実効性を失う場合も多い。暗号化されたデータは、たとえ盗難されたとしても復号さえされなければ被害を抑えることができる。重要な情報の保管やネットワークへの情報の転送などで利用できる。入退室管理と同様に、暗号化されたデータの復号のためには、パスワードだけではなく本人確認用に利用可能なデバイスを併用することで、より安全性を高められる。特に、個人情報保護法の施行以降によくニュースの話題となっている顧客データの入っているノートPCの紛失や盗難には、データの暗号化、データにアクセスするアプリケーションの認証機能、そして認証に本人確認の妥当性の高い仕組みを利用することで、大きな効果が期待できるはずである。バックアップは言うまでもなく、日々の定常的な業務である。データの保存は物理的に離れた場所にある金庫などが理想だが、最近では海外拠点などに暗号化した状態で転送することなども可能になっている。

 

● ツールベンダ

 大規模開発では、RDBMS、データフィード、トランザクションモニタ、EJBコンテナ、システム監視やバッチジョブの起動などを行う運用ツール、あるいは統合パッケージなど、さまざまなツールを利用してシステム開発を行う。現在のシステム開発では、ツールに依存せずに開発を行うことはあり得ない。大規模開発になると、利用するツールも多岐にわたり、整合性やサイジングなどを十分に検討したうえでシステム開発をせざるを得ない。そして、アプリケーション開発では、十分に検討され互換性が確認されたツールを用いたとしても、毎回のように接続性の問題などが起こり、その解決を迫られる場面に遭遇する。そのため、大規模開発においては、そのシステムが持つ技術的な要素に関して、システムが動くか動かないかの分かれ目を支えているのがツールベンダの技術者である。

 

 アプリケーション開発者は、しょせんできあがっている技術を流用し、ロジックをプログラムに変換しているにすぎない。その設計や実装が少々下手でもシステムは動くが、ツールベンダの技術者のサポートなしに、アプリケーション開発者だけで大規模システムを確実に稼働させるのは、実質的に不可能と言ってよいだろう。

 

 メーカーなどが元請けとなった場合、あるいはシステム開発が複数のベンダで行われる場合、ツールを利用する大規模開発ではその問題の切り分けなどへの対処がうまく進まないという側面がある。例えば、自社のハードウェアの接続互換性を保証したうえでサポートを提供する範囲が自社のプロダクトのみである場合や、複数のツールに依存するような問題に対して、自社の責任か、他社のツールによる問題かということのみに議論が帰着し、最終的な解決が遅れる事態が発生することがある。

 

 このような問題への解決策として、大規模開発では、発注者がツールベンダ技術の中核を握る技術者を確保する。ツールベンダはコンサルティング名目で、自社のプロダクトのサイジング、適切な利用方法、他社のハードウェア・OS・プロダクトの組み合わせによる稼働保証などを行うことになる。

 

● コンサルタント

 システムに関連するコンサルタントには、2通りのタイプが存在する。ひとつは外資系に代表されるMBAの考え方を持ち込んだ戦略系コンサルタント、もうひとつはノウハウ至上主義の日本的なシステムコンサルタントである。

 

 戦略系コンサルタントの一般的な仕事の進め方は、As Is・To Beモデルと、事例のリサーチによるベストプラクティス(業界における最先端の考え方)である。

 

 As Is・To Beモデルとは、ユーザ企業に現状の姿(As Is)とあるべき姿(ToBe)を語ってもらい、そのプロセスを組み立てる手法である。

 

 ユーザ企業にとっては、ルーチンワークに追い回されている日常から離れ、ビジョンを考えるというのは、よい経験になる。しかし、実際のところ、出発点とゴールが決まれば、そこに向かうプロセスは誰にでも作ることができるだろう。

 

 しかし、日本ではAs Is・To Beモデルの適用は本質的な解決策とはなり得ない。なぜならば、日本企業には、あるいは日本社会には、手本となるTo Beモデルが存在しないのである。さらに、昨今のように市場の変化が激しい時代においては、数年先のビジネスを予測することは事実上不可能であり、経営戦略上の中・長期計画どおりに事業を実施するのは難しい。結局は、その場しのぎに計画を変更し、いかに速くキャッチアップするかがポイントとなることは言うまでもない。

 

 このように、To Beモデルがユーザから出てこない場合には、ベストプラクティスが登場する。業界内において最高にうまくいっている事例を持ち込み、それをTo Beモデルとして利用するのである。

 

 事例のリサーチは、業界誌やシステム構築事例が多数掲載されているような雑誌など多岐にわたる。また、いくつかの企業へのコンサルティング経験を横展開している場合も多い。海外の最新の事例とリンクすることで、これらの情報の説得力をより一層高めることができる。

 

 日本的なシステムコンサルタントの場合は、さらにろくな結果が出ない。経験則派の基本は現状追認と、業務の個別の問題点の解決である。つまり、日本的なシステムコンサルタントには、企業経営全体からの視点でBPRを実現し業務全体を最適化するという、あるべき方向性を望むことができない。

 

 しかも、すでに技術から離れた期間が長く、システムのアーキテクチャの変化や、開発方法論の変化などのフォローができていない場合がほとんどである。結果、過去の豊富な経験に基づく昔話を拝聴しておしまいとなる。

 

 先に、元請けの営業の節で述べたのと同様のことがコンサルタントにも当てはまる。実際に、数社の実績調査とヒアリングにより、本質的な問題を理解することは可能であり、その解決策を見いだすこともできる。結局は、ユーザ企業内部で解決策を実施するにあたり、社内の根回し・説得をするための代弁者となるのがコンサルタントの役割である。コンサルタントもその点はわきまえており、顧客となっている担当者の顔色をうかがいながら、その思惑通りにプレゼンテーションを進めていくのである。

 

コラム:プロジェクトマネジメントの不在

 

 プロジェクトマネジメントに関する知識に熟達しているプロジェクトマネージャとプロジェクトリーダでも、実際にはプロジェクトマネジメント不在のプロジェクト運営をしてしまうことが多い。

 

 管理というのは、システム開発プロジェクトに限らず、一般的に管理する側とされる側に共通認識があって初めて成立する。しかし、システム開発プロジェクトの場合、プロジェクトのあるべき姿を共通認識として持つことができない。例を挙げれば、実際にモノ作りをしている下請けレベルになると、ろくにドキュメントも書かずにコーディングをしているケースは珍しくない。プログラムの納品後にようやくドキュメントを書き始めることも、よく見られる光景である。さらに悲惨なのは、そういうやり方に慣れて、それがあたりまえだと思い込んでいるプログラマが多く実在していることである。

 

 きちんとしたプロジェクトマネジメントを行うことで、プロジェクトがスムーズに進み、プロジェクトの全般にわたり作業がうまくいく可能性が高くなる。ところが、個々のプログラマから見ると「自分の仕事の進め方と違うから能率が落ちる」というお話にならない抵抗が起きる。これは管理する側にとってはかなり深刻な問題である。結果として、プロジェクトマネジメントの知識を持つマネージャやリーダがいたとしても、妥協的でいいかげんなプロジェクト運営をしてしまう場合がほとんどである。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

3.3. 開発側 ハッピィ・エンジニアリング関連ページ

3.1. 利害の対立
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
3.2. 発注側
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング