2018年8月24日にカサレアルで開催したフリーセミナー用の発表資料です。

1. 開発現場から考える
プロジェクトで活躍する
新入社員の育て方とは？
2018/8/24
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長

2. 自己紹介
鈴木雄介
• グロースエクスパートナーズ（株）
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
• 書籍など
» Cloud First Architecture 設計ガイド
» ソフトウェアアーキテクチャが知るべき97のこと（監訳）
1

3. アジェンダ
• 開発現場の外側
• 開発現場で起きていること
»プロセスの変化
»テクノロジーの変化
• 新入社員の育て方
• まとめ
• 新人研修をやってみて
2

4. 開発現場の外側
3

5. 4https://www.flickr.com/photos/iansand/5920421391/https://www.flickr.com/photos/peaceful-jp-scenery/16346037831/
SoR
mode1
SoE
mode2

6. 開発現場の外側
企業システムの類型
• SoR（System of Record）/mode 1
»情報を正しく「記録」するためのシステム
»ユーザーは従業員が中心。取引情報を長期間にわた
って保持し、ビジネスの基幹となるシステム
»変更頻度は低め、システム障害影響大
• SoE（System of Engagement）/mode 2
»顧客や取引先との「絆」を作るためにシステム
»最新の状況を表示し、判断を行ってもらう。機能は
ユーザーごとに最適化され、高頻度で改善していく
5

7. 開発現場の外側
軸足はSoRからSoEへ
• コストとしてのITから売上としてのITへ
»ITを通じて売上（主にLTV）を向上させる
»継続利用させるための仕掛けとしてのIT
»SoRはなくならないが、より重視するのはSoE
• SoEでは仕様が決まらない
»本当のユーザーは社内にはいない
»競合他社や市場環境の変化を受けやすい
6

8. 開発現場の外側
SoRとSoEの違い
• プロセスの変化
»外部の変化に応じて仕様を変えていく
»計画主導から変更主導型へ
• テクノロジーの変化
»外部の変化に応じて性能 etc を変えていく
»変化に対応できるプラットフォーム
7

9. 開発現場で起きていること
8

10. 開発現場で起きていること
プロセスの変化
9

11. プロセスの変化
SoEな現場を取り巻く状況
• 最初に正解がない（小さなスタート）
»要件定義をしても作るものが定まらない
• 段々、変更される（素早いリリース）
»ユーザーからのフィードバックで機能を改善
• 使われるか分からない（UI/UX）
»基本的に使うことを強制できない
10

12. プロセスの変化
従来型プロセスの課題
• 最初に計画ありき
»無理にでも要件定義をしないと計画を決められない
• 曖昧な進捗管理
»進捗率80%は信用できない
• 変更を避ける
»遅延が発見されても「なんとかする」と思いがち
11

13. プロセスの変化
求められるプロセス
• 小さな計画でスタートする
»今、何をするのかを明確にして取り組む
• 定期的に動くもので進捗確認
»短い期間で動くソフトウェアを作り、全員で確認
»動かないことも成果として評価する
• 定期的に作るものを見直す
»今、優先度が高いものがどれか
12

14. プロセスの変化
計画主導から変更主導へ
• 計画主導
»スコープを固定化しスケジュールやリソースを計画
»大きな計画をベースラインに差分を調整していく
• 変更主導
»スケジュールやリソースを固定化しスコープを変更
»小さな計画を繰り返す＝定期的に計画を見直す
»いわゆるアジャイル開発
13

15. プロセスの変化
スクラム
14
スプリント
プランニング
スプリント
レビュー
スプリント
バックログ
デイリー
スクラム
プロダクト
バックログ
インクリメント
プロダクト
プロダクト利用
仕様検討
スプリント
レトロスペクティブ
開発作業
リリース
フィードバック
顧客
プロダクト
オーナー
開発チーム
アイデア

16. エンジニアに与える影響
自分で考えるようになる
• 考えて行動するのは簡単じゃない
»内部統制以降、ルールに従うことが優先であった
• 変更主導の場合、最初に手順が確定しない
»自分で手順を考える癖がないとうまくいかない
• アジャイルは考えることを助ける
15

17. エンジニアに与える影響
考えることを支援する仕組み
• 小さな成果物
»成果物が小さいので具体的に手順を考えられる
• 定期的な評価
»定期的に成果に対する評価がされる
»だから、手順も改善されていく
• チーム意識
»困ったらチームで考えて、チームで解決する
16

18. 開発現場で起きていること
テクノロジーの変化
17

19. テクノロジーの変化
SoEな現場を取り巻く状況
• 最初に正解がない（小さなスタート）
»要件定義をしても作るものが定まらない
• 段々、変更される（素早いリリース）
»ユーザーからのフィードバックで機能を改善
• 使われるか分からない（UI/UX）
»基本的に使うことを強制できない
18

20. テクノロジーの変化
従来型テクノロジーの課題
• モノリシック（一枚岩）
»部分の変更が全体に波及してしまうので調査やテス
トに時間がかかる
• アプリとインフラの分離
»アプリ実装とインフラ構築にギャップがある
»簡単にスケールできない
• 運用は安定稼働が目的
»リリース手続きの煩雑化
19

21. テクノロジーの変化
求められるテクノロジー
• サービス連携
»部分の変更が全体に影響しないことを保証する
»小さなサービスを連携させてシステムとする
• 仮想インフラ/ミドルウェア
»コーディング可能なインフラ/プラットフォーム
• 自動化
»リリースも運用管理も自動化して日常化する
20

22. テクノロジーの変化
計画主導から変更主導へ
• 計画主導
»スコープを固定化し巨大な一枚岩のシステムを構築
»それをベースラインに増改築を繰り返す
• 変更主導
»必要なだけサービスとして作り、連携させる
»変更はサービスの単位で行われ全体に影響しない
»いわゆるマイクロサービスアーキテクチャ
▸クラウド、DevOps、マイクロアップ/フロントエンド
21

23. エンジニアに与える影響
自分で考えるようになる
• 考えて行動するのは簡単じゃない
»標準化ではルールに従うことが優先であった
• 変更主導の場合、最初に手順が確定しない
»自分で手順を考える癖がないとうまくいかない
• マイクロサービスは考えることを助ける
22

24. エンジニアに与える影響
考えることを支援する仕組み
• 小さなサービス
»標準化不要。サービスの範囲で責任をもつ
• 品質を積み上げる
»段階的に作るため品質保証を早期から工夫しないと
自分が大変になる
• チーム意識
»困ったらチームで考えて、チームで解決する
23

25. 新入社員の育て方
24

26. 新入社員の育て方
自分で考えられるようにする
• 「ルールに従う」ことから「自分で考えて行動
できる」ようになることが最初の目標
»規律から自律へ
• チームの中の自分
»「私個人」＋「チームメンバー」
»自分自身で考えることも大事だが、チームに助けて
もらうことも大事
»あくまでもチームとしてのパフォーマンスが重要
25

27. 新入社員の育て方
チームに参加する
• 臆せず意見を言えるようになるのが理想
»上司と部下、チームメンバーの使い分け
»技術的には自分がエキスパートになるかもしれない
• ティーチャーとフォロワー制度
»ティーチャー（2-3年目）：一緒に仕事を教える
»フォロワー（5年目以降）：色々な相談相手
26

28. 新入社員の育て方
チームで育てる
• 小さい範囲で見積や計画をさせる
»失敗してもいいからやってみることから
• 「なぜそう思ったの？」を聞く
»「なんとなく」「言われたから」を許さない
• 他人が評価できるものを成果設定させる
»主観的な「できました」は成果ではない
27

29. 新入社員の育て方
チームで育てる
• 技術は全体感の流れの理解から
»「理解しないなら使わせない」は老害
▸もちろん、理解しないと使えない技術もありますが
• こう動かしたいという情熱をかき立てる
»どう動かせば価値があるか、を考えさせる
»興味をもったことから深く理解するのも1つの道
28

30. 新入社員の育て方
難しいパズルを解けるだけはダメ
• 難しいパズルを解くのは楽しい
»問題解決能力はエンジニアとしてとても大事
• 解くべきパズルを見つけるスキルを
»せっかくの能力を発揮する場所を間違えない
»ビジネスセンスのあるエンジニアになってほしい
▸ITがビジネスのコアになるなら、エンジニアがビジネスの
コアになっていくはず
29

31. まとめ
30

32. 開発現場の変化
ビジネスの変化が開発現場へ
• SoRからSoEが重視されるようになってきた
• SoEでは最初に正解がない
»最初のリリースを小さくしたい
»変化に合わせて素早くリリースしたい
»使いやすさ（UI/UX）にこだわりたい
31

33. 開発現場の変化
テクノロジーもプロセスも変わる
• 計画主導
»最初にスコープを定めて大きな計画を作る
»計画と元に予定を決定し、微調整を行っていく
»全体最適化されたモノリシックなものを作る
• 変更主導
»今、必要なことの集中する小さな計画を作る
»チームを固定化し、定期的に見直す
»チームがサービスを管理し、それらを繋げる
32

34. 新人社員の育て方
自分で考えられるようになる
• ルールに従うことだけではダメ
• チームの中の自分として考える
»小さく試行錯誤させることが大事
»失敗しないと学ばない
• 動かすことに情熱を持たせる
»技術的なモチベーションを生み出す
33

35. 新人研修をやってみて
34

36. 新人研修をやってみて
従来の新人研修への不満
• 設定された課題をこなすことがゴール
»100点を取ることが目標になりがち
• チーム内のコミュニケーションが古い
»文書か口頭でしかやり取りされない
• そもそも技術がダサい
»JavaとSQLだけの現場なんてなくなる
35

37. 新人研修をやってみて
感想
• チームのやり方になじむのが早い
»ツール：チケット管理、Git、IDE
»プロセスやマインド：アジャイル（Scrum）
• アーキテクチャの理解ができている
»SPA、APIなど
• 技術的な理解度は例年通り
»ただし、幅の広さを知ることで学ぶ意欲が高い
36

38. Q&A
37