(cache) PyCon JP 2015 keynote

No notes for slide

それでは基調講演を始めさせていただきます。
今年の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の可能性の１つなのではないかと私は考えています。
また、そのコミュニティのあり方が、これからの会社の大きなヒントになるとおもいます。

最後のメッセージですが、技術に感動しようということをあらためてお伝えして最後としたいと思います。
このあと、技術セッションがあるかとおもいますが、セッションを聞きながら、いつもより意識して技術に感動してみるのはいかがでしょうか。そうすれば、創造的なエンジニアに皆さんもまた近づいていくと思います。

ご清聴ありがとうございました。

PyCon JP 2015 keynote

Haruo Sato

PyCon JP 2015 keynote

A particular slide catching your eye?