SlideShare a Scribd company logo
エンジニアコミュニティで
組織は動きだす
株式会社ビープラウド佐藤治夫
2016/2/18
これからの時代のエンジニア、組織
エンジニアと組織の関係とは
なぜ、野球ユニフォーム?
IT勉強会 発表時ユニフォーム正装化へ
©PyCon JP 2015
ソーシャルメディア(Twitter、Facebook など)へ
私の勇姿(ユニフォーム姿)の写真アップ、
できたらお願いします!
ハッシュタグ: #devsumiD
私から皆さんへ本日たった一つのお願い
発表にあたり
自己紹介
• 佐藤治夫(Sato Haruo)
• Twitter: @haru860
• 株式会社ビープラウド 代表取締役社長
• エンジニア19年目(うち経営者10年目)
ビープラウド
20162006200320001997
個人
事業主
小規模
SIer
東証1部上場
大手SIer
技術記事執筆
Codezine、DB Magazine、@IT、JavaPress、ThinkIT
株式会社ビープラウドについて
• Pythonをメイン言語で用いて開発
• Webの受託開発がメイン事業
(エンジニア40人体制)
• connpass 企画・開発・運営
• Python Professional Programming
第1版 2012年3月、第2版 2015年2月 上梓
→増刷されて売れてます
• Web系勉強会:BPStudy101回連続開催中(2007年9月〜)
アジェンダ
これからの時代の会社がどのようなものか?
1.組織
2. エンジニア
3.組織とエンジニア
Pythonを会社のメイン言語に採用(2008年4月)
↓
会社が大きく変化し、見えて来たもの
テーマ:
エンジニアが活躍するこれからの時代の会社は?
私が会社をつくった当時のエンジニア
2006年当時
・当時の私 = プログラマ / フリーランス
・世の中
・企画/営業の人が組織で上
・エンジニアの給料は低かった
そもそも私が会社をつくった理由
「エンジニアが活躍し、幸せになれる会社
はどのような会社であろうか?」
... と日々考えていた
↓
自分で「これからの時代の会社」をつくろう
Pythonの採用
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温泉)から1人目の
エンジニアが紹介される
↓
2008年 2人入社
↓
2009年 10人入社
… その後も次々と入社
Pythonの採用により
どのような人たちが集まってきたか?
変わったひとたち
(Strange People)
ひとことでいうと….
変わったひとたちが集まって来た
休みやプライベートの時間を使って
技術の勉強をしたり、集まってプログラミングに
いそしむ変わったひとたち…
愛すべき変わりもの(Geek、Nerd)
Q. 個性が強いエンジニアをどう束ねるの?
度々、質問されること
Answer
束ねない(制御不能のため)
→ エンジニアの声に耳を傾け、経営しよう
会社に起こった変化
会社の変化その1
Pythonを好きな人たちが集まった
↓
会社自体がPythonコミュニティの1つになった
BPPython
ツール
フレームワークライブラリ
Meetup
会社がPythonコミュニティになった効果
・同じことに共感し、感動できる
→ 最新の情報が集まりやすい
・ベースの価値観が一致している
(影響)読みやすさ, シンプル , Zen of Python
→ 合意の形成、意思決定の迅速化
・ドキュメントを積極的に書こうという人が多い
(影響)Python標準ドキュメントの充実、Sphinx
→暗黙値の共有化、形式知化の促進
集まったひとたち
・オープンソース を使い、恩恵をうけている
・オープンソース・コミュニティ に参加している
・オープンソースのコントリビューターとして活動
している
↓
会社も自然とオープンソース・コミュニティ型の
会社運営に変わって行った
会社の変化その2
会社の変化の中で
見えてきたもの
これからの時代の会社とは?
工業社会 知識社会
エンジニア
(知識労働者)
?
肉体労働者
エンジニア(知識労働者)
が伸び伸びと創造性を発揮し
価値を創り出せる会社
模索中 エンジニア
コミュニティ
イマココ
エンジニア・コミュニティ
ソフトウェア
ドキュメント
人のつながり
Pyth
on
カンフ
ァレン
ス
Framew
ork
ライブ
ラリ
Meet
up
価値
エンジニア
↑
エンジニアが中心となり自発的に参加し、
さまざまな価値を生み出しているコミュニティのこと
・組織
・エンジニア
・組織とエンジニア
これからの時代の会社
= エンジニア(知識労働者)が伸び伸びと
創造性を発揮し価値を創り出せる会社
1. 会社 = コミュニティである
2. オープンソース・コミュニティ型運営から学ぼう
・フラットな組織
・コミュニティ評議会
・コミュニケーション
組織
同じことに共感し、感動することができる
↓
暗黙値が共有され、組織内の学習や情報共有につながる
↓
切磋琢磨の結果、知識レベルがアップし、事業に活かせる
↓
ブランド化
会社 = コミュニティである
組織に大事なこと
・雑談の積極的奨励
・場作り(社内勉強会)
コミュニティ
= 同じことに興味をもった人たちの集まり
1990年代後半 オープンソースのムーブメント
↓
インターネットの発展
↓
多くのエンジニア がオープンソースプロジェクト に参加
↓
オープンソースプロジェクト の コミュニティ化
↓
組織運営・コミュニティ運営ノウハウを培う
(エンジニア が創意工夫して培って来たノウハウ)
→ エンジニアが活躍する、これからの会社にも有用
組織
オープンソース・コミュニティ型運営から学ぼう
・フラットな組織
・コミュニティ評議会
・コミュニケーション
組織
オープンソース・コミュニティ型運営から学ぼう
フラットな組織
階層型か、フラット型か?
階層型組織
・組織を管理しやすい。
・官僚制
→ 管理のためのルールがつくられる
・情報が階層間で滞りやすい
→ 意思決定のスピードが落ちる
・どうしても出世に目が行く
→ 社内に目が向き、社外に対する意識が薄れがち(大企業病)
メリット
管理しやすいので、うまく回れば、上のひとは楽
デメリット
内発的動機、自尊心、好奇心が失われ、創造性が失われる
フラット型組織
・目的ごとにチームをつくり、役割を決める
・管理のためのルールは最低限
仕事をスムーズにするためのルール
・情報が行き渡りやすい
・出世を気にしなくて良い
メリット
価値を創り出すことに集中できる
デメリット
組織の管理が難しい
フラット型組織で大丈夫か?
・セルフマネジメントと信頼関係を重視
・管理する/管理されるの関係をつくらない
組織にかかるコストを削減できる
・管理するコスト
・管理されるコスト
・コミュニケーションコスト
→ 本来やるべき「価値を創り出す」ことに集中できる
会社の経営 = コミュニティの運営
経営者 = コミュニティ・リーダー(=役割)
経営者は偉い人ではない
↓
権力ではなく役割である
↓
リーダーにとって重要なこと
権力ではなく、良い人格をもつこと
・フラットな組織
・コミュニティ評議会
・コミュニケーション
組織
オープンソース・コミュニティ型運営から学ぼう
コミュニティ評議会(Community Council)
・コミュニティ全体を運営する役割を持つグループ
・課題がある場合に、評議会に提出される
・課題について評議会で議論し、方針を決定する
「Art of Community」
Jono Bacon 著 / 渋川よしき 訳 より
「BP カイゼン」プロジェクト
・会社を改善することを目的
・月2回、1時間のミーティングを開催
・社内誰でも参加できる
・redmineで課題管理。
課題がある場合、チケットを作成する
・議事録は全社員に公開、オープンなプロセスで決定
Be Proud の取り組み
「BP カイゼン」から生まれた制度
BPRD2.0 (BeProud Remote Day)
・週5日間、いつでもリモート勤務可能
・制度を維持できるように、自分たちで制度を育てている
(例)
・アンケートを取り、問題点を改善する
・Slackやbot などのツールを活用し、
皆が気持ちよく仕事ができるような仕掛けづくり
コミュニティ評議会を会社に置くメリット
・自分たちで良い制度を提案し、育てていくことができる
→ 当事者意識、参加意識が生まれる
・決定プロセスがすべてオープンなので風通しがよい
→ 公正感が生まれる
・フラットな組織
・コミュニティ評議会
・コミュニケーション
組織運営
オープンソースコミュニティ型運営から学ぼう
オープンソース・コミュニティ
のコミュニケーション手段
・ML
・Issue Tracking System(ITS)
・チャット
・ビデオ通話
・オフラインミーティング
時間、リソース、場所などの制約が多い
・自然にさまざまな手段を使う
・隙間時間で、成果を出している
リモートワークによるコミュニケーション
導入しているコミュニケーションツール
時間、リソース、場所などの制約が多いのは会社も同じ
↓
リモートワークの体制づくりにより制約を超える
・時間 → 通勤時間の削減→時間を捻出する
・場所/リソース → 家庭事情などで会社に来れない人も仕事ができる
etc….
Q. リモートワークは
チームでのクリエイティブな
仕事に向かないのでは?
リモートワークでは段取りが重要
つくるプロセスアイデアを生み出すプロセス
必ずしも全ての時間、顔をあわせて仕事をする必要はない
チームで一緒に仕事 個別に仕事
「アイデアを生み出すプロセス」と「つくるプロセス」 を区別する
・組織
・エンジニア ← Next
・組織とエンジニア
これからの時代の会社
= エンジニア(知識労働者)が伸び伸びと
創造性を発揮し価値を創り出せる会社
1. 創造的なエンジニアになる方法
2. 何に取り組めば良いか
3. 創造的なチーム
エンジニア
オープンソースのコントリビューター
コミュニティ
自発的に参加
エンジニア
価値に目を向け、アイデアを持っている
・どのようなソフトウェアが世界に役立つのか?
・どのような機能が便利なのか?
価値
・社会にもたらされる価値に目を向けている
・アイデアを持っている
・自発的に参加している
創造的なエンジニアになろう
組織
貢献
エンジニア
<創造的>
価値
アイデア
創造的なエンジニア
= 主体的に価値を創り出そうとするエンジニアのこと
・不安を乗り越え、主体的になる
・技術に感動する習慣をもつ
・価値を創り出すプロセスを学ぶ
創造的なエンジニアになる方法
創造的なエンジニアになる方法
・不安を乗り越え、主体的になる
・技術に感動する習慣をもつ
・価値を創り出すプロセスを学ぶ
創造性を失わせる最大の敵
・不安
“できなかったらどうしよう”
・恐怖
“できなかったらクビになる”
自分の外のことに怯え、主体性を失い、ディフェンシブな思考になる
↓
創造性を失う
創造的なエンジニアになるために
不安を乗り越える方法
その1. 技術を身につける
その2. 今を生きる
その1:技術を身につける
技術を身につける
↓
自信がつき、心が安定し、不安が少なくなる
創造的なエンジニアになるために
不安を乗り越える方法
体 → 技 → 心 の順で身につける
その2:今を生きる
完成した
プログラム
プログラミング 不安
恐怖
<欲しい結果>
不安・恐怖をもとに頑張る(外発的動機)
↓
集中できず、結果がでない
「できなかったらどうしよう」
納期、品質、満足度 etc…
創造的なエンジニアになるために
不安を乗り越える方法
完成した
プログラム
打ち込む/
楽しむ
一旦忘れる
(頭の片隅に置く程度にする)
プログラミングそのものを楽しむ(内発的動機)
↓
集中できて、結果につながる(フロー状態)
プログラミング
<欲しい結果>
創造的なエンジニアになるために
不安を乗り越える方法
その2:今を生きる
・不安を乗り越え、主体的になる
・技術に感動する習慣をもつ
・価値を創り出すプロセスを学ぶ
創造的なエンジニアになる方法
技術に感動する習慣をもつ
(エンジニアを始めた当初)
「おー、動いた!」
「この技術は便利だ!」
↓(経験を積んでくると)
「動いて当たり前」
「その技術は想定の範囲内。目新しくない」
感動すると創造的になれる
感動が少ない人は好奇心が薄れ、記憶も弱まる
。→ 結果、退化していく
感動 好奇心 探求心 創造
記憶 アイデア
「感動する脳」
茂木 健一郎 著 より
子供のような好奇心、あるいは冒険心があって初めて、
新しいものを生み出す力が生まれてくるのです。
ジェフ・ベゾス(amazon.com創業者)
・不安を乗り越え、主体的になる
・技術に感動する
・価値を創り出すプロセスを学ぶ
創造的なエンジニアになる方法
視点→思考→言葉→行為→結果
(入力) (出力)
創造の3つのプロセス
→人は自分の視点をなかなか変えられない
アイデア 価値価値創造プロセス
価値を創り出すプロセスを学ぶ
価値創造プロセスを学ぶと創造の視点が生まれる
走りながら考える
価値
プロジェクト
スタート
間違った方向に
ロケットスタート
途中で力尽きる…
走りながら…でも成功する例
・センスがよかった
・運がよかった
力尽きないためにも、価値を創りだす
プロセス・考え方を学ぶことが必要!
ブレスト、プロトタイプ…
要求開発(匠メソッド)
戦略
要求
業務
要求
IT
要求
システム
開発
<経営者の視点> <現場の視点>
<ITの視点> <開発の視点>
価値 ビジネスモデ
ル
要求ビジョン
コンセプト
リーンスタートアップ
アイデア 構築要求
提供
計測
フィード
バック
学習
・インタビュー
・ブログ反応
・プロトタイプ
使用
MVP
(Minimum Viable Product)
MVPをなるべく早くユーザーに提供し、フ
ィードバック・計測を繰り返しながら、よ
り良い製品に近づいていく方法
リーンキャンバス
ユーザー
開発者
リーンダイアグラム
①ダウンローディング
②観る(Seeing)
③感じる(Sensing)
④プレゼンシング
⑤結晶化
⑥プロトタイピング
⑦実践(Performing)
U理論
実現イメージ
何に取り組めば良いか?
NGパターン:
儲かりそうだという理由で手を出す
儲かっている
ジャンル
¥¥$$
お金 = 外発的動機
↓
長続きしない
経験 経験 経験
強み
興味
機会
人生
取り組むべきこと
×
時代の流れ・ニーズ
自分(会社)
自分をつくってきた経験
自分の内から出て来たので
情熱が長続きする
↓
成功する
社会
自分(強み+興味+経験) × 社会(機会) = 取り組むべきこと
「立志」
創造的なチーム
知識労働者の専門知識はそれだけでは何も生まない。
他の専門知識と結合して、初めて生産的な存在となる。
P.F.ドラッカー
知識労働者の協力
専門知識
価値
専門知識 専門知識
新しい
アイデア
知識創造
新しいアイデア=知識と知識の組み合わせ
↓
メンバー同士の協力、協働・共創が求められる
コミュニテイ
チームがより良いアイデアをうむための思考
新しいアイデア
私の
アイデア
あなたの
アイデア
NGな例
二者択一的
新しいアイデア
私たちの
アイデア
シナジー
私の
アイデア
あなたの
アイデア
全体は部分の総和より大きい 第3の案
〜成功者の選択
OKな例
チームがより良いアイデアをうむための思考
知識労働者のための
チームコラボレーションの基盤
謙虚
(Humility)
円滑な人間関係、健全な対話の基盤
Team Geek
〜Googleのギークたちは
いかにしてチームを作るのか
尊敬
(Respect)
信頼
(Trust)
HRT(ハート)
チームが価値を創造するためのリーダーシップ
空白のキャンバスのリーダーシップ
新しい
知識導く
キャンバス
リーダー
価値
専門知識
専門知識
専門知識
空白のキャンバスに
共に未来を描いていく
イノベーション
ファシリテーター
コレクティブ(集合的)・リーダーシップ
価値専門知識
専門知識
専門知識
リーダーシップ
リーダーシップ
リーダーシップ
知識労働者各自がリーダシップを持ち
、
価値の創造に向けて主体的に取り組む
現実を創り出す
1人1人が
スティーブ・ジョブス!
・組織
・エンジニア
・組織とエンジニア ← Next
これからの時代の会社
= エンジニア(知識労働者)が伸び伸びと
創造性を発揮し価値を創り出せる会社
オープンソースのコントリビューターのように仕事をする
会社
貢献
自分の強み(興味)を活かして
役割を探し、貢献する
会社
仕事
労働
契約で決められたことをする
役割 役割
役割 役割
役割に対して報酬を支払う
会社
貢献
報酬 果たした役割
に対して報酬を支払う
重要:役職に対して支払うのではない
シナジーで社会に価値を生み出す
会社
貢献
役割 役割
役割 役割
強み
・自発的に参加したくなる組織づくり
・組織の目的
・組織運営
価値
創造エンジニア
<創造的>
アイデア
<価値創造インフラ>
シナジー
まとめ
これからの時代の会社
=「エンジニア・コミュニティ」のような会社
→ エンジニア(知識労働者)が
チームで新しい知識・価値を生み出し、活躍する会社
Hack the Real !!
専門知識
価値
専門知識 専門知識
Hack!!
<Real>
創造的なエンジニアになろう!
コミュニティ経営
創造

More Related Content

What's hot

【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...
【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...
【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...
Developers Summit
 
缶詰屋さんの課題解決にスクラムを使ってみた
缶詰屋さんの課題解決にスクラムを使ってみた缶詰屋さんの課題解決にスクラムを使ってみた
缶詰屋さんの課題解決にスクラムを使ってみた
Toshiyuki Ohtomo
 
BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法
Haruo Sato
 
[Devsumi2017]オルタナティブなチーム開発のすゝめ
[Devsumi2017]オルタナティブなチーム開発のすゝめ[Devsumi2017]オルタナティブなチーム開発のすゝめ
[Devsumi2017]オルタナティブなチーム開発のすゝめ
Atsushi Kojima
 
BPStudy#88 connpassにおける戦略決定
BPStudy#88 connpassにおける戦略決定BPStudy#88 connpassにおける戦略決定
BPStudy#88 connpassにおける戦略決定
Haruo Sato
 
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
dreamarts_pr
 
オンラインPython学習サービスPyQの価格決め
オンラインPython学習サービスPyQの価格決めオンラインPython学習サービスPyQの価格決め
オンラインPython学習サービスPyQの価格決め
Haruo Sato
 
組織やチームの問題解決どうしていますか?
組織やチームの問題解決どうしていますか?組織やチームの問題解決どうしていますか?
組織やチームの問題解決どうしていますか?
Toshiyuki Ohtomo
 
匠Methodを使った製品開発の現場
匠Methodを使った製品開発の現場匠Methodを使った製品開発の現場
匠Methodを使った製品開発の現場
Haruo Sato
 
泥臭い受託開発Dev love関西
泥臭い受託開発Dev love関西泥臭い受託開発Dev love関西
泥臭い受託開発Dev love関西Toshiyuki Ohtomo
 
匠Methodをサポートする事業開発に役立つ書籍たちを紹介します
匠Methodをサポートする事業開発に役立つ書籍たちを紹介します匠Methodをサポートする事業開発に役立つ書籍たちを紹介します
匠Methodをサポートする事業開発に役立つ書籍たちを紹介します
Haruo Sato
 
越境する開発
越境する開発越境する開発
越境する開発
toshihiro ichitani
 
エンジニアからプロダクトマネージャーへ
エンジニアからプロダクトマネージャーへエンジニアからプロダクトマネージャーへ
エンジニアからプロダクトマネージャーへ
SmartNews, Inc.
 
匠Methodとの出会いと製品開発への活用
匠Methodとの出会いと製品開発への活用匠Methodとの出会いと製品開発への活用
匠Methodとの出会いと製品開発への活用
Haruo Sato
 
インセプションデッキ紹介
インセプションデッキ紹介インセプションデッキ紹介
インセプションデッキ紹介
You&I
 
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なこととアジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
Yasui Tsutomu
 
アジャイルの本質 - Agile Japan 2019サテライト名古屋
アジャイルの本質 - Agile Japan 2019サテライト名古屋アジャイルの本質 - Agile Japan 2019サテライト名古屋
アジャイルの本質 - Agile Japan 2019サテライト名古屋
hiroyuki Yamamoto
 
○○したら受託開発が180°変わった
○○したら受託開発が180°変わった○○したら受託開発が180°変わった
○○したら受託開発が180°変わった
Atsushi Harada
 
俺の事業部
俺の事業部俺の事業部
俺の事業部
Fumihiko Kinoshita
 
Agile Tech EXPO - New Normal Agile Episode 1 - Akihiro Yamamoto
Agile Tech EXPO - New Normal Agile Episode 1 - Akihiro YamamotoAgile Tech EXPO - New Normal Agile Episode 1 - Akihiro Yamamoto
Agile Tech EXPO - New Normal Agile Episode 1 - Akihiro Yamamoto
Akihiro Yamamoto
 

What's hot (20)

【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...
【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...
【A-L】コミュニティが成長させるマルチクラウド環境でのデータ管理の世界 ~Docker Hubで500,000ダウンロード達成、Scality S3サー...
 
缶詰屋さんの課題解決にスクラムを使ってみた
缶詰屋さんの課題解決にスクラムを使ってみた缶詰屋さんの課題解決にスクラムを使ってみた
缶詰屋さんの課題解決にスクラムを使ってみた
 
BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法BPSttudy#84 アイデアをカタチにする方法
BPSttudy#84 アイデアをカタチにする方法
 
[Devsumi2017]オルタナティブなチーム開発のすゝめ
[Devsumi2017]オルタナティブなチーム開発のすゝめ[Devsumi2017]オルタナティブなチーム開発のすゝめ
[Devsumi2017]オルタナティブなチーム開発のすゝめ
 
BPStudy#88 connpassにおける戦略決定
BPStudy#88 connpassにおける戦略決定BPStudy#88 connpassにおける戦略決定
BPStudy#88 connpassにおける戦略決定
 
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
サーバレスアーキテクチャにしてみた【デブサミ2017 17-E-2】
 
オンラインPython学習サービスPyQの価格決め
オンラインPython学習サービスPyQの価格決めオンラインPython学習サービスPyQの価格決め
オンラインPython学習サービスPyQの価格決め
 
組織やチームの問題解決どうしていますか?
組織やチームの問題解決どうしていますか?組織やチームの問題解決どうしていますか?
組織やチームの問題解決どうしていますか?
 
匠Methodを使った製品開発の現場
匠Methodを使った製品開発の現場匠Methodを使った製品開発の現場
匠Methodを使った製品開発の現場
 
泥臭い受託開発Dev love関西
泥臭い受託開発Dev love関西泥臭い受託開発Dev love関西
泥臭い受託開発Dev love関西
 
匠Methodをサポートする事業開発に役立つ書籍たちを紹介します
匠Methodをサポートする事業開発に役立つ書籍たちを紹介します匠Methodをサポートする事業開発に役立つ書籍たちを紹介します
匠Methodをサポートする事業開発に役立つ書籍たちを紹介します
 
越境する開発
越境する開発越境する開発
越境する開発
 
エンジニアからプロダクトマネージャーへ
エンジニアからプロダクトマネージャーへエンジニアからプロダクトマネージャーへ
エンジニアからプロダクトマネージャーへ
 
匠Methodとの出会いと製品開発への活用
匠Methodとの出会いと製品開発への活用匠Methodとの出会いと製品開発への活用
匠Methodとの出会いと製品開発への活用
 
インセプションデッキ紹介
インセプションデッキ紹介インセプションデッキ紹介
インセプションデッキ紹介
 
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なこととアジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
 
アジャイルの本質 - Agile Japan 2019サテライト名古屋
アジャイルの本質 - Agile Japan 2019サテライト名古屋アジャイルの本質 - Agile Japan 2019サテライト名古屋
アジャイルの本質 - Agile Japan 2019サテライト名古屋
 
○○したら受託開発が180°変わった
○○したら受託開発が180°変わった○○したら受託開発が180°変わった
○○したら受託開発が180°変わった
 
俺の事業部
俺の事業部俺の事業部
俺の事業部
 
Agile Tech EXPO - New Normal Agile Episode 1 - Akihiro Yamamoto
Agile Tech EXPO - New Normal Agile Episode 1 - Akihiro YamamotoAgile Tech EXPO - New Normal Agile Episode 1 - Akihiro Yamamoto
Agile Tech EXPO - New Normal Agile Episode 1 - Akihiro Yamamoto
 

Viewers also liked

Python入門 コードリーディング - PyConJP2016
Python入門 コードリーディング - PyConJP2016Python入門 コードリーディング - PyConJP2016
Python入門 コードリーディング - PyConJP2016
Shinya Okano
 
Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!)
Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!) Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!)
Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!)
Haruo Sato
 
「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから
Yoshihito Kuranuki
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
増田 亨
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
増田 亨
 
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1  ドメイン駆動設計の基本を理解する3週連続DDDその1  ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
 
Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)
Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)
Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)
Shinichi Nakagawa
 
Ant「ビルドできません」Travis「よし通れ」
Ant「ビルドできません」Travis「よし通れ」Ant「ビルドできません」Travis「よし通れ」
Ant「ビルドできません」Travis「よし通れ」
Minoru Sakamoto
 
デブサミ 2016 19-C-6
デブサミ 2016 19-C-6デブサミ 2016 19-C-6
デブサミ 2016 19-C-6
Kensuke Ishida
 
The Zen_of ICHIRO
The Zen_of ICHIRO  The Zen_of ICHIRO
The Zen_of ICHIRO
Haruo Sato
 
勉強会で発表してみようかなという方へ(BPStudy)
勉強会で発表してみようかなという方へ(BPStudy)勉強会で発表してみようかなという方へ(BPStudy)
勉強会で発表してみようかなという方へ(BPStudy)Haruo Sato
 
匠メソッドを導入したらサイトのアクセスが8倍になった話
匠メソッドを導入したらサイトのアクセスが8倍になった話匠メソッドを導入したらサイトのアクセスが8倍になった話
匠メソッドを導入したらサイトのアクセスが8倍になった話
Haruo Sato
 
モノを使うプログラミングが楽しかった話
モノを使うプログラミングが楽しかった話モノを使うプログラミングが楽しかった話
モノを使うプログラミングが楽しかった話
Kinuko Yasuda
 
黄金時代の創りかた〜持続的な成功が続く組織を創るには
黄金時代の創りかた〜持続的な成功が続く組織を創るには黄金時代の創りかた〜持続的な成功が続く組織を創るには
黄金時代の創りかた〜持続的な成功が続く組織を創るには
Haruo Sato
 
数字から読む犠打の頻度と有効性
数字から読む犠打の頻度と有効性数字から読む犠打の頻度と有効性
数字から読む犠打の頻度と有効性
Jun Sasaki
 
エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)
エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)
エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)
Hiroyuki Yamaoka
 
【cybozu conference 2015】nomizu 分科会
【cybozu conference 2015】nomizu 分科会【cybozu conference 2015】nomizu 分科会
【cybozu conference 2015】nomizu 分科会
Katsuya Nomizu
 
脆弱性もバグ、だからテストしよう DevSummiFukuoka
脆弱性もバグ、だからテストしよう DevSummiFukuoka脆弱性もバグ、だからテストしよう DevSummiFukuoka
脆弱性もバグ、だからテストしよう DevSummiFukuoka
ichikaway
 
スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態
Eiwa System Management, Inc.
 

Viewers also liked (20)

Python入門 コードリーディング - PyConJP2016
Python入門 コードリーディング - PyConJP2016Python入門 コードリーディング - PyConJP2016
Python入門 コードリーディング - PyConJP2016
 
Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!)
Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!) Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!)
Baseball Play Study 2017春(2017年春 読むべき野球本はこれだ!)
 
「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから「納品のない受託開発」とエンジニアの働きかたのこれから
「納品のない受託開発」とエンジニアの働きかたのこれから
 
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
 
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)3週連続DDDその2  深いモデルの探求(ドメイン駆動設計 第3部)
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第3部)
 
ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方ドメインオブジェクトの見つけ方・作り方・育て方
ドメインオブジェクトの見つけ方・作り方・育て方
 
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1  ドメイン駆動設計の基本を理解する3週連続DDDその1  ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
 
Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)
Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)
Pythonistaな私がChefからAnsibleに乗り換えた話(ひたすらゆるくプレゼンする会 2015/4/9)
 
Ant「ビルドできません」Travis「よし通れ」
Ant「ビルドできません」Travis「よし通れ」Ant「ビルドできません」Travis「よし通れ」
Ant「ビルドできません」Travis「よし通れ」
 
デブサミ 2016 19-C-6
デブサミ 2016 19-C-6デブサミ 2016 19-C-6
デブサミ 2016 19-C-6
 
The Zen_of ICHIRO
The Zen_of ICHIRO  The Zen_of ICHIRO
The Zen_of ICHIRO
 
勉強会で発表してみようかなという方へ(BPStudy)
勉強会で発表してみようかなという方へ(BPStudy)勉強会で発表してみようかなという方へ(BPStudy)
勉強会で発表してみようかなという方へ(BPStudy)
 
匠メソッドを導入したらサイトのアクセスが8倍になった話
匠メソッドを導入したらサイトのアクセスが8倍になった話匠メソッドを導入したらサイトのアクセスが8倍になった話
匠メソッドを導入したらサイトのアクセスが8倍になった話
 
モノを使うプログラミングが楽しかった話
モノを使うプログラミングが楽しかった話モノを使うプログラミングが楽しかった話
モノを使うプログラミングが楽しかった話
 
黄金時代の創りかた〜持続的な成功が続く組織を創るには
黄金時代の創りかた〜持続的な成功が続く組織を創るには黄金時代の創りかた〜持続的な成功が続く組織を創るには
黄金時代の創りかた〜持続的な成功が続く組織を創るには
 
数字から読む犠打の頻度と有効性
数字から読む犠打の頻度と有効性数字から読む犠打の頻度と有効性
数字から読む犠打の頻度と有効性
 
エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)
エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)
エンジニア×デザイナー GitHubで変わるコミュニケーション(PHPカンファレンス2014 P4Dセッション)
 
【cybozu conference 2015】nomizu 分科会
【cybozu conference 2015】nomizu 分科会【cybozu conference 2015】nomizu 分科会
【cybozu conference 2015】nomizu 分科会
 
脆弱性もバグ、だからテストしよう DevSummiFukuoka
脆弱性もバグ、だからテストしよう DevSummiFukuoka脆弱性もバグ、だからテストしよう DevSummiFukuoka
脆弱性もバグ、だからテストしよう DevSummiFukuoka
 
スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態スキニーなシステム開発にぴったりの契約形態
スキニーなシステム開発にぴったりの契約形態
 

Similar to エンジニアコミュニティで組織は動き出す

DevLove(20140124)
DevLove(20140124)DevLove(20140124)
DevLove(20140124)
Haruo Sato
 
20170222 商社セミナー 北村
20170222 商社セミナー 北村20170222 商社セミナー 北村
20170222 商社セミナー 北村
Seminer Goodfind
 
ET West 2012 P-1セッション
ET West 2012 P-1セッションET West 2012 P-1セッション
ET West 2012 P-1セッション
Naoya Maekawa
 
SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜
SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜
SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜
SORACOM,INC
 
全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり
全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり
全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり
Masakazu Matsushita
 
財務諸表で読み解く・業界分析講座 北村
財務諸表で読み解く・業界分析講座 北村財務諸表で読み解く・業界分析講座 北村
財務諸表で読み解く・業界分析講座 北村
Seminer Goodfind
 
エンジニアのキャリアを考える
エンジニアのキャリアを考えるエンジニアのキャリアを考える
エンジニアのキャリアを考える
MKT International Inc.
 
A20_リテールメディアという新しいデータ活用 〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...
A20_リテールメディアという新しいデータ活用  〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...A20_リテールメディアという新しいデータ活用  〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...
A20_リテールメディアという新しいデータ活用 〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...
日本マイクロソフト株式会社
 
目的を持って楽しく仕事をしよう Let's work with objectives happily
目的を持って楽しく仕事をしよう Let's work with objectives happily目的を持って楽しく仕事をしよう Let's work with objectives happily
目的を持って楽しく仕事をしよう Let's work with objectives happily
YOSHITSUGU MIYAZAKI
 
20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと
20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと
20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと
LIFULL Co., Ltd.
 
IBM WatsonでInnovationを
IBM WatsonでInnovationをIBM WatsonでInnovationを
IBM WatsonでInnovationを
Kenichi Inoue
 
Upwind Technology, Inc. Company Profile(Japanese)
Upwind Technology, Inc. Company Profile(Japanese)Upwind Technology, Inc. Company Profile(Japanese)
Upwind Technology, Inc. Company Profile(Japanese)Upwind Technology Inc.
 
20110808azumaism
20110808azumaism20110808azumaism
20110808azumaism
Kohsuke Shinkuma
 
近ごろサイボウズで流行ってる「敷居が低いLT」の話
近ごろサイボウズで流行ってる「敷居が低いLT」の話近ごろサイボウズで流行ってる「敷居が低いLT」の話
近ごろサイボウズで流行ってる「敷居が低いLT」の話
Ko Kazaana
 
開発者からサポートエンジニアにジョブチェンジした話
開発者からサポートエンジニアにジョブチェンジした話開発者からサポートエンジニアにジョブチェンジした話
開発者からサポートエンジニアにジョブチェンジした話
Ito Takayuki
 
OSSではじめる働き方改革
OSSではじめる働き方改革OSSではじめる働き方改革
OSSではじめる働き方改革
Seiya Shimabukuro
 
どうなるIo t ! エキスパートと徹底討論 part2
どうなるIo t ! エキスパートと徹底討論 part2どうなるIo t ! エキスパートと徹底討論 part2
どうなるIo t ! エキスパートと徹底討論 part2
Naoya Maekawa
 
JEPA2017年年末イベントパネルディスカッション資料
JEPA2017年年末イベントパネルディスカッション資料JEPA2017年年末イベントパネルディスカッション資料
JEPA2017年年末イベントパネルディスカッション資料
馮 富久
 
Android IoTとプログラミング教育
Android IoTとプログラミング教育Android IoTとプログラミング教育
Android IoTとプログラミング教育
Kenichi Yoshida
 
【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾
【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾
【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾
schoowebcampus
 

Similar to エンジニアコミュニティで組織は動き出す (20)

DevLove(20140124)
DevLove(20140124)DevLove(20140124)
DevLove(20140124)
 
20170222 商社セミナー 北村
20170222 商社セミナー 北村20170222 商社セミナー 北村
20170222 商社セミナー 北村
 
ET West 2012 P-1セッション
ET West 2012 P-1セッションET West 2012 P-1セッション
ET West 2012 P-1セッション
 
SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜
SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜
SORACOM Conference "Discovery" 2018 | E1. Wioで始めるIoTプロトタイプ開発 〜実践事例のご紹介〜
 
全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり
全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり
全世界6,500万DL突破!ヒットゲームを作り上げたチームの道のり
 
財務諸表で読み解く・業界分析講座 北村
財務諸表で読み解く・業界分析講座 北村財務諸表で読み解く・業界分析講座 北村
財務諸表で読み解く・業界分析講座 北村
 
エンジニアのキャリアを考える
エンジニアのキャリアを考えるエンジニアのキャリアを考える
エンジニアのキャリアを考える
 
A20_リテールメディアという新しいデータ活用 〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...
A20_リテールメディアという新しいデータ活用  〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...A20_リテールメディアという新しいデータ活用  〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...
A20_リテールメディアという新しいデータ活用 〜 ポスト Cookie 時代のブランドメーカーのデジタル戦略 〜 [Microsoft Japan D...
 
目的を持って楽しく仕事をしよう Let's work with objectives happily
目的を持って楽しく仕事をしよう Let's work with objectives happily目的を持って楽しく仕事をしよう Let's work with objectives happily
目的を持って楽しく仕事をしよう Let's work with objectives happily
 
20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと
20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと
20220319_新卒から活躍し続けるエンジニアが大切にしている5つのこと
 
IBM WatsonでInnovationを
IBM WatsonでInnovationをIBM WatsonでInnovationを
IBM WatsonでInnovationを
 
Upwind Technology, Inc. Company Profile(Japanese)
Upwind Technology, Inc. Company Profile(Japanese)Upwind Technology, Inc. Company Profile(Japanese)
Upwind Technology, Inc. Company Profile(Japanese)
 
20110808azumaism
20110808azumaism20110808azumaism
20110808azumaism
 
近ごろサイボウズで流行ってる「敷居が低いLT」の話
近ごろサイボウズで流行ってる「敷居が低いLT」の話近ごろサイボウズで流行ってる「敷居が低いLT」の話
近ごろサイボウズで流行ってる「敷居が低いLT」の話
 
開発者からサポートエンジニアにジョブチェンジした話
開発者からサポートエンジニアにジョブチェンジした話開発者からサポートエンジニアにジョブチェンジした話
開発者からサポートエンジニアにジョブチェンジした話
 
OSSではじめる働き方改革
OSSではじめる働き方改革OSSではじめる働き方改革
OSSではじめる働き方改革
 
どうなるIo t ! エキスパートと徹底討論 part2
どうなるIo t ! エキスパートと徹底討論 part2どうなるIo t ! エキスパートと徹底討論 part2
どうなるIo t ! エキスパートと徹底討論 part2
 
JEPA2017年年末イベントパネルディスカッション資料
JEPA2017年年末イベントパネルディスカッション資料JEPA2017年年末イベントパネルディスカッション資料
JEPA2017年年末イベントパネルディスカッション資料
 
Android IoTとプログラミング教育
Android IoTとプログラミング教育Android IoTとプログラミング教育
Android IoTとプログラミング教育
 
【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾
【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾
【公開取材】ジャーナリスト・林信行さんに聞く、「iPhone、iPadが次にコネクトする世界」とは? 先生:伊藤 健吾
 

More from Haruo Sato

私の積読解消法
私の積読解消法私の積読解消法
私の積読解消法
Haruo Sato
 
将棋を上達しようとおもった2つのショックと上達の取り組み
将棋を上達しようとおもった2つのショックと上達の取り組み将棋を上達しようとおもった2つのショックと上達の取り組み
将棋を上達しようとおもった2つのショックと上達の取り組み
Haruo Sato
 
炎上ドラゴンズ!与田剛監督に2019年への提言
炎上ドラゴンズ!与田剛監督に2019年への提言炎上ドラゴンズ!与田剛監督に2019年への提言
炎上ドラゴンズ!与田剛監督に2019年への提言
Haruo Sato
 
自社サービスプロジェクトから学んだ事業開発の進め方
自社サービスプロジェクトから学んだ事業開発の進め方自社サービスプロジェクトから学んだ事業開発の進め方
自社サービスプロジェクトから学んだ事業開発の進め方
Haruo Sato
 
はてなブックマーク2000を獲得した一生役立つ3冊のライティング本
はてなブックマーク2000を獲得した一生役立つ3冊のライティング本はてなブックマーク2000を獲得した一生役立つ3冊のライティング本
はてなブックマーク2000を獲得した一生役立つ3冊のライティング本
Haruo Sato
 
Pythonの10年と今、これから
Pythonの10年と今、これからPythonの10年と今、これから
Pythonの10年と今、これから
Haruo Sato
 
ビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のり
ビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のりビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のり
ビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のり
Haruo Sato
 
カイゼン・ジャーニーとお金のおいしい関係
カイゼン・ジャーニーとお金のおいしい関係カイゼン・ジャーニーとお金のおいしい関係
カイゼン・ジャーニーとお金のおいしい関係
Haruo Sato
 
匠Methodを学んで 私のここが変わった
匠Methodを学んで 私のここが変わった匠Methodを学んで 私のここが変わった
匠Methodを学んで 私のここが変わった
Haruo Sato
 
IT勉強会支援プラットフォームconnpassからみた IoT
IT勉強会支援プラットフォームconnpassからみた IoTIT勉強会支援プラットフォームconnpassからみた IoT
IT勉強会支援プラットフォームconnpassからみた IoT
Haruo Sato
 
松坂大輔物語
松坂大輔物語松坂大輔物語
松坂大輔物語
Haruo Sato
 
良いルール・悪いルール
良いルール・悪いルール良いルール・悪いルール
良いルール・悪いルール
Haruo Sato
 
35億!とんでもないところへ行くただひとつの道
35億!とんでもないところへ行くただひとつの道35億!とんでもないところへ行くただひとつの道
35億!とんでもないところへ行くただひとつの道
Haruo Sato
 
一生役立つ3つのライティング本
一生役立つ3つのライティング本一生役立つ3つのライティング本
一生役立つ3つのライティング本
Haruo Sato
 
プログラミングを学ぶと何が良いのか
プログラミングを学ぶと何が良いのかプログラミングを学ぶと何が良いのか
プログラミングを学ぶと何が良いのか
Haruo Sato
 
Pythonの会社を
9年間経営してきて分かったこと
Pythonの会社を
9年間経営してきて分かったことPythonの会社を
9年間経営してきて分かったこと
Pythonの会社を
9年間経営してきて分かったこと
Haruo Sato
 
BPStudy#116(PyQ開発秘話)
BPStudy#116(PyQ開発秘話) BPStudy#116(PyQ開発秘話)
BPStudy#116(PyQ開発秘話)
Haruo Sato
 
connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017
connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017
connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017
Haruo Sato
 

More from Haruo Sato (18)

私の積読解消法
私の積読解消法私の積読解消法
私の積読解消法
 
将棋を上達しようとおもった2つのショックと上達の取り組み
将棋を上達しようとおもった2つのショックと上達の取り組み将棋を上達しようとおもった2つのショックと上達の取り組み
将棋を上達しようとおもった2つのショックと上達の取り組み
 
炎上ドラゴンズ!与田剛監督に2019年への提言
炎上ドラゴンズ!与田剛監督に2019年への提言炎上ドラゴンズ!与田剛監督に2019年への提言
炎上ドラゴンズ!与田剛監督に2019年への提言
 
自社サービスプロジェクトから学んだ事業開発の進め方
自社サービスプロジェクトから学んだ事業開発の進め方自社サービスプロジェクトから学んだ事業開発の進め方
自社サービスプロジェクトから学んだ事業開発の進め方
 
はてなブックマーク2000を獲得した一生役立つ3冊のライティング本
はてなブックマーク2000を獲得した一生役立つ3冊のライティング本はてなブックマーク2000を獲得した一生役立つ3冊のライティング本
はてなブックマーク2000を獲得した一生役立つ3冊のライティング本
 
Pythonの10年と今、これから
Pythonの10年と今、これからPythonの10年と今、これから
Pythonの10年と今、これから
 
ビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のり
ビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のりビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のり
ビープラウドの紹介と渋谷区千駄ヶ谷5-32-7に漂着するまでの道のり
 
カイゼン・ジャーニーとお金のおいしい関係
カイゼン・ジャーニーとお金のおいしい関係カイゼン・ジャーニーとお金のおいしい関係
カイゼン・ジャーニーとお金のおいしい関係
 
匠Methodを学んで 私のここが変わった
匠Methodを学んで 私のここが変わった匠Methodを学んで 私のここが変わった
匠Methodを学んで 私のここが変わった
 
IT勉強会支援プラットフォームconnpassからみた IoT
IT勉強会支援プラットフォームconnpassからみた IoTIT勉強会支援プラットフォームconnpassからみた IoT
IT勉強会支援プラットフォームconnpassからみた IoT
 
松坂大輔物語
松坂大輔物語松坂大輔物語
松坂大輔物語
 
良いルール・悪いルール
良いルール・悪いルール良いルール・悪いルール
良いルール・悪いルール
 
35億!とんでもないところへ行くただひとつの道
35億!とんでもないところへ行くただひとつの道35億!とんでもないところへ行くただひとつの道
35億!とんでもないところへ行くただひとつの道
 
一生役立つ3つのライティング本
一生役立つ3つのライティング本一生役立つ3つのライティング本
一生役立つ3つのライティング本
 
プログラミングを学ぶと何が良いのか
プログラミングを学ぶと何が良いのかプログラミングを学ぶと何が良いのか
プログラミングを学ぶと何が良いのか
 
Pythonの会社を
9年間経営してきて分かったこと
Pythonの会社を
9年間経営してきて分かったことPythonの会社を
9年間経営してきて分かったこと
Pythonの会社を
9年間経営してきて分かったこと
 
BPStudy#116(PyQ開発秘話)
BPStudy#116(PyQ開発秘話) BPStudy#116(PyQ開発秘話)
BPStudy#116(PyQ開発秘話)
 
connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017
connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017
connpass運営が選ぶこのコミュニティがすごい〜コミュニティマネージャーSummit2017
 

エンジニアコミュニティで組織は動き出す

Editor's Notes

  1. 本日お話しする内容の全体像を先にお伝えします。Pythonを開発のメイン言語に採用したのは、2008年4月でした。その後、Pythonの採用をきっかけに会社は大きく変化して行きました。その変化の中で見えて来た、エンジニアが活躍するこれからの時代の会社、未来の会社はどのようなものになるかということでした。 これについて組織運営、エンジニアのありかた、そして、組織とエンジニアの関係という3つの観点からお話しします。 私はエンジニアであり、かつ経営者ですが、その立場から本日はお話しし、皆さんの今後にお役に立てることが1つでもあればとおもいます。
  2. まず、そもそも、なぜ、私が会社をつくったのかという理由について最初にお話しします。会社をつくる前は、私はフリーランスのプログラマでした。 私がその頃に感じていたことですが、一般的な会社では企画や営業の人がエンジニアより立場が上という感じだったと思います。エンジニアの給料も低かったとおもいます。そのような状況で、私は「エンジニアが活躍し、幸せになれる会社はどのような会社なのだろうか」ということをいつも考えていました。そして、そのような会社が無いなら、自分でこれからの時代の会社をつくろうと決心したのがきっかけです。
  3. このような状況で、私は「エンジニアが活躍し、幸せになれる会社はどのような会社なのだろうか」ということをいつも考えていました。そして、そのような会社が無いなら、自分でこれからの時代の会社をつくろうと決心したのがきっかけです。
  4. 2006年の5月に会社を立ち上げ、2008年の3月までの約2年間はJavaやperlで開発していました。そこを2008年4月に会社のメイン言語をPythonにすることに決めて、社内で発表しました。その当時、社員は私を含めて4人。Pythonでの開発実績は0件でした。
  5. 次に、私がPythonを採用した理由です。たしかにPythonの開発生産性の高さ、保守性の高さなどの技術的メリットというのも選択理由としてはありました。しかし、本当の理由は、これからの時代の会社をつくっていくためのエンジニアを採用したいということでした。JavaやPHPのエンジニアを採用しようとすると、どうしても大手会社との争いになります。そうなると採用のための資金量ではかないません。一方、Pythonは個人で使っている人は多い印象でしたが、仕事で使っている人は少ないという印象を私は持っていました。そこで、会社でPythonを言語として使うようにすれば、大手の会社と競争にならずに、良いエンジニアが来てくれるのではないかと考えました。
  6. Pythonを採用した結果どうなったか。まず、2008年4月にPythonを採用することをTwitterでひっそりと宣言しました。4人程度の小さな会社なので、特に何もないだろうと思ってたのですが、2か月後に、Python温泉というコミュニティから、エンジニアが1人紹介されました。彼は今でもうちの会社で仕事をしています。その後も、2008年には2人、翌年には10人と次々と、Python界隈のエンジニアが入社することになりました。
  7. Pythonを採用したことにより、どのようなひとたちが集まって来たのでしょうか。
  8. ひとことでいうと「変わった人たち」です。私が期待していた通り、変わった人たちが集まってきました。
  9. どれくらい変わっているか?というと、休みやプライベートの時間を使って、家族を説得してまで、Pythonの勉強をしたり、ハッカソンで集まってプログラミングをしているような人たちです。
  10. 私がたびたび、質問されることがあります。 個性が強いエンジニアをどのように束ねるのか?ということです。
  11. 私の答えは「束ねない」です。それはなぜかというと、私には束ねることができないからです。 束ねることができないので、彼らが望むような会社はどのような会社なのだろうということに目線が変わって行きました。そうすると、次第に会社が変化して行くのがわかりました。
  12. Pythonを採用したことにより、会社に起こった変化について2点お話しします。
  13. 会社におこった変化の1つ目です。Pythonを採用したことにより、Pythonを好きな人たちが集まりました。必然的にPythonのコミュニティに会社が変わっていったわけです。
  14. 会社がPythonコミュニティになったおかげで、いろいろな効果が会社に生まれました。ここでは3つあげました。 1つ目は、同じことに共感し、感動できるということ。Pythonという同じことに興味をもっていますので、例えば、何かのソフトウェアがリリースされたとか良いツールがあるという話を、誰かが始めた時に、周りの人もそれに対して「おーすごい」とか、一緒に共感するようになります。これが、Pythonを使わない人が、Pythonの話を聞いても「へぇ」くらいの反応で、共感したりすることが少ないと思います。そのように、興味が同じ人が集まると、自分が知った新しい情報を共有しあうので、社内に情報が集まるようになります。 2つ目が、ベースの価値観が一致しているということです。Pythonには、コードの読みやすさ、わかりやすさを重視するような価値観、シンプルさの追求やzen of python という思想があります。その思想はプログラミングに限らず仕事に通じる価値観があります。それらの価値観が一致していることで、合意の形成や意思決定が速くなったとおもいます。 3つ目が、ドキュメントを積極的に書こうという人が多いということです。これは、Pythonは標準ドキュメントが充実していたり、Sphinxという素晴らしいツールがあったりするので、その恩恵を受けている人が多く、ドキュメントを書こうという意志のある人が、pythonistaには多いのかなと想像しています。ドキュメントを積極的に書こうという人が多いので、社内では、暗黙知の共有化、そして暗黙知の形式知化が促進されたとおもいます。
  15. 会社に起こった変化の2つ目です。それは、会社の運営がオープンソース・コミュニティ型に変わって行ったということです。集まって来た多くのエンジニアは、オープンソースを使って恩恵を受けていたり、コミュニティに参加していたり、自分がコントリビューターとして活動していたりして、日頃からなんらかのかたちでオープンソースに関わっている人たちでした。したがって、オープンソース・コミュニティで行われている組織運営方法が、自然に会社に採用されたのかと思います。詳しい内容は、のちほど説明致します。
  16. 私が経営者として、Pythonを採用し、会社が変化して行く中で、見えて来たものがありました。
  17. 冒頭で申し上げたことですが、私が会社をつくった理由は「これからの時代の会社をつくりたい」ということでした。工業が中心の工業社会では、階層型、上意下達の組織形態で、働き手はブルーワーカーと呼ばれるひとたちです。ピーター・ドラッカーのいう、知識社会では、エンジニアなどのナレッジーワーカーが主な働き手となります。皆さんのようなエンジニア、ナレッジワーカーがのびのびと創造性を発揮し、価値を創り出すためには、工業社会の焼き直しのような組織ではなく、知識社会のための組織が必要になります。現時点ではその過渡期であり、知識社会の組織が、どのような組織であるべきかを模索している段階なのではないでしょうか。Pythonを採用し、会社が変化して行く中で私に見えて来たものは、知識社会の会社、これからの時代の会社、未来の会社は、エンジニア・コミュニティのような会社になるだろうというものです。
  18. エンジニア・コミュニティとは、オープンソースのコミュニティであったり、今回のPyConや、さまざまなMeetup などのようにエンジニアが中心となって活動しているオープンなコミュニティをイメージして頂ければと思います。 みなさんご存知のように、ソフトウェアや、ドキュメント、人のつながりなど、さまざまな価値を生み出しているコミュニティです。
  19. 知識社会の会社、未来の会社がどうあるべきかということについて、エンジニアコミュニティのような組織になるだろうとお伝えしました。 これについて、組織運営、エンジニアのありかた、組織とエンジニアの関係のありかたという3つの観点からお話ししたいと思います。
  20. 組織運営については、2つお話しします。 1つ目は、会社はコミュニティであるということ。 2つ目は、オープンソース・コミュニティ型運営から学ぼう ということをお話しします。
  21. コミュニティとは、同じことに興味をもった人たちの集まりです。 同じことに興味をもっているので、同じことに共感し、感動することができます。そのような日頃の会話の中から個人が持っている暗黙知が共有されやすくなり、組織内の学習や情報共有につながります。そのような切磋琢磨の結果、会社の知識レベルはあがり、その知識を事業に活かせるようになります。それがひいては会社のブランド化にもつながっていくこともあります。ここはポイントなのですが、コミュニティの興味の対象、ジャンルは、なんでも良いわけではなくて、会社の事業に関係するものがよいとおもいます。たとえば、会社のみんながラーメンが大好きだとします。毎日毎日、仕事中にラーメンについて活発に議論したからといって、会社の直接の成果には、つながりにくいとおもいます。うちの会社の場合は、Pythonを好きな人たちが集まったおかげで、書籍出版にもつながり、さらにはその書籍出版が会社のブランドにまでつながっていきました。そのようなコミュニティを活発化するために、会社として重要なのは、仕事中の雑談の積極的な奨励と、社内勉強会など、場作りだと思います。それによって、社員同士の知識や情報が自然と共有されていくことになります。私の会社の場合は、オンライン上での雑談がとても活発です。
  22. 組織運営の2つ目は「オープンソース・コミュニティから学ぼう」ということについてお話しします。1983年にリチャード・ストールマンがGNU(グニュー)プロジェクトを始めて、フリーソフトウェアの重要性を訴え、多くの人の支持を受けました。その後、1990年代にオープンソースのムーブメントが起こります。そして、インターネットの発展とともに、世界の多くの人がオープンソースプロジェクトに参加するようになりました。それにつれて、オープンソースプロジェクトもコミュニティとなり、組織運営、コミュニティ運営というものが必要になりました。オープンソースプロジェクトの参加者は、ほとんどがボランティアで隙間時間に成果を創り出していますので、その運営には効率性が求められます。また、オープンソースというくらいですから、オープンな運営、風通しの良さが求められます。こうして、経営者や経営学者ではなく、エンジニアたちが創意工夫して培って来たオープンソース・コミュニティの運営ノウハウが、エンジニアが活躍するこれからの会社、知識社会の会社にも有用であるというのが私の考えです。
  23. オープンソースから学ぼうということで、具体的には、フラットな組織、コミュニティ評議会、コミュニケーションという3点についてお話しします。
  24. まずは、フラットな組織ということについてお話しします。 ここでは、単純に、階層型か、フラット型か、の2形態に絞ってお話しします。
  25. まずは階層型組織についてお話しします。まず、階層型の特徴として、組織を管理しやすいということがあげられます。 2つ目は官僚制。官僚制では、管理のためのルールが組織内につくられていきます。3つ目が、情報が階層間で滞りやすいというものです。情報が滞りますので、意思決定のスピードがどうしても落ちるということが特徴としてあげられます。4つ目が、どうしても出世に目が行くということです。階層型組織では、たいていの場合、組織の階層をあがっていけば、昇進で給料があがります。社内での昇進を考えるとどうしても社内に目が向いてしまい、社外にどのような価値をもたらすのかという意識がおろそかになりがちです。 階層型のメリットは、管理しやすいので、うまく回れば、組織の上の人は楽ということです。 デメリットは、管理されたり、社内に目が向いているうちに、創造性の源である、個人の内発的動機、自尊心、好奇心が失われ、個人の創造性がなくなってしまう恐れがあるということです。
  26. 次に、フラット型組織の特徴についてお話しします。 フラット型組織は、オープンソースのコミュニティのような組織をイメージしてください。オープンソースのコミュニティで、階層型組織というのは考えられないとおもいます。フラット型組織では、プロジェクトなど、なにか目的が生まれたらそのたびにチームをつくり、都度メンバーが果たすべき役割を決めて行きます。そして、管理のためのルールは最低限。ここでつくられるルールも仕事をスムーズに進めるためのルールです。また、階層とセクションがありませんので、情報が行き渡りやすいという特徴もあります。また、組織の階層を昇って行く必要がありませんので、出世も気にする必要はありません。これらのようにフラット型組織をつくることで、エンジニアは余計なことを考えず、のびのびと考えられるようになります。それにより、エンジニアが価値を創り出すことに集中できるようになるのではないかとおもいます。デメリットとしては、組織の管理が難しいということです。
  27. さきほど、フラット型組織のデメリットとして、管理が難しいという話をしました。 フラット型組織は、管理が無いので大丈夫なのか?組織が崩壊するのではという疑問をもたれた方もいらっしゃるかもしれません。 フラット型組織で、大事なのは、個人個人のセルフマネジメントと、お互いの信頼関係です。個人が自律的に動くということです。また、誰かが誰かを管理するという関係性をつくらないようにすることも重要となってきます。 それにより、組織にかかる様々なコストを削減できます。様々なコストとは管理するコスト、管理されるコスト、コミュニケーションコストなどです。そのコストを本来やるべき、「価値を創り出す」ということにより使うことができるのです。
  28. 会社の経営は、コミュニティの運営であると定義すると経営者はコミュニティのリーダーということなります。 オープンソースのコミュニティで、リーダーが偉いということはないとおもいます。 それはただの役割でしかありません。つまり、経営者も偉いひとではないということです。経営者は権力ではなく、役割であるということです。 組織のリーダーにとって重要なこと。それは権力ではなく、リーダーという役割を果たせるだけの良い人格をもつということだと私は思っています。
  29. 次に、コミュニティ評議会ということをお話しします。
  30. コミュニティ評議会とは、「アートオブコミュニティ」という書籍に書かれている概念です。 コミュニティ評議会とは、コミュニティ全体を運営する役割を持つグループです。 課題がある場合に、その課題は、評議会に提出され、提出された課題について評議会で議論し、方針を決定します。
  31. 私の会社では、このコミュニティ評議会に該当するものを運営しています。それは、「BP(ビーピー)カイゼン」という取り組みです。この取り組みの目的は会社を改善することです。どのように運営しているかというと、月2回、1時間のミーティングを開催し、社内誰でも参加できます。redmineで会社の課題を管理し、課題がある場合はチケットを作成します。 議事録は全社員に公開し、すべてオープンなプロセスで課題の解決方法が決定されていきます。
  32. 「BP(ビーピー)カイゼン」から生まれた制度について1つ紹介します。 それはBPRD2.0、BeProud Remote Dayという制度です。どのような制度かというと、週5日間、つまり全ての日に関していつでもリモートで勤務可能というものです。名前に2.0とついているのは、もともと週1日はリモートで勤務可能というものが、さらに拡大されたからです。この制度は、BPカイゼンで、社員からアイデアが出され、実現しました。自分たちでつくった制度なので、アンケートをとったり、ツールをつくったりして制度をうまく運用できるように、みんなで工夫をしています。
  33. コミュニティ評議会を置くメリットですが、私は2点あると考えています。 1つ目は、自分たちで制度を提案して、自分たちで育てて行くことができるということです。これによって、会社を自分たちでよくしていこうという当事者意識や参加意識が生まれてくるという効果があります。2つ目は、決定プロセスがすべてオープンなので、風通しがよいということです。これによって、会社全体に公正感が生まれてくるという効果が期待できます。
  34. 3点目は、コミュニケーションです。
  35. オープンソース・コミュニティのコミュニケーション手段は、メーリングリスト、ITS、チャット、ビデオ通話、時には直接のミーティングなどが使われているとおもいます。 これは、オープンソース・コミュニティは、時間やリソース、場所などの制約が多いため、 自然にさまざまな手段を使って、隙間時間で、成果を出すための工夫です。
  36. コミュニケーションについての弊社での取り組みを紹介します。 時間やリソース、場所などの制約が多いのは会社も同じです。これらが充分にあるという企業はほとんどなさそうです。そこで弊社では、リモートワークの体制作りによって、時間、リソース、場所の制約を超えようとする取り組みをしています。時間については、リモートワークにより通勤時間の削減が期待できます。 場所とリソースについては、リモートワークによって、家庭事情などで会社に来れない人も仕事ができるようになります。 例えば奥さんが出産するという場合に、地方の奥さんの実家に一緒に戻り、そこから仕事をするというような場合です。 そのために、SlackやGoogle hangout、Google Drive、DropBox、redmineなどさまざまなツールを活用してリモートワークを推進しています。
  37. リモートワークの話をすると出てくる疑問が、リモートワークはチームでのクリエイティブな仕事に向かないのではないか?ということです
  38. その疑問に対する私の考えをお伝えします。 何かを創り出すときにはアイデアを生み出すプロセスと、実際につくるプロセスがあります。 そのアイデアを生み出すプロセスと、つくるプロセスをしっかりと分けるように段取りをすれば、必ずしも全ての時間を同じ場所で顔を合わせて仕事をする必要がないというのが私の考えです。このプロセスを意識し、仕事の段取りをしっかりすれば、リモートワークでもクリエイティブなチームの仕事は可能ということです。
  39. 「知識社会の会社、未来の会社とは」ということで、組織の次は、エンジニアのありかたというお話をしたいとおもいます。
  40. 組織運営については、2つお話しします。 1つ目は、会社はコミュニティであるということ。 2つ目は、オープンソース・コミュニティ型運営から学ぼう ということをお話しします。
  41. オープンソースのContributorをイメージしてみると、3つ特徴が思い浮かびます。 1点目が社会にもたらす価値に目を向けている。どのようなソフトウェアが世界に役立ち、使われるのかを常に考えているということです。 2点目は、自らがつくるソフトウェアに対してのアイデアをもっているということです。3点目がコミュニティの活動に自発的に参加しているということです。このようにオープンソースのContributorは、主体的に価値を創り出そうとしている、創造的なエンジニアであるということが言えるのではないでしょうか。
  42. エンジニアのありかたについての私のメッセージは、「創造的なエンジニアになろう」ということです。 みなさんは、Pythonという素晴らしいプログラミング言語や、サードパーティー製のの充実したライブラリをつかって、さまざまなソフトウェアをつくりだすことができます。 従って、みなさんが価値あるものを創り出せるかどうかは、みなさんがいかに創造的になれるかどうかということにかかっていると私は思います。 創造的なエンジニアとは、自ら主体的になって価値を創り出そうとするエンジニアのことです。
  43. では、創造的なエンジニアになるにはどのようにしたら良いかというお話をします。 ここでは、創造的になるための、3つの方法を紹介したいと思います。 それは、不安を乗り越え、主体的になる、技術に感動する習慣をもつ、価値を創り出すプロセスを学ぶの3つです。
  44. 1つ目は「不安を乗り越え、主体的になる」です。
  45. 創造的になる最大の敵はなんでしょうか。それは不安と恐怖です。 仕事における不安、恐怖とは”できなかったらどうしよう”、”できなかったらクビになる”という自らの感情です。不安や恐怖に怯えてしまうと、自分の外からの刺激に反応することに意識が向いてしまうので、主体性を失ってディフェンシブな思考になってしまいます。そうなると人は、創造性を失ってしまいます。
  46. では、不安を乗り越えるにはどうしたらよいでしょうか。 そのための方法として、2つお話しします。 1つ目は、「技術を身につける」、2つ目は、「今を生きる」ということです。
  47. 不安を乗り越える方法の1つ目は「技術を身につける」です。 不安が生まれる原因の1つに「自信がない」ということが上げられます。なぜ、自信がないかというと、技術がないからというのが一番大きな原因ではないでしょうか。逆にいうと、技術を身につけると、自信がつき、次第に心が安定し、強くなっていくということが考えられます。 このように考えると、創造的なエンジニアになるには、自分に自信がつくまで、技術を徹底的に身につけるというのが重要ではないでしょうか。
  48. しかし、技術を身につけるといっても技術はすぐに身に付かないです。そのため、すぐにできる方法をお話しします。それは「今を生きる」ということです。開発プロジェクトでは、納期や品質などさまざまなものが求められます。そのため、エンジニアには「できなかったらどうしよう」という不安や恐怖が生まれてきます。その不安や恐怖にかられて仕事をしていると、集中して仕事ができずに、結果的に成果がでないということになりがちです。
  49. そのようなことにならないためには、求められる結果に、まず付箋紙を貼ってしまいます。一旦忘れてしまって頭の片隅に置く程度にしてしまいます。そしてプログラミングという行為そのものに打ち込む、楽しむということに専念します。 プログラミングが楽しいという気持ちで仕事をすると、集中できるようになります。 集中してものごとに取り組むと、結果的に成果につながります。 このように集中して取り組んでいる状態をフロー状態と言って、心理学では、人が仕事をする上では、理想的な状態と言われています。
  50. 創造的なエンジニアになる方法の2つ目として、「技術に感動する習慣をもつ」ということをお話します。
  51. プログラミングを始めた当初は、自分がつくったプログラムが動くと「おー、動いた!」とか、何かの技術やライブラリ、ツールを使った時に「この技術は便利だ!」と感動していたとおもいます。それが、だんだん経験を積んでくると、「動いて当たり前」「その技術は想定の範囲内、目新しくない」というように考えてしまいます。
  52. 何かに感動すると、その感動した対象に対して、人は好奇心が湧いてきます。好奇心がわくと、その対象についてもっと知りたいという探究心が生まれてきます。その探究心が新しいものを創り出すことにつながります。 感動は、その感動した対象への記憶を強くするという効果もあります。記憶は記憶同士が結びついて、アイデアとなるので、それが創造につながります。 何が言いたいかというと、感動する習慣をもつと、創造的なエンジニアになれるということです。逆に考えると、感動が少ない人は、好奇心も薄れて、記憶力も弱まるので創造性を失い、エンジニアとして退化していくことになります。 「子供のような好奇心、あるいは冒険心があって初めて、新しいものを生み出す力が生まれてくるのです。」これは、amazon創業者のジェフベゾスの言葉です。
  53. 創造的なエンジニアになる方法の3つ目として「価値を創り出すプロセスを学ぶ」ということをお話したいと思います。
  54. 「知識社会、未来の会社とは」ということで、組織、エンジニアとお話ししましたので、次は、組織とエンジニアの関係についてお話しします。
  55. 組織とエンジニアの関係についての私のメッセージは、「オープンソースのContributorのように仕事をしよう」ということです。通常、会社とエンジニアのあいだでは雇用契約が結ばれていて、仕事もあらかじめ契約で定められていることもしばしばあります。しかし、そのような関係を重視しすぎると、契約で決められたことだけをやるということになり、創造的なものを生み出す仕事はできなくなってしまいます。その一方で、オープンソースのContributorは、コミュニティの中で、自分の強みや興味を活かして、自分が貢献できることをみつけて仕事をするということをしています。 オープンソース・コミュニティと同じように、会社という組織でも、さまざまな役割があります。会社においても、オープンソースのContributorのように、エンジニアが自分の強みや興味をもとに、社内で果たせる役割をみつけて、貢献するという仕事のスタイルが良いのではないかというのが私の考えです。貢献という言葉がキーワードになります。それにより、やらされる仕事から、自分で貢献できる仕事を主体的に見つけて行くというスタンスに変わっていきます。
  56. そのような会社とエンジニアの関係のときに、報酬は何に対して支払うべきかということをお話しします。私の答えは、果たしてくれた役割に対して、報酬を支払うということです。そうすれば、エンジニアは自分が果たせる役割は何かという視点を持つようになり、主体的に貢献するようになります。会社でよくある報酬の支払いとして、役職に対して報酬を支払うということがありますが、これですと、仕事をせず、偉いだけの人に多くのお金を支払うことになり、不公平となります。組織を活性化させるためのポイントは、役割に対して報酬を支払うということです。
  57. 組織とエンジニアの関係について、もう1点お話しします。 それは、エンジニアと組織はお互いに協力して、シナジーを生み出す関係であるということです。 エンジニアは自分の強みと興味で組織に貢献する。会社は、エンジニアが自発的に参加したくなるような組織作りをする。会社は、価値を創造するためのインフラになることです。そのようにお互いが創造的でシナジーを生み出せる関係になることがポイントであると私は思っています。