｢ハーバード流交渉術｣を読んだ

最近社内でいろいろなミーティングに参加する機会が増えてきて, その中で自分達の意見を伝えたり, うまい着地点を一緒に探っていく機会が少しずつ増えてきました. 一方で, そういう時の振る舞いや注意点など, 結構模索しながらやっていたので, 会社の同僚に教えてもらった｢ハーバード流交渉術｣という本を読んでみることにしました.

ハーバード流交渉術 (知的生きかた文庫)

なんとなく, ｢ハーバード流｣とか強そうな(?)タイトルがついているので, ｢えっ, そんな方法で!?｣みたいな, 突拍子もない飛び道具的な方法が紹介されそう... とか想像していたのですが, その予想と反して素朴というか, 手堅いというか, ｢確かにここは抑えるべきだな...｣と腹落ちの行く内容が紹介されていて, 良かったです. 具体的には, 以下の4点が基本点として紹介されています:

• 人と問題を分離せよ
• 立場ではなく利害に焦点を合わせよ
• 行動について決定する前に多くの可能性を考えだせ
• 結果はあくまでも客観的基準によるべきことを強調せよ

個人的には, 以下のような内容が意識に残りました:

• 交渉に入る前に, 交渉相手と雑談したりして関係を持つと良い
• 圧力や混乱を防ぎ, より良いコミュニケーションを実施するため, 交渉に参加する人数を制限した方が良い時もある
• 可能なら, 交渉の前の検討段階から相手に参加してもらって, その成果についてお互い責任を持てるようにすると良い
• 向き合っている問題や, 現れた意見に対して相手の気持ちになって考え, 真に欲していることを導かないといけない(利害関係を明らかにする)
• 合意形成を急ぐ前に, 視野を広げて, 双方が利害に満足出来る選択肢を考え出さないといけない
• 交渉を助けるために, 客観的な意見や数値, 慣習といったお互いにとって公平な基準を用いるべき

...これまで何度か, ミーティングに望むにあたって｢自分の意図をきちんと相手に伝えられるよう, しっかり準備しよう...｣と時間をかけて案を練って共有したところ, 相手からすると｢突然, 案(意見)が降ってきた｣ように見えてしまって, 結果として議論が紛糾するという事が少なからずあったように思っています. なので最近は, ある程度20%〜30%くらいの完成度の素案が完成した段階でステークホルダーに共有し, 意見を求めながら一緒に進めていく... というやり方を意識していて, 今のところ以前よりうまくいっているように思っています(加えて, 意見を求めて一緒に取り組むステークホルダーも, なるべく少人数になるよう配慮してみています).

会社やチームの規模が一定以上になってくると, どうしても社外はもちろんのこと, 社内のステークホルダーとも交渉する機会が増えてくると思います. そういう時に, お互い後腐れなく(特に社内のコミュニケーションで, 議論が紛糾して険悪な関係になる... というのはやっぱり避けたいですし...), 交渉する原因となった問題をうまく解決出来るようにするには, やっぱり行き当たりばったりでは乗り越えられないので, ある程度の工夫(意識)が必要だと思います. その上で, 本書は道標になってくれる本だと感じました. ミーティングに出る機会が増えて, 自分の意見を伝えたり, ステークホルダーと意識のすり合わせをする機会が増えてきた... という方におすすめです.

JPAの理事に就任することになりました

...というわけで, JPAのブログでお知らせがありましたように, 一般社団法人Japan Perl Associationの理事に就任することとなりました.

blog.perlassociation.org

Perlは自分にとって, まさに｢青春の言語｣という立ち位置だと思っていて, Perlを通じて多くの人と出会うことが出来ましたし, そこから多くのことを教えてもらって, 育ててもらったと思っています.

昨今, Perlを取り巻く状況は年々厳しくなっていると思っていますが, とはいえプロダクト開発の中でガッツリと, あるいは日々の業務を支えるスイスアーミーナイフとしてPerlを仕事で使っている方, 更に趣味としてPerlを楽しんでいる方もまだまだいらっしゃると思っています.

JPAの理事として, そういった方々と, そのコアとなるコミュニティを引き続き支えていけたらいいと思います. 新体制となるJPAを, これからもどうぞよろしくお願いいたします.

｢Web System Architecture研究会｣に参加させて頂きました

websystemarchitecture.hatenablog.jp

京都で開催された, ｢Web System Architecture研究会｣, 通称WSA研に参加させてもらいました.

WSA研は参加者全員発表型の研究会なので, 今回は｢GPGPUを活用したWebサービス開発のこれからに関する考察｣というタイトルで発表を仕上げていったのですが, 正直大学院の頃の学会発表とか修論発表会よりも緊張しました... とは言え, 本職の研究者を含めた多くの方から感想やフィードバックをもらえたのは, 本当に良い機会だったと思います.

発表もかなり勉強になるものが多くて, id:y_uuki さんの｢エッジコンピューティングに向けた分散キャッシュ技術の調査｣とかは, はてなブログが今以上にスケールしていった時に活かせそうな話題だなー, と思いながら聞いていました. id:matsumoto_r さんの｢CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法｣とか, monochromeganeさんの｢Ebira: Webサービスの特性に依存しない汎用的な付加的オートスケール機構｣とかも, 非常に興味深かったです.

あとは, 研究として作るプロダクトでk8sを試してみようと思っている... といったお話を大学で研究されている本職の先生がお話されていて, なんというか自分が大学生だった頃より, 研究の世界とWebサービス開発の世界が, もっともっと近づいているんだな... というのを感じた気がします(もしかしらたら, 元々近かったのだけれど, 自分が大学生だった頃は視野が狭くて, 気づけていなかったのかもしれないですね...).

今後, Webサービスはどんどん増えていくし, その中で大規模化するもの, データ量がどんどん増えていくもの, 高速に処理しないといけないものなど, いろいろな種類のWebサービスが登場して, 高機能化/高性能化の果てに, その開発や運用はどんどん難しくなっていくかもしれません. そういう中で, Webサービス開発の現場から生まれる技術やツールだけでなくて, 研究の現場から生まれてくるアイデアや成果を, Webサービス開発の現場において, うまく取り込んでいく必要性は, もっともっと出てくるように感じています. 逆に, 研究の場でも, Webサービス開発の現場における様子や課題感を知ったり, そこで使われている技術やツールをキャッチアップしていく必要があったりするのかもしれません. WSA研は, Webサービス(Webシステム)とそのアーキテクチャという領域で, 開発の場と研究の場が交流し, 情報交換ができる, 良い場所だなあ... と思いました.

今回は初めての参加ということもあって, ちょっと気負いすぎて(?)｢研究｣っぽいネタを持っていった(つもり)なのですが, 先に書いたように, 自分はWSA研に対して｢開発の場と研究の場が交流し, 情報交換ができる｣場であると感じたので, 次に参加する機会があれば, ｢Webサービス開発の現場で直面した課題と, その解決策や考察｣みたいな, もう少し自分が今立っている, Webサービス開発の現場に寄った話題を話せれば良いのかな... と思いました. 機会とネタがあれば, またぜひ参加してみたいと思います.

技術書典6で頒布される｢Hatena Tech Book｣に｢障害対応五訓｣という記事を書きました

developer.hatenastaff.com

というわけで, こちらのエントリで紹介されている｢Hatena Tech Book｣に, ｢障害対応五訓｣という記事を書きました!!! こういう感じの序文となっております.

Webサービスを運用していると，さまざまな障害と出会います．当然，そんな障害とは一切出会わずに済むのが一番ではあるのですが……．とはいえ，どうしても立ち向かわなければならないときがあります．
これまで5年ほど，業務としてWebサービスの開発や運用に携わってきて，さまざまな障害と直面し，たくさんの成功や失敗を経験してきました．
その中で，障害に立ち向かう際に求められる振る舞いや，解決に至るために必要なアクションについて，いくつかの気付きを得ることができました．
そのような知見を，「障害対応五訓」としてまとめてみたので，紹介します．

斬新な内容とかはなくて, 割と当たり前なことを自分なりの言葉で改めてまとめてみた... という記事ではあるのですが, とはいえ障害対応という場面だからこそ, 当たり前の事を当たり前にこなすのがまず大事で, そこで大事なことを改めて文章化出来たのは非常に有意義だったなーと思います.

｢技術書典6｣の当日は, ｢え40｣にて頒布されているそうなので, 興味のある方はぜひ足を運んでみてください! ...ただ自分は, 開催当日にSFC修行をしてるので現地にはおらず沖縄から様子を伺う感じになると思います. よろしくおねがいします.

2019/05/17 追記

papix.hatenablog.com

本文をブログで公開しました.

｢振り返り｣などの司会を他チームの人にお願いするという選択肢

期初/期末であったり, プロジェクトの終了だったりといった節目に｢振り返り｣をして, 良かったことや課題をチームで見つけ, 次に向けたアクションを考えるのは非常に重要です.

これまで, 振り返りの司会はチーム内でアサインすることが多かったのですが, 最近社内で｢他チームの人に任せる｣という選択肢が流行っているので, そのメリットなどを書いてみます.

関係者全員が｢振り返り｣に集中出来る

これはかなり大きいメリットでした. これまで｢振り返り｣をするときは, チームの責任者であったり, スクラムマスターが司会をすることが多かったですが, どうしても司会の役割を任された人は, 進行に集中する必要があり, 十分に振り返りに参加できないという事がありました.

特に, プロジェクトの中でリーダー的な役割をしていた人が司会をすることになると, その人が体験してきたこと, 気づいたことをうまく｢振り返り｣の場で引き出すことが難しくなります. 他チームの人に任せることで, こういった状態を回避しやすくなりました.

｢振り返り｣を通じて知見の共有が出来る

チームに閉じて｢振り返り｣をしていると, どうしても出てくるアイデアやアクションは, チームメンバーが持っている知見に閉じてしまいがちです. また, 振り返りのアクティビティも固定化されがちです.

他チームの人に司会をお願いすると, 例えば｢○○のような課題があった!｣という話題になった際, ｢自分のチームでは, そういう時に✕✕のような対策をしました｣というように, 他チームの事例をアドバイスしてもらうことができます. また, 逆に司会として参加した他チームの人も, ｢このチームの△△はいいな!｣というように, 自分のチームに還元できる部分を見つけることができます.

このように, 他チームの人に｢振り返り｣の司会をお願いすると, ｢振り返り｣を実施するチームにとっては新しい視点が得られるようになり, 加えてあるチームの｢振り返り｣の成果が, 他のチームにも繋がっていくことが望めるようになりました.

社外のファシリテーターを招くより, 調整が容易

これまで紹介してきたメリットは, 社外のスクラムマスターなどをファシリテーターとして招聘することでも実現できます. しかし, そうすると費用面であったりスケジュール面であったり, いろいろと考慮するポイントは多くなります.

社内の他チームの人にお願いするのであれば, そういった問題の一部は考慮しなくて良くなります. また, ｢振り返り｣を実施するにあたっての前提条件(例えばどういうプロジェクトで, どういう人が参加しているのか等...)の共有も, 最低限で済みます.

ありがたい事に, 最近社内の幾つかのチームで｢振り返り｣を設計し, 司会させてもらう機会があったのですが, だいたい準備に2時間前後, 実施に2〜3時間くらいで, 1営業日あればギリギリいける... くらいの時間で済みました. 外部の方を招聘するのであれば, 守秘義務の締結で普通にガッツリ時間が取られたりするので, 特にサクッと(?)｢振り返り｣を実施するときは, 社内で司会をアサイン出来ないか検討出来ると良いのではないかと思いました.

ここまでメリットを述べてきましたが, 社内の人に｢振り返り｣の司会をお願いする際の課題として, 参加者全員が同僚ということもあり, 司会が意識して行動しないと, 参加者全員が｢空気を読んでしまう｣可能性が否定できない, という点があります. そういった状況を確実に防ぐには, 社外のファシリテーターを呼んで司会を担当してもらった方が良いと思います.

社内の他チームの人に｢振り返り｣の司会をお願いするのは, これまで述べてきたように多くのメリットがありますが, とはいえ社外のファシリテータを招く, という選択肢も引き続き存在します. そのため, 時と場合によってこれらの選択肢を使い分けることが重要そうです.

まとめ

｢振り返り｣の司会を他チームの人に任せることによって得られるメリットについてご紹介しました. もしかしたら, こういった取り組みを日常的に実施している会社もたくさんあるかもしれませんが, 自分たちの場合は最近こういう選択肢が増えてきて, それによって良い体験が出来ているので, ご紹介してみた次第です.