（2010/1/3 掲載)（2010/4/27 一部改訂） お知らせ・・・
１）XDDPやUSDMの推進団体を立ち上げました・・・・・・「派生開発推進協議会」
この団体を通じて、日本の派生開発のあり方を発信していきます。
詳しいことは、ＨＰ（www.xddp.jp）をご覧下さい。
２）「派生開発カンファレンス2010」を６／１８に横浜で開催しました。
約２７０名という大勢の方の参加を得て、盛況のうちに終了しました。ありがとうございました。
今年の６月１８日（金）に、横浜市開港記念会館（http://www.city.yokohama.lg.jp/naka/kaikou/）にて「XDDP」や「USDM」など、私が提案し勧めてきた方法に関連したカンファレンスを開催します。「XDDP」のコンサルティングを始めたのは15年前で、この間、講演やセミナーの形で話をした回数は、２つのテーマだけで１２００回は下らないはずです。1回の研修の参加者が３０名としても延べにして３万以上の人が「XDDP」や「USDM」の話を聞いていることになります。もっとも最初の頃は「XDDP」とか「USDM」という呼び方をしていませんでしたし、内容は今と比べると少し不足しているところはありますが、その代わりほとんどはコンサルティングの中で話してきましたので、資料上の不足はコンサルティングの中でカバーしてきました。
その後、10年のコンサルティングのまとめとして2004年に｢USDM」として雑誌に公開したのを皮切りに、翌年に単行本の形で発行し、さらに2007年に「XDDP」を単行本で発行してきました。この間、「USDM」は23000部を越え、「XDDP」の13000部に近づいていて、講演やコンサルティングの機会をもてない人たちにも、これらの方法がだいぶ知られるようになったと思います。
しかしながら、システムクリエイツの活動は、基本的には私一人ですので、なかなか手が回りません。コンサルティングも現場のいくつかのチームではうまく取り組めるようになったところは少なくないのですが、社内に「USDM」や「XDDP」の指導者を育成するところまで取り組めたところは僅かしかありません。それは時間的な制約の他に、組織としてそのような人材を配置することを受け入れてもらえなかったことが主な要因です。
そのため、「USDM」や「XDDP」は多くの組織で取り組まれていると思いますが、果たしてうまく取り組めているのかどうかわかりません。嘗てコンサルティングを実施した組織でも、その後もうまく継続してくれているかどうかわかりません。多くの場合、当面のプロジェクトで成功に誘導できたことで、あとは自分たちでできるだろうという判断が下され、彼らに対するコンサルティングはそこで終了するというケースも何度もありました。一度目は私の方で誘導していたのであって、自分たちの判断でできたわけではないのですが、組織のマネージャーにはそのことを認識してもらえないこともありました。したがって、このようなケースではおそらくその後は行き詰まっている可能性が高いと思われます。そのほか、コンサルティングの時と比べてターゲットの規模が大きく変化することで対応に混乱したり、社内に指導者を育成していない状況ではチームのメンバーが入れ替わったりすることで崩れてしまう可能性もあります。
今回、ある方の勧めもあって、日本中で「USDM」や「XDDP」に取り組んでいる現場の人たちが集まって、自分たちのやり方を確認したり、それぞれの組織で抱えている課題に対するヒントを得たりする場を設けてみようということで「派生開発 in Japan（仮称）」の開催を計画することになりました。手始めに横浜で「１日」で実施しますが、実際に「XDDP」や「USDM」に取り組んでいる現場の事例を紹介してもらいますので、会場に来られた方たちの参考になればと思っています。
内容としては「XDDP」に限りません。「XDDP」に取り組めば、いやでも「USDM」への取り組みも出てきますし、新規開発で「USDM」を使った例も出てくるかもしれません。とにかく、それぞれの現場で取り組まれている様子を「目に見える形」にすることで、課題を抱えている人たちの参考になればと思っています。今回は、初回ということもあって、発表していただく事例は私の方で選ぶ形をとりました。今回のカンファレンスの反響を見て、開催の継続や日数の拡大、開催場所の展開なども考えたいと思っています。
なお、今回のカンファレンスの詳しい案内は、このホームページとは別に、準備でき次第お知らせします。
以下に、今回のカンファレンスを開催するにあたって、その有効性や必要性などを時代的背景という面から触れてみます。
オフショアリングの見直し
2008年夏のリーマンショックをきっかけに、世界の経済が停滞し、その中でアメリカの過剰消費も見直されました。それまで、アメリカの過剰消費に依存して生産を積み上げてきた世界の企業は一気に在庫を抱えることになり、慌てて生産を半減させました。中には１／３に減らすところもあったようです。
過剰生産（供給過剰）を原因とする従来の不況では、一時的に生産を調整し在庫を減らすことで、半年か1年程度で生産を元のレベルに戻すことができましたが、今回の不況は需要の減退（需要不足）が原因です。しかも一時的なものではなく、明らかにアメリカでは過剰消費が見直されており、社会習慣が変化したと捉えるべきでしょう。それを裏付けるものとしてアメリカの貯蓄率がこの1年で大幅に上昇しています。それまで１％台で推移していたのが６％台に上昇しているのです。需要の減退が一過性のものではないということで、世界全体で元の需要レベルに戻るには、新しいマーケットの創造が必要になります。当然、回復までには3年とか5年という時間が必要でしょう。はたして日本の製造業はこれに堪えられるかどうか。
この過程で、製造業を支えているソフトウェア開発の現場では、開発のペースがスローダウンしています。また利益が大幅に減少したことで強烈なコストの削減要求がでています。その影響でアウトソーシングやオフショアリングの見直しも行われ、ソフトウェア開発の国内回帰や社内回帰が始まっています。つまり、国内や海外のソフトウェア企業に外注していた開発案件を引き上げて社内開発に切り替えているのです。
企業の収益が落ちている状況では、ビジネス分野でもこの余波を被ることになります。不急不要のソフトウェア開発にはブレーキがかかっているでしょう。また社会インフラに関係するソフトウェアシステムでも、税収減によって公共事業の予算が削減されたことで開発期間を延ばす傾向も見えています。この分野でも、アウトソーシングやオフショアリングが広がっていたはずで、そこでも国内回帰、社内回帰が始まっていると思われます。
なぜ「社内回帰」ができるのかというと、日本ではアウトソーシングやオフショアリングを取り入れたにもかかわらず、社員（ソフトウェア開発要員）を減らさずに、役割がこれまでのソフトウェアの開発から、外注の窓口に変わっただけなのです。しかも、不思議なことに今回のアウトソーシングやオフショアリングの見直しの目的は「コスト削減」なのです。
かつてアウトソーシングやオフショアリングに取り組んだときの目的も「コスト削減」でした。もし、社内要員で開発するよりもアウトソーシングやオフショアリングによってコスト削減の効果を上げていたのであれば、今回のリーマンショックで一層のコスト削減が求められたのを機に、それらの外注を斬って社内回帰するという選択は矛盾する可能性があるのです。
現実には開発の総量（件数）を減らしたことで、少なくなった開発案件を社内に残っていた要員で対応しようというケースが考えられますが、これだって開発案件単位の利益率でいえば、アウトソーシングやオフショアリングによってコスト削減に成功していたとすれば、社内回帰でコスト削減ができることはないはずです。それともデフレによって国内で開発するコストが海外よりも安くなったといいうことでしょうか。
このように開発の社内回帰という事実を裏返せば、これまでのアウトソーシングやオフショアリングでコスト削減が達成していなかったのではないかと思われます。それはアメリカと違ってアウトソーシングやオフショアリングした際に、社内のソフトウェアの開発要員を解雇しなかったからです（正しくはできなかった）。つまり、社員を指名解雇できない状況にあっては、単なる「コスト削減」を目的にしたアウトソーシングやオフショアリングは実現しないのです。はからずも、今回のリーマンショックによる揺り戻しで、そのことが露呈したのです。実際、アメリカではインドにオフショアリングしたことで年収が1500万円クラスのプロジェクトリーダーが職を失っています。
いずれにしても、結果的に安易なアウトソーシングやオフショアリングが見直され、ソフトウェア開発の社内回帰が始まりました。確かに組織にはかつてソフトウェアの開発に携わっていた技術者（？）は残っています。でも、多くの場合、そこにいる人がここ何年かの間やってきたのは発注作業や外注の窓口作業であり、その間ソースコードを触っていないのではないだろうか。90年代半ばのアウトソーシングから続いているとすれば10年以上、ソースコードに触れていないかもしれません。あるいは入社以来一度もソースコードに触ることなく外注の窓口をやってきたという人も少なくないと思われます。その状態で突然「これからは社内で開発する」と言われても、はたしてまともに対応できるでしょうか。ソフトウェア開発の仕事は、工場の生産労働者と違って数週間の訓練でできるようになる仕事ではありません。
必要な技術をきちんと習得していたのであれば、数週間の準備期間があれば、元の状態に戻るかもしれませんが、中途半端なトレーニングだけでソフトウェア開発に携わってきたような状態の場合は、「元の状態」が安定しているわけではないので、簡単には使える状態にならない可能性もあるのです。組織のトップは、このことに気付くべきです。
まずは「XDDP」で対応しよう
幸いにも、ほとんどの開発案件は「派生開発」です。派生開発では一般に開発期間が短く設定されます。開発期間が短いということは、そこで求められるプロセスの数も少ない（はず）ということです。しかも最も難しい「システム設計」というプロセスは基本的には「派生開発」には出てきません。そこで求められるのは、新しい機能を追加するための機能単位の設計技術と、既存機能の仕様を変更する作業です。既にそれなりのアーキテクチャが確立している状況では、追加機能の設計で必要になる技術はそれほど難しいものではありません。もちろん、アウトソーシングやオフショアリングによってベースのソースコードが限度を超えて崩されていなければの話ですが。
むしろ、注意が必要なのは「機能追加」ではなく「仕様変更」の方です。そこでは、現状のソースコードを読んで理解するという、別の意味で厄介なプロセスが出てきます。これこそ、派生開発特有のプロセスであって、新規開発や追加機能の開発には出てきません。それでも、こうした派生開発への取り組み方は「XDDP」という派生開発専用のプロセスでだいたいは対応できます。
「XDDP」では、要求仕様（追加／変更）からソースコードの変更までの一連の開発アプローチを提供しています。そこに含まれていないのは、機能追加の「設計プロセス」だけであり、それは既存のそれぞれの手法に基づいた設計プロセスを当てはめることになります。「XDDP」は変更プロセスと追加プロセスを並行させて進める派生開発全体の開発アプローチがなのです。しかも、変更プロセスは再利用性が高く、一度きちんと習得すれば同様のドメインであれば僅かな調整（テーラリング）で再利用できます。
ドメインが変わったり、変更規模が大きく変化したときにはプロセス設計からやりなおすことになりますが、その場合は「ＰＦＤ」によるプロセス設計の方法を習得していれば、要求にマッチするプロセス（開発アプローチ）を自在に設計することができます。このスキルを同時に手に入れることで、「XDDP」は非常に再利用性が高い開発アプローチになり、現下の状況においてはうってつけの方法でもあるのです。
かつてのアウトソーシングやオフショアリングが実際にはコスト削減の効果がないという偽りの対応だったわけですが、逆に、ソフトウェア開発をしてきたエンジニアが組織に残っていたり、その製品やドメインを知っている要員が確保されているのです。確かに、ソフトウェア開発作業からはしばらく離れていたかもしれませんが、２，３週間、「XDDP」や「USDM」など、関連した技術を真剣に準備すれば、派生開発にはなんとか対応できると思われます。
痛んだソースコードへの対応
ただ一つ気になることは、この間のアウトソーシングやオフショアリングによって、外部のソフトウェア企業に提供したソースコードが無規律に弄られてしまった可能性があり、「保守性」という観点から相当に痛んでしまったかもしれません。もともと、派生開発を社内で開発していたときから、ソースコードを劣化させないための「保守性」の要求仕様について何も記述されていません。途中でアウトソーシングやオフショアリングに切り替わったわけですが、外部のソフトウェア企業に対して劣化防止のための保守性の要求仕様を課してきませんでした。
これは大失敗です。この間の仕様変更や機能追加に対して、その実現方法をまったく問うことなく、機能仕様書上で望むように動作するかどうかしか求めてきませんでした。仕様変更の実現方法だって一つしかないわけではありません。簡単な仕様変更でも、実際には実現方法は複数存在するものです。代表的な例としては、安易なコピー＆ペーストによって実現する方法です。本来なら「共通機能分割」という方法で対応すべきところを、変更作業を簡単にするためにしばしばコピー＆ペーストによってクローンコードが作られています（実際にはコピー先の環境に合わせて変数名などを変えてしまうために「ステルスコード」の状態になっています）。ただし、納品検査では変更の実現方法までは検証していないし、機能仕様上は依頼通りに動作しています。その上、今からではそうした変更を改める時間的な余裕も残されていません。
なぜ、このような事が起きるか。その理由は簡単です。もともと他人の書いたソースコードを読み解くのは容易ではありません。ましてや国が違い、国民性も違った状態では、ソースコードを理解する難しさは数倍に跳ね上がります。さらに、ソフトウェアエンジニアリングそのものがほとんどは新規開発の場面を想定したもので、派生開発の場面でなすべきプロセスが定義されていません。そのため、大学などでも新規開発向けのソフトウェアエンジニアリングのカリキュラムは用意されていても、派生開発の場面で必要な技術は取り残されています。
たしかに「リエンジニアリング」という領域はありますが、これはいわゆる旧来の「保守プロセス」を想定したもので、今日の組み込みシステムなどで盛んに行われている機能追加や多彩な仕様変更には対応できていません。したがって仕様変更に対する「保守性」の要求をしっかり課していない状態では、時間的な制約もあってどうしても担当者の思いつくままの対応が行われてしまうのです。
こうして外部のソフトウェア企業に託されたソースコードが、今回のリーマンショックを機に社内回帰で戻ってきたものの、これまで無規律に弄られてしまったことによって、ソースコードは相当に痛んでいる可能性があるのです。以前に担当したことのある人が見れば、その変わった姿に驚くかもしれません。でも、今となって後の祭りです。この現実を受け入れるところから再開するしかないのです。
これらのソースコードは、しばらくは簡単な変更には耐えられるでしょうが、本格的な機能追加や仕様変更には耐えられないかもしれません。近いうちに新規開発が必要かどうかを早く見極めておく必要がありそうです。その際に、どのような変更なら現状のソースコードで対応できるか、どのような変更には耐えられないのかという基準のようなものを掴んでおくとよいでしょう。そうして、派生開発を進めながら、迫り来る新規開発の準備をしなければなりません。「XDDP」は、派生開発に特化した効果的な開発アプローチを提供しているので、しばらくは「XDDP」で時間を稼いで、その間に新規開発に必要な技術の準備を進めるとよいでしょう。
新しいチャンスを掴めるか
今回の不況は日本の企業にとって大きなダメージとなってしまいました。しかも先に述べたように、今回の不況はこれまで水増しされていた需要が通常の状態に戻ったということであって、簡単にはこの需要は以前のレベルには戻らないでしょう。実際、アメリカ国民の行動は変化しており、これまでのアメリカにおける需要の構造は変わったのです。
つまり従来の需要構造には簡単には戻らないということであり、日本の企業にとっては大きな選択を迫られています。一つは、減退した需要に合わせて供給を減らす方法です。かつて日本の造船業界は何度かの設備廃棄によって需要減退を乗り切ったことがあります。でもこの方法は明らかに雇用を失うことになるため、簡単には選択できないでしょう。
もう一つの方法は新しい需要を作り出すことです。この場合は新しいマーケットを作り出す必要がありますが、これは日本にとって大きなギャンブルになるかもしれません。
新しいマーケットには2種類あります。１つは、新興国が経済力をつけることでマーケットが生まれるので、そこに資本などの投資を行って経済力を高めることを促進することです。この場合は、そこに提供するサービスや製品などは、ほとんど既に存在しているもの、あるいはいつでも用意できるものなので、日本としては直ぐに対応できます。ただし、マーケットが日本にとって新しい地域に生まれるということで、その地域に新しい供給者が生まれる可能性があり、日本の企業としては展開するタイミングを逸すると参入機会を逃す可能性があります。残念ながら、この種の行動は日本の企業の得意とするところではありません。言葉の障壁もさることながら、普段からそれぞれの地域社会に根ざした企業活動が行われていないことも大きな原因になっています。
もう一つは、いままでとは違う「環境」や「ルール」を作り出すことで性質の異なるマーケットがを生み出す方法です。このマーケットはまったく新規の事業になります。たとえば再生可能エネルギーによる「スマートグリッド」のマーケットであり、電気自動車を基幹とし、「都市空間全体を電動化した移動社会」のマーケットであり、多世代住居をベースにしながら「情報の移動を瞬時に提供する」マーケットといった、まったく新しい発想が必要になります。そこでは、人間の幸福とは何か、コストのかからない社会とはどうあるべきか、地球を壊すことのない社会とはどうあるべきかといった根源的発想に根ざしたところで、新しいマーケットを創造することが求められます。
過去の日本企業の行動から判断すると、こちらも必ずしも日本の企業は得意とはしていません。誰もやったことのないことに挑戦することが苦手であることや、製品やシステムの「要素」は開発できても、「全体」を構築するにはシステム的発想が必要になるのですが、どうもその部分が弱いのです。
ところで、ソフトウェアの開発部門、あるいはそこに所属するソフトウェア技術者として、どのようにしてこの新しい時代に備えますか。目の前の派生開発プロジェクトでは、ソースコードの見つけた箇所を拙速に変更しまうことによってバグに追い回されています。開発期間の半分以上がこうしたバグつぶしに追われている状況を改善しなければ、時代の先端を走るチャンスは掴めません。
「XDDP」は、まさにこうした状況の中で効果を発揮する派生開発専用の開発アプローチということができます。短期間の準備で、目の前の派生開発の案件をそつなくこなし、余った時間を「未来」の準備に回すのです。派生開発に対応しながら新規開発の設計技術を習得したり、新しいドメインの知識を身に付けるのです。多重コアのCPUを使いこなすためのアーキテクチャ設計技術なども必要でしょう。準備することは沢山あるはずです。
「XDDP」は当面の派生開発に効果的というだけでなく、「MDA」などの方法で開発したシステムの派生開発や「SPL」にも基本的に対応でき、一度手に入れると長く使える開発アプローチなのです。「USDM」の方も、UMLと組み合わせる方法があり、要求の仕様化が相当に改善されるはずです。
「派生開発」のプロフェッショナルを！結局、新しい時代に備えて準備するためにも、目の前の派生開発の案件をうまくこなす必要があるのです。バグに追い回されることなく、予定通りに派生開発の案件をこなすことです。決して必要以上の工数を投下することはありません。そうした状況を作り出さないかぎり、個人としても新しい時代に備えることはできません。同時に日本の産業は敗退してしまうことになります。そんなことになればとてつもなく多くの雇用を失うことになります。これはあり得ない話ではありません。
評論家といわれている人たちは過去の実績と企業から出てくる経営上の数字（これも過去の数字ですが）から、いろんな話をしています。日本の製造業は世界に誇るものがある。日本には他の国に負けない技術があると言い続けています。
確かに1980年代の日本の製造業は強かったことは事実です。「Japan as No.1」と言わせたことも決して誇張ではありません。その当時、技能オリンピックでメダルを独占しました。でもそれはメカやエレキの領域であり、いわばハードウェアの領域です。
今日の製品は80年代の製品と大きく違う部分があります。それは「ソフトウェア」の占める位置が大きく変化したことです。今日の製品はソフトウェアで動いていると言っても過言ではありません。ソフトウェアのできによって製品の善し悪しが決ってしまいます。
私は長年このソフトウェアの開発現場を見てきました。今もソフトウェアの開発現場で何が起きているか見ています。ソフトウェアの派生開発というのは、管理を過つと突然行き詰まります。前回はなんとかリリースできたとしても、この間にメンバーが交替し、ソースコードの傷みが限界を越え、競合他社との競争が激化しています。さらにCPUなどの部品の性能が一気に向上したのをきっかけに、その製品に搭載する機能が大きくブレークし、その途端にとんでもないことになります。
そのような組織の特徴としては、開発の組織体制も混乱を繰り返す度に分担が細かくなり、中間成果物が複数の組織を行ったり来たりして複雑になっていき、どこに問題があるのか分からなくなっていきます。そのような組織に限ってまともなテスト部門すら存在しないことも少なくありません。「そんな人材がいるなら設計（開発）の最前線に送り込め」という檄が飛びます。結果は悲惨なことになります。
実際、この15年間に、そのような事態に陥った企業からのコンサルティングの依頼は何件かありました。まさに事業継続の瀬戸際の状態で依頼が入ったのです。でもそれらのケースはすべて「XDDP」「USDM」「PFD」のセットで切り抜けてきました。すべて1年以内に混乱をクリアしています。そして、混乱が収まったことで前線から人を下げて組織体制を建て直しました。もし、「XDDP」「USDM」「PFD」といった方法が無ければ、その事業から撤退を余儀なくされた可能性もあるのです。
こうした事態にすでに陥っているか、今にもその崖を滑り落ちようとしている状態にある企業は少なくないと思われます。そこでは、人垣を作って必至に食い止めていることでしょう。もちろん、その状況の中で人は壊れていきます。果たして企業のトップはこの状況が見えているでしょうか。現場の責任者はこの状態をきちんと報告しているでしょうか。
バグで混乱したものの数ヶ月遅れで製品は何とか出荷できたとすれば、問題になっていないのではないでしょうか。いや、問題にする暇がないといった方が適切かもしれません。休む暇もなく着手が遅れているプロジェクトに投入されるのです。前回の問題点を究明していませんので、次のプロジェクトに対して効果的な方法を手に入れたわけではありません。技術レベルは前回と同じなのです。いや、疲弊した分だけ前回よりも条件は悪いのです。
日本の多くの企業は、この状態を繰り返しているのです。これらの行動は水面下で行われているため、外からは見えません。でも私には、日本の企業から生み出される製品は、こうした「人柱」の上に成り立っているように見えるのです。このまま行けばきっとどこかでプロジェクトは「破裂」します。ソフトウェアの開発組織は日本のあちこちで「崩壊」します。
今回のリーマンショックで、事態はさらに悪くなっています。一層のコスト削減ということで、これまでの外注政策が見直されて社内回帰が始まりました。でも実際の仕事に耐えるソフトウェア技術者は減っています。彼らの技術レベルを引き上げるためのコストも出し惜しみされている状況です。「竹槍一本で何とかしろ」と言われているようなものです。このままでは、「破綻」のペースが早まってしまいます。
この意味からも、「XDDP」や「USDM」「PFD」といった方法をできるだけ早く普及させなければならないのです。「XDDP」などで破綻のペースを遅らせ、その間に、体制を建て直す必要があります。ここにおいて私一人ではとても間に合いません。「派生開発 in Japan（仮称）」は、こうした状況を何とか切り抜けたいという考えから計画しているのです。
さらに、単に「XDDP」などによって時間稼ぎをするだけではなく、これを機会に「派生開発のプロフェッショナル」を作りたいのです。21世紀に入って、ソフトウェアの寿命はどんどん長くなっていきます。ソフトウェア規模の増大の他に、コンピュータ言語も長く生き続けていることが背景にあります。「流用」や「再利用」も頻繁に行われるでしょう。「派生開発」の機会がどんどん増えていくはずですので「XDDP」などの出番も増えていきます。そして「派生開発のプロフェッショナル」の出番もますます増えるでしょうし、派生開発で世界をリードすることもできるでしょう。
日本の製造業がこうした「派生開発」の技術に支えられて、スムースに製品開発ができ、新しい製品を計画通りにリリースすることは、製品の競争力という面からも大きな意味を持っています。企業の競争力が高まれば、雇用の方も確保できることでしょう。そして、製造業が元気であれば、それを支えるビジネスシステムや社会システムの需要も増えていくはずです。
資本家は資本を投下する市場があれば良く、それは国内・国外を問いません。とにかく投資手段があれば「利潤」を得ることができます。これに対して労働者が得るのは、労働に対する「対価」であり、そのためにはそこに「労働の場」が必要です。つまり、日本に「労働の場」を残さないかぎり、日本の雇用は守れないのです。1985年のプラザ合意のあと1987年の円高不況から今日まで、機会あるごとに多くの企業が海外に進出し、日本から雇用が失われてきました。経済がグローバル化し、人、物、金の国境が取り払われたことも、雇用の喪失に繋がっています。
日本に「労働の場」を確保するには、日本の企業が競争力を持っていることが条件になります。そして競争力を支えるのは技術力であり、そのような優れた技術を持った人材です。
２０１０年１月
「硬派のホームページ」主催者より
◆◆◆ これまでの巻頭書 ◆◆◆
２００7／０１〜 ２１世紀の品質保証体制の構想
２００６／０１〜 生産性を３０％UPしよう
２００４／０９〜 崩れ始めた日本語の“万里の長城”
２００３／０１〜 仕事を楽しくなるようにしよう
２００２／０７〜 ソフト産業の空洞化に対抗しよう
２００２／０１〜 競争力をつけよ
２００１／０１〜 ２１世紀にどう対応するか
２０００／０８〜 “先送り”のツケ
２０００／０１〜 ２１世紀への準備
１９９９／０３〜 本当の問題
１９９９／０１〜 １９９９年のはじめに
１９９８／１０〜 これから始まること
１９９８／０５〜 金融ビッグバンを迎えて
１９９８／０１〜 １９９８年を迎えて