2020-02-13 Developers Summit 2020 Day1 #devsumi
2020/02/13 に開催された Developers Summit 2020 Day1 のイベントレポートです。
●イベントのテーマ
ともにつくる
●イベント概要
“Why Software Is Eating the World”という言葉の登場から8年が経過し、日本でも、多種多様な業界にソフトウェアが組み込まれることで、本当に社会を変えていることを実感するようになりました。ITエンジニアのみならず、さまざまな役割の人々にとって、テクノロジーは身近なものとなり、エンジニアは、ドメインの知識を携え、非エンジニアとも連携しながら、世の中の課題を解決する存在となりつつあります。
そして、ソフトウェアの作り方もまた、変化が求められています。エンジニアは、PaaS、FaaS、SaaSなどのクラウドの力を借り、DevOpsなどのプラクティスを駆使し、チームのパワーを最大化し、生産性を上げて価値を提供し続けることが期待されています。
ともにつくる。それは、さまざまなテクノロジーを組み合わせ、エンジニア同士が協力すること。エンジニアと他のロールのメンバーが手を取り合うこと。プロダクトの先にあるユーザーのことを思うこと。組織を越えた仲間と志を一つにすること。デブサミ2020では、一歩外へ踏み出す勇気を携え、まわりをエンパワーメントしていきたいエンジニアに対して、エールを送ります。
■質とスピード
和田 卓人 さん [タワーズ・クエスト]
●荒ぶる四天王
・時間、予算、品質、スコープ
アジャイル侍
時間に対して、やることが多すぎる
・品質を犠牲にするを選びがち
・短期的なスピードは得られる
中期的には逆効果
長期的には致命傷
●品質とは？
・品質とは誰かにとっての価値
ワインバーグ
・◯◯性
ilities
沢山ある
・狩野モデル
顧客の満足感 / 物理的な充足度
当たり前品質
減点法
商品が変える
一元的品質
あるだけすてき
商品数など
魅力品質
なくても良いけどあると魅力的
SNS連携など
・見える品質と見えない品質
見える品質 = 外部品質
見えない品質 = 内部品質
・「品質を犠牲にする」の品質
概ね内部品質
・レガシーコードからの脱却
内部品質を作り込んだ結果が、外部品質
●内部品質とスピード
・犠牲に捧げたのは？
保守性
テスト容易性
理解容易性
変更容易性
●保守性とスピードはトレードオフなのか？
・保守性を犠牲に捧げると？
クリーンアーキテクチャ
あとでクリーンにすることはない
・疲弊しきった現場
帰れなくなると
椅子で寝るスキルを身につける
テーブルの下で寝ていたり
・荒みきったコード
変更しにくい
呪いの言葉
動くコードに触れるな
・動くコードをコピーして、ちょっと変える
grepしたらコピーしたコードが10数件
真面目な人はコンテキストに合わせて、名前を変えたり
grepに引っかからず修正漏れ
・動くかどうかわからない
爆弾処理のようなリリース
・保守性の低さ（技術的負債）がもたらすもの
ひとつひとつの修正に時間がかかるように
一週間で済んでいたものが3週間かかったり
がんの様に増えていく
・スピードを落とせば、保守性は上がる？
技術力の高い人
意図的に品質を落としても速度は上がらない
技術力の低い人
技術力以上の品質は出ない
エンジニアリング組織論への招待でも
同じことを言っている
・保守性とスピードは、トレードオフではない
・トレードオフ構造を見つけて要はバランスだね
は思考が止まっているかも
●品質アップはコストアップか？
・コストアップ、コストダウンどちらも説がある
トレードオフ関係にあるか議論されてきた
・Quality is Free
品質 "実質無料"
品質向上のためのコストが
やり直しコストを上回ることで
実質無料
・エクストリームプログラミング
品質を高めることで、デリバリーが高速になる
・クリーンアーキテクチャ
短期的にも長期的にも
崩壊したコードを書く方が
クリーンなコードを書くよりも常に遅い
・リガシーコードからの脱却
コードの品質を高く保っていたからこそ早い
●スピードから質への影響は？
・品質が低い
手戻りが発生
リードタイムが増加
・リードタイムが増加すると
仮説検証サイクルが回らない
・ゆっくりしても、本当に良いのか分からない
・LeanとDevopsの科学
4つのメトリクス
リードタイム
デプロイ頻度
MTTR
昔はMTTF
間隔の長さだった
変更失敗率
●本当の関係
・質とスピードは正の相関関係
内部、外部、プロセスの品質を含めて質
・質 vs スピードが二律背反なのは局所的
帯域的には、片方を犠牲にしたら
知らぬうちにもう一つも犠牲にしている
・どうやって個人の質を上げる？
ソフトウェアの開発に最初から最後まで関わる
自分で設計したシステムを長い間メンテナンスする
・内部品質への投資の損益分岐点はいつくるのか？
3年後では会社がないかもしれない
テスト自動化の損益分岐点は、およそ4回
tacticalがstrategicに追い越されるのは、思ったより早くくる
マーティン・ファウラー
3年後とかではなく、1ヶ月以内に現れる
自分たちがメリットを受けることができる
怠ると、自分たちが損をする
・内部品質の利害関係者は開発者自身
・中期的は1ヶ月後
・荒ぶる四天王
答えは、スコープを削る
リリースを取るか機能数をとるかしかない
●「スピードと質」は何とトレードオフになっている？
・学習や成長
教育、学習、調査
多様性の確保
メンバーの成長
必要なフィードバック、学習時間
・モノカルチャーの方が早い
が、変化には弱い
■ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜
福井 勝史 さん [Insight Edge]
●自己紹介
・Insight Edge
・住友商事リードエンジニア
●Insight Edge
・住友商事グループのDXを推進するエンジニア集団
・2016からDX関連に取り組んでいた
2016 IoT & AI Working Group
2018 DX Center
外部から人を読んで組成していた
2019 Insight Edge
・ミッション
技術の力で世界をRe-Designする
・ビジョン
全てのビジネスを Digital Version upする
・DXの定義
ビジネスモデル変革
既存日自演す高度化
新ビジネス創出
これらをデジタルで進めていく
●DXプロジェクト
・住友商事グループの事業会社
国内外 900社以上
海外で 700社
B2Bが多い
・160プロジェクトくらいが進行中
●産業分野
・金属
自動車の部品など
・輸送機・建機
飛行機、船のリースなど
・インフラ
電力、発電所、水道、交通
・メディア・デジタル
ケーブルテレビ、通販、ITサービス
・生活・不動産
スーパーマケット、ドラッグストア
・生活・不動産
・資源・化学品
鉱物の採掘など
-> 各産業にまんべんなく
●ビジネスゴールによる分類
・ビジネス高度化: 91
需要予測、サブスクモデルなど
現在のビジネスをベースに考える
・新ビジネス創出: 57
マッチング、マーケットプレイスなど
・アイデア整理: 12
●利用技術による分類
・AI・データ分析: 48
・アプリ・プラットフォーム: 23
・IoT: 20
・その他
ブロックチェーン、ドローンなど
●AI・データ分析
・市場予測、需要予測、価格予測、在庫量最適化
ものを仕入れて加工して売る
安く仕入れって高く売る
経営計画の参考
・BIにる可視化
位置情報、PoS、センサー、購買
ビッグデータを集計して活用
・外観検査
・異常検知
●IoT
・エッジ x クラウド x Web/モバイル
定型化してきた
センサーを付けて、クラウドに上げて、見えるようにする
・物理的な環境、耐塩風、耐爆発などをそれぞれ考慮
●アプリ・プラットフォーム開発
・今までなかったところにモバイルアプリ導入
・B2Bマッチング/シェアリングで新ビジネス
・バリューチェーン全体の最適化
●ともにつくる「DX」
・DXの主体は「ビジネス」
ビジネスを高度化、創出するのに
デジタル技術活用は必須
・ビジネス側とエンジニアの一体化
・スタートアップとの協業
AIなどの最新技術
●進行プロセス
・相談、アイデア想起
ビジネス課題の整理
技術要素の検討
・DX施策検討
ビジネスモデル検討
BMCを書いたり
技術課題の整理
プロジェクト化
・実証実験
ビジネス実証
市場調査、ユーザーヒアリング
技術実証
・実用化検討
残存課題整理
多ければ実証実験を続けたり
Go / NoGo
実用プロジェクト化
・実用化、運用
ビジネス体制構築
実用システム開発
●重要なプロセス
・企画、設計
相談、アイデア想起
DX施策検討
・既存ビジネスの理解
現行オペレーション
課題
・新規ビジネスモデルの理解
AsIs / ToBeを整理
-> ここからエンジニアが参画
のちのち動きやすい
エンジニアとしての示唆だし
●定性効果と定量効果の文字化
・何をしているのかわからなくなりがち
文字化できなければ進めない
・予測モデルができたとして
何がどの程度良くなるのか？
そのための精度はどのくらいか？
いくら儲かるのか？
->ゴールの明確化、Go/NoGoの判断基準
・実証実験が進む前に
運用どうするの？
->エンジニア観点の示唆だし
●推進体制（従来型）
・事業
-> コンサル会社
-> ベンダー
・問題
事業部が個別に相談
ノウハウの分散
丸投げ
三者分断
費用とスピード
●自社DX人材の確保
・自社エンジニア
ビジネスの理解が容易
企画〜実現までのスピードが早い
キャッシュアウトがない
柔らかいアイデアを相談しやすい
・日本のエンジニア分布比率
ユーザ企業 : ベンダー = 3 : 7
SOE人材の不足
= DX人材かな
●推進体制（DX推進体制）
・事業
-> DXセンター
企画チーム
技術チーム: Insight Edge
投資チーム
・企画チーム
各部門でビジネスを推進してきた方
当事者意識
双方向通訳
コラボレーションを自律的に考えられる
・投資チーム
スタートアップメンバーの常駐化
課題共有
先端技術で活躍してもらう
内製力の強化
●グローバルプロジェクト
・現地の文化に合わせた支援
・現地の人が運用
現地のパートナーを連れてくる
・投資前の技術ヂューデリ
・海外スタートアップへの支援
・国内スタートアップを海外につなげる
●DXを推進するためのエンジニアスキル
・ゴール設計
ビジネス課題とデジタル課題
・フルスタック（マルチスタック）
プロトタイプを少人数で短期に
得意分野が複数
目利き
・AI・データ分析の知識
開発者も基礎的な知識は必要
-> どう伸ばす？
現場、イベント、コミュニティ
■Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦
岩根 義忠 さん [ホンダエンジニアリング]
松浦 洋介 さん [NECソリューションイノベータ]
星 直人 さん [ホンダエンジニアリング]
矢田 将 さん [ホンダエンジニアリング]
●紹介
・岩根さん
仕掛け人
・松浦さん
アジャイルコーチ
・星さん
スクラムマスター
・矢田さん
プロダクトオーナー
●ホンダエンジニアリング
・本田技研工業の子会社
・研究開発->具現化->販売の具現化
・Hondaフィロソフィ
人間尊重
なにか振り返るときの価値観になっている
●なぜアジャイル導入を目指すようになったのか？
・良い体験
タイの新工場
完成車組み立て
これまでと違うアプローチ
4-50病の組み合わせから
数百秒のワンプロセスへ
ワンチーム化
・苦い体験
数年掛けたプロジェクトだったが
1年後には使われなくなっていた
-> 必要なものが変化した
・環境の変化
各部署に一匹狼のエンジニア
自分の腕で仕事
属人化->組織化
・なんちゃってウォーターフォール
つめきらずに後続に丸投げ
新人の負担が大きい
外部に頼り切り
・ちょっと変えてみた
こんなんつくりたい パワポ
何言ってるかさっぱりわからん！
２週間やるからつくってみろ
やりたかったのはこれです 動くソフト
やっとわかった！GO
なるほどわかった！GO
ユーザーからも好反応
・ウォーターフォール的にやろうとしても
スキルがない
完全分業はHondaらしくない
●導入への道のり
・立場が変化
20人のグループリーダー
あーあ、実務できないよ〜
チームリーダー
管理は全部やるんで
先のことを考えて！
->暇な人をつくる！つくってもらった
・アジャイルに行き着いた
良いものを早くつくる
魔法はないから生産性を上げるしかない
・CVFで測ってみた
競合価値観フレームワーク
官僚文化だった
-> イノベーションを促す文化にしたい
・嬉しい出会い
NEC松浦さん
最初はアナログスタート
スクラムの期限はHondaのやり方
うちでも導入してみたいんですけど、手伝ってくれませんか？
・私的な体験
夏休みに自宅DIYでウッドデッキをフルスクラッチ制作
素人が成果を出すためには、成長しながらやるしかない
・「やる」と決めたら一気に走る
良いもの（必要なもの）を早く・高品質に提供する
・嬉しい出会い2
アジャイルジャパンにHondaの別会社の方が登壇
登壇良いね
●開発体制
・開発チームと支援チームを準備
・アジャイルを共通言語化する
セミナー開催
募集をかけたら60名以上
企画部門も巻き込めた
・VSMでボトルネック可視化
●スクラム開発開始
・ふりかえりに力を入れた
・問題が発生した次のスプリントでどれか一つでも潰していこう
いつでも Nowが自己ベスト
●SMからの7つの質問
・最初からチームとして成立していたの？
部門が混在
優先度が違う
〇〇部のヒトが足を引っ張ってくる、、、
-> 各部署からチームへ
・PO、SMはどう決めたの？
PO: 受けたのはキャリアに有益だから
SM: むちゃぶり文化。情熱はあるが温和だったから
・チームには何が一番大切？
役割に対してどんな期待値があるのか
どこで活躍できるのか
の方向を揃える
・ベロシティ上がらない、外から見えにくい、どう管理する？
一番苦しいところ
スプリントゴールを決めて動くがこなせない
ステークホルダーから責められる
スプリントゴールが弱気に
・一時的にでもベロシティを下げるプラクティスってどう？
ペアプロ、モブプロ
ものを早くつくるとはマッチしないので響かなかった
何をねらって、なにを諦めるのかの共有が必要
新しいプラクティスの導入コストを最小化する
失敗はすれば良い
・開発チームにすべて委ねるって怖い？
信頼はしていた
自分(PO)もチームの一員
アジャイルやめて も準備していたが、使うことはなかった
覚悟を決めて、チームを信じて投げるしかない
・チームの成長を促すって何をする？
学びのスピード
仮説検証の結果
小さな失敗
自転車では転ぶ経験も必要
コーチングで引き出す
●メンバーの声
・自分の声でチームが改善していく！
・ソフトだけではなく、設備・ハードにも適用できる
●不確実性コーンの実証
・アジャイルトライアル前のフルスペック仕様書
と比較して、1/4くらいのサイズに
つくり過ぎのムダだった
●マインドの変化
・なんでやってないの？
-> 一緒に考えるように
・CVFの変化
官僚文化 -> 家族文化
今後は イノベーション文化へ
●今後の展開
・対象を広げる
今は、貸オフィスの箱庭
業務フローとの齟齬
雑務、外乱
・フェーズを広げる
DevOpsへ
●導入に悩んでいる方へ
・属人的、ばらつきが多いならおすすめ
・スモールスタート、味方を増やしていく
・改善サイクルが回りだすと、感性の高い人が味方に
■クラウドサービスとゲーミフィケーション:「TwilioQuest 3」を用いた開発者オンボーディング
池原 大然 さん [Twilio Japan]
●自己紹介
・Twilio
・Developer Evangelist
●Twilioとは
・赤を基調とした会社
・コミュニケーションチャネル
クラウドを介して
プログラム可能な状態で
サービス提供
・電話、SNSなど
●デモ
・webから日本の電話番号を買う
・電話がかかってきたら合成音声を流す
を画面で定義
・node.jsのプログラム
かかってきた電話番号をリスト
uniqBy
substr & mask
●利用例
・サインアップ時の2要素認証
・死活監視で登録者全員に一斉コールw
●他のサービスと連携
・チャットボット、音声合成サービスなど
・AIボットとの連携例
AITalkで関西弁で応答
●オンボーディングとゲームの活用
・こんなこと言ってませんか？
うちのサービスのユーザは、〇〇の知識を持っている。
だから一般常識として△△は分かるはずだ。
・一般常識って全ユーザの何%でしょう？
・Pay-as-you-Goモデル
いかに使いはじめてもらうか
いかにつかいつづけてもらうか
・Twilioの問題
製品
多すぎ
製品ドキュメント
全部は読めない、読まない
-> ゲーミフィケーション
・TwilioQuest3
レガシーシステムに対して、クラウドオペレーターがアタックしていく
GettingStartedをゲームのイベントに込みこむ
経験値とアイテムが手に入る
アバターの装備を変えられたり
イベントを組んで、競争もできたり
●TwilioQuest3のアーキテクチャ
・2はwebアプリだった
開発環境はユーザ個別
どこでも動くようにローカルアプリにした
・クラサバ
server
firebase
コンテンツ管理
client
TQ Launcher App
electron
TQ Game Window
コンテンツ表示
react
phaser: 2dゲームエンジン
tiled : map編集
・コンテンツ
日々更新されるシナリオ
4つのファイルの追加でイベントを作成できるようにしている
・Developers Summit 2020 向けMapを用意しました！
●導入の効果
・ユーザ数
2と比較して、前年比 +95%
新規ユーザ獲得、リテンション
・コンテンツ消費数
3リリース後、前年比 +135%
リテンション、製品理解の向上
・セールスパイプライン
開発者向けイベントのツールとして利用
案件の数が増えた
●今後の課題・改善
・web app vs ローカルアプリ
インストールできない端末も
・ユーザー体験の改善
ゲームそのもののわかりやすさ
言語の壁
ローカルコンテンツを増やしていこう
・ゲームに対しての嫌悪感
興味ない層への対応
GitHub上にチュートリアルをつくったり
●まとめ
・オンボーディングはサービスを成功させる1要素
・チュートリアルのゲーム化
・ユーザーの獲得、リテンションに効果があった
■エンジニアと人事がともに考えるエンジニア採用
てぃーびー（田部井 勝彦） さん [スタディスト]
伊藤 哲弥 さん [LAPRAS]
梶原 成親 さん [ヤプリ]
安立 沙耶佳 さん [ヌーラボ]
金山 貴泰 さん [うるる]
●てぃーびーさん
・スタディスト
・Teachme Biz
・人事
●転職透明化らぼ
・採用担当者と求職者間の情報の非対称性
採用担当者の採用の知識を
求職者に提供して透明化
●デブサミなので
・エンジニアと人事間の情報の非対称性
人事は採用の知識
エンジニアは開発の知識
それぞれから提供
●エンジニア個人にとって何がよい？
1. おちんぎん
良い人が入れば
売上に反映されて、給与が上がる
2. 職場体験
コミュニケーション能力が高い人が入れば
環境が良くなる
3. キャリアアップ
スキルが高い人が入れば
学びを得られる
-> 直接的ではないが、大きな影響がある
●今日のお話
・採用活動
求人要件定義
職務分析
潜在層対策
カジュアル面談
選考
・前提理解
採用市場
チャネルがどこに有効なのか？など
●伊藤さん
・LAPRAS
webの情報をクロールして
エンジニアのポートフォリオを自動生成
企業がスカウト
・エンジニア側から見た採用市場
超売り手市場
求人倍率 11倍
他の職種 0.x - 1.x倍
IT人材需給の予測
2030年で45万人不足
エンジニアの質
課題解決型->価値創造型
-> 超売り手で10年くらい変わらないのは限定的
・スカウトメールの集中
22% 1社
50% 2-5社
18% 6-10社
8% 11-20社
-> 受け取っているのは53万人のうち1%
・企業の採用要件も、特定の技術に集中
・企業側から見た採用市場
ディスコースの階層
認知は、階層化されたディスコースが相互に影響
社会文化的
マスメディア、権威
コミュニティ
コチ込み、SNS
グループ
一次情報との接点
個人
人生経験
内面
・エンジニアコミュニティでの評判が採用に直結
では、誰がやるべきか？
採用担当に会いたい人は少ない
・エンジニアとしてのキャリア
Engineering Manager
Tech Lead
Product Manager
●梶原さん
・ジョブディスクリプション
職務の目的、目標、責任、権限の範囲
必要とされる知識や技術、資格、経験、学歴
採用や評価に連携
・やってほしいことと、やりたいことのマッチング
企業側の情報開示の一つ
業務の内容や進め方のイメージができたら最高
・書いてあると、なお良いもの
ローンチ後の仮説検証の仕方
直面している課題から採用を頑張っている理由がわかると良い
・他者企業のディスクリプションをチェック
30社くらいで良し悪しが見えてくる
転職後の業務が見えるか？
・採用職種のリーダーと会話する
エンジニアを採用する = チームを大きくする
大きくしてどうしたいのか？
足りないピース = 欲しい人
マッチ率で、高い報酬と戦えるかも
・ジョブディスクリプションを書いてチームビルディング
・勝手にレビューしてみますw
nulab: SRE
Backlogをどう大きくしていくのか
入った後に何をするのかのイメージが湧く
Studist: テストエンジニア
歴史、理想像・課題感、業務フロー、プロセスの改善方法
求める人物像が分かりやすい
うるる: サーバーサイドエンジニア
すんごい文章量でhowの裏側にある考え方が分かる
・JDを通して期待値をすり合わせる
合意していない期待があるとつらい
・JDを整理する中で
チームの現状と理想を定義できる
・ベストは常に変わるので都度見直す
●足立さん
・ヌーラボでの去年の内定決定率
100%
内定〜入社した割合
・エンジニア不足は年々悪化
そもそもエンジニアと出会えない
-> カジュアル面談
・カジュアル面談
興味ありますか？
まずは話してみましょう
・やることは会社によってまちまち
行ってみたら志望動機を聞かれたw
・逆パターンも
なんで僕を採用しようと思ったんですか？
まだ採用するって決めてないし、、、
・ヌーラボ式選考フローのマスト項目
1: 自社なりの面談の定義を決めて候補者に伝える
興味があったら連絡ください でボールを離す
2: 選考フローを設計、社内に共有する場を設ける
技術面接 120min + 事前/事後mtg
採用定例mtgを参加自由に
・他の会社でも使えること
1: 自社なりの面談の定義を決めて候補者に伝える
面談って何を書き出す
セリフレベルまで落とし込む
ブログで面談の定義を表明
2: 選考フローを設計、社内に共有する場を設ける
フロー、担当者、選考の役割をwikiで
月1でも採用に関わるメンバーの認識を揃える
■パネルディスカッション
●採用ってなぜ重要なのですか？
・梶原さん
プロダクトの品質がビジネスに直結
入る人次第でチームが大きく変わる
●エンジニアが採用に関わったことによる効果は？
・安立さん
志望意欲を上げていくとが必要
ジョブディスクリプションのレビュー
良い人と働きたいなら採用に
・伊藤さん
人事だけでやると終わる
あてずっぽうになってしまう
エンジニアが関わることがスタートライン
フルスタックエンジニアw
機械学習エンジニアに向かってAIってw
●採用担当は入社後にどんなフォローをすべき？
・梶原さん
入社までに人間関係ができているので
相談しやすい相手
・伊藤さん
活躍するところまで見越してオンボーディング
手法がググれば沢山
・安立さん
採用担当ではなく人事
採用から評価まで一気通貫
●120分面接は、辞退されませんか？
・安立さん
その前に課題がある
辞退するのはそっち
120分 5人 も掛けてもらえるんだ
と思ってもらえる事が多い
・伊藤さん
スキルチェックに力をかけている
半日位かかるのをやってもらう
クリアできることがチェックになる
・梶原さん
現場でチェックするのは大変そう
・伊藤さん
全員これをやってきているから自然
同じ流れで入社しているから、マインドが近い
●求職者側のスキルを確認するために有効な手段は？
・安立さん
やってもらう課題もあるけど、ディスカッションが効果的
1hインターンのような
・梶原さん
課題解決のロジックを問う
何を考えていた、どうしてそう考えた？
・伊藤さん
ハードスキル、ソフトスキル、カルチャーを見ている
構造化面接を試そうとしている
面接官が誰であっても同じ結果になる
基準を越えたら採用するルール
80点が基準だとして
81点のヒトが来たら採用
あとで120点の人が来たとしても
・金山さん
相対評価だとタイミングとかの問題が出てしまいますね
●内定出したい候補者の給与希望と社内の相場とマッチしない場合は？
・安立さん
内定の基準を上げられるように考えている
・伊藤さん
社内の相場にマッチする人を募集する
■感想
・内部品質への投資の損益分岐点は1ヶ月以内に現れる
・「スピードと質」と「学習」がトレードオフ
・ビジネス部門、外部専門家を巻き込んだ内製組織
・ITエンジニアの少ない組織でのアジャイル導入ストーリー
・オンボーディングにゲーミフィケーション
・ジョブディスクリプションを通して
組織の現状を知り、目標を設定する
組織と候補者の期待を調整
・社内での活躍までを見越したオンボーディング
など、広い分野でたくさんの気づきをいただけました。
さすがデブサミですね！！
登壇者の皆さん、運営の皆さん、ありがとうございました！
Day2も楽しみです！
■Day2の様子
いつも応援していただいている皆さん支えられています。