エンジニアコミュニティで組織は動き出す
•Download as PPTX, PDF•
32 likes•14,971 views
2/18のDeveloper Summit 2016 の資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to エンジニアコミュニティで組織は動き出す
Similar to エンジニアコミュニティで組織は動き出す (20)
More from Haruo Sato
More from Haruo Sato (18)
Recently uploaded
エンジニアコミュニティで組織は動き出す
- 2. なぜ、野球ユニフォーム？
- 3. IT勉強会 発表時ユニフォーム正装化へ ©PyCon JP 2015
- 5. 自己紹介 • 佐藤治夫（Sato Haruo） • Twitter: @haru860 • 株式会社ビープラウド 代表取締役社長 • エンジニア19年目（うち経営者10年目） ビープラウド 20162006200320001997 個人 事業主 小規模 SIer 東証1部上場 大手SIer 技術記事執筆 Codezine、DB Magazine、@IT、JavaPress、ThinkIT
- 6. 株式会社ビープラウドについて • Pythonをメイン言語で用いて開発 • Webの受託開発がメイン事業 （エンジニア40人体制） • connpass 企画・開発・運営 • Python Professional Programming 第1版 2012年3月、第2版 2015年2月 上梓 →増刷されて売れてます • Web系勉強会：BPStudy101回連続開催中（2007年9月〜）
- 8. 私が会社をつくった当時のエンジニア 2006年当時 ・当時の私 = プログラマ / フリーランス ・世の中 ・企画/営業の人が組織で上 ・エンジニアの給料は低かった
- 10. Pythonの採用
- 19. 会社に起こった変化
- 21. 会社がPythonコミュニティになった効果 ・同じことに共感し、感動できる → 最新の情報が集まりやすい ・ベースの価値観が一致している (影響)読みやすさ, シンプル , Zen of Python → 合意の形成、意思決定の迅速化 ・ドキュメントを積極的に書こうという人が多い (影響）Python標準ドキュメントの充実、Sphinx →暗黙値の共有化、形式知化の促進
- 23. 会社の変化の中で 見えてきたもの
- 27. 1. 会社 = コミュニティである 2. オープンソース・コミュニティ型運営から学ぼう ・フラットな組織 ・コミュニティ評議会 ・コミュニケーション 組織
- 28. 同じことに共感し、感動することができる ↓ 暗黙値が共有され、組織内の学習や情報共有につながる ↓ 切磋琢磨の結果、知識レベルがアップし、事業に活かせる ↓ ブランド化 会社 = コミュニティである 組織に大事なこと ・雑談の積極的奨励 ・場作り（社内勉強会） コミュニティ = 同じことに興味をもった人たちの集まり
- 29. 1990年代後半 オープンソースのムーブメント ↓ インターネットの発展 ↓ 多くのエンジニア がオープンソースプロジェクト に参加 ↓ オープンソースプロジェクト の コミュニティ化 ↓ 組織運営・コミュニティ運営ノウハウを培う （エンジニア が創意工夫して培って来たノウハウ） → エンジニアが活躍する、これからの会社にも有用 組織 オープンソース・コミュニティ型運営から学ぼう
- 32. 階層型組織 ・組織を管理しやすい。 ・官僚制 → 管理のためのルールがつくられる ・情報が階層間で滞りやすい → 意思決定のスピードが落ちる ・どうしても出世に目が行く → 社内に目が向き、社外に対する意識が薄れがち（大企業病） メリット 管理しやすいので、うまく回れば、上のひとは楽 デメリット 内発的動機、自尊心、好奇心が失われ、創造性が失われる
- 35. 会社の経営 = コミュニティの運営 経営者 = コミュニティ・リーダー（=役割） 経営者は偉い人ではない ↓ 権力ではなく役割である ↓ リーダーにとって重要なこと 権力ではなく、良い人格をもつこと
- 37. コミュニティ評議会（Community Council） ・コミュニティ全体を運営する役割を持つグループ ・課題がある場合に、評議会に提出される ・課題について評議会で議論し、方針を決定する 「Art of Community」 Jono Bacon 著 / 渋川よしき 訳 より
- 39. 「BP カイゼン」から生まれた制度 BPRD2.0 (BeProud Remote Day) ・週５日間、いつでもリモート勤務可能 ・制度を維持できるように、自分たちで制度を育てている （例） ・アンケートを取り、問題点を改善する ・Slackやbot などのツールを活用し、 皆が気持ちよく仕事ができるような仕掛けづくり
- 40. コミュニティ評議会を会社に置くメリット ・自分たちで良い制度を提案し、育てていくことができる → 当事者意識、参加意識が生まれる ・決定プロセスがすべてオープンなので風通しがよい → 公正感が生まれる
- 43. リモートワークによるコミュニケーション 導入しているコミュニケーションツール 時間、リソース、場所などの制約が多いのは会社も同じ ↓ リモートワークの体制づくりにより制約を超える ・時間 → 通勤時間の削減→時間を捻出する ・場所/リソース → 家庭事情などで会社に来れない人も仕事ができる etc….
- 46. ・組織 ・エンジニア ← Next ・組織とエンジニア これからの時代の会社 = エンジニア（知識労働者）が伸び伸びと 創造性を発揮し価値を創り出せる会社
- 47. 1. 創造的なエンジニアになる方法 2. 何に取り組めば良いか 3. 創造的なチーム エンジニア
- 59. 感動すると創造的になれる 感動が少ない人は好奇心が薄れ、記憶も弱まる 。→ 結果、退化していく 感動 好奇心 探求心 創造 記憶 アイデア 「感動する脳」 茂木 健一郎 著 より 子供のような好奇心、あるいは冒険心があって初めて、 新しいものを生み出す力が生まれてくるのです。 ジェフ・ベゾス（amazon.com創業者）
- 63. 要求開発（匠メソッド） 戦略 要求 業務 要求 IT 要求 システム 開発 <経営者の視点> <現場の視点> <ITの視点> <開発の視点> 価値 ビジネスモデ ル 要求ビジョン コンセプト
- 64. リーンスタートアップ アイデア 構築要求 提供 計測 フィード バック 学習 ・インタビュー ・ブログ反応 ・プロトタイプ 使用 MVP (Minimum Viable Product) MVPをなるべく早くユーザーに提供し、フ ィードバック・計測を繰り返しながら、よ り良い製品に近づいていく方法 リーンキャンバス ユーザー 開発者 リーンダイアグラム
- 66. 何に取り組めば良いか？
- 68. 経験 経験 経験 強み 興味 機会 人生 取り組むべきこと × 時代の流れ・ニーズ 自分（会社） 自分をつくってきた経験 自分の内から出て来たので 情熱が長続きする ↓ 成功する 社会 自分（強み+興味+経験） × 社会（機会） = 取り組むべきこと 「立志」
- 69. 創造的なチーム
- 78. ・組織 ・エンジニア ・組織とエンジニア ← Next これからの時代の会社 = エンジニア（知識労働者）が伸び伸びと 創造性を発揮し価値を創り出せる会社
- 83. Hack the Real !! 専門知識 価値 専門知識 専門知識 Hack!! ＜Real＞ 創造的なエンジニアになろう！ コミュニティ経営 創造
Editor's Notes
- 本日お話しする内容の全体像を先にお伝えします。Pythonを開発のメイン言語に採用したのは、2008年4月でした。その後、Pythonの採用をきっかけに会社は大きく変化して行きました。その変化の中で見えて来た、エンジニアが活躍するこれからの時代の会社、未来の会社はどのようなものになるかということでした。 これについて組織運営、エンジニアのありかた、そして、組織とエンジニアの関係という３つの観点からお話しします。 私はエンジニアであり、かつ経営者ですが、その立場から本日はお話しし、皆さんの今後にお役に立てることが１つでもあればとおもいます。
- まず、そもそも、なぜ、私が会社をつくったのかという理由について最初にお話しします。会社をつくる前は、私はフリーランスのプログラマでした。 私がその頃に感じていたことですが、一般的な会社では企画や営業の人がエンジニアより立場が上という感じだったと思います。エンジニアの給料も低かったとおもいます。そのような状況で、私は「エンジニアが活躍し、幸せになれる会社はどのような会社なのだろうか」ということをいつも考えていました。そして、そのような会社が無いなら、自分でこれからの時代の会社をつくろうと決心したのがきっかけです。
- このような状況で、私は「エンジニアが活躍し、幸せになれる会社はどのような会社なのだろうか」ということをいつも考えていました。そして、そのような会社が無いなら、自分でこれからの時代の会社をつくろうと決心したのがきっかけです。
- 2006年の5月に会社を立ち上げ、2008年の3月までの約２年間はJavaやperlで開発していました。そこを2008年4月に会社のメイン言語をPythonにすることに決めて、社内で発表しました。その当時、社員は私を含めて４人。Pythonでの開発実績は0件でした。
- 次に、私がPythonを採用した理由です。たしかにPythonの開発生産性の高さ、保守性の高さなどの技術的メリットというのも選択理由としてはありました。しかし、本当の理由は、これからの時代の会社をつくっていくためのエンジニアを採用したいということでした。JavaやPHPのエンジニアを採用しようとすると、どうしても大手会社との争いになります。そうなると採用のための資金量ではかないません。一方、Pythonは個人で使っている人は多い印象でしたが、仕事で使っている人は少ないという印象を私は持っていました。そこで、会社でPythonを言語として使うようにすれば、大手の会社と競争にならずに、良いエンジニアが来てくれるのではないかと考えました。
- Pythonを採用した結果どうなったか。まず、2008年4月にPythonを採用することをTwitterでひっそりと宣言しました。４人程度の小さな会社なので、特に何もないだろうと思ってたのですが、２か月後に、Python温泉というコミュニティから、エンジニアが１人紹介されました。彼は今でもうちの会社で仕事をしています。その後も、2008年には2人、翌年には10人と次々と、Python界隈のエンジニアが入社することになりました。
- Pythonを採用したことにより、どのようなひとたちが集まって来たのでしょうか。
- ひとことでいうと「変わった人たち」です。私が期待していた通り、変わった人たちが集まってきました。
- どれくらい変わっているか？というと、休みやプライベートの時間を使って、家族を説得してまで、Pythonの勉強をしたり、ハッカソンで集まってプログラミングをしているような人たちです。
- 私がたびたび、質問されることがあります。 個性が強いエンジニアをどのように束ねるのか？ということです。
- 私の答えは「束ねない」です。それはなぜかというと、私には束ねることができないからです。 束ねることができないので、彼らが望むような会社はどのような会社なのだろうということに目線が変わって行きました。そうすると、次第に会社が変化して行くのがわかりました。
- Pythonを採用したことにより、会社に起こった変化について２点お話しします。
- 会社におこった変化の１つ目です。Pythonを採用したことにより、Pythonを好きな人たちが集まりました。必然的にPythonのコミュニティに会社が変わっていったわけです。
- 会社がPythonコミュニティになったおかげで、いろいろな効果が会社に生まれました。ここでは３つあげました。 １つ目は、同じことに共感し、感動できるということ。Pythonという同じことに興味をもっていますので、例えば、何かのソフトウェアがリリースされたとか良いツールがあるという話を、誰かが始めた時に、周りの人もそれに対して「おーすごい」とか、一緒に共感するようになります。これが、Pythonを使わない人が、Pythonの話を聞いても「へぇ」くらいの反応で、共感したりすることが少ないと思います。そのように、興味が同じ人が集まると、自分が知った新しい情報を共有しあうので、社内に情報が集まるようになります。 ２つ目が、ベースの価値観が一致しているということです。Pythonには、コードの読みやすさ、わかりやすさを重視するような価値観、シンプルさの追求やzen of python という思想があります。その思想はプログラミングに限らず仕事に通じる価値観があります。それらの価値観が一致していることで、合意の形成や意思決定が速くなったとおもいます。 ３つ目が、ドキュメントを積極的に書こうという人が多いということです。これは、Pythonは標準ドキュメントが充実していたり、Sphinxという素晴らしいツールがあったりするので、その恩恵を受けている人が多く、ドキュメントを書こうという意志のある人が、pythonistaには多いのかなと想像しています。ドキュメントを積極的に書こうという人が多いので、社内では、暗黙知の共有化、そして暗黙知の形式知化が促進されたとおもいます。
- 会社に起こった変化の２つ目です。それは、会社の運営がオープンソース・コミュニティ型に変わって行ったということです。集まって来た多くのエンジニアは、オープンソースを使って恩恵を受けていたり、コミュニティに参加していたり、自分がコントリビューターとして活動していたりして、日頃からなんらかのかたちでオープンソースに関わっている人たちでした。したがって、オープンソース・コミュニティで行われている組織運営方法が、自然に会社に採用されたのかと思います。詳しい内容は、のちほど説明致します。
- 私が経営者として、Pythonを採用し、会社が変化して行く中で、見えて来たものがありました。
- 冒頭で申し上げたことですが、私が会社をつくった理由は「これからの時代の会社をつくりたい」ということでした。工業が中心の工業社会では、階層型、上意下達の組織形態で、働き手はブルーワーカーと呼ばれるひとたちです。ピーター・ドラッカーのいう、知識社会では、エンジニアなどのナレッジーワーカーが主な働き手となります。皆さんのようなエンジニア、ナレッジワーカーがのびのびと創造性を発揮し、価値を創り出すためには、工業社会の焼き直しのような組織ではなく、知識社会のための組織が必要になります。現時点ではその過渡期であり、知識社会の組織が、どのような組織であるべきかを模索している段階なのではないでしょうか。Pythonを採用し、会社が変化して行く中で私に見えて来たものは、知識社会の会社、これからの時代の会社、未来の会社は、エンジニア・コミュニティのような会社になるだろうというものです。
- エンジニア・コミュニティとは、オープンソースのコミュニティであったり、今回のPyConや、さまざまなMeetup などのようにエンジニアが中心となって活動しているオープンなコミュニティをイメージして頂ければと思います。 みなさんご存知のように、ソフトウェアや、ドキュメント、人のつながりなど、さまざまな価値を生み出しているコミュニティです。
- 知識社会の会社、未来の会社がどうあるべきかということについて、エンジニアコミュニティのような組織になるだろうとお伝えしました。 これについて、組織運営、エンジニアのありかた、組織とエンジニアの関係のありかたという３つの観点からお話ししたいと思います。
- 組織運営については、２つお話しします。 １つ目は、会社はコミュニティであるということ。 ２つ目は、オープンソース・コミュニティ型運営から学ぼう ということをお話しします。
- コミュニティとは、同じことに興味をもった人たちの集まりです。 同じことに興味をもっているので、同じことに共感し、感動することができます。そのような日頃の会話の中から個人が持っている暗黙知が共有されやすくなり、組織内の学習や情報共有につながります。そのような切磋琢磨の結果、会社の知識レベルはあがり、その知識を事業に活かせるようになります。それがひいては会社のブランド化にもつながっていくこともあります。ここはポイントなのですが、コミュニティの興味の対象、ジャンルは、なんでも良いわけではなくて、会社の事業に関係するものがよいとおもいます。たとえば、会社のみんながラーメンが大好きだとします。毎日毎日、仕事中にラーメンについて活発に議論したからといって、会社の直接の成果には、つながりにくいとおもいます。うちの会社の場合は、Pythonを好きな人たちが集まったおかげで、書籍出版にもつながり、さらにはその書籍出版が会社のブランドにまでつながっていきました。そのようなコミュニティを活発化するために、会社として重要なのは、仕事中の雑談の積極的な奨励と、社内勉強会など、場作りだと思います。それによって、社員同士の知識や情報が自然と共有されていくことになります。私の会社の場合は、オンライン上での雑談がとても活発です。
- 組織運営の２つ目は「オープンソース・コミュニティから学ぼう」ということについてお話しします。1983年にリチャード・ストールマンがGNU(グニュー)プロジェクトを始めて、フリーソフトウェアの重要性を訴え、多くの人の支持を受けました。その後、1990年代にオープンソースのムーブメントが起こります。そして、インターネットの発展とともに、世界の多くの人がオープンソースプロジェクトに参加するようになりました。それにつれて、オープンソースプロジェクトもコミュニティとなり、組織運営、コミュニティ運営というものが必要になりました。オープンソースプロジェクトの参加者は、ほとんどがボランティアで隙間時間に成果を創り出していますので、その運営には効率性が求められます。また、オープンソースというくらいですから、オープンな運営、風通しの良さが求められます。こうして、経営者や経営学者ではなく、エンジニアたちが創意工夫して培って来たオープンソース・コミュニティの運営ノウハウが、エンジニアが活躍するこれからの会社、知識社会の会社にも有用であるというのが私の考えです。
- オープンソースから学ぼうということで、具体的には、フラットな組織、コミュニティ評議会、コミュニケーションという３点についてお話しします。
- まずは、フラットな組織ということについてお話しします。 ここでは、単純に、階層型か、フラット型か、の２形態に絞ってお話しします。
- まずは階層型組織についてお話しします。まず、階層型の特徴として、組織を管理しやすいということがあげられます。 ２つ目は官僚制。官僚制では、管理のためのルールが組織内につくられていきます。３つ目が、情報が階層間で滞りやすいというものです。情報が滞りますので、意思決定のスピードがどうしても落ちるということが特徴としてあげられます。４つ目が、どうしても出世に目が行くということです。階層型組織では、たいていの場合、組織の階層をあがっていけば、昇進で給料があがります。社内での昇進を考えるとどうしても社内に目が向いてしまい、社外にどのような価値をもたらすのかという意識がおろそかになりがちです。 階層型のメリットは、管理しやすいので、うまく回れば、組織の上の人は楽ということです。 デメリットは、管理されたり、社内に目が向いているうちに、創造性の源である、個人の内発的動機、自尊心、好奇心が失われ、個人の創造性がなくなってしまう恐れがあるということです。
- 次に、フラット型組織の特徴についてお話しします。 フラット型組織は、オープンソースのコミュニティのような組織をイメージしてください。オープンソースのコミュニティで、階層型組織というのは考えられないとおもいます。フラット型組織では、プロジェクトなど、なにか目的が生まれたらそのたびにチームをつくり、都度メンバーが果たすべき役割を決めて行きます。そして、管理のためのルールは最低限。ここでつくられるルールも仕事をスムーズに進めるためのルールです。また、階層とセクションがありませんので、情報が行き渡りやすいという特徴もあります。また、組織の階層を昇って行く必要がありませんので、出世も気にする必要はありません。これらのようにフラット型組織をつくることで、エンジニアは余計なことを考えず、のびのびと考えられるようになります。それにより、エンジニアが価値を創り出すことに集中できるようになるのではないかとおもいます。デメリットとしては、組織の管理が難しいということです。
- さきほど、フラット型組織のデメリットとして、管理が難しいという話をしました。 フラット型組織は、管理が無いので大丈夫なのか？組織が崩壊するのではという疑問をもたれた方もいらっしゃるかもしれません。 フラット型組織で、大事なのは、個人個人のセルフマネジメントと、お互いの信頼関係です。個人が自律的に動くということです。また、誰かが誰かを管理するという関係性をつくらないようにすることも重要となってきます。 それにより、組織にかかる様々なコストを削減できます。様々なコストとは管理するコスト、管理されるコスト、コミュニケーションコストなどです。そのコストを本来やるべき、「価値を創り出す」ということにより使うことができるのです。
- 会社の経営は、コミュニティの運営であると定義すると経営者はコミュニティのリーダーということなります。 オープンソースのコミュニティで、リーダーが偉いということはないとおもいます。 それはただの役割でしかありません。つまり、経営者も偉いひとではないということです。経営者は権力ではなく、役割であるということです。 組織のリーダーにとって重要なこと。それは権力ではなく、リーダーという役割を果たせるだけの良い人格をもつということだと私は思っています。
- 次に、コミュニティ評議会ということをお話しします。
- コミュニティ評議会とは、「アートオブコミュニティ」という書籍に書かれている概念です。 コミュニティ評議会とは、コミュニティ全体を運営する役割を持つグループです。 課題がある場合に、その課題は、評議会に提出され、提出された課題について評議会で議論し、方針を決定します。
- 私の会社では、このコミュニティ評議会に該当するものを運営しています。それは、「BP（ビーピー）カイゼン」という取り組みです。この取り組みの目的は会社を改善することです。どのように運営しているかというと、月２回、１時間のミーティングを開催し、社内誰でも参加できます。redmineで会社の課題を管理し、課題がある場合はチケットを作成します。 議事録は全社員に公開し、すべてオープンなプロセスで課題の解決方法が決定されていきます。
- 「BP（ビーピー）カイゼン」から生まれた制度について１つ紹介します。 それはBPRD2.0、BeProud Remote Dayという制度です。どのような制度かというと、週５日間、つまり全ての日に関していつでもリモートで勤務可能というものです。名前に2.0とついているのは、もともと週１日はリモートで勤務可能というものが、さらに拡大されたからです。この制度は、BPカイゼンで、社員からアイデアが出され、実現しました。自分たちでつくった制度なので、アンケートをとったり、ツールをつくったりして制度をうまく運用できるように、みんなで工夫をしています。
- コミュニティ評議会を置くメリットですが、私は２点あると考えています。 １つ目は、自分たちで制度を提案して、自分たちで育てて行くことができるということです。これによって、会社を自分たちでよくしていこうという当事者意識や参加意識が生まれてくるという効果があります。２つ目は、決定プロセスがすべてオープンなので、風通しがよいということです。これによって、会社全体に公正感が生まれてくるという効果が期待できます。
- ３点目は、コミュニケーションです。
- オープンソース・コミュニティのコミュニケーション手段は、メーリングリスト、ITS、チャット、ビデオ通話、時には直接のミーティングなどが使われているとおもいます。 これは、オープンソース・コミュニティは、時間やリソース、場所などの制約が多いため、 自然にさまざまな手段を使って、隙間時間で、成果を出すための工夫です。
- コミュニケーションについての弊社での取り組みを紹介します。 時間やリソース、場所などの制約が多いのは会社も同じです。これらが充分にあるという企業はほとんどなさそうです。そこで弊社では、リモートワークの体制作りによって、時間、リソース、場所の制約を超えようとする取り組みをしています。時間については、リモートワークにより通勤時間の削減が期待できます。 場所とリソースについては、リモートワークによって、家庭事情などで会社に来れない人も仕事ができるようになります。 例えば奥さんが出産するという場合に、地方の奥さんの実家に一緒に戻り、そこから仕事をするというような場合です。 そのために、SlackやGoogle hangout、Google Drive、DropBox、redmineなどさまざまなツールを活用してリモートワークを推進しています。
- リモートワークの話をすると出てくる疑問が、リモートワークはチームでのクリエイティブな仕事に向かないのではないか？ということです
- その疑問に対する私の考えをお伝えします。 何かを創り出すときにはアイデアを生み出すプロセスと、実際につくるプロセスがあります。 そのアイデアを生み出すプロセスと、つくるプロセスをしっかりと分けるように段取りをすれば、必ずしも全ての時間を同じ場所で顔を合わせて仕事をする必要がないというのが私の考えです。このプロセスを意識し、仕事の段取りをしっかりすれば、リモートワークでもクリエイティブなチームの仕事は可能ということです。
- 「知識社会の会社、未来の会社とは」ということで、組織の次は、エンジニアのありかたというお話をしたいとおもいます。
- 組織運営については、２つお話しします。 １つ目は、会社はコミュニティであるということ。 ２つ目は、オープンソース・コミュニティ型運営から学ぼう ということをお話しします。
- オープンソースのContributorをイメージしてみると、３つ特徴が思い浮かびます。 １点目が社会にもたらす価値に目を向けている。どのようなソフトウェアが世界に役立ち、使われるのかを常に考えているということです。 ２点目は、自らがつくるソフトウェアに対してのアイデアをもっているということです。３点目がコミュニティの活動に自発的に参加しているということです。このようにオープンソースのContributorは、主体的に価値を創り出そうとしている、創造的なエンジニアであるということが言えるのではないでしょうか。
- エンジニアのありかたについての私のメッセージは、「創造的なエンジニアになろう」ということです。 みなさんは、Pythonという素晴らしいプログラミング言語や、サードパーティー製のの充実したライブラリをつかって、さまざまなソフトウェアをつくりだすことができます。 従って、みなさんが価値あるものを創り出せるかどうかは、みなさんがいかに創造的になれるかどうかということにかかっていると私は思います。 創造的なエンジニアとは、自ら主体的になって価値を創り出そうとするエンジニアのことです。
- では、創造的なエンジニアになるにはどのようにしたら良いかというお話をします。 ここでは、創造的になるための、３つの方法を紹介したいと思います。 それは、不安を乗り越え、主体的になる、技術に感動する習慣をもつ、価値を創り出すプロセスを学ぶの３つです。
- １つ目は「不安を乗り越え、主体的になる」です。
- 創造的になる最大の敵はなんでしょうか。それは不安と恐怖です。 仕事における不安、恐怖とは”できなかったらどうしよう”、”できなかったらクビになる”という自らの感情です。不安や恐怖に怯えてしまうと、自分の外からの刺激に反応することに意識が向いてしまうので、主体性を失ってディフェンシブな思考になってしまいます。そうなると人は、創造性を失ってしまいます。
- では、不安を乗り越えるにはどうしたらよいでしょうか。 そのための方法として、２つお話しします。 １つ目は、「技術を身につける」、２つ目は、「今を生きる」ということです。
- 不安を乗り越える方法の１つ目は「技術を身につける」です。 不安が生まれる原因の１つに「自信がない」ということが上げられます。なぜ、自信がないかというと、技術がないからというのが一番大きな原因ではないでしょうか。逆にいうと、技術を身につけると、自信がつき、次第に心が安定し、強くなっていくということが考えられます。 このように考えると、創造的なエンジニアになるには、自分に自信がつくまで、技術を徹底的に身につけるというのが重要ではないでしょうか。
- しかし、技術を身につけるといっても技術はすぐに身に付かないです。そのため、すぐにできる方法をお話しします。それは「今を生きる」ということです。開発プロジェクトでは、納期や品質などさまざまなものが求められます。そのため、エンジニアには「できなかったらどうしよう」という不安や恐怖が生まれてきます。その不安や恐怖にかられて仕事をしていると、集中して仕事ができずに、結果的に成果がでないということになりがちです。
- そのようなことにならないためには、求められる結果に、まず付箋紙を貼ってしまいます。一旦忘れてしまって頭の片隅に置く程度にしてしまいます。そしてプログラミングという行為そのものに打ち込む、楽しむということに専念します。 プログラミングが楽しいという気持ちで仕事をすると、集中できるようになります。 集中してものごとに取り組むと、結果的に成果につながります。 このように集中して取り組んでいる状態をフロー状態と言って、心理学では、人が仕事をする上では、理想的な状態と言われています。
- 創造的なエンジニアになる方法の２つ目として、「技術に感動する習慣をもつ」ということをお話します。
- プログラミングを始めた当初は、自分がつくったプログラムが動くと「おー、動いた！」とか、何かの技術やライブラリ、ツールを使った時に「この技術は便利だ！」と感動していたとおもいます。それが、だんだん経験を積んでくると、「動いて当たり前」「その技術は想定の範囲内、目新しくない」というように考えてしまいます。
- 何かに感動すると、その感動した対象に対して、人は好奇心が湧いてきます。好奇心がわくと、その対象についてもっと知りたいという探究心が生まれてきます。その探究心が新しいものを創り出すことにつながります。 感動は、その感動した対象への記憶を強くするという効果もあります。記憶は記憶同士が結びついて、アイデアとなるので、それが創造につながります。 何が言いたいかというと、感動する習慣をもつと、創造的なエンジニアになれるということです。逆に考えると、感動が少ない人は、好奇心も薄れて、記憶力も弱まるので創造性を失い、エンジニアとして退化していくことになります。 「子供のような好奇心、あるいは冒険心があって初めて、新しいものを生み出す力が生まれてくるのです。」これは、amazon創業者のジェフベゾスの言葉です。
- 創造的なエンジニアになる方法の３つ目として「価値を創り出すプロセスを学ぶ」ということをお話したいと思います。
- 「知識社会、未来の会社とは」ということで、組織、エンジニアとお話ししましたので、次は、組織とエンジニアの関係についてお話しします。
- 組織とエンジニアの関係についての私のメッセージは、「オープンソースのContributorのように仕事をしよう」ということです。通常、会社とエンジニアのあいだでは雇用契約が結ばれていて、仕事もあらかじめ契約で定められていることもしばしばあります。しかし、そのような関係を重視しすぎると、契約で決められたことだけをやるということになり、創造的なものを生み出す仕事はできなくなってしまいます。その一方で、オープンソースのContributorは、コミュニティの中で、自分の強みや興味を活かして、自分が貢献できることをみつけて仕事をするということをしています。 オープンソース・コミュニティと同じように、会社という組織でも、さまざまな役割があります。会社においても、オープンソースのContributorのように、エンジニアが自分の強みや興味をもとに、社内で果たせる役割をみつけて、貢献するという仕事のスタイルが良いのではないかというのが私の考えです。貢献という言葉がキーワードになります。それにより、やらされる仕事から、自分で貢献できる仕事を主体的に見つけて行くというスタンスに変わっていきます。
- そのような会社とエンジニアの関係のときに、報酬は何に対して支払うべきかということをお話しします。私の答えは、果たしてくれた役割に対して、報酬を支払うということです。そうすれば、エンジニアは自分が果たせる役割は何かという視点を持つようになり、主体的に貢献するようになります。会社でよくある報酬の支払いとして、役職に対して報酬を支払うということがありますが、これですと、仕事をせず、偉いだけの人に多くのお金を支払うことになり、不公平となります。組織を活性化させるためのポイントは、役割に対して報酬を支払うということです。
- 組織とエンジニアの関係について、もう１点お話しします。 それは、エンジニアと組織はお互いに協力して、シナジーを生み出す関係であるということです。 エンジニアは自分の強みと興味で組織に貢献する。会社は、エンジニアが自発的に参加したくなるような組織作りをする。会社は、価値を創造するためのインフラになることです。そのようにお互いが創造的でシナジーを生み出せる関係になることがポイントであると私は思っています。