プロジェクトチーム構成編

第８章　Dropによる組織改革

８．１　Dropによる組織改革とは

　本章では、Dropが目指すチーム構成を実現するための組織改革について述べる。この組織改革は、ソフトウェア企業におけるビジネス・プロセス・リエンジニアリング(BPR)の一環として位置づけるものであり、中期・長期的な計画で、ソフトウェア開発ビジネスにおける技術部門の根幹となるチーム自体をリエンジニアリングするためのものである。
　Drop方法論にこのような組織改革が必要な理由は、Dropの開発プロセスにおいては、ADG、ODGという特異なチームに構成することを唱えているのであるが、一般的なソフトウェア企業では、このような組織（または類似する）形態をとっていることは稀である。よって、Dropを採用しようとする誰かが、企業の組織を変えていかなければならない。　このような戦略は、技術者一人で達成できるものではなく、ビジネス戦略としてのバックアップが必要とされるものだ。ここに、Drop方法論の範囲として「技術部門に限定された組織改革」を組み込む必然性がある。その中で組織改革のための戦略を例として示すことにより、Dropの目指すチーム構成がとれるよう道案内しようとしているのである。
　Dropを効果的に適用するためには、Dropに定められたリエンジニアリングチームが、技術者個人と組織全体の意識を変革し、必要であれば組織改革を実施することが重要である。Dropはそのためのフレームワークを提供している。このフレームワークをベースにして、まずは技術者個人から初め、徐々に組織へと改革を進めていくことになる。このように、段階を踏みながら組織改革を進めていくことで、オブジェクト指向技術という安定したテクノロジを支えに、次世代のソフトウェア開発をターゲットとする、優れた技術者とチームが育成され、企業にとって貴重な財産を生み出すことができる。

sorry this is image

図8-1 企業のビジネス戦略とDropによる組織戦略の関係

８．２　組織改革を開始する必要条件

開始の条件

　Dropによる組織改革を開始するアプローチとしては、「人材がある程度育ってから組織編成をおこなう方法」や「組織編成をおこなうことで人材育成を促進させる方法」（またはそれらをミックスさせた方法）がある。前者はボトムアップ的なアプローチで、個人が中心となって少しずつ実績を積み重ね、組織化に結びつけていく方法である。後者はトップダウン的なアプローチで、枠組みを作った後に人材を選定したり育成したりしていく。両者のどちらが適しているかは会社組織の体質によって異なるものである。
　しかしながら、このような組織改革を計画し、実施するためには、最低限以下のような人材が必要とされる。

Dropリエンジニアリング技術者
　Dropの考えをよく理解し、その効果を発揮できるよう、自ら努力と工夫を怠ることのない技術者で、自分のことだけでなく部下を導くことができる。
Dropリエンジニアリング管理者
　Dropリエンジニアリング技術者の技術力を高く評価し、Dropによる組織改革に対する長期的なビジョンを企業の経営者に提案することができる。

　このような人材を見つけること、あるいは、読者自身がその人材になるべく立ち上がることが、Drop組織改革の事始めとなる。後は、読者と共に学ぼうという相棒を何人か見つけて「Dropリエンジニアリングチーム」と名前を付ければよい。

トップダウンアプローチ
　もし読者が、「Dropリエンジニアリング管理者」を目指す、あるいは該当するならば、相棒のリエンジニアリング技術者たちをバックアップし、組織化する準備に入りやすいだろう。この場合、組織編成が容易なトップダウン・アプローチとなる。
ボトムアップアプローチ
　もし読者が「Dropリエンジニアリング技術者」を目指す、あるいは該当するならば、そして運良く、相棒の「Dropリエンジニアリング管理者」が見つれば、上記と同じトップダウン・アプローチとなる。しかしながら、通常のケースを考えると、「Dropリエンジニアリング管理者」を相棒にすることから始めなければならないだろう。それには、技術者としての信頼を勝ち取り、技術的にも一流を目指して鍛錬しながら、相棒として白羽の矢を立てた管理者にDropの考えを伝えていかなければならない。この方法はボトムアップアプローチとなる。

　このように、どちらのアプローチでも、Drop組織改革を前進させていくのである。

開始時期

　Dropの組織改革の開始時期は、上記のリエンジニアリングチームが結成され、実際にターゲットとする開発チームを定めるための準備が整う頃である。
　このような時期がくると、リエンジニアリングチームは、次節の「ビジョン策定」を基に組織改革のための計画を立て、実行していくことになる。

リエンジニアリングチーム役割と責務の遂行

　リエンジニアリングチームの役割は、Drop組織化改革の番人のようなものである。それは、Drop組織改革のターゲットとなる１つ以上のチームの状況を客観的に分析しながら、彼らチームの発展が正しい方向に進んでいるかを見守り、改善策を練るという役割である。彼らリエンジニアリングチームの具体的な責務は「８．３　組織改革のための戦略」に基づいたアクティビティを実施することにある。それは、図8-2に示すように改革のターゲットとなるチームの枠組みを企業戦略の視野で分析し、発展させるよう設計する。つまり、チームを外側から支援することにある。　一方、改革の対象となるターゲットチームは、リエンジニアリングチームが築いたチームの枠組みを、内面から充実させプロの専門チームとして発展させていく責務がある。
　実際には、リエンジニアリングチームは、Dropによりの改革されるターゲットチームに含まれることもあるだろう。しかしそのような場合でも、リエンジニアリングチームとして、常に客観的な立場で「８．３　組織改革のための戦略」に基づいたアクティビティを実施することができなければならない。

sorry this is image

図8-2 リエンジニアリングチームと組織改革のターゲットチーム

８．３　組織改革のための戦略

　リエンジニアリングチームは、組織改革に向けて、図8-3に示すアクティビティを実施しなければならない。このアクティビティを、約１年周期で繰り返しながら、企業内の技術系組織を、Dropの目指すADG、ODG構成にリエンジニアリングする。

sorry this is image

図8-2 Drop組織改革アクティビティ

ビジョン策定

　組織改革は、明確なビジョンを持って企業経営者を説得する力が必要とされる。そのためには、リエンジニアリングチームが、Drop方法論を使ってどんな目的で、どのようにチームを育てていくのかというビジョンを提案する必要がある。リエンジニアリングチームの重大な任務のひとつに企業戦略の一貫としてDrop組織改革を行えるよう企業経営陣を説得することである。
　Dropに書かれている組織改革のビジョンは、そのような提案のベースとなるものである。つまり、ビジョン策定とは、Dropによる組織改革の柱となるビジョンを明確な形とすることをいい、実際には以下の内容をいう。

現状分析
　企業におけるオブジェクト指向開発の現状と開発チームの現状を調査する。
- ソフトウェア環境がどの程度オブジェクト指向化されているか。
- 顧客からどの程度オブジェクト指向開発してほしいという要望があるか。
- 経営陣がどの程度オブジェクト指向に対する正しい認識をもっているか。
- 開発担当者はなぜオブジェクト指向を使うのか。
- 開発担当者はオブジェクト指向開発の効果を把握できているか。
- どのような問題領域にオブジェクト指向技術を使っているか。
- 組織編成はバラバラなのか、何かオブジェクト指向開発としてコミュニケーションがあるのか。
- チームの実力は向上しているのか。オブジェクト指向に対する意識は変化があったか。
- 既にDropを採用している場合、その効果と問題点を整理する。
戦略分析
　現状分析をふまえた上で、Dropの組織改革を採用した５年後のあるべき姿を形として表すことである。これがすなわち企業経営陣に示すビジョンを定めることであり、それは、提案書の中で５ヶ年目標として文章化される。しかし、それだけではなく、リエンジニアリングチームの自信と熱意を、企業経営者に伝えることが重要である。リエンジニアリングチームは、以下のような説明をいつでも企業経営者に語ることができなければならない。
- ５年後のソフトウェア企業のありかた。下記ような５年後の状況を想定した、将来のビジネス形態を考えて今何をすべきか決定すべきだ。
  - マルチプラットフォーム化が急速に進んでいる。
  - オブジェクト指向開発が基礎技術として浸透し、すべてのテクノロジの土台となりつつある。
  - コンポーネント技術が急速に進歩している。
  - ソフトウェア開発者は今以上に分析能力や問題解決能力が必要とされる。
  - ソフトウェア開発者は今以上にソフトウェアデザイン能力が必要とされる。 etc..
- 上記ビジネス形態に必要とされる技術者は、明確なソフトウェアに対するビジョンを社内外に示せる人材であり、オブジェクト指向技術をベースとした分析・設計能力と問題解決能力が必要とされる。
- 上記人材を何人育てるかが、５年後にソフトウェア・ビジネスにおいて優位に立てるかどうかの鍵となる。また、この人材をチームとして形成できるかが、次なるステップとなる。
戦略設計
　戦略分析をふまえた上で、約１年単位で実施すべき組織戦略を示す。これはマネージャーに示す短期的なビジョンであり、以下のような内容となる。
- Dropのチーム構成を計画する
  以下のようにチームの発展段階に合わせた次なる短期目標をターゲットとなるチームのリーダと話し合って定める。
  1. オブジェクト指向開発をとりあえず経験させる教育期間
  2. 開発チームのメンバ一人一人の意識改革段階
  3. 開発チームの内でADG、ODGを分類する段階
  4. ADGとODGを別チームにする段階
- 開発するソフトウェア
  　短期的なチーム計画の中で実施するプロジェクトの内容を明確にする。
  - プロトタイプ的な開発なのか？それとも、本開発での採用なのか？
  - 開発計画
  - 評価の方法
- 期待する効果、目標(チーム目標、個人目標)
  　チーム育成計画としての目標を定める。たとえば以下のような目標である。
  - 分析・設計ができる人材を育てる
  - オブジェクト指向開発の意義をチームメンバ全員が説明できるようになる
  - 主要人員の個人目標
  - チーム目標
- 教育計画
  チームを育てるために有効となる教育計画を定める。できれば個人単位にて。個人申告させることも有効。
  - 社外研修
  - コンサルテイングによる研修
  - 自己目標の提示と実施
  - 個人の研究目標など

実施・検証

　戦略設計で計画された開発スケジュールなどに基づいてプロジェクトを実施する。プロジェクト実施後は、計画の中で定めた目標を、チームと個人を照らし合わせながら評価・検証し、それを基に社内発表するためのワークショップを開催する。このような評価・検証は、年１度だけ開催されるというわけではない、チームの中では、頻繁に目標の達成度や進み具合を確認し合うミーテイングが開かれる。ワークショップは、その成果をまとめるために企業内で行われるイベントである。たとえば「技術報告会」としてプロジェクトの課題と成果、および問題点などを企業経営者や他部門に報告する。

sorry this is image

図8-4 Drop組織改革プロセス

８．４　犯しやすい過ち

　リエンジニアリングチームは、企業経営者に、Dropによる組織改革のビジョンとその効果を説得できなければならない。しかしながら、オブジェクト指向で俗にいわれる表面にでる効果だけを唱えていると、将来、思わぬ落とし穴が待っていることとなろう。ここでは、リエンジニアリングチームがビジョン策定において、そのような落とし穴でコケないように、「犯しやすい過ち」を例として示しておこう。

オブジェクト指向技術による生産性の向上を唱い文句にする
　オブジェクト指向技術は再利用性と保守性を向上させることで、ソフトウェア開発における生産性を高めることができる。しかし、だからといってこの生産性をプロジェクトの評価・検証としているならば、その戦略は失敗に終わる可能性が高い。なぜなら、「第５章　プロジェクト構成の問題点」でも述べたように、ソフトウェアに対する要求が非常に複雑化、多様化し、さらに日々変化している現在の状況において、過去と同じ生産性のメトリクス(評価の基となる基準値)を使って評価しようとしても困難であるからだ。
　また、果たして生産性を正しく評価できる確実なメトリクスを持っているかということも問題となる。しかし、何らかの生産性を唱える必要があるならば、下記のように考えるべきである。
- オブジェクト技術を習得し初めて１，２年はテクノロジーをうまく使えないため、従来より生産性が低下するだろう。
- ソフトウェアに対する要求が非常に複雑化、多様化している現在、オブジェクト指向技術を使っていけば、生産性を現状より落とさずコストを均一化できるだろう。
会社経営者に対して、組織改革の成果を開発工数などの数値で表そうとする
　Dropの組織戦略は、次世代ソフトウェア開発に向けて基盤となるチームを育てるというビジョンを示すものである。このようなビジョンを、従来のソフトウェア開発に使われる工数計算などを使った数値で表現することは得策ではない。
　しかしながら、以下のような数値表現を５年後の目標として使うことは、ビジョンを形にできる有効な手段といえよう。
- 全社の開発チームの50%にオブジェクト指向技術を採用する。
- 全社員の10%をオブジェクト指向によるコンサルタントができる人材に育てる。
- 全社員の10%をオブジェクト指向による設計と実装ができるリーダ的な人材に育てる。
急ぎすぎる組織改革
　Dropの目指すADGとODGによるチーム構成は、チームメンバの意識改革後に初めて実現できるものである。まだ、オブジェクト指向技術が未熟な段階やDropの思想をよく理解していない段階で、無理してODGチームを作ってしまうとよい成果はあげられないだろう。まずは、１つのチームの中の役割分担として、ADGとODGの構成を考えるようにしなければならない。
急ぎすぎる開発
　開発チームのメンバが育っていない段階で、非常に大きなソフトウェア開発をおこなうべきではない。できるだけリスクの少ない開発を対象にし、開発期間をあらかじめ長めに設定することによって、開発後の検証・評価に時間を使えるようににすべきである。
計画性のない組織変更、クローズされた情報
　プロジェクトをこなすことに精一杯となり、プロジェクトに合わせて頻繁に組織変更がなされてしまった結果、Dropによる組織改革の成果をあげられずに終わってしまうようなこともあるだろう。このような場合、リエンジニアリングチームは、早急に「頻繁な組織変更による影響」を企業経営陣に報告するための会議を開催し、計画変更・延長などの対策を企業経営陣と共に練らなければならない。もしそれを怠ってしまうと、Dropによる組織改革は、誰も知らないうちに有耶無耶に終わってしまうことになろう。リエンジニアリングチームは、できるだけDropの組織改革の状況をオープンにするよう心がけなければならない。その方法として、社内ネットワークを使って組織改革の進行状況を常に社員に伝えることは非常に有効な手段となるだろう。