DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
•Download as PPTX, PDF•
464 likes•127,407 views
2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきました
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
- 2. 自己紹介 • ところてん • @tokoroten • 株式会社NextInt 代表 • 怪文章職人・インターネット芸人 • 最近のお仕事とか • 謎の講演とかワークショップ業 • 機械学習顧問（2社） • モバイルミドルウェア企業 • データ分析企業 • 新規事業コンサルティング（1社） • 業務改善コンサルティング（1社） • ゲームディレクター(1社) ↓共著 ↓寄稿↓共著 2
- 4. 注意 • このスライドは緑の恐竜がだいたい悪い • 自分が勉強したことや見聞きしたことが適当にまとまってます • ポエムであり怪文章です • 本ポエムは「闇のDevOps」というブログ記事を下敷きにして います • https://medium.com/@tokoroten/5aff8b60f589 • だいたい緑の恐竜が悪い、いいね？ 4
- 5. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 5
- 6. Why Software Is Eating The World http://sora.rainbowapps.com/software https://www.wsj.com/articles/SB100014240531119034809045765122509156294606
- 7. ソフトウェアが全てを飲み込む • ソフトウェアによって置き換わったもの • 電話 → スマートフォン • カメラ → デジカメ → スマホ • レンタルビデオ → Youtube、NetFlix • 映画 → Pixer • 書店 → Kindle • タクシー → Uber • 地図 → Google Map • 小売店 → Amazon • 財布 → 電子決済アプリ • 全ての産業でソフトウェアによる変革が進む • これから先は？医療？教育？銀行？ 7
- 8. President Obama asks America to learn computer science https://www.youtube.com/watch?v=6XvmhE1J9PY 8
- 9. • コンピュータ・サイエンスのスキルを身につけることは、皆さん自 身の未来のみならず、私達の国の未来にとっても、大事なことです。 • アメリカという国が最先端であり続けるためには、皆さんのような 若いアメリカ国民に、今後の世界のあり方を変えるようなツールや 技術について学んでもらわねばならないのです。 • 初めからコンピュータ・サイエンスの専門家の人なんていません。 しかし、少しの努力と数学と科学の知識で、誰でもコンピュータ・ サイエンティストになることができます。 • コンピュータは皆さんの未来の大部分を占めることになります。 President Obama asks America to learn computer science 9
- 10. 余談：オバマ前大統領のスピーチの背景 • 2013年12月に行われた、コンピュータ科学教育週間の応援 • コンピュータ科学教育週間の主催はCode.orgというNPO • https://hourofcode.com/jp • Hour of Codeというイベントを実施 • 1時間のプログラミングでコンピュータサイエンスに対する理解、興味 を持ってもらうのが目的 • 2013年はアメリカのみならず、170の国や地域から約1500万人が参加、 累計で５億行のプログラムが書かれた • コンピュータサイエンスを通じて「問題解決能力」「論理的思考」 「創造性」をはぐくむことで、21世紀のキャリアパスにおいて成功す る基盤を身につける 10
- 11. What Most Schools Don't Teach https://www.youtube.com/watch?v=nKIu9yen5nc 11
- 12. 全てはコンピュータに 12
- 13. 全ての職業にプログラマーが必要 • ポール・グレアム、Yahooに起きてしまったこと http://blog.livedoor.jp/lionfan/archives/52682119.html 13
- 14. 100の職業でどんな数学が使われるか • When Are We Ever Gonna Have to Use This? （1996） https://readingmonkey.blog.fc2.com/blog-entry-625.html 14
- 15. 100の職業でどんな数学が使われるか • コンピュータの利用は82/100の職業で必要 • プログラミングは13/100の職業で必要 • ただしこれは1996年の書籍 • 現在はもっと比率が上がっている と思われる https://readingmonkey.blog.fc2.com/blog-entry-625.html 15
- 16. 全ての産業でコンピュータが使われている • コンピュータ無しでの現代の産業は成り立たない • 1996年の書籍でも82/100の職業でコンピュータを使う • 日本の場合 • 工場の情報化は80年代から • 一般オフィスへの浸透は2000年ごろ • 1990年前後と現在を、フィクションの中で比較してみる • 1988 美味しんぼ • 1989 機動警察パトレイバー • 2015 SHIROBAKO • 2016 シン・ゴジラ • 2018 アグレッシブ烈子 16
- 17. 1988 美味しんぼ • 新聞社のオフィス • ワープロもなければパソコンもない 17 公開版は画像省略
- 18. 1989 機動警察パトレイバー ON TELEVISION • 当時はコンピュータは「電算室」にあるものだった 18 公開版は画像省略
- 25. 世界ではなにが起こっていたのか？ • DX、DevOps、toCのソフトウェア会社が躍進 • ソフトウェアを全世界に輸出できている • 日本企業はうーん… • ソフトウェアの輸出ができていない？ • じゃあ、DX、DevOpsって何よ？なんでDevOpsが必要なの？ 25
- 26. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 26
- 27. DevOpsの初出 • 2009年、Velocity2009 • Flickrの事例 • 「DevとOpsが協力することで、1 日に10回のデプロイが可能にな る」 • やっていること • インフラの自動化 • バージョンコントロール • ビルドとデプロイが1ステップ • 監視の自動化、IRCにログ • etc https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 27
- 29. なぜDevOpsが必要なのか • 収益の主体・差別化がDev・SalesからOpsに移った • LTV>CPAである限り無限スケール • マーケットの変化速度の上昇 29
- 30. 収益の主体がOpsに • ビジネスがサブスクリプション化 • Netflix、YouTube Premium • Amazon Prime、Kindle Unlimited • 各種SaaSアプリケーション • コマツ、KOMTRAX • GE、航空機のエンジンのサブスクリプション • Opsがよければユーザは契約を続ける • ＝品質が高ければLTVは上昇する • 満足度が高い顧客は、新規顧客を連れてくる • 口コミで評判を広めてくれるので、広告が効きやすくなる • ＝品質が高ければCPAが大幅に下がる 30
- 31. LTV>CPA の世界 • LTV • Life Time Value • 一人当たり顧客生涯価値 • CPA • Cost per Acquisition • 顧客一人当たり獲得単価 • LTV > CPAの世界 • 利益＝LTV-CPA • これが実現できていると、広告を打てば打つだけ利益が出る状態 • クラウドのスケールアウトと組み合わせて、急激な顧客拡大が可能になる • Opsが人手で事業拡大に時間とコストがかかるとこうはいかない 31
- 34. 変化に対応するには細かい軌道修正が必要 • 従来の中央研究所方式の製品リリースでは世界と戦えない • 研究所で数年 • 事業会社でさらに１年開発 • 運用移管して数年の運用 • より短い期間で軌道修正を行える者が勝つ • リーン開発、スクラム、DevOps、DX 34
- 37. 違う、そうじゃない 画像省略37
- 39. なぜDevとOpsは対立していたのか？ • 部署が分かれている • 評価基準が違う • 採用が違っていた 39
- 43. ベクトルで分かる、部門対立 • 評価軸が部門ごとに独立 • Devは新機能軸を評価する（評価される） • Opsは安定性軸を評価する（評価される） • どうしてこうなった？ • ハードウェアの時代の歴史的経緯による分業 • 現代では、分業による効率化、餅は餅屋 43
- 44. ハードウェアの時代の歴史的経緯 • 研究・開発・運用サポートの分離 • 少数精鋭・高学歴の研究開発 • 基礎技術の研究開発 • 製品の開発のための図面起こし • 高等教育を受けた製造オペレータ • 工場労働、製品の品質管理 • 大量の運用人員、労働集約産業 • 設備の設置、修理サポート、販売支援 • コールセンターサポート • 製品に何かあったら運用でカバーはこの時代から • ハードウェアはなかなか直せない 44
- 45. ソフトウェアの時代へ • ソフトウェアはハードウェアの従属物の時代 • ハードウェア時代のウォーターフォール開発が そのままソフトウェアに適用される • ハードウェア時代の組織構造がそのままソフトウェアに適用 • 設計：コードの設計をする人 • 製造：コードを書く人 • 保守：コードの運用＋マシンのメンテをする人、サポセン • ソフトウェアのリリースも一年に一回、半年に一回程度 • 運用でカバーで何とかなっていた 45
- 46. 企業のネットが星を被い 電子や光が駆け巡っても 国家や民族が消えてなくなるほど 情報化されていない近未来 攻殻機動隊 GHOST IN THE SHELL(1991)46
- 47. 時代はインターネットへ • 毎日が機能追加、毎日がデプロイ、毎日がバグ • 開発部門は機能開発・売上が業績評価指標 • 運用部門は稼働率、SLAが業績評価指標 • 開発と運用では必要なスキルセットが異なるので、分業する • 開発部門と運用部門の業績評価指標が直交 • DevとOpsが対立する • じゃあ、これを何とかしようぜ、というのがDevOps • そして、そのキッカケはクラウドの登場（だと思っている） 47
- 48. 余談）少しずつ壊れていく分業 • 最初はうまくいく • なぜ部門が分割されたか皆が知っている • 隣の部門をカバーするように動く • 評価制度が狂いはじめる • 問題を分割したことによって、 評価が分かりやすい数字に置き換えられる • 部門の数値目標が一人歩きを始める • 個人の評価も同様の数値目標で行われるようになる • 考える人が居なくなる • 与えられた評価基準を満たすように皆が動くようになる • 隣の部門の問題は誰も知らない • 部署の間に落ちたボールは誰も拾わなくなる 48
- 49. クラウドの登場 • 1999年 VMWare • x86の完全仮想化 • 2000年 FreeBSD jail • 1台のPC内のユーザを仮想的にアイソレーションする • 2003年 Xen • 2005年 OpenVZ • 2006年 AWS EC2 • APIでキックしてインスタンスを立ち上げる • 2009年 FlickrがDevOpsの講演 詳しい話は緑の恐竜に聞いてください49
- 50. 余談：クラウドと仮想化って何が違うの？ • 仮想化：基礎技術、1960年代からあった • 分散処理：基礎技術、1960年代からあった • クラウド：提供形態、2006年ごろから • クラウドは仮想化されたコンピューティング資源が、APIを経由してプログ ラマブルになったサービス • コンピュータを制御するのに、人の手を介さないでもよくなった • 人間が直接管理できるコンピュータはせいぜい10台程度 • コンピュータをコンピュータで制御することで限界突破 • より優れたプログラマは、より多くのコンピュータを扱える時代 • クラウドは人間の能力の限界を突破させた 50 詳しい話は緑の恐竜に聞いてください
- 52. 余談：Иττのクラウドに絶望した話 • 入社式で分散処理の専門家のS先生がゲスト公演 • クラウドは人間をエンパワーする • より優れたプログラマが、 より多くのコンピュータを扱える時代が来る • クラウドとは人間の能力を100倍、1000倍に引き上げる仕組み • 社長の講演は全く覚えてなかったけど、 S先生の話は自分に深く刻まれていた • Иττのクラウドは人間をエンパワーしているか？ • していない → 退職へ 52
- 53. クラウドの登場で何が変わったのか？ • クラウドにより「計算機資源そのものが仮想化され、計算機資 源がプログラマブルになった」 • Ops業務のメインは「サーバ管理」＝「計算機資源のマネジメント」 がであったが、これの大部分がプログラマブルになった • 仮想化や自動化に対して様々なツール・サービスが登場 53
- 54. Opsの手作業業務の大部分が自動化 • サーバラックに機材を積み込んで、 電源入れてOSインストールして、 必要なパッチを当てて、 ネットワーク回りの設定を書き換え、 サービスをデプロイして、 ログを画面に表示して目視確認して…… • 開発初期におけるOpsの手作業業務の大半がプログラマブルに • Infrastructure as a Code、 Immutable Infrastructure、に繋がる • DevがOpsの業務を取り扱えるようになった • Opsがプログラミングによって自らの仕事を減らすのもアリだが、 日本ではプログラミングのできるOpsが少ないため、 結果的にこうなることが多い 54
- 55. DevOpsとは何か？ • クラウド＋周辺ツールによるOpsの手作業業務の自動化 • 変化への対応 • 無限の事業スケールへの対応、LTV>CPA時の急拡大対応 • DevとOpsの業務をプログラミングにより垂直統合 • 「手を取り合えば効率的になる」というわけではない • Opsの仕事をDevがプログラミングで奪い取る • 業績評価指標の見直し • 分業から垂直統合仕様に • 垂直統合前提で業績評価指標を見直す 55
- 56. DevOpsとはツールではない • 業務プロセスの垂直統合 • プログラマーの活動範囲の拡大 • オペレーションまで加味した全体最適化 • 全体最適化なので、業績評価指標を「全体最適」にする必要 • 個別最適の業績評価指標のままではDevOpsはできない 56
- 57. 業績評価指標をDevOps仕様にする • 一番簡単なのは生株付与やSO • 会社の評価額の上昇が、自らの利益になる • サービスの価値が上がる、会社の評価額が上がることなら何でもやる • 次に簡単なのはサービスの利益連動ボーナス • とはいえ、サービスの利益を計算するのはとても大変 • 人数が多くなると、その人の貢献を計測するのは超大変 • 配属ガチャで給与が決定されるという問題が生まれる • GoogleではSREとプロダクト開発チームはError Budgetを共 通の指標にする 57
- 58. Error Budget • SLO(Service Level objectives)に基づくError Budgetを設定 • DevとSREは Error Budget を共通の評価指標に • Devも稼働率を改善するのに協力する • サービスがダウンすると、その分 Error Budget が削られる • Error Budget が尽きるとデプロイできなくなる • Error Budget が尽きそうになったら、デプロイの間隔を下げる • その分、コードレビューやテストを厚くする • サービスの種類によって、設定されるBudgetの 大きさは異なる • 安定性が重要なtoBサービスは小さく • 改善速度が重要なtoCサービスは大きく • プロダクト性質に応じて柔軟に変更する 58
- 59. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 59
- 60. 日本の労働法の歴史的経緯１ • 明治時代 • 工場労働者は低賃金 • 給与を上げるには、スキル身に着けて転職 • 大正から太平洋戦争 • 熟練工の長期雇用をしたい • 社内で職工を育成、長期雇用が前提に • 年功賃金制、年功序列制の発生 • 生活給思想が広まる • 若年層に過度な高給を与えても飲食で浪費してしまう • 壮年層には、家族を扶養するために多くの給与を与えるべきだ • 賃金統制令、年功序列が法律で規定される 60
- 61. 日本の労働法の歴史的経緯２ • 戦後、電産型賃金体系 • 本人の年齢＋扶養家族数をベースに生活給を決定 • これに職能給や勤続給を加えた年功賃金制度 • 占領軍、政府、経営はこれに反対 • 1950年代、職能給の確立 • 技術革新により新規工場が設立、大規模な配置転換が必要に なり、労働者は給与が維持されること条件にこれを労使合意 • 給与の維持＝職能の維持、仕事が代わっても「職能」は変化しない • これにより、労働市場からの人材調達ではなく、 社内の配置転換による雇用調整がメインになる • 「勤続年数が長くなれば潜在能力が伸び、潜在能力があるか ら配置転換しても大丈夫」というのが建前 61
- 62. 日本の労働法の歴史的経緯３ • 1960～1970年代 • 配置展開が子会社、グループ会社間に拡大 • 転籍という形で企業の枠を超えた異動 • 人事権法理の確立 • 労働者の同意を得ない配置転換を正当とする • 配置転換に本人の同意が必要だとすると、同意を得られな かった場合、労働者を解雇することになる • 一方で解雇権は制限されている • 配置転換と解雇で、配置転換が優先される • ジョブ保障とメンバーシップ保障で後者が優先された 62
- 63. 日本の労働法の歴史的経緯４ • 1985年 男女雇用機会均等法 • 男性採用・女性採用のラベルを張替えて対応 • 男性採用→総合職 • （家族を養うので）職能給、年功序列で昇給 • コア業務、配置転換あり • 女性採用→一般職 • （結婚までの腰掛なので）昇給しない • 事務業務、配置転換なし • 日本企業は総合職の配置転換によりアジリティを 確保していた 63
- 64. 日本の労働法と事業会社 • 事業会社は配置転換を前提に従業員を雇用する • 配置転換できそうか？どこに配属しても大丈夫か？ • そしてコミュ力採用に…… • そして産業の高度化について行けず…… • IT人材は社内での配置転換先がないので、雇いづらい • ITシステム開発には稼働の波があるが、事業会社一社ではこれを吸収できない • IT人材を配置転換したいが、配置転換先がない、なので雇えない • IT業務については社外に発注する → SIerへの依存 • 社内にITの専門家がいなくなる • 要件定義、発注、ベンダーコントロールができない • 日本的DX問題に発展、みずほ4500億円… … … 64
- 65. 余談：追い出し部屋は何故できるのか？ • 日本の給与制度と、労働法の判例が合わさった結果の闇 • 解雇、不当な減給は禁止、でも配置転換はOK • 配置転換をして、自主的に進退を考えるように促すことはOK • 職能が上がってしまって、給与が上がり過ぎてしまった人が生まれる • 職能は「潜在能力（笑）」なので、計測が難しく、年功で上がってしまうことが多い • 職能は「潜在能力（笑）」なので、下げることが難しい • 職能は実際に仕事ができるかどうかは別 • 職能と役職はリンクすることが多いが基本的には独立 • 職能は高いが役職がない、という人が生まれる • リンクさせる必要がある場合、解雇か降格をする必要があるが、これは難しい • 「異動してきたばかりだから、出来なくても仕方ない、そのうち出来るようになるよ…」 65
- 70. 余談：本当にあった怖い話（n=1） • 優秀な新人はプロフィットセンターの生産部門へ • アレな新人はコストセンターのIT管理部門へ • IT管理部門が人材の吹き溜まりに…… • 現場とは話が通じるが、IT部門が30年遅れ…… • 何も考えずに安全側に倒しまくる • データは工場の外に出してはいけない、クラウドなんてもってのほか • ある種のイノベータのジレンマ • 稼いでいる部門に優先的にモノヒトカネを投入 • IT部門に投資して全体の効率を改善するという意思決定ができない 70
- 71. 分社化される大企業 • 労働者は「同一職能・同一賃金」を期待する • 経営者は「同一労働・同一賃金」にしたい • これを両立させるために、事業・職種ごとに分社化される • グループ会社間で異動させることで、給与を調整できる • 大きく給与を下げるのは判例的にはNG • どこの会社で最初に雇用されたかで給与差が生まれる • 親会社から送り込まれた天下りおじさんが自分の倍の給与をもらっておりモチベダウン • 大企業、本社指向で、そこに人が集まる • あと、ポストを用意したい • 人件費圧縮として行ってきた子会社戦略がDevOps、DXの足枷に • 部署の壁よりも厚い、会社間の壁が 71
- 72. そして火を噴く日本的労働 • 仕事が高度化、配置転換では対応できなくなってきてる • 配置転換先のない窓際おじさん、パソナルーム、追い出し部屋 • 配置転換をすることで「自発的に退職していただく」 • 先端業務で使える専門性が磨けないローテーション人事 • DXの要請、 2025年の崖 • 仕事の高度化＝コンピュータ時代、全てがコンピュータの時代 • コンピュータが使えないやつに仕事がない時代 • ルールを作って人を管理する時代から、 コードを作ってコンピュータで世界を管理する時代へ • 機能別子会社による給与抑制は、DXの足枷になる • DXは業務をデジタルによって垂直統合をする • 部署の壁だけでなく、会社の壁にぶち当たる 72
- 73. 全てのがDevOpsになるのか？ • toC、toBで状況が変わる • toC • toCはOpsの自動化と無限オートスケールの相性が良い • LTV>CPAの数式でビジネスが語れる世界 • toB、toGov • ビジネスのスケールが限定的、まだ変化速度は遅い • なので、全部が全部、DevOpsにならなくてはいけないわけ ではない 73
- 74. とはいえ、toB、toGovも変わっていく • 政府のソフトウェアのOSS化 • クラウドの採用、API化 • 入札からコンペ型・直接雇用の契約へ • Industory4.0やConnected Factoryによる事業のAPI化 • 少量多品種生産の増加、全自動フルカスタマイズ生産 • 変化速度が速まっていくことは間違いない • 遅かれ早かれ、WFタイプは減っていくんじゃないかなー 74
- 75. 例）東京都 新型コロナウィルス対策サイト • Github上でOSSで運営 • https://github.com/tokyo- metropolitan-gov/covid19 • Vue+Nuxt.js+Netlify • SSR かつ SPA • 一般からのPullRequestの 受付 • SIerはこの速度感でサービ ス提供できるか？ 75 https://stopcovid19.metro.tokyo.lg.jp/
- 76. 目次 • ソフトウェアが世界を食らう • DevOpsとは何か？ • 日本の労働法とDX/DevOps • DevOpsとメンタル 76
- 77. 大本営発表マネジメント • 日本的な職能による昇進は、その職位に付く能力があるかない かとは関係なく行われる • マネジメント能力がない人がトップに就くと、大本営発表マネジメン トがよく行われる • 「俺たちは勝っている」というメッセージを発し続ける • 大本営発表マネジメントは、視野の狭い人には強烈に効く • 大半の人は「お気持ち」で働いており、「お気持ち」＝生産性 • 視野の広い人には、強烈なマイナスに作用する 77 大本営発表マネジメントは私の造語なので、ググっても出てきません
- 80. How Not to Land an Orbital Rocket Booster 80 https://www.youtube.com/watch?v=bvim4rsNHkQ
- 81. ポストモーテム、検死 • 大本営マネジメントは、失敗から学ばない組織を作り上げる • 失敗したプロジェクトを社内でちゃんと話せるか？ • 失敗のコストとは教育である 81 https://landing.google.com/sre/sre-book/chapters/postmortem-culture/
- 82. Error Budgetは失敗を許容する • Error Budgetは開発者とSREの間でのインセンティブに使われる • 信頼性100%はあり得ない、誰でも、どんなシステムでも失敗する • Budgetが尽きない限り失敗してもよい • Budgetを設定することで、信頼性を上げすぎて、過剰コストになることを防止する • 失敗が起こることを前提に組織を回すことができる • 失敗をゼロイチで捉えない • SLAの場合、SLAを割ったかどうかでしか評価されない • SLAを下回ったから、謝罪、返金、社長が謝る、終わりの組織は多い • Budgetにして監視をすることで、連続値になり、 意思決定を柔軟に変えることができる 82
- 83. 学習姿勢と心理的安全性 • How Google Works ラーニングアニマルを採用す る • 自分の能力は変わらないと考えていると、その自己イメー ジを維持するために「到達目標」を設定する。一方、しな やかマインドセットの持ち主は「学習目標」を設定する。 • 学ぶこと自体が目標になると、くだらない質問をしたり、 答えを間違えたりしたら自分がバカに見えるのではないか などと悩んだりせず、リスクをとるようになる。 • ラーニング・アニマルが目先の失敗にこだわらないのは、 長い目でみればそのほうが多くを学び、さらなる高みに上 れることを知っているからだ。
- 84. プロジェクトアリストテレス • 心理的安全性はGoogleの調査からIT業界に広まった • Project Aristotle チームの生産性に何が寄与するかを調査するプロジェクト https://rework.withgoogle.com/jp/guides/understanding-team- effectiveness/ https://rework.withgoogle.com/print/guides/5721312655835136/
- 85. 生産性には5つの要素が必要 • 次の5つが上から順に重要 • 心理的安全性（Psychological Safety） • 相互信頼(Dependability) • 構造と明確さ(Structure ＆ Clarity) • 仕事の意味(Meaning) • 影響(Impact) • 真に重要なのは「誰がチームのメン バーであるか」よりも「チームがどの ように協力しているか」であった※ ※「Googleに採用されている人」という観測バイアスがかかっているので注意 https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/
- 86. 心理的安全性の計測指標 • チームの中でミスをすると、たいてい非難される。 • チームのメンバーは、課題や難しい問題を指摘し合える。 • チームのメンバーは、自分と異なるということを理由に他者を拒絶す ることがある。 • チームに対してリスクのある行動をしても安全である。 • チームの他のメンバーに助けを求めることは難しい。 • チームメンバーは誰も、自分の仕事を意図的におとしめるような行動 をしない。 • チームメンバーと仕事をするとき、自分のスキルと才能が尊重され、 活かされていると感じる。 https://rework.withgoogle.com/print/guides/5721312655835136/ https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
- 88. 心理的安全性は何のために必要か？ • ひとことで言うと、心理的安全があれば、厳しいフィード バックを与えたり、真実を避けずに難しい話し合いをしたり できるようになる。 • 心理的に安全な環境では、何かミスをしても、そのためにほ かの人から罰せられたり評価を下げられたりすることはない と思える。 • 手助けや情報を求めても、不快に思われたり恥をかかされた りすることはない、とも思える。 • そうした信念は、人々が互いに信頼し、尊敬し合っていると きに生まれ、それによって、このチームでははっきり意見を 言ってもばつの悪い思いをさせられたり拒否されたり罰せら れたりすることはないという確信が生まれる。 チームが機能するとはどういうことか ４章 心理的に安全な場を作る より引用
- 89. 心理的安全性の勘違い • 「うちの会社は心理的安全性があります！」に意味はない • セクハラだと当人が感じたらセクハラ • 心理的に安全だと当人が感じたら心理的安全 • 心理的安全性は、空間ではなく個人の体感 • 心理的に安全だと感じるラインは個々人で異なる • リーダーは「ここまでやっても安全だ」と見せる必要がある • 自社の失敗をモンティパイソンのBGMで紹介できるか？ • 周りはなかなか変えられない、自分は変えられる • 心理的安全性のラインが高い人を雇用することも大事
- 90. 個人が心理的に安全になるには？ • なぜ人は発言しなくなるのか？ • 会社や組織と対立することによって、自分の仕事が危うくなると思っている • 日本的な雇用は対立を極端に恐れる • いつ配置転換で地方に飛ばされるか分からないし…… • 会社や組織に対して強くなることでも心理的安全性は改善する • 会社や組織が間違っているのであれば、いつでも出ていける • クビを切られたとしても明日からでも行ける会社がある • 対立したとしてもそれは学習だと認識する • 能力・人脈・転職活動・学習姿勢がある人は、 対立を恐れずにGive firstができる
- 91. DevOpsが出来る人材を雇用する • そもそもプログラミングが出来ることが必須 • 失敗を学びだと認識できる人 • 目の前の不確かな事象を理解できる言語能力の高さ • 人と対立してもそれを感情ではなく、ロジックで解釈する • 全体最適を意識した動きをするための視野の広さ • HRT、謙虚・尊敬・信頼を持った人 • コミュ力と言語能力は違う • 相手に共感することと、論理的に情報をやり取りする能力は違う • 言語能力が高い人を正しく採用する • これを間違えると、言葉狩り、ポリコレ、コンプラ地獄に陥る • 配置転換を前提とした企業は、コミュ力に寄りがち 91
- 92. HRT（謙虚・尊敬・信頼） • 優れた開発チームでは、HRTの価値が大切にされている • 謙虚 Humility • 世界の中心は君ではない。 君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。 • 尊敬 Respect, • 一緒に働く人のことを心から思いやろう。 相手を一人の人間として扱い、その能力や功績を高く評価しよう。 • 信頼 Trust • 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば、仕事を任せることができる。 • HRTは学び続け、成長し続けるための姿勢 • HRTの逆を考えてみればよい、人から学ぶことが出来なくなる • HRTを持つことで同僚の行動に対して正しく振る舞える • 同僚は安心して自己を開示し、良い議論が行えるようになる
- 93. NETFLIXの事例 • 一時ネットフリックスはバッファリング時間（ビデオをクリックして からスタートするまでの時間）の短縮に大苦戦していた。エンジニア にしか完全には理解できない、厄介きわまりない問題だ。 • 私たちはセールスとマーケティングの担当者に要請した。「あのくそ いまいましいバッファリング問題をなんとかしてくれ！」とエンジニ アにぶちまける代わりに、「なぜバッファリングにこんなに時間がか かるのか、わかるように説明してくれ」と聞いてほしい、そしてその 質問は本心からぶつけてほしいと。 • 相手がとりくんでいる課題に心から関心をもってする質問は、理解の 架け橋になる。技術系でない従業員は、この質問への答えを通して、 エンジニアがどんなに手ごわい課題にとりくんでいたかを初めて知り、 視野を大きく広げた。 • こうした質問を投げかけるうちに、やがて社内に好奇心と敬意が育ま れ、チームや部門の内外で有益な学習が行われるようになった。いい 加減な噂や陰口のたぐいも減った。 NETFLIXの最強人事戦略4章より引用
- 94. 余談）IPOでレガシー化するベンチャー企業 • 売り上げを増やすために商品を増やす • 商品を増やすために人を一気に増やす • 人材レベルが低下して、大本営マネジメントが始まる • 市場に対して弱気を見せると株価が落ちる • 市場への強気のアピールは社員の自己洗脳につながる • 対外的なポストモーテムは株価に影響が出ると思い込んでしまう • 社内で失敗の分析や、ネガティブな発言は禁忌となる • 失敗から学ばなくなる • 監査対応でレガシーなシステムが必要になってしまう • 会計監査、内部統制 • 外部の会計会社が慣れ親しんだワークフローを要請される • チェックリスト地獄、監査がレガシー • それをビジネスに組み込んでしまうとシステムが複雑化、レガシー化 94
- 95. 余談）クソスクラム野郎問題 • 「俺たちはスクラムをしているから勝っている！」と思い込む • 大本営発表マネジメントの亜種 • プロセスを信奉して思考停止する • プロセスは改善するものであり、信奉するものではない • スクラムは「まずは型をコピーするところから始め、自らのビジネス に合わせてカスタマイズしていく」という守破離を説いているが、 そのせいで、守で満足して思考停止してしまう人が多い • 新しいことをするのは怖い、勝ってることにするのは楽 • 「俺はスクラムが嫌いだ」と言うスクラムマスターが何人も… 95
- 96. SIerはどうなるのか？ • 企業・公共のアジリティを上げる流れ • 公共のOSS化、公共のクラウド化 • 世界は「WFよりも、DevOpsのほうがコストが下がる」ということを 知ってしまった • 柔軟な予算体制を組める組織はそちらに移行していく • 準委任契約の請負とか • ITシステム入札の闇にそろそろ気づき始めている • 結論 • 知らんがな、うちは単なる中小企業だ、俺に聞くな • 緑の恐竜がだいたい悪い 96
- 97. 大企業はどうしているのか？ • 既存ビジネスを変更するコストは激烈にヤバイ • 新しい子会社を作るのは簡単 • 新しい人事評価制度、採用ラインで運用 • 最近できたRidgelinez社とか、傍からはそう見える • 既存ビジネスはキャッシュマシンとして現状維持、 新規子会社でチャレンジをする • 現状に危機感を覚えたら、こういうチャレンジをして いる子会社への転職・転属・出向を考えるのもアリ • 富士通クラウドテクノロジーの人にこの辺の話を聞 いてみたい • 富士通標準の業務プロセスをどうやって潰して、 DevOps体制を構築した？ • どのように人材を雇用した？ 評価した？ • 次回の富士通 Tech Liveとかで話してもらったら面白 いんじゃない？ 知らんけど 97 https://pr.fujitsu.com/jp/news/2020/01/30.html
- 98. 余談：DXできてない企業だと思う事例 • 激ヤバドメイン • なんで富士通が2回？ 階層おかしくない？ • fujitsu.com/jp/ の下にあるべきなのでは？ • コンウェイの法則 • システム設計は組織構造を反映したものになる • 社内政治の壁がドメイン名から透けて見える • 公式ウェブサイトを改修する権限をもらうよりも、 サブドメインを切るほうが楽というのは異常 • 心理的安全性 • 激ヤバドメインにたいしてストップをかけられる 人がいなかったという機能不全感 https://twitter.com/tokoroten/status/1228559664163385346 98
- 99. 参考資料 • 闇のDevOps DevOpsと業績評価 • https://medium.com/@tokoroten/5aff8b60f589 • xOps: エンジニアがスタートアップの成長の原動力となる日 • https://www.slideshare.net/takaumada/xops • 技術の創造と設計 • https://amzn.to/2VPFaYX • 日本の雇用と労働法 • https://amzn.to/2vxJPDY • How Google Works • https://amzn.to/2TB1J0s • SRE サイトリライアビリティエンジニアリング • https://amzn.to/3cmkvkS 99