シン・アジャイル「社内勉強会をゼロ負荷で実施するために [組織の芯に社内勉強会を宿す]」

久しぶりにオンライン勉強会に参加した。

社内勉強会の実施についてである。

なお、個人的に思っているのは組織内勉強会は定着するまでに時間もかかり、

その間、なんで勉強会やるの？意識高い系？とか耳障りの悪い言葉を聞かされることも多く主催側が挫けることが多いと思っている。ただ、定着していくにつれて運営負担も減っていくし何よりも組織に対して大きなムーブメントを作ることが出来る試みであると確信している。

下記、速記記載する。具体的な20個のプラクティスは示唆に富む。

「◾️社内勉強会をゼロ負荷で実施するために 〜組織の芯に社内勉強会を宿す〜」

• そもそも
  • アジャイルの知見を共有する社内勉強会が必要
  • 社内勉強会は躓きやすい
  • 「社内で上手くいかないから、社外でやろう」ということではなく、あくまでも各社毎の社内勉強会をグロースさせる」
  • 社内勉強会を挫けず実施する上での戦術
• 社内勉強会を実施する上では「立ち上げ」「巻き込み」「運営自動化」で進めていく
  • 立ち上げフェーズ
    • 1.一人で始める、続ける
      • 始めるのはぼっちだが、勇気を持って情報発信し続ければ仲間と自然に出会える
    • 2.勉強会実施の負荷を下げる
      • ゼロコスト運営を意識。開催頻度を多くする必要があるためなるべく楽に
        • 先人が作ってくれた資料を流用する
        • ネタをストックしておく
    • 3.コンテンツの難易度を下げる
      • 準備は大変という先入観を払拭させる（Youtubeを皆で見る、カンファレンスの記事、技術記事を見るだけ）
    • 4.参加のハードルを低くする
      • ルールを作ってハードル上げない。聞き専でもOK
        • 開催時に目的、グランドルールを設定
        • 初心者歓迎。参加するメリットをわかりやすく
    • 5.参加の準備運動をする
      • 勉強会での良い「ふるまい」を最初に練習してから始める
        • 行動しやすいツールを整理する
        • 最初に書き込む練習をする
  • 巻き込みフェーズ
    • 6.コアな人たちから広げていく
      • 何をやるのかの前に、誰とやるのかを決める
      • 参加してくれる人を指定で呼ぶ
    • 7.社内コミュニティを作る
      • 勉強会運営を頑張りすぎず、コミュニティ作りに重きをおく
        • 少人数からでも作ってみる
        • ゆるくてもOK
    • 8.社外コミュニティを活用
      • 社内勉強会は挫けやすいため、勉強家の悩みを社外のコミュニティで相談する
    • 9.社外の有識者を活用する
      • 外部の有識者は、Tweet1つくらいで意外と来てくれる
    • 10.Whyを明確化する
      • 何のための勉強会なのか明確にする
        • 参加で得られるOUTCOME
        • 実施者／運営者としての目的
    • 11.社内へアピールする
      • 宣伝について楽に継続的に実施。外からでも雰囲気がわかるようにする
        • 勉強会に参加しやすい空気を醸成する
    • 12.上司の後ろ盾を得る
      • 偉い人を巻き込んで、みんな参加しなよ！の空気を作る
        • 勉強家に参加することが日常の空気となるように、徐々に仕立てていく
    • 13.業務にする
      • 業務の一環として勉強家にやる
      • テーマを業務の内容と絡める
  • 運営自動化フェーズ
    • 14.定例で実施されるよう仕組み化定期的に集まる（まず集まるを重きに置く）
      • 案件振り返り→勉強会を定例化前回の内容を忘れていたとしても集まる
    • 15.ネタ集めを運営化
    • 16.いろんな参加者
      • 段階的内容を意識した複数のレベルの参加者が長く続く秘訣
        • 毎回参加。参加して気になったら質問するという層だけをスコープにしない
    • 17.勉強会運営を改善
      • アンケートや振り返りで勉強会小野運営自体をカイゼン
    • 18.実施する時間のコツ
      • 昼ごはん前、夕方が狙い目。テーマによっては60分。30分
    • 19.メンバー間コミュニケーション
      • 勉強会がコミュニケーションが取れる場になると良い
        • ワークショップ型
        • 読書会
        • アクティブ・ブック・ダイアローグ
    • 20.勉強会自体の有用性評価
      • 勉強会参加が本業に有用な点を評価する
      • 勉強会を評価
• その他
  • アーリーマジョリティ向けには「業務にする」というのが良い
  • 心を折る上司の声「またお勉強？（成果上がるの？）
    • 企業における研修（勉強会）評価は、
      • 日々の経営・現場にインパクトを出せること
      • インパクトに繋がる観点（勉強会のプロセスは経営プロセスと類似）
        • 勉強会を受けたメンバーが日々の業務でイキイキと機能発揮
        • コミュニティ運営自体が、会社の働き方に影響を与える

ご登壇の方はおそらく大変な苦労もあったであろうと思う。

このようにきちんと体系的にアウトプットするところもまた勉強会実施をリードする人の素養なのかと感じた。

読書「エンジニアリングマネージャーのしごと」

プロジェクトマネージャーという仕事は本当に難しいと思う。技術を追求しコードを書いていてお金を貰えてたときと違って、「人と仕事をする」というのにはテクニックも必要であるし、自分がどんなチームを作っていきたいのかというステージで仕事をすることとなる。

プロジェクト関係の書籍は多く何冊も読んできたが、最近のトレンドとも言える1 on 1の方法やギルドの組成など。新しい観点が多く読んでいて終わりを迎えるのが寂しくもなった。新人マネージャーや新しいチームで働く人におすすめの一冊。

エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

本書が一貫して伝えてくるメッセージ 

書籍の中で繰り返し述べられているのは、以下である。

「マネージャーのアウトプット ＝ あなたのチームのアウトプット＋あなたが影響を与えた他のチームのアウトプット」

• 自分のチームのアウトプットを最大化していくにはどうすればよいか
• アウトプットを計測するにはどうすれば良いのか
• 他のチームにどう影響を出していくのか

いずれも具体的な方法が紹介されている。

特に刺さったポイント

• 1 on 1でのフィードバックで、最良かつ簡潔なアドバイスは徹底的な本音。受け手に対する過剰な配慮は受けての成長につながらない。摩擦の回避を重視すると良い行いも悪い行いも無視されてしまう。
• 上司とパフォーマンスについて話をする。上司はマネージャーたる自分にどんなパフォーマンス期待を持っているのかを話をし目線合わせ。これによってチームが成果を上げる基準も明確にできる。1on1は上司に対しても行うものだ。
• タスクの委譲にはレベルがある。丸投げとマイクロマネジメントの間には段階がある。
• 委譲するにしても、説明責任と実行責任の二つのうち説明責任はマネージャーたる自分にある。この説明責任を守れない委譲は適切ではない。
• 個人とチームの成長について、マズローの欲求階層をもとに考え、「自己実現欲求」を叶えていくことを支援する。例えば技術セミナーの参加助成など
• 他のチームに対してナッジングする。ナッジングとは「他のチームが考えていた意思決定に対して、もっと効果的に決断できるように誘導すること」。誘導というと悪い言葉のように見えるが、良い方向に影響を与えるということである。
• メンタリングとコーチング。メンタリングの関係は指導的。コーチングの主な焦点は、会話を相手の興味に沿ったものにすること。これによって自分自身で問題を解決できるようになる。
• 仕事の成果を示す一番普通のやり方は、ステールホルダーに頻繁に状況報告を行うこと。当たり前のことのように読めるが基本原則。これいによって反応やフィードバックを受け双方向であることを意識する
• スコープ定義の上でタスクにはラベルをつける。「Must」「Should」「Could」「Wan't」。チームが繁忙期になった時に「Must」のみに特化して、「Should」は次のスプリントで対応するなど、チームとしての優先順位づけを見える化する。
• マネージャーは「他人を通じて仕事をしている。これがマネージャーの仕事である。これが優れたマネージャーの仕事である」

まとめ

本書を通じてマネージャーは「他人を通じて仕事をしている」という意味がよくわかる。現場によくいる工数管理と予算管理だけしているマネージャーには誰しもなりたくないはずだ。他人の力をフルに発揮できるようにするのもマネージャーの仕事であるし、説明責任はたえず自分が持ち丸投げするような弱いマネージャーではあってはいけないと改めて思う。

なお、本書では思考エクササイズも多く紹介されている。チームで読みあわせするのも良さそうだ。

読書「プロジェクトのトラブル解決大全」

ITプロジェクトでは、大小はあるものの炎上と呼ばれるプロジェクトに遭遇することがある。

• バグだらけのシステム改修
• 要件が曖昧でユーザとの認識に不一致が後工程で出てくる（ウォーターフォール）

今回取り上げる書籍は、著者が過去に直面した炎上プロジェクトに対する火消し術である。

プロジェクトのトラブル解決大全　小さな問題から大炎上まで使える「プロの火消し術86」

本書はプロジェクトリーダーを想定読者として記載されている。例えばプロジェクトメンバーのモチベーションを上げる方法や、対応期限が逼迫する中でいかに優先順位をつけて決断していくのか。いずれもリーダーとしての目線を大事にしている。

本書が一貫して伝えてくるメッセージ

炎上プロジェクトにおいて奇跡はなく、地道な課題解決を突き詰めていくことが大事と著者は伝える。この突き詰めていくというのは言葉にすると簡単ではあるが、実際には難しいのだ。この過程にはリーダーの決断も必要である。決断するには勇気がいる。同書の中では「腹をくくる」という言葉が出てくる。腹をくくらないと勇気を持てない。

気持ちの問題にもフォーカスしつつ、課題管理とWBSと体制図と進捗報告資料の現物確認で何を見るべきなのか、プロジェクトにおいて特定の兆候が見られたらどうするのかなど、すぐに活用できるメソッドも多く伝えてくれる。

特に刺さったポイント

1. 担当者がアサインされていない課題管理表はリーダーの気の弱さが表されている。難局打破のためにはメンバーに遠慮しすぎてはいけない。それで嫌われてしまうかもしれないが、それでもプロジェクトの完遂のためには無理なお願いも申し入れする機会も出てくる。課題管理表はリーダーを表すのではないだろうか。他にもダメなかだり管理表には次の傾向があるとのこと。同じような体験をした諸兄もいるのではないだろうか。① 課題内容がわからない ② 担当者がブランク、もしくは複数名書かれている ③ 期限が設定されていない ④ 課題提起した人を担当者にしてしまう  
2. 仮説検証は一人で考え抜く。プロジェクトが陥っている状態の深掘りと解決策の模索。これらを余計なバイアスを入れず現状をありのまま捉えて解決策を出していく。何が問題であるかなどメンバーにヒアリングしながら民主的な解決策を出していくことが最適解と思っていただけに、なるほどなと思った。
3. 直接工数と間接工数。いわゆる報告会議などの間接工数を下げていき、直接工数たる作業に注力していく。一見当たり前であるがこの間接工数を下げていくためにリーダーが会議を30秒で終了判断（もちろんダメな点を伝えて次の機会を作った上でである）をするなどはポイントである。
4. メンバーとの飲み会は立食形式。メンバーとの交流をやりやすい形にするためにゲームなども用意する。このご時勢では飲み会を開くのも一苦労かもしれないが結局はプロジェクトは人である。コミュニケーション大事

まとめ

本書は炎上プロジェクトにリーダーとしてアサインされた際の心構え、具体的な対応方法を伝えてくれる。私も過去に炎上プロジェクトを体験してきたが、大きく頷く点も新しい発見もあった。運悪く炎上プロジェクトの中にいる人はもちろん、このような炎上プロジェクトにならないようにするための予防として本書の記載内容は示唆に富む。

読書「知略の本質」

名著「失敗の本質」から始まった物語（失敗の本質、戦略の本質、国家経営の本質）を終結に結ぶ本。

引用

現象を「二項動態」的に把握したうえで、状況と文脈に応じて具体的戦略を実践していくことを「知略」と定義した。

もうこれだけで痺れる。戦略の本質と重複するところが多いのではないかと、

少し購入を躊躇っていたが、読んで本当に良かったと思う。

（なお、戦略の本質と重複しているかどうかでいうと決して重複していない。

　バトルオブブリテンの物語も大幅改定されている）

少し難解な書籍ではあるが各章のアナリシスと最終章だけでも読む価値がある。

戦略と戦術の違い、二項式と二項動態。知略の定義とは何なのか。

優れたリーダーシップとは何を指すのか。

戦史を例にとってはいるが、日々ダイナミックに状態が変わる中で、

「いま・ここ」の情況に応じた本質を見抜いていく例からは、

読み手に対して多くの示唆を与えてくれると考える。

これらは日々の仕事の中でも応用出来ることも多い。

なお、この書籍の読み方としては、是非最初の失敗の本質から読んでいき

著者たちの長い挑戦を追体験すべきだと考える。

おそらく最後の腹落ち感が全然違ってくるだろう。

知略の本質 戦史に学ぶ逆転と勝利

読書「勝間式超コントロール思考」

IT本ではないが勝間氏のITガジェット を駆使した豊かな生き方への誘いは健在。

結論としては残念ながら読んでいて楽しいが目新しい気づきは少ない。

勝間式超コントロール思考

「コントロール」と聞くと、
なんでもかんでもコントロールしたがるわがままな人、
他人を自分の思い通りに支配したがる人など、
あまり良い印象を持たないかもしれません。

しかし、本書でいうコントロールの対象は、自分自身とその周りの環境です。

つまり、
「自分も他人も大事にしつつ、時間やお金を効率的に使いながら
イメージ通りに物事を進める方法」というのが、
本書で提唱する「超コントロール思考」です。

読んだ感想

• 全体的にカテゴリが複数に渡っており浅く広い内容になっている（これは逆に著者の書籍を初めて読む方であれば良い点でもあるかとも思う）
• コントロールを作り出すには主体性と余裕と人間関係。いずれも自らの手によって生み出すものであり必ず自分にも可能という話。その通りだと感じる。
• 当方、著者の書籍「7つのフレームワーク」にて感動を覚えたことがありファンであるが、何か読後感は「他の本ですでに読んだ内容だな」と思った。主体性は「七つの習慣」で、人間関係は「人を動かす」で深く理解した。それに比べるものではないがどうにも同じことを読んでいるように感じた。これは読み手によって感触も違うだろうとは思う。
• ただし、「食事のコントロール」の章は非常によかった。「栄養コントロールのため外食から自炊へ。自炊を可能となる仕組み作りへ。仕組みのために導入したガジェット はこちら」。これこれ、このロジカルな流れには引き込まれる。

まとめ

正直な話を言うとエッセンスに留めているため、どうしても読み応えを感じない。ただしコントロール対象のカテゴリ定義を示してくれること。コントロールするための具体的な方法を示してくれる点を鑑みると決して「薄っぺらい本」ではない。

読書「業務システム開発モダナイゼーション」

昨年から積ん読の一冊であった業務システム開発モダナイゼーションを読んだ。

結論から言うとITエンジニア必携の1冊である。

業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス

 本書は、日本のSI業界における多重請負構造を前提条件とした上で、近代的な業務システム開発に必要となる基礎知識やノウハウ(SI技術)を幅広く提供する。これにより、多重請負構造の上流の立場にあるIT部門やSIerのプロパーが、システム開発を正しい方向に導き、開発現場を近代化できるようになることを目指すものである。

読んだ感想

• 全体的に熱い。各記載に頷きながら読了した。
• システム開発の現場で起こっている問題に対して切り込んでいる。切り口として要件定義〜リリースまでの各工程における問題と解決のヒントが盛りだくさん。
• 特に外部設計書と内部設計書について明確な意図の違いを提示している。例えば外部設計を基本設計、内部設計を詳細設計と認識しているSEの方はこの章立てだけでも十分な気づきになるかと思う。外部設計書で書くべきは何か。内部設計書で書くべきは何か。社内テンプレートを疑わず各設計書を記載していることを反省できる記載だ。
• 自動ビルドとカナリアサーバといった継続的インテグレーションの記載もあり、いずれも問題に対する解決方法の記載であり実践的である。

まとめ

現場でEXCEL方眼紙で設計書書いたり、詳細設計というソースコードと同じような設計書を書いているITエンジニアに是非手を取って貰いたい書籍。そして今の開発現場を少しでもよくしていくことをミッションとするシニア層にも響くものがあるはずだ。

RPAについての簡単な所見

RPA（Robotic Process Automation）について現時点での考えを簡単に記載しておく。

■RPAとは何か

普段ヒューマンリソースを使用しながら行なっている作業を自動化するもの。

所謂、事務処理の自動化であり以下の業務特性に対して相性が良い。

まぁ、こんなの別に皆んな知っていることだろうからさくっと。

• 業務プロセスが定まっていること
• 業務として恒久的に行われる作業であること
• 判断が必要にならない作業であること
• 人為的ミスが発生しやすいこと

■RPAとAI

事例などを調べていると、どうにもRPAとAIが一緒に語られすぎているように感じる。

広義でいうとRPAにAIも含まれるのであろうが、RPAそのものにはフェーズが存在する。

1. フェーズ１：定型作業の自動化「マクロ」
2. フェーズ２：非定型作業の自動化「AI」
3. フェーズ３：意思決定の自動化

このうち現時点で実用段階にあるのは、フェーズ１だと感じているが、利用部署（以下ユーザ）はRPAさえ入れたら定型作業は自動化できるし、非定型作業もロボがなんとかしてくれるんでしょ？みたいな感触だったりするので、エンジニアとしてはきちんとRPAをフェージングして期待値に対する誤解を払拭しておいたほうが良いのではないかと思う。

■金融における適合性はどうか

金融といっても複数レイヤーあるが、フロント・ミドル・バックにおける、バックに対してRPAは適合性が高いと思う。これはバックは業務プロセスが明確（フロント・ミドルに業務プロセスが無いと言っているわけでは無い）であり定型的な作業が多く、意思決定が必要になる業務と区別できるからに他ならない。これは事務コストの大幅な現象も見込めるだろうと現に「みずほ」「MUFG」「SMBC」とメガがこぞってRPAに対して積極的な取り組みを見せている。

各行の取り組みは金融財政事情「2018年1月22日 号」に詳細記載がある

きんざいストア

■不安な点であり手を打たないといけないポイント

世間が「RPAだ。自動化だ。これは働き方改革だ」と言うのとは裏腹に、特に野良ロボットが分散作成されて収拾がつかなくなることが心配。RPAは中央集約型で管理してロボの重複も避けるべきだと思うが、そうでない場合は注意が必要と思われる。具体的には機動力を活かすには現場で作るのが良いとばかりにユーザがエンドユーザコンピューティングと同じ感覚で取り組みロボが量産されてしまう可能性がある。こうなったらいつの間にかエンジニアの知らない自動処理がユーザ部門で出来上がっていてそれがいつの日か保守をしてくれといった要望になる可能性すらある。中央集約されていないので機能的に他のロボと重複もあるだろうし何ならユーザ部の一担当者が個人的に作ったロボも存在するだろう。このロボたちが悪さをしないのであれば良いがマクロの組違いなどで意図しない挙動を見せて本来のシステムに対するダメージコントロールが出来ない状態になると目も当てられない。

■ユーザ部と手を取り合って

前述した手を打たないといけないポイントについては開発部門が中央集約のメリットを提案する必要があると思う。規律を設定し野良ロボの発生を抑え開発部門がRPAを統制するといった前向きな意見具申が必要であると考える。またRPAの単純マクロでうまくいかない部分については共通パーツの開発と提供など機能に対する標準化も推し進めていければと思う。RPAはエンジニアにとっても大きなビジネスチャンスだと推量する。