マネジメント語りについて - Kentaro Kuribayashi's blog
以下のnaoya氏のツイートを見て思ったところを書いてみる。書かれている文字通りのことには完全に同意で、自分自身の行いも反省する余地があろうかと思われた。一方で、多分この発言を読んだひとが誤解するだろうなということもあるので、そのことについて。 マネジメントって業績伸ばすためにやるんですよね？ 業績伸びてないのに俺たちはマネジメントうまくやってますって語るの意味あるんですかね— Naoya Ito (@naoya_ito) December 22, 2016 結論 結論から先に書くと、マネジメントについて語ることは、業績云々に関わらずおおいにやるべきだと思う。それは、たとえばソフトウェアエンジニアリングについての文書などと同様に、世の中にとって大きく役立ち得る。 ただし、それは一般化・抽象化された(つまり、組織が違っても役立ち得る)マネジメントの理論やテクニックに限る。自分たちがそれをうま
技術組織をスケールするためのCTL = チーフテクニカルリード - Kentaro Kuribayashi's blog
GMOペパボにおいて、チーフテクニカルリード(略称: CTL)という職位を作りました。既に以下のブログエントリで新任の2人がエントリを書いているところですが、制度設計者として、その背景を述べてみたいと思います。 diary.shu-cream.net ten-snapon.com GMOペパボの執行役員CTOになって1年半*1、その前に技術責任者に就任してから早2年*2が経過しました。その間、組織面においては、「いるだけで成長できる環境」*3、技術面では「事業を差別化できる技術」*4というコンセプトでやってきました。まだ道半ばではあるものの、逆にいえば、通るべき道は見えているともいえます。 そんな中で、この2年間、ずっと気にかかっていることがありました。 組織的にはエンジニアの人数が90人弱になり、近いうちに100人に達することでしょう。また、技術の移り変わりはますます早くなっていき、つい
組織の公安9課モデルについて - Kentaro Kuribayashi's blog
「組織の公安9課モデル」とは何か。「攻殻機動隊」好きにはお馴染みの公安9課だが、9課課長の荒巻大輔の以下のセリフが象徴するような組織のことをいう。 我々の間にチームプレイなどという都合のよい言い訳は存在せん。あるとすればスタンドプレーから生じるチームワークだけだ。 昨今は「ホラクラシー」などといわれたりもするフラットな組織が話題になっている。 「ホラクラシー」（holacracy）とは、従来の中央集権型・階層型のヒエラルキー組織に相対する新しい組織形態を示す概念で、階級や上司・部下などのヒエラルキーがいっさい存在しない、真にフラットな組織管理体制を表します。ホラクラシーの下では、意思決定機能が組織全体に拡張・分散され、組織を構成する個人には役職ではなく、各チームでの役割が与えられます。細分化されたチームに、それぞれ最適な意思決定・実行を行わせることで、組織を自律的・自走的に統治していくシス
プロダクトマネジメント(あるいはオーナシップ)に関心のあるひとが集まるSlack Teamを作成した - Kentaro Kuribayashi's blog
プロダクトマネジメント、あるいはプロダクトオーナシップに関心のあるひとが集まるSlack Teamを作成しました。以下のページから参加できます。 Join Product Managers Japan on Slack! 追記: Product Managers JapanのWebサイトもできました。そちらも御覧ください → Product Managers Japan (PMJP) 昨今、プロダクトマネジメントに関心が集まっています。最近の盛り上がりは、Rebuildで語られたりなどによるものだと思いますが、しばらく前に出た『世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法』『プロダクトマネジャーの教科書』などにより、アメリカのWeb業界におけるその職能が紹介されてもおり、また、『スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB
メタ・マネジメント: ビジネスと技術とDXの均衡点を探ることと、その均衡をぶち破ること - Kentaro Kuribayashi's blog
今日、エンジニア職位制度に基づく面談をしていて、自分の職務のうちのひとつを言語化したということがあったので、メモっておく。 CTOとは何か？ CTOというのがなにをする役職であるかについては、基本的には以下のスライドで述べた通り。 上記で述べられている、4つのマネジメント対象のうち、ヒトについては全ての基盤になる要素であり、あとの3つを別の言葉でいいかえると以下の通りとなる(それぞれに重なる部分はあるが)。 モノ: 技術 カネ: 事業 情報: DX(デベロッパー・エクスペリエンス)*1 3要素のバランス 組織の成長を最大化するという前提において、3要素それぞれについてバランスよくマネジメントして、そのいずれもが良い状態にあることが目指すべきところである(下図(1)の状態)。 その3つをうまいこと取り持つことで、上記の(1)のように3つのどれもに重なる部分を得られる時、技術マネジメントがうま
エンジニアとしていかに成長するかについて、GMOグループの新卒エンジニア・クリエータの皆さんにお話した - Kentaro Kuribayashi's blog
GMOグループにはGMOテクノロジーブートキャンプという新卒エンジニア・クリエータ向けの研修メニューがあって、そこでなんか話してくれという要請があったので、「エンジニアになる」というタイトルで、エンジニアとしての成長について、少しお話をしてきました。 自分自身がエンジニアとしていままでどうしてきたかみたいな話は、まとまった形ではこれまでしたことがなかったわけですが、立場上とか年齢的にも「僕ごときが……」とかいってもいられないので、恥を忍んでスピリチュアルな話をしてみました。以下、ご笑覧くださいませ。 いいたいことはだいたいスライドに書きこんだのですが、以下、ちょっとだけ補足。 このスライドを作っていた時に、ちょうど「現場ロックイン」についてのエントリが話題になったり、また、このエントリを書く直前にも似たような話題のエントリを見たりしました。 現場ロックインが技術力さげてるのかもしれない -
大きな構想を持つこと - Kentaro Kuribayashi's blog
DeNAのZIGOROuさんによる技術選択とアーキテクトの役割というスライドを拝見して、大いに感じるところがあったので、少し書く。といっても、技術的な話というよりは、もうちょっと違うレイヤの話(技術選択についても思うところはあるのだけど、それはそれについて述べたスライド*1を参照していただきたい)。 経験曲線効果 経験曲線効果という言葉がある。元は、ボストン・コンサルティング・グループ(BCG)のコンサルタントによって提唱されたものだ*2。このような図*3を見たことがあるだろう。 Wikipedia*4には以下のように説明されている。 経験曲線効果(けいけんきょくせんこうか、experience curve effect)とは、経験と効率との間の関係を示す経験則である。単に経験効果とも呼ばれる。一般に個人や組織が特定の課題について経験を蓄積するにつれて、より効率的にその課題をこなせるように
Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』 - Kentaro Kuribayashi's blog
著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。 Serverspec 作者: 宮下剛輔出版社/メーカー: オライリージャパン発売日: 2015/01/17メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。 Serverspec誕生の頃 約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけ
YAPC::Asia 2014で「いろんな言語を適材適所で使おう」という話をした #yapcasia - Kentaro Kuribayashi's blog
YAPC::Asia Tokyo 2014で、いろんな言語を適材適所で使おう - YAPC::Asia Tokyo 2014という話をしてきました。 これまでのソフトウェアエンジニアとしての経験から、継続的に価値を提供し続けるための技術選択はどのようにあり得るのかということをずっと考えていて、「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdaysや、GMOペパボのエンジニア新人研修 #lldiverという発表でもそのあたりの問題意識に基いて話したりしてきました。今回の話は、では、それらの延長線上での、将来における技術選択の最適化について考えてみました。 もうちょっとちゃんと定量化できる感じにしたいけど、まだまだ難しそうだなあという感じ。もうちょっと深堀りして考えていきたいと思います。
GMOペパボ株式会社の技術責任者に就任いたしました - Kentaro Kuribayashi's blog
標題の通り、8/1付けでペパボの技術責任者に就任しました。あわせて、@hsbtさんがチーフエンジニアに就任しました。技術者の体制を強化したことで、Webサービス事業者、すなわち、技術の会社として、さらに高い成果を出していけるよう努めたいと思います。 ちなみに、CTOでも役員でもありません。たとえていえば、技術部長みたいな感じの立ち位置です(うちには技術部という部署はありませんが)。 ところで、その技術責任者の主な役割を、以下のように定義しています。 技術的な会社の意思決定に貢献し、また技術面における中長期的な計画の策定・執行を行う。 経営陣、幹部会議、技術基盤チーム及び技術専門職へ情報の橋渡しを行う。 技術専門職の人事、技術基盤チーム予算に関する責任を有する。 会社におけるエンジニア出身の幹部として、適切な経営判断に貢献するとともに、それを技術者に橋渡しをし、また、技術者がより力を発揮でき
ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog
GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる
リリースの高速化はWebサービス企業にとって最重要である - Kentaro Kuribayashi's blog
インターネットを眺めていたら、リリースの高速化自体を目的化するのではなく、ビジネス成果によって成否を判断するべきだという主張があったので、思うところを書いておく。起点は他社さんにおける議論だが、そこは問題ではなくて、もし自分の関わるところでそういう議論が起こったら、自社の技術に対してそれなりのポジションにおいて関係する人間としてどのように考えるべきだろうかという視点で述べる。 リリースあるいはリリースの高速化自体を目的化するのではなく、その結果としてのビジネス的成果が大事だということは、マネジメントにとっては当たり前なわけで、いちいちいうまでもないことだろう。そもそも、サービスが圧倒的に成長し続けていれば、リリース頻度 = 成果になるはずだ。現状そうでないのであれば、成長速度が遅いということになる。エンジニアが技術を尽くしてリリース速度を向上させたにも関わらずそれが成果に結びつかないとした
書評『Chef活用ガイド - コードではじめる構成管理』 - Kentaro Kuribayashi's blog
『Chef活用ガイド』をご恵贈いただきました。ありがとうございます。 Chef活用ガイド コードではじめる構成管理 作者: 澤登亨彦,樋口大輔,クリエーションライン株式会社出版社/メーカー: KADOKAWA/アスキー・メディアワークス発売日: 2014/04/25メディア: 大型本この商品を含むブログを見る Immutable Infrastructureだから冪等性とかいらないんだーとかいう昨今ですが、そう簡単にはことは進まないので、ChefなりPuppetなりには今後もしばらくは活躍の余地があるだろうという見通しが共有されているところです。『入門Chef Solo - Infrastructure as Code』から1年経ったいま、決定版ともいえるような書籍が刊行されました。Chefの入門者はもちろん、Chefやその周辺環境をより深く知りたいユーザにとっても、有用な情報が満載である
ペパボのエンジニア評価制度をパワーアップした - Kentaro Kuribayashi's blog
mizzyさんのエントリ(paperboy is hiring - Gosuke Miyashita)にある通り、ペパボでは、エンジニアに関しては一般のラインとは別に、専門職としてのキャリアアップをしていくラインがあって、ここ2年ほど運用され、よく機能しているところです。そんな折、技術基盤チームも陣容が充実し、社内にもその存在や成果が充分に浸透してきただろうというわけで、半年ほど前からあたためてきた新しい制度を、先日から運用開始しました。 今回の制度は、上述の専門職としての評価制度はそのままに、既存の半期ごとの目標設定 → 評価サイクルの中に、エンジニア的観点をより盛り込んでいこうというものです。エンジニアであろうがなかろうが、一般に、事業目標をブレークダウンしたものが個々人の目標 → 成果になっていくわけですが、そうしたプロセスにおいて、より多様な観点からアウトプットの生産性を向上させて
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - Kentaro Kuribayashi's blog
JAWS DAYS 2014のImmutable Infrastructure(以下、II)に関するトラックに呼ばれたので、話をしてきました。Immutable Infrastructure時代のConfiguration Management Toolの要件およびその実装についてや最近のImmutable Infrastructureに関する議論(Orchestration編)というエントリを書いていたからということでしょう。 ただ、最近は首都大学東京ビジネススクール不合格記に書いたように、経営学関連の学習をずっと行っていて、すっかりそのような話題から離れてしまっていた、ありていにいえば特に興味を持たなくなってしまっていたので、進学していたら研究テーマのひとつにしていたであろう件について、だいぶ生煮えではあるけれども最近またそうした話題でネットが盛り上がっていたりもしたので、以下スライド
【無料】「継続的Webサービス改善ガイド」(WEB+DB PRESS Vol.75)【公開】 - Kentaro Kuribayashi's blog
以前寄稿したWEB+DB PRESS Vol.75の特集を、Web上でも読めるよう公開しました。 継続的Webサービス改善ガイド：特集｜gihyo.jp … 技術評論社 今日は、僕の書いた「第1章 なぜ「継続的Webサービス改善」が必要なのか～変化に対応し，10年後も生き残るWebサービスのために：継続的Webサービス改善ガイド｜gihyo.jp … 技術評論社」が公開されました。 特集全体の趣旨は以下のような感じです。 本特集のテーマは「継続的Webサービス改善」です。できるだけ長い間，ユーザに価値を提供し，利潤を生み続けるWebサービスを運営するためには，継続的な改善を行うことが必要です。Webサービスを改善するには，技術的な取り組みはもちろん，開発投資とそのリターンという経営的な観点，チームビルディングなどの開発プロセス，ビジネスメトリクスへの注視など，考慮すべきことがたくさんありま
A/Bテストでいちばん大切なこと - Kentaro Kuribayashi's blog
「A/Bテスト」が、Webサービスの最適化技法として人口に膾炙して久しい昨今ですが、それでもなお、個々の施策実行時にはいろいろと迷うことがあります。たとえば: 有用なテスト結果を得るためにパターンをどのような基準で用意すればよいのか テスト結果の統計的有意性をどのように検定すればよいのか 個々の改善がそれぞれによかったとしても、それらが局所最適に陥らないためにはどうしたらよいのか といったあたりが挙げられます。(2)については純粋に技術的な問題なので、ここでは議論しません。問題にしたいのは(1)および(3)についてです。ひとまず、いまのところ僕が思う一番大切なことをひとつだけ述べておきましょう。それは: 「それに対してなんらかの肯定的/否定的意見のあるパターンをテストする」 ということです。どういうことか。 視野狭窄的なA/Bテスト A/Bテスト、あるいは同様の最適化技法については、かつて
情報共有の必要性について
本エントリは、社内向けに書いた記事を公開するものです。 なぜ情報共有するのか みなさんご存知の通り、コーポレートサイトにて、以下のように謳われています。 意見やアイデアは、ミーティング、社内SNS、メールなどで積極的に発言しましょう。不採用かもしれないと思っても、他のアイデアと合わさることで新しいものになることがあります。そのために、すべてのアイデアに耳を傾けると同時に、頭に浮かんだことをどんどん外に出しましょう。 また、インターネットで表現し続ける、コミュニケーションし続けることを楽しんで、自分たちが一番のユーザーであることを心掛けましょう。 大切にしてほしいこと | 採用情報 | 株式会社paperboy&co. このことからもわかる通り、様々なことに関してアウトプットを行い、広く共有することは、我々みなに求められていることです。 組織面からの理由 他にも理由があります。それは、我々が
『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』 - Kentaro Kuribayashi's blog
訳出が待望されていた『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』が刊行されたので、さっそく購入して読みました。 この本は、ひとことでいうと組織変革を試みるひとへの手引です。組織には歴史や慣性などもあって、ただ意欲のまま無手勝流に変革に臨んだところで、きっとうまくいかないことでしょう。そこで、先人の知恵を集積したものとして紹介されるのがパターンです。プログラマにとってのデザインパターンが、ソフトウェア設計という困難な仕事に道標を与えるように、この本で紹介されているパターンたちもまた、組織変革にとって役立つことでしょう。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者: 川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,古家朝子,安井力,山口鉄平,米沢仁,角征典出版社/メーカー: 丸善出版発
理論と実践について - Kentaro Kuribayashi's blog
理論よりも実践を、という発言を読んで、僕自身そのあたりをあれこれと考えもするので、あらためて考えてみた。もちろん、当該発言をDISる意図はまったくなく(というか、まったくもって賛成するものである)、単純にもう少し具体的に考えてみたいという話である。 理論より実践の方が優れているといえる場合は3通りある。(1)理論そのものがくだらない場合。(2)行為者が優秀であるなどして、理論を内面化した、あるいは、あたかもそうであるかのような行動を取りうる場合。(3)行為者が非優秀なため、行動からしか学べない場合。(1)もわりとありそう。— kentaro (@kentaro) January 19, 2014 しかしたいていは(2)か(3)であることが多いと、経験的には思われる。(2)である場合は、(2)的能力を持っていない者はそれを額面通り受け取るべきではないし、(3)である場合は、(3)的非優秀者は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
