プロジェクトマネージャ養成講座 |  プロジェクトマネージャ小論文合格講座CD |  △HOME

システムアナリスト日記 |  システムアナリスト小論文・記述式対策講座 |  システムアナリスト小論文突破講座CD


 加藤忠宏のプロジェクトマネージャ日記

   掲示板に書ききれない情報を日記風にまとめました。
   気まぐれに更新します( 2004/8/30更新)
   →2005年度版はこちら

テンプレート活用と短期開発
平成16年 8月30日(月)

 著作の執筆や原稿の執筆が多重化していたのと、論文試験の添削がかなり重複していたこと、そして何よりも今年はプロジェクトの当たり年で、 仕事が重複していたので更新が遅れてすみませんでした。日経ビジネスソリューションを読んでいたら面白い記事があり。論文用に要点を整理してみました。

○テンプレートとは

 テンプレートとは、わかりやすくいうと、データベースとWebベースの業務システムを連携する仕組みです。 通常、このような仕組みを作るときはCGI(Common Gateway Interface)を使うことが一般的でした。
 しかし、CGIと違う点は、テンプレートでは、HTMLをベースにして、「フォーム」「リスト」「パラメータ」をセットすることによって、 「Webとデータベース間のデータの流れを記述すること」です。
 この結果、テンプレートのメリットは次のようになります。
  1. データベースとWeb系情報システムとの連携が容易かつ構築が早い
  2. Web経由のメール(SMTP :Simple Mail Transfer Protocol)とHTTP(Hyper Text Transfer Protocol)のデータとが同一データとして処理できる


○早期開発とテンプレート利用

 テンプレートを利用した開発で納期と開発規模を抑制した事例の要点は次のとおりです。
以上

 参考文献:「テンプレートとは」http://www.jcc.co.jp/get/p3_2.html
        「商談の軌跡」日経ビジネスソリューション 2004/08/30 P37




要件定義とスケルトン開発
平成16年 7月24日(土)

 今日は要件定義について考えて見ましょう。

○要件定義の難しさ
 要件定義の正確さは設計品質を高めるためにはとても重要な作業です。しかし、現実には大変困難を極める作業といえます。私は次のような工夫をして要件定義の品質を保っています。

 [工夫]
 1.業務マニュアルを入手する
 2.業務マニュアルに基づき、DFD、機能階層図を作成する
 3.DFDをユーザに説明し、例外業務と例外機能を洗い出す

 基本的には、これで機能の曖昧な点は相当な頻度で明確化できます。

○画面遷移とプロトタイプ
 しかし、ユーザによっては「画面イメージを示してほしい」等の要望があがります。弊社では画面のプロトタイプを示したり、中途開発中のソフトウェアを弊社のWeb上におき、ユーザにIDとパスワードを与えてみていただきます。
 特に意識はしていなかったのですが、これをスケルトン開発というようです。

○スケルトン開発
 スケルトン開発とは、画面イメージをWeb上に示し、開発側とユーザ側で情報を共有することです。同様に進捗中の画面もユーザに見てもらいます。スケルトン開発のメリットは次のとおりです。

 [スケルトン開発のメリット]
 1.情報の共有化により、ユーザの信頼を得られる
 2.ユーザの視覚イメージに訴え要件定義を詰めることができる
 3.その結果、手戻りがすくなくなり、開発コスト低減や開発期間の厳守に寄与する

以上



ソフトウェア保守の標準化とJIS X0161
平成16年 7月20日(火)

○プロジェクトマネージャとソフトウェア保守標準化の必要性
 ソフトウェア保守といいますと、「試験区分的には『システム管理』だろう。」という方がいらっしゃるかと思います。しかし現実には、プロジェクトマネージャにも保守性が要求されます。その理由は以下のとおりです。

[ソフトウェア保守が開発局面で重視される理由]

  1. JIS X0129-1994の述べる品質特性のなかに、保守性が含まれている
  2. ソフトウェア開発は、SLCP-JCF98のように、トータル的にソフトウェアライフサイクルのなかの位置プロセスと考えるべき
  3. 保守目的が従来の安定稼動から、機能拡張重視の流れになっていること

○JIS X0161
○保守プロセスで要求される文書
 保守プロセスで用いられる文書は、@変更依頼書(change request)、Aソフトウェア関連ドキュメント、Bソフトウェア品質保証計画書、C保守計画書、D引継ぎ書、E廃版計画書です。 特に変更依頼書は2つあって、修正依頼書(modification request)と問題報告書(problem report)があります。


○保守の体系
 JIS X0161の保守の体系はその体系を次のように分類しています。
 保守体系 -------(1)訂正 -------(1)-1.是正保守・・・問題の再発防止
      |   |---------------(1)-2.予防保守・・・潜在的障害の予防
      |-----(2)改良  --------(2)-1.完全化保守・・ソフトウェアの性能や保守性の改良
          |---------------(2)-2.適応保守・・・利用環境変化への適応

○感想
 保守というと、比較的に地味な分野としての印象が強いですが、情報システムの監査などをしていると、随分、保守コストの肥大化が問題になることがあります。 そのような意味でも開発段階から保守性を考慮した情報システムの開発が必要と考えています。


参考文献 「プロジェクトマネージャテキスト」P171~175 財団法人 日本情報処理開発協会
 「Overview of JIS X0161:2002 Software Maintenance」 Kazunori SHIOYA, Technical Report SRA-KTL-2003J-001
 「ソフトウェア保守」P36 日経コンピュータJuly2004 7/12





アジャイル・ソフト(agile soft)開発技法
平成16年 7月15日(木)

 みなさんはアジャイル・ソフト開発技法という手法を知っていますか。
ここで、アジャイル(agile)とは、素早いという意味を持つ、経営環境の変化に対応するため素早くソフトウェア開発を行うという意味を持つのです。
 実際にはアジャイル・ソフト開発技法は議論が始まったばかりで、まだ確定的な技術はないのですが、おおよそ、次のような特性を備えているといえそうです。


[アジャイル・ソフト開発技法の特性]

  1. 開発に時間を掛けすぎない:時間を掛けると完成後にユーザ要件と乖離することがある
  2. 当面、稼動するシステムを開発し、ユーザに見せながらユーザ満足度を精製してゆく
  3. ウォーターフォールモデルと対比的な考え方である
  4. アジャイル開発では計画的反復作業をスケジュールの中に事前に組み込み、スパイラルな開発アプローチをとる

 アジャイル・ソフト開発の代表的な手法として、アジャイルモデリング(AM)があります。これは効果的なモデリングと文書化に焦点を絞ったモデリング手法のことです。すなわち、まずは簡単で良いからモデリングを行い、少しずつこれを改めてゆき、時間の経過に伴って代わってゆく経営環境や業務環境の内容をモデル化のなかに受け入れてゆくのです。


赤字プロジェクトの予防対策について
平成16年 7月 6日(火)

○問題の提起
 大手、ITベンダーが軒並み、営業利益や経常利益を減収させています。その原因は、 赤字プロジェクトに起因することが指摘されています。(注1) よくあるケースとして、営業が顧客に押し切られ、要件定義が不十分なまま請負契約を締結し、開発規模が巨大化した結果、赤字になるケースが多いと思います。

○二重の見積りによる、見積り精度の向上
 見積手法としてFP法などの手法が周知ですが、見積り精度を向上させるために、他の手法を交えた見積りの二重化によって、見積精度を向上させる方法があります。 その概要を整理すると次のようになります。

  1. FP法ではユーザから見える帳票、画面、データベースなどの側面から見積り実施
  2. 内部的な機能や開発の技術的妥当性の観点からの見積り実施
 上記の2つの結果の差が少なければ見積もり誤差が少ないといえます。

○営業力強化
 とはいっても技術チームが見積もり精度をあげても営業が不適切な合意をしてしまっては意味がありません。 その意味でも、営業チームに対する@営業トークの標準化、Aプロジェクトリスク教育、B契約締結の知識教授が必要でしょう。



(注1)参考:「さらば赤字プロジェクト」日経ソリューションビジネス2004.06.30 P23



言語変換ツール Lyee方式による効率的な情報システム開発
平成16年 7月 5日(月)

○レガシーマイグレーションの問題点
 レガシーマイグレーションといって、旧来の情報資産の運用が問題となっています。
 特に、4GLなどのツールを使っている場合の、ライセンス料の継続的支払いなどによる無駄な運用コストの増大は、非常に問題視されています。 こういったツールはシステム開発の効率化に寄与はするのですが、他社とのシステム連携や情報システムのオープン化の阻害要因になるのです。

○言語変換ツール Lyee方式とは
 上記のような問題を解決するために4GLを汎用的言語に置き換えてゆくのですが、 そのためにLyee方式を用いてソフトウェア開発や旧来開発したプログラムの自動変換を推進します。Lyee方式の手法は次のとおりです。


[Lyee方式の手法]

  1. 言語変換ツールを使う
  2. 変換前後のプログラム言語の特徴をパラメタで定義
  3. パラメタには、言語の文法特性と開発標準を定義

○Lyee方式の課題と対策
 言語変換プログラムの利用を誤るとシンタックスエラーを出力するケースがあります。言語変化プログラム設定に当たっては次のような工夫が必要です。
  1. 言語変換パラメタのチェックリスト作成による定義漏れの予防
  2. 旧来システムの標準外の機能定義していた部分の調査・洗い出しと対応

○成果の評価
 不二サッシ(株)は上記のLyee方式利用の成果として、 元のプログラム500本、20万ステップを25人月で達成したのだそうです。


参考:「第4世代言語の基幹をCOBOLに」日経コンピュータ(2004.06.28)P16




派遣法改正
平成16年 7月 4日(日)

 16年3月1日に、労働者派遣法が再度、改正になりました。

○派遣期間の延長
 政令で定める26の専門的業務について、改正前は、派遣期間が「3年が限度」だったのですが、改正後は「3年限度とする取扱いを廃止」となりました。 プロジェクトマネージャとして、関係のありそうな専門的業務として、(1)ソフトウエア開発、 (6)通訳、翻訳、速記、(7)秘書、 (8)ファイリング、(9)調査、(10)財務処理、(11)取引文書作成、 (12)デモンストレーション、 (17)研究開発、(25)セールスエンジニアの営業です。

○紹介予定派遣
 紹介予定派遣とは、「就職することを前提として、派遣すること」です。従来は禁止されていましたが今回改正からOKとなりました。このような場合、派遣元企業は一般労働者派遣業と職業紹介事業の届出が必要です。

○事前面接の解禁
 従来は派遣前の面接が禁止されていました。これが、派遣労働者の力量をブラックボックスとするため、プロジェクトリスクになっていましたが、改正によって、派遣前に労働者を特定できることになりました。

●加藤の感想
 派遣法は、めまぐるしく変化するので対応が大変です。平成15年に改正されたと思ったら16年にも改正です。これは社会の就労環境の劇的変化と関係があると思われます。弊社でも正社員募集すると、フリーターを脱出した若者や高齢者も応募してきます。
 特に困るのがフリーターです。基本的な職業訓練が行われていないため、雇用しても会社への適合が難しかったり、そもそも職業的能力が無いケースがままあります。

参考:厚生労働省ホームページ「改正職業安定法及び改正労働者派遣法が施行」
   http://www.hiroroudoukyoku.go.jp/contens/antei/antei.html?main02Frame/contens/antei/contens/topice/k_roudoushahaken_gaiyou.html




セキュリティホールを作らないシステム開発
平成16年 6月26日(土)

 2004年6月21日、春試験の合格発表があり、皆様のお蔭様で、無事システム監査の試験に合格することができました。
 これで、基本的に秋・春試験とも取りたい科目はすべて取り終わったので、好きなバードウォッチングなどの趣味の時間が取れることが嬉しいです。
 さて、今日はセキュリティの話題です。

●情報システムの開発初期からセキュリティ機能の作りこみ
 情報セキュリティの国際規格であるISO17799によると、セキュリティ機能はソフトウェア開発の企画段階から作りこむべきだとしています。 その理由は、設計段階や運用段階でセキュリティ機能を作りこむよりも安価で容易に実現することができるからです。

●ウィルスによる脅威の増大
 最近のウィルスは、OSやアプリケーションのソフトウェアの脆弱性の発見と時間を置くことなく発生する、あるいは、セキュリティホールを突く高度な機能を備えているなど脅威が増大しています。
 ここで問題なのは、セキュリティ対策が後手後手に回っていることであり、セキュリティホールの発見と対策パッチ等の提供との期間にウィルスに感染し、ネットワークを通じて被害が拡大することにあります。

●セキュリティに強いソフトと開発の努力
 プロジェクトマネージャとして、ウィルス感染に強いソフトウェア開発を行うことを考えなければならないと思いますが、以下の様な要点がありそうです。

  1. ソフトウェアのセキュリティホール(論理的アクセス可能、未使用のポートの放置)をバグの一形態と捉え、設計検証で是正・予防する
  2. セキュリティホール未然予防のために開発ツールの活用を行う
  3. ウィルスに感染した可能性のあるホストをネットワークに接続させないような仕組みを作りこみ、例えウィルスが感染しても拡散できないようにする
  4. ウィルスに感染しても機密情報が漏洩しないように、機密情報の対ダンパー性を高める
※耐ダンパー(damper)性
 ダンパーとは、「くじくもの」のことです。だから、耐ダンパー性とは、情報の改ざんや複製が極めて困難な状態や、安全性が防御されている状態のことです。情報の暗号化や秘匿などがこれにあたります。
 参考:NIKKEI BYTE 2004 July Special Edition




オフショア開発について
平成16年 6月17日(木)

 岡山から東京に向かう新幹線の中で、日経ソリューションビジネス2004年6月15日号(失敗しないオフショア開発、岡崎邦明)を読んでいたら、 オフショア開発についての論文が出ていました。

 オフショア開発(offshore development)とは、海外の委託先に、情報システムの開発や運用を委託することです。 狙いとして、コスト削減や海外の優れた技術者の活用が上げられます。 しかし、言語の問題や文化の違いなどで失敗するケースも多いようです。 また、海外の技術者は転職を頻繁に行われるため、重要な人物のロストがプロジェクト中途であるとプロジェクトマネージャとしてきついですね。

 オフショア開発の成功要因を上記、論文から参照すると次のようになりそうです。

  1. コーディネータに相当するブリッジエンジニアを活用する
  2. 海外の開発メンバのMBO(Management By Objectives ):目標管理制度の活用
  3. 相手の国の文化を尊重する
  4. 合意点、非合意点をあいまいにせずに、明確化する
 これらの項目は、必ずしも海外取引だけの問題ではなく、国内でもいえると思いますがいかがでしょうか。



ITベンダー淘汰の時代到来です。
平成16年 6月15日(火)

 大手ITベンダーが協力会社再編に出ているようです。理由は、システム開発コストの削減です。
その手法は極めてシンプルです。協力会社の数を絞り込み、特定の協力会社に集中的に発注し 発注単価削減を依頼するそうです。
 う〜ん、嫌ですね。考えたくないですね。
 弊社は開発の比率が少なく、ITコンサルティングが多いからまだ良いのですが、
ソフトウェアハウスは生き残りのために大変だと思います。

 それでは、どのような会社が有利なのでしょうか。その要因を整理しておきます。

  1.ISO9000やISO14000などのマネジメントシステムを持つ企業
  2.CMM(Capability Maturity Model):ソフトウェアの能力成熟度モデルのレベル3以上の企業
    =プロジェクト管理のマネジメントシステムを持ち、文書化されている=
  3.プロジェクトマネージャ資格、PMPなどの有資格者を保有する企業

 確かに資格がなくても優秀なエンジニアがいることも知っています。
また、ISOの認証取得をしなくてもしっかりした仕事をする企業がありますが、
厳しい時代にあって、スキの無いプロジェクト管理が求められているようです。



ERPパッケージのサポート期間
平成16年 6月14日(月)

 今日、日経コンピュータ2004年6月14日号を読んでいたら、考えさせられる記事が載っていました。
SAPが提供するERPパッケージ「R/3」について、標準サポート期間は出荷後8年で終了だそうです。
 ERPは通常、基幹情報システムに導入されるものです。
しかし、導入したとたん、「実は、8年でサポート打ち切ります」といわれたら、腹立ちますよね。
ご存知のとおり、基幹システムは10年程度の耐用が常識です。

 ここから分かるように、購買調達にあたって、性能、コスト、機能の充実さ、業務への適合性、技術力だけでなく、 サポートの永続性が重要だと思います。
サポートの永続性に影響を与える要因をいくつか挙げておきましょう。

  1. 提供ベンダーの財務状態
  2. 提供ベンダーの経営環境と経営戦略
  3. 競合企業の経営戦略
  4. 業界の評判

 これは、単にERPだけに留まらず、協力会社との取引関係に言えそうですね。
以前、あるお客様がISPと契約をされました。契約にあたっては、親族の会社だからという理由が大半でした。
でもそのISPは半年後に倒産し、お客様はITによるサービス継続が危機に陥りました。
購買調達においては、慎重さが求められます。



プロジェクトマネージャ養成講座 |  プロジェクトマネージャ小論文合格講座CD |  △HOME

システムアナリスト日記 |  システムアナリスト小論文・記述式対策講座 |  システムアナリスト小論文突破講座CD



アイ・リンク・コンサルタント
加藤忠宏
TEL:054-205-3320

info@katoken.gr.jp