見たものブログ

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

「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 201820日目です。

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 メンタリングの技術

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

...

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

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

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

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

本書のパンチラインの秀逸なところは、このように「私の弱さ」をえぐってくるところです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:それを知らないってだけで不幸になっている方々も遍在してたなぁと...

恐怖体験を乗り切るための : 『カイゼンジャーニー』

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼンジャーニー』を読んだので、メモを残しておきます。

本書と、この間読書メモを書いた『エンジニアリング組織論への招待』、同じ2018年2月に発売されてたんですね。両方ともマネジメント関連の本として名作で、同じタイミングで同じ日本でこんな素晴らしい本が生まれてしまうなんて、こんな偶然あるもんかと。

k-nakahashi.hatenablog.com

両書の私の読後感は対照的で、『エンジニアリング組織論への招待』は、マネジメントへの自信(を通り越して万能感)のようなものが芽生えたのに対し、『カイゼンジャーニー』は「マネジメントって大変だな」と思わされました。

続きを読む

「未来」と「他人」をなんとかする : 『エンジニアリング組織論への招待』

からっぽな頭にノウハウを詰め込んで取り出せなくなる問題

私は、エンジニアがいる組織でマネジメントっぽい仕事をすることがあります。

なにがしかの課題が与えられたとき、とにかく考えるのはもちろんなのですが、先人の知恵をどれだけ拝借できるか、要は「ノウハウをどれだけ知っているか」は重要ですよね。

とはいうものの、これらのノウハウとやらは使ってみないと使うコツはわからないし、数も多いので把握しきれません。経験で成長できる範囲にも限界があるので本を読んだりするのですが、現場で課題に直面した際にどれだけ自分の引き出しからノウハウを持ってこられるのか、相当怪しいものがあります...w

続きを読む

エンジニアが娘(小1)に『ルビィのぼうけん』を読み聞かせてみた

ルビィのぼうけん コンピューターの国のルビィ

ルビィのぼうけん コンピューターの国のルビィ

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

最近では小学校一年生の授業でパソコンを習い始めるらしく、

「ダブルクリックのやり方をならってきた」

などと自慢してくるようになりました。

そして、私が自宅で開発作業をしていると、横から見てきたりして「プログラミング」という行為を認識したようで、

「私にプログラミングを教えて」

と言うようになってきました。

普段の業務ではRubyをちょっと使っていることから、私は 苦し紛れに 『ルビィのぼうけんコンピューターの国のルビィ』という本を読み聞かせに使ってみることにしました。

続きを読む

一人で聴けるダンスミュージック : 『Future Pop』

Future Pop(通常盤)(DVD付)

Future Pop(通常盤)(DVD付)

Perfumeの新しいアルバムと、中田ヤスタカPerfumeの対談記事を摂取しました。

栄養価高かった... 😍

かしゆか シングルの「If you wanna」を最初に聞いたときはびっくりしました。”サビに歌が無い!”という。それまでフューチャー・ベースに触れたことがなかったから

続きを読む