Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)テクノロジーでビジネスを加速するための実践Webメディア

テーマ別に探す

見える化の効能

2007/07/30 10:20

システム開発は、プロ冥利に尽きる、面白い仕事であるはずなのですが、開発依頼者の要求に振り回されて、なかなかうまくいかないことも多いのではないでしょうか。

 この連載では、プロジェクトレビューの機能を中心にプロジェクトを成功に導くための心得を解説します。

はじめに~楽しいシステム開発のために

 30年以上もシステム開発に携わっていて、これがシステム開発の仕方の決定版、これを押さえておけば必ずうまく行くといった技術にお目にかかれません。その理由は、システム開発が担当者の持つ技術だけで進められる仕事ではないからです。

 あれを作ってほしい、これを作ってほしいという開発依頼者の要求も…さて、どれだけ具体的でしょうか。彼らの頭の中では具体的でも、実際のところ、システム開発の設計図を書くためには、あまりに抽象的で粒度が粗いですよね。そんな要求を聞いてシステム作りをはじめるのだから、これを吟味せずに進めたら、どうなりますか。

 しかし、料理だって、全て材料がそろえられていて、料理法も、料理も決まっていて、ただ作るだけだったら面白くはないですよね。やはり、どういうものを作るか、どういう風に作るか、考えるのが面白いのです。

 例えば、お客さんが考えを決めていて、そこにばかりこだわるようなら、どうですか? これまた、つまらない…というより、場合によっては匙を投げたくなりませんか? 話をし、一緒に、どういうものを、どういう世界を、どのような水準で実現するかを考え、決めていくのが面白いわけです。

 システム開発は、プロ冥利に尽きる、面白い仕事でもあるのです。

 独立行政法人・情報処理推進機構(IPA)・ソフトウェアエンジニアリングセンター(SEC)が発行しているSECジャーナル6号に、失敗学の東京大学名誉教授・畑村洋太郎先生が次のように書いています。

 コンピュータシステムを構築するということは、どのようなことかという基本から考えると、最初に要求機能があって、その要求機能を細かく分析すると、それに付随する制約条件がしだいに明らかになります。制約条件をもちながら、機能の分解や分析を行い、単位機能まで落とし込んで、個々の単位機能を実現する解決手段を考える。1個ずつの課題要素を実現する方法は数多く考えられますが、1個ずつの利害得失も考え、全体について解決策をトータルとして見たときに、どう見えるかという総合判断をしながら、その解決策を具体策にまとめる。そして、具体策を全部まとめて実現可能な計画にするんですね。したがって、最初の半分は分析、残りの半分は統合・総合なんですね。企業にいる多くの人ができるのは、分析して解決策を見つけるところです。それらを統合しながらきちんとした解決策にして、全体計画にまでもっていく…

 これが、システム開発の面白いところなのです。

プロジェクトをレビューするという仕組み

 さて、システム開発が本来面白いものであることはご理解いただけたことと思いますが、システム開発を面白く進めるためには、先ほど書きましたように、担当者の持つ技術だけではどうもうまく行きません。多くの人の知っていること、見ていること、やっていること、考えていること、把握していること、了解していることなどをみんな集めて、共有化していかなくてはなりません。共有化してシステム開発を共同で行うことが必要です。

 昨今の開発は、規模も大きく、利用範囲が広く、利用者、ステークホルダーが多いですから、そういった情報を的確にかつ、開発進捗の各段階で正確に集めなければ、よい仕事ができないのです。面白くなりません。

 システム開発を面白く進めるためには、情報管理が不可欠なのです。そんなことは、実のところ、皆さん百も承知でしょう。そのためにプロジェクト管理が大変大切なことも釈迦に説法と思います。

 しかし、具体的に情報を開発の各工程で的確に集めるとなると、臨機応変といっても、なかなかうまく行かないところがありますよね。開発依頼側の組織に開発受託側から直接、指示ができないという制約もあります。

 もっとも、開発依頼側でも同じ事で、権限や職務分担といったことがあります。職場の壁ですね。プロジェクトリーダーが臨機応変にといってもなかなかうまく行きません。やはり、基本ルールとなった仕組みが必要です。私が長く勤めた損害保険会社では、システムプロダクツの品質を高めるために、「デザインインスペクション」や「ウォークスルー」、また要件や、設計書のレビューといったことを開発の基本作業として定義し実施してきました。加えて、仕事の状況を正確に把握するため、プロジェクトのレビューを10年以上にわたって進捗管理とは別に行ってきました。

 この、プロジェクトをレビューするという仕組みをシステム開発の基本ルールとし、それもステークホルダーも参加してそれを行うという仕組みとすることによって、進捗管理では得られない、システム開発品質を向上させる情報の入手と共有化が実現したのです。

 情報入手と情報供給・共有そして情報管理がうまく行けば、システム開発がうまく行くことになります。何をすればよいかわかれば、我々は最短距離を最高スピードで安全に走る技術を持っています。打つ手が全てうまく行けば、そして主導権を握ることができれば、システム開発が面白くなっていくこと請け合いです。

 それでは、このプロジェクトをレビューするといった手法で何がよくなるのか、これから一つ一つ詳しく説明していくことにしましょう。これから、7回にわたって説明する、プロジェクトレビューの効能をお読みいただき、ぜひ面白いシステム開発を実現してください。まずは、「見える化」からです。

 なお、一度に読みたい…という方は、今回の連載の底本である拙著「実務で役立つプロジェクトレビュー」(翔泳社刊)をお読みください。

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 菊島 靖弘(キクシマ ヤスヒロ)

    独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センター(SEC) リサーチフェロー。 1975年東京海上火災保険に入社。以来30年間、損害保険、生命保険、確定拠出年金といった業務システムの開発に携わった他、東京海上日動システムズ取締役品質管理部長として、トラブル削減や、開発品質管...

バックナンバー

連載:実務で役立つプロジェクトレビューの心得

この記事もオススメ

All contents copyright © 2006-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5