ブ  ロ  グ

『企業システム戦略』の構築・実践に関する記事に対する私見を掲載しています。

 ※記事やニュースの内容は、タイトルをクリックすると参照できます。

ThinkIT
●ソフトウェアの定量的評価

『コラム』(企業システムの品質は、どこまで要求されるか?)

5000万円なら、欠陥数は10件以内が目標。
20日/月の内、最低でも1.6日はレビューに当てる。
できれば、2日。つまり、2週間に1日はレビューを行う。
開発側のプロマネは、ソフトの信頼性に責任を持ち、要求側のプロマネは、要求仕様に責任を持つ。

東証ダウン、真の原因はプログラムの破損 危機に瀕する「現場力」
いずれにしても「現場任せ」で、良いことは何もない。
現場を様々な定量的指標で測定し、分析し、改善するということは、どこの製造業でもやっていること。
TPQ、TQCには「測定しなければ、改善のしようが無い」という格言がある。



日経BP SMB+IT
●中堅中小企業のERP利用実態調査

『コラム』(中堅中小企業は、ERPベンダにとって"おいしい"マーケット!)

「はっきり言って"おいしい"マーケット」だそうです! そして、「レガシーは時代遅れ」だそうです!
しか〜し、満足度、安定性、堅牢性が高いために、ユーザーは入れ替えの必要性を感じていないのです。
ハードウェアは「老朽化」しても、ソフトウェアはどうでしょう。
世がオープン化の流れだから?最新のIT技術の波に乗り、時代に翻弄されてしまう危険性はないのだろうか。
いずれにしても、ERPに注目しているのは、ERPベンダとマスコミだけではないでしょうか。
だって「"おいしい"マーケット」なんですから。。。気をつけましょう。
それに、基幹システムは、10年やそこらで簡単に捨てて良いものでしょうか。企業遺産ですよ。
凍結するのでもなく、捨てるのでなく、進化させ変革させては、いかがでしょう。
システムの基本設計がしっかり継承されていけば、ハード/ソフトは、新しくして良いと思いますよ。 でも、基本設計まで捨てて、ERPに入れ替えて、業務を合わてしまうのは、良く考えましょう。 特に製造業の生産管理や、小売業の販売システムなど経営のコアは、ほんとうに企業遺産ですから。



@IT記事
●できるだけコードを書かないという発想

『コラム』

考えてみれば、プログラミングが好きで、プログラマになった人に、 プログラミングするな、コードを書くなと言う方がムリ。生理的に受付けません。

ならば、最初からプログラミングを知らない人を雇用するしかありません。 そのためには、プログラミング知識、コンピュータ知識不要の自動生成ツールが必要ですが。

技術者と作業者の完全な分離です。産業革命で、職人から工具を取り上げて 生産ラインに作業員を貼付けたのと同じことが起こる必要があります。

このようなソウトウェア産業革命が起きれば、ソフト業界の生産性も飛躍的に 向上する可能性があります。新たな雇用も創出され、産業の裾野も広がります。

いつまでも、個人の力量に頼った、生産性の向上では限界が見えてきているのも事実です。 生産性向上の問題を、SEやプログラマのやる気だけに任せていて良いのですか? 経営者からは、ソフト開発に対するコストダウン要請がきつくなっています。 ハードだけ必死にコストダウンしていて、ソフトは聖域などということは、これからは無くなります。





●「リアルタイム(経営)」

『コラム』

私は、リアルタイムという言葉が嫌いだ。何の定義も、前提も無く、リアルタイムという言葉を使う人は、いったい、どれくらいのタイムラグまでをリアルタイムと言うのだろう。リアルタイムな情報システムには金がかかるものだ。せめて、アジャイル(俊敏な)ではどうか?

机上の空論、虚構、人間不在の効率至上主義。。。そんな匂いがしてしかたがない。

たとえ情報通信技術によって情報が電気的速度、光の速度で伝達されようと、人間は、そんなには簡単には変われないものだろう。
刺激に対して反射的に反応する人とは、疲れるので付合いきれない。大人は、どう反応するのか一呼吸置いて考える。だからコミュニケーションがスムーズに行われる。
スムーズな経営には、スムーズな運転にハンドルのあそびが必要なのと同じように、あそびが必要だ。あそびの少ないハンドルは、切れが良すぎて危険だ。経営は、F−1レースやアクロバット飛行ではない。舵を握るものが、刺激に対して一々反応していたら、関わっている人たちは、たまったものではないだろう。まるでジェットコースターにでも乗っているようなものだ。



日経コンピュータ
●動かないコンピュータ経験は役立つか

『投稿』

私も、要件定義の失敗から変更が多発して収拾がつかなくなったり、アーキテクチャやプログラミングの失敗により実用性能がでなかったり、ユーザ担当者の異動で運用試験が頓挫し、そのままお蔵入りになったりと様々な「動かないコンピュータ」を経験しました。これまで、いろいろな対策も試みて、のたうちまわってきました。「事前にしっかり計画し、しっかり考え、しっかり準備をすれば、うまくいくはず」という幻想に振り回されて。

しかし、最終的に学んだことは、結局、どんなに注意しても「先のことは、何が起こるかわからない」ということです。

ハードウェアの世界では、作るべきものをコンピュータ上で仮想的に3次元モデルを作って事前に検証しようということが進められていますが、ソフトウェアでは、せいぜい図表と文章でモデリングするしかなく、完成品と同じものを仮想的に作るということが論理的に不可能です。ソフトウェア自体が仮想現実ですから。

であるならば、先のことはリスクとして認識し、できるところから動くものを作っては検証するという繰返型開発が良いのではないかと思うのです。

例えば、1年先の全ての動くものを思い描いて要件定義、設計、実装して、全く動かないコンピュータになるよりも、1ヶ月単位で12回に分けて少しずつ動くものを作っていけば11回のリスク回避チャンスがあります。

要件定義、設計、実装するチャンスも12回あるので、経験も積めますし、失敗しても取り返すチャンスが11回もあります。例え、1年後に100%できていなくても、70%の動くものがあれば、ひとまず安心です。

 ◆ラショナル統一プロセス
  ソフトウェア開発の経験から学んだ成功のための実践原則
  1.反復して開発すべし
  2.要求を管理すべし
  3.コンポーネント・アーキテクチャを使用すべし
  4.ビジュアルにモデリングすべし
  5.継続的に品質を検証すべし
  6.変更を管理すべし
  ※ここでいう「管理」とは、マネージメントするという意味で、決して制限するというような意味ではありません。



●性能改善とムダとり

『コラム』

性能改善は、ムダとり改善のチエ出しです。ある意味、高度なコンピュータ知識は不要です。皆でチエを出してムダ取り(性能改善)しましょう。ポイントは、いかにムダ無く、必要なデータをDISKから持ってくるか持ってきたデータをいかに、メモリ内で使い回すかです。

ヒントとして、コンピュータに仕事を効率的にさせることと、生産を効率的に行うことと基本は同じなので生産管理のアイデアも応用ができます。

『トヨタ生産方式のムダ』を活用する。
・つくりすぎのムダ(Waste of overproduction)
・手持ちのムダ(Wasteoftime on hand (waiting))
・運搬のムダ(Waste in transportation)
・加工そのもののムダ(Waste of processing itself)
・在庫のムダ(Waste of stock on hand (inventory))
・動作のムダ(Waste of movement)
・不良つくるムダ(Waste of making defective products)

以上のムダをコンピュータが行う作業について考えてみる。
・全データを探すムダ
・読み取りすぎのムダ
・不要不急のデータを処理するムダ
・同じデータを繰返し探すムダ
・データを滞留させるムダ
・関係の無いデータを取り込むムダ
・通信を繰り返すムダ
・ファイルのオープン/クローズを繰り返すムダ
・同じ経路を繰返し探すムダ
・不要なデータを溜め込むムダ
・必要以上にデータを細分化するムダ
・必要以上にデータを集約するムダ
・不良なデータを作るムダ
・不要不急の計算をするムダ
・DISKの回転時間、探索時間のムダ
・DISKの中を行ったり来たりするムダ
・DISKへ運ぶ(書き出す)ムダ
・DISKから運ぶ(読み出す)ムダ
まだまだ、他にもありそうですね。ところで。トヨタでは「作りすぎのムダ」が最も悪いとされているそうですが、システム構築においても、作りすぎて良いことは何もありません。ムダな機能やムダな性能は、資源のムダ使いですし、ムダなシステムは、諸悪の根源です。

◆生産管理講座 IE(Industry Engineering)

『ギルブレスの動作経済の法則』を活用する。
動作のムリ・ムダ・ムラをなくし、少しでも効率良く、正確な仕事を安全に行うために、

@基本動作の数を少なくする => DISKからの読取動作を少なくする
A両手を同時に使う     => 同時並行化
B動作の距離を短くする   => キャッシュ、バッファ
C動作を楽にする      => アルゴリズムの単純化

以上4つの基本原則を、それぞれ

@動作方法    => アクセス方式、アルゴリズム
A作業場所    => プラットフォーム、サーバ側/クライアント側
B治工具・機械  => ハードウェア/ミドルウェア

の3つの要素ごとに検討していく。

いかがですか、このように生産改善と性能改善は、チエ出しの点で非常に共通点が多いのです。



IT PRo SMB+IT
●中堅・中小企業の後悔しないIT導入
  (1)最適なベンダーとシステムの選び方
  (2)ベンダーの実力を見極める具体策

『コラム』

工夫も何も、対応しなければ取引停止かも。。。

 だからこそ、ITを武器に無理な要求に応じても儲けが出るようにしなければいけないのですね。

 そして、小が大に勝つために、大の真似をしてもだめだということを分かっているベンダを探す必要があるということですね。特に大手ベンダには要注意ですね。無理な要求を出している側が、受け手の側に立って真の解決策を考えられるのかという懸念があります。
 「経営戦略」なんて言い出したら、それこそ大手ベンダの思う壺かも。付け刃では、かえって危険かもしれませんね。彼らは、経営者向けのプレゼンテーションを、しっかりと教育されています。その彼らのプレゼンの真意を見抜くのも大変そうですね。

 中には、MBAも無く、経営戦略論も語らず、口下手で、プレゼンが下手でも、真に頼れる人物が身近にいるかもしれません。しかし、本当に技術の他は何も知らないダメSEかもしれません。彼らの真の実力を無抜くのも難しそうですね。

 そのような目利きができる人材育成も簡単ではなさそうですし。

  では、生死を分ける真剣勝負の場で相手の実力を見切るには。。。

 ご心配はいりません。これまで、一国一条の主としてやってきている経営者の方が、本気で腹を据えて掛かれば、似非コンサルや似非SEは、きっと尻尾を出しますよ。決して、技術論や経営戦略論、世界標準、ベストプラクティスなどの「あるべき論」に臆したり、乗せられないようにして下さい。

 「そんなに素晴らしいソリューションなら、御社では既に実際に使われているのでしょうね。
  ぜひ、”現場”を見せて下さい。」

 「その素晴らしいソリューションを導入したら、我が社の売り上げや利益は、どれくらい向上しますか?

  その数値に”コミット(約束)”できますか?」

 このように真剣を突きつけて見ましょう。竹刀を振りかざしている輩は、きっと逃げ出すはずです。親身になって提案していれば、恐らく、目の色を変えて食い下がってくるでしょう。ひょっとしたら喧嘩腰で「御社のためを思って提案しているのですよ!」と声を荒げてくるかもしれません。それでこそ、腹を割って話が出来るというものです。



IT PRo SMB+IT
●「メリー流IT革命」当社のキーワード「仮説検証」とは

『コラム』

※「戦略とは、因果関係の仮説である」  ロバートキャプラン

計画に目標値(売上げ)だけが示されて、そこへ到達するための因果関係(シナリオ)が無いことが多いですね。 そして、ガンバレの精神論で目標を達成しようと実行する。 確認といえば、計画と実行の差異分析(多い、少ない)だけで、「なぜ」の因果関係の分析をしていない。

それもそのはず、因果関係の仮説が無ければ、目標を達成しても、しなくても、その仮説が正しかったか どうか検証することもできません。 検証できなければ、次の計画に反映できません。つまり、Plan−Do−Seeが回りません。

  「一生懸命頑張った。良く分からんけど、ダメだった。」..... The END です。

落語に「風が吹けば、桶谷が儲かる」というのがりますが、これが因果関係(シナリオ)の仮説です。 この仮説が、他力本願で突拍子も無いので落語になっているわけです。
しかし、このように因果関係の仮説がはっきりしていれば、桶谷が儲からなかった時は、その因果関係の仮説に誤りがあったわけですから、この仮説をいろいろ変えてみて、次々と新たな計画を試して見ることができるわけです。

 ・風が吹くと、ほこりが舞う
 ・ほこりが舞うと、盲目が増える
 ・盲目が増えると、三味線ひきが増える
 ・三味線ひきが増えると、三味線が沢山必要になる
 ・三味線が沢山必要になると猫の皮が沢山必要になる
 ・猫の皮が沢山必要になると、猫が居なくなる
 ・猫が居なくなると、ねずみが増える
 ・ねずみが増えると、桶を沢山かじられる
 ・桶を沢山かじられると、桶が沢山売れるから儲かる

例えば、ねずみを沢山増やす別の方法を考えるとか、猫を減らす別の方法を考えるとかです。

ここで、それぞれの仮説が、どれくらいで発生するのか、発生しなかった場合は、どうなるのか。仮説を崩すような事態が、どの程度発生するのか、発生したらどうなるのか。発生確率や発生頻度、影響度を、あらかじめ洗い出してコントロールするのが、リスクマネージメントです。
 つまり、リスクマネージメントを適切に行うためにも、因果関係(シナリオ)の仮説は必要となるわけです。 なんの因果関係の仮説もなしに、勘と経験だけでリスクを洗い出すことはできませんから、度胸だけでリスクをコントロールすることはできませんから、残念!



日経コンピュータ
●“白けた会議”がプロジェクトを破綻に導く

『投稿』

白けた会議を、どのようにいじくろうとも無駄だと思います。それは、白けた会議というのは、白けた人が集まっているからです。なぜ、人が白けるのか。原因は、いろいろあるでしょうが、会議の進め方などよりも、もっと根の深いところにあるからです。

最悪、会社に社員が白けてしまっている場合すらあります。あるいは、私生活で人生に白けている人、処遇に白けている人、仕事に白けている人、いろんな白けた人がいます。

目的を明示し、本音の言いやすい環境を造り、発言を促しても、白けた人は「特に(意見は)ありません。」の一言で終わりです。私自身、その日の体調や気分などで白けている時もあります。ですから、そのような白けた人を気にしていても始まりません。

パレートの法則によれば、結果の80%は、上位20%の要因によるものです。問題意識や参画意識の高い20%の人が議論して会議を主導すれば、残りり80%の白けた人は、それでも後に着いて来ることもあります。

白けたフリをして、実は反旗を翻そうとしている人、このような人は、その人を立役者にして、表通り引きずり出してしまいましょう。骨のある人なら、そこで腹を決めますし、そうでなければ、自分から居なくなるでしょう。



日経コンピュータ
●IT Doesn't Matter(もはや、ITは重要ではない)は本当か?

『コラム』

この質問に対する回答として、この書籍をお勧めします。

・チェンジ・ザ・ルール!(Necessary but Not Sufficient:必要だが十分ではない)
・レビュー

ITは必要だけど、それだけでは不十分なんですね。仕事のやり方やルールを変えないと。そういえば、ERPを入れてリアルタイム経営が実現できないのは、月末締めなどの日本的商習慣があって、伝票をリアルタイムに入れないからだと聞いたことがあります。
業務改革プロジェクトが、いつの間にかERP導入プロジェクトにすりかわっていることが、なんと多いことか。他人と過去は変えられない、せめてシステムだけでもと夢をむさぼるのか? 統合という夢、幻想を。。。



日経コンピュータ
●「1泊2日の合宿でプロジェクトの成功率は変わる」――専門家が提言

『コラム』

1泊2日の合宿研修は、よくやりますよね。講師が来て、ブレーンストーミング等をやり若手社員として会社経営の問題発見&改善のアイデアを協議して、最後に発表しあうというやつ。あれで、実際に職場に戻って、実行したという話をきいたことがありません。

日常の職場から環境を変えて、リラックスした雰囲気で、自由に議論するので良いのですけど、職場に戻ったとたん現実に引き戻されるんですよ。研修では前向きな発言をしていた人が、実際の会議などで後ろ向きの発言をするのを目の当たりにすると、それこそ、むなしいというか寂しい気になりますね。

1泊2日で、自己開示ができて、その後の実プロジェクトでも、闊達な議論ができるとしたら、それは、最初からそういった素養のあるプロジェクト・メンバが集まっていたのであって、合宿は、プラスαの効果を引き出すものだと思います。

それこそ、合宿とプロジェクトの成功率に相関関係があるとは考えられないのですが。。。データを見たいです。



日経コンピュータ記事より
●ソフトウェア開発データ白書2005 IT企業1000プロジェクトの定量データを徹底分析
(独立行政法人 情報処理推進機構ソフトウェア・エンジニアリング・センター)


『コラム』

見積り評価に使えそうな生産性に関する調査データです。

 ・1人時 0.118FP(0.008〜0.729の中央値、90倍差)
 ・23FP/人月(200人時/月) 20日/月 x(8時間+残業2時間/日)
 ・1FP 100行 から 1人時 11.8行
 ・1000行で4個のバグ

 ユーザー企業向けソフトウェアメトリックス調査報告2005
 (社団法人日本情報システム・ユーザー協会)
上記の調査結果と、この調査結果と同じような結果が出ています。

 ・40社、133プロジェクト
 ・90万円/人月
 ・1.4KLOC/人月
 ・23FP/人月 ※ユーザーの21%しか利用していない
 ・620円/LOC ※ただし、言語別換算は未実施
 ・規模が100人月を越えると単価は10%以上下がる
 ・予算オーバー率 件数比 40% 金額比3.0%
 ・計画予算に対する外注費の割合 66%
 ・システム規模が大きくなると外注比率も高くなる
 ・企画段階100万円/画面が使える




ITPro 記者の眼
●開発標準・失敗事例集・仲裁機関で動かないコンピュータ撲滅を目指せ
(「未熟な業界だから動かないコンピュータが増えるのか」【総括編】)


『コラム』

私の投稿が掲載されました。

総合住宅展示場、欠陥住宅救急センター、病院検索JAPAN、医療事故情報センターのようなWebサイトのシステム構築版の設立を切に希望します。いまのIT業界は各ベンダーの実力が全く分かりませんし、問題が起きたときの救済機関や失敗事例や悪質ベンダー又は優良ベンダーなどの情報もありません。



日経BP SMB+IT IT化Q&A
●Q&A:システム稼働前のテストについて教えて?

『コラム』

テストに力を入れたい=納期・コストの追加 でなければ。。。

  「どのように」力を入れるのでしょうかね。全てのロジックをテストす るのは当然であり、その程度なら力を入れるとはいいませんし、単に 時間を掛けるというのであれば、時間稼ぎだとも思えます。
  逆に、いままで手を抜いていたということを表明しているようなもので すから、真意によっては、その業者はやめたほうが良いかも。



@IT連載記事
●IT技術者が「上流」に出て行く理由

『コラム』

「まずは一流のIT技術を身に付けよう」に一票!!

  IT技術を知らない人が要求仕様を作ると実現不可能な要求が盛り込ま れてしまい、あとから揉めることがあります。SCMとかPLMとかソリューションだけにはやけに詳しい、似非技 術者が巷にあふれています。
 しかも、高いお金を取って。。。ご用心!



日経BP 競争優位を獲得する最新IT経営戦略
●IT不良資産を生まないために 情報システム部門を改革せよ

『コラム』

かなり昔から、そして今も言われ続けているテーマです。経営とITの乖離。IT投資は経営問題として扱うべきである。ところが、CIOを置いている企業は極一部ですし、そのCIOも名前ばかりで、実際はシステム部門長だったりします。システム部門長は、コンピュータオペレータやプログラマの親分です。経営問題に首など突っ込めません。

経営問題を扱うのは、たいてい企画部門です。システム部門長は損益計算書や貸借対照表を見ることさえできません。例え、見たとしても理解できませんし、口出しできないのですから見るようになる必要性もありません。そもそも企業がコンピュータを導入したのは、給与計算や経理処理を電卓ではやりきれなくなったのが動機ですから、必要経費なのです。

変に投資効果だのを前面に押し出して経営者に話を持っていけば、当然、収益に貢献していなければ予算は削減されます。このご時世に、わざわざ自部門の予算が削られることが分かっているのに自殺行為のようなことをするシステム部長などいないと思います。「説明責任」などは奇麗事ですし、そもそも経費に説明責任も何も無いはずです。

いつから、ITは投資(=リターンを求める)になったのでしょうか。ところで、いまどきコピー機が無い会社は少ないと思いますが、「コピー機は経営問題だ」と言う人はいません。しかし、ほとんどのITは、本質的にコピー機と同じです。コピー機も実は、情報を高速に転写するというITなのです。コピー機の導入に戦略論を唱える人がいるでしょうか?経営者が経営問題として扱うでしょうか?

経費ですから売り上げの一定比率を当てるというのは自然な考え方です。損益が悪化すれば、第一に経費削減の対象とされます。逆に、最新のコピー機を導入したら、会社の収益が改善されるなどと言い出せば笑われてしまいます。無駄なコピーは抑制し、コピー機を活用して業務を効率的に行うことに異論はありませんが、リターンを求めたり、経営問題だとか、戦略だとかは行き過ぎですよね。

ITも同じスタンスで付き合っていけばよいのではないでしょうか。

経費を投資だと言い、さもリターンがあるかのように思わせて、経営者やシステム部門長を炊きつけて、必要経費以上に予算を確保して、いったい誰が一番得をするのでしょうか?予算の行き先は、IT産業であり、IT産業が活性化すれば、IT関連のマスコミも好況になるわけですよね。

IT投資に対してシニカルな見方で、逆説的に論じてみました。実は、コピー機ではない一部の重要なITを見極め、有効な投資を行えているかどうか、活用できているかどうかが、会社の強さのバロメータなんです。そして、そういったコアコンピタンスとなるようなIT投資を提案・実行・説明できているかどうかが社内でのシステム部門の価値なんです。



IT Pro 記者の眼
●なぜ私は2007年問題をテレビで解説したか

『コラム』

2007年問題の病巣として、ホストの既存システムを「ブラックボックス」又は「レガシ・システム」と称して、これを廃却/凍結して、新しく作りなおせば問題解決できるとする風潮があるがそもそも「ブラックボックス」の正体とはなにか? 

例えば、あるシステムの改訂に伴って業務標準が改訂された。
このなかに、以下の記述がある。

※自動発注方式の概要 電算機を利用してスケジュール,作業指示の内容,価格計算等,すべての準備が整ったデータを抜き出して自動的に発注処理を行う方法をいう。また,注文書の発行と同時に作業指示書,納品書の発行を行う。
注:スケジュール,作業指示の内容,価格計算等のどれか1つでも不備があれば注文書及び作業指示書は発行されない。


注の部分は、具体的になんらかの条件で検査されて、発行を制御するようにプログラムが記述されていると思うが、具体的な条件は何で、その記述が、システムを構成する、どのプログラムのどこに記述されているか、即座に分かるようにトレーサビリティが確保されているだろうか? この判定条件を変更したい場合に、即座に、どのプログラムの、どこを改修すれば良いか、そして、影響範囲を特定することができるだろか。

できなければ、これが、ブラックボックスである。

そもそも、これらの条件を記述した正式文書(業務標準、業務マニュアル)が業務部門内に存在するのだろうか? 存在しなければ、関連プログラムを探して、現状の条件設定から調べなければならない。これでは、現場から、注文者と作業指示書が発行されないが何故かと、問われた時にプログラムを調べなければ、答えられないということになる。 もし、手作業による時代であれば、この条件は「業務マニュアル」として明確に記述されていたであろう。問合せにも「業務マニュアル」を調べて、業務担当者自らが回答ができた。

コンピュータ化したとたんに、業務マニュアルには記述されず、仕様書はあっても、維持改訂されずに、自然消滅する。システム開発時に作成した大量の仕様書は、どこに行ってしまったのだろうか? 誰が、維持改訂しているのだろうか?
業務要件とソースコードのトレーサビリティが無い。

結局、思い当たるプログラムをしらみつぶしに調べなければ、現状さえ分からない。
コンピュータ内部に、本来、業務担当者が知っておくべき業務条件や手順が隠蔽された状態になる。

これが「ブラックボックス」の正体なのだ。

これを解決しなければ、何度、新しく作り直しても「ブラックボックス」から逃れることなどできない。
2007年問題も繰り返されるだろう。

例えば、ハードウェア製品の場合、カタログや図面も納入し、顧客とは図面番号や製造番号で、コミュニケーションが図れる。 システムの場合、ユーザが言う「XXXシステムのXXX条件」が、どの製造番号(プログラム番号)のことなのか分からない。ユーザは、何故、図面番号や製造番号を知らないのだろうか。

プログラムの記述が汚いのは問題ではない、業務上の条件が利用者から明確に提示され、それに対応するソースコードが、どこにあるのかさえ分かれば、そのソースコードを読み解くのは、それほど問題では無い。

最新のERPパッケージを採用した業務システムでさえ、すでに大きな「ブラックボックス」である。ことの重大さを良く見極める必要がある。ERP採用時には、「ブラックボックス」化した既存システムを改修して延命するより、最新のERPパッケージで再構築したほうがよいという、その結果は。

結局、新たな、しかも、より大きな「ブラックホール」を生んだ。
現在、ERPパッケージを改修をしようにも、中身が分からず、技術者不在で「できない」。「ERPベンダに依頼すれば、初期開発の数倍の費用がかかる」といった状態。そのため、一部では、自社で再々構築して移行する始末。

業務標準−業務マニュアル−(仕様書/設計書)−プログラマーズマニュアル−ソースーコード。
このトーレサビリティの確保こそが「ブラックボックス」問題の解決策である。



@IT(アットマーク・アイティ)Insider.NET
●マルチスレッドはこんなときに使う

『コラム』

コンピュータに仕事を効率的にさせることと生産を効率的に行うことと基本は同じなので 生産管理のアイデアも応用ができます。逆にコンピュータのアイデア(パイプラインやメモリ・バンク)を生産管理 にも応用できます。

<ギルブレスの動作経済の法則>
動作のムリ・ムダ・ムラをなくし、少しでも効率良く、正確な仕事を安全に行うために、

@基本動作の数を少なくする => DISK読取や命令等を少なくする
A両手を同時に使う     => 同時並行化、並列マシン、クラスタ化
B動作の距離を短くする   => キャッシュ、バッファ
C動作を楽にする      => アルゴリズムの単純化

以上4つの基本原則を、それぞれ

@動作方法    => アクセス方式、アルゴリズム
A作業場所    => プラットフォーム、サーバ側/クライアント側
B治工具・機械  => ハードウェア/ミドルウェア

の3つの要素ごとに検討していくというもの。



ITPro 記者の眼
●未熟な業界だから動かないコンピュータが増えるのか[2005/03/10]

『投稿』

・動かないコンピュータを減らすためにユーザー,ベンダーを含め業界全体で取り組めること

失敗事例の公表、業者評価の公表などの情報公開です。また、自動車業界の発展に、徳大寺さんの「間違いだらけの車選び」も貢献したとか。そういった辛口の評論家による書籍などで、消費者が賢くなれば、未熟な業者は自然淘汰されていきます。  歴史もあって、規範もある建築業界での欠陥住宅や医療業界での医療過誤が社会問題化していることを考えると、情報公開と消費者が賢くなることで厳しい選択眼に業界がさらされなければ問題は解決しないと考えます。例えば総合住宅展示場、欠陥住宅救急センター、病院検索JAPAN、医療事故情報センターのようなWebサイトのシステム構築版の設立も有効だと思います。

・業界全体の規範とすべきもの

ISO/IEC12207、JIS X 0160、共通フレーム:SLCP−JCF98など。



日経SMB+IT IT化 Q&A
●速度向上のためベンターに高性能のハードの導入を求められたが…

『コラム』

昨今の複雑なIT環境では、チューニング(性能改善)は、 芸術の世界と言われています。

つまり、プロの芸術家は少なく、依頼すれば非常に高価です。

一般的な技術力レベルでは、要件定義や設計段階で性能を適切に予測するのは不可能に近く「動かしてみなければ分からない」と いうのが実情です。 テストでは機能確認の他に、性能に対するチューニングは必須作業として、あらかじめ予算・期間を適宜、盛り込んで計画を立ててお くのが良いでしょう。 また、ハードウェアを増強するにしても、その結果、確実に性能が改善できるものかどうかもベンダに確認しましょう。 「なぜ、ハードウェアを増強すると性能が改善されるのか、どの程度改善すると見ているのか、その技術的な根拠は何か、要求スペックの 妥当性を証明してもらいましょう。

なんの技術的な裏付けや根拠も無くハードウェアの増強を要求するベンダもいます。



日経BP ITPro
●業界の期待を裏切るレガシー移行

『コラム』

「売るものがなくなってしまったSI業界の、頼みの綱が レガシーマイグレーションだ」と、CSKの有賀貞一副会長が期待する。

いやー、とうとう本音が出てきましたね。 やはり、レガシ・マイグレーションは、かつてのダウンサイジングの焼き直しではないのでしょうか。 メインフレームが売れなくなったときに、業界はダウンサイジングと称して、UNIXやPCサーバの市場を開拓しました。

本質的には、これと同じです。そして、オープン化して、バラバラにした暁には、今度は、これを効率良く統合管理するツールなどが売り出さ れるのでしょうか。
「光あるところに影がある。」ということですね。

◆IT Pro Special レガシーマイグレーションのすすめ

◆IT Pro Special 基幹システム再構築の“最新動向”と“肝”



日経SMB+IT IT化 Q&A
●CIOに求められる資質とは?

『コラム』

情報化ということが先に立ってしまいITに詳しい人、 全体最適なシステムを見通せる人、ITと経営の両方に強い人 などがCIOに相応しいとされていますが、 情報化投資の失敗は、業務改革の失敗。

何よりも、業務改革を強力かつ粘り強く推進できるかどうかが最重要です。 現場からの信奉があり、業務改革を率先垂範し、地道に愚直に成果が出るまで、諦めずに実行できる人が必要です。
その意味では、CIOは、Chief Innovation Officer:最高革新責任者 というのがピッタリかもしれません。

例え、カッコよく全体最適を考え、経営層に情報投資を説明し 首尾よく了解を得て、立派に動くシステムを構築できたとしても、 そのシステムを活用した業務改革が進まなければ全てが水疱と なる恐れさえあります。

・IT投資の成否は“事後”に決まる

・IT導入の成否を分ける業務改革



日経SMB+IT IT化 Q&A
●システム構築のプロジェクト管理はベンダーに任せてよいか?

『コラム』

基本的には任せてよいのだと思います。請負契約では、内部統制に立ち入らないのが原則ですから。
ベンダの中には、あまり干渉されることを好まないところもあるでしょう。信用していないのかと思われても困ります。

しかし、任せるからといって放任してよいということではないでしょうね。
納品日に完成しておらずに、本稼動のセレモニーがドタキャンにでもなったら、それこそ大変です。

少なくとも、1週間に1度位は進み具合を連絡してもらうのが普通です。

遅れている場合でも、原因と対策を聞いておくことです。内容はともかく、遅れの原因と対策を顧客に分かるように説明してこないよ うなベンダでは、先が危ぶまれます。
例え納期遅れの場合のペナルティを契約で取り決めていたとしても最終的に困るのは誰かを考えましょう。

稼動が1ヶ月遅れた場合、自社のビジネスにどんな影響が出ますか?

もし、何も影響が無いのでしたら、納期遅れに目くじらを立てて人間関係を悪くすることも無いでしょう。
あせって品質の悪いシステムを納品されるくらいなら、腹を据えて待ちましょう。
そのほうが利口です。負けるが勝ちということもありますから。



@IT 情報マネジメント> 情報化戦略・投資
●システム開発におけるユーザーニーズは絶対か?

『投稿』

 なぜユーザーニーズを聞いているのに、役立たないシステムになるの?
 なぜユーザーニーズを聞いているのに、システムへの改訂要求が多いの?

  この記事は、正に私が20年間社内で叫んできたことです。実は、記事で紹介されているようにユーザーに費用意識を持たせてはいるのですが、その結果、予算が無いので十分な要求機能を盛り込めず、システムが所期の成果を達成できないという言い訳を生んでいます。そこで、私のカイゼンの主な視点は、以下の5点です。

 ・志
  これがトップから担当レベル、利害関係者で共有できていることが必要最低限の成功要因
  になります。
  志に欠けたユーザーニーズは、個人の趣味的な欲望へと暴走し止まるところを知りません。

 ・質問力
  隠れたユーザ要求を獲得するには、適切な質問が必要です。良い質問は、ユーザに「気付き」
  を与えます。
  ユーザーにとってあまりに日常的で無意識下の要件は、忘れ去られていることがあります。
  ところが、いざ運用試験を始めたところで、基本的かつ重大な要件漏れとして発覚するの
  です。
  また、他部門との利害関係や近い将来のこと、例外事項については無意識に遠ざけてしまう
  という人間心理も働きます。

 ・要求工学
  5W2Hを基本とした要求の「見える化」です。そして、適切な要求を開発します。
  ユーザーニーズ(要求というより欲望)を全て満たすシステム要件が、最適とは限らない
  のです。
  工学的アプローチによって、混沌とした要求(欲望)を構造化し、システム要件を定義する
  必要があります。

 ・価値工学
  要求に対する価値を算定します。価値の高い要求を獲得するために、機能とコストのトレード
  オフ・スタディ、
  優先順位付け等を関係者合意の下でおこないます。ここでも、志が重要になります。
  志に向かって機能を関連付けることで高い価値を獲得することができます。

 ・リアルオプション
  8:2の法則によれば、重要な基本要求は全体の2割りです。価値の高い、上位2割り
  の要求から資金を投入し、効果を見ながら段階的に資金投入し不確実性と不可逆性の
  リスクを緩和します。
  情報投資は効果の獲得が不確実な投資であり不可逆です。かといって、必要以上に消極的に
  なっていたのでは遅れをとってしまうという大きなリスクを抱え込むことにもなります。
  ここに、段階的に投資しながら将来の成果を獲得するという選択肢を持っておくことに
  価値を見出します。



経済財政諮問会議
●「日本21世紀ビジョン」にあなたの意見を ―「私の描く2030年」―

『投稿』

 21世紀のめざす日本は、やはり「日本国憲法」の前文にあるように 「国際社会において、名誉ある地位を占めたい」の一言に尽きます。そして「日本国民は、国家の名誉にかけ、全力をあげてこの崇高な理 想と目的を達成することを誓う」のです。民間企業ではCSR(企業の社会的責任)が問われるようになっており、やはり目指すのは「尊敬される企業」です。

 名誉ある国家や尊敬される企業を支えるのは、尊敬される人々であります。その人々が持つ「志」が大切です。

 小さいころ偉人伝をよく読みました。その中で「尊敬の念」を学び、「志」を構築してきたように思います。しかし残念なことに昨今の社会現象を見てみると、大人から子供まで、「志」を失っているように思えて仕方ありません。

 偉人伝やTV番組では、戦国武将や明治維新、せいぜい昭和初期の偉人がテーマです。20世紀後半の私が生きてきた、この時代において自信を持って我が子に伝えられる「尊敬できる人」が見当たりません。

 もう一度、日本国憲法に戻りますと「崇高な理想と目的」として「国際社会における、名誉ある地位」があると思うのですが、具体的に「何が、どうなれば、名誉ある地位」を占めることができるのか、その道筋が今の日本には見えてないように思います。

 「尊敬される」とはどういうことなのか、今一度、明確に定義する必要があります。

 私の思う「尊敬する人」は、宮沢賢治ように、しっかりと自己を確立した心豊かな人です。日本が尊敬される国家になるには「豊かさ」とは何か、それぞれの立場で今一度、再定義してみる必要があると思います。

 心が豊かでなければ、平和を維持し、専制と隷従、圧迫と偏狭を永遠に除去することに邁進できません。 さらに「情報」「環境」「人材」を加えましょう。例えば、情報においても平和を維持し差別を無くさなければいけません。

様々な分野で「尊敬される人」を多く排出できる国は「尊敬される国家」でもあります。そのような「環境」を整備することが必要です。 個人の努力と環境の相乗効果で、人は才能を開花できます。「環境」が汚れていれば、人の心も体も汚れます。 豊かな環境、豊かな人、豊かな国家から「尊敬」を得られる言動が生まれるものと思います。



ITPro 記者の眼
●トップがダメだと動かないコンピュータが生まれるのか

『投稿』

(私が、以前に投稿したコメントが再び引用されています!)

失敗の原因を、一言で言えば、”当たり前のことを愚直にやり遂げる”組織能力の不足。 バランススコアカードでは、学習と成長の視点であり、「能力構築競争(中公新書)」 では、組織能力。これが無いので、その次にある「プロセス」や「深層の能力」を、IT活用で強化しようとしても 計画倒(頭でっかち、地に足がついていない)となってしまう。

いずれにしても、組織を「成功」へ向かわせるには、組織能力を強化するということに尽きるが、トヨタが 、どのように現在の組織能力を身に付けたのか、当事者さえも分からない。分からないから、他社が簡単 にトレースできない、真似できないという強みになっていると「能力構築競争」は言う。

思うに、トヨタの場合は、”カンバン”とか”在庫はムダ”という分かりやすく、かつ、強烈で 全員が思想や哲学を共有でき、(KPIを持ち出すまでも無く)その達成度合いを測定しやすいキーワードがある。 戦時中の”欲しがりません勝までは”にも似た、ある種、組織を意識・無意識下で全体主義的に一つの方向に向かわ せる何かが必要なのではないか。やはり日本は、ガバナンスのあるべき論よりも、運命共同体になれる「志」を示さ れるほうが強い。ところが、価値観の多様化に伴って「志」も希薄になってしまったようだ。ITに関しても トップから末端まで、真に「志」を共有できているケースは、たとえ時間がかかっても”愚直に”成功しているようだ。



日経BP SMB+IT(Q&A)
●りん議書を電子化したがスピードアップに貢献しない!

『コラム』

りん議書の主なプロセスは、1.起票→2.承認依頼(送付)→3.内容確認→4.承認 という流れですが、電子化でスピードアップできるのは、おおむね2の送付プロセスです。 3などでの滞留は、紙でも電子でも変わりません。机の上に書類が溜まっている人は、メールBOXの中身も 溜まっています。承認期限を付けるつけないは電子化とはあまり関係がありません。 期限が迫っても溜める人は、紙でも電子でも溜めます。

単に紙が電子化されただけでは、紙での滞り状態も、同じく、電子化されるということです。

そこで、もう一工夫が必要になります。

例えば、電子化による同時発信の利便性を活かしてりん議書を承認依頼すると同時に、承認ルート上の関係者に 参考配布してしまいます。すると、事前に内容確認ができるので3.のプロセスもスピードアップできます。 しかし、それとても参考配布されたりん議書で事前に内容確認するという組織文化が無ければ、ムダにメール・サーバの負荷 を増やすだけに終わるでしょう。

また、電子データの分類し易さに着目すれば、りん議書の金額や緊急度などによってメールBOX内での分類や色分けを 行うことで、緊急案件が埋もれてしまうことを防止できるかもしれません。

結局、ITの「情報を早く・広く伝える、分類や並べ替えなどの計算処理ができる」などの特徴を活かした、りん議プロセスを 考案し、それに組織文化が追従できなければ、期待されるような効果は得られません。

最初にシステム化計画を立てるときに、現状の業務プロセスのどこで、どんな問題が発生し、真の原因は何かをしっかり分析し、 ITが真に課題解決策になるのかを、良く考えることが成功の第一歩です。

案件数の割りに遅延が多いのであれば、りん議書の書き方が分かりにくく、内容確認に時間がかかっているのかもしれません。 その場合の解決策は、電子化ではなく、りん議書の記入様式の見直しや、そもそものりん議ルールの簡素化が解決策となります。



@IT 情報マネジメント > 情報化戦略・投資
●連載:企業システム戦略の基礎知識

『投稿』

 このたび、@ITさんで連載記事を執筆 することになりました。
IT導入はどうして失敗するのか? なぜ、導入効果が分からないのか? ユーザー企業が知っておくべきITに関する知識と考え方を“本質から”解説していきます。こちらも、どうぞ宜しくお願いします。



ITPro 記者の眼
●なぜ繰り返すのか,失敗プロジェクト[2004年11月08日]

『投稿』

 いろいろ原因はあると思いますが、 失敗が失敗として問題にならないところが最大の問題ではないでしょうか。

例えば、製造業での新製品開発プロジェクトなど社運を賭けてやっているよう なものは、トップの関心はあつく失敗/成功の評価もしっかりとされます。 失敗すれば、徹底的に原因と責任を追及するでしょう。 建築プロジェクトは、厳格な建築基準や法律に縛られたなかで施主も業者も緊張感を持って仕事をします。 医療プロジェクトなら、人命に直結するので、医師免許を持たない者が従事することはありません。 自動車を整備するにも国家資格が必要なのです。

しかしながら、ITプロジェクトに関しては一部の業界やシステムを除けば 今だに業務改善を目的としたプロジェクトが多く、失敗しても大して問題視さ れず、逆に成功しても、これまた大した評価が得られません。 当事者意識も無く要件定義を業者に丸投げしたり、素人同然のものが技術者として プロジェクトに参加したり、プロジェクト管理をしたり、システムに変更を加えたりと なんらの法規制もありません。 ITは、PL法の対象でさえないのです。
つまり、ITは野放し状態であり関係者に緊張感や責任感が感じられないのです。

その最たるものが、社内での情報システム部門に対する位置付けや評価です。 所詮「ITは本業ではない」というのが大方の経営者の認識なのではないで しょうか。

マスコミやITベンダが「IT経営」とか「IT戦略」とか叫んでも、どうも ピンとこないというのが実感のようです。

また、企業会計上も100億円の投資をして工場設備を建設すれば資産として 組み入れることができますが、ITは客観的に効果が証明され、キャッシュ・ イン・フローがなければ資産にはならないのです。 つまり投資金額は、費用でしかありません。

しかも、税務会計上では効果の有無にかかわらず繰延資産として固定資産税の 対象となるのです。

このような状況では、よほど効果が明確で業績に直結するようなIT投資でな ければ、投資額を絞りたくなるのは当然です。さもなければ、効果を度外視した 政治的な道具や見栄を目的とした捨て金に近い投資なのかもしれません。 効果が不明で、投資額を絞るとなれば、失敗しても成功してもとるにたらないのです。
そのような状況ではモチベーションもあがらないのが人情ではないでしょうか。

そうではない、ITプロジェクトに社運や命を賭けているのだというなら、各部門の ナンバーワンを専任で要件定義にあたらせ、徹底したレビューを実施し、成功の 暁にはプロジェクトマネージャに次期社長の席を用意しておくというのはいかがでしょうか。 また、一定規模のプロジェクトにおいては、プロジェクト管理やシステム設計には、それなりの 資格保持者でなければ従事できないと規制してはいかがでしょう。

実際には、業務部門の割と手が空いている人が要件定義に兼任で参加し、しかも本業が忙しくなれば 要件定義は後回し、レビューには参加せず最終的にはシステム部門と顔馴染のベンダにお任せと言うのが実体ではないでしょうか。



財団法人 愛知県中小企業振興公社
●ネットあいち産業情報 平成16年11月1日号

『コラム』

  ※以下の第2部に私の記事が掲載されました!!

 特集 バランス・スコアカードとIT投資
 ・ 第1部 バランス・スコアカード導入に成功する法
   中小企業診断士・ITコーディネータ 井上 実

 ・ 第2部 最小の投資で最大の効果を生むシステム戦略
   企業システム戦略家(企業システム戦略研究会代表) 青島弘幸



経済産業省 商務情報政策局 情報セキュリティ政策室
●新「システム監査基準」、「システム管理基準」の公表について

『コラム』

  今回、監査基準改訂の趣旨は、監査の位置付けにあるとのこと。

 (旧)情報システムの有効性に対する点検、改善

 (新)社外の利害関係者に対する情報システムの健全性を保証する=>保障型監査

 つまり、これまでは自助努力としての意味合いが強く、経営者からは「必要性を感じられない」とか「監査をしても実益が無い」などの評価が多く、普及率はかならずしも高くは無い。しかし、一方ではシステム構築プロジェクトの70%は失敗していると言う状況がある。
 これを考えるに「失敗はしても、他人にとやかく言われたくない。」という人間心理が具間見える。確かに、情報システムが社内の業務効率化中心の時代であれば、失敗しても自分の腹が痛むだけで誰に迷惑かけるものではないし、業務改善が進まないというだけであるなら、わざわざ監査の必要性を感じないだろう。
 ところが、昨今は企業の社会的責任や利害関係者への説明責任、透明性などが強く求められるようになりしかも、情報システムが経営と密接に関係してくるようになった現代では、情報システムの健全性を対外的に公表し説明責任を果たすことは当然の流れである。
 また、個人情報保護法など企業の情報マネジメントに責任を課す法案などが施行されるようになると、万一、調停紛争が発生した場合に、その情報マネジメントの正当性・適切性を立証し、自社の利益を保護しなければならない。監査は、その立証の役割も担うことになる。

 さらに、これまで情報化を進めてきた企業は、それなりの規模でありシステム部門やシステム専任者を要することができたので、第三者による監査を必要としなくても、それなりにやってこれたということもあるだろう。
例え、70%が失敗しているにしてもだ。
 ところが、eJapan構想などを受けて政府が推進している中小企業のIT化では、そうはいかない。特に80%以上を占める従業員20人以下の小規模企業では、システム部門はおろか、システム専任者さえもいないことを前提にIT化を推進することになる。
 この巨大な市場にビジネスを求めて、様々なもの達がやってくる。コンサルタントやITサービス企業、ITコーディネータなどが口を揃えて「御社の経営課題を解決します!」と。彼らは、いずれもIT化の当事者であり、利害関係者だ。その彼らの言動を素人同然の経営者や担当者が理解し、自社に適合する適正なサービスを選択していかなければならないのである。
 これを救済できるのは、利害関係から独立したシステム監査制度しかない。さもなくば、70%どころか80、90%の失敗事例が瓦礫のように積みあがり、食い物にされた挙句、大して役に立たないITを背負わされる被害企業が多発するのではないかと危惧する。あるいは、懸命な中小企業の経営者は、独特のカンで危機を感じ取りIT化を避けているのかもしれない。いずれにしろ、そのような状態では健全なIT化を推進し、日本経済を回復することなどできない。
 ITの専門知識に疎い中小企業には「全て自己責任で」というようなやり方ではなく、安心してIT関連サービスを利用して、「最小の投資で最大の効果を得、真に会社を強くするシステム戦略」を実行できる社会的バックアップ制度を整備する必要があるのではないだろうか。
 建築基準法における建築基準検査は、建築業者が申請し監督基準局が検査を実施し認可するもので、施主が費用を負担するものではない。IT関連も、同様な制度が整備されることを望む。

ITPro 動かないコンピュータフォーラム
●動かないコンピュータが生まれる理由は何か
●読者が伝えた70の動かないコンピュータから考える(上)

『投稿』

  記事の3ケースいずれにもあてはまらないものがある。
実は、動かないコンピュータは意外に少ない。システム開発プロジェクトは、ほぼ成功し安定稼動している。
しかし、それを使う人や組織が動かないために、コンピュータが想定した威力を経営上発揮しないというもの。

理由は、公知のようにリーダシップ、戦略シナリオや目標、適切な評価指標の欠如。
あるいは、それらの組織への教育、浸透不足など。つまり、経営戦略とIT戦略の乖離、
ITガバナンスの欠如だと考えられます。

朝日新聞 H16・10・17付け1面
●電子カルテ共有、26地域中10地域で完全休止 手間と費用に医師ら敬遠

『コラム』

  経済産業省は相次ぐ休止に「費用や入力の手間がかかっても、効率化といった目的を追求するシステムなのに、ムードで手を挙げた団体もあるのではないか」という。しかし、費用や入力の手間がかかるというのは、非効率なのではないか。電話やファックスで十分とする医師ら現場のニーズを無視して、効率化とは誰のための効率かなのか。もし、現場が非効率になっても患者の利便性が高まるのであれば、そのようなプラス効果とマイナス効果をしっかり理解していたのかどうか。また、手をあげた地域に資金を援助する場合、ムードだけで手をあげたのではないことを経済産業省は、しっかりと確認していたのだろうか。

たしかに、目的や成果獲得までのシナリオや適正な効果試算もせずにムードだけで、IT化や電子化を推進すると言うのは、どこの世界でも同じような話はある。例えば、鳴り物入りで導入したERPで経営の効率化を目指すも、現場が入力の手間を嫌がり失敗に終わると言うケースなどがある。なにも本件だけを攻められたものではないが、企業の経営者がムードだけでIT化を推進して投資がムダになっても、一企業の中だけで済む。しかし、本件は56億円と言う税金が使われており、その大半が水泡に消えようとしている。結局、漁夫の利よろしく儲けたのはITベンダだったりするのだ。

何故もっと最初にモデル地域を少なくして、最小の投資で効果を確認するようなアプローチができなかったのか悔やまれる。もっとも成功事例とあるトヨタ記念病院(トヨタ自動車設立)がシステム維持費を全額負担するなどというのはモデルケースとしては特殊であろう。(それとも大企業が地域貢献として資金援助せよということ?)また、税金を投入するからには「入力の手間」などという理由で休止する場合は、援助金を返納させるという契約を最初にしてもよかったのではないだろうか。もっとも、それではムードで手をあげたようなところは尻込みし応募が極端に少なく事業そのものが休止になっていたかもしれない。むしろ、そのほうが無駄な投資を最小に抑えられたのではないだろうか。

日経BP SMB+IT
●小規模企業でもIT化するメリットはあるか?

『コラム』

  この話の続きとして、パソコンを購入して奥さんの仕事が2日から1日に減り1万円浮いたとしたら、 給料は19万円に減らすのでしょうか?そして、減らしたとすれば会計上は1万円の利益増ということになりますが、 ほんとうに利益(一家の手取り収入)が増えますか?例え、社員を雇っているにしても、カンタンに給料を減らすことが できますか?

浮いた1日で、奥さんは何をしますか?営業に出て売上増を狙いますか、それとも、家事にいそしみますか、余暇の時間を増やしますか? そういったところまで突き詰めて「効果」を考えないとダメです。

相談者は「不自由は感じていない」と言っているのですから、その上の「効果」としては、手取り収入アップでしょうか。 手取り収入アップなら、売上増か利益増が必要です。奥様の給料削減が、それらに貢献しますか? そこのシナリオ、因果関係がはっきりしていないといけません。

例え手取り収入が増えなくても、余暇の時間が増えることが「効果」として納得できるなら良いですが、そうでなければ、結局、パソコン に投資したお金は、確実に外部流出金です。例えば、利益率が10%ならば、10万円のパソコン購入にペイするには、 売上を100万円上乗せするか、経費を10万円削減できなければ、赤字です。

この記事にある「効果の計算」は、見なし効果と呼ばれており、お金に余裕のある大企業がIT投資予算の稟議を通すために 便宜的に使っている手法です。しかも、それが経営者からは投資効果が不透明と不評です。

それを、家族で運営しているような経営環境に、そのまま持ち込んでも、きつねにつままれたような気になります。 結局、ITは金食い虫ということになってしまします。

ようは「ITは、何か効果があるか?」ではなく、自分や家族の生活をこのように改善したい、そのために経営状況を、このように 改善したい。と目的・ビジョンを明確にして下さい。 ついては、その手段として「ITは、どのように使えるか?」というように考えなければ、記事のような説明をするITベンダに 多額の設備を買い込まされたあげく、手取り収入は減ったというようなことになりかねません。

@IT記事
●ソフトウェア要求の詳細な分類

『コラム』

  要求:What と 設計:How の違いには注意しましょう。

設計を(あいまいな)要求の細分化作業だと勘違いしているケースがあります。 Whatを細分化し明確化することと、Howを考えることは本質的に別物です。 このことを理解していないシステム技術者もいます。そのような人が書いた要求仕様書は、WhatとHowが 混在していて、要領を得ません。

細分化・明確化が不十分なWhatは、不完全な要求です。 不完全な要求からは、不完全な設計しかできません。 要求を明確化するには、業務用語に着目し、入力・処理・出力を5W2Hで整理することから始めましょう。

要求の不完全さを、設計以降で補うのは、コスト増につながります。 運用試験以降で補わなければならない事態が発生した場合、 要求段階に比べて200倍のコストがかかるというデータもあります。

@IT記事
●システム化の第一歩は社内用語の統一から

『コラム』

  要求分析で、業務用語一覧表を作成しますが、「分かりきった用語」と安易に取り扱わずに、 複数の部門・人に、突っ込んだヒアリングをして定義を明確にしないと、ホモニム(同名異義語)やシノニム(異名同義語)に よって、仕様書に書いてある内容が全く異なってしまうということも。

例えば、「部品」や「在庫」といった良く使われる言葉も、突き詰めれば、部門・人によって様々な意味で使われています。 同じ「在庫」でも、営業部門では、「製品在庫」、購買部門では「資材在庫」です。これまでのように部門毎の個別システムで あれば「在庫」で通じたのですが、営業と購買を連携させようとすると「在庫」では、混乱します。 それぞれ「製品在庫」「資材在庫」を識別して定義する必要があります。その用語について、入力・処理・出力を5W2Hで整理 すれば、業務処理の要求仕様になります。このように、業務システム構築においては「業務用語」を大切に扱いましょう。

ITPro 記者の眼
●大学生は「情報システム部門」を理解しているか[2004年09月09日]

『コラム』

  ある大学の期末試験に出題されたものだそうです。記事では、 大学生でなくても高校生や中学生でも考えられると書かれていますが、当の現役システム部門の 部門長や中堅クラスは真剣に考えるべき問題だと思います。 しかし、私の周りを見ても、日々の開発・運用業務に追われて、目先のサービスを 提供するのに精一杯で、それに甘んじている人が多いように思います。

記事では、「システム部門の担当役員は次期社長と言われる人になってもらう」と ありますが、おそらく、それは他の部門出身者が、兼任するというのが実情であり、 今日現在、社内で情報システム部門の部門長が次期CIOやCEOと目されている 会社が、どれくらいあるでしょう? そのようなキャリアパスを社内に認知させるには、単に情報を提供し支援している だけではダメで自ら情報を戦略的に活用し、会社の財務諸表に好影響を与えることが できなければなりません。

さらに、情報および情報システムと財務諸表との相関関係を、経営陣や株主に理解 できるかたちで説明できなければなりません。

つまり、これまでは業務部門からの「売上アップやコストダウンをしたいのでシス テムを作って欲しい」という依頼に応えていたのを、「このようなシステムを創る ことで売上アップやコストダウンができる」というように企画し、成果を経営者や 株主にコミットし、それを実現していくという自主自立が必要になってきます。

各業務部門毎の個別改善では、行き詰まりつつある現在、企業の業務プロセスとシ ステムの全体を俯瞰し、全体最適解を提案できるのはシステム部門ですから、大き なチャンスでもあります。

それが、できなければ流通業界の「中抜き」による効率化・スピードアップは、シ ステム構築でも例外ではありません。すなわち、システム部門廃止、業務部門から ベンダへの直接発注です。

ITPro 記者の眼
●大半は「勘」や「経験」で見積もり[2004年09月10日]

『投稿』

  ソフトウェア工学が科学的なアプローチ(実験データの積み上げによる普遍的な法則や仮説理論の立証) ではないので、見積においても工学的な見積もり技法は存在しません。 工学は、科学の上に成り立つものですが、理論の裏付けとなる実験データが少なすぎるのです。

ソフトウェアの生産性・保守性・品質を向上するために発展してきたソフトウェア工学なのですが、 この35年間で、どれくらい生産性・保守性・品質が向上したのか数値で示されていません。 一部には、ほとんど変わらないか、むしろ悪化しているという報告もされています。

最新のソフトウェア工学を適用しても、人によって10倍も生産性が違ってしまうような状況では、 芸術品と同じで、信頼性の高い見積は困難です。 従って実績データベースも、人やチームが変わってしまうと変動が大きくなります。 見積精度を上げるなら、まず、人によって生産性が大きく変動しないような開発手法(生産技術)を ソフトウエア工学が確立する必要があります。 ところが、最新のオブジェクト指向やアジャイル手法をやっている開発チームでは、ますます見積り の信頼性が低下しているのではないでしょうか。

このような状況ですから、発注側である我々も何らかの自衛手段をとっておかないと、ベンダの見積 に対して、何ら反論もできずに「言い値」で発注するしかありません。

私の場合は、発注した各システムの発注額と画面、帳票、ファイル数、使用言語などをエクセルに 蓄積しています。このデータから、発注先別、言語別に1画面当たりの平均単価などを算出します。 この平均単価を元に、いろいろ交渉に応じます。 同じ会社、同じ規模、同じ言語でありながら、この平均単価と大きく異なる見積が出てきた場合は その理由を聞くようにしています。 明確な理由が無ければ、こちらの平均単価をベースに再度、見積を依頼します。 また、今回は「未経験者が担当するので」という理由などは却下します。 あくまで「会社の実力」で見積もってもらいます。

ITPro 記者の眼
●「見えないもの」と格闘する方法 [2004年09月02日]

『投稿』

  ITは見えないといいますが、そんなこともありません。建築で言う「柱」や「壁」は、ソースーコードです。ITの世界では、ソースコードはマネージャが見るものではないという風潮ですが、これでは、「柱」や「壁」を見ずに工事監理するようなものです。まともなマネジメントができるはずもありません。かの、マイクロソフトでは、ソースコードを読めない人はマネジャになれないそうです。3現主義に照らして言えば、あたりまえですね。ちなみに、モデルは抽象概念であり、これも3現主義に反します。よほど、抽象的概念を扱うことに長けた能力がないと、これで、実際の製品(コスト、納期、品質)をマネジメントするのは難しいでしょう。さらに、ソースコードを速読できる能力がマネジャには求められると思います。

 ただ、ソースコードを読むといっても、詳細に全てのロジックを解読する必要はありません。出来高を測るには、完成したソースコードの量を確認すれば良いし、品質は読みやすく記述ルールに沿って整形されているかを確認する。これは、言語知識も不要ですし、しかし、どんな言語にも共通に言えることです。また、どんな言語も英語を基礎としていることを考えれば、大まかな流れはカンタンな英語が読めれば、なんとなく理解できるものです。それで、流れが分からないようであれば、そのソースコードは保守性が悪い可能性があります。

−−−−−−−もっと読む(ここをクリック!)−−−−−−−