【イベントレポート】LAPRAS株式会社様の人事エンジニアリング勉強会にて「チーム開発講座」を開催いたしました

10/30（木）にLAPRAS株式会社様の人事エンジニアリング勉強会にて、ディープロのCTOの藤澤が「チーム開発講座」を開催いたしました。その様子をお伝えします。

2019年10月30日（木）にLAPRAS株式会社様の人事エンジニアリング勉強会にて、ディープロのCTOの藤澤が「チーム開発講座」を開催いたしました。その様子をお伝えします。

LAPRAS株式会社のご紹介

「あらゆる事象を必然化し、世の中のミスマッチをなくす」というミッションの基、個人向けのサービス「LAPRAS」と企業向けのサービス「LAPRAS SCOUT」を運営しています。

＜LAPRASについて＞
LAPRASはWEB上に公開されているSNSやGitHubなどのオープンデータを活用したスキル情報の可視化プラットフォームです。公開されているレポジトリやブログ記事、イベント参加状況やSNSプロフィールなどを基にして、エンジニアのスキルや志向性、転職の可能性を判定したポートフォリオを自動生成しています。
自身のポートフォリオは、LAPRAS上で認証を行うことで確認できます。

＜LAPRAS SCOUTについて＞
LAPRAS SCOUTは、人工知能によりインターネット上のオープンデータから情報を取得して、人々の能力を自動分析し、最適な企業とマッチングする登録不要の新しい転職サービスです。経験年数や希望年収などの単純な数値情報だけでなく、自分の書いたコードやブログ投稿のような定性的な情報もふまえた本質的なマッチングが可能です。エンジニアに対して本人も知らないようなより良い環境や職場を提供することを目的としてサービスを展開しています。

講座の開催背景

2019年9月、LAPRAS株式会社様はプログラミングスクール7社と共同で、人事担当者向けに「採用に必要なエンジニアリング知識」を教える人事向けエンジニアリング学習講座を開講されました。10月9日に実施する第1回の講座を皮切りに、2019年中に全7回の無料講座が、LAPRAS株式会社様とプログラミングスクールの共同で開催される予定です。

講座が開催された背景には、「売り手市場のエンジニア採用で、弊害となっている人事の知識不足」があります。
ITエンジニアの求人倍率が極端な売り手市場となっている現在においても、多くの企業にとってITエンジニアの採用は大きな課題となっています。人事担当者にエンジニアリング知識が欠如しているため、採用候補者と円滑なコミュニケーションが取れなかったり、適切な採用候補者を見極めることができないという問題が起こっています。

LAPRAS株式会社様は、日本初のAIヘッドハンティングサービス「LAPRAS SCOUT」を運営し、企業の人事担当者の方を対象にサービスを提供されています。エンジニアリング知識の欠如という問題を重く捉えられており、その問題を解決することにより、人事担当者の方のスキルアップやエンジニア採用業務に対してのハードルを下げることを目指していらっしゃいます。

こうして、同様の課題感を持つプログラミングスクール7社とともに、人事向けのエンジニアリング学習講座の開講が決まりました。その7社のうちの1社として、ディープロも第4回目となる10月30日（木）に「チーム開発講座」を開講させていただきました。担当した講師は弊社CTOの藤澤です。

■LAPRAS株式会社様の人事向けの無料講座に関するプレスリリースはこちら

■今回の講師の藤澤のインタビュー記事「CTO・藤澤勇樹さんインタビュー 『自動テストを用いた“講師ロボットの開発”で、プログラミング教育の新しいスタンダードを作る』」はこちら

チーム開発の枠組みと、それを支えるツール・役割の用語解説

チーム開発に関して、人材がいなくて困られている会社様は結構いらっしゃるのではないでしょうか。
エンジニア採用に携わる人事の方にとっては、「コードを書く」といったプログラミング知識ではなく、エンジニア採用のための用語理解が必要になります。今回の講座では、チーム開発の枠組みの歴史からお話し、チーム開発の枠組みとそれを支えるツール・役割を深く理解していただくことを目指しました。用語だけを聞くとおもしろくないかもしれませんが、歴史や背景から学ぶとおもしろく感じるのではと考え、このようなアプローチを採用しています。

まずは力試しとして、用語の理解度チェックを行ないました！
次の用語が何を表しているのか、会場のご参加者にお答えいただきました。

①	4つの特徴を持つ開発の枠組み。 1. スプリントという一定の期間毎に動くソフトウェアを作る 2. 要求はプロダクトバックログという優先順位付けされた一覧表に保管される 3. 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する 4. スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行なう
②	ムダの無い生産方式という意味。

正解は、①がスクラム、②がリーンです。

さらに会場の皆様への理解度チェックが続きます。

③	4つの価値を重んじる開発全般 1. プロセスやツールよりも個人と対話を 2. 包括的なドキュメントよりも動くソフトウェアを 3. 契約交渉よりも顧客との協調を 4. 計画に従うことよりも変化への対応を 価値とする。 すなわち、左記のことがらに価値があることを認めながらも、右記のことがらにより価値を置いている。
④	ジャスト・イン・タイムでのソフトウェアリリースを強調した開発の枠組み。 顧客への価値提供に必要なタスクを作成し、そのタスクの進捗をプロジェクト関係者が理解するためにボードに貼って視覚化する。

正解は、③がアジャイル、④がカンバンです。

これらが、今回の講座で覚えて帰っていただきたい4つのキーワードです。

1．チーム開発の枠組みの歴史から用語を理解する

チーム開発の枠組みとは、「フェーズを組み合わせたものが枠組み」を指します。代表的な枠組みには、「ウォーターフォール開発」や「アジャイル開発」などが挙げられます。
そして、フェーズとは、「要件定義」、「設計」、「開発」、「テスト」、「リリース」のことを指します。

ウォーターフォール開発は、これらのフェーズが上流から下流へ順次移行していくような開発手法のことで、フェーズごとに完了していきます。これに対してアジャイル開発は、各フェーズの機能単位での実装・テストというサイクルを繰り返すことで開発していく手法を言います。

ここから、チーム開発の枠組みの歴史のお話に移ります。
日本の製造業において、竹内弘高氏と野中郁次郎氏の論文「The New New Product Development Games」が1986年に発表されています。その中で、NASA等の「米国型プロセス（ウォータフォール）」と日本の「新製品開発のプロセス（スクラム）」を比較し、今で言う「ウォーターフォール開発」と「アジャイル開発」を比較しています。

皆が集まってひとつの部屋で会話をしながら開発をする、まるでラグビーのチームのような進め方の開発プロセスを「スクラム」と呼びました。よく勘違いされやすいのですが、開発者のみで組むことを「スクラム」と言う訳ではありません。マーケティングや営業など、会社が一体となって「顧客に何を届けるべきか」という目標に対してスクラムを組むのです。

ご興味のある方は、平鍋 健児氏の「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」もぜひご覧ください。

これらは、日本の製造業でのお話でした。

これに対して、野中氏の「The New New Product Development Games」 を参考にして、プロジェクト管理法として今の「スクラム」にまで進化させたのが、ジェフ・サザーランド（Jeff Sutherland）氏でした。

今回の講座では深くは触れませんでしたが、ご興味ある方は、ジェフ・サザーランド氏の「スクラム　仕事が４倍速くなる“世界標準”のチーム戦術」も合わせてご覧ください。

ジェフ・サザーランド氏は現在もご存命で、KDDI株式会社ら3社、アジャイル開発を支援する合弁会社「Scrum Inc. Japan」を設立した際の動画（「Scrum Inc. Japan設立にあたって」）に出演されています。

日本の製造業からスクラムという概念が生まれ、これが海外で進化してまた日本に再上陸するような形で戻ってきたという流れです。

次に、カンバン方式とリーンのお話です。
リーンはもともとToyota Production System（TPS）と呼ばれており、1988年にMIT（マサチューセッツ工科大学）の研究者が、TPSが従来の大量生産よりもはるかに効果的かつ効率的であることを発見し、「リーン生産」と名付けたことに由来します。高い品質のものを短い期間と低いコストで届けるために、自動化や改善などが提唱されています。

そして、先程のスクラムの流れとプログラマの方がちょうど出会った形で生まれたのがアジャイルと言えます。アジャイルの定義はいろいろとありますが、実際はシンプルです。2001年にスクラムに影響を受けた著名な17名のエンジニアが行なった「アジャイルソフトウェア開発宣言」に則ったものを「アジャイル」と呼びます。

そしてカンバンは、2010年にDavid J. Andersonという方が、”Successful Evolutionary Change for Your Technology Business“という書籍で提唱した考え方です。カンバンにご興味のある方は、「カンバン ソフトウェア開発の変革」という翻訳版もおすすめです。ぜひ原書（Intro to Kanban）とあわせてご覧ください。

ウォーターフォールとアジャイルの違い

ここで、ウォーターフォールとアジャイルの違いについて触れます。
ウォーターフォールは、一般的なサービスに適しています。「分析（要件定義）」、「設計」、「開発」、「テスト」といった大量生産方式から来ているため、要件が変わらないものに向いています。官公庁や銀行での業務改善に用いられるのは、要件定義があまり変化しないためです。一方、Web系などで要件がどんどん変わるところではウォーターフォールの導入は難しくなります。こういう場合は、市場の変化に迅速に対応する新規サービス開発という発想からスタートしているアジャイルが適しています。
1番大きな違いは、PDCAサイクルを回せるか回せないかという点が挙げられます。

※PDCAサイクルとは、Plan（計画）・Do（実行）・Check（評価）・Action（改善）を繰り返すことで、業務を改善・効率化していく手法のこと。

2．カンバンから具体的に用語を理解する

下図のようなチームを例に、カンバンについてご説明します。プロダクトオーナー、開発チーム、テストチームがいる会社をご想像ください。
「TODO」「開発」「デプロイ」という各ステージでは、WIP（Work in Progress）と呼ばれる「仕掛り作業」が制限されています。「WIP制限」とは、各ステージにWIPの数以上のカードを貼ることはできないというルールです。

プロダクトオーナーがバックログからカードを選択します。「TODO」のWIPは2なので2枚のカードを選びます。

開発チームは2枚のカードの作業に着手します。プロダクトオーナーから作業を依頼される訳ではなく、各自がカードをプル（引っ張る）しています。「TODO」にカードがなくなったため、プロダクトオーナーはさらに2枚のカードを選びます。

Aの作業が完了すると、テストチームがカードをプルして、デプロイを開始します。

開発チームは新しくカードをプルし、テストチームは完了したカードをデプロイします。

ここで、テストチームがデプロイに苦戦したとします。ビルドに失敗し、テストチームの作業が止まっていますが、開発チームがBの開発を完了させました。

手の空いた開発チームが別のカードをプルしようとしましたが、「開発」ステージ（「開発中」と「完了」の両方）に設定されているWIP2の影響で、新しい開発を始めることができません。

このような場合、開発チームはテストチームのフォローにまわります。一方、プロダクトオーナーが緊急に進めなければならないカードを「TODO」に追加しました。

開発チームの開発がまた終わりましたが、WIP制限があるため、緊急であっても新しい作業に着手することはできません。仮に作業に着手したとしても、デプロイでのトラブルが解決しない限り、テストチームの作業がボトルネックとなります。

こうして、開発チーム全員がテストチームのサポートをすることになりました。ただ、手は足りているようなので、同じような問題が再発したときに備えて、将来的に問題回避するための作業も行なうようです。

プロダクトオーナーもボトルネックのフォローへまわります。
このようにして、カンバンでカードがスムーズに流れるように、WIPの数を変更するなど微調整を続けていくのが、カンバンの本質でもあります。

カンバンの効果

• ボトルネックの見える化
• 価値の流れを管理
• WIPで個人の過負荷を防ぐ
• プル型の助け合うチームへと導く
• 価値をすばやくデリバリできる

カンバンの役割

対象	役割
プロダクトオーナー / プロジェクトマネージャー	開発チームから生み出される プロダクトの価値の最大化に責任を持つ
開発チーム	リーダーやマネージャーに責任を押し付けず、チーム主体でセルフマネジメントしていける開発者の集まり
テスト＆ リリースチーム	リーダーやマネージャーに責任を押し付けず、チーム主体でセルフマネジメントしていけるテスト＆リリース作業者の集まり

カンバンを支えるツール

ツール名	機能
Github Project	カンバン式のタスク管理をサポートする機能
Github Issue	プロジェクトやソースコードの課題のこと Issueは、バグ、機能、タスクといった単位で作成する
Github PullRequest	コードレビュー機能

まとめ

用語の理解度チェック

用語	意味	歴史的背景
スクラム	4つの特徴を持つ開発の枠組み 1. スプリントという一定の期間毎に動くソフトウェアを作る 2. 要求はプロダクトバックログという優先順位付けされた一覧表に保管される 3. 各スプリントにおいてその時点での優先順位の高いバックログ項目を基本に、開発チームがスプリント内で開発できる目標を設定する 4. スプリント毎にバックログへの項目の追加や優先順位付け、動くソフトウェアの評価はプロダクトオーナーという役割の人が行なう	1986年、野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、論文「The New New Product Development Game」から生まれた用語。 「The New New Product Development Games」 を参考にジェフ・サザーランド(Jeff Sutherland)がプロジェクト管理法「スクラム」に進化させた。
リーン	ムダの無い生産方式という意味	1980年代、MITの研究者が、TPS(Toyota Production SystemToyota Production System)が従来の大量生産よりもはるかに効果的かつ効率的であることを発見し、TPSをリーン生産と名付けたことから生まれた。
アジャイル	4つの価値を重んじる開発全般 1. プロセスやツールよりも個人と対話を 2. 包括的なドキュメントよりも動くソフトウェアを 3. 契約交渉よりも顧客との協調を 4. 計画に従うことよりも変化への対応を 価値とする。 すなわち、左記のことがらに価値があることを認めながらも、右記のことがらにより価値を置いている。	2001年、軽量ソフトウェア開発手法と呼ばれていた分野において名声のある17人が開発手法の重要な部分を統合することについて議論し、 「アジャイルソフトウェア開発宣言」(Manifesto for Agile Software Development) という文書にまとめた。 参考：アジャイルソフトウェアの原則
カンバン	ジャスト・イン・タイムでのソフトウェアリリースを強調した開発の枠組み。 顧客への価値提供に必要なタスクを作成し、その案件の進捗をプロジェクト関係者が理解するためにタスクボードに貼って視覚化する。	2010年、デイヴィッド・アンダーソン（David J. Anderson）によってまとめられた「Kanban: Successful Evolutionary Change for Your Technology Business」で生まれた。

採用業務での活用方法

1．求人票を見てエンジニアが気にするポイント
①スクラム
「会社全体で取り組んでいるか」、「あるチームだけで終わってないか」というポイントを押さえてください。

②カンバン
「カンバンボードを見てみたいが、可能かどうか」ご確認ください。

③アジャイル
アジャイル開発をされているところでは、「無計画な開発という意味ではないかどうか」チェックされてみてください。

2．差別化になる用語、ならない用語
チーム開発講座のキーワードを10個ほどまとめてみました。ぜひご参照ください。

RANK	カテゴリ	用語	求人数
1	役割	PM/プロジェクトマネージャ	3386
2	バージョン管理	Git	2789
3	コミュニケーション	AdobeXD	69
4	コミュニケーション	共通認識	65
5	役割	フロントエンド	1931
6	コミュニケーション	Slack	1817
7	ナレッジ管理	wiki	58
8	バージョン管理	Github	1731
9	プロジェクト管理	Github	1731
10	コミュニケーション	マインド	1400
11	開発手法	アジャイル開発	1321
12	バージョン管理	リポジトリ	150
13	バージョン管理	SVN	135
14	バージョン管理	commit	64
15	バージョン管理	CVS	7
16	役割	サーバーサイド	1260

採用業務で気をつけること

1．ウォーターフォール
求人内容にこの単語があると、エンジニアにとってネガティブに捉えられることが多いです。

2．アジャイル
「アジャイル開発」と言っても、決まった形がある訳ではありません。アジャイル開発宣言に則った開発という意味ですが、その意味を分からずに「アジャイル」と言っている可能性もあります。無計画という意味のアジャイル開発をしていないか、確認された方が良いでしょう。

3．スクラム
スクラムとは型にはまると、プロダクトオーナーやスクラムマスター以外は、開発全体を知らないエンジニアの可能性があります。面接で深掘りしてみても良いかもしれません。スクラム認定試験に受かっている方もいるかもしれませんが、経験があることとは別です。やはり経験があった方が望ましいと思います。

4．プロダクトオーナーになれる人材の採用や育成
プロダクトオーナーになれる人材の採用や育成は難しいです。とても貴重な存在で、マネジメント経験があるからと言って、プロダクトオーナーになれる訳ではありません。プロダクト全体を見ながら優先順位を決めるためには、開発とマネジメント、業務知識のバランスが必要とされます。

ここまで理解された方は、ぜひ次の一手を！

1．Google検索で下記のような用語を調べてみましょう！
「スクラム 野中郁次郎」、「スクラム 開発」
「リーン 開発」、「リーン TPS」
「アジャイルソフトウェア開発宣言」、「アジャイル 開発」
「カンバン 開発」

2．求人や経歴書を検索してみましょう！
「スクラム」
「リーン」
「アジャイル」
「カンバン」

3．ディープロのチーム開発講座を受講されてみてください！
ディープロの「チーム開発講座」の詳細とお申し込みはこちらです。GitHubを使ったチーム開発の手法を身につけることができますので、ご興味のある方はぜひご受講ください！