Masteries

技術的なことや仕事に関することを書いていきます.

Devel::KYTProfに送ったパッチが取り込まれました

metacpan.org

Devel::KYTProfで, Furl::HTTPのProfilerが一部環境下で正しく動かない(warningメッセージが出る)のを解決するPull Requestを送ったところマージしていただき, 0.9993としてリリースされました.

github.com

これまでのFurl::HTTPのProfilerは, 下記のような使い方では正しく動作しますが...

my $furl = Furl->new;

my $res = $furl->get('https://papix.net');

下記のように, requestを使った場合はうまく処理出来ず, warningメッセージが出るようになっていました.

my $furl = Furl->new;


my $res = $furl->request(
    method => 'GET',
    scheme => 'https',
    host   => 'papix.net',
);

0.9993以降では, 後者のように記述しても正しくプロファイルが実施され, またwarningメッセージも出ないようになっています.

Devel::KYTProf::Profiler::AWS::CLIWrapperをリリースしました

Devel::KYTProfに対するAWS::CLIWrapper用のプロファイラー, Devel::KYTProf::Profiler::AWS::CLIWrapperをリリースしました.

metacpan.org

最近行われたDevel::KYTProfの大改良で, 独自のプロファイラを定義出来るようになったので, AWS::CLIWrapper用のプロファイラを用意してみました. Devel::KYTProfの変更については, 下記の id:Songmu さんのエントリを参照しましょう.

songmu.jp

とりあえず, かなりシンプルな実装になっていて, 現状では"AWSのサービスに対して(AWS::CLIWrapper経由で)どのような操作を実施したか"のみをプロファイリングするようにしています. 今後の展望としては, 各種操作に対するオプション(パラメータ)なども表示出来るようにしていけると, 更に便利に使うことができそうですね.

また, Deve::KYTProf + Devel::KYTProf::Profiler::AWS::CLIWrapperに, id:sfujiwara さんの AWS::XRay を組み合わせれば, PerlのバックエンドサーバからAWS::CLIWrapperを使って, AWSの操作にどれくらい時間がかかっているか... という部分をトレースすることが出来るようになります.

この辺りの話題を, 今週〜来週にかけて開催する「Hatena Engineer Seminar」で話そうと思っているので, 興味のある方はぜひご参加ください(宣伝).

hatena.connpass.com

hatena.connpass.com

「失敗の本質」読んだ

失敗の本質―日本軍の組織論的研究 (中公文庫)

失敗の本質―日本軍の組織論的研究 (中公文庫)

  • 作者: 戸部良一,寺本義也,鎌田伸一,杉之尾孝生,村井友秀,野中郁次郎
  • 出版社/メーカー: 中央公論社
  • 発売日: 1991/08/01
  • メディア: 文庫
  • 購入: 55人 クリック: 1,360回
  • この商品を含むブログ (304件) を見る

id:shimobayashi さんが下記のブログエントリで紹介していて, 「面白そう!」と思って買って読んでました.

shimobayashi.hatenablog.com

この本は, 第二次世界大戦前後における日本軍の6つの戦い, つまりノモンハン事件, ミッドウェー海戦, ガダルカナル島の戦い, インパール作戦, レイテ沖海戦, そして沖縄の戦いという, 6つの戦いを通して, 日本軍がそれぞれの戦いで敗北に至った理由を, 組織論の観点で考察している本です. 戦史の研究家と組織論の研究家が協力して作り上げた本なので, 論ずるにあたっての前提となる, それぞれの戦いの経緯や経過なども非常に丁寧に書かれていて, そういう意味では「組織論」の本としては極めて異色と言えるかもしれません. 歴史が好きな人にとってはかなりとっつきやすい(?)組織論の本, と言えるかもしれません.

本書は, 大きく分けて3つの章によって構成されています. まず1章はケーススタディとして, 先に挙げた6つの戦いにおいて, その前提(どのような経緯があり, それを踏まえてどのような作戦が立案されたか)や実際の戦における経緯(どのような出来事があり, どのような判断が成されたか)が紹介されます. その中で, 日本が敗北に至った(あるいは, 敗北による影響をより強めてしまった)日本軍の問題点が取り上げられていきます.

先も述べたように, 戦史の研究家が関わっているということもあって, それぞれのケーススタディは経緯や経過が非常に丁寧に綴られていると感じました. とはいえ, ケーススタディにおける戦史の解説は, あくまで考察のための一要素なので, 各々の戦いの"全ての経過"が紹介されている訳ではありません. なので, (そんな人はいないと思いますが...)本書を戦史の本として読むと, 非常に不完全燃焼という感想になってしまいそうです.

2章と3章は, これらのケーススタディを元にして, それぞれ「日本軍の失敗の本質は何か」, 「その失敗の本質から何を教訓として得ることが出来るか」について解説されています. 特に印象深かったところは「分化」と「統合」について述べている部分で, 引用すると,

組織の環境適応理論によれば、ダイナミックな環境に有効に適応している組織は、組織内の機能をより分化させると同時に、より強力な統合を達成しなければならない。つまり、「分化(differentiation)」と「統合(integration)」という相反する関係にある状態を同時に極大化している組織が、環境適応にすぐれているということである。「分化」というのは、上述の引用が示唆しているように、環境特性によって、組織の構成員の目標、時間、人間関係についての態度やものの見方が違ってくるということである。

組織が大きくなると, 機動力を維持するためにも, うまく「分化」していくことを考えがちです. しかし, それだけでは不十分であり, 「分化」はもちろん実施した上で, より強力な「統合」も成し遂げなければならない... と書かれています. この視点は自分自身なかったので非常に参考になりました. また, 日本軍と米軍の組織構造の違い, すなわち陸軍や海軍といった各軍を統括する組織の権限や役割についての考察も印象深かったです.

この辺りを含めて, 最近感じていた現職の組織的な課題を, うまく言語化している部分が多々あって, かなり勉強になったと思います. 一方で, 本書では「失敗の本質の考察と教訓」について述べるにとどまっていて, そこから今現在日々を過ごしている組織に対して, どのようにアクションを取っていくことができるか... という部分は取り上げられていません. とはいえ, 組織の問題点を丁寧に解説している本書は, 自分たちの組織の問題点を言語化していくにあたっての道標になってくれる事は間違いないと思います. そして, 問題点を言語化することができれば, その解決に向かってかなり前進することが出来た... と言えるのではないでしょうか. 所属しているチームや組織に対して, 何かうまく進めていない感じもするけれど, その原因をうまく表現できない... そういった時に読んでみるとたいへん気づきのある, 良い本だと思います.

次は「人を動かす」を読む予定です.

「Hatena Engineer Meetup」を沖縄で開催することになったので, 登壇します!!!

hatena.connpass.com

はてなでは, 「Hatena Engineer Seminar」というエンジニア向けのイベントを開催しているのですが, これまではオフィスがある東京や京都で開催することがほとんどでした 今回, 「それ以外の場所でもやってみたい!!!」ということで, 「Hatena Engineer Meetup」という名前のもと, 沖縄で開催することになりました!!! 自分とSREの id:cohalz が沖縄に行き, はてなの紹介や技術にまつわるトークなどをします.

学生の方はもちろん, はてなやはてなのサービスに興味がある社会人の方も大歓迎です. 諸事情により日曜日開催ではあるのですが, この機会に是非沖縄の皆さんと交流できればと思っています. 是非ご参加ください!!!

「より良いミーティング」を目指して意識していること

最近, ミーティングをセッティングする機会が徐々に増えてきました. 業務の中でミーティングを開催するということは, 同僚の有限な作業時間を拘束することになるので, なるべく有意義に, 生産性が高くなるように実施したいものです. それを実現するために, 個人的に意識している3つのポイントを紹介します.

はじめに

一言でミーティング... と言っても, いろいろな種類のミーティングがあると思います. 個人的には, 少なくとも3つの種類があるのではないかと思っています.

  • 収束させるミーティング
  • 発散させるミーティング
  • チームのためのミーティング

「収束させるミーティング」は, いわば"決めるため"のミーティングです. なにかしらの前提情報があり, それに基づいていくつかの選択肢が考案された状態で, その中のどれを選択するかを協議する(時と場合によっては, 用意された選択肢から採択をせず, 別途新しい選択肢を考え直すという結論に至ることもあるでしょう)... 要するに意思決定のためのミーティングです.

一方で, 「発散させるミーティング」は, いわば"アイデアを出す"ためのミーティングです. 前提情報や現状分析の結果などを元に, ブレインストーミングなどの手法で, 選択肢(アイデア)を出すためのミーティングと言えるでしょう.

最後の「チーム運営のためのミーティング」は, チームの相互理解を深めたり, チームの開発サイクルを回すためのミーティングです. 例えばチームビルディングのための会であったり, スクラムを採用しているのであればスプリントの計画会や振り返り会などが該当します.

これを踏まえて, この記事では特に「収束させるミーティング」をセッティングする時に考えている事を紹介します. 具体的には, 以下の3点です:

  • 30分で終わることを目指す
  • 最少人数になるよう招待する
  • 事前にアジェンダを作って共有する

30分で終わることを目指す

長いミーティングは参加する側としても大変です. 更に, 時間が長くなれば長くなるほど, 多くのメンバーの作業時間を拘束することになります. そのため, ミーティングをセッティングするにあたっては, なるべく短い時間で議論が終わり, メンバーの時間を拘束しすぎないように工夫するのが極めて重要であると思います. 話す事柄(議題, 決めたい事)の数にもよりますが, 大抵の場合は30分で終わるように意識すると良いのではないかと思っています. そのためにも, 後述する「最少人数になるように招待する」や, 「事前にアジェンダを作って共有する」といった部分を意識しながら事前準備をしておいて, ミーティングそのものはなるべく短い時間で終わるように工夫するのが, ミーティングをセッティングするにあたって大事になってきます.

例えば, 5人で実施するミーティングがあったとして, そこに準備なしで挑む代わりに1時間が必要になったとすれば, 1時間 x 5人で5時間を使うことになります. 一方で, ミーティングをセッティングする人が1時間の事前準備を実施し, その成果を他の4人が事前に5分かけてチェック, それによってミーティングが30分で終わるのであれば, 事前準備の1時間, 事前チェックの40分(5分 x 4人), そしてミーティングに30分 x 5人 = 2.5時間なので, 合計で4時間10分になります. 50分の時間が浮きますね.

たまに, 今後のアクションなどを決める(= 収束させるミーティング)なのに, 最初の10分〜20分を使ってその前提状況や選択肢について長々と説明してしまう事があるように思います. もちろん, 重要な部分については仮に事前に資料などを配布していたとしても, ミーティングの場で改めて共有/確認する必要はあると思います. とはいえ, 事前に資料を提供することもせず, ミーティングで初めてそれを展開して, 全てを説明してから本題に移行する... というのは, 結構時間の無駄なのではないか? と感じています.

また, 「30分で終わることを目指す」と, ここまで述べた「拘束時間を短くできる」以外にもメリットがあると思っています. 例えば会議室不足の解消に寄与できる, というメリットがあると考えています. 最近メンバーが増えて, 会議室が足りなくなってきている... という問題に直面している方は案外多いのではないでしょうか. そのような状況で「30分で終わることを目指す」ことは, 会議室の回転率を上げ, 結果としてより多くのミーティングを会議室で実施出来るようになる(会議室探しで苦労することが減る)のではないかと思います. そのように考えると, 「1時間で終わるかどうか微妙なので, 念の為1時間抑えておく...」というのは, 非常に良くないアクションだと思っています. 仮に30分で終わった時, 残りの30分間にわたって会議室が無駄になってしまうからです.

...そもそもとして, ミーティングが30分で終わらなかった場合, 30分延長するのではなく, むしろ別のタイミングで30分のミーティングをセッティングした方が良いのではないか... と最近は思っています. もしミーティングが予想以上にヒートアップしてしまったのであれば, 時間をある程度置くことでクールダウンすることができます. また, 30分話した事を元にして再び事前準備を実施することで, 次の30分はより準備の出来た状態でミーティングに望むことが出来るはずです.

より良いミーティングができるかどうかは, ミーティングでどのように話すか, 議論するか, 説明するかではなく, むしろミーティングが始まる前からの準備にかかっている... と言っても良いでしょう. そのためにも, 「30分で終わらせる」ことを意識し, そのために必要な準備を丁寧に済ませておく... というのが, ミーティングをセッティングするにあたって重要であると考えています.

最少人数になるよう招待する

前述した, 「30分で終わることを目指す」ためにも, ミーティングの人数は極限まで絞るのが重要であると考えています.

ミーティングを実施するにあたって, 人数を増やすことは2つのコストが増加します. 1つは単純で, ミーティングによって費やされる時間が線形的に増加します. 30分のミーティングであっても, 10人で実施すれば30分 x 10人で300分の時間が費やされることになります. 加えて, 「収束させるミーティング」においては, 収束させるためのコストが指数関数的に増加すると思っています. 何かしらを決めたり, 議決するためのミーティングにおいては, 参加する全メンバーが同じ認識を共有して, それに基づいて意思決定をしなければいけません. しかし, 参加するメンバーが増えれば増えるほど, 認識を共有するコストは増えていきます. 話を聞き逃してしまったり, 勘違いしたり, 時と場合によっては意図的に曲解されてしまう事があるかもしれません. その結果として, 議論が紛糾して, 予想以上にミーティングに時間がかかってしまう......... そういった事態を防ぐためにも, 正しい決定が出来る範囲で, ミーティングに参加する人数を絞る必要がある訳です.

例えば, 2つの部署が連携して, ある施策を実施しており, そのための意思決定をしなければならない場合を考えます. この時「念の為...」という気持ちで, 自分たちの部署のリーダーや, 相手部署のリーダーと, エンジニアと, プランナーと... といった風に参加者を増やしてしまえば, ミーティングのコストはみるみる高騰していきます. そうならないためにも, ミーティングで意思決定したい事項について, 一番責任を持っている人(判断が出来る人)を必要最小限かつピンポイントに招集するのが重要であると考えます.

もしも技術的な話題が主なのであれば, お互いのチームのエンジニアリーダー的なポジションの人を呼べば, 意思決定を行うにあたって必要十分なはずです. また, 企画や機能要件などの話題であれば, 真っ先にミーティングの参加者候補として名前が挙がるのは部署のリーダーになるかもしれません. ...が, 自分たちのチームや相手のチームをよく観察すると, ミーティングで話したい話題についての権限が, 他のメンバーに委譲されている場合もあると思います(自分たちの部署と連携している施策については, 相手部署においてチームリーダーではなくプランナーの人が権限を持っている... など). そういう場合は, 権限を委譲されているメンバーを中心にミーティングに招集することを意識しなければなりません.

事前にアジェンダを作って共有する

経験則として, アジェンダのないミーティングは迷走しがちです. アジェンダがないミーティングは, 何を話すか, 何を決めるかについて, 参加者が各々の考えを持って参加することになるので, 意見が噛み合わなかったりしがちです.

そのため, より良いミーティングを目指すためには「事前にアジェンダを作って共有する」ことは必要な条件であると考えています. 少なくとも, 以下の3点を事前に参加者に対して共有する必要があるでしょう:

  • 誰が参加するか
  • 何について話すか
  • 何を決定したいか

加えて, 事前にチェックしておくべき資料があれば, それも共有しておくと良さそうです.

さて, このように事前にアジェンダを作っておく事は, 幾つかの利点があります.

まず1つは, そもそもミーティングを実施する必要があるかどうかをチェックできる, という点です. 特に, 先に挙げた3つの項目のうち, 「誰が参加するか」, 「何について話すか」は定まっていて, 「何を決定したいか」が不明瞭な場合, 「ただ単に共有がしたいだけではないか...?」と気づくことが出来ます. 内容にもよりますが, 単に共有がしたいだけなら, グループウェアやSlackなどのチャットツールで共有することができれば, ミーティングで時間を拘束することなく目的を果たせるはずです.

もう1つは, フィードバックを受けて, アジェンダをブラッシュアップ出来るという点です. 事前にアジェンダを共有することで, 「この人も参加するべきでは?」とか, 「この観点についても話す必要あるのでは?」とか, 逆に「これは話さなくても良いんじゃない?」といったフィードバックが得られることがあります. それを元にアジェンダを修正していけば, より有意義なミーティングが出来るはずです. 結果として, ミーティングが始まった後に「この人も呼ぶ必要があるのでは?」とか, 「これは話さなくてもいいのでは?」といった話題が登場して, 「なるほど, また別途ミーティングを開きましょう...」となり, 結果として集まった時間が無駄になってしまう... という事態を防ぐことができます.

最後の1つは, アジェンダを事前に用意することによって, ミーティングの流れやゴールのイメージを予め全員で共有することができるという点です. ミーティングを実施するにあたって, 話したい事や決めたい事についてのイメージが参加者の間で異なっていると, 大抵の場合迷走してしまいます. 事前に共有するアジェンダは, そういった迷走を防ぐ, 「ミーティングの水先案内人」の役割を果たしてくれる訳です.

まとめ

「収束させる(決める)ミーティング」を主催するにあたって, 意識していることを3つ紹介しました. 結論から言えば「事前準備で決まる」という一言に収束出来ると思っています. とはいえ, その準備に時間やコストをかけすぎると本末転倒で, とはいえ準備しないと(前述のように)無駄が多くなったり, 迷走したりするので, 程よいサイズ感の事前準備が求められる, という気がしています.

どうしても, 複数人/複数部署で仕事などをするにあたっては, ミーティングというアクションが必要になってくると思います. 皆さんは, ミーティングに望むにあたって, あるいはその準備をするにあたって, どういったポイントに気をつけていますか? 何かしら意識していることがあるという方は, 是非はてなブックマークのコメントなどで教えて頂けると勉強になります.

これからも, より良く有意義なミーティングが出来るよう, 試行錯誤していきたいと思っています.