【楽天ブックスならいつでも送料無料】ITプロジェクトの英語 [ 塚本俊 ]
ITプロジェクトの英語(無料MP3音声付き) (ビジネスエキスパートEnglish)

塚本 俊・小坂 貴志

ジャパンタイムズ

2015年刊



 システム開発プロジェクトの工程定義・・

 オフショア先や海外拠点との仕事の大前提になります。

 PMBOKの用語との紐付けもしておいた方がいいですね。


Initiating
  Creating business plan
  Estimate & proposal
  Request for managerial & final decision 稟議と決裁

Project Planning
  Creating project plan
  Creating Project Charter プロジェクト憲章
  Decide development method
  Defining Project Scope
  Creating WBS
  Defining output  
  Making a project schedule
  Creating an organizational plan
  Creating a personnel plan
  Creating a cost plan
  Creating a test plan
  Creating a communication plan
   identify project stakeholders
  Creating project standards
  Creating development environment plan
  Creating migration / expansion plan
  Creating a project management plan
  Holding kick-off

Executing
  Current system analysis
  Requirement definition
  Functional design / Non-functional design
  Development (Coding / Unit test)
  Integration test
  System test
  User test
  Introduction of a system
  Migration rehersal
  production migration
  Launching production release / development
  Maintenace

以下、
Control
Closing ..




<目次>
Chapter 1 立ち上げ
No.1 企画書の作成
No.2 見積りと提案
No.3 稟議と決裁
No.4 プロジェクト計画の作成

Chapter 2 プロジェクト計画No.5 プロジェクト憲章の作成
No.6 開発手法の決定(アーキテクチャとフレームワーク)
No.7 プロジェクトスコープの定義
No.8 WBSの作成
No.9 成果物の定義
No.10 プロジェクトスケジュールの作成
No.11 組織計画の作成(プロジェクト体制)
No.12 要員計画の作成
No.13 コスト計画の作成
No.14 テスト計画の作成
No.15 コミュニケーション計画の作成
No.16 プロジェクト標準の作成
No.17 開発環境計画の作成
No.18 機器導入計画の作成
No.19 移行/展開計画の作成
No.20 プロジェクト管理計画の作成
No.21 キックオフミーティングの実施

Chapter 3 実行
No.22 現行分析
No.23 要件定義
No.24 機能設計
No.25 非機能設計
No.26 開発(コーディング/単体テスト)
No.27 統合テスト
No.28 システムテスト
No.29 ユーザーテスト
No.30 システム導入
No.31 移行リハーサル
No.32 本番移行
No.33 本番リリース/展開
No.34 保守

Chapter 4 管理
No.35 プロジェクト管理
No.36 進捗管理
No.37 コスト管理
No.38 品質管理
No.39 変更管理
No.40 問題管理
No.41 リスク管理
No.42 要員管理
No.43 構成管理
No.44 セキュリティ/個人情報管理
No.45 ステークホルダー管理
No.46 コミュニケーション管理
No.47 チームビルディング

Chapter 5 終結
No.48 プロジェクト完了手続き
No.49 プロジェクトの評価
No.50 プロジェクトの成功と失敗の記録
スポンサーサイト


ケイパー・ジョーンズ「ソフトウェア工学のベストプラクティス ―ソフトウェア工学の真の工学への発展をめざして―」

Capers Jones

富野壽・岩尾俊二 監修

水野哲博・吉田善亮 訳

共立出版

2012年刊



 ケイパー・ジョーンズさんの新刊・・

 といいつつ、原著は2009年に出ていますが、訳出いただきました。


 まだ手に取ったばかりですが、

 いまから40年後のソフトウェア開発の現場を予測した
 
 3章の「2049年頃のソフトウェア開発と保守についての予見」に、

 目が留まりました。


 とっても興味のある論評なのですが、

 1980年代当時、2000年頃には実現しているはずの

 プログラムの自動化など、聴いたようなことが改めていわれています。

 2049年頃には必要な道具立てが揃っているか、またそうでない場合でも、

 必要なものが何かがわかっているはず・・・というトーンでした。

 SEやプログラマーが、単純作業をやっているのであれば、自動化も容易なので

 しょうが、そうでないことの裏返しなのだと思います。

 でも、あるべき未来像から逆算することで、現在の仕事の効率化や、

 効果を求めるべき領域が明らかになってくると思います。




≪1960年から2009年の現在に至るまで、ソフトウェア開発は基本的に

 工芸的な色彩が強かった。

 複雑なアプリケーションはそれぞれ固有のものとして設計され1行ずつ書かれる

 ソースコードから構築されてきた。≫
 
 このような開発は、効率的でも経済的でも、安定したレベルの品質やセキュリティを

 満たすことはできなかった。


 ケイパーさん、このような状況のソフトウェア工学は、

 芸術的表現から、真の工学になってほしい、といいます。

≪ソフトウェアが真の工学分野になるためには、

 コード開発だけでなくもっと多くのことに関心を寄せる必要がある。

 アーキテクチャ、要求定義、設計、コード開発、保守、顧客サポート、訓練、

 文書化、尺度と測定、プロジェクト管理、セキュリティ、変更管理、ベンチマーク、

 およびその他の多くの主題を考えなければならない。≫




○未来の要求分析

 未来の要求分析は、まず最初に、インテリジェントエージェントやアバターを

 使って、Webやデータベースに蓄積された、ソフトウェアや技術文献、

 マーケット情報などあらゆる関連情報を収集、分析することからはじまるといいます。

 
≪・・ソフトウェア再利用が成熟し広範囲にわたる再利用成果物のカタログが

 利用できるようであってほしい≫といいます。

 再利用されるソフトウェアは、品質やセキュリティは保証されていること。


 また、インテリジェントエージェントは、

≪・・計画中の機能と類似の機能をもつすべての既存特許を収集し分析するために

 起動されることになるだろう。≫

 なぜなら、特許侵害による巨額の出費により、開発中止になることを未然に防ぐことが

 必要とされているため。

 さらに、≪・・早期の規模予測機能、開発時の要求変更を予測する機能、

 顧客の学習曲線のコストを予測する機能もときょの保護が必要である。≫

 現時点の見積りツールには、このようなき3つの機能を持つものはない。




 しかしながら、現在の再利用のレベルはまだまだ。

≪・・SOAもOO(オブジェクト指向)もアルゴリズムやビジネスルールのレベルでは

 古いアプリケーションの利用を正式には含めていない。・・

 さらに、OOパラダイムは惜しいところまで近づいているものの、

 両者ともにすべての新機能を再利用可能な開発対象とは見てはいない。

 また、SOAとOO手法の品質管理とセキュリティプラクティスは本当に安全な

 アプリケーションにとって必要は厳格さを持ち合わせているとはいえない。≫
 
 


○未来の設計

≪設計は、すべての類似アプリケーションのアークテクチャと設計の注意の深い

 分析から始まる。≫

 
 現在と未来の設計の非常に重要な差異の1つは、

≪企業内部、商業組織、あるいは品質が保証された再利用可能な機能ライブラリからの
 
 多くの標準的な再利用部品の利用であろう。≫

≪注意すべきは、経済的に成功するためには再利用成果物は欠陥レベルに近いことの

 保証が必要なことである。≫


≪類似の古いアプリケーションからの情報を利用するためにはエキスパートシステム

 による設計ツールが必要である。

 このツールは静的解析、複雑度分析、セキュリティ分析、アーキテクチャと設計の

 構造分析の機能を含むだけでなく、古いコードからアルゴリズムやビジネスルールを

 抽出する機能ももつことになるであろう。≫


 上記の機能は、とってもハードルが高いと思いますが、

≪既存のアプリケーションの構造、機能、性能およびユーザビリティの分析が

 できるエキスパートシステムは、ソフトウェアを工芸から工学に変えるための

 基本的な要件であろう。≫



○未来のソフトウェア開発

 固有アプリケーションのコードを1行ずつ書くスタイルから、

 品質やセキュリティは保証されたソフトウェアの再利用が前提となる。


 そのためには、新規に開発されるにあたっては、再利用を考慮したものになる

 必要があります。

≪・・後に加えられる新しい機能に配慮しつつ、既存の再利用可能なコンポーネントを

 すべて集めて、機能するプロトタイプを組み上げることであろう。

 このプロトタイプはユーザビリティ、性能、セキュリティ、品質等の基本的な

 評価に用いることができる。≫
 
≪アプリケーションの新機能は単一の利用を目指すのではなく、

 それ自体が再利用可能なコンポーネントになることを目標に計画される・・≫




 そのためには、

 品質とセキュリティの欠陥を発見できるインテリジェントエージェントと

 エキスパートシステムが必須となる。



<目次>
1.ソフトウェアベストプラクティスの定義

2.50のソフトウェアベストプラクティスの概観

3.2049年頃のソフトウェア開発と保守についての予見

4.ソフトウェア要員はどのようにしてスキルを学ぶか?

5.ソフトウェアチームの組織と特化

6.プロジェクト管理とソフトウェア工学

7.要求定義,ビジネス分析,アーキテクチャ,エンタープライズアーキテクチャ,設計

8.プログラミングとコード開発

9.ソフトウェア品質:ソフトウェア工学の成功の鍵


【送料無料】ソフトウェア工学のベストプラクティス [ ケーパーズ・ジョーンズ ]

【送料無料】人月の神話新組新装版

人月の神話 フレデリック・P・ブルックス Jr.


第16章 銀の弾などない――ソフトウェアエンジニアリングの本質と偶有的事項


≪・・私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じように
 ソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を
 聞くのである。≫

しかしながら、

≪技術においても管理手法においても、それだけで10年間に生産性や信頼性と
 容易性での飛躍的な改善を1つでも約束できるような開発は1つとしてない。≫



≪本質的な難しさとは、ソフトウェアの性質に固有な困難のことであり、
 偶有的な難しさとは、目下の生産にはつきまとうが本来備わっているものではない
 困難さのことである。≫

 
 本質的な仕事・・概念構造体の仕様作成とデザインおよびテスト

 偶有的な仕事・・上記を表現する仕事やその表現に忠実か否かをテストする仕事


 本質的な難しさ・・

 複雑性・・複雑性は、ソフトウェアの大きさにしたがって、非線形に増大する。

 同調性・・多くの複雑性は、他のインターフェースにしたがうことにより発生する。

 可変性・・ソフトウェア製品は、アプリケーションの利用者、慣習および機械機器
  (媒体)といった文化的マトリックスにすっかりはめ込まれ、そしてそれらは
  絶えず変化し続ける。その変化は、ソフトウェア製品に容赦なく変更を強制する。

 不可視性・・≪ソフトウェアの構造を制限したり単純化したりすることは進歩したにも
 かかわらず、その構造は本質的に視覚化できないままになっている。
 その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、
 複数の人間の間でのコミュニケーションもひどく妨害する。≫


 20年前の時点での「銀の弾」の候補・・

 偶有的問題・・高水準言語、タイムシェアリング、統合プログラミング開発環境

 本質的問題・・

 モジュール化、
 抽象データ型
 階層的構造化
 オブジェクト指向・・モジュール性、カプセル化、継承により、上記を解決策を包含


 人工知能?
 エクスパートシステム△
 自動プログラミング○
 ビジュアルプログラミング○

 プログラム検証・・≪完全なプログラム検証を行っても、プログラムが仕様書と合っている
 ことを立証するだけだ。≫
 本質的な課題は、仕様書のデバッグ・・要件の正しさの立証にある。


 コンセプトの本質への対策・・

≪ソフトウェア製作者が顧客のために行う最も重要な仕事は、
 製品の要件を繰り返し抽出し、洗練していくことだ。
 実際のところ、顧客自身何を希望しているのか分かっていないものだ。≫

≪繰り返し対話しながら要件を指定していく方法の一部として、
 システムのプロトタイピングを迅速に行うアプローチのしかたとツールを
 開発することである。≫


≪ハーラン・ミルズは、どのソフトウェアシステムも漸増的(インクリメンタル)開発に
 よって育成されるべきだと提案した。≫


≪偉大なデザインは、偉大なデザイナーから生まれる。
 ソフトウェア構築は創造的プロセスだ。≫



第17章 「銀の弾などない」再発射

≪作業の偶有的または表現的部分は今や全体の約半分以下に減っている・・


 概念構造体を作る上の本質的な困難さには、
 複雑性・同調性・可変性・不可視性がある。

 複雑さの回避には、階層化による。一度に全階層と勝負しない。

 
 本質的問題を攻略する最良の方法は、

 「全然構築しないこと」である。

 パッケージソフト、プログラムやモジュールの再利用、
 レガシーシステムの再利用等




【送料無料】人月の神話新組新装版

人月の神話 フレデリック・P・ブルックス Jr.

訳 滝沢徹、牧野祐子、富澤昇

ピアソン桐原

2010年刊


 フレデリック・ブルックスさんの35年ぶりの新刊「デザインのためのデザイン」とあわせて、
 昨年12月新装版として出された「人月の神話」・・

 最大の関心事は、35年前といまとで何が大きく変わったか?


 一番異なるのは、システム構築に必要となる環境・・

 パソコン、メール、グループウェア、インターネット、ウェブ、
 パッケージソフト、リレーショナル・データベース、オブジェクト指向言語
 アプリケーションフレームワーク、仮想化技術、
 BIツール、ETLツール・・
 静かできれいなオフィス、オフショア・ニアショア利用などが、
 35年前にはなく、またあっても実プロジェクトへの適用はこれからの段階でした。


 不思議なことに、本書を再読して、全然古く感じられないのには、
 大きく2つの理由があります。

 一つ目は、議論の中心が、「人と組織に関する課題」であり、
 プロジェクト活動をする以上、いまでも存在する課題であるため。

 二つ目は、システム構築にまつわる課題には、
 大きく「本質」的な課題と、「偶有」的な課題(副次的な課題)があるが、
 この35年のIT技術や様々なプロダクトが解消したことの多くは、
 「偶有」的な課題に対してあり、
 ソフトウェアの持つ「本質」的な課題は依然残っていること。
 「偶有」的な課題が減少した分、「本質」的な課題が半分以上を占めるに至っている。 大規模化、複雑化する中で、難度は確実に上がっている。

 20年前時点もわかっていたことですが、
 インプリメンテーションに対する自動生成、プロダクトによるサポートは確かに充実
 してきています。でも、35年前の時点でも、インプリメンテーションにかかる工期は、
 プロジェクト全体工期の6分の1・・いまだと10分の1程度。
 残りの9割の生産性や品質を、格段に向上させる方法が課題になります。
 また、不良の根本原因の大半は、インプリメンテーションではなく、
 設計やそれ以前の要件定義にあります。
 様々なモデリング技法はありますが、表記法のレベルではなく、表記する内容そのもの
 に対する理解・把握は、エンジニアのスキルや知見に大きく依存します。


 35年ぶりの「デザインのためのデザイン」は、
 ずばり、この要件定義工程に焦点を当てていました。



 
第18章『人月の神話』の命題――真か偽か

1.1.プログラミングシステム製品は、個人使用目的の別個に書かれたコンポーネントプログラム
 の約9倍の労力を必要とする。
 製品化には3倍の労力が必要であり、各コンポーネントプログラムをデザイン・統合化

 テストして1つのまとまったシステムにすることに3倍の労力がかかる。
 そしてそのコストは本質的に別々のものである。



2.2.おいしい料理には時間がかかるのと同じように、結果が惨憺たるものにならない 
 ようにするためには、急かすことのできない仕事もある。


2.6.(略)人月は、間違った危険な神話である。
 というのも、人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。


2.11.ブルックスの法則-遅れているソフトウェアプロジェクトへの要員追加は、
 さらにプロジェクトを遅らせるだけである。


3.3.少数精鋭チームが最高である-人数はできるだけ少ない方がよい。


3.5.少数精鋭チームで非常に大きなシステムに取り組むと、
 開発が遅れすぎる。


4.1.「コンセプトの完全性こそ、システムデザインにおいて最も重要な考慮点だ」。

4.3.コンセプトの完全性を得るには、デザインが1人ないしは互いに意見が
 同じ少人数の頭脳グループで考え出されなければならない。


7.16.組織の目的は、必要となるコミュニケーションと調整作業の量を減らす
 ことである。

7.17.従来の木構造組織は、「二君に仕えず」という権限構造の原理を反映
 している。
7.18.組織におけるコミュニケーションの構造は、ネットワーク構造であって
 木構造ではない。(略)


9.6.大人数のチームの場合、その中でさらに分けたサブグループは、そのグループの
 目標だけを満たすために部分的に最適な状態を作り出す傾向があり、
 利用者に全体として与える影響を考えない。
 こういった取り組む姿勢と(コミュニケーションの)断絶こそが、大規模プロジェクト
 にとっての主要な障害の要因である。


10.9.プロジェクトマネージャーの基本的仕事は、全員を同じ方向へ進ませることだ。

10.10.プロジェクトマネージャーの主要な日課は、意思決定ではなくて
 コミュニケーションを図ることである。
 そして、文書は計画と決定事項をチーム全体に伝達する。


11.3.たいていのプロジェクトでは、最初に完成したシステムはほとんど使い物に
 ならない。遅過ぎたり、大き過ぎたり、使いにくかったりする。
 ひどいものになるとこの3つすべてが当てはまっていることもある。

11.6.だから、1つは捨て石にするつもりでいることである。
 どうしたってそうせざるを得ないのだから。

11.8.実際の利用者のニーズとニーズに対する認識の両方が、
 プログラムが作成されテストされ使用される中で変化していく。


12.17.アプリケーションの中には、対話型システムがバッチシステムに取って代わる
 ことが決していないものもあるだろう。【今もそうである。】

12.18.デバッグがシステムプログラミングの困難で時間のかかる部分であり、
 長いターンアラウンドでデバッグの悩みの種である。
 ⇒ 単体テストでのターンアラウンドは、一人一台のPCで解消済。
   でも、結合テスト以降は依然そのまま。


13.12.システムデバッグは困難であるがゆえに、しっかりと系統立てて計画された
 アプローチが必要である。

13.13.各部分がきちんと動くようになってから初めてシステムデバッグに着手する
 べきである。(略)


14.1.「プロジェクトはどうして1年も遅れるようになるのか?

 ・・一度に1日ずつ」。

14.2.1日ごとの遅延は、災難による遅れに比べ、気づくことも予防することも、
 さらにはその分を取り戻すこともより困難になる。


E.1.ソフトウェアシステムは、人間の作り出したもののうちで、おそらく
 (異なる部品の種類の数という点で)最も分かりにくく複雑なものだろう。


 
 蛇足・・

 1996年に邦訳が出た時も手に取りましたが、
 15年前は、パソコンが一人一台にはなったばかりの頃で、
 メールやグループウェアに対する抵抗感はまだまだ残っており、
 インターネットは個人利用のレベル。
 大規模プロジェクトの開発においては、毎日、100ページ以上の配布物や
 回覧物が出回る状況でしたが、いまは配布や回覧用のものはほぼ全廃。
 残るは、レビュー用に確認するための成果物ですが、これは何百枚あっても
 大量印刷⇒大量コピー⇒レビュー⇒シュレッダーにより大量廃棄は、
 まだまだ無くせていません。
 レビュー済みの成果物は、電子媒体納品ですが、設計書やエビデンスの目視確認
 が課題。・・iPadを利用して、紙の配布を止めた部署もありますが、
 プロジェクトへの適用はこれからです。


<目次>
第1章タールの沼
第2章人月の神話
第3章外科手術チーム
第4章貴族政治、民主政治、そしてシステムデザイン
第5章セカンドシステム症候群
第6章命令を伝える
第7章バベルの塔は、なぜ失敗に終わったか?
第8章予告宣言する
第9章5ポンド袋に詰め込んだ10ポンド
第10章文書の前提
第11章1つは捨石にするつもりで
第12章切れ味のいい道具
第13章全体と部分
第14章破局を生み出すこと
第15章もう1つの顔
第16章銀の弾などない――ソフトウェアエンジニアリングの本質と偶有的事項
第17章「銀の弾などない」再発射
第18章『人月の神話』の命題――真か偽か
第19章『人月の神話』から20年を経て
エピローグ50年間の不思議、興奮、それに喜び

 今年5月に「高度情報通信ネットワーク社会推進戦略本部」より出された
 「新たな情報通信技術戦略」ですが、

 新たな情報通信技術戦略より


 そこでのテーマは、国民ID導入による電子行政を確立し、
 この電子行政サービスにより、地域レベルでの医療、介護、災害・犯罪・事故対策、教育、テレワーク等々を実現することを目指しています。

 
 技術面の取り組み・・

「3.新市場の創出と国際展開
(2) 我が国が強みを持つ情報通信技術関連の研究開発等の推進
【重点施策】
○ 我が国が強みを持つ情報通信技術関連の研究開発を重点的に推進し、早期の市場投入を目指す。

【具体的取組】
今後、世界的な成長が期待され、我が国が強みを有する技術分野
(新世代・光ネットワーク、
 次世代ワイヤレス、
 クラウドコンピューティング、
 次世代コンピュータ、
 スマートグリッド、
 ロボット、
 次世代半導体・ディスプレイ等の革新的デバイス、
 組込みシステム、
 三次元映像、
 音声翻訳、
 ソフトウェアエンジニアリング等)
を特定して集中的に研究開発を行うとともに、国際的なパートナーシップの下で国際標準(デジュール及びデファクト)の獲得や知的財産の活用につながる知的財産マネジメントを推進する。さらに、多様なユーザーニーズに応える革新的なコンピューティング環境の開発・整備を推進するとともに、情報通信技術に係る最先端の研究を行い、海外から有能な教員等を呼び込める高等教育機関を強化する。【内閣官房、総務省、文部科学省、経済産業省等】」

 として、6月には工程表も出されています。

PAGETOP