見たものブログ

Webエンジニア（元組み込みエンジニア）が、本とか見たものをメモしていくブログです

Progressiveなのが好感 : 『世界で一番やさしい会議の教科書』

段階的に取り入れられるのが素敵

世界で一番やさしい会議の教科書

世界で一番やさしい会議の教科書

社内でこの本を布教している方がいて、私も読んでます。とてもよかったですね。

何かを良くしていこうという試みって、理想形を語るのは気持ちがいいものの、実際それに近づけていくのは泥臭かったり恥ずかしかったりで、やってられないこと多いじゃないですか。

会議の改善もそうだと思うのですが、この本では「理想形に近づけていく」部分をフォローしているところかなと思います。つまり Progressive であるってことが役立ちポイントですね。

初期段階では、

  • 会議が終わったタイミングで、 "決まったこと、やるべきこと" を確認する
  • 会議の終了条件を決める
  • 手元の紙でスクライブの練習をする

辺りから始めて、徐々に

  • ホワイトボードでスクライブ
  • アジェンダ上での時間配分

を取り入れていける。いきなり大ジャンプしなくても、スモールスタートで始められるというところに希望が持てます。

フレームワーク的な「プロセスのパターン」

大きな問題へ対処するためのミーティングをしようとする場合、私は漫然と人を集めて深刻そうに語りだすというこちしかしてこなかった気がします。

本書では「会議の種類によってだいたいプロセスが決まっている」と述べていて、対応表を紹介しています。ここはフレームワーク的に使えそうで、何かあったときはすっと取り出したい本書のエッセンスですね。

f:id:k_nakahashi:20190709212449p:plain （『世界で一番やさしい会議の教科書』より）

「ミーティングが非効率的である」という話は酒席での定番アイテムで、個人的には愛おしいすらあります。非効率的なミーティングは滅びていいとは思うのですが、本当に滅びたとしたら、次の酒席の定番アイテムがどうなっていくのかは興味があります。

会社のリファクタは誰がするのか : 『会社のITはエンジニアに任せるな！』

プラント型IT

会社のITはエンジニアに任せるな! ―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていること

会社のITはエンジニアに任せるな! ―――成功率95.6%のコンサルタントがIT嫌いの社長に教えていること

本の冒頭に「プラント型IT」というおもしろい比喩が出てきます。

会社で使うITには、「ツール型IT」と、それとは別に、会社にとって死活的に重要な「プラント型IT」がある

「ツール型IT」は、メールやチャットツール、Webサイト上のIRページのことです。一方「プラント型IT」は、業務と密接に絡みつき、業務を支えるITのことです。工場のプラントのように、稼働が生産に直結しているからです。

工場のプラントは基本的に一点物で、その企業の生産力・差別化力そのものです。会社における基幹システムは、プラントと同じようなものだと言っているわけです。

どの会社にもあるツールを開発するわけではないわけですから要件定義は容易ではなく、費用も莫大にかかります。コストやリターンで得なことが明らかであれば決断は簡単ですがそうではないので、こういうことこそ経営幹部の意思決定が必要なわけですね。

経営幹部と業務担当者が主体的にITに関わるしかない、IT部門や外部のITベンダーに丸投げすべきではない

私は仕事で社内外向けのシステム開発を主に担当しているので、本書のタイトルには少し釣られた感がありますw 少なくともエンジニアが白紙委任状をもらっちゃいけないなとは思います*1。

ボトムアップ型ITの限界

会社でいい資料がSlackで回ってきて、一部社員の中で話題になっていました。ボトムアップアプローチのITが会社で氾濫して、情報が構造化していかないと。

「自分の業務」を効率化するために秘伝のスプレッドシートを作ったり、部署ごとにサービスを導入したりするわけですが、当然他のITのことを考慮せずに部分最適で進めていくため、全体として辻褄が合わないという事になっていきます。

会社全体で整合性・拡張性のあるシステムを構築するには、プラント型ITと同じトップダウンアプローチが重要になってきます。これは組織の範囲という面もありますが、「システム全体を俯瞰して設計できるか」という視点の広さの意味合いもあります*2。

プログラミングの世界でも似たような話があって、当初は jQuery で画面ごとにごまかしながら作っていたのを、リファクタの段階で Nuxt を導入するみたいなことはあります。

可読性や拡張性を考えると、会社全体のITもどこかでリファクタするタイミングが出てくるのでしょう。そうしないと会社の成長に耐えられないからです。しかも一時のリファクタだとだめで、正しい設計を維持する仕組みも含めて整備する必要があって、それが（エンジニアチームも含めた）組織の設計なのではないかと思っています。

*1:エンジニアは「システム構築プロジェクト」の成功に拘泥しがち

*2:時間軸的な視野の広さの意味合いもあります

一度書いたことを忘れて見直そう : 『文章を整える技術』

読書メモ

文章を整える技術　書いたあとのひと手間でぜんぜん違う

文章を整える技術　書いたあとのひと手間でぜんぜん違う

推敲

仕事上、週末と月末にまとまった報告を書く生活になっています。たまにブログも書きます。

昔から日本語をうまく操る人に対して羨望と嫉妬が激しかったのですが、最近コードを書くよりも日本語を書く方が増えてきて、死活問題になってきました。あぁ.. 美しくてわかりやすくて印象に残る日本語を書きまくりてぇ...

本書は推敲のノウハウをまとめてくれている本です。

文章に自信がない人は、そもそも「文章を整え、読みやすくする」という作業を怠っている、とも考えられ ます。

う、そうです。書いた文章、ちゃんと見直していないかもしれません。*1

本書では推敲に使うためのチェックリストを作るとよいとあるので、自分用に最低限のリストを作ってみました。

  • [ ] 無駄が多く長いだけの文章
  • [ ] 専門用語ばかりでチンプンカンプンの文章
  • [ ] 「ウラ」がとれていない文章
  • [ ] 接続詞が多すぎる
  • [ ] 「本当に必要な情報か」を意識する

推敲の際、上記のリストを念頭に置いて読み返し、すべての項目をパスできるかテストしてみるとよいだろうと思いました。

推敲をちゃんとするための戦略

推敲のテクニックに、「なるべく書いた内容を忘れて読み直す」というものがあります。当然のことながら書いた本人は文章の内容を完全に理解しているので、推敲の際、多少わかりにくい表現であっても見過ごしてしまうからです。

つまり、ちゃんと推敲をするには、推敲そのものの時間と「一度忘れる」ための時間が必要になるわけです。うーん、時間なんてないっていうのに。。

本書では、コーヒー休憩やメールボックスの確認などを挟んでリフレッシュだけでもよいと言っています。休憩というのは作業の合間合間に必要だとは考えていたのですが、作業には「一度忘れる」という意味でのリフレッシュというのはやはり重要だなと思いますね。自分がテスターとして生まれ変わるための儀式のようなものかと。

チャット内容の推敲

メールや報告書は推敲する時間は取れると思うのですが、Slackなどのチャットはどうなのでしょう。特にテンポよく会話してる時などはちょっと難しいと思います。

ただ、文章でのやり取りのせいで真意が伝わらず、トラブルになる例も散見されます。それはチャットだと推敲できないことと関連している感じがしますね。

*1:文章を整える時間ちゃんと取れないし、見直すくらいなら早く会社を出て帰りの電車でスト5のeスポーツ動画を見たいと思っています

アンチハッピーマニアになれる : 『人を伸ばす力』

マネジメント 読書メモ

内発的動機づけ

人を伸ばす力―内発と自律のすすめ

人を伸ばす力―内発と自律のすすめ

個人的には、自分の子どもや後輩を「私が一人前にしてやろう」という殊勝な考えは強くない*1のですが、それぞれ成長するスピードやタイミングが異なることに関しては興味があります。

本書で言う「内発的動機づけ」は、「楽しい」「好きだから」という本人の心理による動機づけのことです。

時間の感覚が消え去り、集中力が持続し、ワクワクするような気持で満たされ、その時間がいつまでたっても終わらないでほしいと願うような心理状態

こういった状態に誘導することで、ひとの成長を促進できると本書では言っています。

「時間の感覚が消え去り」という精神状態は共感できます。プログラミングを調子よくやっているときなどは、こういう感じ。「10分後に予定があります」というGoogleカレンダーの通知が目に入っても頭に入ってきません*2。

様々な実験によると、これと相反する「外発的動機づけ」（報酬・締め切り・罰）による施策は、かえって成長を阻害する要因となりうるとか。要は「やらされている感」があるとよくないということです。

ではどうやって内発的動機づけを高めていけばいいのか。それは

  • 自律性への欲求
  • 有能さへの欲求
  • 関係性への欲求（誰かと結びついていたい）

という、人間が本来持っている欲求を中心に考えていけばよいとしています。

幸福と成長について

「自分の行動を調整すること」の章で、なかなか味わい深いフレーズがあります。

人が幸福のみを求めるとき、幸福の追求により、それ以外の経験が抑圧されることになり、発達を阻害するかもしれない。

生きていることの本当の意味は、単に幸福を感じることではなく、様々な人間の感情を経験することである。

本書は、基本的に実証実験からのエビデンスをもとに議論を進めていくのですが、ここだけちょっと宗教がかっていて、熱がこもっています。

割と当たり前のこととして語られている「幸福の追求」ということへの偏重が、本書が遠ざけるべきとしていた「外発的動機づけ」を招いてしまうわけです。*3

個人的にも、「幸せなことしか経験してきてません」みたいな自信満々なひとより、色々な障害を乗り越えたり逃げたりして、命からがら生きてきたような人物に魅力を感じます。

私は幸福感センサーが鈍いタイプの人間なので、「幸福だけが大事ではない」と言ってもらえると、自分を認めてもらえたようで安心できます。落ち込んでいるときにこのことを思い出すだけで、何とか生きていけそうな感じはしますね。

「人を伸ばす力」は、「自分を生かしていく力」にもなるなと、しみじみ考えさせられました。

研修によって「外発的に」読んでいた

実はこの本は、会社のリーダー研修での課題図書として読んだもので、「外発的」に読んだものですw でも意外な展開もあって、読んでよかったと思ってます。

*1:マネジメントにも「メンタリング」という領域があり、仕事上人を成長させることに一定の責任を持つことがあります。

*2:よくミーティングに遅れてきてしまう言い訳ですが。。。すみませんすみませんすみません

*3:何事にも「コスパ」で判断してしまう方々を想起させます

「VOYAGE GROUP エンジニアの公開ガチ評価会」で、制度を運用可能にする文化を感じてきた

「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加してきました。

voyagegroup.connpass.com

エンジニアの評価はすごく難しくて、公平感を保つの困難だし、数が増えてくるとすぐ見切れなくなっていくんですよね。各社いろいろな工夫をされているのですが、名高い VOYAGE GROUP の評価会制度については特に興味を持っていました。

5分でわかる技術力評価会

最初にCTOの @makoga さんによる、「5分でわかる技術力評価会」。

課題意識や目的があってのこの制度で、概要は私もなんとなく知っていました。

成り立ちや制度設計を改めてお聞きすると、この評価制度がものすごく洗練されていて、どこかで間違いがあってもすぐに補完できる冗長性のような設計もあって、一朝一夕でできていないことがよくわかりました。

そして、一回の評価にコスト（つまり時間）をかけてるなぁ...と。コストがかかるので、それを嫌いそうな事業側のメンバーやもっとコードを書きたいエンジニアにこれを理解してもらうのは大仕事に違いありません。

このプレゼンは早足だったのですが（さすがに5分で収まる内容ではない）、全く淀みなく一直線に話されていて、この評価制度を根付かせるために、何度も何度もこの説明をされてきたんだなぁ、と思いを馳せて無限に尊敬しました。

公開評価会

@yangwei21 さんによる評価会を見学できました。普段は、被評価者1人＋評価者2人で、会議室などで行っているとのこと。

自分などは20分程度のLTの準備するにもあたふたするwのですが、この日の発表は60分(!) 、本番は90分(!!!) 程度かけて行っているそうです。発表の最中にも、コードのかなり細かい部分にまで指摘が飛ぶので、プレッシャーもかかりそう...

ただ、評価会の間は雑談っぽいツッコミなどもあったりして、指摘自体は鋭いものばかりであるものの、和やかな空気は維持しているように思いました。

Symfony + Modern JavaScript = Symphony · GitHub

Symfonyアプリのフロントが題材になってたのですが、社外のSymfonyのコード見るの久しぶりでちょっと感動。twig と Vue.js のそっくりの記法が同じファイル内で同居してたりするヤバさは非常に面白かったですww

↑ この名言も良かったww

評価会を運用可能にする文化

懇談会があったので、登壇されていた @yangwei21 さんにお話を聞けたのですが、

  • 普段の業務で、評価会で発表できる開発をしているか考える
  • このコード、評価会でどう言われるか？ を考えながら開発する
  • 発表前に、自チーム内で素振りしたりする

といった話が印象的でした。

この評価会、漠然と「直前の準備が大変になるんだろうなぁ...」程度に考えていたのですが、直前だけではなく、普段の業務に影響を与えているんですよね。

環境としては大変なのかもですが、コードを書くということにしろ、他人に説明するという能力にしろ、スキルアップを促す方向に作用しています。「評価に役立つ」ことってスキルアップできる環境であることと表裏一体なのだろうなと。

孫引きになってしまうのですが、

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

に

構成員が、意識しなくても自然と仕事をこなせる、そんな行動原理や行動様式が組織にあれば、それこそがその組織の「文化」である。

フレデリック・ラルー

という記述があって、評価会に向けて開発するという姿勢も VOYAGE GROUP の「文化」になっているのだと思いました。

非常に恐縮でラッキーなことに @makoga さんにもお話を聞けたのですが、エンジニアのグレードも含めて 「事業への貢献」を評価軸にすることを徹底 されているという話が特に興味深かったです。

技術要素の選定ひとつとっても、各人の視点の違いや宗教の問題w で決まらないこともあると思うのですが、それがどのように事業に貢献するかという観点があることで、議論に筋が通る感じがします。

よく「技術的負債の返済を事業側に理解してもらえない」みたいな話もありますが、評価会などで「どのように事業に貢献するか」を説明するプレッシャーを受け続けているエンジニアであれば、理解してもらうためのロジックは勝手に作っているはずです。*1

それと、評価会制度自体も最初は極小規模から初めて、ちょっとずつ大きくしていったとのことでした。

もちろんうまくいくかどうかもわからないのでスモールスタートで行くのはわかりやすいのですが、少しずつ浸透させていくことで、この制度を回していくための文化のようなものを熟成できていっている感じがしました。（本当に勝手な感想ですが）

この評価制度は控え目にいって最高なのですが、現状の完成度まで育てていった長い長い道のりの方に気持ちが持っていかれたのでした。

*1:なので、あえて「技術的負債を返済しない」という決断も、エンジニアからできるはず

フィボナッチさんの伝記絵本を読み聞かせで使ってみる

絵本 読書メモ

この記事は、子育てエンジニア Advent Calendar 2018 の20日目です。

Webアプリケーションエンジニアをしている私には、小1になる娘がいます。

夜寝る前に絵本の読み聞かせをせがんでくるのですが、どうせなら教育に良さそうな本がいいと思い、この本を使ってみることにしました。

フィボナッチ―自然の中にかくれた数を見つけた人

フィボナッチ―自然の中にかくれた数を見つけた人

  • 作者: ジョセフダグニーズ,ジョンオブライエン,Joseph D’Agnese,John O’Brien,渋谷弘子
  • 出版社/メーカー: さえら書房
  • 発売日: 2010/09
  • メディア: ハードカバー
  • クリック: 37回
  • この商品を含むブログ (9件) を見る

仕事に疲れてでハイになってオフィスの近所をさまよっているときに見つけた、数学者フィボナッチの伝記です。

プログラミングでの課題で「フィボナッチ数列」はお馴染んでいますが、そもそも「フィボナッチ」という人物がいるということ知りませんでした。ほんとヒドいw

イタリアの（例の斜塔がある）都市ピサで、商家の息子として生まれたレオナルド・フィボナッチが、周囲に理解されないまま数学の面白さに取り憑かれていく、というストーリーです。

中世ヨーロッパ

フィボナッチ数列は有名ですが、絵本の中ではアラビア数字をヨーロッパに紹介したという功績も取り上げています。

それまでヨーロッパでは、ドラクエのナンバリングでおなじみの I, II, III, IV, V, VI.... といったローマ数字をつかっていたらしいんですよね。時代は13世紀ごろの話なのですが、当時のヨーロッパが他の地域よりものんびりしていたという感じは、本全体から伝わってきます。

ピサの街並みはとてもきれいでいいですね。

f:id:k_nakahashi:20181220014649j:plain

子どものツボに刺さったところ

フィボナッチが海外で学んだアラビア数字を故郷の街で紹介しようとすると、市井の人々には全く通じません。

フィボナッチは

「あいつは "のうなし" だ！」

と言われてしまうのですが、ここで娘は

「フィボナッチさんはのうなしなんかじゃないんだよ！」

とすごく憤慨します。

この本、ここでフィボナッチをバカにしていた人々が、後に彼の偉大さを認識して謝罪する、みたいなハリウッド的なカタルシスは訪れませんw でも「周りがなんと言おうと、好きなものに打ち込め」というメッセージが強烈で、そこに私はすごく共感します。

娘もそこが気に入ったみたいで、年老いたフィボナッチが「数は今もわたしをしあわせにしてくれます」と語るラストシーンでは、とても満足そうにしてくれます。

小1はフィボナッチ数列を理解できるのか

この絵本のハイライトは、フィボナッチが見つけたフィボナッチ数列を解説するシーンです。

つがいのうさぎがどのように増えていくのかを解説しているのですが、うさぎの数がすごく自然にフィボナッチ数列になっていくのはとても美しく、感動的です。

f:id:k_nakahashi:20181220014952j:plain

ただ、やっぱりこの感動、ちょっと小1には難しかった...w

隣同士の数を足すというのも、ちょっと桁数が多くなってくると理解できなくなってくるので、私が「こことここを足すと次のマスの数になるね」という説明をしても表情は曇るばかりですw

とはいうものの、「フィボナッチ数列が自然界によく現れる」といった辺りのくだりはこどもにもちゃんと伝わりますね。花びらやヒトデの腕、リンゴの種の数が「フィボナッチさんが見つけた数」という事実は、大人でも子どもでも面白い。

まとめ

読み聞かせは、子どもにも大人にも楽しい本を選ぶのが一番だと思いました。

これらの本も読んであげてますが、私が喜ぶので子どもも喜びますw

ルビィのぼうけん こんにちは! プログラミング

ルビィのぼうけん こんにちは! プログラミング

ルビィのぼうけん インターネットたんけん隊

ルビィのぼうけん インターネットたんけん隊

こちらの本に関するブログも、以前書きました。

k-nakahashi.hatenablog.com

パンチラインで読む : 『エンジニアリング組織論への招待』

マネジメント 読書メモ

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

パンチライン？

「エンジニアリング組織論への招待」に関しては、以前読書メモを書きました。この本、論旨が素晴らしいのはもちろんなのですが、読んでいて「楽しい」んですよね。

私がなぜ楽しく感じたかというとこですが、要所要所にパンチラインが出てきて「え？ なにこれスゴイ」と引き込まれたからだと思っています。

パンチラインとは、HIPHOP用語では「印象的な部分」とか「決め台詞」みたいな意味です。

えてして現実って複雑で面倒くさくて理解不要なものなで、私のような子羊は基本的にさ迷ってまるじゃないですかw

この本、マネジメント界にたくさん存在する複雑な概念を、シンプルに一言で表現してくれるんですよね。私は、しばしば登場するこの「ひとこと」にいちいち感心し、心の中で勝手に「パンチライン来た！」と思ってました。

なので、私がこの本の論旨を理解しようとするなら、パンチラインをまとめてみるのがよさそうと思い、やってみることにしました。*1

Chapter 1　思考のリファクタリング

誰かの曖昧な要求からスタートし、それが具体的で明確な何かに変わっていく過程が実現で、その過程のすべてがエンジニアリングという行為です。

もっともなので、迷ったら「自分は何かを具体化できているか」を問うようにするとよさそう。

人間にとって、本質的に「わからないこと」はたった2つしかありません。それは、「未来」と「他人」です。

要は、マネジメントの対象は「未来」と「他人」だとわかります。

あまりに鮮やかなフレーズなので、あの名作パンチライン「3つの袋」に替わり、結婚式でのスピーチでの定番になることを密かに願っています。

論理的に考えるには、「非論理的に考えてしまう」瞬間を知ることが重要です。

私は非常にしばしば、論理性よりも自分の承認欲求を満たす行動に走ります*2。なので上記のように言われると耳が痛いですね。

お互いの情報伝達が不完全で、それゆえに引き起こされた問題であっても、何か害意や悪意をその中に見出してしまいがちなのが人間の性です。

国際紛争も社内の謎なゴタゴタも、思い当たる節があります。

「透明性」とは、つまり、継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持し、情報の非対称性が削減され、限定合理性の働きを弱められている状態のことをいうのです。

本書で繰り返し語られる「不確実性を下げることが大事」は、「透明性」という言葉もより具体的に説明しまえるところがスゴイ。「透明」という言葉からすると「見えている」という印象だけが先行しますが、「お互いに話が通じる」ということが大事であることがわかります。

Chapter 2　メンタリングの技術

すべてのその人の問題は当人しか解決できないので、解決策を言うこと自体が、相手への敬意を欠いた行為とも言えます。

...

「問題を解決してあげよう」という意識ではなく、「モヤモヤしていない問題に変換してあげよう」と考えることが重要です。

最近以下の本を楽しく読んで、これに関してはまた別途まとめたい感じがしています。

([い]6-1)アドバイスかと思ったら呪いだった。 (ポプラ文庫)

([い]6-1)アドバイスかと思ったら呪いだった。 (ポプラ文庫)

「いいアドバイスをする」というのは、無理ゲーなことがしばしばあります。

「誰が悪いか」という問題解決にとって「どうでもいいこと」にこだわるのは、自分でない誰かに責任を求めて思考停止することで、自分自身をコンフォートゾーンの中で安心させるための防衛装置が働いているからです。

本書のパンチラインの秀逸なところは、このように「私の弱さ」をえぐってくるところですw 私も心地よい場所だけにいたいんですよ、本当は。

「自分の弱さやミス、相手との意見の違いや直したほうがよいところを、率直に飾らずに話せるかどうかというのが、「心理的安全性」という概念の重要な視点です。

これは別の文書を読んだ時にも感じました。↓

必要なのは、結果ではなく行動、行動だけでなく存在への承認です。

へーしゃでは現在「インストラクター」を設置していますが、基本的にこのためだけのものです。意外（？）とよくできてるなぁと...w

「わかる」の定義を「具体的な行動を行うことができる」に変換してしまえば、その行動を通じて、「わかった」状態を確認できますし、「わからない」ポイントもより明確になるでしょう。

これはChapter 1で出てきた「具体的にすることがエンジニアリング」というパンチラインと呼応していて面白いです。

Chapter 3　アジャイルなチームの原理

アジャイル開発は従来型の開発に比べて、平均して3倍の成功率と1/3の失敗率という統計が出ています。

大規模開発ほどアジャイル開発が効果的であるという調査結果や一部ヨーロッパ諸国ではアジャイル開発が政府からの受注の前提になっていることなども紹介していて、基本的にこの流れは不可避化だと思います。

プロジェクトにとって最大のリスクは、「終了しないこと」

...

プロダクトにとっての最大のリスクは、「終了してしまうこと」

これも固い韻を踏んでてまさにパンチラインって感じですがw、非常に重要なことを言っています。

プロダクト内にプロジェクトが生まれることも普通で、この場合はPMBOKのようなプロジェクトマネージメント的な管理手法も大事になってくると思います。

「何を作るかを考える人」は、目的不確実性の削減に対してアプローチをしたいと考えていて、「どのように作るかを考える人」は方法不確実性の削減に対してアプローチしたいと考えています。

これも現場レベルで重要で、優秀な人同士の議論で「話が食い違ってしまう」パターンのよくある例かと思います。

「人はその人のアイデンティティの一部となっていることについて実りある議論はできない」

これは他のエッセイからの引用ということですが、納得感もありつつ、難しさも感じます。

マネジメントレベルで何かを変えようとするとき、今まで一生懸命だった誰かのアイデンティティを踏みにじる可能性は思ったより高い印象があります。

アジャイルな方法論で重要なことは、役割で関係性を縛らないことにあります。

自分が「役割を遂行するにはどうしたらよいか」ではなく、チーム全体の目的において、「今自分は何をすべきか」という問いをメンバーが常にもつことになるからです。

...

また、役割を分けない、決めないということは、ある専門性を持ったメンバーがいたとしても、必要に応じて、別の専門領域の事柄も手伝っていくように変化させていきます。

たまに私も、なんらかの施策によって自分の「役割」がなくなってしまうと怯えることがあります。そういうときこそ、「何をすべきか」を問うべきなのでしょうね。。。

Chapter 4　学習するチームと不確実性マネジメント

「わからないもの」に立ち向かうことが人間にとって困難なことだからです。不安の量を「見える化」していくことで、早期にリスクを顕在化することができます。

Web開発初心者あるあるで、「ビジネスロジックより先にViewを作りがち」ということあると思うのですが、こういうことが理由な気がしますね*3。

スケジュールマネジメントを行うのであれば、要求が詳細化していく過程そのものをマネジメントしていかなければなりません。

これホントにその通りで、ウォーターフローの悪習として語られる「基本設計」「詳細設計」とかのあれですが、スケジュールマネジメントの上では詳細化のフォーマットがあるのってありだと思うんですよね。

多くの経営者が「納期」というものを決めて、プロジェクトを管理させるのは、その日にリリースされるという絶対の情報を欲しがってしまうからです。

こうして「納期」におびえて愚痴りながら仕事をする現場のエンジニアが誕生するのですが、やはりお互いにコミュニケーションをとるべきなのでしょう。たとえばスクラムなどは、そういったコミュニケーションをとるためのイベントを色々組み入れていますよね*4。

スクラムはいつどのようにチームが課題と不安に向き合うのかを規定して、改善を行うためのタイミングを矯正するためのフレームワークであることがわかります。

「スクラムとは何なのか」について、スクラムガイドよりもわかりやすく描写してくれています。

Chapter 5　技術組織の力学とアーキテクチャ

エンジニア組織は、組織の下流工程に位置しやすい

↑ 章のタイトルですが1行で泣けますね、これ😭

続いて ↓

開発部門は、組織のアウトプットとしての「システム」を構築する部門であるため、この多重に積み重なったエージェンシースラックの不合理が発露される場所になりやすいという性質を持っています。また、恐ろしいことにそのような関係性をもって生み出された「システムそのもの」に、組織の不合理が蓄積されるという現象が起きてしまうのです。

これらの何が泣けるって、結局手を動かしている私たちのモチベーションを維持できなくなってくるとこかと思います。

「やらされて」いる上にクソコードができあがっていくという。。。

権限を明示することは、「縛ること」であって、明示しないからこそ自由であるとする発想をすると、多くの場合問題が生じます。

...

権限が明示的でないことが意味しているのは、上司の胸先三寸で権限について差配できるということです。

上司がそんなつもりなくても、そうなってしまうかもしれません。「明示的にする」のって意外と大変であるという現実が、この状況を加速させる気がしますね。

ある単体の組織の効率性を測るときに、「より少なく抽象的な指示」であっても成果を残すことができるのかを考えると、組織の成長をとらえることができるということです。

本の冒頭の「エンジニアリング≒具体化」とリンクしてくる話です。

ついでにいうと、これは組織ではなく個人でも同じですねぇ。成長してない個人はマイクロマネジメントになりがちになってしまう (>_<

「技術的負債」というキーワードで問うべきは、エンジニアチームと経営者の間に存在する認識の差

これはかなり大胆な提起ですが、そのくらい両者の認識の差は大きいので心してコミュニケーションとるべし、とも思います。これに関しては、筆者の広木さんの以下のツイートも補助線ですね。

↓はもっと怖い。

これ、「技術的負債」って実はエンジニア組織そのものなのではww😱 「POがリファクタの必要性をわかってくれない」とか言ってるの、自分たちのせいなわけです。

内製領域と外部調達の領域を決めるのは、経営上不可欠な視点です。

つまり経営レベルでの発言力を持つメンバーに、システムのことをわかっている人がいるといいのではないかと思います。

「工数」「納期」「人月単価」といった、外注であるがゆえに発生する契約コストをわざわざ発生させて、流動性のあるリソースに見せかけても、全社レベルではメリットがありません。

私はインハウスエンジニアなので、こういった議論は心強いです。「流動性のあるリソース」っていう認識、外部のエンジニアにもまあまあ失礼だと思うんですけどね。

まとめ

「エンジニアリング組織論への招待」のパンチライン、まとめてみるとやっぱり楽しいw

この本自体とてもためになりますが、パンチラインの楽しさのおかげで再び読む日も近いのではないかと予感しています。やっぱり本は読んで楽しいの大事ですね。

それと、この本をちゃんと読む上では以下の本は避けて通れないという予感が。ゲーム買ってないで読まなきゃ。

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

反脆弱性[上]――不確実な世界を生き延びる唯一の考え方

こちらは、私の読書メモ前編(?)です。

k-nakahashi.hatenablog.com

*1:その他の感想については前編で書いています。((ちゃんとした論旨の一覧は、こちら)がよさそうです。

*2:しかも一見論理性があるかのように押し通そうとしてしまう。本当にタチ悪いw

*3:ここはテスト駆動ができれば変えられる

*4:それを知らないってだけで不幸になっている方々も遍在してたなぁと...