SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」
- 1. SoRとSoEをつなぐ 「エンジニアの役割」と 「企業の課題」 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.2017/7/28 2017.7.28 Developers Summit 2017 Summer
- 2. 自己紹介 清田 馨一郎（せいだ けいいちろう） コーポレート本部 事業推進統括部 データソリューション部 アナリティクス＆テクノロジーグループ 【経歴】 2002年 システム開発会社に入社 PGから叩き上げでPMまで経験 案件も大手企業基幹システムからソーシャルゲーム開発まで 2014年に株式会社インテリジェンス （現社名：パーソルキャリア株式会社）に入社 マーケティング部門のKPI集計、内製BIの開発?運用を行う 現在は、ビジネスに機械学習を用いるプロジェクトの アーキテクト、開発者として活動中 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 3. 事業紹介 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved. コーポレート 本部 Works事業 人材紹介事業 転職メディア 事業 エグゼクティブ 事業 新卒事業 Innovation Lab.
- 4. セッション対象者 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 5. ? ITプロジェクトをマネジメントする方 ? いわゆるレガシーな開発とモダンな開発の どちらかのみ経験という方 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 6. 異なるIT流儀？ Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 7. System of Record System of Engagement 2011年 Geoffrey Moore氏 ホワイトペーパー「Systems of Engagement and the Future of Enterprise IT: A Sea Change in Enterprise IT」で提唱 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 8. System of Engagement ? 2011年当時は、Facebook,TwitterなどのSNS、 iPhoneなどのモバイル端末が、世の中に爆発的に 浸透した ? ビジネスを取り巻く環境の変化が激しい中で、 スピーディーに適応する エンタープライズITのあり方として 「System of Engagement」を提唱した Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 9. SoR – Enterprise Content Management SoE – Social Business Systems フォーカス トランザクション インタラクション ガバナンス 指示とコントロール 協調 コア要素 事実、日付、約束 洞察、アイディア、 ニュアンス 性能標準 精度と完全性 即時性と利用しやすさ 記録タイプ ドキュメント （テキスト、グラフィックス） ”会話” （テキストの会話ログ、画像、音声、 動画） ユーザビリティ システム上で訓練 サポートへの問い合わせ 顧客体験から”知る” ポリシー セキュリティ（資産の保護） プライバシー（ユーザの保護） Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved. 「System of Engagement and The Future of Enterprise IT」から抜粋
- 10. SoR vs SoE ? いわゆるレガシーな開発とモダンな開発の対立軸を 述べている訳ではない Moore氏も 「正しいアーキテクチャは、SoRの上で動作するSoE」 であると述べている Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 11. BiModal IT 2014年 Gartner社が提唱 デジタルビジネスにおける２つの流儀 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 12. BiModal Mode１ ? ニーズを受けて開発 ? 予測可能である ? 要件が理解されている ? 技術領域について知見を 持っている ? 計画可能である Mode２ ? 可能性を探る ? 探索的である ? あらかじめ要件が決まっ ていない ? 技術領域で知見を持って いない ? 事前計画が立てられない Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 13. Mode１ Mode２ ゴール 信頼性 俊敏性 アプローチ ウォータフォール、V字モデ ル アジャイル、カンバン 管理 計画駆動、承認ベース 経験的、連続的、プロセス ベース 向くこと 従来型プロセスのプロジェク ト 新しく不確実なプロジェクト 文化 IT中心。顧客からは遠い ビジネス中心。顧客に近い サイクル 長期(月単位) 短い(日,週単位) Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 14. Mode1 vs Mode2 ? Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved. Mode2Mode1 Mode2の取り組みが成功。 定着すればMode1化
- 15. パーソルキャリアのケース Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 16. パーソルキャリアでの３つのケース 1. SoRの１機能でSoE 2. SoRのサブシステムでSoE 3. 新規事業（SoE） Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 17. パーソルキャリアでの３つのケース 1. SoRの１機能でSoE 2. SoRのサブシステムでSoE 3. 新規事業（SoE） Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 18. 基幹システムに 機械学習を利用する機能 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 19. SoR型開発での課題 データアナリスト ? システム開発は専門外 ベンダー ? 機械学習の経験なし 機械学習部分は、 システム化の知見がなく計画不可 機会学習部分以外は、 経験があり計画可能 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 20. SoR型開発での課題 ? Try & Errorが必要 ? やって気づく問題点 ? 蓄積されるナレッジ ? リリース後、改善は素早くしたい ? 従来の開発プロセスだと スピードが出ない ? 仕組みを知らないと改善も出来ない Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 21. 「難易度が高くTry & Errorで進めるもの」 「ナレッジを内部に残したいもの」 ? 内製化 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 22. パーソルキャリアでの３つのケース 1. SoRの１機能でSoE 2. SoRのサブシステムでSoE 3. 新規事業（SoE） Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 23. 追加サービスの開発で スクラム開発 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 24. ? IT部門主体でのスクラム開発 ? B2Bだが企業様に直接利用していただく ? B2Cサービス ? フィードバックを素早く得たい ? 機能のデリバリーサイクルを短くしたい Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 25. 大切なこと ? POの育成 – プロダクト?バックログの回し方 – 開発側もPOをサポート ? 開発メンバーの育成、アサイン – スクラム開発事前に学んでもらう – 既存システムを知っている人 – プロダクトへの熱い想いがある人 ? IT部門の本気度 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 26. パーソルキャリアでの３つのケース 1. SoRの１機能でSoE 2. SoRのサブシステムでSoE 3. 新規事業（SoE） Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 27. Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 28. Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 29. なぜ、非IT企業で内製化ができたか？ Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 30. ? 最初は優秀なエンジニアが必要 – トップがテクノロジーで会社を変えると強い意志を示した – 共感した優秀なエンジニアがJOIN ? エンジニア採用 – まずはエンジニアに知ってもらう – メディア露出 – 勉強会への登壇、もしくは主催 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 31. ? 社内風土 – エンジニアの価値を知ってもらう – 小さい成果をコツコツだす – 所属部署以外へも積極的に絡む ? プロジェクトを回せることをアピール – 5名程度のチームで、内製BIをスクラム開発 – IT部門との調整、交渉 – 企画部門の人を巻き込み一緒に開発できると 認知してもらう Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 32. 見えた課題 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 33. 非エンジニアとのエンゲージメント Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 34. エンジニアが能動的に動かなければならない – 社内調整、業務要件整理など地道な活動も必要 – 言われた事をだけをやるのではない。 提案、ときには依頼を拒否できる非エンジニアとの 関係性を築く – 企画、営業とサービス、プロダクトについて議論すべき Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 35. 非エンジニアの上司と、エンジニアの関係性 – Tech Leadへの権限委譲。 – 育成、チーム運営についてTech Leadと一緒に考える Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 36. 変化が激しく、現場は混乱している – テクノロジーが増えすぎて選べない – スタンダードが決まるまで待てない – ビジネスに合うものが無ければ、自分たちでやるしかない – 事業会社にはアーキテクトが必要 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 37. 風土、マインド Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 38. 企業風土 – 現場に権限が与えられているか – チャレンジが推奨されているか – トップの強い意志があるか Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 39. 改善 – 無駄なプロセスを削る。従来プロセスは正しいのか？ – IT部門の強化。ベンダー任せはダメ。自分たちで動く チャレンジ – しっかりとしたシステム基盤(土台)が必要 – 土台が安定していてこそチャンレジができる Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 40. まとめ Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 41. エンジニアの役割 ? たった一人にエンジニアの力で、 大企業の風土を変えるポテンシャルがある ? 枯れた事だけではダメ。 新しい事だけでもダメ ビジネス（サービス、お客様、社員）に 良いものを選択する Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 42. 企業の課題 ? トップの強い意志がなければ、 どうしようもない ? エンジニアにも得意なフェーズ、役割がある 企業側がどの位置にいるかを 把握しないといけない – 0 → 1 – 1 → 100 – 安定を保つ Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
- 43. エンジニア積極採用中 Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved. https://www.persol-career.co.jp/recruit/engineer/
- 44. Copyright ? PERSOL CAREER Co., Ltd. All Rights Reserved.
Editor's Notes
- #4: 総合人材サービスのパーソルキャリア株式会社は、誰もが前向きに仕事と向き合える社会の実現を目指し、 転職サービス「DODA」やアルバイト求人情報サービス「an」など、求職者と企業に向けた、 幅広いサービスを提供しています。 また、リファーラルリクルーティングの「MyRefer」、オープンイノベーションプラットフォームの「eiicon」などの 新規事業、新卒事業、エグゼクティブ事業を展開しております。 2017年7月1日に、株式会社インテリジェンスから社名変更し、新グループブランド「パーソル」の認知度を高めることで、パーソルグループの総力をあげて、雇用や労働に関する社会課題の解決を目指します。
- #6: さて、本セッションですが、このような方々を対象に、何かの参考にしていただければと思います。 ITプロジェクトをマネジメントされている。または、これからされる方 レガシーとか、モダンとか言われている開発の、どちらかのみ経験されている方
- #7: 「異なるIT流儀」 流儀とは、やり方?しきたりという事ですが、ITでの流儀とは？ １つとして、開発プロセス?手法が思いつきます。 目標2分
- #8: 今回のテーマの「System of Record」と「System of Engagement」 変化が少なく、システムの安定性求められる「System of Record（SoR）」と、 スピーディに開発?改善することが求められる「System of Engagement（SoE）」 これは、2011年にジェフリー?ムーア氏によるホワイトペーパーで提唱されました。 タイトルは、「System of EngagementとエンタープライズITの将来」
- #9: 2011年当時、FacebookやTwitterなどのSNS、iPhoneなどのモバイル端末が、爆発的に浸透しました。 これにより、みなさんもご存知のとおり、ビジネスを取り巻くIT環境も大きく変わりました。 そのような変化の激しい中で、スピーディーに対応するためのエンタープライズのあり方を提唱したので 「System of Engagement」です。
- #10: ホワイトペーパーにある対比の抜粋です。 では、SoRとSoEは、対立する流儀なのでしょうか？
- #11: 提唱者のムーア氏も「正しいアーキテクチャは、SORの上で動作するSOE」であると述べています。 SORがなければ、ビジネスをすることは不可能です。 ただ、コスト、品質、契約上のコミットメントに重点を置いています。 SOEはビジネスの複雑さに対処するものです。 「正しくSORの上でSOEが動作する」ことで、ビジネスの進化が起こるのです。
- #13: モードワンは、ニーズを受けて開発するもので、要件は理解され、技術面の知見があり 計画可能なものを指します。 モードツーは、可能性を探るもので、要件は定まっていませんし、技術面も知見がなく 計画不可能なものを指します。
- #14: モードワンとモードツーの対比表です。 モードワンとモードツーは対立するものなのでしょうか？
- #15: モードワンとモードツーは、それぞれでサイクルが繰り返されます。 モードワンは、ビジネス上のニーズを受け、計画可能であるのもをサイクルで回します。 モードツーは、不確実で計画不可能なものを回します。 ここで重要なのでは、モードツーでの取り組みで成功、定着したものがモードワンへ移行することです。 サービスにおいて、全てが変わり続けることはなく、固定化される部分はあります。 そのような部分がモードワンへ移行します。 よく、ウオーターフォール開発とアジャイルを対比し、ウオーターフォールは悪いものであると言われていますが 私は、そうは思いません。 うまく、SoRとSoE、モードワンとモードツーを組み合わせ、適切なときに適切な方法で開発すべきだと考えています。
- #16: パーソルキャリアでSoRとSoEを使い分けたかを３つケースでお話しします 目標10分
- #19: 基干システムに机械学习を取り入れたケースです。
- #20: 元々、弊社のシステム開発は、外部ベンダーもしくはグループ会社への外注でした。 また、データアナリストは在籍しており、Rによるモデル開発などは行っていました。 ただし、データアナリストは、システム開発の経験はありません。 また、ベンダーも機械学習をシステムに取り入れた経験はありませんでした。 機械学習のシステムに組み込みことへの計画ができませんでした。
- #21: このように知見がなく計画不可なものを開発する場合、トライ＆エラーで開発する必要があります。 やって初めて気づく問題点や、徐々に蓄積されるナレッジがある。 受託開発で行う場合、トライ＆エラーで試す目的で変更管理工数を多めに持っておく手がありますが、 変更管理も見積もりや、スケジュール計画などで、スピード感が出ませんでした。 リリース後も問題生じます。 検証時に試したデータと、本番のデータは異なるため予測モデルの結果が悪い場合があります。 そのような場合は、データ加工の変更や削除などを行ったりしますが、 受託開発だとスピードが出ませんでした。
- #22: 「難易度が高くTry & Errorで進めるもの」「ナレッジを内部に残したいもの」は内製化が必要でした。 データアナリストとエンジニアが協業し、短いサイクルで検証?開発を進めることができます また、内部で開発することでナレッジも残ります。
- #24: 既存の基幹システムに追加サービスをスクラム開発で導入した話です。 目標15分
- #25: 企業様が候補者様へオファーメールを出せるサービス B2Bでありながら、B2Cに近いサービスです。 それまでにも多くのサービスを開発してきましたが、 従来の企画ですとユーザに喜ばれるサービスがわかりづらく、ユーザからのフィードバックを早くを得たいという 企画側の要望がありました。 機能のデリバリーを早くしたいという要望もありました。 このような課題では、SOE、スクラム開発が適切です。 そこで、その基幹システムの担当であったIT部門が主体でスクラム開発を行いました。 とは言え、そう簡単にできるものではありません。 スクラム開発を実践した中で、大切であったものをあげます。
- #26: １つ目のは、PO プロダクトオーナーの育成です。 POは、そのサービスの企画者ですので、サービスへの理解も想いも一番ですが、 スクラム開発をするためのPOとして活動はできません。 そこで、プロダクトバックログの回しをマスターしてもらいました。 POが主体に回せないと、全体が回らないので必ずやる必要があります。 POが主体で回すべきですが、もちろん、任せたままにせずに開発側もサポートが必要です。 ２つは、開発メンバーにスクラム開発を事前にまなでもらいました。 チームで学んでもらうと必然的に牽引役で出ていますので、協力をしながら開発を回しました。 ３つ目です。 やはり必ずやりとげるという意志です。
- #27: 目标20分
- #28: いくつかの新规事业が厂翱贰型开発を行っています。
- #29: これらのような、新しい技术を导入しています。
- #31: やはり最初は優秀なエンジニアが必要です。 では、どうやって優秀なエンジニアに来てもらったのでしょう それは、TOPが意志を明確にすることでエンジニアも安心できます これは、エンジニアに限ったことではありませんね。 次にエンジニアを採用ですが。 まずは、エンジニアの方々に会社を知ってもらう必要があります。 メディア露出。 Webメディアにエンジニア自ら営業をかけた。
- #32: 小さな成果。 VBAマクロから小規模なWebシステムまで作成し、業務へのインパクトを理解してもらい信頼をえました また、所属部署以外にも相談やツールの提供などし、エンジニアの価値を多くの方に理解してもらいました。 今まで外注する文化でしたので、１から開発できるイメージもなかったはずです。 やはり効果的だったのは、エンジニアだけで回すのではなく、企画の人も巻き込んで 一緒にプロジェクトが回せることを理解してもらったことです。
- #33: このようなケースを経験することで、他でも発生するであろう課題が見えました。 目標25分
- #34: 非エンジニアとのエンゲージメント いかに、非エンジニアの方々と絆をきづくかです
- #35: まず、エンジニア自身で動かなければいけません。自走できるかです。 実装だけではなく、調整とか地道な行動も重要です。 言われたことだけやるではなく、ビジネスに必要な提案もすべきでしょう。 また、ビジネスに不要なことであれば、拒否するもの重要です。 特に新規でサービスについてな、企画?営業をサービスについて、エンジニアから積極的に議論すべきです その議論で互いの認識?意志がすりあっていきます
- #36: エンジニアが少ない場合、上司に非エンジニアとなるのよくあります。 エンジニアチームの方針であったり、進め方などで文化的面でわからないことが多い 非エンジニアの上司は、テックリードに権限委譲し、エンジニア文化にあった進め方でやってもらう。 育成やチーム運営方針は、上司とテックリードで 異文化をうまく すり合わせる
- #38: 目标35分
- #39: 現場に権限。 例えば、エンジニアが開発しやすい環境が提供できますか 私が入った当初は、Macを用意するにも一苦労で、かつ開発言語も制限があった ひとつひとつ、交渉して一歩ずつ進めた
- #41: 目标40分