2016-04-25

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

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

2016-04-21

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

CloudWatch twilio Zapier EC2

ふと 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 ID と AWS Secret Access Key を、twilio は上述の AccountSID と Auth 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 は連携できるサービスが多いので、普通に監視サービスの一環としてもう少し凝った実装をするのもいいですが、家庭を支える技術系でなにか考えるのもいいかもしれないなと思っています。

2016-01-14

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

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

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

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

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

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

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

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

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)

2015-11-10

OpenStack Cloud Computing Cookbook Third Edition, Second Edition からの変更点（削除された章編）

先日品川で開催された OpenStack Summit Tokyo 2015 でラッキーなことに２ヶ月ほど前に出版されたばかりの OpenStack Cloud Computing Cookbook Third Edition (以降 TE、2015/8 出版、Juno および Kilo ベース) をゲットすることができたので、Second Edition (以降 SE、2013/6 出版、OpenStack Grizzly ベース) との違いをまずは見ていこうと思います。長いので SE で削除された章編と TE で追加された項目編に分けて書こうと思います。

※見落としや間違いがありましたら教えて頂けると助かります。

余談ですが、OpenStack のリリーススケジュールは６ヵ月毎となっており、TE が出版された２ヵ月後には Kilo の次のバージョンである Liberty がリリースされていますし、その次のバージョンである Mitaka (Meiji という名称はどうのこうのという話がありましたね) 予定通りであればまた半年以内にリリースされると思われますので、Forth Edition のころにはコアサービスだけが対象だったとしても Neutron を始めとして内容が結構変わっているかもしれません。出版されれば、の話ですが。せっかく著者が OpenStack Summit にいらしていてサインまでもらったので perspective とか聞いてみればよかったです…。

Third Edition の目次

Chapter 1: Keystone - OpenStack Identity Service
Chapter 2: Glance - OpenStack Image Service
Chapter 3: Neutron - OpenStack Networking
Chapter 4: Nova - OpenStack Compute
Chapter 5: Swift - OpenStack Object Storage
Chapter 6: Using OpenStack Object Storage
Chapter 7: Administering OpenStack Object Storage
Chapter 8: Cinder - OpenStack Block Storage
Chapter 9: More OpenStack
Chapter 10: Using the OpenStack Dashboard
Chapter 11: Production OpenStack

Second Edition の目次

Chapter 1: Keystone OpenStack Identity Service
Chapter 2: Starting OpenStack Image Service
Chapter 3: Starting OpenStack Compute
Chapter 4: Installing OpenStack Object Storage
Chapter 5: Using OpenStack Object Storage
Chapter 6: Administering OpenStack Object Storage
Chapter 7: Starting OpenStack Block Storage
Chapter 8: OpenStack Networking
Chapter 9: Using OpenStack Dashboard
Chapter 10: Automating OpenStack Installations
Chapter 11: Highly Available OpenStack
Chapter 12: Troubleshooting
Chapter 13: Monitoring

太字が今回の対象。

Second Edition との違い（TE で削除された章編）

Chapter 10: Automating OpenStack Installations (SE)

SE 10 章では OpenStack の環境を構成する方法として Chef を利用していますが、Chef を使って環境を構成するという決定の背景には以下のような議論があったようです。

Notes for this edition of the OpenStack Cookbook

There are lots and lots of choices when it comes to the bare-metal and automated provisioning of an OpenStack environment. In this edition of the book, after some discussion with Kevin and those in the community, we decided to change gears from Ubuntu's MaaS to something that would allow for a greater degree of flexibility. After considering the great work going on in the TripleO project and Bare Metal OpenStack, we decided that while great progress is being made in those projects, at this time we were going to print with PuppetLabs Razor and Chef.

これは First Edition の時に Ubuntu MaaS を利用してベアメタルプロビジョニングをする項目があったようで、そこからの "Change gears" ということのようです。その結果 SE では Vagrant と VirtualBox を OpenStack 環境のベースにしており、さらに TE では Ansible の Playbook を利用して Ubuntu の上の LXC Container に OpenStack 環境を構成する方法を採っています。なお、TE では OpenStack のインストールを自動化する内容が 11 章の Production OpenStack の中の一項目となり、SE のような章立てではなくなっています。

Chapter 11: Highly Available OpenStack (SE)

SE 11 章では、単一障害点を取り除いた可用性の高い OpenStack 環境を構成することをコンセプトに、バックエンドのデータベース側には MySQL Galera cluster + HA Proxy、Keystone と Glance の冗長化の目的で Pacemaker + Corosync を利用した構成を行う形となっています。TE では SE の 10 章と同じく TE の 11 章の Production OpenStack の中の項目となり、MySQL Galera cluster から MariaDB Galera cluster に変更となっていますが、構成内容そのものには大きな変更はなさそうです。

Chapter 12: Troubleshooting (SE)

SE の Chapter 12 ではトラブルシューティングの方法として OpenStack が生成するログの保存先の情報（e.g. nova-compute: /var/log/nova/nova-compute.log）の提示やサービスの確認等々の記載がありましたが、これらの内容は TE では章立てとしてそもそもなくなっており、SE で記載があった内容についても大半がなくなっているようです（ぱっと見では nova-manage, nova list, swift-recon についてはそれぞれ関連する章内に別々に記載がありました）。

ちなみに、トラブルシューティングの仕方については、OpenStack Summit Tokyo の Debugging the Virtualization layer (libvirt and QEMU) in OpenStack で興味深い話がありましたので、よかったらリンク先のスライドもどうぞ（このスライドを使った OpenStack Summit の動画は 11/9 時点でまだ公開されていないようです…）。

Chapter 13: Monitoring (SE)

何か先例を引き合いに出すまでもなく、モニタリングと環境の見える化（Visibility）はこういったシステムの運用にとって非常に重要な要素だと思いますが、SE 13 章では監視する対象に合わせて以下のような見出しになっていた一方で、TE では同様の内容として 9 章の More OpenStack 内で Ceilometer を利用した Nova ノードのリソース監視を行うものの、それ以外は記載がなくなっているようです。

Monitoring OpenStack services with Nagios
Monitoring Compute service with Munin
Monitoring instances using Munin and collectd
Monitoring the storage service using StatsD/Graphite
Monitoring MySQL with Hyperic

余談ですが、Operations and Management of a Hyper-Converged Multi-Tenant Platform のセッションでの Nick Gerasimatos 氏の発言によると FICO では OpenStack の監視に Zabbix を使っているとのことです。

We've been using Zabbix for very long time and what we realize is Zabbix, it's not bad tool. It requires a lot of custom immigration to meet our needs (and) our requirements...

ご参考: モニタリングに関しては Monitoring Swift with Elastic Search や Monitoring system for OpenStack, using a OSS products というセッションがありましたが、私は別のセッションに出ていたので内容はまだ未確認です。興味があればあわせてどうぞ。

2015-03-02

FYDIBOHF23SPDLTの意味

Exchange Server 2007 以降でメッセージング環境を扱ったことがある方なら FYDIBOHF23SPDLT という文字列を見たことがあると思いますが、この文字列のアルファベットおよび数字を以下の順番においてそれぞれ1文字ずつ前（左）に戻すと… EXCHANGE12ROCKS。それだけの話でした（いままで知りませんでした）。

ABCDEFGHIJKLMNOPQRSTUVWXYZ
(0)123456789(0) ※数字のゼロは前なのか後ろなのか判断できません。

意味はともかくですが、これをどう読んでいいのかわからなくてちょっと電話のときとか NATO フォネティックコードを使った会話みたいになってつらかったので、今度からはドヤ顔で EXCHANGE12ROCKS と言おうと思います。

※ちなみに FYDIBOHF25SPDLT があるのは確認していてこれもバージョンの違いですね。

2014-12-09

PowerShell でフォレストの信頼を作成する

※これは PowerShell Advent Calendar 2014: ATND 9 日目の記事です。

昨今進化が目覚ましく、頻繁に話題を目にするようになった PowerShell ですが、Micorosft の製品を利用/運用しているといまだ PowerShell で簡単に実行できないことがいろいろあることに気づく方も多いのではないかと思います（簡単にとい言うのはいわゆる"動詞-名詞" 形式の命名規則に基づいたコマンドレットの実行のことです）。

今回はその中のうち、フォレストの信頼を PowerShell で実行する方法を紹介しようと思います。ご存知かもしれませんが Active Directory の信頼を作成する方法としては GUI と Netdom コマンドレットがあります。個人の観測範囲内では Netdom すらあまり使われているのを見たことはなく GUI とスクリーンショットのコンボを決めているのが大半かなと思います。。。

それで、まずマウスでポチポチするのはやめましょうか、と考えたときにじゃあ Netdom を使いましょうか、と思うのですが

Netdom cannot be used to create a forest trust between two AD DS forests. To create a cross forest trust between two AD DS forests, you can either use a scripting solution or the Active Directory Domains and Trusts snap-in. (TechNet | Netdom trust)

要するにフォレスト間の信頼を作成するのに Netdom は使えません。そんな馬鹿な、誰か反論を。ということで残念ながら現時点では PowerShell にもそれを実現するコマンドレットは存在しません。

Get-ADForest で、実行した AD フォレストの現時点の情報を取得する→わかる。
Get-ADTrust で、実行したドメインにおける現時点の信頼されたドメインオブジェクトの情報を取得する→わかる。
Get-ADForest があるということは New-ADTrust や Create-ADTrust で、特定のドメインもしくはフォレストの間に信頼を作成できそうなのにそういうコマンドレットがない→？！

とは言え、ないものは仕方がありません。幸い PowerShell では .NET Framework を利用できます。利用できますというか PowerShell はいわば .Net Framework アプリケーションですので、今回は不本意（？）ですがその機能を明示的に使っていきたいと思います。

まずどこからか [System.DirectoryServices.ActiveDirectory] 名前空間の Forest クラス見つけ出します。msdn で Forest メソッドを確認してみると CreateLocalSideOfTrustRelationship というメンバーがあります。"Creates the local side of a trust relationship with the specified forest." と書いてあるのでちょうどよさそうです。

一応 PowerShell 上でも確認してみると

PS > $sample = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()

PS > $sample | Get-Member


   TypeName: System.DirectoryServices.ActiveDirectory.Forest

Name                               MemberType Definition                                            
----                               ---------- ----------                                            
CreateLocalSideOfTrustRelationship Method     void CreateLocalSideOfTrustRelationship(string targ...
CreateTrustRelationship            Method     void CreateTrustRelationship(System.DirectoryServic...
DeleteLocalSideOfTrustRelationship Method     void DeleteLocalSideOfTrustRelationship(string targ...
DeleteTrustRelationship            Method     void DeleteTrustRelationship(System.DirectoryServic...
Dispose                            Method     void Dispose(), void IDisposable.Dispose()            
Equals                             Method     bool Equals(System.Object obj)                        
FindAllDiscoverableGlobalCatalogs  Method     System.DirectoryServices.ActiveDirectory.GlobalCata...
FindAllGlobalCatalogs              Method     System.DirectoryServices.ActiveDirectory.GlobalCata...
FindGlobalCatalog                  Method     System.DirectoryServices.ActiveDirectory.GlobalCata...
GetAllTrustRelationships           Method     System.DirectoryServices.ActiveDirectory.TrustRelat...
GetHashCode                        Method     int GetHashCode()                                     
GetSelectiveAuthenticationStatus   Method     bool GetSelectiveAuthenticationStatus(string target...
GetSidFilteringStatus              Method     bool GetSidFilteringStatus(string targetForestName)   
GetTrustRelationship               Method     System.DirectoryServices.ActiveDirectory.ForestTrus...
GetType                            Method     type GetType()                                        
RaiseForestFunctionality           Method     void RaiseForestFunctionality(System.DirectoryServi...
RepairTrustRelationship            Method     void RepairTrustRelationship(System.DirectoryServic...
SetSelectiveAuthenticationStatus   Method     void SetSelectiveAuthenticationStatus(string target...
SetSidFilteringStatus              Method     void SetSidFilteringStatus(string targetForestName,...
ToString                           Method     string ToString()                                     
UpdateLocalSideOfTrustRelationship Method     void UpdateLocalSideOfTrustRelationship(string targ...
UpdateTrustRelationship            Method     void UpdateTrustRelationship(System.DirectoryServic...
VerifyOutboundTrustRelationship    Method     void VerifyOutboundTrustRelationship(string targetF...
VerifyTrustRelationship            Method     void VerifyTrustRelationship(System.DirectoryServic...
ApplicationPartitions              Property   System.DirectoryServices.ActiveDirectory.Applicatio...
Domains                            Property   System.DirectoryServices.ActiveDirectory.DomainColl...
ForestMode                         Property   System.DirectoryServices.ActiveDirectory.ForestMode...
GlobalCatalogs                     Property   System.DirectoryServices.ActiveDirectory.GlobalCata...
Name                               Property   string Name {get;}                                    
NamingRoleOwner                    Property   System.DirectoryServices.ActiveDirectory.DomainCont...
RootDomain                         Property   System.DirectoryServices.ActiveDirectory.Domain Roo...
Schema                             Property   System.DirectoryServices.ActiveDirectory.ActiveDire...
SchemaRoleOwner                    Property   System.DirectoryServices.ActiveDirectory.DomainCont...
Sites                              Property   System.DirectoryServices.ActiveDirectory.ReadOnlySi...

大丈夫そうです。ちょっと途切れてしまっていますが、Syntax は CreateLocalSideOfTrustRelationship(string targetForestName,TrustDirection direction,string trustPassword) となっていますので、例えば一方向:出力の信頼を作成する場合、

$TargetForestName = "Domain.Name"
$TrustPassword = "H0gehQ83"
$TrustDirection = "Outbound"
$Forest = [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest()
$Forest.CreateLocalSideOfTrustRelationship($TargetForestName,$TrustDirection,$TrustPassword)

という、なんともすっきりしないコマンドレットを実行することで信頼の作成が可能です。本当に構成ができているのか確認もしておきたいですよね。では、GUI における [検証] ボタンを押すのと同じように検証をしてみます。

PS > $forest.VerifyOutboundTrustRelationship($TargetForestName)

PS >

何も出力されません。これで大丈夫なのですが、念のため誤ったドメイン名を変数に入力するとこのようなエラーになります。

PS > $fakeTargetForestName = "contoso.com"

PS > $forest.VerifyOutboundTrustRelationship($fakeTargetForestName)
Exception calling "VerifyOutboundTrustRelationship" with "1" argument(s): "A forest trust relationship does not exist 
between "Domain.Name" and "contoso.com"."
At line:1 char:1
+ $forest.VerifyOutboundTrustRelationship($fakeTargetForestName)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ActiveDirectoryObjectNotFoundException
 

PS >

このように出力されると信頼の作成に失敗していることがよくわかります（）一応、信頼の作成ができている状態だと Get-ADTrust のような形で現在構成されている信頼関係から状態を確認することもできますので、確認してみてもいいのではないでしょうか。こんな感じですね。

PS > Get-ADTrust -Filter * | Format-Table -Property Direction,Name,ObjectClass,TrustAttributes -AutoSize

Direction Name                    ObjectClass   TrustAttributes
--------- ----                    -----------   ---------------
 Outbound Domain.Name             trustedDomain               8
 Outbound hogehoge.tokyo          trustedDomain               4

ちなみに今回の記事を書くベースになった Automate Forest trust creation に記載がある通り、双方のフォレストの管理者権限をもつアカウントの情報を持っている場合は PowerShell においてもまたちょっと違った方法で信頼を作成する形となります（内容自体は GUI で実施するときと同じです）。

2014-07-08

AsSecureStringの値はパスワード欄にそのまま入れると死ぬ

PowerShell 内でパスワードの情報を扱う際に -AsSecureString というパラメーターを使ったり ConvertTo-SecureString コマンドを使ったりするシーンがあるかと思います。SecureString にしない場合はこう。

PS > $Password = Read-Host -Prompt "Enter your Password..."
Enter your Password...: Password

PS > $password
Password

-AsSecureString パラメーターを付けた場合はこう。

PS > $Password = Read-Host -AsSecureString -Prompt "Enter your Password..."
#パスワード入力のためのポップアップは表示されるが、入力した内容は伏字になる
PS > $Password
System.Security.SecureString

ということで、そのままだとパスワードの値そのものは利用できないという認識だったのですが、 Windows PowerShell 4.0 for .NET Developers を見てると次のような形で Outlook.com に接続してサインインまでしてしまおうとしていて「？」となったわけです。

$EmailAddress = Read-Host -Prompt "Enter your Microsoft Account.."
$Password = Read-Host -AsSecureString -Prompt "Enter your Password..."
$ie = New-Object -ComObject InternetExplorer.Application
$ie.visible = $true
$ie.navigate("https://outlook.com")
while ($ie.Busy){Start-Sleep -Milliseconds 500}
$doc = $ie.document
$tbUsername = $doc.getElementByID("i0116")
$tbUsername.value = $EmailAddress
$tbPassword = $doc.getElementByID("i0118")
$tbPassword.value = $Password
$tbnSubmit = $doc.getElementByID("idSIButton9")
$tbnSubmit.Click()

結構回りくどい感じですが、それよりも $Password で SecureString になっているパスワードをそのまま突っ込んでいますし、実際にこのコードを実行するとサインインに失敗します。ではどうするか。1つは SecureString を平文に戻す方法です。

$EmailAddress = Read-Host -Prompt "Enter your Microsoft Account.."
$Password = Read-Host -AsSecureString -Prompt "Enter your Password..."
$ie = New-Object -ComObject InternetExplorer.Application
$ie.visible = $true
$ie.navigate("https://outlook.com")
while ($ie.Busy){Start-Sleep -Milliseconds 500}
$ie.document.getElementByID("i0116").value = $EmailAddress
$ptr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Password)
$PasswordPlain = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ptr)
$ie.document.getElementByID("i0118").value = $PasswordPlain
$ie.document.getElementByID("idSIButton9").Click()

今回は COM を使って元のパスワードに戻していますが、それでもまだ面倒くさい感じがします。もう一つの方法は Get-Credential にアカウント情報を持たせてあげる形です。というより@guitarrapc_tech 氏が下のように言っていたのを見て、そう言えば書籍に書いてあることが間違えているのに気づいたことを思い出して書いているだけです（）

gmail に IE で自動ログインするなにかをさくっとかいてみた pic.twitter.com/z1yOkBqO6S
— guitarrapc_tech (@guitarrapc_tech) 2014, 7月 6

$cred = Get-Credential -Message "Input username for login"
$ie = New-Object -ComObject InternetExplorer.Application
$ie.visible = $true
$ie.navigate("https://outlook.com")
while ($ie.Busy){Start-Sleep -Milliseconds 500}
$ie.document.getElementByID("i0116").value = $cred.UserName
$ie.document.getElementByID("i0118").value = $cred.GetNetworkCredential().Password
$ie.document.getElementByID("idSIButton9").Click()

こちらのほうが比較的シンプルな感じでしょうか。。。他にいい方法があれば教えてくだしあ。 ※それでもやはりパスワードの情報を利用する際には GetNetworkCredential メソッドを使わないと正しくパスワード情報を得られなくて死にます。

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

それで出世が遅れ（ｒｙ

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

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

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

CloudWatch から twilio への連携図

CloudWatch で障害（その他）を検知する

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

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

電話通知を実際に受ける

あとがき

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

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

脚注

OpenStack Cloud Computing Cookbook Third Edition, Second Edition からの変更点（削除された章編）

Third Edition の目次

Second Edition の目次

Second Edition との違い（TE で削除された章編）

Chapter 10: Automating OpenStack Installations (SE)

Chapter 11: Highly Available OpenStack (SE)

Chapter 12: Troubleshooting (SE)

Chapter 13: Monitoring (SE)

FYDIBOHF23SPDLTの意味

PowerShell でフォレストの信頼を作成する

AsSecureStringの値はパスワード欄にそのまま入れると死ぬ

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

CloudWatch から twilio への連携図

CloudWatch で障害（その他）を検知する

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

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

電話通知を実際に受ける

あとがき

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

脚注

Third Edition の目次

Second Edition の目次

Second Edition との違い（TE で削除された章編）

Chapter 10: Automating OpenStack Installations (SE)

Chapter 11: Highly Available OpenStack (SE)

Chapter 12: Troubleshooting (SE)

Chapter 13: Monitoring (SE)

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