Advertisement
PyCon JP 2015 keynote
Oct. 11, 2015•0 likes•18,230 views
20 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Engineering
2015年10月11日のPyConJP 2015のkeynoteです
Haruo SatoFollow
代表取締役社長 at BePROUD Inc.Advertisement
PyCon JP 2015 keynote
- Possibilities of Python 〜エンジニア・コミュニティ で組織は動き出す 株式会社ビープラウド 佐藤治夫 PyCon JP 2015 Keynote 2015/10/11
- Question Do you like Python ?
- 自己紹介 • 佐藤治夫（Sato Haruo） • Be Proud Inc. CEO 2006年5月設立 • Webの受託開発がメイン事業 • connpass 企画・開発・運営 • Pythonでの開発実績：70 プロジェクト以上 （2008/4〜） • Python Professional Programming 第1版 2012年3月、第2版 2015年2月 上梓
- PyConJP(APAC) と私 ＜個人＞ 2011年「Pythonで働くということ」 パネルディスカッション登壇 2012年 一般枠参加 2013年 - 2015年 Patron枠 で参加
- PyCon JP 2014 ©PyCon
- Theme 未来の会社（Future Compamy) 1.組織(Organization) 2. エンジニア(Engineer) 3.組織とエンジニア(Organization and Engineer) Pythonを会社のメイン言語に採用（2008年4月） ↓ 会社が大きく変化 ↓ 変化の中で見えて来たもの エンジニアが活躍する未来の会社はどうあるべきか
- そもそも私が会社をつくった理由 2006年当時 ・当時の私 = プログラマ / フリーランス ・世の中 ・企画/営業の人が組織で上 ・エンジニアの給料は低かった エンジニアが活躍し、幸せになれる会社 はどのような会社であろうか？ ↓ 「これからの時代の会社」を自分がつくろう
- Pythonの採用 2006年5月〜2008年3月 主に Java、perlで開発 ↓ 2008年3月、会社のメイン言語をPythonに決定 ・会社のメンバー4人（役員含む） ・Pythonによる開発実績は0件
- Pythonを採用した理由 「これからの時代の会社」を つくっていくエンジニアを採用したい ↓ Java、PHPのエンジニアは大手会社との争いになる → 資金量でかなわない ↓ Pythonは個人で使っている人は多いが、仕事で使っている 人は当時少なかった ↓ Pythonで仕事ができるようにすれば、大手会社と競争にな らず、良いエンジニアが来てくれるのではないか
- 目をつけたのは技術よりも人 ・仕事で使う機会が少ないのに自ら学ぶ技術への意欲 ・複数言語を知っていてバランス感覚が良い ・自ら技術を選択する主体性
- Pythonを採用した結果 2008年4月、Pythonを採用することをひっそりとTwitterで宣言 ↓ 2008年6月、Pythonコミュニティ(Python温泉)から１人目の エンジニアが紹介される ↓ 2008年 2人入社 ↓ 2009年 10人入社 … その後も次々と入社 リーマンショック後にも関わらず 開発案件が増加した
- Pythonの採用による会社方針の変化 選択と集中 PHP、Ruby、Javaなどの仕事は請けない方針 ↓ 信頼の輪を広げて行く パートナーとして任せてもらえる顧客との信頼づくり → 信頼される仕事をする → パートナーとして任せてもらえる顧客を紹介で広げて行く ※良い顧客は良い顧客とつながっている → 70件以上のPython開発実績につながっていった （営業マン0人）
- Pythonの採用により どのような人たちが集まってきたか？
- 変わったひとたち (Strange People) ひとことでいうと….
- 変わったひとたちが集まって来た 休みやプライベートの時間を使って Pythonの勉強をしたり、集まってプログラミングに いそしむ変わったひとたち… 愛すべき変わりもの（Geek、Nerd） 10月の3連休にプログラマ同士で集まって 「ウェーイ」とはしゃいでるひとたち…
- Q. 個性が強いエンジニアをどう束ねるの？ 度々、質問されること
- Answer 束ねない（制御不能のため） → 彼らの声に耳を傾け、 彼らが望むように経営にしよう ↑ 会社が変化していった
- 会社に起こった変化
- 会社の変化その1 Pythonを好きな人たちが集まった ↓ 会社自体がPython Communityになった Python PyCon FrameworkLibrary Tool BP
- 会社がPython Communityになった効果 ・同じことに共感し、感動できる → 最新の情報が集まりやすい ・ベースの価値観が一致している (影響)読みやすさ, シンプル , Zen of Python → 合意の形成、意思決定の迅速化 ・Document を積極的に書こうという人が多い (影響）Python標準ドキュメントの充実、Sphinx →暗黙値の共有化、形式知化の促進
- 集まったひとたち ・オープンソース を使い、恩恵をうけている ・オープンソース・コミュニティ に参加している ・オープンソースの Contributor として活動してい る ↓ 会社も自然とオープンソース・コミュニティ型の 会社運営に変わって行った 会社の変化その２
- 変化の中で見えてきたもの
- これからの時代の会社とは？ 工業社会 (Industrial society) 知識社会 (Knowledge society) エンジニア（Engineer） （Knowledge Worker） ？ 肉体労働者 （Blue Worker） エンジニア（ナレッジワーカー） が伸び伸びと創造性を発揮し 価値を創り出せる会社 模索中 ＜現代社会＞ (Modern society） エンジニア コミュニティ
- エンジニア・コミュニティ（Engineer Community) Software Document Connection of people etc… Python PyCon Framework Library Tool Meetup 価値 (Value) Engineer ↑ エンジニアが中心となり自発的に参加し、 さまざまな価値を生み出しているコミュニティのこと。 ここでは、主にオープンソースを中心としたコミュニティを指す 。
- ・組織（Organization) ・エンジニア(Engineer) ・組織とエンジニア(Organization and Engineer) 知識社会の会社（これからの時代の会社） = エンジニア（ナレッジワーカー）が伸び伸びと 創造性を発揮し価値を創り出せる会社 → エンジニア・コミュニティにヒントがある
- ・会社 = コミュニティである ・オープンソース・コミュニティ型運営から学ぼう 組織運営
- 同じことに共感し、感動することができる ↓ 暗黙値が共有され、組織内の学習や情報共有につながる ↓ 切磋琢磨の結果、会社が知識レベルがアップし、事業に活かせる ↓ ブランド化 会社 = コミュニティである → ジャンルは、事業に関係するものが効果的 ・雑談の積極的奨励 ・場作り（社内勉強会） コミュニティ = 同じことに興味をもった人たちの集まり
- 1983年 GNU Project 1990年代後半 Open Source Movement ↓ インターネットの発展 ↓ 多くのエンジニア がOpen Source Project に参加 ↓ Open Source Project の コミュニティ化 ↓ 組織運営・コミュニティ運営ノウハウを培う （エンジニア が創意工夫して培って来たノウハウ） → エンジニアが活躍する、知識社会の会社にも有用 組織 オープンソース・コミュニティ型運営から学ぼう
- ・フラットな組織(Flat Organization) ・コミュニティ評議会(Communtiy Council) ・コミュニケーション(Commnucation) 組織 オープンソース・コミュニティ型運営から学ぼう
- フラットな組織 階層型か、フラット型か？
- 階層型組織 ・組織を管理しやすい ・官僚制 → 管理のためのルールがつくられる ・情報が階層間で滞りやすい → 意思決定のスピードが落ちる ・どうしても出世に目が行く → 社内に目が向き、社外に対する意識が薄れがち メリット 管理しやすいので、うまく回れば、上のひとは楽 デメリット 内発的動機、自尊心、好奇心が失われ、創造性が失われる
- フラット型組織(Flat Organization) ・目的ごとにチームをつくり、役割を決める ・管理のためのルールは最低限 仕事をスムーズにするためのルール ・情報が行き渡りやすい ・出世を気にしなくて良い メリット 価値を創り出すことに集中できる デメリット 組織の管理が難しい
- フラットな組織への取り組み（役職無し） ・社長含む役員２人以外は役職無し ・名刺には好きな肩書きを記載 ←肩書き
- フラット型組織で大丈夫か？ ・セルフマネジメントと信頼関係を重視 ・管理する/管理されるの関係をつくらない 組織にかかるコストを削減できる ・管理するコスト ・管理されるコスト ・コミュニケーションコスト → 本来やるべき「価値を創り出す」ことに集中できる
- 会社の経営 = コミュニティの運営 経営者 = コミュニティ・リーダー（=役割） 経営者は偉い人ではない ↓ 権力ではなく役割である ↓ リーダーにとって重要なこと 権力ではなく、良い人格をもつこと
- ・フラットな組織(Flat Organization) ・コミュニティ評議会(Community Council) ・コミュニケーション(Communication) 組織 オープンソース・コミュニティ型運営から学ぼう
- コミュニティ評議会（Community Council ） ・コミュニティ全体を運営する役割を持つグループ ・課題がある場合に、評議会に提出される ・課題について評議会で議論し、方針を決定する 「Art of Community」 Jono Bacon 著 / 渋川よしき 訳 よ り
- 「BP カイゼン」プロジェクト ・会社を改善することを目的 ・月２回、１時間のミーティングを開催 ・社内誰でも参加できる ・redmineで課題管理。 課題がある場合、チケットを作成する ・議事録は全社員に公開、オープンなプロセスで決定 Be Proud の取り組み
- 「BP カイゼン」から生まれた制度 BPRD2.0 (BeProud Remote Day) ・週５日間、いつでもリモート勤務可能 ・制度を維持できるように、自分たちで制度を育てている （例） ・アンケートを取り、問題点を改善する ・Slackやbot などのツールを活用し、 皆が気持ちよく仕事ができるような仕掛けづくり
- コミュニティ評議会を会社に置くメリット ・自分たちで良い制度を提案し、育てていくことができる → 当事者意識、参加意識が生まれる ・決定プロセスがすべてオープンなので風通しがよい → 公正感が生まれる
- ・フラットな組織（Flat Organization) ・コミュニティ評議会(Community Council) ・コミュニケーション(Communication) 組織運営 オープンソースコミュニティ型運営から学ぼう
- オープンソース・コミュニティ のコミュニケーション手段 ・ML ・Issue Tracking System（ITS） ・チャット(Chat) ・ビデオ通話(Video Call) ・オフラインミーティング(Offline Meeting) 時間、リソース、場所などの制約が多い ・自然にさまざまな手段を使う ・隙間時間で、成果を出している
- Remote work for communication 導入しているコミュニケーションツール 時間、リソース、場所などの制約が多いのは会社も同じ ↓ リモートワークの体制づくりにより制約を超える ・時間 → 通勤時間の削減→時間を捻出する ・場所/リソース → 家庭事情などで会社に来れない人も仕事ができる etc….
- Q. リモートワークは チームでのクリエイティブな 仕事に向かないのでは？
- リモートワークでは段取りが重要 つくるプロセスアイデアを生み出すプロセス 必ずしも全ての時間、顔をあわせて仕事をする必要はない チームで一緒に仕事 個別に仕事 「アイデアを生み出すプロセス」と「つくるプロセス」 を区別する
- エンジニア・コミュニティ型組織運営 のまとめ 会社はコミュニティである ・共感による社内知識共有→会社がレベルアップ ・価値観の一致による意思決定の迅速化 オープンソース・コミュニティ型運営から学ぼう ・フラットな組織により価値・目的に集中できる ・オープンな運営による当事者意識、参加意識、公正感の醸成 ・コミュニケーション手段の効率化により、 時間、リソース、場所の制約を超える
- ・組織(Organization) ・エンジニア(Engineer) ← Next ・組織とエンジニア(Organization and Engineer) 知識社会の会社（未来の会社） = エンジニア（ナレッジワーカー）が伸び伸びと 創造性を発揮し価値を創り出せる会社 → エンジニア・コミュニティにヒントがある
- 創造的なエンジニアになろう Organization Contribution Engineer ＜創造的＞ Value idea 創造的なエンジニア = 主体的に価値を創り出そうとするエンジニアのこと
- Open Source Contributor Community 自発的に参加Engineer 価値に目を向け、アイデアを持っている ・どのようなソフトウェアが世界に役立つのか？ ・どのような機能が便利なのか？ Value ・社会にもたらされる価値に目を向けている ・アイデアを持っている ・自発的に参加している
- ・不安を乗り越え、主体的になる ・技術に感動する習慣をもつ ・価値を創り出すプロセスを学ぶ 創造的なエンジニアになる方法
- 創造的なエンジニアになる方法 ・不安を乗り越え、主体的になる ・技術に感動する習慣をもつ ・価値を創り出すプロセスを学ぶ
- 創造性を失わせる最大の敵 ・不安 “できなかったらどうしよう” ・恐怖 “できなかったらクビになる” 自分の外のことに怯え、主体性を失い、ディフェンシブな思考になる ↓ 創造性を失う
- 創造的なエンジニアになるために 不安を乗り越える方法 その1. 技術を身につける その2. 今を生きる
- その１：技術を身につける 技術を身につける ↓ 自信がつき、心が安定し、不安が少なくなる 創造的なエンジニアになるために 不安を乗り越える方法
- その２：今を生きる 完成した プログラム プログラミング 不安 恐怖 ＜欲しい結果＞ 不安・恐怖をもとに頑張る（外発的動機） ↓ 集中できず、結果がでない 「できなかったらどうしよう」 納期、品質、満足度 etc… 創造的なエンジニアになるために 不安を乗り越える方法
- 完成した プログラム 打ち込む/ 楽しむ 一旦忘れる （頭の片隅に置く程度にする） プログラミングそのものを楽しむ（内発的動機） ↓ 集中できて、結果につながる（フロー状態） プログラミング ＜欲しい結果＞ 創造的なエンジニアになるために 不安を乗り越える方法 その２：今を生きる
- ・不安を乗り越え、主体的になる ・技術に感動する習慣をもつ ・価値を創り出すプロセスを学ぶ 創造的なエンジニアになる方法
- 技術に感動する習慣をもつ （エンジニアを始めた当初） 「おー、動いた！」 「この技術は便利だ！」 ↓（経験を積んでくると） 「動いて当たり前」 「その技術は想定の範囲内。目新しくない」
- 感動すると創造的になれる 感動が少ない人は好奇心が薄れ、記憶も弱まる 。→ 結果、退化していく 感動 好奇心 探求心 創造 記憶 アイデア 「感動する脳」 茂木 健一郎 著 より 子供のような好奇心、あるいは冒険心があって初めて、 新しいものを生み出す力が生まれてくるのです。 ジェフ・ベゾス（amazon.com創業者）
- ・不安を乗り越え、主体的になる ・技術に感動する ・価値を創り出すプロセスを学ぶ 創造的なエンジニアになる方法
- 価値を創り出すプロセスを学ぶ ・要求開発 ・U理論 ・リーンスタートアップ etc… 価値を創り出すプロセス・考え方、イノベーション について体系的に学ぶ ↓ 創造的視点が生まれる ↓ アイデアが生まれる
- ・組織(Organization) ・エンジニア(Engineer) ・組織とエンジニア (Organization and Engineer) ← Next 知識社会の会社（未来の会社） = エンジニア（ナレッジワーカー）が伸び伸びと 創造性を発揮し価値を創り出せる会社 → エンジニア・コミュニティにヒントがある
- Open Source のContributorのように仕事をしよう 会社 貢献 自分の強み（興味）を活かして 役割を探し、貢献する 会社 仕事 労働 契約で決められたことをする 役割 役割 役割 役割
- 役割に対して報酬を支払う 会社 貢献 報酬 果たした役割 に対して報酬を支払う 重要：役職に対して支払うのではない
- シナジーで社会に価値を生み出す 会社 貢献 役割 役割 役割 役割 強み ・自発的に参加したくなる組織づくり ・組織の目的 ・組織運営 価値 創造エンジニア ＜創造的＞ アイデア ＜価値創造インフラ＞ Synergy
- まとめ 組織運営 ・会社=コミュニティである ・オープンソース・コミュニティ型運営から学ぼう エンジニア ・創造的なエンジニアになろう エンジニアと組織の関係 ・オープンソース・コントリビューターのように仕事をしよう ・エンジニアと会社はシナジーで価値を生み出す 知識社会の会社 =「エンジニア・コミュニティ」 → エンジニア（ナレッジワーカー）が活躍する会社
- Python PyCon Framework Library Tool Meetup Possibilities of Python Value 「Pythonが好き」という気持ちのもとに つながったPython Communityが生みだしていく価値 = Possibitities of Python Software Document Connection of people etc… →これからの会社のありかたのヒントに
- Thank you for listening! PyCon JP 2015 Keynote Last Message Possibility of Python 技術に感動しよう！ ご清聴ありがとうございました
Editor's Notes
- それでは基調講演を始めさせていただきます。 今年のPyConは、Possibilities of Python というテーマです。 株式会社ビープラウドの佐藤と申します。よろしくお願いします。
- まずは、1つみなさんに質問をさせてください。「Pythonが好きだ」という方は手をあげていただけますか。もしくは「Pythonは素晴らしいプログラミング言語だ」という方。 ありがとうございます。XX割くらいの方が手をあげてくださいました。 今日は、皆さんのようにPythonを好きな人たちが会社に集まって起きたこと、そのなかで私がきづいたことをお伝えできればと思います。
- 自己紹介です。名前は佐藤治夫といいます。 株式会社ビープラウドという会社の代表取締役社長です。メイン事業は、Webの受託開発で、そのほぼすべてのプロジェクトをPythonで開発しています。 現在、Pythonのエンジニアは35人ほど在籍しています。PyConで使っているconnpassもビープラウドで開発し、Pythonでつくられています。2008年にPythonを採用して以来、70以上のプロジェクトでPythonを使って開発してきました。 Pythonで開発して来たノウハウをまとめた書籍の「Python Professional Programming」を会社のメンバーで執筆し、2012年に出版しました。今年の２月には、半分ほど書き直した改訂第２版を出版しました。 この書籍の出版前のレビューに、Pythonコミュニティの多くの方々、２０名ほどに参加頂き、大変お世話になりました。 というように、ほぼPython一色でやっている、とても変わった会社です。
- PyConJPと私ということで、もうすこし自己紹介を続けます。 2011年の第１回のPyConJPで「Pythonで働くということ」テーマのパネルディスカッションに登壇させて頂きました。個人としては2012年に一般枠で参加し、2013年からはパトロン枠で参加しています。そして、今年は基調講演をやらせて頂くことになりました。このような大きな機会を頂き、大変感謝しております。本当にありがとうございます。
- これは昨年のPyConJP 2014年の２日目最後の写真です。 私も赤い矢印の場所、前から４列目に映っています。
- 本日お話しする内容の全体像を先にお伝えします。Pythonを開発のメイン言語に採用したのは、2008年4月でした。その後、Pythonの採用をきっかけに会社は大きく変化して行きました。その変化の中で見えて来た、エンジニアが活躍するこれからの時代の会社、未来の会社はどのようなものになるかということでした。 これについて組織運営、エンジニアのありかた、そして、組織とエンジニアの関係という３つの観点からお話しします。 私はエンジニアであり、かつ経営者ですが、その立場から本日はお話しし、皆さんの今後にお役に立てることが１つでもあればとおもいます。
- まず、そもそも、なぜ、私が会社をつくったのかという理由について最初にお話しします。会社をつくる前は、私はフリーランスのプログラマでした。 私がその頃に感じていたことですが、一般的な会社では企画や営業の人がエンジニアより立場が上という感じだったと思います。エンジニアの給料も低かったとおもいます。そのような状況で、私は「エンジニアが活躍し、幸せになれる会社はどのような会社なのだろうか」ということをいつも考えていました。そして、そのような会社が無いなら、自分でこれからの時代の会社をつくろうと決心したのがきっかけです。
- 2006年の5月に会社を立ち上げ、2008年の3月までの約２年間はJavaやperlで開発していました。そこを2008年4月に会社のメイン言語をPythonにすることに決めて、社内で発表しました。その当時、社員は私を含めて４人。Pythonでの開発実績は0件でした。
- 次に、私がPythonを採用した理由です。たしかにPythonの開発生産性の高さ、保守性の高さなどの技術的メリットというのも選択理由としてはありました。しかし、本当の理由は、これからの時代の会社をつくっていくためのエンジニアを採用したいということでした。JavaやPHPのエンジニアを採用しようとすると、どうしても大手会社との争いになります。そうなると採用のための資金量ではかないません。一方、Pythonは個人で使っている人は多い印象でしたが、仕事で使っている人は少ないという印象を私は持っていました。そこで、会社でPythonを言語として使うようにすれば、大手の会社と競争にならずに、良いエンジニアが来てくれるのではないかと考えました。
- 私は、Pythonをやっている人には、３つの特徴があると考えていました。 １つ目は、仕事で使う機会が少ないのにも関わらず、自ら学ぶ技術への意欲。２つ目は、複数言語を知っていてバランス感覚が良い。 ３つ目は、自ら技術を選択する主体性があるということです。つまり、これらの特徴をもっているpythonistaという人に目をつけた、ということになります。
- Pythonを採用した結果どうなったか。まず、2008年4月にPythonを採用することをTwitterでひっそりと宣言しました。４人程度の小さな会社なので、特に何もないだろうと思ってたのですが、２か月後に、Python温泉というコミュニティから、エンジニアが１人紹介されました。彼は今でもうちの会社で仕事をしています。その後も、2008年には2人、翌年には10人と次々と、Python界隈のエンジニアが入社することになりました。
- Pythonを採用したことによって会社の方針も大きく変わりました。Pythonで開発するということに決めましたので、PHPやRuby、Javaなどの仕事は、話が来ても請けないということになりました。当時の日本では、Pythonでシステムを開発するということは、珍しいことでしたので会社としては仕事が減るというリスクをとったことになります。 そこで、どうしたかというと顧客との信頼づくりということを強く意識して始めました。信頼してくれて、仕事のやりかたは任せると言ってくれる顧客との関係をつくっていくということです。そして、その信頼してくれるお客さんにさらにお客さんを紹介してもらうというかたちで輪を広げて行きました。良いお客さんは良いお客さんとつながっていますので、紹介してもらうお客さんも、任せてくれるお客さんが多かったように思います。そのようにして仕事を増やして行き、現在の70件以上のPythonによる開発実績につながっていきました。
- Pythonを採用したことにより、どのようなひとたちが集まって来たのでしょうか。
- ひとことでいうと「変わった人たち」です。私が期待していた通り、変わった人たちが集まってきました。
- どれくらい変わっているか？というと、休みやプライベートの時間を使って、家族を説得してまで、Pythonの勉強をしたり、ハッカソンで集まってプログラミングをしているような人たちです。 例えば、日本でも１番季節が良く過ごしやすい10月の3連休に、エンジニア同士で集まって「うぇーい」と、はしゃいでるようなひとたちです。おわかりのように、今日ここに集まってる皆さんのような方たちです。
- 私がたびたび、質問されることがあります。 個性が強いエンジニアをどのように束ねるのか？ということです。
- 私の答えは「束ねない」です。それはなぜかというと、私には束ねることができないからです。 束ねることができないので、彼らが望むような会社はどのような会社なのだろうということに目線が変わって行きました。そうすると、次第に会社が変化して行くのがわかりました。
- Pythonを採用したことにより、会社に起こった変化について２点お話しします。
- 会社におこった変化の１つ目です。Pythonを採用したことにより、Pythonを好きな人たちが集まりました。必然的にPythonのコミュニティに会社が変わっていったわけです。
- 会社がPythonコミュニティになったおかげで、いろいろな効果が会社に生まれました。ここでは３つあげました。 １つ目は、同じことに共感し、感動できるということ。Pythonという同じことに興味をもっていますので、例えば、何かのソフトウェアがリリースされたとか良いツールがあるという話を、誰かが始めた時に、周りの人もそれに対して「おーすごい」とか、一緒に共感するようになります。これが、Pythonを使わない人が、Pythonの話を聞いても「へぇ」くらいの反応で、共感したりすることが少ないと思います。そのように、興味が同じ人が集まると、自分が知った新しい情報を共有しあうので、社内に情報が集まるようになります。 ２つ目が、ベースの価値観が一致しているということです。Pythonには、コードの読みやすさ、わかりやすさを重視するような価値観、シンプルさの追求やzen of python という思想があります。その思想はプログラミングに限らず仕事に通じる価値観があります。それらの価値観が一致していることで、合意の形成や意思決定が速くなったとおもいます。 ３つ目が、ドキュメントを積極的に書こうという人が多いということです。これは、Pythonは標準ドキュメントが充実していたり、Sphinxという素晴らしいツールがあったりするので、その恩恵を受けている人が多く、ドキュメントを書こうという意志のある人が、pythonistaには多いのかなと想像しています。ドキュメントを積極的に書こうという人が多いので、社内では、暗黙知の共有化、そして暗黙知の形式知化が促進されたとおもいます。
- 会社に起こった変化の２つ目です。それは、会社の運営がオープンソース・コミュニティ型に変わって行ったということです。集まって来た多くのエンジニアは、オープンソースを使って恩恵を受けていたり、コミュニティに参加していたり、自分がコントリビューターとして活動していたりして、日頃からなんらかのかたちでオープンソースに関わっている人たちでした。したがって、オープンソース・コミュニティで行われている組織運営方法が、自然に会社に採用されたのかと思います。詳しい内容は、のちほど説明致します。
- 私が経営者として、Pythonを採用し、会社が変化して行く中で、見えて来たものがありました。
- 冒頭で申し上げたことですが、私が会社をつくった理由は「これからの時代の会社をつくりたい」ということでした。工業が中心の工業社会では、階層型、上意下達の組織形態で、働き手はブルーワーカーと呼ばれるひとたちです。ピーター・ドラッカーのいう、知識社会では、エンジニアなどのナレッジーワーカーが主な働き手となります。皆さんのようなエンジニア、ナレッジワーカーがのびのびと創造性を発揮し、価値を創り出すためには、工業社会の焼き直しのような組織ではなく、知識社会のための組織が必要になります。現時点ではその過渡期であり、知識社会の組織が、どのような組織であるべきかを模索している段階なのではないでしょうか。Pythonを採用し、会社が変化して行く中で私に見えて来たものは、知識社会の会社、これからの時代の会社、未来の会社は、エンジニア・コミュニティのような会社になるだろうというものです。
- エンジニア・コミュニティとは、オープンソースのコミュニティであったり、今回のPyConや、さまざまなMeetup などのようにエンジニアが中心となって活動しているオープンなコミュニティをイメージして頂ければと思います。 みなさんご存知のように、ソフトウェアや、ドキュメント、人のつながりなど、さまざまな価値を生み出しているコミュニティです。
- 知識社会の会社、未来の会社がどうあるべきかということについて、エンジニアコミュニティのような組織になるだろうとお伝えしました。 これについて、組織運営、エンジニアのありかた、組織とエンジニアの関係のありかたという３つの観点からお話ししたいと思います。
- 組織運営については、２つお話しします。 １つ目は、会社はコミュニティであるということ。 ２つ目は、オープンソース・コミュニティ型運営から学ぼう ということをお話しします。
- コミュニティとは、同じことに興味をもった人たちの集まりです。 同じことに興味をもっているので、同じことに共感し、感動することができます。そのような日頃の会話の中から個人が持っている暗黙知が共有されやすくなり、組織内の学習や情報共有につながります。そのような切磋琢磨の結果、会社の知識レベルはあがり、その知識を事業に活かせるようになります。それがひいては会社のブランド化にもつながっていくこともあります。ここはポイントなのですが、コミュニティの興味の対象、ジャンルは、なんでも良いわけではなくて、会社の事業に関係するものがよいとおもいます。たとえば、会社のみんながラーメンが大好きだとします。毎日毎日、仕事中にラーメンについて活発に議論したからといって、会社の直接の成果には、つながりにくいとおもいます。うちの会社の場合は、Pythonを好きな人たちが集まったおかげで、書籍出版にもつながり、さらにはその書籍出版が会社のブランドにまでつながっていきました。そのようなコミュニティを活発化するために、会社として重要なのは、仕事中の雑談の積極的な奨励と、社内勉強会など、場作りだと思います。それによって、社員同士の知識や情報が自然と共有されていくことになります。私の会社の場合は、オンライン上での雑談がとても活発です。
- 組織運営の２つ目は「オープンソース・コミュニティから学ぼう」ということについてお話しします。1983年にリチャード・ストールマンがGNU(グニュー)プロジェクトを始めて、フリーソフトウェアの重要性を訴え、多くの人の支持を受けました。その後、1990年代にオープンソースのムーブメントが起こります。そして、インターネットの発展とともに、世界の多くの人がオープンソースプロジェクトに参加するようになりました。それにつれて、オープンソースプロジェクトもコミュニティとなり、組織運営、コミュニティ運営というものが必要になりました。オープンソースプロジェクトの参加者は、ほとんどがボランティアで隙間時間に成果を創り出していますので、その運営には効率性が求められます。また、オープンソースというくらいですから、オープンな運営、風通しの良さが求められます。こうして、経営者や経営学者ではなく、エンジニアたちが創意工夫して培って来たオープンソース・コミュニティの運営ノウハウが、エンジニアが活躍するこれからの会社、知識社会の会社にも有用であるというのが私の考えです。
- オープンソースから学ぼうということで、具体的には、フラットな組織、コミュニティ評議会、コミュニケーションという３点についてお話しします。
- まずは、フラットな組織ということについてお話しします。 ここでは、単純に、階層型か、フラット型か、の２形態に絞ってお話しします。
- まずは階層型組織についてお話しします。まず、階層型の特徴として、組織を管理しやすいということがあげられます。 ２つ目は官僚制。官僚制では、管理のためのルールが組織内につくられていきます。３つ目が、情報が階層間で滞りやすいというものです。情報が滞りますので、意思決定のスピードがどうしても落ちるということが特徴としてあげられます。４つ目が、どうしても出世に目が行くということです。階層型組織では、たいていの場合、組織の階層をあがっていけば、昇進で給料があがります。社内での昇進を考えるとどうしても社内に目が向いてしまい、社外にどのような価値をもたらすのかという意識がおろそかになりがちです。 階層型のメリットは、管理しやすいので、うまく回れば、組織の上の人は楽ということです。 デメリットは、管理されたり、社内に目が向いているうちに、創造性の源である、個人の内発的動機、自尊心、好奇心が失われ、個人の創造性がなくなってしまう恐れがあるということです。
- 次に、フラット型組織の特徴についてお話しします。 フラット型組織は、オープンソースのコミュニティのような組織をイメージしてください。オープンソースのコミュニティで、階層型組織というのは考えられないとおもいます。フラット型組織では、プロジェクトなど、なにか目的が生まれたらそのたびにチームをつくり、都度メンバーが果たすべき役割を決めて行きます。そして、管理のためのルールは最低限。ここでつくられるルールも仕事をスムーズに進めるためのルールです。また、階層とセクションがありませんので、情報が行き渡りやすいという特徴もあります。また、組織の階層を昇って行く必要がありませんので、出世も気にする必要はありません。これらのようにフラット型組織をつくることで、エンジニアは余計なことを考えず、のびのびと考えられるようになります。それにより、エンジニアが価値を創り出すことに集中できるようになるのではないかとおもいます。デメリットとしては、組織の管理が難しいということです。
- これは、うちの社員の名刺ですが、肩書きには「Warlock」と書かれています。 「魔法使い」という意味です。このように私の会社では、役職がありません。 名刺には好きな肩書きをのせることができます。
- さきほど、フラット型組織のデメリットとして、管理が難しいという話をしました。 フラット型組織は、管理が無いので大丈夫なのか？組織が崩壊するのではという疑問をもたれた方もいらっしゃるかもしれません。 フラット型組織で、大事なのは、個人個人のセルフマネジメントと、お互いの信頼関係です。個人が自律的に動くということです。また、誰かが誰かを管理するという関係性をつくらないようにすることも重要となってきます。 それにより、組織にかかる様々なコストを削減できます。様々なコストとは管理するコスト、管理されるコスト、コミュニケーションコストなどです。そのコストを本来やるべき、「価値を創り出す」ということにより使うことができるのです。
- 会社の経営は、コミュニティの運営であると定義すると経営者はコミュニティのリーダーということなります。 オープンソースのコミュニティで、リーダーが偉いということはないとおもいます。 それはただの役割でしかありません。つまり、経営者も偉いひとではないということです。経営者は権力ではなく、役割であるということです。 組織のリーダーにとって重要なこと。それは権力ではなく、リーダーという役割を果たせるだけの良い人格をもつということだと私は思っています。
- 次に、コミュニティ評議会ということをお話しします。
- コミュニティ評議会とは、「アートオブコミュニティ」という書籍に書かれている概念です。 コミュニティ評議会とは、コミュニティ全体を運営する役割を持つグループです。 課題がある場合に、その課題は、評議会に提出され、提出された課題について評議会で議論し、方針を決定します。
- 私の会社では、このコミュニティ評議会に該当するものを運営しています。それは、「BP（ビーピー）カイゼン」という取り組みです。この取り組みの目的は会社を改善することです。どのように運営しているかというと、月２回、１時間のミーティングを開催し、社内誰でも参加できます。redmineで会社の課題を管理し、課題がある場合はチケットを作成します。 議事録は全社員に公開し、すべてオープンなプロセスで課題の解決方法が決定されていきます。
- 「BP（ビーピー）カイゼン」から生まれた制度について１つ紹介します。 それはBPRD2.0、BeProud Remote Dayという制度です。どのような制度かというと、週５日間、つまり全ての日に関していつでもリモートで勤務可能というものです。名前に2.0とついているのは、もともと週１日はリモートで勤務可能というものが、さらに拡大されたからです。この制度は、BPカイゼンで、社員からアイデアが出され、実現しました。自分たちでつくった制度なので、アンケートをとったり、ツールをつくったりして制度をうまく運用できるように、みんなで工夫をしています。
- コミュニティ評議会を置くメリットですが、私は２点あると考えています。 １つ目は、自分たちで制度を提案して、自分たちで育てて行くことができるということです。これによって、会社を自分たちでよくしていこうという当事者意識や参加意識が生まれてくるという効果があります。２つ目は、決定プロセスがすべてオープンなので、風通しがよいということです。これによって、会社全体に公正感が生まれてくるという効果が期待できます。
- ３点目は、コミュニケーションです。
- オープンソース・コミュニティのコミュニケーション手段は、メーリングリスト、ITS、チャット、ビデオ通話、時には直接のミーティングなどが使われているとおもいます。 これは、オープンソース・コミュニティは、時間やリソース、場所などの制約が多いため、 自然にさまざまな手段を使って、隙間時間で、成果を出すための工夫です。
- コミュニケーションについての弊社での取り組みを紹介します。 時間やリソース、場所などの制約が多いのは会社も同じです。これらが充分にあるという企業はほとんどなさそうです。そこで弊社では、リモートワークの体制作りによって、時間、リソース、場所の制約を超えようとする取り組みをしています。時間については、リモートワークにより通勤時間の削減が期待できます。 場所とリソースについては、リモートワークによって、家庭事情などで会社に来れない人も仕事ができるようになります。 例えば奥さんが出産するという場合に、地方の奥さんの実家に一緒に戻り、そこから仕事をするというような場合です。 そのために、SlackやGoogle hangout、Google Drive、DropBox、redmineなどさまざまなツールを活用してリモートワークを推進しています。
- リモートワークの話をすると出てくる疑問が、リモートワークはチームでのクリエイティブな仕事に向かないのではないか？ということです
- その疑問に対する私の考えをお伝えします。 何かを創り出すときにはアイデアを生み出すプロセスと、実際につくるプロセスがあります。 そのアイデアを生み出すプロセスと、つくるプロセスをしっかりと分けるように段取りをすれば、必ずしも全ての時間を同じ場所で顔を合わせて仕事をする必要がないというのが私の考えです。このプロセスを意識し、仕事の段取りをしっかりすれば、リモートワークでもクリエイティブなチームの仕事は可能ということです。
- エンジニア・コミュニティ型組織運営のメリットについて、ここでまとめておきたいと思います。会社はコミュニティであるというお話をしました。会社がコミュニティであることの効果として、共感による社内知識共有。その結果、会社の知識レベルがアップし、事業につながるということが考えられます。私の会社の場合は、書籍出版にまでつながりました。 また、価値観の一致により、意思決定が迅速になるということがあげられます。 オープンソース・コミュニティ型運営に学ぼうという点では、３つのメリットをあげました。フラットな組織により価値や目的に集中できる。オープンな運営による当事者意識、参加意識、公正感の醸成。コミュニケーション手段の効率化により、時間、リソース、場所の制約を超えることができるということです。
- 「知識社会の会社、未来の会社とは」ということで、組織の次は、エンジニアのありかたというお話をしたいとおもいます。
- エンジニアのありかたについての私のメッセージは、「創造的なエンジニアになろう」ということです。 みなさんは、Pythonという素晴らしいプログラミング言語や、サードパーティー製のの充実したライブラリをつかって、さまざまなソフトウェアをつくりだすことができます。 従って、みなさんが価値あるものを創り出せるかどうかは、みなさんがいかに創造的になれるかどうかということにかかっていると私は思います。 創造的なエンジニアとは、自ら主体的になって価値を創り出そうとするエンジニアのことです。
- オープンソースのContributorをイメージしてみると、３つ特徴が思い浮かびます。 １点目が社会にもたらす価値に目を向けている。どのようなソフトウェアが世界に役立ち、使われるのかを常に考えているということです。 ２点目は、自らがつくるソフトウェアに対してのアイデアをもっているということです。３点目がコミュニティの活動に自発的に参加しているということです。このようにオープンソースのContributorは、主体的に価値を創り出そうとしている、創造的なエンジニアであるということが言えるのではないでしょうか。
- では、創造的なエンジニアになるにはどのようにしたら良いかというお話をします。 ここでは、創造的になるための、３つの方法を紹介したいと思います。 それは、不安を乗り越え、主体的になる、技術に感動する習慣をもつ、価値を創り出すプロセスを学ぶの３つです。
- １つ目は「不安を乗り越え、主体的になる」です。
- 創造的になる最大の敵はなんでしょうか。それは不安と恐怖です。 仕事における不安、恐怖とは”できなかったらどうしよう”、”できなかったらクビになる”という自らの感情です。不安や恐怖に怯えてしまうと、自分の外からの刺激に反応することに意識が向いてしまうので、主体性を失ってディフェンシブな思考になってしまいます。そうなると人は、創造性を失ってしまいます。
- では、不安を乗り越えるにはどうしたらよいでしょうか。 そのための方法として、２つお話しします。 １つ目は、「技術を身につける」、２つ目は、「今を生きる」ということです。
- 不安を乗り越える方法の１つ目は「技術を身につける」です。 不安が生まれる原因の１つに「自信がない」ということが上げられます。なぜ、自信がないかというと、技術がないからというのが一番大きな原因ではないでしょうか。逆にいうと、技術を身につけると、自信がつき、次第に心が安定し、強くなっていくということが考えられます。 このように考えると、創造的なエンジニアになるには、自分に自信がつくまで、技術を徹底的に身につけるというのが重要ではないでしょうか。
- しかし、技術を身につけるといっても技術はすぐに身に付かないです。そのため、すぐにできる方法をお話しします。それは「今を生きる」ということです。開発プロジェクトでは、納期や品質などさまざまなものが求められます。そのため、エンジニアには「できなかったらどうしよう」という不安や恐怖が生まれてきます。その不安や恐怖にかられて仕事をしていると、集中して仕事ができずに、結果的に成果がでないということになりがちです。
- そのようなことにならないためには、求められる結果に、まず付箋紙を貼ってしまいます。一旦忘れてしまって頭の片隅に置く程度にしてしまいます。そしてプログラミングという行為そのものに打ち込む、楽しむということに専念します。 プログラミングが楽しいという気持ちで仕事をすると、集中できるようになります。 集中してものごとに取り組むと、結果的に成果につながります。 このように集中して取り組んでいる状態をフロー状態と言って、心理学では、人が仕事をする上では、理想的な状態と言われています。
- 創造的なエンジニアになる方法の２つ目として、「技術に感動する習慣をもつ」ということをお話します。
- プログラミングを始めた当初は、自分がつくったプログラムが動くと「おー、動いた！」とか、何かの技術やライブラリ、ツールを使った時に「この技術は便利だ！」と感動していたとおもいます。それが、だんだん経験を積んでくると、「動いて当たり前」「その技術は想定の範囲内、目新しくない」というように考えてしまいます。
- 何かに感動すると、その感動した対象に対して、人は好奇心が湧いてきます。好奇心がわくと、その対象についてもっと知りたいという探究心が生まれてきます。その探究心が新しいものを創り出すことにつながります。 感動は、その感動した対象への記憶を強くするという効果もあります。記憶は記憶同士が結びついて、アイデアとなるので、それが創造につながります。 何が言いたいかというと、感動する習慣をもつと、創造的なエンジニアになれるということです。逆に考えると、感動が少ない人は、好奇心も薄れて、記憶力も弱まるので創造性を失い、エンジニアとして退化していくことになります。 「子供のような好奇心、あるいは冒険心があって初めて、新しいものを生み出す力が生まれてくるのです。」これは、amazon創業者のジェフベゾスの言葉です。
- 創造的なエンジニアになる方法の３つ目として「価値を創り出すプロセスを学ぶ」ということをお話したいと思います。
- 価値を創り出すプロセスや考え方、イノベーションについて体系的に学ぶと、何かを創り出す創造的な視点が自分の中に生まれます。視点が生まれると、それは思考につながりますので、創造的な思考が、創造的なアイデアに結びついていきます。価値を創り出すプロセスや考え方の具体的なものとしては、要求開発、U理論(Theory U)、リーンスタートアップなどさまざまなものがありますが、自分にあったものを見つけるのが良いのではないでしょうか。私は要求開発というものに取り組んでいます。
- 「知識社会、未来の会社とは」ということで、組織、エンジニアとお話ししましたので、次は、組織とエンジニアの関係についてお話しします。
- 組織とエンジニアの関係についての私のメッセージは、「オープンソースのContributorのように仕事をしよう」ということです。通常、会社とエンジニアのあいだでは雇用契約が結ばれていて、仕事もあらかじめ契約で定められていることもしばしばあります。しかし、そのような関係を重視しすぎると、契約で決められたことだけをやるということになり、創造的なものを生み出す仕事はできなくなってしまいます。その一方で、オープンソースのContributorは、コミュニティの中で、自分の強みや興味を活かして、自分が貢献できることをみつけて仕事をするということをしています。 オープンソース・コミュニティと同じように、会社という組織でも、さまざまな役割があります。会社においても、オープンソースのContributorのように、エンジニアが自分の強みや興味をもとに、社内で果たせる役割をみつけて、貢献するという仕事のスタイルが良いのではないかというのが私の考えです。貢献という言葉がキーワードになります。それにより、やらされる仕事から、自分で貢献できる仕事を主体的に見つけて行くというスタンスに変わっていきます。
- そのような会社とエンジニアの関係のときに、報酬は何に対して支払うべきかということをお話しします。私の答えは、果たしてくれた役割に対して、報酬を支払うということです。そうすれば、エンジニアは自分が果たせる役割は何かという視点を持つようになり、主体的に貢献するようになります。会社でよくある報酬の支払いとして、役職に対して報酬を支払うということがありますが、これですと、仕事をせず、偉いだけの人に多くのお金を支払うことになり、不公平となります。組織を活性化させるためのポイントは、役割に対して報酬を支払うということです。
- 組織とエンジニアの関係について、もう１点お話しします。 それは、エンジニアと組織はお互いに協力して、シナジーを生み出す関係であるということです。 エンジニアは自分の強みと興味で組織に貢献する。会社は、エンジニアが自発的に参加したくなるような組織作りをする。会社は、価値を創造するためのインフラになることです。そのようにお互いが創造的でシナジーを生み出せる関係になることがポイントであると私は思っています。
- 最後に全体のまとめです。2008年に会社のメイン言語にPythonを採用し、Pythonistaが集まってきました。会社が変化して行く中で、私が気づいたことがありました。それは、エンジニアのような、ナレッジワーカーが活躍する知識社会、未来の会社は、エンジニア・コミュニティのようなものになるということです。つまり、オープンソース・コミュニティの運営・ありかたに、これからの時代の会社、エンジニアのようなナレッジワーカー活躍する会社が学ぶべきものがたくさんあるということです。これについて、組織運営、エンジニアのありかた、エンジニアと組織の関係という３つの観点から、お話しをしました。
- 今年のPyConのテーマ、Possibilties of Python ということに則しますと、Pythonが好きという気持ちのもとに、つながったPythonコミュニティが生み出して行く価値。それはソフトウェアやドキュメントだったり、人のつながりなど、さまざまなものになるとおもいます。そのような素晴らしい価値あるものを生み出していけるコミュニティが数多く存在すること、それがPythonの可能性の１つなのではないかと私は考えています。 また、そのコミュニティのあり方が、これからの会社の大きなヒントになるとおもいます。
- 最後のメッセージですが、技術に感動しようということをあらためてお伝えして最後としたいと思います。 このあと、技術セッションがあるかとおもいますが、セッションを聞きながら、いつもより意識して技術に感動してみるのはいかがでしょうか。そうすれば、創造的なエンジニアに皆さんもまた近づいていくと思います。 ご清聴ありがとうございました。
Advertisement