プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > プロマネへの道 > 浜田 佳正さん(5) 東芝情報システム株式会社

2008年9月 8日

浜田 佳正さん(5)
東芝情報システム株式会社 第二SIソリューション事業部 技術管理部長

浜田 佳正さん浜田 佳正(はまだ よしまさ)さん
東芝情報システム株式会社
第二SIソリューション事業部
技術管理部長
1981年、青山学院大学経営学部卒業。同年4月東芝情報システム(株)に入社、分散処理コンピュータのビフォアSE、システム開発作業に従事。
1992年に、(株)東芝と協働で、C/S方式に切り替える顧客向けにDOAによる要件分析を開始。1999年よりISO9001、CMMに基づいた品質・生産性向上活動に従事。
2003年より現在まで、事業部の人材育成・技術管理を担当。

CMMを活用し、全社的に品質向上を

浜田 佳正さん

能登原
CMM(Capability Maturity Model)の活用は2000年くらいから始められたのですか?

浜田
まずQMS(Quality Management System)をいろいろ見直し始めて、CMMは2001年くらいからです。

能登原
その当時、浜田さんが担当でいらしたのですね。

浜田
ええ、品質管理担当のような仕事でした。

能登原
それはソリューション事業部の中でのお仕事だったのでしょうか。

浜田
いえ、会社全体としての仕事です。ですから、同じグループの中に、ほかの事業部の人間もいましたし、工場の品質担当の面々もいましたね。

能登原
そうですか。やはりそれは浜田さんがSI開にいらしたというのも関係しているのでしょうね。現場でモデルを実際に使った経験がおありなので、今度は全社の底上げにも力を振るってもらおうというということだったのでしょうか。

浜田
会社トップの熱意があったと思います。
現場には品質を上げたい、生産性を上げたいという思いはあるのですが、それを「じゃあ、どうしようか」という部分が分からないわけです。地道な活動をしていくといっても、やり方が全く見えないというか、「どこから手を付ければいいの?」という状態だったと思います。そこにCMMの考え方を持ってくると、障子の桟(さん)のようなモデルの枠を、現場の状況に当てはめてみることができるわけです。

能登原
ええ、一定の枠をはめることができます。

浜田
そうすると、自分たちのどこが弱いのだろうか、どこを強くしたらもっと品質が上がるのかということが、一応見当がつきます。「じゃあ、そこをピンポイントで上げていこうよ」という話を始めるわけです。そのアプローチはやはり正しかったと思いますね。

能登原
確かに、どういう形でもいいから物差しで測って、「ここがちょっと弱い」とか「ここが強い」と分かるのがCMMの良いところだと思います。そういう意味ではよくできていますよね。

浜田
よくできていますよ。あくまでもモデルではありますが、よくできたモデルです。一度、東芝グループ主催のCMMの講習会に出席したことがありますが、そのときは、CMMのアセッサーの方が講師で、3日間の基礎コースを受講しました。そこで「CMMとはこういうことですよ」というお話をしてくれるのですが、毎日毎日、本当に1時間おきくらいに言われる一言があって、それが「CMMはあくまでもモデルだからね」ということでした。それをずっと繰り返して言われていたのです。要するに、CMMは万能ではなくて、判断の入れ物でしかないということですね。だから何を入れるかは、ちゃんと自分たちが考える必要があると。

能登原
なるほど、その通りですね。

浜田
特に「現場の人が考えて、現場でそれを改善していかないと、ちゃんと成果は上がりません」ということを、もう本当に口を酸っぱくして言われました。それが今でもずっと記憶に残っています。

能登原
それはまた、いいお話をお聞きしましたね。そういう残っている言葉が、一番大切なキーワードなのでしょうね。

浜田
まさにキーワードです。「それが万能だと思ってやってしまうと、現場がついてこれません」と言われました。

能登原
そのあと実際に活動されていったのですね。CMMの場合、ISOのように認証を取得するというのではないですよね。

浜田
ええ、「達成」といいます。でも、達成がいつだったかより、どういう成果が上がったかというのが重要かと思います。

能登原
ええ、そうです。

浜田
CMMの本当の成果が出てきたのは、現場がそれに取り組み始めて、CMMの組織と併行してPMOが作られてからです。特にうちの事業部では、「PMOをちゃんとしなきゃいけないね」ということで、経験豊富でしっかりした人にやっていただいて、その中で、幾つかの施策を考えました。
CMMというそのモデルの中に当てはめることもできますが、そうはせずに、PMO中心に弱い部分をピンポイントで改善していくことになりました。まず、受注時のレビューのやり方とか、承認のレベルとか、そこがまず一つ弱いと。それからプロジェクトが始まったときに、プロジェクトマネジメントレビューがありますが、そこも弱いので、きちんとてこ入れしないといけないということでした。そういうピンポイントについて、PMOが自分たちの足で各レビューの場を歩いて、必ず100%いろいろな階層で地道に全部フォローしていったのです。そして「○」「×」「△」「雨」「曇り」「晴れ」とか、判定結果もつけていきました。

能登原
今もそれをやられているのですね。

浜田
ええ、それをやって、やっと見えてきたのが、品質が良くなってきて始めて生産性の改善に取りかかれるということでした。品質と生産性は、切り分けが難しいですよね。

能登原
難しいですね。

浜田
だから、品質が良くないときには、生産性を出せているかどうかは、なかなか測定できないのかなと思いました。

能登原
同様の意味で、プロジェクトが成功かどうかを出すのも難しいですからね。

浜田
難しいですよね。

能登原
私は最近、KPIのような指標でマクロ的に見るようにしています。例えば、プロジェクトが1年間に50個あるとします。今までは50個のうち、失敗が半分ありましたが、次の年は50個のうちに失敗が5個しかありませんでしたということであれば、その成功確率というのを年間で出して、その指標が上がれば、実はトータルで品質も生産性も上がっていると判断できるのではないかと。

浜田
結果としては、品質も生産性も上がっているのでしょうね。そういう判断の仕方もあるのかもしれませんね。

能登原
そのくらいマクロで見ないと、活動の成果が上手く評価できないと思います。CMMの活動は非常に広いので、いろいろな手を打っていますよね。教育も、標準の導入もやっているし、さきほどのお話のようにPMOの活動もやっていますので、なにが効いたかよく分からなくなってしまいます。

浜田
ええ。現状の品質での正確な生産性は、計算して出るのですが、品質とその生産性の関係になると難しくなりますよね。どこまでが品質問題で、どこからが生産性かって切り分けできないですから。永遠のテーマですよね。

能登原
でも、そういうことを、地道にずっと積み上げられているということですよね。

浜田
そうです。今はもう私自身は、ほとんど品質のことはやっていません。どちらかというと品質の教育の方向におりまして、実際の開発のほうはしておりません。

能登原
現在、浜田さんはPMOのメンバーではないのですか。

浜田
当時からPMOのメンバーではありませんでした。今お話ししたのは、私ではなくてPMOの成果です。

能登原
とは言っても全部、連動していますからね。

浜田
ええ、そうですね。

今までにない、トータルな教育コースへのチャレンジ

能登原 伸二

能登原
そのころから、弊社と浜田さんのかかわりが生まれてくるわけです。あれは2003年でしたね。

浜田
はい、ちょうど私が前任者の大西の部下で、こちらにお邪魔したときが最初です。そのときから、教育や技術推進の担当でした。

能登原
大西さんと浜田さんのお話を受けて、web三階層アプリケーションの新規開発における要件定義、設計から開発までの全体を俯瞰したトータルな教育コースという、その当時、あまり世の中になかったものを作ろうということになりました。最初にお二人の熱意に感銘を受けたことを覚えています。

浜田
最初から、すごい要求を出していたような気がしました(笑)。

能登原
ええ、大西さんの考え方で、非常に広い範囲のお話をされていましたね。

浜田
私もびっくりしていました。全てのプロジェクトの要素がA3一枚にまとめられて。

能登原
設計の要素だけでなく、全ての要素が入ったものを聞かせていただいて、それを理解してかみ砕くのに一ヶ月くらいかかりました(笑)。今も常に改善させていただいています。
あの当時、やはりそういうことをやらないといけないというニーズがあったのですか。

浜田
そうですね。現場からのニーズというよりも、問題意識です。それが大西の中にも、私の中にも、会社のトップにも、現場にもあったと思うのです。ちょうどJavaが一般的になってきて、その開発をするのに、開発の前段階の設計の手法がきちんと確立していなかった。「要件分析ってどうやるの?」という話から始まっていたと思います。

能登原
そうですね。Java用の要件分析を調べても、きちんとしたものはあまりありませんでした。

浜田
「やっぱり要件分析ってDOAだよね」「それがいいよね」という話になります。どこまでいってもこの世界はDOAかな(笑)と。まだ、これから当分続くと思います。

能登原
そうですね。リレーショナルデータベースがなくなるまでは、たぶん続くのだと思いますね(笑)。

浜田
それで実装もリレーショナルデータベースになります。この流れは間違いないのですが、Javaで開発しないといけない。Javaはオブジェクト指向ですから、「上手く組み合わせないと、開発の現場が上手くいかないよね」というのが、お願いしたときのストーリーだったと思ういます。

能登原
そうですね。

浜田
さらに、いろいろな要素、プロマネの要素なども加えていただきました。ですから最初は、すごかったですよね。

能登原
すごかったですね(笑)。

浜田
まず林さんに全体像をプレゼンしていただいて。

能登原
最初は、本当に挑戦させていただきました。だんだん勉強しながら、少しずつ形にしていたわけです。御社には非常に勉強させていただきました。

浜田
お互いの勉強だったかもしれないですね。

能登原
その当時、私は個人的にも非常にその問題意識が強かったのです。それ以前にもいろいろ本を読んでいましたし、あるプロジェクトで挑戦したことがありました。最終的にはJavaでコーディングしないといけないのですが、上流をDOAで設計すると、どうもその上流設計とプログラミングの内部設計書、あるいはプログラム設計書のあいだに、非常に大きいギャップがあったのです。それをどう解決して、完璧とまでは言わなくても、ある程度、エンジニアリング的に上流から下流につなげるにはどうしたらよいのか、どこかで考えてやらないといけないと、ちょうど考えていたところだったのです。そこにそういうお話をいただいたので、非常にタイムリーに一緒に勉強させていただきました。お金をいただいて勉強できて、本当に感謝しています(笑)。

浜田
最初は、今能登原さんがおっしゃったように、きれいにつなぐのではなくて、現実として上手くつながっていくということを目指してやっていましたよね。

能登原
ええ、そうでしたね。

浜田
でも、実際にはそれでは満足しない人たちがいて、本当にちゃんときれいにつながらなければいけないということで、二回目か三回目のときに、「ここをきれいにつなげて下さい」ということをお願いしました。あのときやっていただいた方は、またすごい方でした。「ロバストネス図を入れてつなげば、上手くつながります」と。その発想も良かったです。実際にそれで講習をしていって、講習の中でつながりました。
それが正しいと実感できたのが、実はMDA(model driven architecture)なのです。ちょうどそのころ、弊社の中でも、MDAでの開発ツールを研究開発で作って、それをお客さまのプロジェクトに活用するということをやり始めていたのです。そのときの開発者の発想が全くその方と同じで、ちょっとツールの名前は忘れましたけど、ロバストネス図をまず描いて、それを機械的に変換していくと最終的にプログラムにできる、つまり、上流からロバストネス図にさえ落とせば、そこからは機械的にできるというツールを作ったのです。

能登原
それは東芝の研究所で作られたものですか。

浜田
いえ、東芝情報システムの研究所で作りました。

能登原
上流をちゃんとやればよいということになると、生産性は上がりますよね。

浜田
ええ、上がります。それが実証されたので、「ああ、今教えていることって、正しかったんだ」と、そこで実感できたのです。

能登原
そうですね。確か、ロバストネス図は、UML(Unified Modeling Language:モデルの統一的な表記法)の正式版には入っていないと思いましたが。

浜田
ええ、正式版には入ってないです。何で入らないのでしょうね。非常に上手くつなげられるのに。でも、私としては、それが分かって非常に嬉しかったです。

(次回に続く)

構成:萩谷美也子

↑ このページの先頭へ