「プロジェクト推進」タグアーカイブ

「NASAを築いた人と技術」

大規模組織の内部に切り込んだ、一種のマネジメント事例として読みました。NASAといっても構成するセンターごとに生い立ちも組織文化も違うなど、興味深い記述があります。一般の組織運営でも役立つヒントが多数あるのではないでしょうか。

本書付録の組織図
〔本書付録にある詳細な「組織図」(有人宇宙船センター)。クリス・クラフトなどの名が見える〕
【佐藤靖(著)、2007年刊、東京大学出版会】

■天下のNASAだって、ただの人の集まりじゃないかっ
本サイトでは、これまでも宇宙機関に関連する話題を組織・人事的な視点から記事にしてきました(月の記憶ドラゴンフライ-1同-2同-3日本企業はNASAの危機管理に学べなど)。本書は、まさにNASAという組織の分析がテーマです。ただし現在のNASAの話でなく、1950年代後半から1970年くらいまでのアポロに代表される時代が対象です。副題は「巨大システム開発の技術文化」。

遠くからNASAのような組織をぼやっとみている限りでは、一枚板の強固でシステマチックな組織だと思えてしまいます。しかし本書ではまず、NASAを構成する各センター間に相違があることが明確にされています。さらに、ワシントンのNASA本部から持ち込まれる技術手法や送り込まれる管理者が各センターと盛んに軋轢をもたらし、時に変化し、時に挫折する様が丁寧に描かれています。

ようするにNASAといえども、我々の身近にころがっているそこらの会社と同じ未成熟な組織に過ぎないのでしょう。歴史的事実を示して説明されることで、そんな当たり前のことに今さらながら気付かされます。

本書の第1章から第4章で、NASAの4つの異なるセンター(マーシャル宇宙飛行センター、有人宇宙船センター、ジェット推進研究所、ゴダード宇宙飛行センター)についてまとめられています。第5章は日本の宇宙開発機関の話題です。

〔目次〕
序章 未踏技術への陣容
第1章 フォン・ブラウンのチーム学
第2章 アポロ宇宙飛行船開発
第3章 大学人の誇りと試練
第4章 科学者たちの選択
第5章 人間志向の技術文化
終章 システム工学の意味

■あちこちで反発を浴びる「システム工学」
第1章を単純化してみると…
・ロケット技術者の第一人者でありマーシャル宇宙飛行センターをまとめるリーダーとしても長けた能力を持つヴェルナー・フォン・ブラウンらが、
・NASA本部から持ち込まれる「システム工学」の考え方と対峙し、時に猛反発しながらも、
・フォン・ブラウンの卓越した判断力とチームの団結力を背景に、サターンV型ロケット(アポロ打ち上げに使ったロケット)開発プロジェクトを大成功させる。
・ただしフォン・ブラウンが退いた後は、予算縮小の波の中でチームは縮小(消滅?)していく。

第2章については…
・有人宇宙船センターは、ロバート・ギルルース、クリス・クラフトといったリーダーの下で“徒党的”ともいえる組織に成長していたが、
・NASA本部から送り込まれたジョセフ・シェイによって、(それまでとは水と油のような考え方である)システム工学の手法がもたらされ、
・既存メンバーと頻繁に衝突しながらも、有人宇宙飛行のための業務体系化に成功していく。
・アポロ1号火災事故を機にシェイが去ったこともあり、「人的解決」も「システム工学的解決」の要素も持ち合わせた組織作りが進み、アポロの成功につながっていく。

うーむ、概略としては少し下手なまとめ方だったかもしれません。詳細はぜひ本書を読んでみてください。リファレンスが非常に充実していますので、英語の資料にあたることができる方は、もっとずっと多彩な情報にたどり着くかもしれません。他の章でも、それぞれ興味深い記述があります。

■「属人的なノウハウ」と「脱人格化したシステム」
我々もいろいろなチームやプロジェクトに関わっていると、仕事の進め方で大きな違いがあることを経験します。特定の人のリーダーシップに引っ張られるチーム、仲間内ではツーカーで自動的に意図が伝達し事がうまく運ばれるチーム、常に細かく明示的なドキュメントを作ってそれを軸に仕事を進行させるチーム…。チームの仕事の運び方を認識していないと、実力のある人でも全然役に立たなかったり、険悪なチーム構成になってしまったりします。

それでいて、特定の組織文化に染まったメンバーだけで仕事を続け異分子の参加を避けていると、組織そのものが衰退したり、大きな失敗につながったりします。某老舗食品会社の製造日偽装事件など名の知れた企業の不祥事がここのところ次々明らかになっていますが、外部からの異分子が経営に参画していればもっと早く手を打てた事例かもしれません。あるいは異分子にあたる存在が、昨今の事件発覚(ひいては正常化)に一役買っているのかもしれません。

また、プロジェクトの初期に取り決めた仕様や契約がいつのまにか変わっていくことはままあります。状況変化に柔軟に対応できる人がいたからこそ成功したプロジェクト、きっちりドキュメントをまとめることをしなかったために崩壊したプロジェクト、各人の責任範囲を明確化した故に相互補完できず特定の人にしわ寄せがいったプロジェクト…。本書を読みながら、自分の過去の失敗が思い浮かんでくることもありました。

「経営はアートかサイエンスか」は長く議論されているテーマです。本書で使っている用語と少し意味が違うかもしれないことを承知で単純な表現をすると、
「属人的(≒アート的)手法」と「脱人格的(≒サイエンス的)手法」の衝突
が本書の重要な視点といえそうです。

本書については、宇宙開発の分野で有名な技術ジャーナリスト、松浦晋也氏のblogでも紹介されています。ご参考まで。
「NASAを築いた人と技術 巨大システム開発の技術文化」

「RFP入門 ― はじめての提案依頼書」

発注者自らが、求めるシステムやサービスの仕様・条件をドキュメントとしてまとめきるのは、けっこう労力が必要です。

RFP入門・表紙
RFP入門 ― はじめての提案依頼書
【Bud Porter-Roth(著)、渡部洋子(監訳)、2004年、日経BPソフトプレス刊】

■ドキュメント化の重要性
Request for Proposal(RFP)とは、「システムなど何か複雑なものを導入・購買する際に、提供してくれる業者を選ぶため(入札するため)発注者が用意するドキュメント」とでもいえばよいでしょうか。安直な表現をすれば「提案書を書いてもらうためのガイドライン」です。

中小企業や小規模な調達実務を想定すると、業者から提案書さえ受けるとは限らず、場合によると口頭説明と見積書だけで済ませてしまうことも多いものです。提案書を出す前に発注側から「提案依頼書」を出すとなると、「少し大げさ」と感じられる場合もあるでしょう。

でも、特に技術的内容を含む取引では、相互の意思疎通の過程をドキュメントとして残すことの重要性は高いものです。記録として残す習慣があることで、ビジネスの進め方もシステマチックになっていくものと思われます。当ブログの別の記事(※など)で、マニュアル化を重視することで成功したNASAの仕事の進め方について触れました。宇宙に飛ぶロケットや人工衛星となると、それこそ膨大な技術ドキュメントが必要となり、業者の選択では多くのRFPが用意されてプロジェクトが進んでいることでしょう。

「日本企業はNASAの危機管理に学べ」

本書は、RFPの書き方を具体的に説明した実用書です。事務的事項、管理的事項、技術的事項それぞれについて、文書例、必要条件、注意事項などがまとめてあります。本書の事例では、情報システム構築プロジェクトのようなものが想定されています。

■RFPの章立て構成
本書では、RFPの枠組みとして次のような構成例が挙げられています。ただし、以下は本書に書かれている内容そのものでなく、一部を(ブログの筆者である私が)勝手に取捨選択しているとともに、タイトルなど本書に書かれている用語をそのまま使わず“意訳”しています。

[RFPの章立て例] …本書自体の目次ではありません
第1章 概要説明と事務的事項
当社の現状
プロジェクトの背景
提案してもらいたい事項
言葉の定義
提案書の書き方
入札の締め切りと当社の質問窓口
採用決定通知までの手順
第2章 技術的な仕様詳細
プロジェクトの目的と目標
現在のシステムおよび業務の内容
提案書に求められるシステムおよび業務の技術的要件の詳細
機能・性能・業務範囲等に関する条件
第3章 管理面での仕様詳細
現在想定しているプロジェクト計画案
提案書に求められる管理的要件の詳細
(日程、投入する人員・リソース、手法など)
スケジュール全体・納品・保守・文書化等に関する条件
第4章 参加資格
入札に参加できるための条件、資格
第5章 提案者の企業情報
提案書とともに提供してほしい企業情報について
(企業沿革、財務情報、組織人員体制、過去の実績など)
第6章 価格提示のための書式
価格を算出・提示するための明細項目
価格を算出するための注意点説明
契約 契約書(購買契約、保守契約、機密保持契約など)の書式または要件
付録 ワークフローや検討資料、Q&A

中心部分は、第2章と第3章です(本書自体の目次でいうと、第4章と第5章にそれらの説明がある)。「広すぎず狭すぎず、具体的でありながら硬直化していない条件を表現する」ことで、発注者としての意図をきちんと示すことができるでしょう。こうした枠組みと実例が、実際にRFPを書くために参考になると思われます。取引の内容により構成や表現はさまざまであるべきなので「このサンプルのまま使っちゃあかんで…」という意味の注意が書かれていますが、場合によってはここで書かれている実例をなぞるだけでうまくRFPをまとめられるかもしれません。

同時に、読んで試して書いてみるほどに、サンプル文章の言葉の入れ替えだけでは提案依頼書が書けないことも実感できます。こうしたドキュメントをまとめきるには、やはり何度も同様のドキュメントを過去に作った経験がものをいうことでしょう。

■ビジネス・ドキュメントの実用題材に
本書は海外本の訳書のため、直訳したような言葉が多いのが難点です。ビジネスの現場では正直ピンとこない言い回しがけっこうあり、文章の意味を解釈するのに時間がかかることがあります。この本を使いこなすには、書かれている言葉をあらためて実践的な言い回しに頭の中で“翻訳”するステップが必要かもしれません(上に示した[RFPの章立て例]のように…)。

それでも、この種のビジネス・ドキュメントを書いたことがない若手ビジネスパーソンなどにも、構造的なビジネス・ドキュメントの枠組みとか、要件の記述方法とかを学ぶよい題材になると思われます。システマチックにドキュメントを書くことの少ない「ベテラン」より、本書をつてにして構造的に文書を構成しようとする経験不足の若手ビジネスパーソンのほうが、案外良い提案依頼書や提案書を書けるかもしれません。