2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2010年1月 | トップページ | 2010年3月 »

2010年2月

2010年2月26日 (金)

【共通フレーム2007第2版】「(b)要件定義プロセス」の解説が厚くなった

P248「(b)要件定義プロセス」において解説が大きく書き加えられている。
後半が多少冗長過ぎる気もするし、共通フレームでは旧版程度でも良いとは思われるが、この辺りに力を入れることは良いことであると思われる。

P249「(3)エンジニアリングの視点から」においても同様に記述が厚くなっている。

P251「(b)保守プロセス」も記述が厚くなっている。
しかし、個人的には、こちらはもう少し厚くても良かったように思える。完全に個人的な見解であるが。

2010年2月24日 (水)

【共通フレーム2007第2版】「契約の変更管理プロセス」の細かい変更

P244「1.1 主ライフサイクルプロセス(1)契約と合意の視点から」の「図4-2 契約の変更管理プロセス」についても微妙な変更がなされている。

第2版の「プロセス開始の準備」は、旧版では「開始」であった。
記述の詳細化というより、意味も少し変わっている。
旧版では「開始」そのものであったが、第2版では「開始の準備」であり、開始はされていない。

第2版の「影響の調査分析」は、旧版では「影響の分析」であった。
こちらは、意味的にはそれほど変わらないと思われる。

難しいのは次の2つ。
第2版の「協議の実施と合意の形成(経営層の関与)」は、旧版では「協議の実施」であった。
そしてその後に続く、第2版の「契約の変更(関係者への通知)」は、旧版では「合意及び関係者の通知(経営層の関与)」であった。

「合意」と「経営層の関与」が1つ前に移っている。

【第2版】「協議の実施と合意の形成(経営層の関与)」=>「契約の変更(関係者への通知)」
【旧版】 「協議の実施」=>「合意及び関係者の通知(経営層の関与)」

この変更、大きな意味を持つようにも見えるし、大した意味がないようにも見える。
「合意」と「経営層の関与」が早い段階で行われるように定めたと考えれば前者であるが・・・。
単に、「協議の実施」=>「合意の形成(経営層の関与)」=>「契約の変更(関係者への通知)」と3段階のプロセスを2つで表現しようとしているだけで、実質のシークエンスは変わらないと考えれば後者となろう。

2010年2月22日 (月)

【ソフトウェア開発の生産性】厄介なパラメータ・・・要員のやる気なるもの

生産性。頑張る時もあればサボるときもある人の特性を含む活動を、定量的に把握するためにはどのような統計的もしくは算術的処理をすべきか。

考慮すべきパラメータはざっとみても沢山ある。やる気、残業時間、個人差、プロジェクトの状況や時期、要件変更の頻度や時期…キリがないが、どれも生産性に大きな影響を及ぼすように思える。

そして一番厄介なのはやる気だと考える。
プロジェクト初期は余裕持って臨んで、末期に徹夜してなんとか間に合ったと言っている組織に生産性管理の導入は早い(とはいえこれは現在の大多数の組織がそうかもしれない。というか人間の性として永久になくならないかもしれない)。
まずは定性的管理を。PMはこのあたりを平準化してメンバーを導くことがプロジェクト管理と定量的管理の共存点かもしれない。

生産性管理の導入が早いというのはプロジェクト管理の視点での話であり、財務視点の管理は当然必要。

工業製品の製造は組立ラインの速度といったペースメーカーがあるので人の作業が関与しても生産性を把握しやすい。如何に人の作業を速くするかで速度が決まる世界。
究極は全自動化。一方ソフトウェア開発にはこのようなペースメーカーはない。計画はあるが流れ作業ではないので緻密な管理はできない。

2010年2月19日 (金)

【共通フレーム2007第2版】「契約準備・締結・更新」から「締結」が落ちた理由

P243「1.1 主ライフサイクルプロセス(1)契約と合意の視点から」における、「図4-1 取得プロセスと供給プロセス」について微妙な変更がなされている。

第2版の「取得プロセス」における「契約準備及び更新」は、旧版では「契約準備・締結・更新」であった。
「締結」が落ちた。

供給プロセスに「契約締結」があるからなのか。

名称上の問題だけなのだろうか・・・、それとも意味的にも契約を取得プロセスから外すことに意味があるのであろうか。
よく分からない。

2010年2月17日 (水)

【共通フレーム2007第2版】「共通特定業務」を含めた理由

P234「4.7 共通特定業務のシステム監査」において、ガイダンスとして、

「アクティビティ名称の一部に『共通特定業務』を含めた理由は、主ライフサイクルプロセスに対して、支援ライフサイクルプロセスと組織に関するライフサイクルプロセスとは『共通な位置づけにある』という意味合いである」

と書かれている。

これは、旧版では、

「システム監査プロセスのアクティビティ名称の中で、『共通特定業務』としているのは、主ライフサイクルプロセスに対する『共通プロセス』では、支援ライフサイクルプロセスや、組織に関するライフサイクルプロセス等とは『共通』の意味あいで、誤解を生じるので、敢えて、『共通特定業務』としている」

となっていた。

どちらも分かりづらい表現であると思うが、第2版の法が洗練されてはいると思える。
言おうとしていることは、同じ(であろう)。

しかし個人的な感想であるが、意図がいまひとつ分からない。

2010年2月15日 (月)

【プロマネのメトリクスへの寄与】SW開発におけるプロジェクトマネジメントとメトリクス管理

プロマネは計画を立てて管理するのであるが、実際のところソフトウェア開発において失敗プロジェクトがあとをたたない。ここにメトリクス管理を持ち込めば成功するか。それともメトリクス管理を既にしていてダメなのか。メトリクス管理ができない分野があって、かつそこが成否のキーなのか。おそらく全部だろう。

そもそも、ソフトウェアのメトリクス管理とプロジェクトマネジメントの考え方は両立するのだろうか。

成功プロジェクトと失敗プロジェクトの開発指標の推移をモデル化して、新規プロジェクトを成功するように導こうとかいう管理を聞くが、これは、プロジェクトマネジャーの能力を鑑みない方法だと思われる。

一方で、途中からPM交代したから成功したみたいな話もソフトウェア開発の世界ではいくらでもある。

マネジメント能力に開発の成否が左右されるならば、メトリクス管理など意味がなくなるはず。なぜならメトリクス管理には、実行者・推進者によるばらつきはないものと仮定して進められているはずだから。

逆に定型的傾向が成功案件・失敗案件にあるのであれば、それをコントロールすればPMによらずプロジェクトの成功に近づけるはず。
まさかプロジェクトマネジャーの能力を数値化して・・・なんてことまで考えることはいくらなんでもおかしいと感じるであろう。

折衷案としては、優秀なPMが、我流ではなく成功パターンを元にメトリクス管理をしていくことが重要・・・とかいうのが出てきそうだが、概念上の話に過ぎないような気がする。
優秀なPMは凡百な成功事例の積み重ねとは違うところで管理しているかもしれないから(天才打者に凡人コーチが一般的に正しいとされる打法を伝授するような感じ)。

ソフトウェアのメトリクス管理とプロジェクトマネジメント。それぞれ何ができて何ができないのか整理が必要。

2010年2月12日 (金)

【共通フレーム2007第2版】「ドメイン」と「領域」

「3.6.2 ドメインの識別」は旧版では「3.6.2 ドメインの特定」であった。

「識別」でも「特定」でも意味の上ではどちらでも良いと思われる。
ここで注意すべきは、「ドメイン」という語が変わらなかったということだ。
旧版の「領域」は第2版では「ドメイン」と書き換わっているので、逆に旧版で「ドメイン」と呼んでいたものは何に変わるのだろうかと思ってしまうかもしれない。

しかし、旧版では、「領域」と「ドメイン」とが同じ意味で異なる語で書かれていただけなのである。旧版には「ドメイン(領域)」という表現もある。

色々なパターンで書かれていたものが、第2版で統一化されたものなので、旧版の「ドメイン」という表現に変更がなかったのである。

2010年2月10日 (水)

【共通フレーム2007第2版】、「適切な管理者」の「適切」は誰が決めるのか

「3.6.2 ドメインの識別」において、「適切な管理者」という表現がある。

これはどういう人のことだろう。
「適切」には主観が入るので、人により解釈が異なるのではないだろうか。

どこかに定義があるのを見落としているのかもしれないが・・・。
ひょっとしたら・・・。

2010年2月 8日 (月)

【国際標準の取扱い】用語の共通化は現実問題として可能か

標準化と一口で言っても色々ある。
組織内標準・業界標準・国内標準・国際標準・・・等々。

さて、標準には「用語の共通化」という役割もある。
役割と言うかそれが無いと標準と名がついてもそれに従った活動がばらばらになる。

で、日本語と英語の問題。

さて、国際標準と呼ばれるものは大抵英語である。
標準において、どんなに厳密に英語で定義されても、それを翻訳された日本語で書かれた瞬間に誤差を呼ぶ可能性は避けられない。

これは誤訳と言うことではない。訳しようが無い違いとでも言えようか。
言語には文化的背景があるからだと思う。

このような差は、大したことが無いのかそれとも重大なのだろうか。

例えば、「Control」「Management」これはどちらも「管理」と訳されることが多い。
しかし英語では違う。

そのため「管理」とは訳さず、「コントロール」「マネジメント」とカタカナで訳されることも多い。

・・・で、これで解決するか。
どんなに定義されようとも、日本人は「Control」も「Management」も「コントロール」も「マネジメント」も全て頭の中の深いところでは「管理」と変換されて同じものと理解されてしまうことは無いだろうか。

国際標準・・・これを翻訳版で理解実践することは、実は元々の標準に従ったものではないと言う可能性を秘めていると考える。

「要件」「要求」と「requirement」も(こちらは日本語の方が複数となる形態だが)同じだと思う。

さて、このような問題は、国際標準においてだけ生ずる問題ではないと考える。
冒頭で、標準化と一口で言っても色々あると書いたが、組織内標準・業界標準・国内標準・国際標準等々の切り口でも同様の「文化ギャップ」による解釈違いがあるのではないかと考える。

2010年2月 5日 (金)

【共通フレーム2007第2版】再利用関連の役割

P212からの「3.6 再利用施策管理プロセス」において、様々な役割が出てくる(旧版においても)。

・再利用後援者(スポンサ)
・再利用施策参画者
・再利用施策管理者
・再利用運営機関
・再利用責任者
・再利用専門家
・再利用施策支援機関

このうち、再利用施策管理者は比較的内容が記述されているが、他は役割やそれぞれの関係がはっきり定義されていない。

自明ということか。

2010年2月 2日 (火)

【共通フレーム2007第2版】「標準は・・・標準として決めてある必要はない」の解消

P203「ガイダンス 3.3.3.3」において旧版では「組織のプロセス標準は、修正し、定義されたプロセスを指し、組織で標準として決めてある必要はない」と書かれていた。

標準として決めてない標準?
良くわからない文章。

これが第2版では修正されている。
「組織のプロセス標準は、修正し、定義されたプロセスを指し、組織でプロセス標準を決定していることが望ましい」

矛盾的記述は解消されたように見えるが、これも分かりづらい。

結局、組織のプロセス標準はなくても良いといっているのだろうか。
また、定義されただけで修正されていないプロセスは「組織のプロセス標準」ではないのだろうか。

望ましいのは「プロセス標準を決定していること」なのか「組織で決定していること」なのか。

読み込みが足りないだけなのだろうか・・・。

« 2010年1月 | トップページ | 2010年3月 »