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

by Takaichi00

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

本日何を話すか？

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

縦割り、局所最適な組織

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

生存戦略

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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