コミュニティ

2019年10月31日

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

Aws4 request&x amz signedheaders=host&x amz signature=3c34d0fa6997e32a9485071d3f2ae28cc365ddd5e8b9c5f123c4cbefbbfb210d

2019年10月30日(木)にLAPRAS株式会社様の人事エンジニアリング勉強会にて、DIVE INTO CODEの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社として、DIVE INTO CODEも第4回目となる10月30日(木)に「チーム開発講座」を開講させていただきました。担当した講師は弊社CTOの藤澤です。

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

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

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

Image from Gyazo

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

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

4つの特徴を持つ開発の枠組み。

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

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

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

4つの価値を重んじる開発全般
1. プロセスやツールよりも個人と対話を
2. 包括的なドキュメントよりも動くソフトウェアを
3. 契約交渉よりも顧客との協調を
4. 計画に従うことよりも変化への対応を
価値とする。

すなわち、左記のことがらに価値があることを認めながらも、右記のことがらにより価値を置いている。
ジャスト・イン・タイムでのソフトウェアリリースを強調した開発の枠組み。
顧客への価値提供に必要なタスクを作成し、そのタスクの進捗をプロジェクト関係者が理解するためにボードに貼って視覚化する。

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

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

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

Image from Gyazo

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

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

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

Image from Gyazo

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

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

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

Image from Gyazo

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

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

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

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

Image from Gyazo

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

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

Image from Gyazo

そしてカンバンは、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の数以上のカードを貼ることはできないというルールです。

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

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

Image from Gyazo

カンバンの効果

  • ボトルネックの見える化
  • 価値の流れを管理
  • 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.DIVE INTO CODEのチーム開発講座を受講されてみてください!
DIVE INTO CODEの「チーム開発講座」の詳細とお申し込みこちらです。GitHubを使ったチーム開発の手法を身につけることができますので、ご興味のある方はぜひご受講ください!

DIVE INTO CODEのことをもっと知ってみませんか?