第1回　プログラムは「どう書くか」の前に「何を書くか」

前田卓雄
2008/9/12

前のページ｜1　2｜

■そのまま放置してよいか

　環境はどうか。図2を見てほしい。ソフトウェアの開発需要は今後も増大すると考えられる。ハードウェア製品の多くにはソフトウェアが組み込まれているし、他社より優れたものを出荷するためにソフトウェアは欠かせなくなっている。業務系でも、今日、ITを駆使し業務を推進することが当たり前になり、情報システムに大きく依存している。こうした傾向は今後も継続・拡大し、結果的にソフトウェアは複雑化・大規模化していかざるを得ない状況だと考えられる。

図2　ますます増大するソフトウェア開発要求

　他方、複雑化・大規模化することによって、ソフトウェアのコンポーネント間の関連が増える。これにより、開発やテストに要する期間・工数が激増し、ソフトウェア技術者の生産性はどんどん下がっていく。つまり、開発・テストにかけた時間の割には付加価値向上につながらないという事態に遭遇する。結果、稼げない。

　さらに、その事業分野から撤退するソフトウェア企業が増加することになるだろう。例えば、ソフトウェアが凝縮された携帯電話のメーカーに事業撤退の事例が発生している。現状のソフトウェア開発の事業モデルが成長の限界に達し、これ以上成長の余力がないにもかかわらず、やみくもにソフトウェアを開発すればよいとする事業を継続することによって（撤退が）必然的に生じている（図3）。新しいビジネスモデルを創生できなければ、廃業することもやむを得ない局面である。

図3　S-Curve（成長曲線） 出典：「TRIZ実践と効用−体系的技術革新」

　このような環境では、図1（D）のように、無為に「順応する」ことほどリスクの高いことはない。順応する前に、将来にわたって成長し、安心できる組織・環境か、確認することが欠かせない。生き延びるには、知恵やアイデアが必要なのである。「人まかせ」にすれば、納得できない結果になったとしても、やはり受け入れるしかない。

■自分の理想的な解

　では、能力が存分に発揮できる分野はどこだろうか。ソフトウェア開発であれば、2つの大きな分野がある。1つはどんなソフトウェアを作ればよいか、という「アイデア出し」の工程であり、もう1つはそのアイデアを実現させる工程である。後者には、設計・開発・テスト・リリース・保守などのサブ工程が含まれる。設計以降の工程がどのように優れていても、その前に作るべきソフトウェアのアイデアが必要である。また、アイデアだけでは実際にソフトウェアは作れない。2つの側面で着実に成果を出せる能力・方法・仕組みが必要だ。

　この2つの側面を自分中心に見ると、アイデアを出す側に参加するか、アイデアを実現することに寄与するかである（多くの技術者はこの工程に参加していて、アイデアを出す側にいない）。もちろん、小規模なソフトウェアであれば、1人で2つの側面を担当することが好ましい。また、アイデアには、これまでになかった画期的なソフトウェアを創出することと、身近なソフトウェアに内在している問題に解決策を提示することの2つの側面がある。もしこのアイデアが自分になければ、他者から「要求」として受け取らなければならない。

　図1の下部に記載した「TRIZ/USIT for Software and Information Technologies」は、このアイデアを豊かに創造するための考え方・方法を教えるものである（TRIZ/USITの詳細は次回以降で紹介する）。ソフトウェア技術者が、成長の限界を感じたとしても、むしろその限界を問題（創造・発明し、事態を革新すべき課題）としてとらえ直し、視点を変えることで新しいアイデア・力を生み出すことが可能になる。例えば、TRIZには「究極の理想解」という概念がある（図4）。最初に、問題がない理想的な状態を考え、そこから少しずつ現実的な解決策を探すのである。

図4　究極の理想解 出典：「TRIZ実践と効用−体系的技術革新」

■自分の力を引き出してくれるもの

　アイデアを出せといわれても、なかなか出てくるわけではない。アイデア創出の古典的名著『アイデアのつくり方』（ジェームス・W・ヤング著）では、（1）資料集め、（2）資料に手を加える、（3）孵（ふ）化や組み合わせ、（4）アイデアの誕生、（5）アイデアの具体化・展開、の5つのステップでアイデアが出るとしている。つまり、アイデアを出すには、問題意識を持って日ごろから努力を積み重ねなければならない。継続した意志が必要なのである。

　意志があるのであれば、努力も積み重ねるであろう。そうであれば、もう少しアイデアが出るかもしれない。アイデアが出ないとしても、問題を抱えているとすれば、アイデアを形成することができる。では、アイデアの源である問題を持っているだろうか。

　問題があれば、問題をアイデアに変えるための「手法」を習得すればよい。そこで、次回以降で、「果報は寝て待て」ではなく、問題からアイデアに変える「手法」を紹介する。

【筆者注】 ●TRIZ：「トゥリーズ」と発音する。もとはロシア語。英語ではTheory of Inventive Problem Solving、日本語では「発明的問題解決の理論」と訳されている。 ●USIT：「ユーシット」と発音する。Unified Structured Inventive Thinkingの略語。日本語では「統合的構造化発明思考法」と訳されている。 TRIZとUSITについては、こちらに詳細な情報が掲載されている。

筆者プロフィール

前田卓雄（まえだたくお） 匠システムアーキテクツ株式会社 代表取締役 外資系コンピュータベンダのシステムエンジニア、デロイトトーマツコンサルティングを経て独立。主に、ユーザー企業、行政機関、大手システムインテグレータ、ハイテク企業、大手組み込みソフトウェア開発ベンダにおいて、情報戦略の立案、ユーザーが自ら作成するRFP（提案依頼書）作成を支援、ソフトウェアビジネスのプロジェクトポートフォリオ、プログラムマネジメント、プロジェクト管理とプロセス改善、開発プロジェクト管理システムの開発、バグ削減・欠陥予防・ソフトウェア生産性や競争力向上コンサルティングに従事。

前のページ｜1　2｜

＠IT自分戦略研究所 全記事インデックス