Pivotal Lab、ソフト開発にはプロジェクトマネージャーではなくプロダクトマネージャーが必要
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/6570_main.jpg?itok=Df9ZOovl)
![Pivotal Labのレセプション。コーポレートカラーの緑色](/sites/default/files/657001.jpg)
図1: Pivotal Labのレセプション。コーポレートカラーの緑色
EMC連合の企業としてPivotalといえばCloud FoundryというPaaSの開発元として有名なのかもしれないが、実際にはエクストリームプログラミングやペアプログラミング、そしてDevOpsを実践している企業なのはソフトウェア開発を行っているエンジニアには有名なことだろう。Pivotal LabはPivotalの中でアジャイル開発、ペアプログラミングを啓蒙するトレーニングの場として広く企業に門戸を開けている。そんなPivotal Labのサンフランシスコオフィスを訪問して、DevOpsを実践するコツをきいてみた。
今回、対応してくれたのはアソシエイトディレクターオブエンジニアリングのジェーアール・ボイエンス(JR Boyens、Associate Director of Engineering)氏だ。
![ヒゲ、メガネ、チェックのシャツ、ちょっと肥満気味。オタクの見本のようなボイエンス氏](/sites/default/files/657002.jpg)
図2: ヒゲ、メガネ、チェックのシャツ、ちょっと肥満気味。オタクの見本のようなボイエンス氏
まず最初にPivotal Labのオフィススペースをツアーして一番驚いたのが、ソフトウェア開発の現場なのに「静かではない」こと、そして次に「デスクが区切られていない」ことだ。今回、GitHubやAppDynamics、SurveyMonkeyなどの本社を訪問して気付いたのはどこもエンジニアが長いテーブルを使って席に着き、各人がパーティションで区切られていないこと。だが何よりもPivotal Labの現場は言ってしまえばもっと「ざわざわとうるさい」のだ。この理由はあとで明らかになる。そして当日行われていた勉強会のスペースも壁で区切られているわけではなく、エントランスのすぐそばにあるキッチンも同様に区画分けされていることもなく、全てのスペースが連続体のようにつながっている。もちろん、個別のミーティングルームはあるのだが、プログラマーは広いスペースにテーブルとイス、それに液晶モニターが島となって並んでいるところで作業するのだ。そして当然ながら全員がカジュアルな装いでリラックスして開発を行っていた。
勿論、定番のピンポン台もあるし、キッチンはご覧のとおりの大きさだ。
![ピンポンはリフレッシュには最適](/sites/default/files/657003.jpg)
図3: ピンポンはリフレッシュには最適
![キッチンはいつでもエネルギー補給を行えるようにするために非常に重要](/sites/default/files/657004.jpg)
図4: キッチンはいつでもエネルギー補給を行えるようにするために非常に重要
以下、ボイエンス氏との質疑応答。
ーーー何かソフトウェア開発の現場なのにざわざわとうるさいんですね?ちょっと驚きました。
そうです。ここではペアプログラミングが行われているから、二人のプログラマーが隣同士に並んで座っています。だからよく見ると2つのモニターに映っている画面は同じです。それを見ながら二人でコーディングを行います。勿論、コーディングだけではなく確認や意見を伝えるために頻繁に会話をしています。なのでちょっとうるさく感じられるのかもしれません。ペアの人が会話するのはとても大事でそれを聞いたチームのメンバーが会話に参加したり、その会話を聞いて理解を深めたりする機会を作っている、ということですね。ペアは毎日、入れ替えを行いますので、コードの中身をチームメンバー全員が理解をするということに役立っています。
———なるほど騒がしいわけが分かりました。ひとつのチームには何人ぐらい居るのですか?
それは開発するソフトウェアによって違いますが、だいたいは4名から8名というところです。そのメンバーで通常は3か月程度、このラボの中で開発を行います。朝から晩まで余計なことはせずに開発に集中できます。キッチンもあるので、外にランチに行く必要もありません。朝から食べ物は用意されていますし。勿論、外にランチに行くこともできますよ(笑)。それに余計なミーティングも極力排除しています。
![オフィスの様子](/sites/default/files/657005.jpg)
図5: オフィスの様子
ーーーここではエクストリームプログラミング、ペアプログラミングを学ぶ場所だと思いますが、座学的に行うのではなくあくまでも作るべきソフトウェアを持ち込んでPivotal Labのスタッフと一緒にやってみるというスタイルなのですか?
そうです。座学で学ぶのではなく一緒に実践するわけです。テストを書いて、コーディングを行い、テストを通す、その繰り返しです。テストを書いてからコーディングをするのは単に品質を上げるためだけではありません。ある仕様を実装する時に必要最小限のことをやる、つまりテストの通りに動くことだけをコーディングする、テストが通ればそれでその実装は終わり。これだと余計なことを実装することがなくなります。約3か月をこのスタイルでやってペアプログラミングを実践して身に付けてもらうということですね。
ーーー実際にはここの参加者が自分の所属する企業に戻った時にそのままペアプログラミングを続けられないかもしれませんよね?
それはその通りです。それはこちらでは何ともできませんね(笑)。ただプログラマーはここでの経験からこのスタイルが上手く行くことを実感するはずです。だいたいここを経験した人がこれを続ける割合は半々といったところかもしれませんけども。
ーーープログラマーはここの経験からペアプログラミングの効果を実感すると思いますが、中間管理職の人はどうでしょう?実際には日本のIT部門はプログラマー出身ではない開発部門のマネージャーがいることもありますが。
実際にはトップの経営者の人の理解のほうが早いのです。つまり数値で判断することに慣れている人たちはこのスタイルの効果を数値でみて即理解します、それにプログラマーも実体験として理解してくれます。中間管理職のマネージャーにとっては、二人一組でプログラミングを行うために人員が半分になる!という過激な反応をする人もいますし、ちょっと理解するのは難しいかもしれませんね(笑)。ただ、Pivotal Labにはスタッフを管理するだけの専門職と言う人はいないのです。各チームには4~8名のプログラマーがいて、その中にプロダクトマネージャーがいます。その人はプログラミングだけではなく約10%程度の時間を管理に充てていると思います。
![各人のスペースは狭く、日本のオフィススペースとも変わらない?](/sites/default/files/657006.jpg)
図6: 各人のスペースは狭く、日本のオフィススペースとも変わらない?
ーーープロダクトマネージャーというのはプロジェクトマネージャーとは違うのですか?
そこはとても重要なのでちゃんと説明しますと、全てのチームにはプロダクトマネージャーがいます。それはどんなに小さなソフトウェア開発でも、巨大なソフトウェアの開発でも同じです。プロダクトマネージャーの仕事はそのプロダクト、つまり開発するソフトウェアのオーナーとして成果物に責任を持ちます。つまりこれは私が作って欲しいと言ったソフトウェアかどうかを最終的に判断する人、です。プロジェクトマネージャーは「プロジェクト」を管理しますが、ここでは「プロダクト=成果物」を管理するのです。そのソフトウェアを開発し始めた1日目からその日の成果を確認して、これで良いかどうかを判断する、それの繰り返しです。小さな繰り返しを積み重ねていって最終的にソフトウェアを完成させる、その繰り返しなのです。
ーーーそのスタイルだと小さなソフトウェアの場合は、問題無いのかもしれませんが、例えばオペレーティングシステムなど巨大なソフトを開発する際はどうするのですか?
その場合もまず全体の仕様を考えるプロダクトマネージャーがいて、その全体から機能を細分していきます。それを個々のチームに割り振る、それを開発して毎日成果を確認する、その繰り返しなのです。このやり方だと「仕様が決まって6か月間、何も出てこないのに突然出てきた訳の分からないアルファー版ソフトウェア」に頭を抱える必要がありません。実際にCloud Foundryもそのようにして開発されています。
ーーー日本ではまだ開発部門は外部、運用部門は社内というように分断されていることが往々にしてありますが、DevOpsが必要であることを経営層に理解してもらうためにはどうしたらいいんでしょう?
現在のWebシステムというのは非常に多くのサーバーで成り立っています。例えばGoogleには数えきれないくらいのサーバーが稼働していると思いますが、それらを人手で管理運用しようとすれば、凄まじい数の要員が必要になりますが、それは現実問題として不可能です。ですからGoogleがやっていることは徹底的な自動化なのです。アプリの開発から本番環境への実装も自動化しようとすると開発と運用も同様に連続的に自動化するしかないのです。その結果、運用の人であってもプログラミング、つまりソフトウェアによる自動化が必須になります。実際には運用の人間が全く要らなくなるわけではなく、やるべき仕事が変わるだけなのです。
ーーーつまりGoogleのようなシステムを作ろうとすれば、DevOpsは必須である、ということですね。
Googleとまでもいかなくてもソフトウェアがこれからのビジネスに重要になることはみなさん分かってますよね(笑)。
-----
前回、ケンブリッジのEMCのラボに訪れた時はまだ稼働前ということだったが、今回のサンフランシスコのラボは今まさに全速で回転しているという様子だった。近日、日本でもPivotal Labがオープンする予定もあるそうで、オフィスのレイアウトにも相当気を遣っていると語っていた。日本でのラボがオープンした際には再度、取材をする予定だ。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- 「Pivotal Labsで作っているのはソフトウェアではなくてチームです」 東京オフィスのダイレクター、ダニー・バークス氏に聞く
- CNDO 2021、マイクロサービスへの取り組みをツールではなく手法からアプローチするセッションを紹介
- Red Hat Summit 2017 CEOのJim Whitehurst氏がOpenShiftを語る!
- チーム開発を円滑にするための必須ツール
- Cloud Foundry Summitはエコシステムの拡がりを感じるカンファレンス
- PivotalとGoogleによる「クラウドネイティブのススメ」
- Cloud Foundry FoundationのCTOが語る「Cloud Foundryの強さは数よりも品質」
- GitHubのCEO「世界中の全ての人がプログラマーになれること」が究極の目標
- Pivotalの強みはビッグデータ分析とアジャイル開発のタイトな連携
- youRoomとPivotalTrackerではじめる無駄のないコミュニケーション