DXでアジャイルやるなら必読!
「変更を制する者がプロジェクトを制す!」



       ブ  ロ  グ

【著書】 Amazon「変更を制する者がプロジェクトを制す!」
Amazon「変更を制する者がプロジェクトを制す!」

もう大丈夫!変更に振り回されずに対処する方法



 あなたはシステム開発で変更に振り回されずにうまく対処できていますか?1.計画や要件定義を入念にやるので 変更はほとんど発生しない。2.変更は発生の都度、柔軟に対処できており何の問題はない。3.それとも。。。  あなたがもし、これまでシステム開発で変更に振り回され、ストレスを感じたり、疲れたりしているなら、 あるいは、これから変更が多発しそうな恐れがあり不安をかかえているなら、きっとこの本は役に立つことでしょう。

 なぜなら、かつての私がそうだったからです。新卒でシステム部門に配属されてから、これまで30年以上、 システム開発では変更、変更、変更との戦いでした。

 教科書はウォーターフォール型のシステム開発方法論が主流で、基本的な姿勢は変更を出すな!です。 そのため要件定義をしっかりやって固めたら凍結し、それ以降に出てきた変更は「招かざる客」というわけです。

 ところが実際のシステム開発では凍結したはずの要件、スケジュール、予算、人員とあらゆるものが変更され、 教科書とは程遠い惨状でした。長い間、教科書の理想と現実のあまりのギャップに悩みました。そして、なんとか 理想に近づけようと毎日、変更と格闘し、もがき苦しんでいました。

 そんなある日、気が付いたのです。先のことは誰も分からないという事実を。日程や予算はもちろん、要件さえ。 変更はあって当たり前、凍結とか、変更を出すなとか言う方が無理!という当然のような事実。 ウォーターフォールの教科書が示す理想は、幻想にすぎないと。そして、今はより先のことが分からないVUCAの時代 と言われています。VUCAとは、Volatility:変動性、Uncertainty:不確実性、Complexity:複雑性、Ambiguity:曖昧性 の頭文字をとった造語です。

 このような時代、DX(デジタルトランスフォーメーション)を推進するためにウォーターフォールに変わる アジャイル開発が注目されています。アジャイル開発の精神は「変更を受け入れる」ことです。 ええっ!?ウォーターフォールでさえ変更を抑止・制御できていないのに、変更を受け入れたらどうなりますか? あらゆる利害関係者が変更、変更、変更と当然のように頻繁に出して来たら、それこそカオスです!

 そこで提案です! ウォーターフォールのように変更を無き者にするのでもなく、アジャイルで無作為に変更を受け入れるのでもなく、 いかにすれば変更を制御することができるのか、その方法がここにあります。私が30年以上、もがき苦しんできた末に 到達した境地です。私の経験だけではなく、アジャイル開発やリーン開発、トヨタ生産方式、五輪書、孫子の兵法など、 変更に対処するための先人の知恵や知見も取り入れています。もし、あなたが私と同じように何十年かの歳月をかけ、 自らの経験と学習によって変更を制するスキルを身に着けたいと思うのであれば、この本は必要ないかもしれません。

 しかし、あなたがこの本を手にすることで、私が長い歳月をかけ経験し学習したことを、1時間ほどで共有することが できます。その上に、あなた独自の工夫を加えて、さらに新しい境地を確立することができるでしょう。 これからのVUCAの時代、システム開発に限らず「変更を制する者がプロジェクトを制す!」ことができるのです。

Amazon「変更を制する者がプロジェクトを制す!」



はじめに
「変更」は、プロジェクトの混乱を引起す主要因です。スコープ変更、要件変更、コスト変更、日程変更などの様々な変更、特に想定外の変更は、プロジェクトを失敗に陥れる元凶と言っても過言ではありません。このような変更が一切無ければ、プロジェクトは計画通りに進み、何の問題も無いはずです。しかし、現実にはITプロジェクトの70%が失敗していると言われています。その失敗の原因は、計画時点では想定しなかった、あるいは想定できなかった、意図する変更や意図しない変更によって、計画が狂ってしまうからに他なりません。 しかし、変更があったとしても、あらかじめ想定された範囲であれば、余裕を持って対処することも可能です。対処方法そのものを計画に盛り込んでおくこともできるでしょう。そこで、プロジェクトを襲う様々な変更に振り回されず、能動的な攻めの姿勢を持って、事前に変更を想定していくことがプロジェクト成功への道です。

本書では、このような考え方に基づいて、変更に適切に対処する為の『変更管理』を紹介します。また、「兵法」には戦闘における攻防の変化に対処し勝つために先人が考え出した知恵が多々あります。戦闘では、変化を制したものが勝つといっても過言ではありません。 戦闘での「攻防変化」とITプロジェクトの「変更」には共通点も多く、応用できるテクニック、心構えや勘所等も随所で紹介していきたいと思います。

目次
はじめに
1. 混乱の原因となる「変更」とは
2. 変更によるプロジェクトへの影響
3. プロジェクトの主要成功要因
4. 主な変更内容とリスク
5. 攻めの変更管理プロセス
6. 変更に対する危険予知
7. 変更に対する影響分析/優先付け
8. 変更の実施
9. モニタリング
10. 是正処置/改善
11. 孫子の兵法 九変篇
あとがき








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

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



 『企業システム戦略研究会オフィシャルブログ』


@IT
●構成管理 configuration management / コンフィギュレーションマネジメント
/ 形態管理 / 型式管理 / 『ソフトウェアBOM』


『コラム』

 ”構成監査は構成記録が正しく行われているかを確認”

 構成管理の難しさは、この一言に集約されます。

 ”構成記録が正しく”という意味は、

 要求事項と設計図書と製品(製造記録)とが一致していることを、仕様変更や設計変更も含めて保証するということです。

 保証するというのは、要求事項と設計図書と製品との間で、部品一点毎に、トレーサビリティが確立されているということです。

 航空機の場合、1機あたりの部品数が、数百万点と言われていますから、それらが間違いなく、要求事項が製品に反映されていることを保証するのは、かなり大変な作業です。

 ISO 10007「品質マネジメントシステム − 構成管理の指針」

 ”構成管理とは、製品の構成を文書化するものである。
  構成管理は、ライフサイクルの全段階で、識別及びトレーサビリティ、その物理的及び
  機能的要求事項の達成状況並びに正確な情報へのアクセスをもたらす。”

 これは、「言うは易く、行うは難し」です。

 数百万点もの部品に対して、要求事項=設計図書=製品(製造記録)の照合を人間系で行うのは、不可能に近いため、コンピュータを使用します。もちろん、製品によっては、設計に描画された図形情報と製品を、直接、人間系で目視確認し、照合を行っている場合もあります。

 コンピュータで、部品番号を識別子として、各々のデータを照合することになります。

 各段階で部品情報を、部品表に記載し、BOM(Bill Of Material)と呼ばれるデータベースに格納します。

 ※BOMの中身


 設計図書はEBOM、製造指示書はMBOM、製造記録はQBOMにそれぞれ格納し、これらをコンピュータで照合します。

 ここで、重要となるのが、照合のキーとなる番号体系です。

 例えば、設計図書に記載されている部品を識別するための番号体系と、製品に取り付ける部品を識別するための番号体系には、  一貫性を待たせる必要があります。各要素に変更が発生した場合は、改訂履歴を記録し、番号には、改訂符号を付与して識別します。  照合は、この改訂符号まで含めて行うことで、全ての変更が、製品に反映されたか確認します。  変更の度合いによっては、全く別の番号を付与することで、反映を確実にすることもあります。

 ところで、航空機は、製品を構成する部品が数百万点あり、大規模システムといわれていますが、情報システムは、どうでしょうか?

 ソフトウェア部品を、どう捕らえるかにもよりますが、モジュール化の原則である、「1モジュール1機能」とすれば、ソフトウェア部品の最小単位は、1命令行と考えることもできます。

 例えば、給与計算という要求事項に対する、部品は、給与計算式の命令になります。

 そして、ソフトウェアの場合、この計算式の1文字でも間違っていれば、給与計算システム全体が保証されません。このように考えると、情報システムの部品点数は、数百万〜数千万点にも上ることになります。組み込みソフトウェアでは、自動車で700〜1000万行、航空機では2000万行以上に及びます。

 例:30行/部品x30万個=900万行

 ISO 10007「品質マネジメントシステム − 構成管理の指針」に忠実に従い、要求事項=設計図書=製品(製造記録)の一致を、  コード1行単位で実現し、トレーサビリティを確立すれば、ソフトウェアの品質は格段に向上するはずで。  そのためには、上述したようにコンピュータによる照合は、必須であり、そのためには、製品を構成する部品を識別するための番号体系に、上流から下流まで一貫性を待たせる必要があります。

 要求仕様書の各要求事項に識別番号をつけ、その識別番号の単位で、設計図書を起こします。そして、その設計図書の単位で、コードに識別番号を付与します。モジュールは、各階層ごとに、結合設計書を作成し、その単位に識別子を割り当てます。こうすることで、システム全体−要求仕様− 結合設計書−単体設計書−コード(単体試験)− モジュール(結合試験)−システム(システム試験)プロセス(運用試験)が一貫してトレースできます。

 そして、これらの情報を、『ソフトウェアBOM』(Software BOM)としてデータベース化することで、コンピュータ上で容易に一貫性を保証することができます。

 ちなみに、BOMは一般には組立て製造業の生産管理、MRP(所要量計算)に使われるデータベースとして認識されて、解説などされてます。 しかし、構成管理としても中心的なデータベースであり、ソフトウェアも組立て製造業に近いので、構成管理に応用することが可能と考えられます。

 BOMの基本機能として、ある要求事項が変更された場合、どの設計図書、どのモジュール、どのコードに影響が及ぶか、瞬時にトレース(正展開)が可能です。また、コードから設計図書、要求事項へと、逆にトレース(逆展開)することも可能です。コストを積算することも可能です。

 『ソフトウェアBOM』を構築すれば、このように多発する変更に対しても、確実にISO 10007の要求事項を満足することができます。品質だけではなく、変更の影響が正確かつ迅速に把握可能となれば、プロジェクト管理におけるコスト・納期の管理にも有効です。

 この構成管理のプロセス(仕組み)は、非常に重たいプロセスであり、アジャイルとは、正反対の指向にも思われます。

 しかし、このプロセスを確立せずに、数百万行もあるソフトウェア製品に対して、ISO 10007の要求を満足することは不可能です。

 むしろ、アジャイルで、頻繁にイテレーションを繰り返し、変更を加えていく中で、ライフサイクルの全段階で、「要求事項と製品の一致性」を保証していくには、必須のプロセスです。

 こういったプロセス無くして、顧客を常駐化させ、頻繁にフィードバックを得る(顧客がOKと言えばOK、というスキーム)で、 要求事項と製品の一致性を担保できるのか、はなはだ疑問です。

 航空機やロケット、プラントなど大規模システムで、顧客に部品や組立て途中で見せて、良い悪いを判断してもらい、その都度、変更を加えるというようなやり方は、想像もつきません。

 これだけ、情報システムが社会インフラ化している現代、『ソフトウェアBOM』の構築は、もはや必須であり、これ無くして、ソフトウェア品質の向上はありえません。

ソフトウェア開発の創造性を「芸術」に近いという考え方も分かりますが、根本的に異なるのは、芸術家は他からの要求事項に基づいて創作しているわけではないこと、作品は信頼性や保守性において問題にならないことです。これらを組織的に精度高く管理することと、ソフトウェアの創造性は、必ずしも背反するものではありません。

 ワープロを使い、自然言語のみで設計図書をかいて、要求事項に識別番号も付与せず、モジュールやコードの識別番号は、プログラマ任せで、個人ごとにバラバラ。試験記録と要求事項も一意に識別番号で照合できない。このような状況からは、早く脱しなければいけませんね。




ITPro
●新業務をモデリングするとき、業務の担当組織まで決めてはいけない

『投稿』

 日本では、実行組織と業務機能は同時に考えるべきでは?

私の現場的な感覚では、仕事の仕組みが変わるからこそ、あるべき姿とそれを”誰が”実行するかを抱き合わせで、 徹底的に議論すべきでは?特に日本の組織では、誰がそれを実行するかによって、その組織にとっての あるべき姿も変わってくるようです。

 それを”分けて”、あるべき姿だけ考えるのは、単なる分析遊びに終わる可能性も。誰が実行するかを 決めないから、あるべき姿が絵に描いた餅になり、5W1Hがあいまいなままです。

 実例として、生産スケジューラを導入する際に、運用としての”あるべき姿”は中枢組織としての 生産統制組織が必要ということで合意していたのですが、結局、”誰が”その生産統制組織の役割を 担うのかを最後まで決定できずに、結局、現場に押し付けてしまいました。その後、生産スケジューラが どのような運命をたどったか、想像に難くないところです。

 実行組織と業務機能を統合的に考えることと、既存の組織にとらわれるか否かは別の次元の問題で、 とらわれる組織は、分けて考えても、最終的に保守的に落ち着きます。これを、”戦略は組織に従う”という 言葉が示唆しています。


ITPro
●鶴は千年、亀は万年、システムは百年

『投稿』

 記事冒頭の「プログラムが傷む」ということと、インフラを仮想化するということは、明らかに論点が違うと思います。インフラを仮想化しても、「プログラムの傷み」は救えません。これを救うのは、コンポーネントの構造設計と独立性確保です。

特に企業にとって重要なのはビジネスロジックであり、ここをOSやミドルウェア、周辺機器と独立させることです。そして、次に重要なのが保守技術です。せっかく開発時に構造化し独立性を確保しても、改修のたびにコードを汚していくのでは、持続性を確保できません。

そのためには、独立性を破壊するような、バイパス手術をやめることです。保守は、開発よりも時間的余裕が無いので、ついついコンポーネント間を安易にジャンプするコードを書きがちです。また、他人の書いたコードを読みたくないプログラマ心理もそういったバイパスコードを生みます。

私は、他人の書いたコードでも短時間で読解し、元のアーキテクチャ構造を破壊せずに改修できるような、プロ中のプロといえるプログラマーも、スーパープログラマーだと思いますが、日が当たらないので見つけるのが大変です。

腕のいい大工さんは、新品同様に補修工事(継ぎ木)などできて、それに誇りを持っています。保守に対しプログラマが、記事冒頭にあるように「作り直したほうが安い」と思っている限りは、システムを100年存続させることは難しいと思います。

そこで、マスコミは開発プロジェクトの成功事例ばかり記事にせず、保守で30年システムを維持しているような事例をとりあげ、保守してきたプログラマーをヒローとすること。そして、社内でも大々的に匠として表彰・評価することを提案します。

顧客も「作り直したほうが安い」というところよりも、既存システムを改修すれば大丈夫ですというところを選ぶべきです。 どうしても、どうせお金を出すなら新しいものをという心理は分かりますが、既存システムに蓄積してきたビジネスノウハウを失うことの損失や開発・大量生産による経営負荷・環境負荷を冷静に考えて見ましょう。

また、保守スーパープログラマを育てるには、速読をやることです。速読をやると、読解力が飛躍的に早くなるのはもちろん、視野が広がりるので広範囲に全体を見通して最適な改修方法を見つけられるようになります。速読訓練で、迷路の早抜けがありますので、それで能力向上を実感できます。速読では、これを「虫の目」(線)から「鳥の目」(面)になるといいます。


ITPro
●アジャイルはウォーターフォールよりも難しい

『投稿』

いったい、アジャイルに対し何が望みでしょう? 簡単な手法? それとも、効果的な手法? まさか、両方?
トヨタ方式を導入しようとして成功する工場は1%程度だそうです。 成功事例や書籍を読んで「かんばん」を導入すれば、在庫が激減すると思い込んでしまう。そして、いざやりはじめて難しいことに気がつき、道半ばで投げだしてしまうそうです。

成功事例の導入段階での難しさをきっちりと取材して記事にせず、美味しいところだけを記事にするマスコミとそれを鵜呑みにする国民性ゆえでしょうか。

ものには適材適所があるはずです。欧米の大家が言っているからなんだというのでしょう。虚実を見極める眼力を持ちましょう。

五輪書 地之巻 兵法に武具の利を知るという事
http://www.geocities.jp/aoshima_systems/mag/Vol00128.html


ITPro
●頑張るだけのレビューはもう限界

『コラム』

 ”頑張るだけ”と言いますが、いったい何を頑張っているのでしょうか。長時間、誤字脱字を探すことでしょうか、それとも、設計の妥当性について延々と議論をすることでしょうか。

そもそも、”重大な欠陥”とは、何でしょう。

これを、きちんと定義せずに、頑張ったり、目的の再確認したりしても、結局、何をすればよいのか具体的な改善につながりません。ソフトウェア工学の教科書にしても、このようなレビューに関する記事にしても、レビューの目的は、前工程での成果物の品質を高め、後工程での手戻りを少なくするために”欠陥”や”ミス”を発見することだと書かれていませんか。私は、この”欠陥””ミス”という表現にそもそも問題があるのではと考えています。

レビューアは、”欠陥”を発見しようと成果物を読み、頭を使うことになります。そうなると、成果物(文書)の欠陥とは、どうしても誤字脱字が主体となってしまします。また、データベース設計に欠陥があるかないか、これを解決するのには、議論の時間も長くなります。レビューされる側も、する側も、”欠陥”という言葉にネガティブな印象を、潜在的に受けます。そうなると脳があまり活発に仕事をしないのではないかと思うのです。

ここで、レビューの目的をもう一度、よく考えてみましょう。それは、”後工程での手戻りを少なくする”ですね。後工程とは、将来のことです。手戻りとは、品質・納期・コストへの損失です。すなわち、将来に起こりえる損失です。これを、”リスク”と言います。このように考えると、レビューで発見すべきは、”欠陥”(すでに発生してしまった事故)ではなく、”リスク”(将来に起こりえる損失)です。そして、重大な欠陥とは、言い換えれば、プロジェクトの品質・コスト・納期(QCD)に多大な影響を与えるような損失です。また、システムが社会にもたらす大きな損失です。

このような記述、設計では、後工程の作業では、このような損失が発生する可能性があるのではないか。さらには、運用開始後に、このような損失が発生する可能性があるのではないか。(”この設計は欠陥である。”とは言わない。)

※特に注目すべきは、”要件と設計のトレーサビリティ”つまり、要件が漏れなくダブり無く設計されていること。そして、”アーキテクチャ”です。この2点に重大なリスクが潜んでいます。このようなリスクは、成果物を穴の開くほど眺めて欠陥を探しても、決して出てこない指摘事項です。頭の働かせ方が本質的に異なります。皆で、リスクを沢山発見することが、プロジェクトのQCDを守り、顧客を守り、そして、自分たちを守ることになるわけです。決して、欠陥やミスを発見して、痛い思いをさせたり、したりするのではありません。

次に、それぞれのリスクの強度を評価します。

強度 = 発生確率 x 影響度

リスク強度大のものから優先的に対策します。そして、乱暴な言い方をすれば、後工程で発生してもリカバリ可能なリスク強度が小さいものは、”受容”して、先送りすることも可能です。例えば、画面の色や項目配置など。

さらに、もう一歩進んで、QCDを改善できる余地があるかないか、それもリスクとしてピックアップします。この領域では、すでに”欠陥”探しではなく、さらなる付加価値の発見です。この設計内容は、このように工夫すれば、QCDを改善できるのではないか、ユーザの利便性が増すのではないか。この域まで達成できれば、レビューもきっと、楽しく、前向きなものになるに違いありません。ここで、重要となるスキルが、先見性や洞察力、そして、なにより危険予知能力です。

もう一つ、長時間化の問題は、レビュー会議での観点にあります。例えば、リスク強度大の指摘事項として、データベース設計があります。ここのリスクは、アーキテクチャや性能に影響が大きく、手戻りが発生すれば、プロジェクトを危機に陥れかねません。それではと、データベース設計の妥当性をレビューで検証しようとすれば、多大な労力を要することになります。最悪の場合、レビューをしているのか、設計作業そのものをしているのか、はたまたデータベース設計の講義を受けているのか分けが分からなくなってしまいます。その挙句に、性能に関しては、実装してみないと分からないなどという結論になったりします。

レビューが、このような結果にならないために必要なのが、システム監査の視点です。それは、第三者的に設計作業の妥当性を確認することです。例えば、データベース設計であれば、個別の設計内容が妥当かどうかという観点以上に、正規化されているか、索引設計は性能目標を達成できるか、業務要件との整合性はあるか、拡張性を考慮しているかというような観点です。JIS X0129 ソフトウェア品質特性(機能性、信頼性、使用性、効率性、保守性、移植性)などを参考にチェックすれば、網羅性が高まり、レビュー品質が属人的になることを防止できます。その上で、例えば、索引設計は性能目標を達成できるかどうかに疑問があるという場合、それを指摘事項(リスク)としてピックアップします。そして、再度、設計を見直すのは、レビューではなく、再設計検討会として、別に設定します。こうすれば、レビュー時間がむやみに長くなることを防止できます。

要件定義、設計、テストなど、一通りのスキルがあれば、レビューをしなくても、ソフトウェアはつくれます。スキルの高い人ほど自信があり、レビューなんて必要ない、時間の無駄と考えるかもしれません。しかし、その結果が成功率30%なのです。対策として、新手法やスキルアップも大切ですが、そろそろ、レビューは欠陥探しの場ではなく、リスク発見の場であり、リスク管理により利害関係者(もちろん自分も)を守るものというようにマインド・チェンジしてはいかがでしょう。誰が? まずは、将・リーダです。ITプロジェクトは、兵が疲弊しています。

 孫子の兵法 始計篇 その5「将とは、智・信・仁・勇・厳なり」

より詳しいお話は下記の書籍とセミナーで。

 ★ドキュメント・レビュー!!   要求仕様書・設計書のレビュー実践とチェックポイント

 ★100の失敗事例に学ぶ !!   ITプロジェクトの危険予知訓練

  書籍

  セミナー


ITPro
●「育てる」GE、「育つ」グーグルのウソ

『コラム』

人材育成を、(広義の)教育システムと見れば、

 (1)採用時の人材が、入力  (2)育成の仕掛けが、システム  (3)育成後の人材が、出力

となります。

このモデルでは、GEは(2)のシステムに主眼をおき、グーグルは、(1)の入力に主眼をおいている と考えられます。いずれにしても、入力(採用人材) < 出力(育成人財)とするには、 入力とシステムの両方がそろっていなければ、ならないはずです。 GE流がシステム主導であっても、それなりの挑戦意欲のある人材を採用する必要はあるでしょう。 グーグルにしても、挑戦的な人材を採用して、その後、放置しておけば勝手に人財となるほど 甘くはないと思います。

人間の好奇心や挑戦意欲を、何十年も維持させることは容易ではありません。 日本にも有名大学卒業生ばかりを採用していますが、10年いたらバカになるという大企業もあります。

人材が人財になり、活躍している組織には、採用ノウハウや育成システムだけではない、 ”人が育つ土壌”が不可欠なのだと思います。 どんなに良い苗を植えて、最新の技術で育てても、土壌が良くなければ、良い野菜は採れません。 人材育成も、これと同じことが言えるのではないでしょうか。

それでは、人材育成における”土壌”とはなんでしょう。 それは、そこに集う人達です。

五輪書 地之巻 大工にたとへたる事 統領の心がけ

まず、上に立つ人達が、各人の持ち味を良く知った上で、適材適所に配置し、興味を持って能力を活かせるような 仕事をさせていること。画一的に、人を材料扱いしていたら、育成はできません。単に消耗するだけです。 そのように、人を消耗しているような組織が、存続できることは考え難いです。

システムは、入力−処理−出力のサイクルですから、入力 > 出力 となっているような組織は、 採用ホームページで、どんなに良いことを謳ってもいずれ、入力が先細り組織も消耗していくことでしょう。

孫子の兵法 地形篇 その4 卒を視ること嬰児の如し

そして、すでに在籍している人達(上司、先輩、同僚等)が、新しく採用されてきた人達に対して、 嬰児の如し、接してあげられるかどうかです。 つまり、我が子の成長を見守り、慈しむように、厳しくも、暖かい指導を、日常業務の中でできるかどうか。 周りが関心を持って新人を育て、その新人が、次の新人を育て、そのまた新人が、次の新人を育てる。 それが自然にできる組織が、人材育成における良い土壌です。

どんなに良い採用をして、良い教育システムで研修をしても、日常業務の中での切磋琢磨や相互扶助が無ければ、 すぐに、若葉は枯れて萎んでしまうことでしょう。

こうしてみると、自分以外の他人に無関心であったり、気軽に何かを聞けないような雰囲気だったり、 学歴や年功だけで人物評価したり、あるいは、逆にすぐに手っ取り早く答えを教えて、 その意味や背景の着いて説明もしなかったり。人が育たない土壌であるような組織は、 少なくないのではないでしょうか。 仲良しクラブである必要はありません。むしろ、仲良しクラブは、真のプロ育成を 阻害する要因もあります。しかし、冷たいの(無関心)は、もっと困ります。

一時の業績評価制度により、関心事は、自分の業績だけ。後輩や同僚の育成に時間を割いて、 何の特になるという風潮も出てしまいました。これでは、人材育成ができる良い土壌とは、言えませんね。

組織員は、トップの背中を見ています。そして、それまでの自分の処遇を忘れません。 トップが、組織員を良く見ている近い存在であると感じ、自分が、周りから育ててもらったと真に思っていれば、 新しい人にも、自然に同じ様に接するでしょう。逆に、どんなに立派な教育制度や研修が充実していても、 トップが、そういった整備をすることのみに注力し、組織員とのアナログで泥臭い人間関係が希薄であるという 感じを持たれていたり、周りから自分は何も与えてもらっていないと感じていたりすれば、 当然、同じ様な態度で新人と接することでしょう。

このように、人材育成の土壌は、何代にもわたって、組織の中に存続する人達の中に受け継がれていくことで 培養されていくものです。したがって、一朝一夕に良い土壌はできません。

負のサイクルに入っている場合、これまでに負の要素を持った人達が沢山いて、 土壌汚染からなかなか抜け出せません。 腐ってしまった土壌は、いったん土を入れ替えて、耕しなおさないと、せっかく良い苗を植えても、すぐに悪くなり、 その悪くなった苗が、さらに土壌の質を悪化させるので、とてもやっかいです。

このように人事改革は、とても大仕事でリスクも高いのですが、だからこそ、ここに手を入れないで、 ウチの社員は優秀(な人を採用している)だから心配ないなどと、甘く考えているような組織改革は、 骨抜きだと言われてもしかたありません。


CIO
●いざ人事考課、どう臨むのが良い?

『コラム』

企業システム戦略における、人事考課は、構成員のパフォーマンスを評価し、 モチベーションと能力の向上につなげる、重要な要素です。

どんな仕組みもシステムも、結局は、”人”が、動かすものです。 人事を適切に運用しなければ、企業システムの運用もうまくいきません。 私は、人事考課をする立場でも在り、される立場でもあります。 まだまだ、自分の業績を上手にアピールできる人が、 少ないと思います。 日本人特有の”控えめを美徳”とする文化でしょうか。 そうかと思えば、自分がどれだけ”頑張ったか”を切々と訴える人もいます。

人事考課には、2つあって、一つは、業績評価、一つは、能力評価です。 前者は、業績目標に対して、どれだけ達成できたか、そのために、どんなプロセスを実行したかを、 客観的に自己評価するのがポイントです。 そして、その評価結果を事実に基づいて、プレゼンテーションすることになります。 プレゼンテーションは、売り込みと同じです。 自己満足的な売り込みではなく、組織の業績に対して、どんな貢献をしたか、 その付加価値はなにかです。 いいかえれば、顧客指向での視点が必要になります。

人事考課は、各自にとって最も重要なプレゼンテーション、自己売り込みの場である という認識が、まだまだ希薄です。 ”プレゼンテーションは、演壇に立ち、パワーポイントを使った発表のことである。” という固定観念があるのでしょう。

人事考課でのプレゼンテーション、すなわち売り込みに失敗すれば、自分を買ってもらえない という認識を、どれだけの人が持っているでしょう。

五輪書 地之巻 兵法の道 大工の心得

にもかかわらず、アンケート結果などを見ると、”自分は、正当な評価を受けていない” と感じている人が、多いようです。 それは、自分の売込みが失敗しているということを意味しているのだと気がつかないのです。 ここでも、顧客指向の視点が失われています。

つまり、こんなに良い商品なのに、こんなに開発に苦労・努力したのに、 なぜ、お客は、その良さが分からない? 買ってくれないのか? といっているのと同じことなのです。 一方、人事考課をする側の人においては、時に、業績評価と能力評価を混同してる人もいます。 業績は、良い時も悪い時もあります。 能力があっても、いつも業績が達成できるとは限りません。 スパースターにも、スランプの時は、あります。 逆に、能力的には不十分でも、業績をあげられることもあります。

だからこそ、業績目標と業績実績の対比で、客観的に評価することになります。 客観評価だからこそ、評価もしやすいと言えるでしょう。 業績が高いから、能力が高いと混同すると、評価を誤ります。 その能力評価ですが、これが難しい。 人が人の能力を、適切に評価できるかという問題は、昔も今も同じです。 勢い、年功や学歴での評価に走りがちです。 そうやって評価されて、人事考課される側から、人事考課する側になった人は、 やはり、同じように年功や学歴でしか、人の能力を評価するすべがありません。 この弊害は、組織を硬直化させることは、よく知られたところです。

とはいえ、成果だけで、昇格を判定すれば、たまたま、成果が出たけど、 能力は高くない人が昇格するリスクがあります。 その他にも、様々な弊害が出てきています。 よって、この両方を合わせて評価するのが妥当な線ということになりますね。 能力評価をより客観的に行うために、各段階で要求される実務能力を定義しておき、 それと照合することで能力評価を行うという方法もあります。 これが適切に運用されるには、やはり、使う側(人事考課する側)の意識改革も必要です。

せっかく能力判定基準に照合して、能力ありと判定されても、 いやいや、まだ、年功や学歴が云々だからと評価をねじまげてしまっては、意味がありません。 人事部門が新しい人事考課制度を導入して、組織の活性化を図ろうとしても、 その運用を各部門に任せきりにしていると、このように適切な運用がなされず、 いっこうに組織改革はできないことになります。 なぜなら、先にも言いましたように、各部門には、それまでの古い人事制度で、 評価を受けてきた人が沢山いるからです。 その人達の意識改革無くして、新しい人事制度(システム)だけ導入しても、 いとも簡単に、骨抜きにされてしまうのです。 皆さんの人事戦略、人事改革は、進んでいますか。 人事制度は、意図したように適切に運用されているでしょうか。

人事の問題に手を入れない、経営改革は本気ではないと言われるように、 企業システム戦略においても、人事は重要課題です。 最初に書いたとおり、どんなシステムも、仕組みも、それを動かす人が変わらなければ、 人を変えるために、人の仕組みを変えなければ、結局、根底は何も変わらないからです。 すなわち、新しいシステムも、仕組みも機能せず、面従腹背で、容易に水面下で骨抜きにされてしまう 恐れがあります。

それが、組織的リスク(内部統制リスク)で、 人事制度に良く表れます。


ITPro
●(IT投資の)本当の意思決定者は誰か

『投稿』

CIOオフィスとは別のガバナンス

経営と情報をつなぐ新しい価値、ミッションを持つCIOオフィスの創設もよいですが、内部統制・内部けん制の意味から、システム部門と経営企画部門と事業部門の3者による意思決定機関(審査会)方式というやり方もあります。

この場合、ITベンダは、どこか一箇所(CIOオフィス)を口説けば事足りるという仕組みにはなりません。ソリューションを売り込むには、システム部門と経営企画部門と事業部門の3者をヒアリングし、その利害関係を整理し、全体最適な提案をしなければなりません。さもないと、システム部門に行けば、経営に関しては経営企画部門に聞いてくれ、経営企画部門に行けば、ITに関しては、システム部門に聞いてくれ、事業部門に行けばITはシステム部門に、経営判断は経営企画部門に聞いてくれとタライマワシにあうのがおちです。

PMBOKでもステークホルダ分析が重要となってきているようですが、特定の利害関係者だけを口説けば商売ができるというのも安易ではないでしょうか?特に、ハードウェアと異なり、情報システムは利害関係者が多岐にわたり複雑です。

したがって、意思決定者が”見えなくなっている”のは、システム部門が弱体化したからではなく、ホスト一極集中の単純な昔(システム部門だけ口説いていればよい時代)に比べ、顧客のIT経営環境が複雑化したため、ITベンダの提案能力が着いていけなくなっているのかもしれませんね。利害関係者や売り込み先(ターゲット)の分析は、提案書作成の第一歩(マーケティングの初歩)だと思います。


ITPro
●完了報告書の作り方

『投稿』

報告書を組織学習のために再利用する方法

「プロジェクト評価の反省点」では、失敗の”事実”だけでなく、そこに至る経緯や兆候を振り返り、「危険状況」として記述します。この危険状況を読んで、そこに潜む危険や危険要因を予知し、対策を考えるのが危険予知訓練です。危険予知能力が高まれば、同じような失敗を回避するリスク管理を効果的に行えます。

こうして書かれたのが『ITプロジェクトの危険予知訓練 100の失敗事例に学ぶ !!』です。

また、対策は、分かりやすい標語にして、リスト化すれば、レビュー用のチェックリストとしても使用できます。報告書を報告だけの目的で終わらず、貴重なノウハウとして再利用できれば、形骸化も防止できるでしょう。実際の失敗から学んだ対策をチェックリスト化してレビューを行えば、レビューも形骸化・儀式化・空回りしないでしょう。

こうして作成された40チェックリストが
『ドキュメント・レビュー!!  要求仕様書・設計書のレビュー実践とチェックポイント』です。


ITPro
●設計レビューが形骸化していませんか?

『投稿』

記事にあるように有効なレビューを行うために、目的を再確認してみることは意義のあることです。さらに、確認だけではなく、再考してみるのがよいでしょう。

レビューは、”欠陥”の除去(品質向上)だけではなく、将来(後工程〜運用段階)に発生しうる品質、コスト、納期に対する危険(リスク)を予知し、対策を講じるためにあるリスクマネジメントの重要なツールであると考えられます。誰しも”欠陥”は嫌なものです。しかし、その欠陥が引き起こすリスク、プロジェクトの危機にまで考えが至れば、指摘するほうも、されるほうも前向きに取り組むことができるのではないでしょうか。

チームが前向きにレビューに取り組むことで、欠陥やリスクだけでなく、付加価値を高めるような指摘(例えば、よりよいユーザインターフェースなど)ができれば、さらにレビューの有効性は高まります。以下は、その具体的な実践方法に関する書籍とセミナーです。

『ドキュメント・レビュー!!  要求仕様書・設計書のレビュー実践とチェックポイント』

『ITプロジェクトの危険予知訓練 100の失敗事例に学ぶ !!』

レビューは、羅針盤


TechTarget
●“やっつけ”保守開発からの脱却を図るためには?

『コラム』

そもそも”保守開発”とは何か

 “やっつけ”保守開発が問題なら、保守 と 開発 を、しっかり分別することです。そうすれば、保守は、“やっつけ”でも良いのです。保守以外は、開発です。既存のシステムに機能を追加するのも開発です。開発は、必ずしも新規であるとは限りません。

 そのような開発を、保守として“やっつけ”で行うことにそもそも、大きな問題が在ります。

 税務上の観点から言えば、保守は修繕費(経費)であり、それ以外は、資産化対象となります。ここで、資産化する必要があるのは、将来の収益を目的とする機能の追加なども含みます。修繕費で良いのは、明らかに収益の獲得にならないものです。例えば、運用上のコードや条件の追加、表示方法変更などです。あるいは、法改正対応やプラットフィームの老朽更新に伴うソフトウェアの移行や修繕などです。

 すなわち、保守とは、現状のシステムを効果的・効率的に運用するためにベストな状態に保つことであり、資産価値に変更を加えるような機能追加などではないのです。一般的に、これらの作業はアーキテクチャや基本構造は変更しないため、“やっつけ”でも、問題とはなりません。むしろ、開発と同じように重たいプロセスや統制は、ビジネスへの迅速な追従の足かせとなりかねません。

 “やっつけ”保守からの脱却を図ったあかつきに、ソースコードとドキュメントは、バッチリ。しかし、ビジネス対応スピードはガタ落ちでは、本末転倒、シャレになりません。いくら道具をピカピカに磨いても、必要な時期に間に合わないのでは、無用の長物です。

 そこで、“やっつけ”でも、コードを汚さないようにするには、ひとえに保守技術者の腕と心構えしだいです。ここで、保守を行うのは、プログラマではありません。保守では、短期間で既存コードを解読し、アーキテクチャを理解し、どのようにコードに手を入れるか、瞬時に最適解を得なければなりません。これは、アークテクト+SE+プログラマの高度なスキルが必要です。つまり、保守は優秀なマルチプレーヤでなければできないのです。保守技術者は、極めて高度の専門職であり、プロ中のプロです。

 情シ部を戦略部門化など考える前に、こうしたプロ中のプロを育成し、適切な処遇を与えなければ、信頼が足元から崩れ去ります。ところが、保守に初級プログラマをアサインし、ここで下積みをさせてから、開発へと考えているケースがすくなくありません。(企画担当には、そもそも保守の経験さえもさせない)しかも、指導者が修正したコード(現物)をレビューせず、放任しているのです。開発は花形、保守は地味という誤った認識が諸悪の根源かもしれません。

 システムのライフサイクルで2/3が保守なのにです。

 メインフレームのシステムはレガシと揶揄されながらも20年以上も動いているのですが、オープン系は、10年持たないのです。つまり、オープン系をやりたがる若い技術者を、短期開発に次々と投入し、メインフレームの保守技術者並にプロ中のプロとして長期的な育成をしていないからです。そのため、“やっつけ”仕事=“やっつけ”ソースとなり、コードが汚れてしまうのです。

 私は、保守を20年以上やっていますが、開発に比べて、保守こそが大人のプロの仕事だと思います。ビフォーアフターでも、リフォームの匠は素晴らしい。まさに、彼らの仕事には、いぶし銀の渋さがあります。また、技術的には優秀であっても、心構えが低いと、これもコードを汚す結果となります。例えば、ベテランでも保守という仕事に誇りややりがいを見出せず、“やっつけ”手直しをしている場合などです。

 過去に、ユーザの要求に対して、既存コードを解読し、最適化された改修をすれば、たった2〜3行の条件を追加すればことたりるのに、リスクを恐れた保身とコード解読の手間を惜しんで、ユーザの要求した仕様書どうりにバイパス手術し、ほとんど既存と類似のコードをツギハギしたケースを知っています。その時は、本番移行前に私がコードをレビューして指摘し修正させましたが、大いに”速読”が役立ちました。

 ------ 速読とソフトウェア保守 -------------------------
 http://www.geocities.jp/aoshima_systems/taiken.html#soku

 指導者や管理者がコードをレビューしないのは、その時間が無いのが主因です。あるいは、保守ごときは担当者に任せておけば事足りると考えているフシもあるのでしょう。保守をやればやるほど、保守性が悪化するという悪魔のサイクルに、こうして陥っていくのです。保守のマネジメントを行う立場にあるなら、速読は必須であり、コードレビューは必須です。単にアウトプットが要求どうりならOKではなく、如何にコードを汚さず、最小の変更で要求を満足させるか、美的センスをもってコードレビューする必要があります。

 それから、私が考える“やっつけ”保守では、ドキュメントの保守は不要です。なぜなら、保守範囲のコード修正であれば、ドキュメントに反映せず、コードを 唯一無二の正とすべきです。細々とした条件追加や運用改善を全てドキュメントに反映し、コードと一致させるのは困難であり、かつ、ムダです。ドキュメントを改訂してからコードを修正せよというのは、あるべき論であり理想ですが、保守現場からすればナンセンスです。明日までに条件を追加して欲しいというユーザに、”まず、ドキュメント改訂してレビューしてから、、、”そんなことでは、とうてい仕事になりません。

 コードとは、そもそも、プログラミング言語で記述されたドキュメントそのものなのです。
 コードを読めば、変更内容の全てが分かるようにしておくことが第一です。


 ドキュメントの改訂が必要になるのは、アーキテクチャの変更や機能追加があった場合です。これは、既存のコードを解読しても分からないからです。しかし、この規模は、すでに保守ではありません。開発として、きちんとしたプロセスを適用すれば、“やっつけ”のような間違いは起こりません。保守でないのに、保守として“やっつけて”しまうから“やっつけ”ではすまなくなるのです。

 このような問題を引き起こさないためには、それぞれの組織が有する保守技術者のレベルとリスクを見極め、どこまでを保守でやるか、どこから先は開発とするか、案件の”切り分け基準”を明確化することです。”保守開発”というグレーゾーンは極力排除しましょう。これは、JSOXのプログラム変更管理でも要求されています。この切り分けによって、適用するプロセスや統制が異なります。特にJSOXのプログラム変更管理で、職務分離や承認証跡、プログラム変更履歴の確保とモニタリングを厳しく要求され、監査されるのは、保守です。
 なぜなら、保守は”やっつけ”で行われるからこそ、不正のリスクが高いと考えられるからです。

 だからといって、保守を”やっつけ”でやってはならないという不条理な要求は、JSOXでもしません。
 そのかわり、統制をしっかりしましょうと言うわけです。


ITPro
●情シ部は情報戦略部門になれるのか?

『投稿』

そもそも情報戦略は必要でしょうか?

ほとんどの経営者は、自社の情報戦略は?と聞かれても、答えられないと思います。それは、経営者が疎いのではなく、情報処理設備を高く売るために作られたキャッチコピーだからではないでしょうか。

情報システム部門は、自社業務を遂行するために必要な情報処理設備に対して、できるだけ効率的・効果的な投資をする役割があります。そのためには、自社業務の将来方向性などは当然、考慮する必要があります。しかし、日本の経営者は、それを情報戦略などと言いません。

だから、情報システム部門を、情報戦略部門化にと言うのもピンと着ません。その前に情報を活用して大成功を治めることができるのは、明主や賢将だけと孫子も言っています。多くの経営者の経営のよりどころは情報ではなく、己の技術や商才、コネだとすれば、情報戦略や情報戦略部門は、無用の長物でしかないのでは?

情報の戦略では無く、企業が勝つための仕組みはどうあるべきか。それが、企業システム戦略です。これは、一般的な情報システム部門の枠組みでは難しいテーマです。既存の枠組みを超え、企業システム戦略部門として再生する必要があります。それができるのは経営者であり、情報システム部門ではありません。


日経情報ストラテジー
●日本企業を見限ったインドの“システム屋”から学んだこと

『コラム』

インド人が言っていることは、日本のシステム開発現場でも同意できます。

  要件をしっかり決めてから開発するフロントローディングへの過剰意識。
  →要件が決まらない。時間がかかる。
  やっときまった要件は肥大して予算オーバ。
  要件と予算の調整に時間がかかる。
  途中で要求が変わり、予算変更手続きが発生する。
  運用試験では、残予算が無いので機能追加できない。
  →だからよけいに、最初に要件を盛り込もうとして
   検討調整に時間がかかる。それでも変更は起きる。
  最終的に開発しても使われない機能がある。

  この悪魔のサイクルを断ち切るには、
  反復開発(刷りあわせ型開発)と、それを前提とした予算管理を発注側のマネジャが仕切る必要があります。

  まず、決められた予算の1/2〜2/3、期間(予定会議開催数)の中で要件を決める。
  ・決めたデッドラインまでには、
   エンピツを転がしてでも、まず、決める。それでも決まらない要件は、後回し。
  ・予算オーバは、要件に優先付けして、オーバー分は、後回し。
  ・残予算が、確保されているので後回ししても気が楽。

  後回しにした要件は、開発中に検討する。運用試験中に要否を決定する。

  運用試験中に出た不足機能とあわせて優先付けし、運用審査会で審議し、
  残予算で追加開発する。

  要件定義を正確にしようと必要以上に神経質にならないで、
  後で追加できる予算と期間をバッファとして最初から計画する。


ITmediaエンタープライズ
●ITにも「道」あり。究めるなら「守・破・離」を知るべし

『コラム』

私が、「守・破・離」という言葉を知ったのは、学生時代に始めた空手道を通じてでした。何事もそうですが、基本が大切です。「守」では、この基本を徹底的にやります。意識せずとも、基本動作ができるようになるまで、何度も何度も同じことを繰り返します。毎日、100回やり、それを3年続けてやっと無意識に基本動作ができるようになります。

これを、空手道の世界では、握り3年、立ち8年などといいます。拳の握り方が無意識に正しく握れるようになるまで3年かかり、立ち方が無意識にできるようになるまで8年かかるという意味です。格闘技の世界では、いつ、いかなる時でも、とっさに基本動作を無意識のうちに取れなければいけません。

意識してやっているうちは、相手の動き遅れをとり、瞬間的な反応ができません。そして、無意識になるまで基本を体に叩き込むことができて、はじめて「破」に進むことができます。

基本ができていないうちに「破」に進むのは、単なる自己流で将来の大成はありません。逆説的ですが、「破」の難しさは、無意識になるまで体に叩き込んだ基本動作を「破」らなければならないことです。

だからこそ、「破」では、悩み苦しむのです。この悩み苦しみもがいて基本を打破するからこそ、その先の「離」があるわけです。つまり、「離」は、それまでのしがらみや苦悩から離脱する境地です。

ITの世界にも、基本はあります。システムのデザインパターンやデータベースモデル、DOAやOOA、PMBOKなどなど。これらを無意識の使いこなせるようになるまで徹底して「守」です。そして、無意識に使いこなせるようになったら、意識してこれを破壊します。だから、苦しみ悩みもがくのです。その先に、自分の形「離」があるのです。

このように「守・破・離」は、単にこの3段階を踏めば良いわけではなく、徹底した「守」があってこそ、「破」や「離」に意味が出てくるのです。

最近では、形だけ「守」の段階を通り、無意識に体に叩き込むまでに至らないうちに、「破」や「離」に進んで、一派を立ち上げているケースが少なくありません。そのようなものは、底が浅く、すぐに化けの皮が剥がれますし、基本が固まっていないので一度、崩れると立ち直ることができません。

本物を目指すのであれば、あせって「破」や「離」に行かずに、しっかりと「守」を実践し、無意識のうちに動作ができるまでやってほしいものです。その上で、「守」に安住せず、悩み苦しみもがいて「破」「離」へ行って下さい。

いわんや、「守」無しで、いきなり「破」や「離」に走るのは、単なる独りよがり、似非以外の何物でもありません。


@IT情報マネジメント
●“確実な記録”こそが、品質・コストに貢献する

『コラム』

“形だけ”になりがちなソフトウェアレビュー

“途中からベテランの世間話を拝聴する場”になっている、  単なる“間違い探しの儀式”と化している。

なぜなら、これまでレビューは、成果物の”問題点”を発見し、品質を”チェック”するものという定義がされてきたからです。 この”問題点”を発見するとか、品質を”チェック”するというのは、なんとなくネガティブなイメージがあります。

<従来のレビュー>
 品質チェック、問題点・不具合の発、ネガティブ、守り、現状志向、人が育たない

レビューを受ける方は、問題を指摘されないかとビクビクしたり、レビューする側は、問題をつつき粗捜しをしているような気分になりがちです。

これでは、生産的なレビューになるはずがありません。せいぜい、現物ありきで、誤字脱字の類を指摘しておしまいです。 レビューに参加する人も育ちません。そこで、私は、次世代のレビューとして、次のように定義します。

<次世代のレビュー>
 プロジェクト管理の要、リスク発見・付加価値最大化、ポジティブ、攻め、未来志向、人が育つ

プロジェクト管理の要と位置づけ、成果物に潜む、未来の見えざるリスクを利害関係者で発見し、プロジェクト・顧客・プロジェクトメンバを守り、明るく、幸せにするものです。そして、シナジ効果でアイデアを出し合って付加価値の増大を図ります。 こういった生産的なレビューに参加すれば、人も育ちます。

ただし、次世代のレビューを行うには、仕掛けとコツが必要です。その具体的なポイントを余すところなく記載したのが、こちらの書籍です。

ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイント
http://www.geocities.jp/aoshima_systems/bookix.html


書籍をお読みになり、次世代のレビューを導入したいと思われた方は、本書に基づくセミナーや導入サポートもいたしますので、 下記よりごお申し込み下さい。

企業システム戦略(企業価値最大化)支援サービス
http://www.geocities.jp/aoshima_systems/ask.html



日経情報ストラテジー
●「IT以前」の問題は本当にあるのか?

『コラム』

”それは「IT以前の問題」”という表現、我々も時々使います。

そうではなく、ビジネスの検討段階から、システム屋も”仕事”すべきとの記事です。実際、全て決まってからシステムの話だけを急に持ってこられると困るのも事実です。そうはいいながらもやはり「IT以前の問題」と言ってしまうことがあります。

しかし、ここ2年ほどで、問題点・ニーズの把握から計画書作成、仕様書作成を自分たちが主導してやるシステム開発プロセスに変更した意図はここにあります。ビジネスが全て決まって、ユーザが書いた計画書を受けてからシステム開発(ソフト化)だけを ”やらされる”のでなく、ビジネスにITをどう活かすか、ITを活かして、どんなビジネスができるかを考え・提案できる”システム屋”になりたいですね。

良い服を作る仕立て屋さんや良い家を設計する建築士さんは、お客さんの生活様式や信条などからヒアリングして、ピッタリのものを創り出しますからね。

システム屋も、そろそろ下請け業から創作者として、真のプロフェッショナルにならなければいけないということかもしれませんね。どう作るか?より、何を作るか?に軸足を移す時期とも言えます。

それには、ビジネスもシステムとしてとらえる思考や、その背景にあるシーンまで思考視野を広げる必要ありますね。ちょうど、仕立て屋さんが服だけ、建築士さんが家だけを考えるのではなく、服を着る人や家に住む人の人生にまで思いをめぐらせるように。


@IT情報マネジメント
●【「CIOいらない」、経営者の6割強が回答】JUAS、「企業IT動向調査2009」を発表

『コラム』

これが社長の本音ですね。企業価値増大において、ITもしくは情報が提供できる優位性について明確に社長や他の役員に説明できる人がいないということでしょう。あるいは、ITや情報が無くても事業継続が可能なことも事実です。(少なくとも、これまでは。)

特に製造業のサプライチェーンに属している企業で、関連するパートナーから仕事を請けている業態であれば、なおさらではないでしょうか。広く情報収集し迅速に判断し行動を決断しなければ生き残れないという危機感はそんなに高いとは思えません。それよりは、既存パートナーとの良好な関係を維持することが大切です。

それは、品質・納期・コストで、パートナーの信頼を得ることです。そのために情報がどのような役割を果たし、どのような情報戦略が必要ですか?それは、ものつくりの技術力向上とどのような補完関係となっているでしょう。

例えば、納期回答ひとつとっても、正確な生産能力情報などにより高度なシミュレーションを行った上で納期回答している企業は少なく、まずはパートナーの希望する納期をできる限り死守しようという特攻精神がいまだに慣行しているように思います。

高価な生産計画シミュレーションに投資するより、一時的に残業・休出(人件費)で凌いだ方が安上がりということでしょうか。ま、それもあるでしょうが、そのような情報ツールの活用法が分からないということもあるでしょう。

欧米や中国など大陸の騎馬民族と狭い土地での土着農耕民族の違いが、情報に対する価値観の違いになっているのでしょうか?情報が重要となる戦国時代においても、中国と日本では考え方が違うように思います。

情報に価値を認める文化を根付かせるには、情報統括役員候補者が目覚しい業績をあげる必要がありますが、いかんせん、情報だけを統括しても業績を向上させることが難しいところです。結局、他の役員への情報提供を行う補佐役が順当です。

情報だけを売り物にして成り立っている企業がどれだけあるかを考えてみてもわかりますね。

我が社には、情報統括するための”役員が”必要だと社長や他の役員が認めるには、まだまだ時間がかかるでしょうね。そのころにはCIOの役割とか地位向上とか話題にさえもならないでしょう。今は記事ネタになっていること自体がCIO不要の証拠です。


IT Pro
●ベンダー任せで基盤が崩壊 改良を重ね2年がかりで刷新

『コラム』

「増設してはどうかと商談をもちかけてきた。」性能問題が起きると、このようにハードウェアを増強するように進めてくるベンダは少なくありません。自分で問題を分析する力がなければ、言われるがままに増強するしかありません。もしかして、ワザと性能が悪化するようなコードを書いてる?と思いたくなるようこともしばしば。

仕方が無いので、自分たちでSQL文を解析したり、索引の設計を解析したりするのですが、分かってみれば大したことはありません。専門家として、こんなことも分からないのと思うこともしばしば。いえいえ、スキルが無く分からないのではありません。そもそも専門家としての責任感が欠如しているのではないかと思います。なぜなら、自分で分からなくても、ネットで少し検索すれば、解決策などが見つけられるのですから。

「自己責任のとれるIT組織」は、確かに立派なのですが、これでは自己責任のとれるIT組織を持てない中小規模企業など怖くてIT導入などできません。もちろん建築業界でも、問題はありますが、それでも、そういった建築士は一部であり、悪質な場合は、犯罪者として更迭されます。

普通は、建築士のほうが施主よりも建築に関する知識は上で、逆に設計の不備を施主が解析して指摘するなどということは考えられません。それでも、自己責任を果たせていないとは言われません。だから、安心して素人でも家など建てられるのです。

しかし、IT業界は、劣悪な設計をしてユーザに迷惑をかけ、その上、それを踏み台にして設備増強で儲けるなどしても、なんら役所の査察があるわけでも、業務停止処分などを受けるわけでもありません。そもそも、所定の性能を満足できるような設計ができる能力が無くても、業務として設計をしてもよいことになっています。

そろそろ建築士制度のように、規模の大小によって、IT設計を業としてできるかできないか、資格で規制してはいかが? そのようなベンダを取り締まれる法整備もせずに、問題が起きると勉強不足とか自己責任とか丸投げするなとか、起こられるようでは、IT経営とかIT戦略とか言っても、笛吹けど踊らずではないですか。

マスコミも、このような特殊なユーザ企業を賞賛する記事ばかり書かずに、この記事にある、ハード増強の商談を持ちかけてきたベンダ側をしっかり取材して、世に責任を問うような記事を書いて欲しいものです。


日経ソフトウェア
●ソフト品質改善にはテストだけでなくインスペクションが必要,
「ソフトウェア開発の定量化手法」の著者が語る


『コラム』

要求段階で発生するミスが最も対応しにくいという事実や要求段階から運用に至るまで,各ステップでの点検は、私が、拙著『ドキュメント・レビュー!!要求仕様書・設計書のレビュー実践とチェックポイント』で主張していることと全く同じで、ソフトウェアの大御所から、お墨付きをもらったようでとても嬉しく、こころ強い。

要求仕様や設計のバグは、どうあがいても、実装フェーズでは、除去できないと思うが、実装と手直しを繰り返せば、品質が向上するという論調には、疑問を感じていた。また、上流だけでなく、試験工程でのテストケースの漏れについても、同感だ。特に、負荷テストや限界地テストなどをいい加減にして、運用開始後に問題を起こすケースが増えている。

テストを実施する前に、テスト計画やテストケースに対する点検を行うべきなのである。そのほうが、闇雲にテスト&手直しを繰り返すより、効率が良いと思う。しかし、ここでも”やってみたほうが早い”論が横行している。その結果が、デスマーチでは洒落にならないのだが。

これも、アジャイルとかの影響だろうか?などと言うと怒られそうだが。私は、適切かつ信頼できるフィードバックというものが、唯一、動くソフトウェアだけからだとは、どうしても思えないのである。もしそうなら、世の中の他の産業で行われている、設計図書の標準化や規格、設計審査、品質保証システムなどが無意味になってしまうのではないだろうか。

その昔、確かに製造業でも、品質と言えば、製品完成後に検査する品質検査・品質管理を意味した。しかし、デミング博士によって、TQC・TQMが日本に紹介されてからは、品質は設計製造システムによって保証するものであり”工程で作り込むもの”というのが、一般的な考え方だ。このことからしても、ソフトウェアにおける品質マネジメントは、他産業に比べ遅れているのではないだろうか。

ソフトウェアは、工業製品ではなく、芸術作品だと言う論調もあるが、芸術作品の品質を、いったいどのようにマネジメントするのろうか?そもそも、芸術作品だと言い放った時点で、品質は超属人化されマネジメントからは程遠いものになってしまう。

あなたは、「市場への投入時間を短縮するために、十分なテストはしていません。しかし、問題があれば、連絡いただければ、いつでも、手直しして差し上げます。」というような製品を、安心して購入できるだろうか?あるいは、「ソフトウェアは芸術作品だから、品質はマネジメントしていません。」と言われて、そのソフトを安心して使えるだろうか?私は、ゴメンだ。。。


日経ベンチャー
●企業の組織改革が失敗する理由

『コラム』

『あーもったいない』という意識を現場が持つことは大切ですね。この事例に出てくるパートさんは主婦の方だと想像します。同じように、会社で働くお父さんたちは、どうでしょうか。

自宅の生活から、”もったいない”という気持ちが失せているとしたら、会社の仕事でも同じですよね。コスト削減だ、コピー費削減だと旗を振っている当人が、トイレの電気をつけっぱなしにしたり、水道を出しっぱなしにしたりということもあります。それは、自宅の日常生活が自然に出てくるわけですから、取り繕うことが難しい。

つまり、会社でのコスト削減を定着させるには、お父さんたちに日常生活で”もったいない”と思っていただかなくてはならないようです。会社のコスト削減活動は、気が滅入るというお父さんも、地球資源の保護が、自分の子供の未来ためと考えたら、無駄なコピーを少しでも減らそうという気持ちになるかもしれませんね。

企業の組織改革なんていう遠大なテーマも、結局は、こんな生活感から始める方が遠回りなようで確実なのかもしれません。


ITPro
●経営に貢献しないシステムはゴミ

『コラム』

実にキビシイ一言です。最近の記事かと思ったら、1999年の記事が再掲されたものでした。ここにある「3階建ての企業情報システム」は、現在のエンタープライズ・アーキテクチャと良く似ている。1999年から2007年の今日までに、この2階から3階へ上ることができたシステム部門とITベンダは、どれくらいいるだろうか。

しかも、憂えることに経営者やユーザが、1階や2階に口を出すようになってきた。これは、ITベンダが3階へ上らなかった代わりに、1階や2階の話をきらびやかに一見分かりやすく、経営者やユーザに売り込む手法を磨いた賜物であろう。つまり、この記事にあるように、「情報システム部門が3階に上る手助け」をするのではなく、熱心に「1階や2階の話」をした結果、経営者やユーザを洗脳することに成功したのかもしれない。マスコミがその片棒をかついだ可能性もある。TVでIT関連のCMが流れる昨今である。

いずれにせよ、ITベンダは、自分たちの城である1階や2階を守り、経営者やユーザを手なずけた。ここ数年のIT投資が上昇傾向にあるのは、その成果だろう。しかも、経営者やユーザからは、新しいソリューションを提示しないばかりか、理解もせず、運用保守のことばかり心配するシステム部門は無能者に見える。

一方、システム部門も半ば自ら、サーバやセキュリティのお守りだけをする管理部門となったようだ。つまり、景気回復を背景に、経営者とITベンダ(システム部門不在)による、さらなる新たなゴミが生成され、そのゴミ処理をシステム部門が受け持つという構図ができあがったのではないだろうか。

そうなると、システム部門に要求されるミッションとスキルは、新たなソリューション提案ではなく、リサイクルによる資源効率化による経営貢献である。


ITPro
●重要なソフトは外注せず自分で作る

『コラム』

特に社内の業務ソフトウエアに対して、こういう考えを持っている経営者は、必ずしも多くないように思います。ソフトなんて、そこらにある市販のものを買ってくるか、専門会社に任せればよい。システム部門は、何かというと手間とお金をかけて手つくりしたがる。なんて、思っているのではないでしょうか。

確かに、今の世の中、優れものの市販ソフトは沢山あるので使えないことはありませんし、専門会社に任せてもソフトは作れます。そこでポイントなるのが「重要な」というところです。自社にとって、何が重要か重要でないかを見極め、重要でないものは、捨てる。つまり、市販ソフトやアウトソースで十分とするかです。戦略とは、捨てることだと言う人もいるくらいですから、これがIT戦略です。

そこで必要になってくるのが、SWOT分析やドメイン分析などによる自社の重点施策(経営戦略)です。それがあって、初めて、IT戦略(取捨選択)が決まります。これは、社としての”決定”です。

次に重要なのが、取捨選択して社としてのIT戦略を”決定”したら、経営トップが、全社にそれを”徹底”させることです。市販ソフトは、ユーザの痒いところには手が届きません。アウトソースは、社内のように小回りがききません。そこでシステム部門に、様々な改善要求が寄せられ、バックログが溜まることになるわけです。

その時にトップが「現場の要望を聞いて、すぐに、使いやすいものにしてやれ」などと言うようでは、システム部門は板ばさみです。トップは、社のIT戦略で、その分野のソフトは捨てる”決定”をしたのだから、多少の使い勝手の悪さや対応の遅さは我慢するように社内に示さなければいけないと思います。


@IT
●インメモリー・データベースがもたらす驚異のリアルタイム性能

『コラム』

人が会話を交わす時に、一々情報をメモ帳や辞書から取り出していたのでは会話は成り立ちません。コンピュータが人と会話するには、同じようにハードディスクから情報を一々取り出すのではなく、必要な情報を全てメモリ(脳)の中に入れておくのが良いですね。

これまで、それが出来なかったのは、メモリが高価であったのとアドレスできるメモリ空間が32ビットでは最大2GBしかとれなかったという事情があります。それゆえ、少ないメモリ空間を有効活用するために必要な情報をハードディスクから少しずつ取り出して、LRUアルゴリズムなどで入れ換えるという方式が必要でした。

しかし、近年ではアドレス空間は64ビットになり理論上は16TBという事実上無制限の空間となり、さらに実メモリの単価も大幅にダウン(●Vista需要でメモリ1GBが1万円割れ)してきたために必要な情報は全てメモリに入れて処理することが可能になってきたわけですね。

ようやくコンピュータが人間と本当に会話できる脳を持てるような時代になってきたのかもしれませんね。そうすれば、プログラマがハードディスクから、効率よく情報を取り出す手順を考えてコンピュータに指示しなくても、取り出したい必要な情報だけを指示すれば良いので非常に楽になります。

データベース・チューニングやSQLチューニングというのは、将来は死語になるのかもしれません。ちょうど、自動車がオートマチック全盛になり、一般的にはエンジンのチューニングや高度な運転技術が不要になったように。


ThinkIt
@IT情報マネジメント
●情報システム部門はビッグチャンスをつかめ

『コラム』

確かに、経営者の言うことは変わって来ました。これまでは、「効果をコミットしなければ、投資計画を承認できない」とか、「ITも損益にしっかり貢献して欲しい」とかいった言葉は聴かれませんでした。それは、厳しくもあり、嬉しいことではあります。

しかし、やはり、これまでITは期待されていなかったんだなと思い知らされる感じもします。だって、営業部門や生産部門などに、わざわざ「損益にしっかり貢献して欲しい」などと言う事は無いと思います。論点は、どうやったら損益に貢献できるかです。

ITも、経営者がそこまで踏み込んで来るようになったら嬉しいのですが、まだまだ、そのような議論が出来るようになるまでは、いま少し時間が必要な気がします。


ThinkIt
ITPro
●作業計画とスケジュール作成の実践知識

『投稿』

山積やSカーブを描くまでは、なんとかやれるんですけどね。その後、リソースを考慮した平準化やリソース競合の回避、バッファ(安全余裕)の考慮などして、全体最適化された実現性のある計画にしあげるというところが難しいですね。それで、最後はエイヤッと現場に投げて、後は宜しくとなってしまうことが多いようです。

納期を守るためには、どうしたって1日30時間くらいの山が立ってしまうこともあり、それに現実性を求めると納期が守れそうも無かったり。そうなると、そんな納期で仕事を請負った営業を恨みたくなるわけですよね。

このあたりを解決すべく、スケジューリングソフトや最適化ツールを検討したりもするのですが、なかなか思うような計算結果が得られなくて。TOCのクリティカルチェーンなども検討してみるのですが、各工程の安全余裕を最後にまとめて1/2にしてプロジェクトバッファとするというようなことが各工程の責任者から理解を得られず。。。

ザ・ゴールのあとがきに、TOCの考え方に共感しながらも、組織文化や慣習が障壁になって実践できないでいる会社が9割以上だとか書いてあったような。トヨタ方式も、書籍が多く出回っていますが、導入して定着できる会社もこれまた10%以下だとか。

そして、最後は、チェンジリーダの存在に議論が及ぶわけですが、そうそう、チェンジリーダがいないのが悩み。結局、経営者は掛け声だけで、烏合の衆が集まって、右往左往しているのが現実なのですよ。そこを、どうやって改革を推進するのか、具体的かつ実践的に書いてくれる本とかあったらうれしいなー。


ThinkIt
ITPro
●IT部門の解体を考える

『コラム』

私の所属するIT部門では、新入社員を設計部門や製造部門に一定期間配属し、IT関連の教育と並行して現場での作業を覚えながら、そこで業務改善やシステム化にあたらせる。そして、1年の最後には、そのことをテーマとした論文を書くことで、システム屋としての基礎を固め修了とする。

なにも解体などする必要は無いと思う。「企業はIT部門を解体するべきだ。一度、経営企画や現場に再配置してみてはどうだろうか」。それならば、ITベンダは、即刻、店をたたんでユーザ企業に一度、就職してはいかがだろう。

一度解体して、各部門に散らばってしまったIT要員を再編成して、IT部門を再生させるのは不可能であろう。IT部門には、IT部門としての歴史やノウハウ、内部統制があり、そういった貴重な遺産は一度、失ってしまえば、なかなか元には戻らない。IT部門以外では、ITの現場現物に触れることは無く、各部門の個別に分業化された業務に埋没するだけだ。

むしろ、IT分野に身をおいて、離れた場所から多様な業界や各部門の業務プロセス全体を俯瞰してこそ、業務プロセスを抜本的に改善するアイデアが生まれるのではないだろうか。

また、近年では、IT部門を経営企画部門に統合する動きも盛んであるが、実際にそういった再構築をした組織からは、ITの現場が分からなくなって、実効性のあるIT企画が出来なくなったという声もある。技術やサービスの本質を見極める力が失われた結果ではないだろうか。

業務とシステムが分かり、業務改革を主導できるシステム屋は、やはりIT部門でなければ育たないと思う。IT部門を解体するのではなく、業務とITのバランス感覚に優れた人財を育成できるように、IT部門自らが変革しなければならない時期に来ているのだと思う。


ThinkIt
●IT部門主導型の業務部門の変革を考える

『コラム』

確かに、業務改革にITを絡ませることが多くなり、その結果、業務改革が進まないのもシステム部門がしっかりしないからだとトップが苦言を呈することがある。
しかし、それではとシステム部門が業務部門に変革を促そうものなら、「現場のことも知らずに何を!」となるのがオチだ。その時に、苦言を呈したトップが、システム部門の提案を受け入れるように業務部門を指導するのかと思いきや。
ことの本質は、システム部門やITを、業務改革が進まないことのスケープゴートに利用しているだけだったりする。誰も、IT部門に業務改革を主導などされたくないのだ。しかも、業務改革が一番進んでいないのが、IT部門だったりすれば、なおさらだ。
IT部門が業務部門に変革を起こせるのは、組織論ではなく、やはりテクノロジであろう。携帯電話やインターネットが、人々のコミュニケーションを変革してしまったように、情報技術を用いて、無意識のうちに業務に変革を起こすのだ。IT部門が業務改革諭や組織諭を持ち出したとたんに、話が怪しくなる。


CIO
●CIOの次なるミッションは「ビジネス・テクノロジー」の確立

『コラム』

ここでいう「ビジネス・テクノロジー」とは、ビジネスと技術の融合のことを言う。すなわち、経営戦略とそれを支える組織/プロセスの視点からITを考えるというコンセプト。このようなコンセプトが言われだしたのは、いつからだろうか。

かつて、経理処理を電卓ではなくコンピュータを使って迅速化したことは、経営戦略と乖離していたのであろうか。そうではあるまい。業務とシステムの両方を改革しなくても、収益に貢献することができるなら、それにこしたことはない。むしろ、そのような(利用者にとって)軽量なテクノロジが、望まれているのではないか。

あなたは、新しいテクノロジを使った製品を購入するに当たって、生活習慣や生活様式を変えなければ使っても効果が得られないというような商品を買うだろうか。私は、ごめんだ。新製品に期待するのは、その使用によって苦労無く、新しい生活様式を手に入れられること、新鮮な驚きを与えてくれることだ。

カシオ電機が小型電卓を開発するに当たって、「発明は必要の母」という信念を持っていたとテレビで見たことがあるが、これなども同じであろう。通常は「必要は、発明の母」と言われている。しかし、カシオは逆であった。テクノロジが、ニーズを産み出すのだと考えた。

そのような意味で、私は、こちらのようなケースもあってよいと思う。「結果的なIT活用」のススメ。 ITが経営改善の道具であると考えるならば、「効果は大きいが、使うのに苦労する」テクノロジよりは、「効果は小さいが、簡単にすぐ使える」テクノロジを選ぶことも必要ではないか。トップダウンで理論的に事を進めるよりも、目の前の改善を少しずつ積み重ねるアプローチが得意な日本では特に。

野球では、「最初からホームランを狙うな。ヒットの延長がホームランだ」という考え方がある。「効果は小さいが、簡単にすぐ使える」テクノロジを数打つことで、結果的に戦略的にテクノロジを活用したといえる状況になったというのもありだろう。


CIO
●金融庁、「日本版SOX法」実施基準案を公開

『コラム』

今後のシステム開発では、内部統制について、業務統制(人間系)と自動統制(IT系)のバランスを取る必要があります。過度の自動化統制は、IT側の統制機能が重たくなりますし、IT側で統制機能を実装していないのに、業務統制が設計されていないと内部統制が機能していないということになります。

・自動統制とは、個人認証、ログ取得機能、パスワード変更やリボーク機能、電子承認機能などです。
・業務統制とは、いわゆるハンコによる点検・承認・記録です。

ますます、「システム=人間系+機械系」を意識して、業務プロセスとシステム内部のプロセスを設計する必要があります。システムが出力した結果を、誰が承認して正当性を保証するのか、システムへの入力の正当性を、どうやって保証するのかといった統制機能を、IT側で行うのか業務側で行うのか、システムのアーキテクチャとして全体を踏まえて最適な設計をする必要があります。

IT側で自動統制とする場合、利用者に対する内部統制は強固なものになりますが、こんどはIT全般統制として、ソフトウェアの正当性、データベースの正当性を保証しなければなりません。システム部門の統制レベルが低いと、ここが大きなリスクになります。それならば、業務統制とするかという判断もあります。

こういった判断をして、どこにどれだけリソースを割り当てて、会社の内部統制を確立していくかは、最終的には経営判断となります。なぜなら、判断を誤れば、財務諸表の正当性が保証できない企業として法的な制裁を受けることになるからです。経営者個人であれば5年以下の懲役もしくは500万円以下の罰金、または両方の罰則、法人であれば5億円以下の罰金です。

さらに、内部統制と作業効率性のバランスも考慮して、設計しなければなりません。完璧な内部統制を実装したシステムは、とても非効率なものになります。平成20年の法施行開始時点で100点である必要はありません。


ITPro
●ソフトウエア開発者の危うい「更地主義」

『投稿』

レガシ再構築派も更地主義でしょう。彼らは、アプリが老朽化したと言います。本来、ソフトは老朽化などしません。ソフトを改修する時、基本構造を理解して破壊しないようにするプログラマと、無視して構造を破壊するプログラマがいます。ほとんどのプログラマは後者です。

構造を理解するために他人の書いたコードを読み解く手間を嫌がり、手っ取り早く、バイパス手術を施してお終いです。こうして保守してきた過去の自らの罪を、清算したい気持ちは分かりますが、結局、1年も経たないうちに同じことの繰り返しになるでしょう。

都市工学や建築工学のように、アーキテクチャを維持しながら長期間、保守する技術がソフト工学に欠如しているからです。リファクタリングは、そのうちの少ない技術ですが、実践できるプログラマが少ない。

私が、入社以来20年間、基幹システムを保守してきた手段は2つです。一つは、コードを素早く呼んで、全体の構造を把握、理解するための速読です。もう一つは、絶対にGoTo命令を使わないことです。つまり、構造化プログラミングの徹底です。そして、分からなくなったら書き直せばよいと言う安易な発想をしないことです。

全てのプログラマが、このように保守していれば、レガシ問題も、2007年問題も無かったかもしれませんね。


ITPro
●「カイゼンは巧遅より拙速」

『コラム』

確かに考えてばかりで何も行動を起こさないのでは改善はできないと思います。改善のアイデアが浮かんだら、まず、やってみて、それで悪いところがあったらまた改善するというフィードバックサイクルをグルグル回すことで最適化するという制御システム的な考え方は、大いに良いと思います。

ただし、ここで注意しなければいけないのは、グルグル回ってみて気が付いたら元に戻っていたとか、もぐら叩きになってしまい結局は何も前に進んでいなかったということにならないようにしなければいけません。

そのためには、改善の大きな方向性やロードマップ、哲学といっても良いかもしれませんが、一貫したそのようなものが明確になっている必要があると思います。

トヨタには、後工程引取りや7つのムダ、平準化や自働化など多くのトヨタ語によって、カイゼンの方向性やあるべき姿、目指すところを強烈に示している哲学があります。さらに、その哲学を「かんばん」という道具を使って具現化さえしています。

このような一貫した哲学も無いのに、巧遅より拙速ということだけを取り立てて闇雲に改善しても、逆に改悪となる可能性もあります。

トヨタには、「なぜを5回繰り返し、真因を探れ」という言葉もあります。巧遅より拙速とは言いながら、なぜを5回も繰返して真因を探るのですよ。普通は、3回も掘り下げれば良いほうではないですか?


ITPro
●再び塩漬けされる,システム内の「ブラックボックス」

『投稿』

ブラックボックスというのは、ソースコードの無いパッケージソフトのことで、ソースコードがあればブラックボックスではないと思います。時間がかかるかどうかは、問題ではありません。記事にあるような解析が困難なコードは、新規開発の直後にも発生しています。特にデスマーチで動かした大規模システムなど、パッチあてだらけで、プログラマ本人さえ分からなくなっています。当然、ドキュメントとは一致していません。最近はドキュメントレスで、アジャイルという手法もあります。昔のレガシ・システムのように、しっかりしたアーキテクチャ設計もされておらず、オブジェクト指向を少しかじっただけのプログラマが書いたコードは、とても読めたものではありません。かつての構造化プログラミングを徹底的に叩き込まれたプログラマが書いたコードのほうが、未だに、解析がし易いと感じることも少なくありませんん。ま、それでも、ソースコードがあれば解析できますが、パッケージは、なんともなりません、導入コンサルに○投げしていたら、最悪です。

 私の場合、昭和58年の入社当時に、すでに会社には昭和30年代に作られたアセンブラ、それも機械語に近い初期のもので書かれた基幹系システムが存在し、ドキュメントも無い、開発担当者も不在という状態でした。当然、はじめは解析に時間が掛かりましたが、1年も保守を担当しているとかなり全貌が見えてくるようになりました。  また、当初は他への影響が及ばないようにバイパス手術をほどこしていましたが、全貌が分かってくると、改修内容を盛り込むときに、コードを整理し改善しながら作業する余裕も出てきました。今でいうリファクタリングです。  改修内容に対する影響やリスクに対する「匂い」のようなものも感じられるようになりました。既存のコードを少し解析すると、波及する影響が広がりそうな危険なコードの「匂い」がするのです。そのような場合も、効率よく影響範囲を特定するようなコード解析もできるようになりました。そうなると、闇雲に全てのコードを読まなくても良いので、非常に作業効率が上がりました。このように、ソースコードさえあれば、プログラマが学習によって、例え、ドキュメントが貧弱なレガシシステムでも、ちゃんと運用保守できるような技術が身に付くのです。

 また、アセンブラで書かれたレガシ・システムのビジネスロジックには全く手をつけず、データベースとトランザクションモニタだけを新しいミドルウェアに移行したこともあります。これは、オンライン30本、バッチ100本程度のものでしたが1人6ヶ月で、他の仕事の合間に完工したこともあります。このシステムは、その後、ユーザの作業効率を向上しながら、今でも十分に使用されています。運用保守費用が膨れ上がったと言うこともありません。ビジネス・ロジックになんら変更は必要ないのに、ブラックボックスとか塩付けとかを避けるためだけに、再構築していたら、お金と時間が浪費されていたと思います。既存部分に出来るだけ手を加えずに、新しい要求に迅速、かつ柔軟に対応していくのが、最も効率的であり、これは、部品の再利用やオブジェクト指向、SOAの根底にある「隠蔽」という考えかたなのです。全てがクリアになっていなければ運用保守費が高騰するというのは、ブラックボックス化された部品を再利用することができないと言うことになってしまいます。

いざ、と言う時のために、ソースコードを持っておく。それでブラックボックス化対策には十分です。世の中には、企業システムの全てをパッケージ(ブラックボックス)化しているところもあります。

もっとも、金融商品取引法に対応が必要な勘定系システムは、システムの内部ロジックとドキュメントで文書化されている業務プロセスが、常に一致していることが必要らしいですね。誰が、いつ、どのドキュメントに従ってシステムを変更したのか記録を全て残すとかかなり大変そうです。


ITPro
●改めて考える,大企業と中堅・中小企業の違い

『コラム』

『企業規模が違っても経営やIT化に取り組む「基本」には違いがない』

 さすが、IT経営の達人ですね。徳を会得すれば、規模に関係ないと  本質を見抜いておられる。

 宮本武蔵も、五輪書の中で次のように書いています。

『五輪書 地之巻 兵法二つの字の利を知ること』
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 「兵法の道においては、世間では太刀を使いこなせる者を兵法者と言う。

  弓が得意なら射手、鉄砲なら鉄砲撃ち、槍は槍使い、長刀は長刀使いという。
  しかし、太刀は太刀使いや脇差使いと言わないで、”兵法”というには理由がある。

  太刀の徳によって世を治め、我が身を修めるので、太刀は兵法の根本である。

  太刀の徳を得れば、一人でも万人でも勝つ。
  そこで、我が流では、一人でも万人でも同じ事と考え、武士の心得を全て兵法という。」

  様々な、ソリューション・パッケージを使いこなすのは、「xxx使い」に過ぎません。
  そこにある、広義の情報技術の本質を知り、徳を会得しなければ、会社を治めることが
  できないと言うわけですね。


経済産業省
●IT経営マイスター

『コラム』

平成17年度 生産管理ソフトウェアWG報告書より

『IT経営マイスターは、製造業のIT経営を実現する上で、その作業の一部を請け負うのではなく、製造業の経営者 あるいはそれぞれの業務の担当者とともに、IT経営を実施する。そして、経営者あるいは担当者とともに汗をかきながら、要所要所において、専門化の立場から指導あるいはアドバイスを行い、必要ならば自分でシステム構築も行う。』

プログラマから叩上げのシステムアナリストがIT経営マイスターの最有力候補かもしれませんね。プログラミングの道を極めると、国家政策や経営戦略、人生までをもプログラミングできるかもしれません。マイスター(匠)というのは、道を極めた人という意味があると思います。宮本武蔵も、五輪書の中で、つぎのように描いています。

「兵法の利にまかせて、諸芸・諸能の道となせば、万事において、我に師匠なし。今此書を作るといへども、仏法・儒道の古語をもからず、軍記・軍法の古きことをももちひず。。」

戦略立案からはじまり、アーキテクチャ設計やプロジェクト管理も指導し、必要とあれば、データベースのチューニングやコードの改善も指導できる。そんなIT経営マイスターになりたいです。そんなスーパマンは無理ってか!?

なんの!企業システム戦略家としての道を極めるのだ!


経済産業省
●「情報システムユーザースキル標準(案)」意見募集

『投稿』

下記の意見を投稿しました。

・該当箇所(どの部分についての意見か、該当箇所が分かるように明記して下さい。)
3.3 タスクフレームワーク、3.7 人材像とタスクの関連、 3.8人材像定義 についてコメントします。

・意見内容
 はじめまして。私は、情報システム部門に所属しており、事業所レベルでの情報システム整備を統括しております。そのような立場で、このスキル標準を活用するとした場合に疑問となる点について、いくつかコメントさせていただきます。

1.1.1背景に記述されている点について、全く、このとおりであると認識を同じくいたします。これを、踏まえた場合、経営者、CIO、利用部門、システム部門が、持つべきスキル標準とは、どれとどれなのかが不明です。例えば、CIOのタスクとして、ITガバナンス(ISマネジメント全体の統治)というタスクは、フレームワークには存在しません。ISの成果を組織力向上に結び付けるには、経営者の役割が重要とされていますが、経営者のタスクも存在しません。CIOや経営者は、ISストラジストとしてのスキルを持つべきものと考えれば宜しいのでしょうか。

2.用語の定義として、ISが3.3Eに定義されていますが、IS戦略とIT戦略が使われており、切り分けがわかりづらく、混乱します。

3.このため、アプリケーションデザイナは業務プロセスの詳細設計、ISアナリストは、IS企画立案などをミッションとしますが、これらをシステム部門員が実施することは現実的に不可能です。利用部門にも、アプリケーションデザイナやISアナリストのスキルが必要なのでしょうか。情報処理技術者試験での利用側のスキルとして、初級シスアド、上級システムがありますが、ISアドミニは、活用を主なミッションとしており、IS企画・設計は支援となっています。現実問題として、広義のIS企画・設計では、経営者、CIO、システム部門、利用部門の参画が必要となりますので、この全ての部門にISストラテジスト、ISアナリスト、アプリデザイナのスキルが必要となります。

4.ISアーキテクトのミッションは、IT戦略と定義されていますが、広義のISでは、ISの効果を最大限に引き出すための組織構造、各部門ミッションの定義、業務構造、経営資源の最適配置なども考えられます。

5.IS活用は、ISアドミニとアプリデザイナだけの領域になっていますが、経営者、CIO,ストラテジスト、プロマネ等の支援無くして完遂は困難です。その観点で3.7は、企画/構築/評価に偏っているようです。ユーザ企業では「活用」が最重要です。

以上、総括しますとIS遂行組織と人材像の関係付けが不明のため適用が困難です。そして、ISキャリアの最終はCIO/経営者であってほしいと思います。


ThinkIT/プロジェクト管理
●スケジュールとコストに関する指標が一目瞭然にわかるEVM

『コラム』

質問:スケジュール差異ゼロ、コスト差異ゼロでも、プロジェクト終了間際に火を噴くことがある。
   さて、どんなケースか?もちろん、出来高と実績コストは、タイムリかつ正しく報告されているものとする。
   答えは、最後に。

また、スケジュール差異やコスト差異が出た時の打ち手は何があるだろうか。スケジュール差異を埋めようと、人を投入したり残業を増やせばコスト差異がさらに広がり、コスト差異を埋めようとすれば、スケジュール差異が広がる。スケジュール差異を取り戻し、かつ、コスト差異をも埋めるような魔法の打ち手が、はたしてどれだけあるのだろう?

もし、私は、コストを抑えつつ、スケジュールの遅れをとりもどしたという人が居たら、ぜひ、ご教示願いたい。

私の知る限り、スーパーマンでも連れて来ないかぎり、結局、どちらかを諦めざる終えない。生産効率の改善が必要と言われても、それまで、サボっていたわけではあるまいし、そう簡単に生産効率など上げられないのだ。

つまり、赤字覚悟で残業を増やしスケジュールをキャッチアップするか、顧客に頭を下げて、納期を遅らすかだ。

ならば、EVMでコストと進捗を同時にフォローする意味は何だろう?最初からプロジェクト戦略としてコスト厳守か、納期厳守か、優先する方を決めておけば、どちらかのみを管理すればことたりるのではないだろうか。

結局、スケジュールにしろ、コストにしろ、遅れてしまったものを、スケジュールも、コストも両方救うような打ち手など。。。ない。精々、納期遅れやコスト超過が、多少早めに分かるという程度で、それを解消する銀の弾丸など、ありはしない。
「見えないより、見えたほうがいい。しかし、見えても手の施しようが無いなら、見えないほうが幸せだ。」
そこで、何度か痛い目にあったプロマネは、万一に備えて、予算やスケジュールなどに痛みを緩和すべく余力(バッファ)を設けておく。TOCクリティカルチェーンでは、プロジェクトバッファやリソースバッファ、合流バッファなどを設けるようにしている。

質問の答え品質(テスト完了)基準の未達成。

スケジュールも、コストも順調だったはずが、プロジェクト終了間際で品質が要求レベルに達していないことが発覚すると火を噴く。デスマーチの始まりだ。これを防ぐには、コマ目に品質レビューを行うことと、出来高を計上する時は、品質基準をも満たしていることを検査すること。

理想は、現場・現物・現実を是とし、テストファーストと反復により、愚直に地道に一歩ずつ確実に開発を進めることだ。EVMやxx率などの間接情報は、しょせん間接なのだから、そこに人の思惑が入り込めば、簡単に美しいグラフに騙される。

単に予定どうり、10個のプログラムを書いたので、出来高100%ですなどと言うプログラマの報告を鵜呑みにしていたら、痛い目に合うことになるリスクは高い。日本では、ソースコードを見るのは、下級な仕事であるかのように思われているが、「マネージャは、ソースコードを見なくて良い」などと誰が決めたのだろう?

マイクロソフトやGoogleなど一流のIT企業では、ソースコードをマネージャが読めないなどということは無いようだ。考えてみれば、あたりまえ。現物(ソースコード)を見て、品質や出来高、リスクを見抜けなければ、まともなマネジメントなどできるはずが無いのだ。トヨタの経営幹部も、良く現場に顔を出して、作業者と現物を前に喧々諤々やっているとか。強い会社の経営は、例外なく現場・現物・現実に立脚している。


ITPro
●トヨタ流が「なぜなぜ5回」なら、リコー流は「TTY」

『コラム』

この記事が言っているように、「見える化」→問題発見→「なぜなぜ」→真因追究→「本質改善」という流れなのでしょう。ただ、現実には「見える化」をしても、問題発見できないことも少なくありません。何故でしょうか?

デミング博士の言葉に「定義できないものは、管理できない。管理できないものは、測定できない。測定できないものは、改善できない。」というのがあります。これに当てはめてみると「見える化」は「測定」に当たり、測定できるから「なぜなぜ」が機能して、改善に向かうということになります。では、測定の前にある「定義」とは何でしょうか。

それは、JITという戦略(あるべき姿)の明確な定義であり、それを阻害する「7つのムダ」という定義です。これが、現場の全員に浸透しているからこそ「見える化」で、見えたこと(測定結果)にたいして「これは問題だ」という意識・感性が働くのです。問題意識が働けば、原因追求・改善へと繋がります。

こういった全社一貫した明確な戦略の定義や阻害要因の定義と理解・浸透も無しに、やみくもに「見える化」しても、わずらわしいだけで、問題意識が働きません。そうなると「見えて」いても、見ないフリをするか、隠してしまうのが、人間の弱さです。

また、問題を見える化して解決に苦慮する人より、要領よく隠してしまう人のほうが評価されるような組織風土だったりすると真の「見える化」は、なかなか進みません。「見えないよりは、見えたほうが良い。しかし、全て見えてしまうよりは、見えないほうが幸せである。」と誰かが言ったとか。。。

「なぜなぜ」は、論理的に因果関係を追及する手段ですが、論理の出発点である、問題の発見(仮説の選択)には、見えたことに対する感性(情緒や形)が必要だというようなことが「国家の品格」にも書いてありました。

「JIT」「7つのムダ」「自働化」などのトヨタ用語は、トヨタ組織文化の情緒や形を、浸透させるために言葉で定義したものということができるかもしれません。そういった明確で強烈な「言葉」(言霊)があると、全社的な改善のベクトルが合って、大きな力になりやすいものです。


@IT情報マネジメント
●ビジネスとITを全体最適に導くEA

『コラム』

ビジネスモデルやシステムモデルの集大成というべき「EA」(エンタープライズ・アーキテクチャ)。なぜEAが注目されているのだろうか。そしてEAで何ができるのだろうか。

ベンダは、最下層の技術体系(ハード・ソフト構成、ライセンス数等)から、いきなり提案してきます。しかも、その根拠は”???”であることが多いものです。それが妥当がどうかを評価するには、個別の技術各論ではなく、その上位の体系からの要求事項に基づいて検討する必要があるので、EA(基本設計)がしっかりしていなければなりません。 *技術各論では、ベンダに分があるのは当然で、煙に巻かれます。

あくまで、次の順=ビジネス駆動です。アプリケーション・アーキテクチャや技術・アーキテクチャは、上位のビジネス・アーキテクチャやデータ・アーキテクチャの要求変更に従って柔軟かつ容易に選択・取替え・拡張ができるのが理想で、これを実現するための最有力技術が、SOA、Webサービスです。 逆に、下層アーキテクチャが足かせになって、上位層の変更を縛るようでは本末転倒です。

ビジネス・アーキテクチャ  <= ビジネス・モデルが最重要

データ・アーキテクチャ   <= 次にデータの構造が重要

アプリケーション・アーキテクチャ <= これは実現の手段(道具)

技術・アーキテクチャ  <= これは、手段(道具)を支える基盤


IT Pro
●赤字プロジェクトを出さない鍵はアプリケーションのノウハウ

『投稿』

PMBOKには、リスク管理やコミュニケーション管理といった知識エリアもあります。担当SEに対象案件に関する業務知識があるかないか、どのようにユーザとコミュニケーションするかなどは、プロジェクト管理者が、立ち上げ時にリスクを把握しておき、対策を盛り込んでおく必要があります。SEのアプリケーションのノウハウによって、プロジェクトの成否が握られているのでしたら、プロジェクト管理者の存在意義は薄くなってしまいます。プロジェクト管理は、単に数値を追いかけるだけが役割りではないはずです。担当SEにアプリケーションのノウハウが不足しているのであれば、リスク対策として業務に関する事前教育も必要でしょう。スーパーマンSEを望むより、普通のSE集団と普通のプロジェクト管理者で成功を勝ち取れるような技術の体系化こそが重要課題だと思います。

一方で、対象業務に精通していなくても、要求分析スキルや質問力に秀でたSEは、得られた事実関係から、見えない顧客の要求を推察し、適切な質問をすることで、因果関係や真の要求を引き出すことが出来ます。特定の業務知識に頼った要求分析では、昨今のように業務そのものから設計しなければならないようなアプリケーションの設計はできないと思います。ですから対象業務領域の知識に依存しない、汎用性の高いヒアリング技術、科学的合理主義にもとづく分析技術を体系化し、ナレッジを組織内で共有するのも有効だと思います。

いずれにしても、SE個人のスキルに強依存している間は、IT産業は、非科学的、家内工業的な状況から抜け出せないので、産業革命に見るような飛躍的な発展は望めないのではないでしょうか?


@IT情報マネジメント
●企業の中を情報が流れる“3つの川”

『投稿』

これ、私の記事ですが、パソコン・ネットワークは、最初Excelと書いたのですが具体的な製品名は、まずいかなと思って書き換えました。
でも、Excelの功罪ってネタになりますよ。 身の周りでも、ホスト上のマスタのデータを個人のExcelに持ち込んで勝手に加工して業務に使っていますから。

一例ですが、製造業などですと、部品リストなどのマスタがあって、それで、注文や生産をしているのですが、設計変更などで、部品番号が変わったりします。
その時に、個人が古い部品リストをExcelなどに持ち込んでいると設計変更が盛り込まれずに、古い部品を買ったり、生産したり、必要な部品が無かったりと。。。

人事マスタなども同じですね。
人事管理を一人の人がやっているならExcelでよいのですが複数人でやると、マスタが一つでないと、人事リストが 個人に分散していると、退職したはずの人が、いつまでも在籍していることになっていたり。

見た目、電子データで、それらしく見えるのですね、これが。
データ加工が、簡単なのも良し悪しです。便利さの光と影。

最後は、個々人の情報モラルによるのですが。。。 それをダウンサイジングによる業務効率化だと信じて疑わないですから、始末が悪いです。確かに小回りは利きますけどね。

川を汚し、乱すのは、それだけではなく、システム部門の指導力・権限の無さ、経営者の情報軽視、いろいろとありますね。


日経BP社
●団塊世代の引退と技能伝承、5割が「不安」または「やや不安」

『コラム』

これは、団塊世代の自己賞賛か、ノスタルジアか?

少し前までは、IT業界でまことしやかにささやかれていましたが、最近は、製造業など他の業種でも取り上げられることがあるようですが、実際のところは、どうなんでしょう。

私の会社では、2007年問題に向けた技能伝承などが話題になることは、ほとんどありません。会社は、すでに再雇用制度を実施しており、定年退職者のほとんどは離職しておりません。

団塊の世代も、ほとんどが再雇用されるでしょう。

世代交代や引継ぎ問題は、いつの時代にもあります。トリノオリンピックでも、それが出ています。「 ヘッドライン 30年ぶりのメダル無しも現実味=世代交代の谷間、甘すぎた読み」しかし、こういったことがあってこそ、新しい世代が発奮し、次には「なにくそ!」と飛躍もできるのです。

団塊の世代が退職することで、ちょっと規模が大きいだけなのです。パレートの法則によれば、上位20%は意味がありますが、残り80%はどうでもよいのです。引き継がなければ、企業活動に支障をきたすような重要なノウハウなど、どれだけの人が持っているのでしょうか。

実際、記事のアンケートでも、企業の次期中核を担う40代は、半数以上が不安を感じていないのです。私自身も、40代前半ですが、なんら不安を感じませんし、いまさら、定年間際の人から何か教えてほしいことなど思い当たりません。団塊の世代の人たちには、マイナスのイメージのほうが強いです。彼らさえ、団塊の世代と呼ばれることに抵抗感を感じているくらいですから。(東京ガス調査”団塊と呼ばれるとうれしくない!?”)

2007年問題は、後継者の人よりも団塊の世代の人たちの退職後の身を案じて、その人たちを姥捨てにせず、知恵を活かして社会に貢献させてあげましょうと言うことではないでしょうか。さもないと、定年退職後の「濡れ落ち葉」が大量に生産されることになり、自殺者の増加や、ニートに次ぐ不就労人口の爆発的増加など社会問題化する恐れがあります。 政府も、2007年問題を煽り、企業に再雇用させるなどして、企業内に押しとどめておくほうが良いのです。

しかし、そのようなことになって企業内に老害が蔓延すると後進への悪影響など、企業の活性化を阻害することになります。2007年問題などと騒いで、企業に押し付けずに、団塊の世代が、活き々と第二の人生を遅れるような受け皿を国や自治体が用意してほしいものです。彼らは、平均貯蓄1500万円、大企業平均退職金2000万円、プラス、厚生年金の富裕層ですから、いつまでも、会社に依存せず、仕事は後進に任せて、第二の人生を、しっかりと自立して歩いてほしいものです。


メルマガ
●企業システム戦略

『コラム』

謹賀新年!あけまして、おめでとうございます。
新しい年を迎えてメルマガをリニューアルしました。

『損失を最小に抑えて勝つ企業システムとは』
『変化に柔軟に対応する企業システムとは』
『リスクや先を読める企業システムとは』
『自己学習機能を持つ企業システムとは』
『ノイズに強い企業システムとは』
『理想的な情報処理システムとしての企業システムとは』

企業体を一つの情報処理システムとして捉え、そのあるべき姿、とるべき行動は、どうあるべきか?
この遠大なテーマについて、以下を拠りどころとして、さまざまな観点から、徹底研究・解説していこうと
考えています。末永く、宜しくお願いします。

・兵書に学ぶ戦略と戦術:孫子の兵法、五輪書、兵法三十六計
・組織能力成熟度:CMMI
・プロジェクト管理:PMBOK、P2M
・業務とシステムの最適化計画:EA
・ノイズ&リスク対策:品質工学(タグチメソッド)
・その他:速読、乗馬、空手道


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