delirious thoughts

by Kentaro Kuribayashi

Serverspecの作者がつくる、あるひとつのOSS文化 - 書評『Serverspec』

著者のmizzyさんこと宮下剛輔氏よりご恵贈いただきました。ありがとうございます。

Serverspec

Serverspec

さて、本書について、技術的な側面で語れるひとはたくさんいるだろうので、ちょっと趣向を変えて、エッセイ的な話を書く。ちょうど、著者も「本書は、単なるServerspecに関する解説書ではなく、Serverspecに関する思いを綴ったエッセイとも言えるかもしれません」(「はじめに」より)と書いていることだし。

Serverspec誕生の頃

約2年前の今頃、ある新しいシステムのためにサーバを構築しようとしていて、我々(mizzyさん、@lamanotramaさん、僕)は苦心していた。Puppetでサーバ構成を記述するに際して、もっといけてる設計があるのではないかと、議論を重ねていたのだった。その結果としての設計は、僕の『入門Puppet - Automate Your Infrastructure』にも反映されているが、それはあと数ヶ月先の話。ある程度設計が固まり、さてその方針で既存のPuppetマニフェストリファクタリングしなければ、という時に、mizzyさんがあっという間にServerspecを作り上げ、公開した。

構築したサーバをRSpecでテストするという発想は筆者オリジナルのものではありません。前職時代の同僚であるhiboma氏が、LXCによるコンテナにChefレシピを適用したあとに行うテストをRSpecで書いていて、それを真似させてもらいました。Serverspecの初期プロトタイプも彼のコードからのコピペが多く、一日、というよりも数時間で完成しています。そして次の一日で、より汎用的に使えるようにブラッシュアップして、Serverspecという名前をつけてRubyGems.orgで公開しました。それが2013年3月24日です。

(pp.2-3)

本書でも「もともとは、筆者が当時書いたPuppetマニフェストリファクタリングするためのテストツールとして開発」(p.5)したとある通り、我々のPuppetマニフェスト書きにとって大いに役立ったのはもちろん、本書でも利用目的として紹介されている、著者が必ずしもそのように使われることをあらかじめ意図していたわけではない、下記に示す多様な用途に、リリース直後からすぐに使われ始め、あっという間に広まった。

  1. テスト駆動開発によるインフラコード開発
  2. サーバ構築後の確認作業の自動化
  3. 稼働しているサーバの監視
  4. サーバ再起動後の状態確認
  5. サーバのあるべき状態の抽象化

(p.5)

まさに、僕が「代表的プロダクト」と呼ぶものを、ほとんど一瞬にして作り上げたのを目の当たりにして、感嘆したのだった(そのあたりについては、「代表的プロダクト」についてというエントリに書いた。また、mizzyさんには他にも「代表的プロダクト」と呼べるものが既にあれこれあるわけだが)。もちろん、著者のインフラに関する経験や、「インフラをコードし、それをテストする」という熟成されたコンセプトが時機を得て花開いた、という、長年の蓄積あってのことなわけだけれども。

あるOSSの文化事例

そのような著者が、「思いを綴ったエッセイ」でもある本書は、Serverspecのユーザにとってもコントリビュータ(候補)にとっても「実用書」としておおいに有用であるのはもちろんのこと、広く使われているOSSについてその作者がどのような考えをもって開発してきたか、今後するつもりかということを記した、OSSに関する文化的な書物としても面白い。たとえばこんな調子だ。

Serverspecというツールの存在意義がある限りは、長く継続的にメンテナンスを行っていきたいと筆者は考えていますが、それを阻害する一番の要因はServerspec開発に対するモチベーションの低下です。特に、自分のためではなく、他人(特に意見を言うだけでコードで貢献しない人)のために開発を行うことが、最もモチベーションをすり減らす要因となります。

(p.12)

と述べた後、いくつかの方針を述べている。

  • 自分で使わない機能は、自分では実装しない
  • プルリクエストを送ってきた場合は、自分が使わなくても取り込む
  • ただし、Serverspecの基本方針にそわない機能は取り込まない
  • Rubyがまったく書けないひとのためには開発しない
  • 自分が困ってないバグは、困るひとが直すべき
  • コードの添付されない単なるバグレポートはいらない

「Serverspecの究極の目標」(p.16)が「『システムの継続的改善』に寄与すること」(同)であるように、Serverspecそのものの「継続的改善」のために著者が極めて明確なポリシを持ち、その通りの言動を貫いているのは、まったくもってmizzyさんらしいストイックさだなあとあらためて感心するとともに、ひとりのOSS開発者のあり方を述べた文章として、貴重だ。

一方で、単なる口先だけの意見ではなく、コードによってコントリビュートしようという気概の持ち主に対しては、著者は優しい。

仮に他のOSに対応できそうな拡張であっても、自身で利用していないOSに無理に対応する必要はありません。また、動作確認する必要もありません。筆者も基本的には自分がよく使うOS以外については、対応や動作確認はしないというスタンスでやっています。そのOSを使う人が自分で対応したり動作確認をすればよいという考えです。

(pp.115-116)

と、コントリビュータに対しても、自身へのそれと同様、公正にポリシを適用しつつ、プルリクエストの送り方について丁寧に述べ、「とはいえ、筆者はそれほど作法にうるさくありませんので、お気軽にプルリクエストを送ってください」(p.116)と呼びかける。Rebuild: 75: Book Driven Development (gosukenator)では、「コードの直し方は自分が一番知っているから、下手にコード書くより問題だけ指摘してほしい」というひともいるという話もあったが、いずれにせよ、これもまた、あるひとつのOSS開発の文化を端的に示す「エッセイ」として秀逸なエピソードである。

また、実際に本書を読むとすぐに気づくと思われるが、コントリビュートしてくれたひとのことをよく憶えていて、かつ、本書では重要な契機となった改善について、きちんと名前を挙げて紹介しているのも著者らしいなと、僕などは思わされるところだ。さらには、名前を挙げる際には、(確実に意図があって)必ず註釈の中でGitHubのURLを添えるというのも、まさにmizzyさんらしい細部でもある。ちなみに、僕自身の名前も、ある箇所で紹介していただいていてる(内容はコードのことではなくて恥ずかしいのだが。また、最近ちょっと別のことに打ち込んでいたせいでGitHubのコントリビューションが壊滅しているのも厳しい……)。

ServerspecとUNIX哲学

そうした「文化的」側面を伝える記述の他にも、「3.12 テストコードの指針」において述べられる考えにも、mizzyさんらしさはよく現れている。たとえば、Nginxのインストール状態を、バージョンをも指定してテストするべきか述べる場面で、

もし、「Puppetが正しく動作するか不安なので、指定のパッケージが指定のバージョンできちんとインストールされているかテストしたい」という考えでこのテストコードを書くとしたら、それはナンセンスです。そこが信頼できないのであれば、そのツールの使用はやめるべきです。

(p.58)

と書いたあと、続けて、

「Puppetマニフェストを書く人がパッケージ名を間違えたり、記述を削除したりするかもしれない」「バージョンが変わると自己が起きる可能性があるため、誤ってバージョンを書き換えたり、勝手にアップデートされたりしないようにしておきたい」という理由でしたら、このテストコードに大いに意味があります。

(同)

と述べるのは、短いパッセージでありながら「テスト」というもののあり方に対する著者の考えを示しつつ、極めて啓発的な文章になっている。同じ主題は、「5.4 サーバ構成管理ツール」において再び変奏される。ChefのNode AttirbutesをServerspecから読めるようにしてほしいという要望に著者は否定的な考えを持っていると述べた後、

Node Attributesと連携したいということは、Node Attributesで設定されているパラメータが、Chefによって正しく設定されているかテストしたいということだと思われます。ですがそれは、Chefが正しく動作している限りにおいては、正しく設定されているはずであり、そこはChefを信頼すべきでしょう。信頼できないのであれば、Chefを使うのはやめましょう。もし正しく設定されていないとしたら、それはChefのバグです。

このような著者の考えはまた、UNIX哲学における「1つのことをうまくやる」につながるものでもあり、また、「現実のシステムの複雑さと変化に対応するために、システムのあるべき状態を簡潔に記述し、継続するためのもの」(p.16)という「究極の目標」(同)を持つ、ServerspecというOSSを開発するに際して、一連のツールチェインのひとつをなす、そしてそこにとどまり続けることこそが正しいあり方なのだということを堅持する、これもまた、著者のOSS開発に対する活きた思想を示すことでもある。

おわりに

本エントリでは、僕自身の知るmizzyさんのひととなりを思い起こしながら、文化的な側面にフォーカスして本書を紹介してみた。もちろん、本書は実用書としても、広く使われているOSSの内部実装を解説する技術書としても非常に有用なものであることは、あえていうまでもないことだ。そのあたりは、多くのひとが書くだろうので、そちらを参照してもらいたい。

僕が述べたかったのは、本書が、我々のようなOSSに対して関わりの強いソフトウェアエンジニアにとって、たとえば『ハッカーと画家』や『Joel on Software』のような、技術文化に関するエッセイのような味わいを持つ傑作であるということである。

Serverspec

Serverspec

Androidアプリ開発をはじめた

Nexus 5を常用しているAndroidユーザになってしばらく経つので、そろそろAndroidアプリを作りたい気持ちになってきた。先日、そのためにMacBook Proを新調したほどの、気の入れようである。ちょうど3連休だったので、2日目・3日目を使って、あれこれ調べながら、初めてのAndroidアプリ開発をしてみた。

kentaro/palimpsest · GitHub

やりたかったこと

まずは簡単なタスク管理ツールを作ってみようと思った。こんな感じ。

  • 毎日習慣的に行いたいタスクがいくつかあるので、ちゃんと習慣的に行えるよう管理したい
  • タスクは、名前と回数からなる(例: 腕立て伏せを30回する、英和辞典を5ページ読む、みたいな)
  • また、ちゃんとしなかった場合は、前日以前の回数が今日の分に加算されるので、ちゃんと毎日やらないと大変なことになる

画面

ほぼ「sqliteのテーブル1つに対するCRUDを提供するだけのアプリ」といってよいものなのでたいしたことはやっていない。

トップ画面。タスクが並んでいる。それぞれのタスクの数字は、1日のノルマ回数 * タスクをやらなかった日数が表示されている。サボると大変なことになる(以下の場合、3日サボるとスクワットを300回やんないとならなくなる)。

右上のボタンを押して、タスクの新規作成。

リストのタスクをタッチすると、編集と削除。

わかりにくいけど、チェックボックスをチェックすると、その日のノルマが消える(タスクそのものが消えるのではなくて)。スワイプでやりたかったけど、面倒そうなので断念した。

学習に際して注意したこと

  • iOSの世界もそうだろうけど、Androidの世界も移り変わりが激しくて、少し前のドキュメントやノウハウがすぐに古びてしまう。なので、最新のプラクティスを学ぶことを心がけた。Androidの開発におけるベストプラクティスというドキュメントが役だった。
  • そのため、ググって得られるブログ等はありがたいけど、玉石混交という感じなので、ひとつのブログを見て真似せずに、比較検討の上で、ダサくなさそうなやりかたを採ることにした。
  • 使えそうなライブラリは使うことにした。その際、モバイル界隈でのレピュテーションをよく知らないので、そういうのを気にしながら選定したりした。

わかったこと

  • Android Studioめっちゃ便利。ショートカット憶えられないので、⌘↑Aで出てくるあれこれ操作を検索できるやつしかほとんど使ってないけど……(いまのところそれで足りてる)。
  • IdeaVimがいい感じなので、編集もかなり楽々。
  • iOSほどじゃないのかもしれないけど、すごくたくさんのライブラリがある。便利。特にアノテーションを駆使したようなものは、便利なものが多い印象。
  • 設計のパラダイムがわりとコロコロ変わっているのかな?と思われた。また、iOSに比べて自由度が高い感じがする。面倒がない反面で、どうしたらダサくないのかがあんまりわからない。
  • やっぱ憶えるべきことがたくさん。Java自体には抵抗ないし、実装についてもこういう感じでできるだろうな、というのはこれまでのあれこれの経験からわかるが、実際にどうやったらいいかは調べ回る必要があるので、時間かかる。場数踏むしかなさそう。

便利だったもの

IdeaVim

Vimmerなので、とりあえずこれがないと。

ActiveAndroid

タスクの記録にsqliteを使ったのだけど、素でやるとなんか面倒そうだったので、これを使った。使い方自体は簡単なのでドキュメントのままという感じ。

ハマった点: いったんテーブルが作られるとクラス定義をかえても反映されたりしないので、一度table自体を消す必要があった。

Otto

最近はfragmentなんてものがあるそうで、以前のようにactivityをバンバン作るみたいな感じじゃないようだ。以前に買って読むだけしていたわりと新しい本(『プロの力が身につく Androidプログラミングの教科書』)でもほとんど触れられていないし、本とかではまだあんまりベストプラクティス的なのは紹介されていないのかな。んでもって、かといってfragmentとactivityを、Android Studioが吐くひな形にもあるように密結合させちゃうとよくないから、Ottoなどのイベントバスライブラリを使うとよいとのこと。

ハマった点: 以下のようにした時に、replaceされたfragmentでsubscribeしているハンドラが呼ばれなくてつらかった。

public void switchFragmentTo(Fragment fragment) {
    getFragmentManager().beginTransaction()
            .replace(R.id.container, fragment)
            .addToBackStack(null)
            .commit();
}

layoutに背景色をつけた上で、replaceじゃなくてaddするようにした。

public void switchFragmentTo(Fragment fragment) {
    getFragmentManager().beginTransaction()
            .add(R.id.container, fragment)
            .addToBackStack(null)
            .commit();
}

Butter Knife

ドキュメントにはいろんなことが書かれていて、正直まだよくわかってないものもあるのだが、以下のものを実際に使って便利だった。

  1. viewのインジェクション
  2. アノテーションでのリスナ定義

1)については、いちいちfindViewById(...)とかなんとかするのだるすぎるなと思ってたら、これで解決だった。2)については、fragmentとかに、以下のような感じでメソッド作るだけで、リスナの匿名クラスわたして云々みたいなだるいのが解決するので、便利だった。

@Optional
@OnClick(R.id.task_form_button_delete)
public void delete() {
    this.task.delete();
    BusHolder.getInstance().post(new OnDeletedEvent(this.task));
}

よくわからないこと

おおむねよくわからないのだけど、特に、

  • fragmentの移動については、1)現在のfragmentがOttoのイベントバスを通じてイベントを投げる 2)Main Activityが拾ってハンドリングする、みたいにしているのだけど、Androidでは「戻るボタン」の存在があるために、統一的に扱えなくてしんどい。どうしたらよいのか。
  • fragmentの中でgetActivity()したら負けと思ってがんばったが、そうしないとならない時もありそう
  • Butter Knife便利だけど、匿名クラスの中であれこれやりたいこともあって、そういう時には使えるの?使えないの?よくわからんかった。
  • UI作るの、難しくて大変。fragment使ってるのでスマホタブレットとでいい感じにみたいなのできるようだけど、要素の指定とか、冗長な感じになるのかなあ?
  • デザイン的なとこ(スタイルとか画像とか)全然やってないのでまだよくわからない。

などなど。

次にやりたいこと

  • Webと連携するようなアプリを作りたい
  • デザインをちゃんとしたものを作りたい

読んだ本

ちょっと前に、Javaの復習のために以下を読んだ。

AndroidエンジニアのためのモダンJava

AndroidエンジニアのためのモダンJava

本はよさげなのが見つけられなかったが、WEB+DB PRESSの以下の号の特集がよかった。

WEB+DB PRESS Vol.81

WEB+DB PRESS Vol.81

MacBook Proを購入した

2015年の抱負に書いたことの実践のひとつとして、もうちょっと技術的なことをちゃんとやってこうということで、それには2011年モデルのMacBook Airでは非力過ぎてつらいので(Android Studioなどはまったく動かない感じ)、MacBook Proを購入した。消費税込みで約27万という出費は痛いが、元を取れるようがんばろう……。

開封

自分で買ったMacとしては4台目とかなのかな。親が古くからのMacユーザだったのでお下がりを使ったりして20年近く使っているけど、社会人になってからしばらくは仕事の関係もあってVaioを使ったり、ThinkPadUbuntuとか入れて暮らしたりしていたので、途中にブランクがある。新しいマシンを買ったからって、もうあんまりワクワクしたりはしないけど、RetinaディスプレイMacをいままで使う機会がなかったので、「すげーきれーだなー」とか普通に感激してしまった。

2015年の抱負

いざその時がくると面倒だなと思うものの、書いておいたらおいたであとになってふりかえるのに便利なので、2015年も抱負を簡単に述べておきます。

仕事面

2014年のふりかえりに書いた通り、それまでとは違う立場であれこれと仕込みをやってきた。2015年は、仕込んだものを実行に移して成果を出していく年になるだろう。自分に対して、ちゃんと物事をやり切るという意志が薄いのが欠点だと思っているのだが、いまはそれなりの規模の責任もあるので、そんなことではいられない。今年はほんと、きっちりやり切るのみだ。

現在わかってるところはそんなものだが、まあ、そうはいってもやっぱりいろいろあるだろうから、その場その場で適切な判断をして、後悔のないように事を進めていきたい。高い目標を掲げ、必ず達成するまでやり切る。また、足元を見るだけでなく、長期的な展望のもとに、いまここにあることを可能としている条件そのものを、必要とあらば変えていくことを忘れない。

まあ、もういい歳なので、仕事面で目標達成できれば、だいたいそれでOK(詳しい内容は、ここには書けないが)。あとは余談。

技術面

2013年までは、新しい技術をバンバン取り入れて、かつ、自分でも手をたくさん動かしてアウトプットしていたが、去年はもうちょっと組織的な面に心を配っていた。それはそれでよいのだし、まだまだやるべきことはたくさんあるが、それなりに形もできつつあるので、今年はもう少し、直接的に技術に関わる方へあらためて舵を切りたい。

とはいっても、別になにかサービスに直接たずさわっているわけではないので、そうはいってもいままでとはやっぱりちょっとレイヤが違うだろうけれども。まずは、上述の職務面に関することで、必要なことをどんどんやっていきたい。なにはともあれ、もう少し手を動かすのを増やしていきたいところ。GitHubのContributionsもボロボロになってしまったし……。

分野としてコレというのはいくつかはあるけど、具体的に書いてもしかたなかろうので割愛。大切なのは「組織能力を圧倒的に成長させること」に書いた通り、「自分自身の技術的限界が、会社の技術的成長において制限とな」らないよう、研鑽を継続するということだと思う。また、今年も新たな若者たちが入ってくるので、彼らに残念に思われないよう、技術力を高めていきたい。

学習面

去年は、経営学に関する本(ビジネス書ではない)をたくさん読んだ。受験勉強をしていたのと、必要に迫られたからという理由でそうしていたのだけれども、けっこう面白くなってきたので、今年はもうちょっときちんと教科書的な基礎を学んだり、研究書や論文を深掘りしたりしたいと思う。

経営学関連にかぎらず、いつも思ってはいるができていないこととして、もうちょっとまともな知識を身に着けたいというのがある。なにをもって「まともな知識」というかは、僕はわりと独特な考えを持っていると思うので割愛するが、ともあれ、ただひたすら雑然とした読書をするのではなく、もうちょっと系統だって知識を得ていくようにしたい。そのためには、歴史について知るというのを筋として通す必要があるだろう。

また、語学については、英語がやっぱり課題だ。実感としては、少しづつはできるようになってきてはいるものの、TOEICの点数はまったく変化がない(上がりも下がりもしない)し、目に見える成長を感じられない。今年は、あれこれ考える前にまずはTOEICの点数を上げることを目標に、より計画的に学習していきたいと思う。また、英語ばかりやってても飽きるので、仏・伊語の文法書をそれぞれ読み切るぐらいはしておきたい。

プライベート面

相変わらず、仕事の時間以外はほとんど、本を読むか近場の店に飲食にいっているかで、渋谷から出ることもほとんどなく、半分引きこもりみたいな状態だった。まあ、それが悪いとはあまり思っていないので、多分今年もそうだろうなあ。もうちょっと展覧会などあれこれ行きたいのはあるので、そこから引きこもり脱出に向けてリハビリするべきだろうか。

先月38歳になってあらためて振り返ってみるに、これまで僕は、可処分所得をほぼすべて、何も考えることなく書籍と飲食とに費やしてきたので、健康面・金銭面で著しく不安な状態にある。書籍についてはまあ自己投資といえばいえるけれども、上述した通り、ただ雑然と読んでいるだけでは、暇つぶしの娯楽と変わらない。健康面については、そろそろちゃんとしないと取り返しがつかないなと思ったりしている。

というわけで、今年はまず「健康第一」という、10年前の僕が見たらがっかりするだろうけれども、寄る年波には勝てぬということで、そういう方針で行きたいと思う。病院が苦手なので、調子が悪かったり、明らかに行くべき状態でもまったく行ってなかったのだが、今年はちゃんといって、持病を治したりもしたい……。あと、結婚もしたい……。

2014年12月に読んだ本をブクログでふりかえる

今月は34冊(2014年の1年間は268冊でした)。つっても、『3月のライオン』を一気読みしたので、漫画が10冊ちょっとあるけど。

久々に小説をけっこう読んだ。まずは、田中康夫『33年後のなんとなく、クリスタル』。田中康夫さんの小説はすごく好きで、昔たくさん読んだものだけど、その彼が久々、かつ、『なんクリ』のその後を書いたものが刊行されていて、即座に買って読んだ。その他、阿部和重さんと伊坂幸太郎さんの共作ってんで気になった『キャプテンサンダーボルト』は期待に違わず面白かったし、中島京子さんの小説は「これぞまさに小説!」と興奮して、一気に4冊連続で読んだりした。

なんかのきっかけで『最貧困女子』を読んでいたのだけど、そのおすすめにあった鈴木涼美さんの『身体を売ったらサヨウナラ』が非常によかったので、『「AV女優」の社会学』を読んだり、そこから派生して『「AV男優」という職業』を読んだりした。AV業界、話は面白いのだけど、いろいろ大変そうだなあ。かとおもいきや、植物の面白さに突如目覚めて、図鑑を買って眺めたりしていた。自分の興味の行き先がだいぶわからない。

今年はかなり雑多な感じで本を読んでいたので、来年はもっと冊数を減らして、じっくり読むべき本をちゃんと読んでいきたい。

kentaroの本棚 - 2014年12月 (34作品)
ばかウマ
堀江貴文
読了日:12月06日
評価3

最貧困女子
鈴木大介
読了日:12月13日
評価4

小さいおうち
中島京子
読了日:12月27日
評価5

powered by booklog

2014年のふりかえり

年の瀬なので、2014年をふりかえる。

2014年の抱負

2014年の抱負」で抱負を述べた(いま初めて再読した……。本来、こういうのはもっと定期的にふりかえるべきだろう)。ちょっと長いが、引用。

私の本業はなんでしょうか。それはソフトウェアエンジニアです。もうちょっと広くいうと、問題の発見・解決をするに際して、技術的観点からそれを行う専門家といったものです(まあ、それをソフトウェアエンジニアというのでしょうけれども、ちょっと違う)。そのように自己認識を行うと、単にソフトウェアエンジニアというところからは、いろいろとやるべきことが広がってきます。いつかtagomorisさんがいっていたように、自称が自認を決定するわけです。

もちろん上述認識は、ソフトウェアエンジニアという自己規定を包含している、というか、それに基礎づけられているわけですから、まずはその方面においてさらに自己研鑚を行っていく必要があります(そもそもソフトウェアエンジニアとしてのスキルについて、まだまだ伸びる余地があるし、そうするべきだと思っています)。それに加えて、自己(あるいは自分が関わっているあれこれ)の基盤そのものを可能とする条件についてリフレクティブな考察を行い、それをもってさらなる非連続な発展を遂げる必要があるとも、この頃は思うわけです。

抱負とかいって立派なものを掲げても、なかなかその通りにはやれないわけだが、今年はけっこうこの通りにあれこれやったように思う。では、何をやったのか。

1月〜3月: エンジニアリングと経営

年頭、1月7日「 ジェネラリストについて」というエントリを書いた。ソフトウェアエンジニアというスペシャリストでありつつも、性格上拭い難いジェネラリスト志向があり、それらにどう折り合いをつけるかということへの回答が、この1年の取組みだったようにも思う。

すなわちそれは、先に「2014年の抱負」から引用した「問題の発見・解決をするに際して、技術的観点からそれを行う専門家」としてのソフトウェアエンジニアという枠を、もうひとつ上のレイヤへ押し上げようというものであった。つまり、経営のほうへと一歩踏み出すということだ。

それと同時に、折からの組織論への興味関心があって、経営学を学べる大学院に行こうと思って「首都大学東京ビジネススクール不合格記」に書いたとおり、ビジネススクールの受験をしたりしたのだが、不合格になってしまった。そのため、そういう方向からは攻められなかったのだが、いろいろあってそれどころじゃなくなってしまったので、結果的にはよかったと思う。

以下、その関連で書いたエントリ:

4月〜6月: 地固め

いろいろあって僕とhsbtさんとであれこれ引き継ぐことになったので、社内のエンジニアに関する体制や制度を地固めしていた時期。上述した、レイヤを経営に寄せていくことを考えていた時は、そういうのを実際に試みるのはずいぶん将来のことと考えていたのだけど。

まず、これはmizzyさんがいた頃からやりたいといっていたことだが、エンジニア全員について技術的観点からの評価を取り入れようという制度を導入した。その際、勝手に基準を決めてもしかたないので「エンジニア評価のしくみをイイ感じにいじりましたであります | ジンジン(ペパボ人事のブログ)」にあるように、東京・福岡でワークショップをやったりしながら、みんなで評価基準を決めるという取組みを行った。

次に、エンジニア職位制度も評価者が変わるということで、あらためて「こういう考えで評価します」というのを社内外に告知したり。「技術力」というものを、以下3点に言語化した。

  • 作り上げる力
  • 時間の経過に耐える力
  • 影響を広げる力

全体的な水準についてこれまでとは変えることなく、評価軸を明確化することで、より取り組みやすい制度になったように思う。

その他、採用にもより深く関わるようになった。当時新卒採用の後半戦だったので、以下のエントリにあるスライドを作って説明会を行ったりもした。

7月〜9月: 技術責任者として

GMOペパボ株式会社の技術責任者に就任いたしました」に書いた通り、8月1日付けで、僕が技術責任者、hsbtさんがチーフエンジニアに、という体制を作った。このことで、エンジニアリングに関するレイヤをひとつ上へと上げるとともに、マネジメントと技術をふたりで分担することで、より強い体制を作れたと思う。

で、「具体的に何をやってたの?」というところに関しては、まだあれこれと書ける状況ではないので、割愛。社内的には、経営会議のメンバーになるなどして、経営へのコミットを少しだけ持つようになったりした。

10月〜12月: 飛躍的な成長へ向けて

エンジニアの採用について、自らの目標化して取り組むことに決めたので、下半期はあれこれやった。そのうちのひとつとして、ペパランチョンなるものを始めたり。これは、東京・福岡で、話してみたいエンジニアを指名してランチを食べながら会社のことをあれこれ聞けるというもの。マイナビさんに取り上げていただいた(選ばれるエンジニアはドキドキ!? - 転職志望者が自由に話を聞ける、GMOペパボの「ペパランチョン」企画とは | マイナビニュース)。

これまで書いてきた社内の制度・体制にしても、エンジニアの採用にしても、そういうことをやる目的というのを強く意識する必要があって、その目的とは、まずは「成長する」ということだ。「成長」という面において、みなが強くそれを志向しているかといえば、僕の立場からいうとまだまだだと思っている。

以下のエントリは、そういう意味でエンジニアたちに向けてアジテートするために書いたもの。圧倒的に成長しない限り、将来はないのだから。

また、技術責任者としては、適切な技術選択・ポートフォリをの構築を行うというのもまたその仕事のひとつである(そのあたりは、id:stanakaさんの「CTOの役割と組織における技術的ポートフォリオの組み方 - Hatena Developer Blog」に詳しい)。その一環として行ったのが、以下。

その他、来年の取り組みに向けて、プロジェクトの発足や組織作りなど、あれこれといろいろやっていたけれども、そのへんは割愛。

技術イベント

以下5つに出て、おしゃべりしてきた。まあ、上述したような事情もあったりして、自分自身の関心が変わりつつあったので、純粋に技術的内容というよりは、少し違ったレイヤの話が多かった。

まとめ

というわけで、「2014年の抱負」に:

自己(あるいは自分が関わっているあれこれ)の基盤そのものを可能とする条件についてリフレクティブな考察を行い、それをもってさらなる非連続な発展を遂げる必要がある

と書いた通り、少なくとも自分にとってはそれを成し遂げつつあるという1年だったかなと思う。

組織能力を圧倒的に成長させること

この記事は、Pepabo Advent Calendar 2014の12日目の記事です。前日は、hisaichi5518さんの「Web APIを作るときに考えること。 - パルカワ2」でした。


ここ半年ほど考えていることを、以下に述べる。

技術とは何か?

「技術とは何か?」という問いに対しては様々な回答があり得るが、ひとまず「企業にとっての技術」という観点からいえば、経営学による以下の記述にその定義を求めてもよいだろう*1

すべての企業が、自分が必要なインプットを市場から買ってきて、それに自分が得意とする「技術的変換」を加えて、その結果として生まれてくる製品やサービスを市場で売っている。

(中略)

誰にでも容易に手に入る財やサービスであれば、とくに企業が存在してその提供を業とする必要はない。その提供プロセスが難しいからこそ、その困難さを解決する努力が企業の「技術的変換」になるのである。

ここでいわれているのはふたつ:

  1. 「その結果として生まれてくる製品やサービス」というのは、単なる変換結果ではなく、インプットに対して「付加価値」を加えたものであるということ(そうでなければ買われない)
  2. そして、その「技術的変換」は、企業を成すことなく行うには難しい程度には困難であること

1)を図示すると、以下のようになる*2

インプットを元に、企業が付加価値を加えてアウトプットする。それが「技術」である。しかし、1)を満たしさえすればそれが「企業にとって」有意味な技術足りうるかといえばそうではないというのが 2)のいわんとするところである。

延岡健太郎『MOT[技術経営]入門』*3は、その付加価値創造のプロセスを「価値創造」と「価値獲得」とのふたつに分けたうえで*4、日本企業は前者には長けてきたが、近年は、後者において困難に際していると述べる。

とすれば、冒頭の「技術とは何か?」の回答としては、ここではひとまず「企業が、インプットを、付加価値を加えたアウトプットに変換し、市場からその対価を獲得するのに必要な能力」ぐらいの意味ととらえておけばよかろう。

組織能力

価値を創造した上で、それを企業にとっての価値 = 事業価値としての「価値獲得」に結びつけるためには、それが顧客にとっての「付加価値」となる必要がある。すなわち、単に何かを作るだけではなく、競合との争いに打ち勝ち、顧客にとって真に望まれる価値を「付加価値」というわけである*5

その事業価値をどのようにして作り出していけばよいのか。上図に示した通り、以下のふたつがあり得る。

  1. 差別化・独自性・オンリーワン
  2. 戦略・儲けの仕組み

いずれにせよ、3Cの関係において、自らを他とは違う存在として市場にアピールできるかどうかにかかってくるということだ。その時、どのように「違い」を示すかといえば、その方法として、大きくふたつがある。

  • 商品による差別化
  • 組織能力による差別化

いずれも重要であることは間違いないが、こと商品による差別化には困難がある。それが目に見えるものであることから模倣が容易であるため、長期にわたって企業を支え続けるのは難しい。そこで「見えざる資産」(伊丹敬之)であればこそ、他社の模倣が難しく、長期的な優位性をもたらす「組織能力」の向上が重要となってくるわけだ。

では、その「組織能力」とはなんであるか*6

「組織能力」とは、企業が固有に持つ有形無形の資源と、それを活用する能力やプロセスである。このような能力は、通常組織が長年の試行錯誤を繰り返した結果、企業内に蓄積される。

具体的には、「技術的資源」(特許、データ、実験機器、製造機器など)や「人的資源」(個人の知識やノウハウなど)、およびそれらの資源を統合して効果的・効率的に活用するための組織プロセス(よい意味での「組織ルーチン」)として、蓄積される。

そのような過程で蓄積される組織能力は、特定組織に固有のものであり、暗黙的であったり属人的で あったりするので、他の企業が真似をしようとしても難しいし、市場で購入することもできない。

Webサービス企業の組織能力

技術の定義において見てきた「インプット」とは、Webサービス企業においては、「ヒト」が多くを占める。その人々により組織された企業が、顧客に対して「付加価値」をもたらすであろうサービスを提供することに、数多の競合としのぎを削っているわけだ。

そのような「ヒト」が重要な位置を占め、また、参入障壁の低いWebサービス企業においては、その名が示す通り、いかに付加価値をもたらす「サービス」を提供できるかが重要である。すなわち、一般に想像されるような、いわゆるプログラミング技術などのようなものが、必ずしもコアコンピタンスであるというわけでは、必ずしもない。例を示そう。

あるビジネススクールケーススタディ*7は、クックパッドのコアコンピタンスとして、第一に以下のように述べている。

  • 市販のソフトやツールを使わず、全てのシステムを自前の技術で開発し、徹底的に検証 し改善を図っている。これは、Google と同じ発想である。
  • レスポンスタイムに対する徹底的なこだわりを持っている。具体的には、20 ミリ sec 以下(引用者註: 200msecの誤りであると思われる。)のレスポンス保証、16 時前後の圧倒的ピークにおいてもレスポンス低下させない 仕組みなどである。
  • その他として、以下のような技術について特筆すべき点が挙げられる。
    • アクセスログを解析する独自技術の確立&開発
    • 独自技術の追求の結果、2008(平成 20)年より Ruby 言語の全面採用
    • 徹底したユーザインタフェース(UI)へのこだわり

上記に示されるクックパッドの技術に高いものがあるのは、この業界にいれば誰もが知っていることではあろう。しかし、それに反して、中の人はこのように語っている*8

『クックパッド』だと、技術ってコアコンピタンスじゃないんだよね。事業を成長させるという観点から見ると、新しい価値をつくっていくのは、新規事業やサービス開発とかの企画サイドだったりするわけで。

すなわち、主に「ヒト」という入力をもって、顧客にとって価値のある「サービス」や「事業」を提供するに際して、狭義の意味における「技術」とは、「組織能力」の一部に過ぎないことが述べられる。もちろん、それは付け足しで済むものではなく、重要な一部であるにしても、クックパッドほどの技術をもってしてなお、そのように語られることの意味は重い。

技術と組織

とはいえ、Webサービス企業が、ソフトウェアという純粋に技術的産物によってサービスを提供するという業態である以上、そのサービスを提供するプロセスにおいて、比重の多くを狭義の「技術」が占めるのは確かなのであってみれば、「技術」に関する組織能力を高めていく必要があるのはいうまでもない。

そのため、当社であれば「技術基盤チーム」のような横串の組織を導入し、コアコンピタンスとしてのサービス提供能力や、これまでの蓄積をより効率的に付加価値へ変換するために、狭義の意味における「技術」の下支えを行っているわけだ。そして、その重要性について適切に経営へ反映するために、幹部社員としての技術責任者*9という役職を設置している。

また、組織能力を高めるという観点からは、このブログでも縷々示してきた以下のような制度が挙げられる。

このような、組織に関する制度により、直接的に能力の向上を図るという取組みは、どのような会社も大なり小なり行っているだろうし、その事例も昨今では多く公表されている*10

組織能力のトップラインを上げる

それらはいまも変わらず重要なことだが、ここで新たに述べたいのは、もっと別のことである。すなわち、エンジニア/エンジニアリングのビッグピクチャで述べたような、単に狭義の「技術」のみでない、組織能力という意味においての「技術」のトップラインを上げることについてである。

上述のエントリにおいては、エンジニア個々人の能力のトップラインを、市場の期待成長率になぞらえてみたが、他にもいろいろな観点があり得るだろう。より大きな成長を見据えるならば「100倍で考える」*11ということでもよいだろう*12

そのためには何が必要か。技術的な能力を上下左右に大きく広げる必要があると考える。上下左右とはすなわち:

  • 上下: いまできることを、さらに大規模にできるようになる。あるいは、さらに深掘りしてより本質的な技術を極める
  • 左右: いまもっていない知見・能力を獲得するべく、幅を広げる

たとえば上方向の意味においては、僕自身の例を挙げてみよう。先述の通り、「技術責任者」という役職を担っているからには、自分自身の技術的限界が、会社の技術的成長において制限となり得る。もちろん、個別の「技術」において僕より優秀なひとはいくらでもいるが、役職というのは、反面ではそのような制限をもたらし得るものだ。

そのような制限のために、たとえ上述したような制度的仕組みを策定し、うまく回せたとしても、能力の不足によって長期的な構想に基づく大規模なプロジェクトを企画・実施できないようなことになれば、なんのための役職かということになってしまう。その意味において、僕はいまでも自己の能力を大いに向上させることに余念がないし、実際に、「主に技術を用いた問題解決能力」という意味における「技術力」の成長率は、他のエンジニアたちにひけを取らないと考えている。

左右方向でいえば、先般公表した「ペパボのフロントエンドスタンダード」という取り組みが挙げられるだろう。これは、ますます複雑化・高度化する技術環境の変化に、我々が必ずしもキャッチアップできていないかもしれないという、強い危機感のもとに始まったプロジェクトだ。そういうジャンルは他にもいくつかあるが、まずはこうした取組みによって、不確実な将来に対してよりよく立ち向かえるための基礎作りを行うことが、組織能力のトップラインを上げるということだと考える。

まとめ

Webサービス企業は、競合とのせめぎ合いの中で、いかに顧客にとって「付加価値」となるアウトプットをもたらすかという戦いのただ中にある(3C)。その際に拠り所となるのが組織能力だが、これは単に狭義の「技術」のみからなるものではない。そうはいっても、技術が組織能力の枢要を占めることは確かであるのだから、それを飛躍的に向上させるには、成長への強い決意を持って組織全体を引っ張っていく必要がある。

ゼミナール 経営学入門 ゼミナールシリーズ

ゼミナール 経営学入門 ゼミナールシリーズ

MOT“技術経営”入門 (マネジメント・テキスト)

MOT“技術経営”入門 (マネジメント・テキスト)

技術を武器にする経営 日本企業に必要なMOTとは何か

技術を武器にする経営 日本企業に必要なMOTとは何か

How Google Works

How Google Works

*1:伊丹敬之・加護野忠男『ゼミナール経営学入門 第3版』日本経済新聞社、2013年、pp.1-2

*2:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年、p.21より筆者作成

*3:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年

*4:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年、p.33より筆者作成

*5:このような見方を、競合(competitor)・顧客(customer)・自社(company)の3つの頭文字をとって、3Cと呼ぶ。

*6:延岡健太郎『MOT[技術経営]入門』日本経済新聞社、2006年、p.50

*7:「事例研究 クックパッド株式会社」http://www.wbc.ac.jp/pdf/h25jigyou/p2-3-6.pdf

*8:「【後編】 元・超ワガママエンジニアのクックパッドCTOと語る、「CTOって何する人だ?」論 / 飲み会で探るエンジニアのホンネ #naoya_sushi 編」http://tenshoku.mynavi.jp/it-engineer/knowhow/naoya_sushi/02

*9:GMOペパボ株式会社の技術責任者に就任いたしました」http://blog.kentarok.org/entry/2014/08/01/150159

*10:直近の例では、「エンジニアの評価観点について」https://gist.github.com/katzchang/52eb6c8520f2fd4a1025、「エンジニアのキャリアパスと役職定義」http://tech.gmo-media.jp/post/104968432114/careerpath2014

*11:「100倍で考える | Preferred Research」http://research.preferred.jp/2014/10/100x/

*12:しかし我々は、Google的な「スマートクリエイティブだけ採用してればいいじゃん!」的エリーティズムを、その魅力を認めつつも、採ることはしない。「スマートクリエイティブ」に関しては、エリック・シュミット + ジョナサン・ローゼンバーグ『How Google Works』日本経済新聞社、2014年を参照のこと