【JTF2019】日系大企業で2年間アジャイル開発を経験した新卒エンジニアが考える、「なりたい組織・人物像」とは？

Transcript

1. 日系大企業で2年間アジャイル開発を経験した新卒エンジニアが
   考える、「なりたい組織・人物像」とは？
   #JTF2019 #JTF2019_F
   髙市 智章 (Tomoaki Takaichi)
   Dec, 08, 2019 JTF2019
   

   View Slide

2. 自己紹介
   @Takaichi00
   tomoaki.takaichi.5
   ・髙市 智章（タカイチ トモアキ）
   ・ソフトバンク株式会社 入社3年目
   ・Java でのシステム開発
   ・アジャイル開発実践
   ・ショップ向けシステムの開発
   

   View Slide

3. 本日何を話すか？
   

   View Slide

4. ❏ 日系大企業
   ❏ 大企業ならではの悩み
   ❏ 新卒エンジニア
   ❏ 若いエンジニアの考えていること
   ❏ 組織・人物像
   ❏ 組織、エンジニアの生き方に課題を持っている
   本日何を話すか？
   

   View Slide

5. ❏ 業務委託中心の開発により、開発できる社員が減少
   ❏ 若手のモチベーション低下
   ❏ プロジェクトの難航が目立つように
   ❏ 「社員中心」「アジリティ高いシステム開発」を目標とし
   たワークグループが発足
   配属した部署の背景
   

   View Slide

6. 配属 ~ 1年目前半
   予約システム開発
   

   View Slide

7. 配属 ~ 1年目前半 業務概要
   ❏ オンライン予約システムの構築
   ❏ 組織として以下のことを目標としていた
   ❏ 社員中心の開発を推進する
   ❏ アジャイル開発実践、社内教育
   ❏ 内製フレームワークでの開発、改善要望出し
   ❏ ベテランエンジニア1名, 中堅エンジニア1名, 新人4名
   

   View Slide

8. 1年目後半
   某社内システム開発
   

   View Slide

9. 1年目後半 業務概要
   ❏ 某社内システム案件管理システムの構築
   ❏ 引き続き以下の組織目標は継続
   ❏ 社員中心の開発を推進する
   ❏ アジャイル開発実践、社内教育
   ❏ 内製フレームワークでの開発、改善要望出し
   ❏ エンジニア5名, 新人1名(自分)
   ❏ 途中エンジニアの入れ替え、外部エンジニアの参加が発生
   ❏ Sprint0 のやり直し、プロジェクトの中断
   

   View Slide

10. 2年目
    某オンライン販売システム
    

    View Slide

11. 2年目 業務概要
    ❏ 某オンライン販売システムのリプレイス
    ❏ 初めて商用リリースを経験することになったプロジェクト
    ❏ 内製フレームワーク + JavaEE での開発
    ❏ 約1年間のプロジェクトでメンバー構成が大きく入れ替わる
    ❏ 1年間通して携わったのは3名
    ❏ 2年目のエンジニアや新人4名の参画、外部コンサル
    ❏ Sprint0 のやり直し、リリース間際のスケジュール遅延
    

    View Slide

12. 3年目
    ショップ向けシステム
    

    View Slide

13. 3年目 業務概要
    ❏ ショップの方が利用するシステム開発
    ❏ SpringBoot, Quarkus などの一般的な Java フレーム
    ワークによる開発
    ❏ ベテランエンジニア1名、3年目以下のエンジニア3名
    ❏ 7月より2名、10月より1名の新人が参画
    

    View Slide

14. 業務を通して考えた
    「組織」について
    1年目 2年目 3年目
    予約システム
    某社内システム
    某オンライン販売システム
    ショップ向けシステム
    

    View Slide

15. 体験した X 理論と Y 理論による
    組織マネジメント
    

    View Slide

16. 体験した X 理論
    ❏ 某社内システム開発当時、開発が思うように進まないとき
    に受けたマネージャーの方からの指摘
    ❏ リリースまでに必要なポイントから逆算して、 X ポイントのベロシティを
    出さなければいけない
    ❏ 多少開発者に圧をかけ、急いでやらせたほうがいい
    ❏ 見積もりより早くタスクが終わったらその人はサボってしまう。シニアエ
    ンジニアはより多くのタスクを消化し、それを評価にするんだ
    ❏ ⇒これは「大規模スクラム」で記載されている、フレディック・テイラー氏と
    アンリ・ファヨール氏が考えたマネジメント
    ❏ このマネジメント手法では自ら考えなくなり自己組織化の弊害につながる
    

    View Slide

17. 体験した Y 理論
    ❏ 現在のマネージャーの方のスタンス
    ❏ 開発の事はすべて任してくれる
    ❏ 権限を与えようと組織に働きかけてくれる
    ❏ 「チームは全力を出している」と信じてくれている
    ❏ するとチームも「期待を裏切ってはいけない」と奮起する
    といったことが起きる
    ❏ ⇒ チームの自己組織化を促進するマネジメント
    

    View Slide

18. 新しいマネージャーのあり方
    ❏ 新しいマネージャーのあり方を考える
    ❏ 「Less の組織においてマネージャーは、組織の価値提供能力を高めるこ
    とに注力します。マネージャーの仕事は改善です！」
    ❏ 「Craig Larman, Bas Vodde (2019) 大規模スクラム」 より
    ❏ サイボウズさんはユーザー価値の最大化という理想のもと
    組織改革を行った結果、マネージャーを廃止
    ❏ マネージャーの役割はチームに分散させた
    ❏ 個人やチームが動きやすくなることを支援する組織へ
    ❏ 「組織変更したら部長がいなくなりました」
    

    View Slide

19. 「上層部の圧力による偽りのベ
    ロシティ」問題
    

    View Slide

20. ❏ 某オンライン販売システムで、リリース直前になり、とて
    もリリースできる品質や実装になっていないということで
    遅延を決断
    ❏ それまでは「順調」と報告し続けていたため大きな問題となった
    ❏ 自分が考える主な原因は以下
    ❏ 「期限必達」かつ、既存システムのリプレイス案件だったため
    「スコープは不変」というプレッシャー
    ❏ 一度もリリース経験のない開発チーム、スキル不足
    「上層部の圧力による偽りのベロシティ」問題
    

    View Slide

21. ❏ チームの目標が「リリースまでに必要なストーリーポイン
    トを消化し切ること」にすり替わってしまった
    ❏ 見かけ上の進捗は確かに順調
    ❏ プランニングをし、PO とキャパシティ調整をしても「どうせ後が
    きつくなるだけだから」
    ❏ 慢性的な残業、スプリントレビュー前の休日出勤
    ❏ テストカバレッジが「30%」と堂々と表示されていながら放置
    ❏ 守られない Done の定義、タスクの完了条件
    「上層部の圧力による偽りのベロシティ」問題
    

    View Slide

22. 「上層部の圧力による偽りのベロシティ」問題
    ❏ このような状況でも、期限必達のプレッシャーから当初は
    リリースを強行しようとしていた
    ❏ しかし当時、外部から来ていただいたスクラムマスターの
    方からの一言で目が覚める
    ❏ 「Done の定義も守られていない、品質がいいのかも悪
    いのかもわからない、こんな状況でリリースしようと
    しているその考えはダメだ」
    ❏ ここからチームは立て直しの体制を取ることができた
    

    View Slide

23. 「上層部の圧力による偽りのベロシティ」問題
    ❏ 失敗する、上手く行っていないということをオープンにできな
    いと組織は悪い方向へ進む
    ❏ 不安なものは先延ばしにし、確実にできるものを優先してしま
    うという人間の特性があることを認知する
    ❏ 「ベロシティ」を評価軸にすることのリスク
    ❏ 「Done の定義」の重要さ。Undone は定期的に返済する
    ❏ 「靴紐も結べない人が正しくスクラムを実践してもゴミを生み
    出すだけ」
    ❏ 評価に関係のない第三者による指摘の重要性
    

    View Slide

24. 「上層部の圧力による偽りのベロシティ」問題
    ❏ 色々な本を参考にする
    ❏ 今考えれば本に書いてあることのアンチパターンを踏みまくっていた
    

    View Slide

25. 縦割り、局所最適な組織
    

    View Slide

26. 縦割り、局所最適な組織
    ❏ クラウド環境構築時、従来のセキュリティポリシーが弊害
    となり作業が難航
    ❏ 開発側...
    ❏ PaaS 製品などを駆使して徹底的に自動化をしたい
    ❏ セキュリティ、インフラ側...
    ❏ 社内の重要なセキュリティを守るため、開発に好き勝
    手させるわけには行かない
    

    View Slide

27. 縦割り、局所最適な組織
    ❏ 上層部にエスカレーションし組織の垣根を超える
    ❏ 一緒に環境を構築するワーキンググループを作る
    ❏ お互いのミッションをぶつけ合うのではなく、共に協
    業することで問題を解決していく
    ❏ 時間はかかるかもしれないが、アジャイル / サイボウ
    ズさんのようなロールモデルを参考に、継続的に組織
    改善の必要性を上層部に伝える
    

    View Slide

28. エンジニアとしての生き方
    

    View Slide

29. 「教育係」で気をつけること
    

    View Slide

30. 「年次バイアス」を意識する
    ❏ 日本人は「ハイコンテクスト」かつ「年上を尊重する」
    ❏ 東南アジア系に顕著に見られる
    ❏ 教えられた側から反論がないからと言って自分が正しい、
    上手くやれていると錯覚しない
    ❏ 年次を取れば取るほど慎重に謙虚に学び続ける。これは
    合っているのかどうかを慎重に判断する
    ❏ 同時に年次関係なく議論ができる環境が必要
    

    View Slide

31. ❏ 「成功の循環モデル」はダニエル・キムが提唱したループ図。組織として成果を
    上げていくためにどのような観点でカイゼンに取り組むべきかのフレームになる
    (カイゼンジャーニーで知りました)
    好循環サイクル:
    (関係)お互いに尊重し一緒に考える
    (思考)気づきがあり面白い
    (行動)自分で考え、自発的に行動する
    (結果)成果が得られる
    (関係)信頼関係が高まる
    悪循環サイクル:
    (結果)成果が上がらない
    (関係)対立が生じ、押しつけや命令が増える
    (思考)面白くなく受け身になる
    (行動)自発的・積極的な行動が起きない
    (結果)さらに成果が上がらない
    成功の循環モデルを意識する
    関係の質
    思考の質
    行動の質
    結果の質
    ○ 良い起点
    × 悪い起点
    

    View Slide

32. 生存戦略
    

    View Slide

33. ❏ 「この会社に所属している」ということをアイデンティ
    ティにしない。会社がなくなったら自分はどうなるのか？
    ❏ 業界で著名な方、大きなな影響力を及ぼしている人は社名
    を看板にしているだろうか？
    ❏ 親戚に社名を話せば「凄い」と言ってくれることもある
    が、それは会社が凄いのであって自分が凄いわけではな
    い。それで自分は凄いと勘違いして慢心してしまうのが一
    番怖い。
    ❏ 自分を看板にすることを意識する
    社名ブランドの看板を頼りにしない
    

    View Slide

34. ❏ 認知度が高い大企業だからこそ得られる機会もある
    ❏ 色々な方、コンサルさんとの仕事をする機会
    ❏ 様々な研修に行けるチャンス
    ❏ コンサルに来てくださった方による執筆の紹介
    ❏ マイクロソフトさんとのハックフェスト
    ❏ JJUG などのカンファレンス登壇
    ただ、社名による機会は自分に活かす
    

    View Slide

35. 著名な方のエンジニアとしての生き方を参考にする
    ❏ 和田卓人さんの「エンジニアとしてこの先生き残るために」
    ❏ ロードマップ指向とエコシステム指向
    ❏ 四半期毎に技術書を読む
    ❏ 写経する、量は質に転化する
    ❏ まつもとゆきひろさんの「プログラマー勉強方法」
    ❏ 知名度とその人の価値は可換である
    ❏ 社会人の勉強は100点が上限ではない
    ❏ アウトプットを行うことで差別化できる
    

    View Slide

36. 「わかりやすい成果」を出す
    ❏ 自分は「優秀」に属する人ではない
    ❏ この業界には幼い頃から機械やプログラミングが好きで、
    それを生業にしている人が数多いる
    ❏ 自分は幼い頃から機械好きでもなく、ソフトウェア工学を自ら勉
    強していたわけでもない
    ❏ そんな中で生き残るには、誰が見てもわかるような成果を
    継続的に出すしか無い
    

    View Slide

37. 発表することで知識を深める
    発表する
    内容に責任が生まれる
    理解を深め
    知識を広げなければならない
    

    View Slide

38. 外部発表に向けて「ネタ」を仕込む
    ❏ JJUG での発表を意識し、Quarkus の商用導入を決定
    ❏ 外部に発表するというモチベーション
    ❏ 自社の技術アピール
    ❏ チームとプロジェクトにチャレンジできる余裕とスキル
    セットがあれば、外部発表のために尖った技術にチャレン
    ジするといった戦略が取れる
    

    View Slide

39. コミュニティがなかったら作る
    ❏ 外部発表に向けてネタを仕込んでも発表する場が無い
    ❏ 普段の業務でググっても出てこないことが多い
    ❏ 他の人に話すと意外と受けが良いが特段コミュニティがあ
    るわけではない内容がある
    ⇒ 勉強会を作ってみる
    

    View Slide

40. 12/25 (水) 勉強会を開催します
    ❏ LT・一般参加者募集中です！
    

    View Slide

41. ご清聴ありがとうございました

    

    View Slide