グ『企業システム戦略』の構築・実践に関する記事に対する私見を掲載しています。※記事やニュースの内容は、タイトルをクリックすると参照できます。『コラム』”構成監査は構成記録が正しく行われているかを確認”構成管理の難しさは、この一言に集約されます。要求事項と設計図書と製品(製造記録)とが一致していることを、仕様変更や設計変更も含めて保証するということです。保証するというのは、要求事項と設計図書と製品との間で、部品一点毎に、トレーサビリティが確立されているということです。航空機の場合、1機あたりの部品数が、数百万点と言われていますから、それらが間違いなく、要求事項が製品に反映されていることを保証するのは、かなり大変な作業です。構成管理の指針」”構成管理とは、製品の構成を文書化するものである。構成管理は、ライフサイクルの全段階で、識別及びトレーサビリティ、その物理的及び機能的要求事項の達成状況並びに正確な情報へのアクセスをもたらす。”これは、「言うは易く、行うは難し」です。数百万点もの部品に対して、要求事項=設計図書=製品(製造記録)の照合を人間系で行うのは、不可能に近いため、コンピュータを使用します。製品によっては、設計に描画された図形情報と製品を、直接、人間系で目視確認し、照合を行っている場合もあります。コンピュータで、部品番号を識別子として、各々のデータを照合することになります。Material)と呼ばれるデータベースに格納します。設計図書はEBOM、製造指示書はMBOM、製造記録はQBOMにそれぞれ格納し、これらをコンピュータで照合します。ここで、重要となるのが、照合のキーとなる番号体系です。一貫性を待たせる必要があります。各要素に変更が発生した場合は、改訂履歴を記録し、番号には、改訂符号を付与して識別します。照合は、この改訂符号まで含めて行うことで、全ての変更が、製品に反映されたか確認します。変更の度合いによっては、全く別の番号を付与することで、反映を確実にすることもあります。ところで、航空機は、製品を構成する部品が数百万点あり、大規模システムといわれていますが、情報システムは、どうでしょうか?ソフトウェア部品を、どう捕らえるかにもよりますが、モジュール化の原則である、「1モジュール1機能」とすれば、ソフトウェア部品の最小単位は、1命令行と考えることもできます。給与計算という要求事項に対する、部品は、給与計算式の命令になります。ソフトウェアの場合、この計算式の1文字でも間違っていれば、給与計算システム全体が保証されません。このように考えると、情報システムの部品点数は、数百万〜数千万点にも上ることになります。組み込みソフトウェアでは、自動車で700〜1000万行、航空機では2000万行以上に及びます。コード1行単位で実現し、トレーサビリティを確立すれば、ソフトウェアの品質は格段に向上するはずで。そのためには、上述したようにコンピュータによる照合は、必須であり、そのためには、製品を構成する部品を識別するための番号体系に、上流から下流まで一貫性を待たせる必要があります。要求仕様書の各要求事項に識別番号をつけ、その識別番号の単位で、設計図書を起こします。その設計図書の単位で、コードに識別番号を付与します。モジュールは、各階層ごとに、結合設計書を作成し、その単位に識別子を割り当てます。モジュール(結合試験)−システム(システム試験)プロセス(運用試験)が一貫してトレースできます。BOM)としてデータベース化することで、コンピュータ上で容易に一貫性を保証することができます。ちなみに、BOMは一般には組立て製造業の生産管理、MRP(所要量計算)に使われるデータベースとして認識されて、解説などされてます。構成管理としても中心的なデータベースであり、ソフトウェアも組立て製造業に近いので、構成管理に応用することが可能と考えられます。BOMの基本機能として、ある要求事項が変更された場合、どの設計図書、どのモジュール、どのコードに影響が及ぶか、瞬時にトレース(正展開)が可能です。逆にトレース(逆展開)することも可能です。コストを積算することも可能です。10007の要求事項を満足することができます。品質だけではなく、変更の影響が正確かつ迅速に把握可能となれば、プロジェクト管理におけるコスト・納期の管理にも有効です。この構成管理のプロセス(仕組み)は、非常に重たいプロセスであり、アジャイルとは、正反対の指向にも思われます。10007の要求を満足することは不可能です。アジャイルで、頻繁にイテレーションを繰り返し、変更を加えていく中で、ライフサイクルの全段階で、「要求事項と製品の一致性」を保証していくには、必須のプロセスです。要求事項と製品の一致性を担保できるのか、はなはだ疑問です。航空機やロケット、プラントなど大規模システムで、顧客に部品や組立て途中で見せて、良い悪いを判断してもらい、その都度、変更を加えるというようなやり方は、想像もつきません。これだけ、情報システムが社会インフラ化している現代、『ソフトウェアBOM』の構築は、もはや必須であり、これ無くして、ソフトウェア品質の向上はありえません。ソフトウェア開発の創造性を「芸術」に近いという考え方も分かりますが、根本的に異なるのは、芸術家は他からの要求事項に基づいて創作しているわけではないこと、作品は信頼性や保守性において問題にならないことです。これらを組織的に精度高く管理することと、ソフトウェアの創造性は、必ずしも背反するものではありません。ワープロを使い、自然言語のみで設計図書をかいて、要求事項に識別番号も付与せず、モジュールやコードの識別番号は、プログラマ任せで、個人ごとにバラバラ。試験記録と要求事項も一意に識別番号で照合できない。このような状況からは、早く脱しなければいけませんね。あるべき姿も変わってくるようです。それを”分けて”、あるべき姿だけ考えるのは、単なる分析遊びに終わる可能性も。決めないから、あるべき姿が絵に描いた餅になり、5W1Hがあいまいなままです。担うのかを最後まで決定できずに、結局、現場に押し付けてしまいました。どのような運命をたどったか、想像に難くないところです。とらわれる組織は、分けて考えても、最終的に保守的に落ち着きます。言葉が示唆しています。「プログラムが傷む」ということと、インフラを仮想化するということは、明らかに論点が違うと思います。インフラを仮想化しても、「プログラムの傷み」は救えません。これを救うのは、コンポーネントの構造設計と独立性確保です。企業にとって重要なのはビジネスロジックであり、ここをOSやミドルウェア、周辺機器と独立させることです。次に重要なのが保守技術です。開発時に構造化し独立性を確保しても、改修のたびにコードを汚していくのでは、持続性を確保できません。そのためには、独立性を破壊するような、バイパス手術をやめることです。保守は、開発よりも時間的余裕が無いので、ついついコンポーネント間を安易にジャンプするコードを書きがちです。他人の書いたコードを読みたくないプログラマ心理もそういったバイパスコードを生みます。私は、他人の書いたコードでも短時間で読解し、元のアーキテクチャ構造を破壊せずに改修できるような、プロ中のプロといえるプログラマーも、スーパープログラマーだと思いますが、日が当たらないので見つけるのが大変です。腕のいい大工さんは、新品同様に補修工事(継ぎ木)などできて、それに誇りを持っています。保守に対しプログラマが、記事冒頭にあるように「作り直したほうが安い」と思っている限りは、システムを100年存続させることは難しいと思います。そこで、マスコミは開発プロジェクトの成功事例ばかり記事にせず、保守で30年システムを維持しているような事例をとりあげ、保守してきたプログラマーをヒローとすること。社内でも大々的に匠として表彰・評価することを提案します。顧客も「作り直したほうが安い」というところよりも、既存システムを改修すれば大丈夫ですというところを選ぶべきです。冷静に考えて見ましょう。保守スーパープログラマを育てるには、速読をやることです。速読をやると、読解力が飛躍的に早くなるのはもちろん、視野が広がりるので広範囲に全体を見通して最適な改修方法を見つけられるようになります。速読訓練で、迷路の早抜けがありますので、それで能力向上を実感できます。速読では、これを「虫の目」(線)から「鳥の目」(面)になるといいます。両方?トヨタ方式を導入しようとして成功する工場は1%程度だそうです。成功事例や書籍を読んで「かんばん」を導入すれば、在庫が激減すると思い込んでしまう。いざやりはじめて難しいことに気がつき、道半ばで投げだしてしまうそうです。成功事例の導入段階での難しさをきっちりと取材して記事にせず、美味しいところだけを記事にするマスコミとそれを鵜呑みにする国民性ゆえでしょうか。ものには適材適所があるはずです。欧米の大家が言っているからなんだというのでしょう。虚実を見極める眼力を持ちましょう。探すことでしょうか、それとも、設計の妥当性について延々と議論をすることでしょうか。そもそも、”重大な欠陥”とは、何でしょう。これを、きちんと定義せずに、頑張ったり、目的の再確認したりしても、結局、何をすればよいのか具体的な改善につながりません。ソフトウェア工学の教科書にしても、このようなレビューに関する記事にしても、レビューの目的は、前工程での成果物の品質を高め、後工程での手戻りを少なくするために”欠陥”や”ミス”を発見することだと書かれていませんか。私は、この”欠陥””ミス”という表現にそもそも問題があるのではと考えています。レビューアは、”欠陥”を発見しようと成果物を読み、頭を使うことになります。なると、成果物(文書)の欠陥とは、どうしても誤字脱字が主体となってしまします。データベース設計に欠陥があるかないか、これを解決するのには、議論の時間も長くなります。レビューされる側も、する側も、”欠陥”という言葉にネガティブな印象を、潜在的に受けます。なると脳があまり活発に仕事をしないのではないかと思うのです。ここで、レビューの目的をもう一度、よく考えてみましょう。それは、”後工程での手戻りを少なくする”ですね。後工程とは、将来のことです。手戻りとは、品質・納期・コストへの損失です。将来に起こりえる損失です。これを、”リスク”と言います。このように考えると、レビューで発見すべきは、”欠陥”(すでに発生してしまった事故)ではなく、”リスク”(将来に起こりえる損失)です。重大な欠陥とは、言い換えれば、プロジェクトの品質・コスト・納期(QCD)に多大な影響を与えるような損失です。システムが社会にもたらす大きな損失です。このような記述、設計では、後工程の作業では、このような損失が発生する可能性があるのではないか。運用開始後に、このような損失が発生する可能性があるのではないか。(”この設計は欠陥である。)※特に注目すべきは、”要件と設計のトレーサビリティ”つまり、要件が漏れなくダブり無く設計されていること。”アーキテクチャ”です。この2点に重大なリスクが潜んでいます。このようなリスクは、成果物を穴の開くほど眺めて欠陥を探しても、決して出てこない指摘事項です。頭の働かせ方が本質的に異なります。皆で、リスクを沢山発見することが、プロジェクトのQCDを守り、顧客を守り、そして、自分たちを守ることになるわけです。欠陥やミスを発見して、痛い思いをさせたり、したりするのではありません。次に、それぞれのリスクの強度を評価します。影響度リスク強度大のものから優先的に対策します。乱暴な言い方をすれば、後工程で発生してもリカバリ可能なリスク強度が小さいものは、”受容”して、先送りすることも可能です。画面の色や項目配置など。一歩進んで、QCDを改善できる余地があるかないか、それもリスクとしてピックアップします。この領域では、すでに”欠陥”探しではなく、さらなる付加価値の発見です。この設計内容は、このように工夫すれば、QCDを改善できるのではないか、ユーザの利便性が増すのではないか。この域まで達成できれば、レビューもきっと、楽しく、前向きなものになるに違いありません。ここで、重要となるスキルが、先見性や洞察力、そして、なにより危険予知能力です。一つ、長時間化の問題は、レビュー会議での観点にあります。リスク強度大の指摘事項として、データベース設計があります。ここのリスクは、アーキテクチャや性能に影響が大きく、手戻りが発生すれば、プロジェクトを危機に陥れかねません。それではと、データベース設計の妥当性をレビューで検証しようとすれば、多大な労力を要することになります。最悪の場合、レビューをしているのか、設計作業そのものをしているのか、はたまたデータベース設計の講義を受けているのか分けが分からなくなってしまいます。その挙句に、性能に関しては、実装してみないと分からないなどという結論になったりします。レビューが、このような結果にならないために必要なのが、システム監査の視点です。それは、第三者的に設計作業の妥当性を確認することです。データベース設計であれば、個別の設計内容が妥当かどうかという観点以上に、正規化されているか、索引設計は性能目標を達成できるか、業務要件との整合性はあるか、拡張性を考慮しているかというような観点です。)などを参考にチェックすれば、網羅性が高まり、レビュー品質が属人的になることを防止できます。その上で、例えば、索引設計は性能目標を達成できるかどうかに疑問があるという場合、それを指摘事項(リスク)としてピックアップします。再度、設計を見直すのは、レビューではなく、再設計検討会として、別に設定します。テストなど、一通りのスキルがあれば、レビューをしなくても、ソフトウェアはつくれます。スキルの高い人ほど自信があり、レビューなんて必要ない、時間の無駄と考えるかもしれません。その結果が成功率30%なのです。対策として、新手法やスキルアップも大切ですが、そろそろ、レビューは欠陥探しの場ではなく、リスク発見の場であり、リスク管理により利害関係者(もちろん自分も)を守るものというようにマインド・チェンジしてはいかがでしょう。ITプロジェクトは、兵が疲弊しています。」より詳しいお話は下記の書籍とセミナーで。(3)育成後の人材が、出力となります。入力とシステムの両方がそろっていなければ、ならないはずです。GE流がシステム主導であっても、それなりの挑戦意欲のある人材を採用する必要はあるでしょう。甘くはないと思います。人間の好奇心や挑戦意欲を、何十年も維持させることは容易ではありません。日本にも有名大学卒業生ばかりを採用していますが、10年いたらバカになるという大企業もあります。”人が育つ土壌”が不可欠なのだと思います。どんなに良い苗を植えて、最新の技術で育てても、土壌が良くなければ、良い野菜は採れません。人材育成も、これと同じことが言えるのではないでしょうか。それでは、人材育成における”土壌”とはなんでしょう。それは、そこに集う人達です。仕事をさせていること。画一的に、人を材料扱いしていたら、育成はできません。そのように、人を消耗しているような組織が、存続できることは考え難いです。採用ホームページで、どんなに良いことを謳ってもいずれ、入力が先細り組織も消耗していくことでしょう。嬰児の如し、接してあげられるかどうかです。我が子の成長を見守り、慈しむように、厳しくも、暖かい指導を、日常業務の中でできるかどうか。周りが関心を持って新人を育て、その新人が、次の新人を育て、そのまた新人が、次の新人を育てる。それが自然にできる組織が、人材育成における良い土壌です。若葉は枯れて萎んでしまうことでしょう。その意味や背景の着いて説明もしなかったり。少なくないのではないでしょうか。仲良しクラブである必要はありません。阻害する要因もあります。冷たいの(無関心)は、もっと困ります。一時の業績評価制度により、関心事は、自分の業績だけ。何の特になるという風潮も出てしまいました。これでは、人材育成ができる良い土壌とは、言えませんね。組織員は、トップの背中を見ています。それまでの自分の処遇を忘れません。新しい人にも、自然に同じ様に接するでしょう。同じ様な態度で新人と接することでしょう。培養されていくものです。したがって、一朝一夕に良い土壌はできません。土壌汚染からなかなか抜け出せません。その悪くなった苗が、さらに土壌の質を悪化させるので、とてもやっかいです。骨抜きだと言われてもしかたありません。モチベーションと能力の向上につなげる、重要な要素です。どんな仕組みもシステムも、結局は、”人”が、動かすものです。人事を適切に運用しなければ、企業システムの運用もうまくいきません。私は、人事考課をする立場でも在り、される立場でもあります。日本人特有の”控えめを美徳”とする文化でしょうか。思えば、自分がどれだけ”頑張ったか”を切々と訴える人もいます。人事考課には、2つあって、一つは、業績評価、一つは、能力評価です。客観的に自己評価するのがポイントです。その評価結果を事実に基づいて、プレゼンテーションすることになります。プレゼンテーションは、売り込みと同じです。その付加価値はなにかです。いいかえれば、顧客指向での視点が必要になります。いう認識が、まだまだ希薄です。”プレゼンテーションは、演壇に立ち、パワーポイントを使った発表のことである。いう固定観念があるのでしょう。いう認識を、どれだけの人が持っているでしょう。感じている人が、多いようです。それは、自分の売込みが失敗しているということを意味しているのだと気がつかないのです。ここでも、顧客指向の視点が失われています。いっているのと同じことなのです。人事考課をする側の人においては、時に、業績評価と能力評価を混同してる人もいます。業績は、良い時も悪い時もあります。能力があっても、いつも業績が達成できるとは限りません。スパースターにも、スランプの時は、あります。逆に、能力的には不十分でも、業績をあげられることもあります。業績目標と業績実績の対比で、客観的に評価することになります。客観評価だからこそ、評価もしやすいと言えるでしょう。業績が高いから、能力が高いと混同すると、評価を誤ります。その能力評価ですが、これが難しい。人が人の能力を、適切に評価できるかという問題は、昔も今も同じです。勢い、年功や学歴での評価に走りがちです。同じように年功や学歴でしか、人の能力を評価するすべがありません。この弊害は、組織を硬直化させることは、よく知られたところです。能力は高くない人が昇格するリスクがあります。その他にも、様々な弊害が出てきています。よって、この両方を合わせて評価するのが妥当な線ということになりますね。それと照合することで能力評価を行うという方法もあります。これが適切に運用されるには、やはり、使う側(人事考課する側)の意識改革も必要です。いやいや、まだ、年功や学歴が云々だからと評価をねじまげてしまっては、意味がありません。組織改革はできないことになります。評価を受けてきた人が沢山いるからです。簡単に、骨抜きにされてしまうのです。人事制度は、意図したように適切に運用されているでしょうか。企業システム戦略においても、人事は重要課題です。人を変えるために、人の仕組みを変えなければ、結局、根底は何も変わらないからです。人事制度に良く表れます。ITPro●(IT投資の)本当の意思決定者は誰か『投稿』CIOオフィスとは別のガバナンス経営と情報をつなぐ新しい価値、ミッションを持つCIOオフィスの創設もよいですが、内部統制・内部けん制の意味から、システム部門と経営企画部門と事業部門の3者による意思決定機関(審査会)方式というやり方もあります。この場合、ITベンダは、どこか一箇所(CIOオフィス)を口説けば事足りるという仕組みにはなりません。ソリューションを売り込むには、システム部門と経営企画部門と事業部門の3者をヒアリングし、その利害関係を整理し、全体最適な提案をしなければなりません。ないと、システム部門に行けば、経営に関しては経営企画部門に聞いてくれ、経営企画部門に行けば、ITに関しては、システム部門に聞いてくれ、事業部門に行けばITはシステム部門に、経営判断は経営企画部門に聞いてくれとタライマワシにあうのがおちです。PMBOKでもステークホルダ分析が重要となってきているようですが、特定の利害関係者だけを口説けば商売ができるというのも安易ではないでしょうか?特に、ハードウェアと異なり、情報システムは利害関係者が多岐にわたり複雑です。したがって、意思決定者が”見えなくなっている”のは、システム部門が弱体化したからではなく、ホスト一極集中の単純な昔(システム部門だけ口説いていればよい時代)に比べ、顧客のIT経営環境が複雑化したため、ITベンダの提案能力が着いていけなくなっているのかもしれませんね。利害関係者や売り込み先(ターゲット)の分析は、提案書作成の第一歩(マーケティングの初歩)だと思います。「プロジェクト評価の反省点」では、失敗の”事実”だけでなく、そこに至る経緯や兆候を振り返り、「危険状況」として記述します。この危険状況を読んで、そこに潜む危険や危険要因を予知し、対策を考えるのが危険予知訓練です。危険予知能力が高まれば、同じような失敗を回避するリスク管理を効果的に行えます。対策は、分かりやすい標語にして、リスト化すれば、レビュー用のチェックリストとしても使用できます。報告書を報告だけの目的で終わらず、貴重なノウハウとして再利用できれば、形骸化も防止できるでしょう。レビュー実践とチェックポイント』です。記事にあるように有効なレビューを行うために、目的を再確認してみることは意義のあることです。確認だけではなく、再考してみるのがよいでしょう。レビューは、”欠陥”の除去(品質向上)だけではなく、将来(後工程〜運用段階)に発生しうる品質、コスト、納期に対する危険(リスク)を予知し、対策を講じるためにあるリスクマネジメントの重要なツールであると考えられます。誰しも”欠陥”は嫌なものです。その欠陥が引き起こすリスク、プロジェクトの危機にまで考えが至れば、指摘するほうも、されるほうも前向きに取り組むことができるのではないでしょうか。チームが前向きにレビューに取り組むことで、欠陥やリスクだけでなく、付加価値を高めるような指摘(例えば、よりよいユーザインターフェースなど)ができれば、さらにレビューの有効性は高まります。以下は、その具体的な実践方法に関する書籍とセミナーです。すれば、保守は、“やっつけ”でも良いのです。保守以外は、開発です。既存のシステムに機能を追加するのも開発です。開発は、必ずしも新規であるとは限りません。そのような開発を、保守として“やっつけ”で行うことにそもそも、大きな問題が在ります。税務上の観点から言えば、保守は修繕費(経費)であり、それ以外は、資産化対象となります。ここで、資産化する必要があるのは、将来の収益を目的とする機能の追加なども含みます。修繕費で良いのは、明らかに収益の獲得にならないものです。法改正対応やプラットフィームの老朽更新に伴うソフトウェアの移行や修繕などです。保守とは、現状のシステムを効果的・効率的に運用するためにベストな状態に保つことであり、資産価値に変更を加えるような機能追加などではないのです。一般的に、これらの作業はアーキテクチャや基本構造は変更しないため、“やっつけ”でも、問題とはなりません。開発と同じように重たいプロセスや統制は、ビジネスへの迅速な追従の足かせとなりかねません。“やっつけ”保守からの脱却を図ったあかつきに、ソースコードとドキュメントは、バッチリ。ビジネス対応スピードはガタ落ちでは、本末転倒、シャレになりません。道具をピカピカに磨いても、必要な時期に間に合わないのでは、無用の長物です。そこで、“やっつけ”でも、コードを汚さないようにするには、ひとえに保守技術者の腕と心構えしだいです。ここで、保守を行うのは、プログラマではありません。保守では、短期間で既存コードを解読し、アーキテクチャを理解し、どのようにコードに手を入れるか、瞬時に最適解を得なければなりません。これは、アークテクト+SE+プログラマの高度なスキルが必要です。保守は優秀なマルチプレーヤでなければできないのです。保守技術者は、極めて高度の専門職であり、プロ中のプロです。情シ部を戦略部門化など考える前に、こうしたプロ中のプロを育成し、適切な処遇を与えなければ、信頼が足元から崩れ去ります。ところが、保守に初級プログラマをアサインし、ここで下積みをさせてから、開発へと考えているケースがすくなくありません。(企画担当には、そもそも保守の経験さえもさせない)しかも、指導者が修正したコード(現物)をレビューせず、放任しているのです。開発は花形、保守は地味という誤った認識が諸悪の根源かもしれません。システムのライフサイクルで2/3が保守なのにです。メインフレームのシステムはレガシと揶揄されながらも20年以上も動いているのですが、オープン系は、10年持たないのです。オープン系をやりたがる若い技術者を、短期開発に次々と投入し、メインフレームの保守技術者並にプロ中のプロとして長期的な育成をしていないからです。そのため、“やっつけ”仕事=“やっつけ”ソースとなり、コードが汚れてしまうのです。私は、保守を20年以上やっていますが、開発に比べて、保守こそが大人のプロの仕事だと思います。ビフォーアフターでも、リフォームの匠は素晴らしい。彼らの仕事には、いぶし銀の渋さがあります。技術的には優秀であっても、心構えが低いと、これもコードを汚す結果となります。ベテランでも保守という仕事に誇りややりがいを見出せず、“やっつけ”手直しをしている場合などです。過去に、ユーザの要求に対して、既存コードを解読し、最適化された改修をすれば、たった2〜3行の条件を追加すればことたりるのに、リスクを恐れた保身とコード解読の手間を惜しんで、ユーザの要求した仕様書どうりにバイパス手術し、ほとんど既存と類似のコードをツギハギしたケースを知っています。その時は、本番移行前に私がコードをレビューして指摘し修正させましたが、大いに”速読”が役立ちました。-------------------------http://www.geocities.jp/aoshima_systems/taiken.html#soku指導者や管理者がコードをレビューしないのは、その時間が無いのが主因です。保守ごときは担当者に任せておけば事足りると考えているフシもあるのでしょう。保守をやればやるほど、保守性が悪化するという悪魔のサイクルに、こうして陥っていくのです。保守のマネジメントを行う立場にあるなら、速読は必須であり、コードレビューは必須です。アウトプットが要求どうりならOKではなく、如何にコードを汚さず、最小の変更で要求を満足させるか、美的センスをもってコードレビューする必要があります。それから、私が考える“やっつけ”保守では、ドキュメントの保守は不要です。唯一無二の正とすべきです。した条件追加や運用改善を全てドキュメントに反映し、コードと一致させるのは困難であり、かつ、ムダです。ドキュメントを改訂してからコードを修正せよというのは、あるべき論であり理想ですが、保守現場からすればナンセンスです。明日までに条件を追加して欲しいというユーザに、”まず、ドキュメント改訂してレビューしてから、、、”そんなことでは、とうてい仕事になりません。コードとは、そもそも、プログラミング言語で記述されたドキュメントそのものなのです。コードを読めば、変更内容の全てが分かるようにしておくことが第一です。ドキュメントの改訂が必要になるのは、アーキテクチャの変更や機能追加があった場合です。これは、既存のコードを解読しても分からないからです。この規模は、すでに保守ではありません。開発として、きちんとしたプロセスを適用すれば、“やっつけ”のような間違いは起こりません。保守でないのに、保守として“やっつけて”しまうから“やっつけ”ではすまなくなるのです。このような問題を引き起こさないためには、それぞれの組織が有する保守技術者のレベルとリスクを見極め、どこまでを保守でやるか、どこから先は開発とするか、案件の”切り分け基準”を明確化することです。”保守開発”というグレーゾーンは極力排除しましょう。これは、JSOXのプログラム変更管理でも要求されています。この切り分けによって、適用するプロセスや統制が異なります。JSOXのプログラム変更管理で、職務分離や承認証跡、プログラム変更履歴の確保とモニタリングを厳しく要求され、監査されるのは、保守です。保守は”やっつけ”で行われるからこそ、不正のリスクが高いと考えられるからです。いって、保守を”やっつけ”でやってはならないという不条理な要求は、JSOXでもしません。そのかわり、統制をしっかりしましょうと言うわけです。ITPro●情シ部は情報戦略部門になれるのか?『投稿』そもそも情報戦略は必要でしょうか?ほとんどの経営者は、自社の情報戦略は?と聞かれても、答えられないと思います。それは、経営者が疎いのではなく、情報処理設備を高く売るために作られたキャッチコピーだからではないでしょうか。情報システム部門は、自社業務を遂行するために必要な情報処理設備に対して、できるだけ効率的・効果的な投資をする役割があります。そのためには、自社業務の将来方向性などは当然、考慮する必要があります。日本の経営者は、それを情報戦略などと言いません。情報システム部門を、情報戦略部門化にと言うのもピンと着ません。その前に情報を活用して大成功を治めることができるのは、明主や賢将だけと孫子も言っています。多くの経営者の経営のよりどころは情報ではなく、己の技術や商才、コネだとすれば、情報戦略や情報戦略部門は、無用の長物でしかないのでは?情報の戦略では無く、企業が勝つための仕組みはどうあるべきか。それが、企業システム戦略です。これは、一般的な情報システム部門の枠組みでは難しいテーマです。既存の枠組みを超え、企業システム戦略部門として再生する必要があります。それができるのは経営者であり、情報システム部門ではありません。●日本企業を見限ったインドの“システム屋”から学んだこと『コラム』インド人が言っていることは、日本のシステム開発現場でも同意できます。要件をしっかり決めてから開発するフロントローディングへの過剰意識。