エンジニアコミュニティで組織は動き出す 2nd Edition(BPStudy#98)

エンジニアコミュニティで組織は動き出す 2nd Edition(BPStudy#98)

1. 1. エンジニア・コミュニティで 組織は動き出す ２nd Edition 株式会社ビープラウド 佐藤治夫 2015/10/27 BPStudy#98
2. 2. スライド（６４枚） スライド（９４枚） ユニフォームPyCon JP Tシャツ （お願い）
 正装姿の写真を#bpstudy でTwitter/FBにアップ協力 お願いします 2nd Edition について ©PyCon JP 2015
3. 3. 自己紹介 • 佐藤治夫（Sato Haruo） • Be Proud Inc. 代表取締役社長
 2006年5月23日設立 • Webの受託開発がメイン事業 • connpass 企画・開発・運営 • Python Professional Programming
 第1版 2012年3月、第2版 2015年2月 上梓 • BPStudy、懇親会98回連続参加中
4. 4. テーマ 未来の会社  1.組織  2. エンジニア  3.組織とエンジニア Pythonを会社のメイン言語に採用（2008年4月） ↓ 会社が大きく変化 ↓ 変化の中で見えて来たもの エンジニアが活躍する未来の会社はどうあるべきか
5. 5. 私が会社をつくった当時のエンジニア 2006年当時 ・当時の私 = プログラマ / フリーランス ・世の中
  ・企画/営業の人が組織で上  ・エンジニアの給料は低かった
6. 6. 「（Seasar2がつくられた）当時は，今ほど技術があることに 重きが置かれていませんでした。
 つまり，技術力のある人が会社の中に埋もれていた時代，プ ログラマへのフォーカスが外れていた時代，実装に落とすこ とだけが求められており，すごい技術や新しいことが求めら れていなかったように思います。」 2004∼2006年頃 http://gihyo.jp/news/report/2015/10/2701 「さよならSeasar，最後の!? Seasar Conference開催」 私が会社をつくった当時のエンジニア 比嘉康雄さん
7. 7. そもそも私が会社をつくった理由 エンジニアが活躍し、幸せになれる会社 はどのような会社であろうか？
 ↓ 「これからの時代の会社」を自分がつくろう
8. 8. Pythonの採用 2006年5月∼2008年3月 主に Java、perlで開発 ! ↓ ! 2008年3月、会社のメイン言語をPythonに決定  ・会社のメンバー4人（役員含む）
  ・Pythonによる開発実績は0件
9. 9. Pythonを採用した理由 「これからの時代の会社」を
    つくっていくエンジニアを採用したい ↓ Java、PHPのエンジニアは大手会社との争いになる
 → 資金量でかなわない ↓ Pythonは個人で使っている人は多いが、仕事で使っている人は 当時少なかった ↓ Pythonで仕事ができるようにすれば、大手会社と競争になら ず、良いエンジニアが来てくれるのではないか
10. 10. 目をつけたのは技術よりも人 ・仕事で使う機会が少ないのに自ら学ぶ技術への意欲 ! ・複数言語を知っていてバランス感覚が良い ! ・自ら技術を選択する主体性
11. 11. Pythonを採用した結果 2008年4月、Pythonを採用することをひっそりとTwitterで宣言
 ↓
 2008年6月、Pythonコミュニティ(Python温泉)から１人目の
 エンジニアが紹介される ↓ 2008年 2人入社 ↓ 2009年 10人入社 ! … その後も次々と入社
12. 12. Pythonの採用による会社方針の変化 その1 選択と集中
 ・PHP、Ruby、Javaなどの仕事は請けない方針
13. 13. Python採用後にリーマンショック！(2008.9) 会社
 設立 リーマン
 ショック Python採用 東日本
 震災
14. 14. • 取引先の事業縮小／撤退、事業部解体 • IT開発投資一時停止（2009年3月末を目処に） 取引先に呼び出されて、事業責任者の方が青ざめて・・・ Python採用後にリーマンショック！
15. 15. Pythonの採用による会社方針の変化 その２ 選択と集中
 ・PHP、Ruby、Javaなどの仕事は請けない方針 ・常駐の開発仕事もやめる リーマンショックのおかげで、常駐仕事が終了 ↓ 会社メンバーが自社オフィスに戻って来た(2009.4) その２
16. 16. 異動異動 転職 出向 仕事 新規事業 別会社 子会社 別事業部 取引先 Python採用後にリーマンショック！
17. 17. 積極採用開始（2009年9月4日） • リーマンショック後、世の中は採用に慎重 
 → 人余り →優秀な人材を採用するチャンス到来 →採用募集はTwitterのみ →初の事務職（＋テスタ）も採用！ →2010年1月までに9人採用に成功
18. 18. 会社も移転（移転の度に家賃も２倍…） 2007.9∼ 2009.9∼ 2010.1∼ 2011.4∼ リーマン
 ショック 東日本
 震災
19. 19. Python採用で偶然学んだ、経営で大事なこと ①社会的
 ショック リーマンショック 東日本震災 ②社会 の動き → 社会的なショックがあった時が弱者のチャンス → リスクを取る ③チャンス ２度のショックとも翌年に会社の売上が1.5∼2倍伸びた
20. 20. 
 パートナーとして任せてもらえる顧客との信頼づくり  → 信頼される仕事をする  → パートナーとして任せてもらえる顧客を紹介で広げて行く   ※良い顧客は良い顧客とつながっている  → 70件以上のPython開発実績につながっていった
   （営業マン0人） Pythonの採用による会社方針の変化 その３ 選択と集中
 ・PHP、Ruby、Javaなどの仕事は請けない方針 ・常駐の開発仕事もやめる ・信頼の輪を広げて行く その３
21. 21. Pythonの採用により どのような人たちが集まってきたか？
22. 22. 変わったひとたち
 (Strange People) ひとことでいうと….
23. 23. 変わったひとたちが集まって来た 休みやプライベートの時間を使って
 Pythonの勉強をしたり、集まってプログラミングに
 いそしむ変わったひとたち… 愛すべき変わりもの（Geek、Nerd）
24. 24. Q. 個性が強いエンジニアをどう束ねるの？ 度々、質問されること
25. 25. Answer 
 束ねない（制御不能のため） → 彼らの声に耳を傾け、経営にしよう → やりたいようにやってもらおう
26. 26. shachoのクラウド化（ネット上だけに存在） python採用 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 自社にいない(客先常駐)自社にいない(客先常駐) ＜理由＞
 ・自分が色々提示すると、上意下達になってしまう ・入社したばかりの人→社長の自分がいると顔色伺ったりして、
  思った通りに行動できないこともある ↓ 自然に生まれてきたもの、自発的に生まれてきたものが
 会社の文化になる
27. 27. 会社に起こった変化
28. 28. 会社の変化その1 Pythonを好きな人たちが集まった
 ↓ 会社自体がPythonコミュニティになった Python PyCon FrameworkLibrary Tool BP
29. 29. 会社がPythonコミュニティになった効果 ・同じことに共感し、感動できる
   → 最新の情報が集まりやすい
 ・ベースの価値観が一致している
   (影響)読みやすさ, シンプル , Zen of Python → 合意の形成、意思決定の迅速化 ! ・Document を積極的に書こうという人が多い   (影響）Python標準ドキュメントの充実、Sphinx   →暗黙値の共有化、形式知化の促進
30. 30. 集まったひとたち ・オープンソース を使い、恩恵をうけている ・オープンソース・コミュニティ に参加している ・オープンソースの Contributor として活動している ↓ 会社も自然とオープンソース・コミュニティ型の
 会社運営に変わって行った 会社の変化その２
31. 31. 変化の中で見えてきたもの
32. 32. これからの時代の会社とは？ 工業化社会 知識創造化社会 エンジニア ？ 肉体労働者 エンジニア（ナレッジワーカー） が伸び伸びと創造性を発揮し 価値を創り出せる会社 模索中 エンジニア
 コミュニティ イマココ
33. 33. 時代の移り変わり 狩猟社会 農業社会 工業化社会 情報化社会 知識創造化 社会 知識（暗黙知、形式知）を活用し
 新たな知識を創り出し、価値を創造する社会 ・あらゆるものを
   デジタル化 ・情報インフラの整備
  （ブロードバンド）
34. 34. 知識創造化社会 知識（暗黙知、形式知）を活用し 新たな知識を創り出し、価値を創造する社会 暗黙知 形式知 知識 活動 価値 新たな知識を創造 知識労働者 創造
35. 35. 組織運営の違い 資本家 工業化時代 の会社 労働者 知識創造化社会 の会社 知識労働者 知識労働者の生産性向上
 のための組織運営
 ＝ヒト中心 産業製品の生産性向上
 のための組織運営
 ＝モノ中心 トップダウン
 （資本家／経営者から） 上意下達
36. 36. エンジニア・コミュニティ ソフトウェア ドキュメント 人のつながり Python PyCon FrameworkLibrary
 Tool Meetup 価値 エンジニア ↑ エンジニアが中心となり自発的に参加し、
 さまざまな価値を生み出しているコミュニティのこと
37. 37. ・組織 ・エンジニア ・組織とエンジニア 知識創造化社会の会社（これからの時代の会社）  = エンジニア（ナレッジワーカー）が伸び伸びと   創造性を発揮し価値を創り出せる会社
38. 38. ・会社 = コミュニティである ・オープンソース・コミュニティ型運営から学ぼう 組織運営
39. 39. 同じことに共感し、感動することができる ↓ 暗黙値が共有され、組織内の学習や情報共有につながる ↓ 切磋琢磨の結果、会社が知識レベルがアップし、事業に活かせる ↓ ブランド化 会社 = コミュニティである → ジャンルは、事業に関係するものが効果的 ・雑談の積極的奨励 ・場作り（社内勉強会） コミュニティ  = 同じことに興味をもった人たちの集まり
40. 40. SECI（セキ）モデル 共同化
 (Socialization) 暗黙知 暗黙知 形式知 形式知 表出化
 (Externalization) 連結化
 (Combination) 内面化
 (Internalization) ペアプロ 雑談 社内勉強会 ドキュメント 製品化 プロセス改善 書籍化 実践での 新知識取得 振り返り ① ② ③④
41. 41. 1983年 GNU Project 1990年代後半 Open Source Movement ↓ インターネットの発展 ↓ 多くのエンジニア がOpen Source Project に参加 ↓ Open Source Project の コミュニティ化 ↓
 組織運営・コミュニティ運営ノウハウを培う （エンジニア が創意工夫して培って来たノウハウ） → エンジニアが活躍する、知識創造化社会の会社にも有用 組織 オープンソース・コミュニティ型運営から学ぼう
42. 42. ・フラットな組織 ! ・コミュニティ評議会 ! ・コミュニケーション 組織 オープンソース・コミュニティ型運営から学ぼう
43. 43. フラットな組織 階層型か、フラット型か？
44. 44. 階層型組織 ・組織を管理しやすい ・官僚制  → 管理のためのルールがつくられる ・情報が階層間で滞りやすい
  → 意思決定のスピードが落ちる ・どうしても出世に目が行く  → 社内に目が向き、社外に対する意識が薄れがち メリット  管理しやすいので、うまく回れば、上のひとは楽 デメリット  内発的動機、自尊心、好奇心が失われ、創造性が失われる
45. 45. ベンチャー企業成長の罠 ベンチャー
 企業 ・創造力 ・想像力 ・未知の領域への大胆な進出 ・先見性に基づく熱意 成功 ・顧客に関する問題 ・キャッシュフロー ・スケジュールの遅れ 混乱 階層
 構造 経営管理
 のプロの登場 喪失 「ビジョナリーカンパニー2」
  ジム・コリンズ 著
46. 46. 階層構造と官僚制度による起業家精神の抹殺 ＜われわれ＞ ＜やつら＞ ＜階層構造＞ 特権をもつ
 経営幹部の階層 →凡庸な企業になっていく ＜官僚制度＞
 ・手順・手続き ・チェックリスト ・規則 制度の目的：規律の欠如と無能力を補う 嫌気がさして
 辞めていく適切な人たち 経営のプロ 「大人になる時期がきた
  経営のプロが必要だ」 ＜平等な雰囲気＞ ・創造力、想像力 ・未知領域への大胆な進出 ・先見性に基づく熱意 ベンチャー企業 「ビジョナリーカンパニー2」
  ジム・コリンズ 著
47. 47. 官僚的組織の悪循環 規則 管理のための ルール 少数の不適切な人 適切な人 会社を去る 不適切な人の割合が増える 規則 適切な人 不適切な人 会社を去る 「ビジョナリーカンパニー2」
  ジム・コリンズ 著
48. 48. フラット型組織 ・目的ごとにチームをつくり、役割を決める ! ・管理のためのルールは最低限   仕事をスムーズにするためのルール ・情報が行き渡りやすい ! ・出世を気にしなくて良い メリット  価値を創り出すことに集中できる デメリット  組織の管理が難しい
49. 49. フラットな組織への取り組み ・社長含む役員２人以外は役職無し ・名刺には好きな肩書きを記載 ←肩書き
50. 50. フラット型組織で大丈夫か？ ・セルフマネジメントと信頼関係を重視 ・管理する/管理されるの関係をつくらない 組織にかかるコストを削減できる ・管理するコスト ・管理されるコスト ・コミュニケーションコスト → 本来やるべき「価値を創り出す」ことに集中できる
51. 51. 起業家精神（創造性）と規律の関係 偉大な組織 官僚的組織 階層的組織 起業家的組織 起業家精神 規律 高 低 高低 「ビジョナリーカンパニー2」ジム・コリンズ 著
52. 52. 会社の経営 = コミュニティの運営 経営者 = コミュニティ・リーダー（=役割） !  経営者は偉い人ではない  ↓  権力ではなく役割である  ↓  リーダーにとって重要なこと
   権力ではなく、良い人格をもつこと
53. 53. ・フラットな組織 ! ・コミュニティ評議会 ! ・コミュニケーション 組織 オープンソース・コミュニティ型運営から学ぼう
54. 54. コミュニティ評議会（Community Council） ・コミュニティ全体を運営する役割を持つグループ ! ・課題がある場合に、評議会に提出される ! ・課題について評議会で議論し、方針を決定する 「Art of Community」
  Jono Bacon 著 / 渋川よしき 訳 より
55. 55. 「BP カイゼン」プロジェクト ・会社を改善することを目的 ! ・月２回、１時間のミーティングを開催 ! ・社内誰でも参加できる ! ・redmineで課題管理。
   課題がある場合、チケットを作成する ! ・議事録は全社員に公開、オープンなプロセスで決定 Be Proud の取り組み
56. 56. 「BP カイゼン」から生まれた制度 BPRD2.0 (BeProud Remote Day) ・週５日間、いつでもリモート勤務可能 ! ・制度を維持できるように、自分たちで制度を育てている （例）  ・アンケートを取り、問題点を改善する  ・Slackやbot などのツールを活用し、   皆が気持ちよく仕事ができるような仕掛けづくり
57. 57. コミュニティ評議会を会社に置くメリット ・自分たちで良い制度を提案し、育てていくことができる  → 当事者意識、参加意識が生まれる ! ・決定プロセスがすべてオープンなので風通しがよい  → 公正感が生まれる
58. 58. ・フラットな組織 ! ・コミュニティ評議会 ! ・コミュニケーション 組織運営
 オープンソースコミュニティ型運営から学ぼう
59. 59. オープンソース・コミュニティ  のコミュニケーション手段 ・ML ・Issue Tracking System（ITS） ・チャット ・ビデオ通話 ・オフラインミーティング 時間、リソース、場所などの制約が多い
 ・自然にさまざまな手段を使う ・ 間時間で、成果を出している
60. 60. リモートワークによるコミュニケーション 導入しているコミュニケーションツール 時間、リソース、場所などの制約が多いのは会社も同じ ↓ ! リモートワークの体制づくりにより制約を超える ・時間 → 通勤時間の削減→時間を捻出する ・場所/リソース → 家庭事情などで会社に来れない人も仕事ができる etc….
61. 61. Q. リモートワークは
 チームでのクリエイティブな
     仕事に向かないのでは？
62. 62. リモートワークでは段取りが重要 つくるプロセスアイデアを生み出すプロセス 必ずしも全ての時間、顔をあわせて仕事をする必要はない チームで一緒に仕事 個別に仕事 「アイデアを生み出すプロセス」と「つくるプロセス」 を区別する
63. 63. エンジニア・コミュニティ型組織運営 のまとめ 会社はコミュニティである
 ・共感による社内知識共有→会社がレベルアップ ・価値観の一致による意思決定の迅速化 ! オープンソース・コミュニティ型運営から学ぼう ・フラットな組織により価値・目的に集中できる ・オープンな運営による当事者意識、参加意識、公正感の醸成 ・コミュニケーション手段の効率化により、        時間、リソース、場所の制約を超える
64. 64. ・組織 ・エンジニア ← Next ・組織とエンジニア 知識社会の会社（未来の会社）  = エンジニア（ナレッジワーカー）が伸び伸びと   創造性を発揮し価値を創り出せる会社 ! → エンジニア・コミュニティにヒントがある
65. 65. 創造的なエンジニアになろう 組織 貢献 エンジニア ＜創造的＞ 価値 アイデア 創造的なエンジニア  = 主体的に価値を創り出そうとするエンジニアのこと
66. 66. オープンソースのコントリビューター コミュニティ 自発的に参加 エンジニア 価値に目を向け、アイデアを持っている ・どのようなソフトウェアが世界に役立つのか？ ・どのような機能が便利なのか？ 価値 ・社会にもたらされる価値に目を向けている
 ・アイデアを持っている ・自発的に参加している
67. 67. ・不安を乗り越え、主体的になる ! ・技術に感動する習慣をもつ ! ・価値を創り出すプロセスを学ぶ 創造的なエンジニアになる方法
68. 68. 創造的なエンジニアになる方法 ・不安を乗り越え、主体的になる ! ・技術に感動する習慣をもつ ! ・価値を創り出すプロセスを学ぶ
69. 69. 創造性を失わせる最大の敵 ・不安   “できなかったらどうしよう” ! ・恐怖   “できなかったらクビになる” 自分の外のことに怯え、主体性を失い、ディフェンシブな思考になる ↓ 創造性を失う
70. 70. 未来 不安・恐怖 サバイバルモードと創造モード ベータ波 アルファ波 シータ波 デルタ波 リラックス 催眠（うたた寝） 睡眠 サバイバル モード 体を守る 環境を守る 創造モード 発想・ひらめき 「あなたという習慣を断つ」より
71. 71. 創造的なエンジニアになるために 不安を乗り越える方法 その1. 技術を身につける ! その2. 今を生きる
72. 72. その１：技術を身につける 技術を身につける ↓ 自信がつき、心が安定し、不安が少なくなる 創造的なエンジニアになるために 不安を乗り越える方法 体 → 技 → 心 の順で身につける
73. 73. その２：今を生きる 完成した
 プログラム プログラミング 不安
 恐怖 ＜欲しい結果＞ 不安・恐怖をもとに頑張る（外発的動機） ↓ 集中できず、結果がでない 「できなかったらどうしよう」 納期、品質、満足度 etc… 創造的なエンジニアになるために 不安を乗り越える方法
74. 74. 完成した
 プログラム 打ち込む/
 楽しむ 一旦忘れる
 （頭の片隅に置く程度にする） プログラミングそのものを楽しむ（内発的動機） ↓
 集中できて、結果につながる（フロー状態） プログラミング ＜欲しい結果＞ 創造的なエンジニアになるために 不安を乗り越える方法 その２：今を生きる
75. 75. ゾーンに入る技術 認知脳 ・ものごと ・環境 ・他人 とらわれる ライフスキル脳 認知 ・仕事 ・やるべきこと 集中 子供は認知脳 が育っていな いので、遊び に集中できる 自ら集中状態に入るための
 思考・考え方 「ゾーンに入る技術」
 秀一 著 より ＋
76. 76. ゾーンに入る技術（ライフスキル脳）その１ ①内発的動機をもとに仕事をする ・得意よりも好きを大事にする ・自らやると決める ! ②自分に自信を持つ  「結果が出たら自信を持つ」は認知脳の働き ! ③一生懸命取り組む  →楽しさと充実感を得ることができる  →大人になると「一生懸命取り組むことはしんどいことだ」となる ! ④「今を生きる」  →過去を後悔する、未来を不安に思うととらわれる 「ゾーンに入る技術」 秀一 著 より
77. 77. ゾーンに入る技術（ライフスキル脳）その２ ! ⑤ウォッシュアウト思考（コントロールできないことは考えない） ! ⑥プリペアリング思考（準備をしておくと、集中できる） ! ⑦ディファレント思考（多様性、相違点を容認する）  →あれは正しい、あれは間違いとする正誤思考は認知脳の働き ! ⑧周りに与える（周りを喜ばせると、自分も元気になる） 「ゾーンに入る技術」 秀一 著 より
78. 78. ゾーンに入る技術（ライフスキル脳）その３ ⑨リスペクト思考（周りに敬意を持つ）  →尊敬に値するから尊敬するというのは認知脳の働き ! ⑩周りに感謝する  →感謝に値するから感謝するというのは認知脳の働き ! ⑪人を応援する
  →スポーツチームを応援すると元気が出るのと同じ  （チアリーダー的な元気さ） 「ゾーンに入る技術」 秀一 著 より
79. 79. ・不安を乗り越え、主体的になる ! ・技術に感動する習慣をもつ ! ・価値を創り出すプロセスを学ぶ 創造的なエンジニアになる方法
80. 80. 技術に感動する習慣をもつ （エンジニアを始めた当初）
 「おー、動いた！」 「この技術は便利だ！」 ↓（経験を積んでくると） 「動いて当たり前」 「その技術は想定の範囲内。目新しくない」
81. 81. 感動すると創造的になれる 感動が少ない人は好奇心が薄れ、記憶も弱まる。 → 結果、退化していく 感動 好奇心 探求心 創造 記憶 アイデア 「感動する脳」
 茂木 健一郎 著 より 子供のような好奇心、あるいは冒険心があって初めて、
 新しいものを生み出す力が生まれてくるのです。 ジェフ・ベゾス（amazon.com創業者）
82. 82. ・不安を乗り越え、主体的になる ! ・技術に感動する ! ・価値を創り出すプロセスを学ぶ 創造的なエンジニアになる方法
83. 83. 価値を創り出すプロセスを学ぶ ・要求開発 ・U理論 ・リーンスタートアップ etc… 価値を創り出すプロセス・考え方、イノベーションに ついて体系的に学ぶ ↓ 創造的視点が生まれる ↓ アイデアが生まれる
84. 84. ①ダウンローディング ②観る（Seeing） ③感じ取る（Sensing） ④プレゼンシング ⑤結晶化 ⑥プロトタイピング ⑦実践（Performing） U理論 実現イメージ
85. 85. 要求開発（匠メソッド） 戦略
 要求 業務
 要求 IT
 要求 システム
 開発 <経営者の視点> <現場の視点> <ITの視点> <開発の視点>
86. 86. リーンスタートアップ アイデア 構築要求 提供 計測 フィード バック 学習 ・インタビュー
 ・ブログ反応 ・プロトタイプ 使用 MVP
 (Minimum Viable Product) MVPをなるべく早くユーザーに提供し、 フィードバック・計測を繰り返しながら、 より良い製品に近づいていく方法 リーン
 キャンバス ユーザー 開発者
87. 87. 視点→思考→言葉→行為→結果 （入力） （出力） 創造の３つのプロセス →人は自分の視点をなかなか変えられない アイデア 価値価値創造活動 価値を創り出すプロセスを学ぶ 価値創造プロセスを学ぶと創造の視点が生まれる
88. 88. ・組織 ・エンジニア ・組織とエンジニア ← Next 知識社会の会社（未来の会社）  = エンジニア（ナレッジワーカー）が伸び伸びと   創造性を発揮し価値を創り出せる会社
89. 89. Open Source のContributorのように仕事をしよう 会社 貢献 自分の強み（興味）を活かして
 役割を探し、貢献する 会社 仕事 労働 契約で決められたことをする 役割 役割 役割 役割
90. 90. 役割に対して報酬を支払う 会社 貢献 報酬 果たした役割 に対して報酬を支払う 重要：役職に対して支払うのではない
91. 91. シナジーで社会に価値を生み出す 会社 貢献 役割 役割 役割 役割 強み ・自発的に参加したくなる組織づくり  ・組織の目的  ・組織運営 価値 創造エンジニア ＜創造的＞ アイデア ＜価値創造インフラ＞ シナジー
92. 92. まとめ 知識創造化社会の会社  =「エンジニア・コミュニティ」のような会社 → エンジニア（ナレッジワーカー）が活躍する会社
93. 93. 組織運営  ・会社=コミュニティである  ・オープンソース・コミュニティ型運営から学ぼう エンジニア  ・創造的なエンジニアになろう
   ①不安を乗り越え、主体的になる   ②技術に感動する習慣をもつ   ③価値を創り出すプロセスを学ぶ
 エンジニアと組織の関係  ・オープンソース・コントリビューターのように仕事をしよう  ・エンジニアと会社はシナジーで価値を生み出す
94. 94. ご清聴ありがとうございました！ BPStudy#100まで あと2回！