Developer's Summit 2016 【18-D-7】エンジニア・コミュニティで組織は動き出す〜これからの時代のエンジニア、組織、エンジニアと組織の関係とは 聴講メモ
講演資料
http://www.slideshare.net/ssuserafaef6/ss-58412612
概要
エンジニア出身の経営者が、Pythonエンジニアを集中して採用することで発生した会社の変化を通して、これからのエンジニア、組織のあり方と、両者の関わり方について話す。
スピーカー
- ビープラウドの佐藤社長。
- 20年エンジニア、10年経営者。
野球ファンらしい。野球のユニフォームをIT勉強会の正装にしたいらしい。
詳細
ビープラウド
などをやっている。
Pythonをメイン言語に採用したあとで見えてきたもの
会社設立からPython採用まで
- 当初はJava、Perlを使っていたが、2008年にメイン言語をPythonにした。
- 当時はメンバー4人、Python開発実績は0件。
- Java,PHPのエンジニア採用は大手との競争になる、資金力で勝てない。
- Pythonは仕事で使っている人が少ない、競争を避けられるのではと考えた。
Pythonを採用した結果
個性的なエンジニアをどう束ねるのか
- と、よく聞かれるが、束ねない(制御しきれない)。
- エンジニアの声に耳を傾けて経営している。
Pythonを採用してから変わったこと
これからの時代の会社のあり方とは
- 従来は工業社会。肉体労働者と階層型の組織構造。
これからは知識社会。組織構造の姿は模索中というのが現状だと思う。
私なりの答えはエンジニアリングコミュニティのような形。
- エンジニアコミュニティとは、エンジニアが自発的に参加し、様々な価値を生むコミュニティ。
つまり、これからの時代の会社は、『エンジニアがのびのびと創造性を発揮し価値を作り出せる会社』
この点について、以下3点を軸に話したい。
- 組織
- エンジニア
- 組織とエンジニアの関係
組織(会社をエンジニアコミュニティに)
- 会社=コミュニティである
- コミュニティとは、同じことに興味を持った人たちの集まり。
- 同じことに共感、感動できる→暗黙知の共有、情報共有→知識レベルのアップ→会社自身のブランドになる。
- こういうコミュニティを作るのに、組織にとって大事な事柄。
- 雑談の積極奨励
- 社内勉強会のような場作り
- OSS(オープンソース・ソフトウェア)型運営から学ぶ
OSSのコミュニティ運営の特徴は以下3点。
1. フラット化組織
階層型組織にはこんな特徴が。
- 管理しやすい。
- 官僚制。
- 階層間で情報が滞りやすい。
出世に目が行く。
管理しやすいのでうまく回れば上の人が楽だが、内発的動機、自尊心、好奇心が失われる。
- 結果的に創造性が失われる。
一方でフラット化組織。
- 目的ごとにチームを作り、役割を決める。
- 管理のためのルールは最小限。
- 仕事をスムーズにすすめるためのルールに限定される。
- 仕事は進めやすいが、管理が難しい。
フラット化組織のポイントはセルフマネジメントと信頼関係。
- 管理する、されるの関係を作らない。
- 管理コスト、コミュニケーションコストを削減し、本来やるべき価値に集中できる。
経営者はコミュニティ・リーダーであり、権力ではなく役割。
- 権力ではなく良い人格を持つ事が重要。
2.コミュニティ評議会
- 『Art of Community』に記載されている意思決定グループ。
全体運営を担当、課題がある場合、ここに提出し評議会内で評議する。
ビープラウドでは、会社改善目的のプロジェクト(BP改善プロジェクト)を作った。
評議会を会社に置くメリット
- 自分たちで良い制度を提案していくので参加者意識、当事者意識が高まる。
- 決定プロセスの透明性が高く、公平感がある。
3. コミュニケーション
OSSのコミッターはフルタイムの仕事ではなかったり、世界中バラバラに仕事していたりする。
- 時間、リソース、場所の制約が多い。
- 隙間時間で成果を出している。
- が、それは実は会社も同じ。
リモートワークの体制づくりで制約を超える
- 通勤時間の削減や、家庭の事情で出社できない人も仕事ができるようになる。
- 『リモートワークはチーム仕事に向かないのでは?』という話もあるが、段取りが重要だと考えている。
- アイデアを生み出すのはチームだが、作るのは個別。
- すべての時間を顔を合わせる必要はない。
エンジニア(創造的なエンジニアになる)
創造性を発揮するからには、エンジニアは創造的である必要がある。
OSSのコントリビュータなどの創造的なエンジニアは、価値に目を向けつつ、アイディアを持ち、そのアイディアを実装することで価値を提供している。
つまり創造的なエンジニアになる=主体的に価値を作り出すエンジニアになること。
そのためには。
不安を乗り越える
- 創造性の最大の敵は不安(出来なかったらどうしよう)と恐怖(出来なかったら首になる)。
- ディフェンシブな志向になり、創造性を失う。
不安を乗り越える方法は2つ。
- 技術を身につける
- 不安の原因は自分に自信がないから。
- 不安がなくなるまで徹底的に学ぶと良い。
- 体(仕事ができる健康)→技(技術力)→心(不安の克服)と身につけていけば良い。
- 今を生きる
- 不安ドリブンは集中できない。
- 求められる結果(完成したプログラム)のことをあえて一旦忘れ、プログラミング自身を楽しむ。
- フロー状態に入りやすくなり、結果につながる。
技術に感動する習慣を持つ
- プログラムを始めた頃は、動いたことに感動していた。
- 経験を減るとだんだん感動が薄れてくるが、感動によって創造的になれる。
- 感動→好奇心→探究心→創造に繋がる。
記憶にもつながる。
ジェフ・ベゾスも、好奇心や冒険心が新しい物に繋がると言っている。
価値を作り出すプロセスを学ぶ
- 想像は『思考』、『行動』、『行為』の3つのプロセスから成る。
- この時の入力は入力は『視点』。だが、人は自分の視点をなかなか変えられない。
価値創造プロセスを学ぶと変えられる。
よく、『走りながら考える』と言われるが、走りながら考えると間違った方向にスタートし、たいていの場合は力尽きて失敗する。1
- 運が良ければ辿りつけるが‥。
価値創造にはいくつかの定型的なプロセスがあったりする。例えば以下。
- 匠メソッド
- リーンスタートアップ
- U理論
エンジニアが何に取り組めばよいか
儲かりそうだ、という理由で手を出すことはNGパターン。
- 外発的動機なので長続きしない
自分(強み、興味、経験)×社会(機会)=取り組むべきこと。
- 自分の中にある経験、強み、興味と、時代の流れやニーズが合致した箇所。
- 自分の中から出てきた動機なので長続きする。
創造的なチーム
- ドラッガーの言葉のように、専門知識を単独でなく結合させる必要がある。
- エンジニアの専門知識を組み合わせなければならない。
メンバー同士の協働姿勢が求められる。
よりよいアイデアを生むための思考
『Team Geek』では、HRTがチームコラボレーションの基盤として必要だと述べている。
- H(Humility) 謙虚
- R(Respect) 尊敬
- T(Trust) 信頼
チームが価値を生むためのリーダーシップ
- これからのリーダーシップは、リーダーがビジョンを全部描くとは限らない。
- 2つの形態があると考えている。
- 空白のキャンバスのリーダーシップ
- リーダーがみんなの意見を聞いてキャンバスを書いていく。
- コレクティブリーダーシップ
- 全員がリーダー。
- 一人ひとりがリーダシップを持って主体的に取り組む。
- 全員のリーダーシップを集約して価値化する。
- 空白のキャンバスのリーダーシップ
組織とエンジニア
- OSSのコントリビュータのように仕事をしよう。
- 契約で決められた仕事をするのではなく、
- 自分の強み、興味を活かして探し、貢献する。
- 役割に対して報酬を支払う。
- 役職ではない、という点が重要。
- 会社とエンジニアのシナジーで価値を生み出す。
- エンジニアと会社は対等。
- エンジニアは創造性を持つ。
- 会社は価値を生み出すインフラとなる。
- 自発的に参加したくなるような運営が必要。
- エンジニアと会社は対等。
まとめ
- これからの時代の会社=エンジニアコミュニティのような会社。
- 現実世界に価値を向けてハックしよう。そのために必要な経営はコミュニティ経営。
-
実現したい価値を最初に認識していない時のことを指しています。↩