備考欄に感想を書くタイプのエンジニア

それで出世が遅れ(ry

TX 本始めました

私は TX 業界で生業を行っているわけではないので、TX 本と言えばアレみたいな共通認識があるのかすらよく知りませんがこれです。

Transactional Information Systems: Theory, Algorithms, and Practice of Concurrency Control and Recovery (The Morgan Kaufmann Series in Data Management Systems)

この本のことを知ったのはもう4年も前のことで、きっかけは TX本勉強会終了 に書いてあったこれです。

TX本は、ミドルウェアやDBAでトップ・エンジニアを目指すのであれば、是非挑戦されることを勧めます。内容・難易度ともにS級クラスであることは保証させて頂きます。トップ・エンジニアではなくても、エンジニアであれば、いつかは挑戦を志してほしいですね。 それだけのテキストです。(強調は筆者)

これを読んだ当時私は SIer の端くれで、比較的実務に直結しやすい技術書は読む一方で、論文の類やを読んで楽しむ習慣はまだなく、まさにエンジニアとして挑戦してやろうと思いこの本を手にし、以降何度か読破に挑戦するもののあえなく撃沈ということを繰り返していました。今回は、これまでのように暇を見つけてドバっと読むのではなくて、少量(2,3 ページ程度)をルーチン化(平日は毎日)して隙間時間を利用して読んでいく手法に作戦を変更したところ、現時点で1か月弱続けることができているので、このままうまくいくといいなと思いながら読み進めています。

当時、というかつい最近まで 800 ページを超える鈍器を抱えて読むしかなかったと思うのですが、いま Amazon でこの本を探すとなんと Kindle 版なるものがいつの間にか出ています、すばらしい。

論文紹介: In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか

※これは システム系論文紹介 Advent Calendar 2016: ADVENTAR 1 日目の記事です。

昨今話題に事欠かない In-Memory DBMS ですが、暇に任せて Hekaton 関連で何か(←忘れました)を調べていたときに出くわした論文がこちらです。タイトルは

Larger-than-Memory Data Management on Modern Storage Hardware for In-Memory OLTP Database Systems

一応和訳しておくと In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか、という感じでしょうか。

先に結論を言うと後述する通り、今日では HDD だけではない、さまざまなストレージ技術を利用したストレージデバイスが利用可能で、それらをメモリの外の二次ストレージとして利用するときには、それぞれのストレージにとって最適な利用方法があり、その方法いかんでパフォーマンスが何倍にも向上したり、逆にかなり落ち込んだりします、ということを検証、考察したのが本論文の主な内容になります。

知っておくとよい予備知識

ご覧の通り、知っておくとよい予備知識を並べただけで読まないといけない文章(英語論文含む)が積もってしまって大変なことになってしまうのですが、これらの知識なしに上述のような論文に記述されている結論を読んでも「ふーん、まぁそうだよね…。」ぐらいの感想しか出てこないかと思うので、背景まで含めて読んでいただくとよりよいかと思います。

ストレージ関連で言うと、メモリのサイズを上回るデータを退避させる対象の二次ストレージとして、おなじみの HDD や NAND ベースの SSD の他に、次のようなストレージが本論文中で挙げられています。あと、NVRAM は non-volatile RAM、つまり不揮発性ランダムアクセスメモリについても言及があります。

ストレージ関連

一方、in-memory DBMS に関しては以下の DBMS が言及されています。最初に MongoDB のリンクを置いたのは、1章で仮想メモリにアクセスした際にアクセス対象のデータが物理メモリ上になくページフォールトが発生し、トランザクションのパフォーマンスに影響が出る最近の例として挙げられていたためです。具体的に言うとメモリ管理に MMAPv1 を使っている Ver. 3.0 以前の MongoDB です(Ver. 3.0 以降は Storage Engine として WiredTiger を選択できるため改善が可能です)。

DBMS 関連
その他

論文の概要

in-memory DBMS は OLTP のワークロードの処理において、従来のディスクストレージの利用を前提とした DBMS よりも遥かに優れた性能を発揮しますが、それは現状扱う対象のデータベースのサイズが物理メモリよりも小さい場合に限られています。その制約がボトルネックになることを回避するための方法として、アクセス頻度の低いデータをメモリに留めておくのではなく、二次ストレージに退避させることで、物理メモリをアクセス頻度がより高いデータの処理により多く割り当てようという考え方があります。

この論文では、では具体的にどういった方法でデータを二次ストレージに退避させるのか、退避させたデータをどのようにメモリに戻すのかということ、それに加えて HDD やそれ以外のストレージデバイスを二次ストレージとして利用するときにそれらがパフォーマンスにどのような影響を与えるのか、そういった包括的なデザインをどのように決定し構成すればいいのかということを5つの異なるストレージテクノロジーを採用したストレージデバイスを用いることで評価しています。

評価の対象ストレージデバイ

in-memory DBMS の一つである H-Store DBMS に対して以下の5つの異なるパフォーマンス特性を持つストレージデバイスを二次ストレージとして利用します。

  • HDD、いわゆる従来型の磁気記憶装置。昨今は SMR(後述) や PMR(Perpendicular Magnetic Recording, 垂直磁気記録方式) 特別するために CMR(Conventional Magnetic Recording) と呼ばれることもあるようです
  • SMR HDD、瓦記録あるいはシングル時期記録方式と呼ばれる記録方式を採用した HDD
  • NAND ベース SSD、いわゆる普通の SSD
  • 3D-XPoint、2層のクロスポイント構造を用いた大容量メモリ。今回はそれと同様の技術を用いたエミュレーター利用します
  • NVRAM、不揮発性ランダムアクセスメモリのこと。これには PCM(相変化メモリ)、メモリスター、STT-MRAM(スピン注入磁気反転型磁気メモリ)を含んでいます

DBMS 側のコールドデータの扱い方に関する方針(ポリシー)の説明

まず、ホットではないデータを二次ストレージに退避させるために、DBMS が何らかの指標をもとに退避させるデータを特定する必要があります。本論文中ではその方法として H-Store DBMSApache Geode が採用しているオンラインのアプローチと Siberia や VoltDB が採用しているオフラインのアプローチの2つについて説明しています。簡単に言うと、オンラインのアプローチでは LRU (Least Recently Used) アルゴリズムに基づいたリストを管理し、もっともアクセス頻度が少ないデータを二次ストレージに退避させます。一方オフラインのアプローチでは、データへのアクセスをログに残し、別の専用スレッドでこのログからアクセス頻度を解析し、どのデータがコールドなのかを特定します。

次にデータを退避したという情報をどういう手段でメモリに保持しておくのかという問題に対し、H-Store DBMS、Hekaton、および VoltDB が採用しているそれぞれの方法について説明していますが、詳しくは H-Store に関しては H-Store 公式のアンチキャッシュに関するドキュメント、Hekaton については、すでに紹介済みの Trekking Through Siberia: Managing Cold Data in a Memory - Optimized Database あたりを確認しておくとよいと思います。

二次ストレージへのアクセス方法とその方針(ポリシー)の説明

次の章ではコールドデータストレージに採用されているテクノロジーに密接にかかわるポリシーとしてコールドストレージへのアクセス方法とその方針について大きく以下の3つの観点から説明しています。

  • コールドな状態のデータをどのように取得するのか
  • どのような状況でコールドデータをメモリにマージするのか
  • ブロック単位でのアクセスとバイト単位でのアクセス

より具体的な手法については、その次の実験解析の章でそれぞれのストレージデバイスに対していくつかの条件ごとのパフォーマンスを計測するという形でこれらのポリシーの決定がパフォーマンスに及ぼす影響について検証を行っています。

実験解析

H-Store DBMS が構成された dual socket の Intel Xeon E5-4620 2.60GHz(ソケットあたり 8 コア)の CPU と 432GB の DDR2 RAM を搭載しているマシンに各種二次ストレージを接続し、それぞれ前項の観点からパフォーマンスを計測しています。詳細は論文を見ていただいたほうがいいかと思いますが、取得するデータブロックのサイズや取得方法、アクセスパターン分布の違いが各ストレージデバイスの特性を露わにし、特性に応じたパフォーマンスを出していることがわかるかと思います。また TPC-C を利用したベンチマーク結果の他に Voter や TATP といったベンチマークの結果を見ていると、NVRAM のパフォーマンスが DRAM に迫っている様子が見られます。一方で、処理内容に対して適切な構成を行わずにただレイテンシーの低いストレージを使っても、それこそ最適化された HDD ほどにもパフォーマンスが出ない状況もある、ということがわかります。

関連する研究

今回実験をするにあたって利用した H-Store DMBS が採用しているアンチキャッシュというアーキテクチャですが、これはメモリ上にあるデータをディスク上にキャッシュすることに反する、つまりより多くのデータをメモリに最適化された状態でメモリ上に保持しつつ、ディスクをデータのホストとしてではなく、アクセス頻度がほとんどなくなったコールドデータ用の拡張ストレージとして利用するアーキテクチャです。他方、キャッシュするということは一般的に、パフォーマンスを向上させるためにディスクのデータをメモリ上にキャッシュするという意味になります。このアーキテクチャは OS における仮想メモリスワップと同じような考え方にもとづいて実装されているとのこと。

本論文では、H-Store DBMS を利用していたためか、上記の実際の動作について多くの説明がこの章でなされていますが、同じ in-memory DBMS でも Microsoft の Siberia や VoltDB (EPFL のカスタマイズ済み)、Apache Geode、MemSQL 等それぞれ異なったポリシーのもとに異なった実装でコールドデータを扱っていることにも触れており、それぞれがどのように違うのかという興味をそそられます。

結論

実験の結果として、採用しているストレージ技術が異なったハードウェアデバイスを利用する場合にはそれぞれに適した構成を DBMS 側で実施することで、いわゆる既定値のような構成でデータ処理を行った場合と比べて3倍以上のパフォーマンスの改善が見られるということがわかったと結論づけています。あと、私が個人的に実験解析の章で NVRAM のパフォーマンスが DRAM のパフォーマンスに迫っている状況を見て驚いたのですが、それは執筆者も同じだったようで、論文のくくりとしてそのことに言及していました。

感想

たまたまこの論文を見つけたときにはなかなか面白い論文だなと思っていたのですが、参考文献を読んだり同じようなキーワードで検索したりすると同じような研究があちこちでされており、ある意味でホットな話題なんだなという印象を受けました。論文の内容自体もそうですが、予備知識の方で列挙した内容についても極めてハードウェアと関連した事が多いです。DBMS のチューニングはするが DBMS が利用するストレージで採用されている技術のことなど知らない、と言うことは簡単ですがその結果、単にそのことを考慮しないだけで安易にデータ処理のパフォーマンスを1/3以下にしてしまうことになりかねないということを今後の DBMS の設計に関して言えばよく理解しておく必要があるなと思います。

余談で本論文では話題になりませんでしたが、in-memory DBMS といえば他に Oracle の TimesTen や SAP HANA、MIT の Silo、CWI の MonetDB などがありますし、包括的に現状を理解するのであればこれらに関しても同じように学習しておく必要がありますね。

Exchange 2013 CU6 以降の Workload Management の扱い方

先日、これと似たような出来事にでくわしまして。

FIX: Mailbox migration from Exchange Server 2007 to Exchange Server 2013 is very slow

トラブルシューティング等紆余曲折あった中で上の KB と Workload Management の話が出てきて、そういえば Workload Management のポリシーを管理する PowerShell のコマンドがあったんじゃなかったかなと、調べてみたところ…

The -ResourcePolicy, -WorkloadManagementPolicy and *-WorkloadPolicy system workload management cmdlets have been deprecated. System workload management settings should be customized only under the direction of Microsoft Customer Service and Support. ―Exchange workload management

いつの間にかなくなっていました。実際には CU6 からなくなっていたようで、つまり2年以上前になくなっていた(現在は CU14)わけなのでした。普段使うようなコマンドじゃないので全然気が付きませんでした。

じゃあ、CU6 以降、Workload Management (ポリシー)はどうやって管理するのかというと、上の引用にある通り Microsoft サポートが状況を鑑みて必要と判断できるときに方法をお伝えします、という感じでしょうか。ところが話にはもう少し続きがあって、ちょうど CU6 以降から追加されたのが次の PowerShell コマンドなのですが、

  • Get-SettingOverride
  • New-SettingOverride
  • Remove-SettingOverride
  • Set-SettingOverride

冒頭でリンクを張った KB 内にも記載があるように New-SettingOverride-Component パラメーターに WorkloadManagement という引数がありまして、Workload Management の既定の設定内容を変更できるようになっています(もちろん引数はほかにもあります)。

しかし、これらのコマンドで Get-Help してみると、出力された SYNOPSIS 欄(日本語だと概要?)に Microsoft のサポートから指示があった場合に使ってください、という旨の記載があります。実際 Exchange 側で設けている閾値を大きく変更する(または無効化する)ことにもなりますので、用法・用量を守って正しくお使いください。

ちなみに Microsoft は上述の方針を変えるつもりはないようで、公式にこれらのコマンドのリファレンスになるウェブサイトはリリースから2年以上たった今でも見当たりません。もっとも CU11 以降は閾値がより適正な値(十分に大きい、つまり閾値ボトルネックにならないレベルに大きい閾値)に変更されたようで、Workload Management のポリシーを規定値から変更する必要というかそんな機会はほとんどやってこなさそうではありますが、掘るといろいろ出てきそうな部分でもあります。

最近学んだこと: CasperJS を利用して Amazon での買物を自動化する

ここ1週間ほど、ウェブサイトのテスト目的で CasperJS を利用していて、せっかくなので公開できるレベルのコードもなにか書いておこうと思ったのでした。とは言え、特定のウェブサイトに対するテスト スクリプトなんて一般化して公開できないので、なぜか CasperJS で Amazon で買い物する動作をコードにしました。

※後述のコードは 2016 年 6 月時点での Amazon.co.jp のウェブサイトのナビゲーション要素を利用している都合上、ウェブサイトの構成が変わったり刷新されたりすると使えなくなります。

したこと

PhantomJS と CasperJS をインストールする

実行環境は以下の通りですが、wget する場合に Bitbucket を利用する例がネットに散見されるものの、どうも現在何らかの理由で使えないようなので、こちらを使うと良さそうです。CasperJS は公式にあるように $ git clone git://github.com/casperjs/casperjs.git しました。

環境
  • OS: Amazon Linux AMI release 2016.3
  • PhantomJS: 2.1.1
  • CasperJS: 1.1.1

コードを書く

書きました。

変わったところと言えば、注文する商品がアルコールを含む商品扱いされているため、[注文の確定] をする際に

[お客様の年齢確認をさせていただいております。: 20歳未満のお客様の酒類の購入や飲酒は日本の法律により固く禁じられています。お客様が20歳以上の場合は、このチェックボックスをクリックしてから注文を確定してください。]

というチェックボックスにチェックを入れないと [注文を確定する] ボタンをクリックできないところでしょうか。要素名が name="wineNotice" っていうのが面白いですね。

その仕組みを覗いてみると、上記のチェックボックスtrue または false に応じて [注文を確定する] ボタンの span class="a-button a-button-primary continue-button place-order-button-link a-button-span12" style="display: none;"span class="continue-button-blocker a-button a-button-primary a-button-disabled a-button-span12" style="display: inline-block;" の部分が入れ替わって、ボタンが有効化されたり無効化されたりしている都合上、waitForSelector() でクリックできるようになるまで待ってあげる処理が必要でした。display: none;/inline-block; の部分で判定する方法もありかなとは思います。

ちなみに、この処理というか注文フローは全世界共通かというとおそらく違っていて、例えばアメリカだと州によって法律が違うことから、アルコールを含む商品を注文する場合、注文の初期の段階で州を選択しないとカートにも入れられないという状態でした。つまり、このコードの汎用性は非常に乏しいです(かなしみ)。

ところで、コードとは全然関係ない話ですがこのスクリプトで注文しているノンアルコール ビール「龍馬 1865」は、麦芽とホップだけで作られていてノンアルコール ビールなのに結構ビール味であり、しかも他の大手が作っているノンアルコール ビールのように甘味料が入っていない事もあって、ある種のもったりした後味もないのでおすすめです。サントリーのオールフリーなんかは最近のリニューアル後だいぶおいしくなった印象ですが、この龍馬 1865 と比べるとまだまだですし、すべて個人の感想です。

次にしたいこと

  • サーバーレス

    上述の通り、現状では CasperJS の実行環境を EC2 上に構成しているのですが、たったこれだけのために t2.micro とはいえ EC2 インスタンスを起動しているということと、せっかくなのでスケジュールも組み込みたい、ということで Amazon Lambda に組み込めないかなと考えています。

  • Readable Code

    画面遷移数で言うとたったの4ページほどのことなのですが、なぜか Amazon のログイン フォームが Fill() もしくは FillSelector() で対応できなかったので SendKeys()Click() で押し切ったところとか、もう少しブラッシュアップできるのではないかと思っています。

  • 処理の追加

    現状では、予期しないポップアップ(Amazon Prime を使ってみませんか、的なもの)が発生するとそれだけで何も言わずに処理が終わってしまうとか、数量が変更できないとか住所が既定値とか配送日が選択できないとか、いろいろ実装されていると便利な処理がありますので、追加できるといいなと思っています。

  • クレデンシャル情報の暗号化/外部参照

    ベタ書きになっているので取り扱い注意です。ただし、Lambda に載せるとなるとこの辺りどうなるのかな、という感じです(わかりません)。

Appendix: Resurrectio (ver. 0.5) の使用感

Resurrectio は、Chrome Extension の一つで、ブラウザ上で実行した動作を CasperJS のコードに変換してくれるという、夢の様なツールです。ということで試してみたのですが、結論から言うとあまりスクラッチから書く手間を削減できるかというとそんなことはないかな、という印象でした。例えば上述のスクリプトと同じことを Resurrectio でコード化するとこのようになります(最後の注文のクリックは省略)。

テスト利用を想定したコードになっていることはさておき、メールアドレスの入力ステップが認識されていなかったり、クリックしている場所を XPath で表現していたり(気持ちはわかりますし XPath を使うのが悪いわけではないですが)、ナビゲーション要素内のテキストを利用したりしている感じがコンボになって、あまり好きではありませんでした。

これまでとこれからのプロダクト マネージャー

本記事は Matt LeMay 氏の記事 "The Past and Future of Product Management" を本人の承諾を得て翻訳した記事です。文章及びスライドの画像は同氏に著作権があります。


数カ月前[*1]、アメリカ新聞編集者協会で開かれるニュース編集室のプロダクト マネージャーの集まりでプレゼンテーションを行ってほしいという依頼がありました。そこで私はこのプレゼンテーションの中に、私が経験してきたこと、見てきたこと、そして失敗してきた(非常に多くの)ことを土台として、「これからのプロダクト マネージメント」について考えを要約しました。このプレゼンテーションはいろいろな意味で私のこれまでのライフワークそのものでした。

私はこの時、プレゼンテーションのスライドをメモ付きの形式で作ったので、これ以降それをそのまま使ってプレゼンテーションの内容を説明します。内容は簡単にまとめると次の通りです。

  • これからのプロダクト マネジメントは、プロダクトを作り出すために実行するプロセスにおいても、顧客を理解するために必要とするデータにおいても、私たちが人間の複雑さを受け入れる能力にかかっている。
  • これからのプロダクト マネジメントは、基本的に補助的で他人に自ら行動することを促進するような役割[*2]であって、「ビジョナリー」になる役割ではない(スティーブ・ジョブズお断り)。
  • 「ハード スキル」と「ソフト スキル」という区別で考えることは概ね逆効果で、最高のプロダクト マネージャーは組織内の多様なものの考え方と役割の間を橋渡しするために必要な「コネクティブ スキル[*3]」を持っている。
  • これまで言われてきたプロダクト マネージャーに求められる様々な「特性や人物像」は、本来の一部のみを見たような、まだ十分に考えられていないものであり、すばらしいプロダクト マネージャーには「デザインが分かるエンジニア」や「コードが書ける UX デザイナー」というような特性の範囲を超えた、まだ活かされていない大きな可能性が残されている。

もし賛同できそうな内容だったり、続きが気になるような内容だったり、逆に明らかにおかしいように思えるのであればそのまま読み続けてみてください。

---プレゼン資料ここから---

-

今日は、私がここ5年で見てきた4つの大きな変化の概要を通して、これからのプロダクト マネージメントについて話します。

-

ただ、4つの具体的な変化の内容について説明に入る前に、もう1つ気がついた、より上位の変化についてお伝えしておこうと思います。私がプロダクト マネージャーとして仕事を始めた時、こういう質問を多く耳にしました。「なぜプロダクト マネージャーを雇ったほうがいいのですか。」場合によっては CTO と技術に明るい創業者が、プロダクト マネージャーを雇わなくてもソフトウェアを顧客に届けることができたと、人前で自慢することもありました。また、時にはプロダクト マネージャーが必要悪のように見えたり、会社組織図と損益計算書の中で仕方なく存在を認められた役割のように見えたりすることもありました。

-

結局こういったたくさんの話が行き着く先は、プロダクト マネージャーは単に純粋な技術的役割として活躍できない二流の開発者という誤った思い込みへとなっていきました。ソフトウェアを顧客に届けるためには開発者が必要でした。それに対してプロダクト マネージャーはよくても「いたらいい」、悪い場合はコードを書いてソフトウェアを展開するような「実際に手を動かす」仕事を邪魔する存在にしかなっていませんでした。

-

このような考え方は未だに幾つかの組織の中には残っていますが、近頃は昔ほど多くは見かけなくなっているように感じます。その代わりに次のようによく質問されます。「どうやってプロダクト マネージャーを雇えばいいのですか。」

-

このように質問される理由の一つは、注目を集めるハイテク製品が表立って期待通りの製品となることに失敗しているためと考えています。(どのような種類にせよ)顧客にソフトウェアを提供するということはそれ自体が全体的な最終目標である、という考え方は5年前よりも今のほうが支持を得づらい状況になっています。加えてベンチャー キャピタルが、収益を第一に考え自分たちのマーケットを正しく理解している企業に、より多くの関心を持つようになるにつれて、「単にソフトウェアを顧客に提供する」という考え方から「顧客に適切なソフトウェアを提供する」という考え方への明らかな変化が立ち現われています。

-

しかしながら、問題は顧客に適切なソフトウェアを提供するために必要とされるスキルセットを明確にすることがより困難になっていることです。開発者を雇うことは決して簡単ではありませんが、究極的には技術的体系に精通していることを何らかの形で示したり、尺度で測ったりすることは、人間系に対してそれを行うよりも簡単です(もし後者ですら可能なのであれば、ですが)。より多くの企業がプロダクト マネジメントは重要なことであると認識するにつれて、どのような要素を持っているのが「よい」プロダクト マネージャーなのかということと、そのような人をどうやって見つけるのかということに関する不安や、明確な答えがなく戸惑う感覚が高まりつつあります。

※Ken Norton 氏が書いた見識のある(そして時代を先取りした)「プロダクト マネージャーを雇う方法(英語)」という記事は必読で、私も気づいたら読み返している良記事です。 www.kennethnorton.com

-

私は、上述の質問に対する答えも同様に時代とともに変化していると考えています。そして今日は、私たちが考える「よい」プロダクト マネージメントという観点から私が見てきた4つの変化について考えを共有します。まず一つ目に話すのは大文字のアジャイルAgile)から小文字のアジャイルagile)[*4]への変化です。

-

これはどういう意味でしょうか。いったん Agile はもともとマニフェスト、つまり価値の宣言だった、という基本の形を振り返ってみる意味はあります。そして、Agile は頻繁にそして継続的に顧客のニーズに合った製品を届けることができる敏捷性を促進する価値をまとめたものです。純粋な形で表現すると「Agile とは一個人として存在している私たち人間の複雑さと必然的な変化を尊重する考え方」ということになります[*5]。

-

皮肉なことに、Agile の価値のまとまりは、高度な考え方と静的なプロセスという形で明文化されました。この考え方とプロセスはどんどん明確になり、また細かく区分されたプロセスとツールで成り立つエコシステムとなりました。そしてこのプロセスとツールは特有の包括的な文書と規則のまとまりを必要としました。

-

しかしながらある意味では、これによってより簡単にプロダクト マネージャーを雇えるようにはなりました。利用したいプロセスを選んで、そのプロセスの専門家を雇えばいいわけです。それで終わりです。

-

ただし、この方法には非常に厳しい制限があります。とりわけ顕著なのは、この方法が適応力が優れていて頭の回転が速い人、つまり agile な人ではなく特定の知識や経験にとらわれている人を雇うことを意味してしまうことです。

アジャイル マニフェストの署名者の一人である Andy Hunt 氏はこのことを自身のブログ記事「Agile の失敗」の中で非常にうまく説明していて、その記事の中で彼が「ルールを守ることの心地よさ」と呼んでいる部分の文章を以下に引用します。

初学者に効果的な唯一の方法は、単純で文脈に依存しないルール、つまり、「これが起こった時はあれを行う」という型になるルールに従うことです。そして、都合のいいことにアジャイル メソッドアジャイルを始めるための幾つかの具体的な実践方法を提供しているため、新しいチームはこれらの実践方法やその一部にとらわれてしまったり、そこから抜け出せなくなったりします。

だから、アジャイルの原則やアジャイル マニフェストの抽象的な考え方を参照する代わりに、可能な範囲でまとめられた実践方法の鉄則を理解して、それ以上先に進みません。アジャイル メソッドアジャイルを実践する人たちに対して自分で考えることを説きますが、正直に言ってそれはなかなか受け入れがたい考え方です。単にアジャイルを実践する人たちに提供されて「型通りにしなさい」と要求する原則に従うほうが、はるかに受け入れられやすくなります。そのほうが簡単ですし、バカにして笑ったり笑い返されたりする心配もありません。そしてその結果としてクビになることもないでしょう。もし誰かに何をやっているのかと聞かれれば「アジャイルを実践している」と答えることができますし、大部分は使えないルールのまとまりを徹底して実行することに集中できます。これでみんな気が楽になります。実際に顧客に何かを提供する時が来るまでは…。

-

そしてこのことは、プロダクト マネジメントの世界で起こっている、これまでのやり方に対するより多くの困難を伴う変化の一つであることを物語っていると私は考えています。そして企業は、プロダクト マネジメントが正しいプロセスを選ぶことではなく、組織全体の中でどのようにやっていくのがよいのかという実績を積み重ねていくことだと気づき始めています。

ここで私が言う「実績を積み重ねる」と言うのはどういうことを意味しているのでしょうか。プロダクト マネジメントは、原理原則を読むことでは十分に習得できないという意味でヨガやマインドフルネス[*6]と似ています(たとえ私がヨガや瞑想から得た経験に何かどんなものであれ効果があったとしても、それが必ずしもすべての人に対して簡単にもしくは自然に訪れる 類のものではありませんが…)。私が見るところでは、一般的に企業が最もしてしまいやすい失敗は、新しいアジャイルAgile) プロセスなるものが実施されるか、新しいプロダクト マネージャーが雇われて、状況がすぐに改善しなかった時にはどちらか一方もしくは両方が失敗だったと明言してしまうことです。問題はツールとプロセスではなく、人と人同士が相互に良い影響を及ぼし合うことの方にあると気づくためだけに、企業がプロダクト マネジメントのプロセスを5回も変えるさまを目にしたこともあります。ツールとプロセスを変更することは比較的簡単ですが、それが人と人同士の相互の影響となると時間を要しますし、楽でもなければ反響も大きいものになります

ツールとプロセスではなく、どのようにやっていくのが良いのかという実績を積見上げていくことという意味でのプロダクト マネジメントの議論の中で、私は Jon Kabat-Zinn 氏が瞑想することについて述べた文が良い教訓になると思っています。

(一般的に人は)リラックスしたり、特有の興奮状態を体験したり、自分を磨いたり、ストレスや痛みを取り除いたり、古い習慣や行動パターンを脱したり、煩悩の束縛から自身を解き放つために瞑想をします。どれも瞑想をする理由としては妥当ですが、もしお望みのこれらのことがただ瞑想をしているからという理由のみで叶えられると考えているのであれば、どれも 同じような問題を抱えることになります。特別な体験をしたり、少しでも望みが叶うことそのものにとらわれてしまい、もしそういった特別な何かをすぐに感じなければ、選択した道が誤っていたのではないかと疑ったり、自分が「正しく行えているか」どうか迷ってしまうでしょう。

-

さて、次に話したい2つ目の変化は、「データ駆動型」プロダクト マネジメントから「顧客駆動型」プロダクト マネジメントへの変化です。

-

おそらくは「ソフト スキル」の一群としてプロダクト マネジメントを見た際に、そのスキルセット関して過剰に不安を持っていることが理由で、「データ駆動型」プロダクト マネージャーの需要が高まっているということを私は耳にしたことがあります。そして、本当に今の時代に「データ駆動型」を望まない人なんているのでしょうか。いるはずがありません。私は自らの PM としてのキャリアを通して、プロダクト マネージャーの権威を確立し、正当性を与える一つの手っ取り早い方法を見つけました。それは、量的「データ」による疑いのない確実性を引き合いに出すこと、ダッシュボードでいっぱいになったスクリーンを眺めて多くの時間を過ごすこと、そしてアナリティクス[*7]のためのツールの評価と管理に十分な時間を費やすことです。

-

ただし、プロダクト マネージャーの仕事はアナリティクスを理解するのではなく、顧客を理解することにあります。「データ駆動型」という言葉は、多くの場合数値を収集する対象となる人々よりも集めた数値のほうに重きをおく考え方を想起させてしまいます。もし私たちのゴールが単にグラフを右肩上がりにすることなのであれば、たとえそれが顧客や私たちの製品の現実の状況を犠牲にしたとしても、特定のグラフを右肩上がりにする要素なら何でも最大限に活用するでしょう。

私の友達でニューヨーク・タイムズのデータ サイエンティストの Mike Dewar 氏は、まさにこのことに関して、リコメンデーション エンジンはメトリクスを最大化することに寄与しているのではなく、むしろ人々の体験をデザインしていくことに寄与していると主張する素晴らしい記事を書いています。

-

ビッグデータ」時代の最も有害で根強い神話のうちの一つに、私たちは数値とダッシュボードを見ることで、「人々が彼ら自身について知っていることよりも多くのことを知ることができる」というものがあります。このような考え方はデータに関する基本的な誤解を招くだけでなく、人間を特徴づける人間性に関しても同様の誤解を招くことになります。私たちが人々の声に耳を傾けることなしに彼らを理解できると考えるのは思い上がりで偏った考え方であり、正直なところ嘆かわしくもあります。実際に人と話すことで、時には困惑したり、気まずくなったり、あからさまにがっかりすることになります。でももし本当に顧客を理解したいのであれば、私たちは人のことを完全に想定できるわけでも数値化できるわけでもないことを受け入れ、それに対応する必要があります。

-

Datascope Analytics 社が自社のブログで公開した風刺漫画は、私たちが時々しょうがなく認めてしまう重要なこと、つまり「データ駆動型」の仕事は、明確な目的がなければただ穴を掘ってはその穴を埋める仕事になってしまうということをうまく捉えています。あるときには、顧客のニーズや行動を過剰に単純化してしまうことによって顧客との距離を広げてしまう見せかけだけの仕事になってしまいます。もし私たちが「なぜ」ということを問わなければ、つまりもし私たちが「データ駆動型」による決定の背後にある乱雑な人間の理性のようなものを探していなければ、プロジェクト マネージャーとしての仕事を全うしていないということになります。 datascopeanalytics.com

-

上述に関連して、次に話したい3つ目の変化は「なに」から「なぜ」への変化です。

-

私が PM として働き始めた時、プロダクトのロードマップを「わがものとすること」にとてもわくわくしていました。次々とアイデアを出すような人、突如として現れたビジョナリーになって会社を良い方向に一変する人になろうとしていました。要するにチームのメンバーに何を作ればよいのかを教えるつもりでした。

-

このような考え方は、プロダクト マネージャーはプロダクトにおける「ミニ CEO」の役割を担っているという思いに端を発しています。PM の仕事を始めた当時、私はこのような考え方がとても気に入っていました。自分がとても重要な人物であるような気にさせてくれましたし、気力が湧いてくるようでした。それどころか、時々この男のことを頭に思い描き始めたりもしました!

-

そういったわけで、私はチームのメンバーが私に「何に取り組めばいいのか」と聞いてくることがとても好きでした。それで私はまるでプロダクトの真の指導者、ロードマップと成功指標の番人、あるいはプロダクトの未来の守護者になったようでした。私一人だけが企業の最も重要なゴールと願望を理解していて、私一人だけがそのゴールを達成できる素晴らしいアイデアをふくらませ、私一人だけがチームにいつどのアイデアを実行すればいいのかを教えようとしました。

-

いま、この考え方は私が問いただしたい別の問題と密接に繋がり合っています。そしてこの問題は正直に言うと私がやってしまったとんでもない失敗です。世の中には開発者とそれ以外の主に経営を行い結果を出すことに責任を持つ他の人々はビジネスもしくはビジネスの主題に関する決定から「分け隔てられる」必要があるという広く支持された考え方があります。開発者はただヘッドフォンをつけて一日中コードを書きたいだけ、そしてもし彼らにビジネスのゴールやユーザーの本質的な欲求の話、つまりなぜ今やっていることを何故やっているのかということを話そうとするのであれば、それは開発者の時間を無駄にし、彼らの特別で非凡な性質をダメにしてしまう原因になってしまっているというようなことです。

私は、これが誤った考え方なだけではなく、あまりにもエンジニアを見下したような考え方だと思っています。別に、単に今やっていることをなぜやるのかということを知らずに、何かを実行することを望んでいる人がいないと考えているわけではありません。ただ一方で、このような考え方を支持した方がいいということはないと明確に考えています。あと、遠慮なく言うと私が見てきた中では、プロダクト マネージャーもしくは経営者が「なぜ」に関する情報を伝えない時は、だいたい彼らがそのなぜということを本当に理解していないです。

-

私がプロダクト マネージャーの仕事を始めた時に誰かに言って欲しかったことは、「ヒーローになろうとするな」ということです。「ビジョナリー」を自称するプロダクト マネージャーは危険な存在です。それで私は、PM の採用面接の最中に某ス****・ジ***氏の名言を連発するような候補者を採用しないようにアドバイスしています。プロダクト マネジメントは、基本的には異なる役割を持つ人たちの間で関係を築き上げ、双方の理解を得られる状態にしていくことであって、どんな作業をするのかを人に伝えることではありません。支援的な役割であり、ビジョナリーではありません。「次に何をすればいいのか」と聞かれたことで私は一時的には気分が良かったですが、実際には PM としていい仕事をしていなかったと一般的には言えます。

特にこういった状況がよく当てはまるのは、私たちの(作業の)優先順位が変わったり、環境が変わった時でした。そして優先順位や環境は常に変わるものです。もしプロジェクト マネージャーが今作っているものをなぜ今作ってるのかということを知らないのであれば、プロジェクトを作業スコープから外すのは(もしくは、初期の段階で技術的な観点からプロジェクトを作業スコープに入れることでさえも)とてつもなく難しいことです。もしチームが今作っているものを何故作っているのかを知らなかったのであれば、彼らがプロジェクトのゴールを実現するために最も適切な技術的決定を下すことはできないでしょう。

結局、私はプロダクトの「リーダー」になろうとすることをやめ、その代わりに企業のゴールが明確で透明性があること、それにそのゴールができる限り多くの人に理解されていることを確認するために尽力しました。その仕事によって自分が重要な人物であるように感じることは少なくなりましたが、チームで協力する働き方が劇的に改善されました。そしていまでは、私が優先順位付けのプロセスをつくり上げる目的で企業と協力して働いている時に、自分に対して「この企業が目指すゴールは、私がここにいなかったとしても、プロダクト チームが同じように効果的に優先度を決めることができる程度に十分に明確になっているか」と問いかけるようになっています。

-

では最後に「ハード スキル」と「ソフト スキル」から、物事を結びつけていくスキルへの変化について話します。

-

PM を雇うときに、PM の能力として「ハードスキル」と「ソフトスキル」のバランスをどう取ればいいのか、ということをしばしば聞かれました。正直なところ、私はまさにこのような区別こそ、企業が最高のポテンシャルを持った PM を見極めるのを妨げる要因であり、また PM が彼らの仕事に自信を持つのを妨げる要因でもあると考えています。

ユーザー分析とプロダクト マネジメントに関して優れた書き手である Megan Kierstead 氏は、ひどい採用面接に最後まで付き合った PM なら多くの人が共感してくれるであろうこんな話をしてくれました。その話の中で起こった出来事は、PM について「ハード スキル」と「ソフト スキル」という観点から考えた時のいわばよくある話です。「ハード」対「ソフト」という言葉そのものが、もともとそれだけで一方が他方に対して特権を与え、たぶん最も害を及ぼすような場合にはどういうわけか一方がもう一方を犠牲にして成り立つゼロサム ゲームを想起させますmedium.com

-

プロダクト マネジメントに関する多くの文献の中に、PM は「十分に技術のことをわかっている」必要があるという考え方を見つけることができます。これはある文脈の中では成り立ちますが、他の場合では裏目に出る考え方です。最もよい場合には、この考え方は、技術に関して効果的に決定を委任し、適切な問いを立てるのに十分な興味と好奇心持っているプロダクト マネージャーを企業に採用させるきっかけになります(もっとも、これらのことができるようになるための技術的なハードルはとても低いです)。最悪の場合には、最高のプロダクト マネージャーにはならず、ほとんどエンジニアと変わらない候補者を採用させることになります

実は採用プロセスの中ではしばしば、ほとんどエンジニアと変わらない PM の候補者がエンジニアリング チームに最も歓迎されます。そうならないわけがありません。こういった候補者はだいたい同じような経験、興味、そして専門技術を持っています。エンジニアリングチームの開発者はこの手の話題を多く持っていますので、「非技術的な」プロダクト マネージャーを採用することで、エンジニアリング チームのエンジニアたちとの仲を引き裂いてしまうことを恐れている採用担当マネージャーは、ホッとして溜息をつくわけです。

不幸なことに、エンジニアと変わらない PM 候補者は、だいたい最初にエンジニアリング チームの面々を惹きつけたまさにその理由でチームの役に立たないという結果に終わります。プロダクト マネージャーとしてのキャリアの初期の頃、私がまだ、そこにいることの正当性の根拠として私が持っているあらゆる技術的な専門知識にしがみついていた時、私は気がつくとよくチームのエンジニアが技術的に最も興味を見出す仕事を失わないように配慮していました。しかしながら、彼らがその仕事における顧客対応の影響に責任をもつこととなってすぐに、私は私が実際には自らのエゴ以外の何も守っていなかったことに気付きました。

私が出会った中で本当に素晴らしくて技術的なスキルを持っている PM は、優先順位付けのプロセスがそれ自体興味深くもあり、そしてやりごたえもあるようなやり方でエンジニアリング チームにそのプロセスに関わってもらう方法を知っています。彼らはエンジニアリング チームに対して情報を提供するのと併せて、彼らに企業のビジネスのゴールに近づくための推進力となるような技術的な決定を下してもらうためにどのように権限を与えればよいかを知っています。言い換えれば、PM の採用に関して成功と失敗を分ける要因は、PM が「十分な技術力を持っている」かどうかではなく、むしろ異なる価値観と専門知識の間を橋渡しするように関係を作ることが非常にうまいかどうかということです

-

では、なぜ「十分な技術力を持った」プロダクト マネージャーという考え方が、あちこちに偏在しているのでしょうか。私には、どちらも額面通りに受け取った時には、とても良いと思われた「エンジニア駆動型カルチャー」と「カルチャー フィット[*8]」という2つの概念が交差するところにこの考え方があるように思えます。理屈の上では、技術的なプロダクトを作る高度に専門化された技術者は、当然彼らがより良い結果を出せる、そして権限が十分に与えられていると感じる環境で働くのが良いでしょう。そしてまたこういった技術者は、当然ながら彼らが尊敬する、賞賛する人々と働くのがよいでしょう。

しかしながら実際のところは、この2つの考え方がしばしばエンジニアは彼らの持つスキルセットを共有する人だけを「尊敬する」という信条となってはっきり表れています。奇妙なのは私がこの信条に遭遇するとき、通常それはエンジニアリング チームから発せられたものではなく、エンジニアの幸せを考え続けているマネジメント チームから発せられていることです。

-

企業がこれほどまでによいPM を採用するのに悪戦苦闘する理由の大部分を占めているのは、カルチャー フィットという考えです。なぜなら、プロダクト マネージャーという役割は仕事の内容が変わりやすく、決まったこれというものがないからです。というのもプロダクト マネージャーの仕事には、「人と人と関わり合いをうまく構築できる能力」を要する面倒な仕事が多いことから、基本的に見た目や行動がエンジニアリング チームやアナリティクス チーム、あるいはその他一緒に協力して働くいかなるチームとほとんど変わらない、わかりやすい人々を雇うことにある種の安心感を生じさせてしまいます。

-

ところが、自称「イノベーティブ」な企業のための、率直に言って滑稽なまでに保守的なものさしになっているカルチャー フィットという考えは、近頃「カルチャー アッド[*9]」という考え方に置き換えられているということを耳にします。この動きは、多様なスキルとものの見方を既存の組織に持ってくる考え方を取り入れることで組織の知識と将来性を大きく広げることを意味しています(友人の Melanie Stern 氏は採用という観点からカルチャー アッドについてとてもよい記事を書いています)。ちなみに私だったら、カルチャー アッドという考え方は、仮に既にあなたのチームのメンバーになっている人々が、新しいものの見方に対して恐怖を感じているというよりもむしろ好奇心を持っているとした場合、彼らに対するアプローチとしても、より思いやりのある方法だということを追記すると思います。 www.pov2050.com

私は、プロダクト マネージャーが組織に与えられる価値を理解する鍵となるのは、上述のような好奇心だと考えています。Scrum と XP のより正確な違いについて饒舌に話すPM の候補者よりも、チームの力学について即興のグループや政治的な組織活動を通じて学んできたことを話す PM の候補者を見るほうがもっとワクワクします。優れた PM というのは、表面上は共通点のないような経験や価値体系、そしてスキルセットの間をまたいで関連付けることができる人たちです

PM としてエンジニアやデータ サイエンティスト、もしくはその他の高度に専門化された才能のある人に気に入ってもらうにはどうすればよいのか、ともし人が私に尋ねたら、私の答えは「コードを書く方法を学ぶこと」ではありません。私の答えは間違いなく「心から彼らがやっている仕事に関心をもつこと」です。このことを理解するのに私は何年もかかってしまいましたが、今となってはこの答えがプロダクト マネジメントにおける議論の余地のない真実だと強く考えています。本当に関心をもつ習慣を作り、それをさらに発展させていくことがプロダクト マネージャーの仕事の大きな部分になります

-

組織の内部で PM の役割を担う候補者を見極めようとしている組織に相談を受けた時、私はしばしば組織内でどのように情報が行き来しているのかを示す図を描いてもらうよう依頼しています。それは組織図というようなものではなくて、単にどのように組織内の人々がお互いにコミュニケーションを行っているのかを表すちょっとしたスケッチのようなものです。大抵の場合、中心のノードとして、他人同士のコミュニケーションをつなぐ人として、または人と人をつなぐ人として数人が浮かび上がってきます。これらの人たちは、一般的にはこれまで言われてきた PM の人物像には合致しません。つまり、彼らはデザインに興味を持つエンジニアではありませんし、いくらかコードが書けるデザイナーでもありません。大抵彼らは営業部門やコミュニティ マネジメント[*10]を行う部門、あるいはマーケティング部門にいます。大抵彼らは完全に「非技術的な」役割を担っています。しかしながら、ほとんどの企業やチームに最低でも1人は、自然に異なった考えや部署の間で連絡をつけるような人がいます。彼らは、agility を理解していて、そして重要な事は、彼らは既にこれまで述べてきた難しい、でも決定的なコネクティブ スキルを持っていることを既に証明している人たちだということです。彼らこそが次の時代のすばらしい PM だと私は信じています

*1:オリジナルの記事は 2015 年 11 月に書かれています。

*2:訳者注: これはコマンド コントロール的な考え方の対比としての意味と判断して訳しています。

*3: 訳者注: 現状一言で言い表す良い言葉がないことと、ハード スキルおよびソフト スキルに対比される言葉としてあえてコネクティブ スキルと訳しました。

*4:訳者注: 以降識別しやすいようにそれぞれ Agile, agile と表記します。

*5:訳者注: アジャイル宣言の背後にある原則を参照のこと http://agilemanifesto.org/iso/ja/principles.html

*6:訳者注: マインドフルネスとは、瞑想を始めとしたストレス対策や健康に関連する活動のようなものらしいのですが、日本語にできないのでそのまま訳しました。

*7:訳者注: アナリティクスとは、日本語にしにくいのでそのまま訳しました。

*8:訳者注: 昨今組織論で話題になりがちな Culture fit については、適切な日本語訳が見当たらないため、そのままカタカナで表記しました。

*9:訳者注: Culture Add という考え方を日本語で表現する例が見当たりませんでしたのでそのままカタカタで表記しました。

*10:訳者注: 文脈からソーシャル メディア上を主とした顧客やステークホルダーに対するコミュニケーションによって製品やサービスを取り巻くコミュニティを良い方向に持っていくような仕事をしている人たちを指していると思われますが、詳細は不明です。

Amazon CloudWatch と twilio を Zapier で連携すると簡単に電話通知を実装できた

ふと Zapier で API 連携できるサービスの一覧を見ていたときに twilio があって、もしかしてこれは CloudWatch と連携させればシンプルに電話通知ができるんじゃないかと思ってやってみたら簡単にできたというのが、この記事の概要になります。

CloudWatch から twilio への連携図

EC2 インスタンスのシステム障害(その他)を CloudWatch で検知して、アラームのステータス変化をトリガーに、twilio から携帯電話に電話をかけてアラームの内容を通知するアクションを以下の形で実装しています(簡単すぎて図を描く気が起きませんでしたもうしわけありません?)。

EC2 -> CloudWatch -> Zapier -> twilio

CloudWatch で障害(その他)を検知する

正直なところ、今回は電話通知ができるかどうかを確認したかっただけなので、手がこんだことは何もしていません。振る舞いを扱いやすい要素を使って検知するトリガーがあればよかったので、単にインスタンスの CPU の使用率にしきい値を設けて、使用率が一定以上になった場合にアラームを出すアラームを CloudWatch で作ります。

$ gzip -9 < /dev/urandom > /dev/null を監視対象のインスタンス上で実行するなどして CPU 負荷を高めてみた結果、アラームが想定通り出るかどうかを確かめておくといいかと思います。

twilio のサービス利用登録を行う

twilioのトライアル登録してみた」あたりを参考に twilio にユーザー登録して電話番号をもらっておきます。加えて、[アカウント] のところにある [API クレデンシャル] の AccountSID および Auth Token をどこかにコピーしておきます。

Zapier のサービス利用登録を行う

こちらも同じく「IFTTTすら使ったことないけどZapierを使ってみたときのメモ」あたりを参考に Zapier の利用登録を行い、Zap を作るために CloudWatch と twilio を選択します。Zapier が両方のサービスにアクセスするために必要な情報として、CloudWatch は AWS Access Key IDAWS Secret Access Key を、twilio は上述の AccountSIDAuth Token を Zap 作成画面で適宜入力します。あとはそれぞれ…

  • CloudWatch の Edit Options で
    CloudWatch の Region と Alarm の名前(Use a Custom Value -> CloudWatch で作成したアラーム名)を入力します。
  • twilio の Edit Template で 取得した電話番号を From Number に、To Number にかける電話の電話番号を、Message の内容は CloudWatch のパラメーターから任意の内容を入力します。

各アプリで動作テストができますので、Test Successful! になれば OK です。

電話通知を実際に受ける

上述の方法を使うなどして監視対象のインスタンスの CPU 負荷を高めます。CPU 使用率がしきい値を超えると CloudWatch 側でアラームが出て、それをトリガーにして twilio から電話がかかってきます。

あとがき

今回は単なる思いつきで CloudWatch -> Zapier -> twilio の連携を作ったわけですが、CloudWatch はもともと有料プラン(最低でも $20/月)でしか使えない(連携対象として選択できない)アプリの一つですし、タスクの実行可能回数や Zaps が実行される間隔もプランによって異なります。どちらかというとメールやメッセージよりも緊急性が高い時に使いたい場合が想定しやすい電話通知ですが、そういったニーズを満たす使い方ができるかというとちょっと微妙かもしれません。あと、別に意図していたわけではありませんが、コードを全然書かずに実装できてしまいました。

ということで簡単なのと Zapier は連携できるサービスが多いので、普通に監視サービスの一環としてもう少し凝った実装をするのもいいですが、家庭を支える技術系でなにか考えるのもいいかもしれないなと思っています。

プログラムマネージャーについて話すときにモヤモヤするのはなぜか

Rebuild.fm 126: Anti-Democratic Product Management (higepon) で Technical Program Manager について言及があった時に、「アジャイルでスプリントを回すとか、大きい意味での会社の依存関係を解決する。」「スクラム マスターのようなもの。」というような形で表現されていましたが、日本ではプログラム マネージャーをあまり見かけませんし、プログラム マネージャーをしている人を見ても結局何をする人なのかよくわからない、という方もいるかと思います。

そこで、プログラム マネージャーがどういう役割なのか、その補足説明をしてみよう思います。ちなみに予め断っておきますが、私自身はプログラム マネージャーがいる組織に在籍したことはありませんし、日本ではそのような組織の存在もあまり聞いたこともありません。また、プログラム マネージャーがいる企業(北米や西ヨーロッパ諸国等含む)でも働いたことはありませんので実情がどうなのかはほぼ知りません。その辺りは差し引いて読んでもらえればと思います。

プログラム マネージャーとは

まず、プログラム マネージャーのプログラムですが、これはコンピューターを動かすプログラムのプログラムではありません。アポロ プログラム(アポロ計画, Apollo program)のような意味でのプログラムなのですが、ではプログラムとは計画なのかと言われるとそれにも少し注釈が必要だと考えていて、例えば PMI (プロジェクト マネジメント協会)ではプログラムをこのように定義しています。

個々にマネジメントすることでは得られないベネフィットを実現するために、調和のとれた方法でマネジメントされる、相互に関連するプロジェクト、サブプログラム、及びプログラム・アクティビティのグループと定義している。(...)プログラムとは、企業戦略を実行し、事業または組織のゴールと目的と達成するための手段である。[1]

少し抽象的なのと横文字が多くてわかりにくいですが、企業が持つビジョンとミッション、それに繋がる企業戦略に沿って決定された投資対象や資源の分配、提供する価値、ビジョンの達成方法(ポートフォリオ マネジメント)をベースとして実際に(有期で)活動をする単位、せっかくアポロ計画を引き合いに出したので、一例にしてみればこのような感じでしょうか。

  1. アメリカ合衆国のビジョン
  2. 上記ビジョンに基づいたアメリカ合衆国のミッション
  3. 上記ミッションを達成するための戦略
  4. 宇宙開発、宇宙空間の平和目的あるいは軍事目的における長期間の探査のために NASA を設立(ポートフォリオ
  5. 人間をつきに送り、安全に帰還させる目的でアポロ計画を開始(プログラム
  6. ロケットの打ち上げ、宇宙船の設計開発、遠隔通信手段の確立と実装など(複数のプロジェクト)

Podcast 内の higepon 氏の「すごく偉い人達にレポートをすることをやっている人もいる」という発言も、上の例に照らし合わせると企業戦略により近い人に対して、コスト実績やスケジュール、予算等のフィードバックを行っているということでプログラム マネージャー(上記のような計画をマネジメントする人)の実態が垣間見えてくるのではないかと思います。

さらに少し上記とは異なった視点でアジャイルな文脈を含みますがアジャイル ソフトウェア要求からプログラムマネジメントに関連する部分を引用してみます。

(...)プログラムレベルでは顧客向けのプロダクト、システム、アプリケーションスイート全体を納品するというより大きな企業の目的のために、複数のチームを制御するメカニズムを提供する組織、プロセス、要求のモデルがある。チームレベルでは、チームは権限を委ねられ、かなり自己組織化し、自己管理している。チームは、チームのプロダクト オーナーの管理下にあるローカル バックログに基づいて開発を行う。(...)ところが、プログラム レベルでは課題が変わり、この一段大きな規模でアジャイルさをうまく実行するためのさらなる課題に企業は直面する。このレベルの目的には以下が含まれる。

  • ビジョンとロードマップを維持する

    プログラムに対するビジョンを継続的に定義し、伝えるとともに、チームが共通の目的に向かって開発を行えるようにロードマップを維持する

  • リリース管理

    企業が選択した開発のリズムでリリース インクリメントを構築するために、複数のチームの作業を調整する。

  • 品質管理

    複数チームの開発結果を集めたもの(システム)が定期的に統合されるようにする。それらでは性能、セキュリティー、信頼性に関する要求や、守らねばならない外部の標準が満たされている。

  • 配置

    チームがシステムをエンド ユーザーに届ける能力、責任範囲、権限を持たないような場合、この重要な作業はプログラム レベルで管理されなければならない。

  • リソース管理

    タイムリーに求められる価値を納品するというプログラムの能力における制約やボトルネックに対処するために必要なリソースを調整する。

  • 障害を取り除く

    プログラムのリーダーや管理者は、チームの制御の及ばない致命的な問題のような複数のチームから沸き起こる障害を取り除く責任も担う。[2]

それでもプログラム マネージャーが実務として何をしているのか想像しにくいでしょうか。その場合、アポロ計画を開始するところをソフトウェアもしくはプロダクトのリリース(による価値の提供)に置き換えてみてはどうでしょうか。

実は、アジャイルソフトウェア要求第 14 章には、中規模以上のソフトウェア企業やプロダクト志向の会社では、上記のプログラム レベルのマネジメントを実施する役割としてより明確にプロダクト マネージャーという役割が担っていると書かれています。詳細は続く第 15 章及び 16 章を読んでもらうのが良いかと思いますのでここでは省略しますが、その役割として戦略的な目標をチームのメンバーと共有/方向性を揃えたり、プロダクト開発のリズムを作ったり(アジャイルリリース列車)することが挙げられています。

プログラムとしてプロダクトを考えた時、例えば昨今の SaaS 企業を始めとしたプロダクトの頻繁なリリースは上記の内容を非常に短い期間で行っていることに他ならないかと思います。そういう意味では higepon 氏が所属する組織で元(テクニカル)プログラムマネージャーがプロダクトマネージャーに着く事例があったというのはキャリアとしてはそれほど不自然ではない気がします。

※ただし、PMI が想定するプログラム マネージャーとアジャイルソフトウェア要求が想定するプロダクト マネージャーの役割は価値を提供する対象の違いやプログラムの性質の違い等から必ずしも同じことを行うわけではないと思います。

さて、プログラム マネージャーが上記のような活動をする一方、引き合いに出ていたスクラム マスターの役割についてスクラム ガイドを引用すると以下の通りとなります。

スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。

スクラムマスターは、スクラムチームのサーバントリーダーである(訳注:メンバーが成果を上げるために支援や奉仕をするリーダーのこと)。スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと/立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスターは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。[3]

冒頭で断った通り、実際の企業規模や組織構造に依存して必要な役割は変わってくるので、常にこうだ、ということではありませんのでプログラム マネージャーがスクラム マスターを兼務している可能性については言うに及びません。しかしながら、定義上の役割だけではなく一方がマネージャーであるのに対して他方はリーダーであるとすれば、2つの役割は大きく異なっていると思われるので兼務は大変そうだな、という印象です。


脚注

[1] Project Management Institute, Inc.(PMI)(2013). The standard for program management third edition. PMI(プロジェクトマネジメント協会日本支部(訳)(2013). プログラムマネジメント標準 第3版 プロジェクトマネジメント協会日本支部)(pp. 4-5)

[2] Dean Feffingwell (2010). Agile software requirements. Addison-Wesley Professional(ディーン・レフィングウェル オージス総研(訳)(2014). アジャイルソフトウェア要求 翔泳社)(pp. 54-55)

[3] Ken Schwaber and Jeff Sutherland (2013). The scrum guide. http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf角征典(訳)(2013). スクラムガイド http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf)(p. 6)