チームのパフォーマンスを高く保つ手法として、ソフトウェアの開発手法やプロジェクトマネジメントのあり方が応用され始めている。そこで本稿では、数々の企業システム開発のプロジェクトに携わってきた岡 大勝氏に、プロジェクトマネジメントのあり方についてお話を伺う。同氏は、日本を代表するソフトウェアアーキテクトであり、現在は、ZOZOテクノロジーズの開発部で、ファッション通販サイト「ZOZOTOWN」のチーフアーキテクトとして活躍している。

岡 大勝(おか ひろまさ):企業ITの世界に“ダウンサイジング”という破壊的なイノベーションのうねりを巻き起こし、今日の企業ITの基礎を創出したとされる米国ディジタルイクイップメント(DEC)の日本法人や米国ヒューレット・パッカード(現ヒューレット・パッカード・エンタープライズ)の日本法人で、主に金融機関のシステムアーキテクチャ設計/開発プロセス設計/運用プロセス設計を担当。のちに入社した日本ラショナルソフトウェア社では、開発プロセス/オブジェクト指向分析設計手法の導入支援を展開した。2003 年にゼンアーキテクツを設立し、最新技術を業務システムに適用する支援を展開。2019年より、株式会社ZOZOテクノロジーズに入社し、現在に至る。2013年には、日経BP社が選ぶ「日本のトップITアーキテクト」の一人として選出されている。

すべてが計画どおりには進まない

現在、ソフトウェアの開発/プロジェクトマネジメントの手法が、企業のチームパフォーマンスを高める“汎用的な手法”として注目され、非IT系のチーム作りにも取り入れられ始めている。一例が、“米国で最も幸せな職場”とされるソフトウェア開発会社メンロー・イノベーションズ社(以下、メンロー社)のケースだ。

同社は、CEO兼共同創業者のリチャード・シェリダン氏が、“従業員の誰もが働く幸せややりがいを感じられる会社(=ジョイ・インク)”を目指して立ち上げた企業である。チームマネジメント/プロジェクトマネジメントの基底として、1999年に登場したソフトウェア開発手法「エクストリームプログラミング」の考え方を全面的に取り入れ、創業以来、増収増益を続けた。そのチームパフォーマンスの良さが米国の各業界から注目を集め、シェリダン氏は、本業の傍らで、世界屈指の大企業のビジネス会議に幾度も招聘され、経営やチームマネジメントの講義を展開してきたという。ちなみに、シェリダン氏が記した書籍『ジョイ・インク(Joy Inc.)~役職も部署もない全員主役のマネジメント~』(邦訳版発行:翔泳社)は、ハイパフォーマンスなチームをどう組織し、維持するかの指南書として、日本でも話題となった。

「こうしたメンロー社の成功と同社の経営に対する関心の高まりは、世の中の変化を象徴的に物語っているように感じています。その変化とは、あらゆるモノがソフトウェア化していて、何事も計画どおりに進まなくなっているということです。それが、ソフトウェア開発の手法や考え方を、チーム作りやチームの運営全般に取り入れようとする動きにつながっているのだと思います」と、株式会社ZOZOテクノロジーズの岡 大勝氏は言う。

岡 大勝氏
株式会社ZOZOテクノロジーズ
開発部
CHIEF ZOZOTOWN ARCHITECT

岡氏は、外資系大手のITシステムベンダーや開発プラットフォームベンダーでソフトウェアアーキテクトとしてのキャリアを積み、開発言語「Java*」との出会いを一つの契機に、特定のシステムに縛られない環境を求めて2003年にゼンアーキテクツ社を創設。以来、企業に向けて革新技術を業務システムに取り込む支援を展開してきた。2019年から、ZOZOテクノロジーズに参加し、ファッション通販サイト「ZOZOTOWN」のチーフアーキテクトを務めている。そうした過去から現在にかけた経験の中で、岡氏は、ソフトウェアの開発が、物理的なモノの生産とはまったく異質なプロジェクトに変容したことを目の当たりにしてきた。

* Java:1995年にサン・マイクロシステムズ社(現オラクル社)が市場に投入したオブジェクト指向の開発言語。「Write Once, Run Anywhere(一度書けば、どこでも動く)」をコンセプトにJavaで記述されたプログラムは、変更なしに、あらゆるOS上で動く世界を目指した。今日では、企業システムの多くがJavaで記述されている。ちなみに、“ジョイ・インク”のリチャード・シェリダン氏も、Javaに衝撃を受け、Javaとエクストリームプログラミング手法をベースに、ソフトウェア開発の実験場「Java工場」を前の会社で創設した。その工場がメンロー・イノベーションズ社の原形となっている。

「かつてのソフトウェア開発は、物理的なモノを作り上げるのとまったく同じように、あらかじめ仕様を固めて、資材を調達し、決められた品質のソフトウェアを、計画どおりに仕上げるのがすべてでした。ただし、そのような時代はとうの昔に過ぎ去っています。ソフトウェア開発の世界には、“完了”や“完成”という概念はすでに存在しません。刻々と変化するビジネスニーズや進化するテクノロジーをダイナミックに取り入れながら、恒常的に発展させていくことが求められています」(岡氏)。

こうした中では、綿密な計画を練り、その計画どおりに物事を進めようとする意味はほとんどなくなり、結果的にプロジェクトマネジメント(以下、プロマネ)が追求すべきことも大きく変容しているという。

「今日におけるソフトウェア開発では、事前に決めた計画や仕様が足かせになって、新しく登場した革新技術が使いたくても使えないといったことが起こりえます。ゆえに、綿密な計画を立てて、計画どおりに物事を進めることは、開発チーム活動の価値でもなければ根本思想でもありません。そのため、開発プロジェクトをマネージすること──要するに、プロマネの本質的な意義も従来とはまったく違ってきているんです」(岡氏)。

上意下達のマネジメントでは一歩も前に進まない

岡氏によれば、ソフトウェアを物理的な生産物と見なし、計画ありきでプロマネを遂行しようとするやり方は、18世紀末の産業革命に端を発し、20世紀の大量生産・大量消費時代へと連なる「産業時代」のなごりであるという。

同氏の言う「産業時代」とは、米国の未来学者アルビン・トフラー氏が約40年前(1980年)に記した著書『第三の波(The Third Wave)』の中で言及されている言葉だ。この著書でトフラー氏は、「農業革命(農耕時代)」「産業革命(産業時代)」に続く“第三の波”として情報革命が引き起こされ、それによって情報化社会(情報時代)が訪れると予見していた。

「トフラー氏が予見した情報化社会は、高度に発達した情報網(ネットワーク)によって、地理的場所を問わず瞬時に価値がやり取りされる世界のことです。そして今日、世界はトフラー氏が予見したとおりの情報時代に突入し、開発したソフトウェアの価値が、インターネットを通じて世界70億人にリアルタイムに届けられるようになっています。そんな情報時代にありながら、ソフトウェアを物理的な生産物のように扱い、一定の生産計画に沿って分業体制を組み、エンジニアを歯車のように動かそうとするマネジメントは、産業時代の発想から抜け切れていない前近代的な行為と言えます」(岡氏)。

ならば、情報時代のプロマネのあり方とは、具体的にどのようなものなのか──。この問いかけに対して、岡氏は、「まずは、プロジェクトチームをマネージ(管理)するという考え方自体を捨てるべきです」と答え、次のように続ける。

「チームを管理するという考え方には、プロジェクトのマネージャーが、チームの誰よりも優れているという発想が根底にあります。ただし、技術の変化・進化が目まぐるしい今日では、過去の経験はほとんど役に立ちませんし、マネージャーが、あらゆる領域のソフトウェアテクノロジーに関して“全知全能”であることなど絶対にありえません。むしろ、正しい知識や役立つスキル/ノウハウは現場で働く個々のエンジニアにあり、彼らの活動を管理するのではなく、それぞれが自らの判断で臨機応変に動ける環境を整えることが大切です」

こうしたチームの動かし方は、プロのサッカーチームを組織し、機能させるのと同じであると岡氏は説明する。

言い換えれば、ソフトウェア開発のプロジェクトマネージャーは、プロサッカーチームの監督のように、試合(プロジェクト)が始まったら、チームのメンバーを信頼し、すべてを委ね、道からそれそうになったメンバーの軌道を微修正してあげるだけでいいという。

「それと真逆のマネジメントが、“産業時代”の考え方をそのままに、チームの意思決定や動きを上意下達で完璧にコントロールしようとすることです。このようなマネジメントを行おうとしたとたんに、ソフトウェア開発は一歩も前に進まなくなります。そもそも、サッカーチームには上司も部下もなく、一人ひとりが、自己判断の下で、さまざまな局面を打開し、チームの勝利に貢献しようとします。開発チームもそうあるべきで、予測不能な変化の中で、プロジェクトを前に進める推進力はそのようなチームによってもたらされるのです」(岡氏)。

また、サッカーチームのように個々のメンバーがそれぞれの判断で臨機応変に動ける環境を築くうえでは、メンバーごとの作業に依存関係のない“疎結合”の状態を作り上げるのが理想であり、そのためにはメンバーが携わる物事の構造もまた“疎結合”型でなければならないという。

ソフトウェアの世界では、構成部品(コンポーネント)同士が密に結合している構造のことを“モノリシック”と呼ぶ。こうした構造のソフトウェアは、例えば、“ハンドル”を変えただけで、“エンジン”の仕様までを変化させる必要が生じるような自動車と同じで、機能の変更・追加を柔軟性に行うことができない。

「このような構造のソフトウェアの開発を任されたチームは、各メンバーが個々の判断によって自由に動くことができません。要するに、特定のコンポーネント開発を担当するエンジニアが、当初の予定にはない新技術を取り込みたいと考えても、他への影響の大きさから、即断即決で実行に移せなくなるわけです。ですから、サッカーチームのような、個々人が自走できるチームを組織し、それによって変化への対応力を高めたいと考えるなら、チームが携わる物事の構造も疎結合型である必要があるのです」(岡氏)。

プロジェクトの本質的な目的と価値の共有

もっとも、プロのサッカーチームにも、強いチームと、そうではないチームがあり、構成メンバーが変わらずとも、監督が変わるだけでチームが強くなることもある。とすれば、サッカーチームのようなプロジェクトチームを率いるうえでもパフォーマンス向上につながる重要なポイントがあるはずである。

その要点について、岡氏は、「何よりも大切なのは、プロジェクトの先にある最終的な目的(オブジェクティブ)を明確に示して、メンバーの理解・共感を得ることです」と語る。

同氏によれば、プロジェクトは、プロジェクトを遂行すること自体に目的があるわけではなく、その先にある複数のオブジェクティブを目標とした活動のひとつがプロジェクトである、という考え方だ。例えば、ZOZOTOWNのようなeコマースサイトの開発であれば、そこには、最高の顧客体験、会社の収益増、保守や拡張しやすい先進的なアーキテクチャ、自律的な開発組織、などといった目的があるという。

「ですから、プロジェクトを率いる立場の人は、そうしたプロジェクトのオブジェクティブを明確に掲げて、メンバーとの対話を重ねながら、共感してもらうことが重要だと考えています。それによって、チームの各人はプロジェクトに自分なりのやりがいを感じ、かつ、その目的の達成に向けて、自分が何をすべきかをしっかりと理解し考えてくれます。そうなれば、あとはチームを信頼して任せることで、それぞれの知見やスキルを活かして、チームとして自律的に動いてくれるようになるんです」(岡氏)。

また、失敗を怖れず、隠さず、それを糧にできる風土をチーム内に作り上げることも成功の要件であると、岡氏は続ける。

「日本の組織は、伝統的に失敗に不寛容で、失敗を強度に怖れたり、失敗を隠そうとしたり、失敗を失敗と認めようとしなかったりする傾向が強くあります。そのため、計画からビジネスの立ち上げまでにやたらと長い時間をかけ、仮に、それが失敗しても、なかなかそれを認めようとせず、取り返しがつかなくなるまで失敗した取り組みを続けるといった事態に陥りがちです。ソフトウェア開発に限らず、いかなるプロジェクトにおいても、そのようなことはあってはならないことでしょう。ですから、物事を小さく始めて、幾度でもやり直しがきく早い段階で失敗を繰り返し、それを糧に成功へと結びつけていくことが、プロジェクトの正しいあり方であり、リードの仕方と言えます」

エンジニアの能力でパフォーマンスに1,000倍の開きが出る

加えて、もう一つ、優秀な人材を集め、その知見と判断を尊重し、能力を発揮してもらうこともプロジェクトの成功には不可欠であるという。

これは、当然のことのように思えるが、ことソフトウェア開発に限って言えば、エンジニアが優秀かどうかでチームのパフォーマンスに極端な開きが出ると、岡氏は指摘する。

「実のところ、“スーパーエンジニア”と平均以下のエンジニアとでは、パフォーマンスが1,000倍から1万倍近い差があります。例えば、平均以下のエンジニアが苦労して記述したプログラムで2時間以上かかっていた処理を、スーパーエンジニアが少しの手直しで0.1秒に短縮してしまうようなことも珍しくありません。米国のIT企業はその違いを分かっているので大リーガー並みの報酬でスーパーエンジニアを獲得しようとしますが、日本のIT業界は遅れを取っていると言わざるを得ません。それをいきなり変えるのは無理だとしても、優秀なエンジニアはもっと正当に評価されるべきですし、エンジニアの能力の違いでパフォーマンスが劇的に変わるという認識をIT業界全体がより強く持つべきです」

岡氏によれば、日本のIT企業の中には、エンジニアが優秀かどうか、提供する価値がどうかではなく、単純な人月単価でシステム開発を請け負うところが依然としてあり、こうした企業とユーザー企業のニーズとのかい離も激しくなり始めているという。

「開発費を人月で算定するというのは、エンジニアの仕事の価値を労働時間の長短でしか測れない、あるいは表現できない産業時代の考え方の企業だと言えます。そのような会社は、優秀なエンジニアを集めることも、つなぎとめておくことも困難と言わざるをえません。また、こうした企業は大抵、官僚的で組織階層が深く、ソフトウェア開発においてもトップダウン型の管理に固執します。そして、マネージャー層の過去の経験則と知識に頼ってプロジェクトを回そうとします。結果、古くなった知識と技術で新しいシステムを作ろうとしてしまい、ユーザー企業から“革新的なシステムを作って欲しいのに、一体、何年前の技術を使っているんだ”と見放されてしまうわけです。今日は産業時代ではなく情報化時代です。そろそろその変化に気づき、開発のあり方、組織・チームのあり方を今の時代にマッチしたものへと大きく転換する必要があるのではないでしょうか」(岡氏)。

This article is a sponsored article by
''.