組込み開発現場のプロジェクトマネジメント＆プロセス改善

『組込み開発現場のプロジェクトマネジメント＆プロセス改善』を読んだ。この本は以下の6つのパート＆著者から構成されている。

■Part 1 新人管理者のためのマネジメントの基礎知識
著者：井上 樹(いのうえ たつき)
(株)豆蔵にて組込ソフトウエアを中心にオブジェクト指向/UMLの導入、プロセス改善等に関する教育、コンサルティングを担当。最近はモデルを活用したシステムエンジニアリングに注目中。

■Part 2 現場が共鳴する開発環境の姿
著者：杉浦 英樹(すぎうら ひでき)
1986年、富士ゼロックス(株)に入社。以来、複写機の組込みソフトウェア開発を担当。複数のドメインを複数のパラダイムで開発。開発現場の問題のほとんどが、コミュニケーションに起因し、真の管理の重要性を痛感。SESSAMEメンバー。

■Part 3 実践的プロジェクト計画の立て方
著者：竹山 寛(たけやま ひろし)
ビジネスモデル構築、ソフトウェア開発プロセス、プロジェクト推進支援、品質管理、プロジェクト管理、開発工程管理、セミナーなどITコンサルタントを手がける。著書に『管理者になって困らない[実践的]ソフトウェア開発工程管理』(技術評論社)がある。

■Part 4 プロセス改善のススメ
著者：玉木 裕二(たまき ゆうじ)
(株)東芝 ソフトウェア技術センター所属。入社以来十数年、社内のソフトウェア開発部門各所に、アーキテクチャ設計提案、プロセス整備やインフラ整備、コーディングやデバッグなど、いろいろな立場で関わってきた。それなりに知見も増えてきたけれど、まだまだ足らないと実感する毎日。

著者：荒見 美香子(あらみ みかこ)
(株)東芝 ソフトウェア技術センター所属。十年以上に渡り、CMM/CMMIなどのモデルを活用したプロセス改善活動に従事。社内のソフトウェア開発部門への改善コンサルに奔走しつつ、効果的な進め方を模索中。最近は、社内のプロセス資産化やインフラ整備に注力。

■Part 5 勘違いだらけのプロセス改善
著者：杉本 恭子(すぎもと きょうこ)
横河ディジタルコンピュータ(株)所属。最初の仕事はソフトウェアプログラマ。その後開発ツールベンダのテクニカルサポートやマーケティングを経て、現在はプロセス改善関連の企画営業を担当。日々、お客様の生の声やお困りごとに接し、支援部隊への橋渡しをしている。

■Part 6 プロダクトラインの歩き方
著者：今関 剛(いまぜき たけし)
(株)ビズモ コンサルティング部所属。日ごろから開発現場でオブジェクト指向やプロセス改善の指導をしているが、解決方法やツールを利用することが目的化して玉砕しているところが多いと感じる今日この頃。現在は、アーキテクチャリファクタリング、テスティング、モデリングを組み合わせ、人材や既存資産の能力をうまく引き出しながら、全体最適の視点に立った再利用型ソフトウェア開発を目指す。IEEE、SEA、SESSAME、EEBOFメンバー。

※プロフィールは掲載当時のものです。

見ていただければわかるように、それぞれのパートは技術評論社の『組込みプレス』に掲載されたプロジェクトマネジメント・プロセス改善に関係する記事（Part6 は再利用戦略の内容）であり、本書はこれらの個別の記事を集約している。

それぞれのパートのキーワードを拾ってみよう。

■Part 1 新人管理者のためのマネジメントの基礎知識

• QCD(Quality:品質、Cost:予算、Delivery:納期)
• PDS(Plan:計画→Do:実行→See:評価)　PDCAよりもわかりやすいPDSで説明しているとのこと。
• SWEBOK(Software Engineering Body Of Knowledge)
• PMBOK(Project Management Body Of Knowledge)
• CMMI(Capability Maturity Model Integration)
• モチベーション管理
• コミュニケーション管理

■Part 2 現場が共鳴する開発環境の姿

• ブルーオーシャン戦略
• 変化に取り残される開発現場
• どうしても人に依存してしまう開発現場
• 開発技術の退行
• PDCA(Plane-Do-Check-Action)の不在
• 改善/改革できない理由（非技術的要素、人的要素）
• 実践的な開発管理のヒント
• CMMIやPMBOKが目的ではない
• 現場中心の管理スタイル
• 改善するための具体的なヒント
• 開発者の気づきをどう促進するか

■Part 3 実践的プロジェクト計画の立て方

• プロジェクトマネジメントの失敗要因
• ソフトウェア開発の階層構造
• プロジェクトマネジメント作業の進め方
• アローダイアグラムによるプロジェクト計画の立て方
• アローダイアグラムの作成
• アロー代打グラムでの進捗管理

■Part 4 プロセス改善のススメ

• 混乱する現場
• スケジュールの逼迫（ひっぱく）
• 変わりやすい要求仕様
• 改造の繰り返し
• 外部リソース依存
• 不透明な進捗
• 混乱を抑えるのに有効な技術
• UML(Unified Modeling Language), MDA(Model Driven Architecture)
• リファクタリング
• CMM
• ソフトウェアプロセスとその改善活動
• ソフトウェアアーキテクチャとプロセス改善
• 改善事例（基本仕様書の標準化、単体テストの改善、構成管理の改善）
• 改善活動を推進する方のためのヒント
• プロジェクトの中に改善リーダーを見つける
• ときにはプロジェクトの開発者として作業を請け負う

■Part 5 勘違いだらけのプロセス改善

• プロセス改善とは何か
• いつから始めたらよいか
• どこから始めたらよいか
• CMM/CMMIを参考にする
• CMM/CMMIの上手な使い方
• プロセス改善の勘違いと落とし穴
• たちまち仕事が楽になる？
• たちまち工数が削減される？
• 目に見えて生産性が向上する？
• 教育と実践、どちらが先か？
• 身の丈に合ったプロセス改善
• プロセス改善は活動し続けるもの
• 外部から見てもらう
• 改善は組織全体の取り組み

■Part 6 プロダクトラインの歩き方

• どうしてプロダクトラインなのか？
• なぜ再利用が進まないのか？
• コア資産開発
• アーキテクチャ定義
• コンポーネント開発
• COTS(Commercial Off-The-Shelf ：市販ソフトウェア製品）の利用
• 既存資産の発掘
• 要求エンジニアリング
• テスト
• 構成管理
• デザインパターン
• 統合運営パターン
• 商品開発パターン
• 資産確立パターン
• コールドスタートパターン
• プロセスパターン
• プロダクトラインとCMMI
• 何をもってプロダクトラインと言えるのか？

キーワードを見てもらえばわかるようにテーマは似たようなところにあっても、それぞれの著者の組織、経験によって抑えるべきポイント、視点が異なることがわかる。

この本を購入しようとする読者は、この本をプロジェクトマネジメントやプロセス改善の教科書＝そこに書かれている通りに実施すればよいという手順書 と考えてはいけない。そうではなくて、プロジェクトマネージメントやプロセス改善の6つのプララクティス（実戦経験）から何かを学ぼうと考えるのが正しい読み方だ。

6つプラクティスもしくは体系は、似ている部分もあれば、異なる部分もある。その違いに混乱することなく、自分達の状態に一番近いものを選び、一番「その通り！」と思える部分に付箋をつけていく。

個人的には Part 4 に一番多く付箋が付いた。この本をお勧めするに当たりもっとも重要なのは、相手が人間である以上、改善の対象となる組織や組織を構成する人間、目に見えない文化や習慣を考慮して活動を進めなければ改善活動は成功しないということだ。

また、必ずしも論理的でない人間は、ロジカルにアプローチをしても予想通りの結果をもたらさない。だから、改善のサイクル(PDCA）を回し続けなければ、目的に近づかない。ソフトウェアの品質改善よりも人間や組織の改善の方がよっぽど手間と時間がかかる。

多くの著者がCMM/CMMIを取り上げているのは、それだけCMM/CMMIが優れた体系であるからだが、CMMやCMMIは自分達の身の丈にあった活動を続けていって、やっとサイクルがまわり成果が出てきたかなあと感じるようになった時点、CMM/CMMIを勉強するくらいがちょうどよいと思う。改善のサイクルが回っていない組織がいきなり CMM/CMMI を勉強し始めると空回りする可能性が高い。

何はともあれ、プロジェクトマネジメントやプロセス改善のテーマで6つの視点を比較することができるという意味でこの本は貴重な存在である。


P.S.

ときどき、「なんで自分はこのブログを続けているんだろうか」「このブログを読んでくれている読者は自分のことをどんな人物と受けとめているのだろうか」と考えることがある。一回の記事を書くのにだいたい1～2時間くらいはかかるから、たまに面倒くさいなあと思う。原稿料をもらっているわけでもないので締め切りもないので、「書き続ける」モチベーションを保ち続けるのもたいへんだ。

最初は本の読者と双方向の意見交換をするつもりだったが、結果的にはこちらかの情報発信が圧倒的に多い。（議論のもとになるネタまってます。以前、高校生からの「組込みソフトってなんですか」の質問では大いに盛り上がりました。）

でも、このブログを4年も続けていて実感しているのは、ブログに記事を書くことは明かに自分のためになっているということである。

他の人が書いた記事や、聞いた話を、ブログを通して多くの人に伝えるためには、いったんインプットされた情報を整理して読者を想定してかみ砕いて分かりやすくアウトプットしなければいけない。これはものづくりやソフトウェア開発にも役立つ。要するに、外界からセンシングした情報をインプットとして加工し特定のユーザーに受け入れられるようにアウトプットする訓練をしているのと同じだ。

コピペではなく、本や雑誌に書いてあることを、キーボードで打ち直すのは面倒だと思うかもしれないが、自分はこの作業がまったく苦にならない。なぜなら、文章を打ち直す行為は学校で先生が黒板に書いたことをノートに写すのと同じで、その行為によって理解や記憶が深まるからである。

もうひとつ。学校で授業を受ける際のインプットは先生が選択した情報だが、自分がやっているのは誰かから強制的に与えられた情報ではない、自分が自分の意志で選択した情報だ。そこに一貫性がないとブログの内容はその人の興味のあること＝日記風になり、何らかの目的、一貫したテーマがあれば、最終的にはその目的、テーマを達成るための体系になりうる。

もちろん、このブログは後者を目指しており、結果的に『組込みソフトエンジニアを極める』→設計に関する体系と『リコールを起こさないソフトウェアのつくり方』→V&Vの体系 にまとめることができた。

自分で自分のやることを選択して実行し、他人に認めてもらうというサイクルを回す際に一番苦しいのは、最初のステップ「自分で自分のやることを選択する」という点だ。なぜって、そこが最初だから選択した責任は自分にある。誰かから言われたことをやって失敗してら失敗した責任の一端は最初にヤレといった人にあるが、やるべきことを自分で選択したらすべての責任は自分にある。その覚悟をするのが大人になるとそれなりに重いのだ。

日本の技術者は自分でやりたいことを選択してやりきるという経験が非常に少ないように感じる。別にソフトウェア開発じゃなくてもいいから、料理でも作曲でも、目的を持ったブログでもちょっとした簡単なことでいいのでやってみるといい。やっていくうちにもう少し極めたいと思ったらしめたものだ。

そして「なんで、自分はこんなことをやっているのだろう」と必ず思うはずなので、そのときに根拠となるロジックを自分の中に構築する。これを習慣化すると自立したエンジニアになれる。

【参照】

1. モンテッソーリメソッド（子供向け）
2. モンテッソーリメソッド（大人向け）：自立したエンジニアを育てよう！

今回の記事を書きながら、そんなことを思ったのだった。