ITエンジニアの【理想の開発環境】に関するツール・サービスランキング

こんにちは！TECH Street編集部です。

IT・テクノロジー人材のためのコミュニティ「TECH Street（テックストリート）」は、定期的にIT・テクノロジーに関する調査企画を実施しております。

調査テーマは毎回コミュニティメンバー内で話題にあがったコト、興味関心が高いトピックスなどを対象に選定しています。

今回は「ITエンジニアの働く環境」と「開発環境」について、外部調査会社にご協力いただき日本国内のITエンジニアを対象としたWebアンケート調査を行いました。本記事では、調査結果を紹介いたします。

調査概要 

調査項目

・PC
・ビジネスチャットツール
・Web会議ツール
・エディタ
・IDE
・プロジェクト管理ツール
・クラウドサービス

ITエンジニアが使いたいPCランキング

「Q.ビジネスやプロジェクトにおいて、自分にPC選定の決定権がある場合、どちらのPCを使いたいですか？」（n=403）と質問したところ、「Windows」と回答した方が90.1％、「Mac」と回答した方は9.9％という結果となりました。

▼ITエンジニアが使いたいPCランキング

Windows：90.1%
Mac：9.9%

また、「Q.PCを選ぶ上で最も重要視するポイントはどれですか？」（n=403）と質問したところ、「操作性の高さ」が28.5％と最も多くなりました。 

▼PCを選ぶ上で最も重要視するポイント

操作性の高さ：28.5%
コストパフォーマンス：27.3%
アプリケーションとの親和性の高さ：12.9%
セキュリティ性の高さ：9.4%
周辺機器との連携性の高さ：7.9%
カスタマイズ性の高さ：5.7%
デザイン性の高さ：2.7%
アフターサポート：2.2％
ゲームに向いているか：0.7%
その他：2.5%

ITエンジニアが使いたいビジネスチャットツールランキング 

「Q.ビジネスやプロジェクトにおいて、自分にツール選定の決定権がある場合、どのビジネスチャットツールを選びますか？」（n=403）と質問をしたところ「Microsoft Teams」と回答したITエンジニアが55.6％と最も多い結果となりました。

▼ITエンジニアが使いたいビジネスチャットツール

Microsoft Teams：55.6%
Slack：13.6%
LINE WORKS：10.4%
Chatwork：7.2%
Workplace from Facebook：5.2%
その他：7.9%

また、「Q .ビジネスチャットツールを選ぶ上で最も重要視するポイントはどれですか？」（n=403）と質問したところ、最も多かったのは「セキュリティ性の高さ」の27.0％でした。

 ▼ビジネスチャットツールを選ぶ上で最も重要視するポイント

セキュリティ性の高さ：27.0%
通信の安定性の高さ：19.6%
データの共有・保存機能：9.4%
社外との連携機能：8.9%
ビデオ、音声通話機能：8.4%
外部サービスとの連携機能：7.4%
タスク管理機能：7.2%
アフターサポート：4.5%
カスタマイズ性の高さ：4.2%
その他：3.2%

ITエンジニアが使いたいWeb会議ツールランキング

 Q.ビジネスやプロジェクトにおいて、自分にツール選定の決定権がある場合、どのWeb会議ツールを選びますか？」（n=403）と質問をしたところ、1位は「Microsoft Teams」で38.5%、2位は「Zoom」で28.0%でした。

▼ITエンジニアが使いたいWEB会議ツール

Microsoft Teams：38.5%
Zoom：28.0%
Skype：9.9%
CISCO Webex Meetings：9.2%
Google Meet：8.7%
SpatialChat：1.5%
V-CUBE：1.0%
Remo：0.2%
その他：3.0%

また、「Q.Web会議ツールを選ぶ上で最も重要視するポイントはどれですか？」（n=403）と質問したところ、「通信の安定性の高さ」が24.6％と最も多い結果となりました。 

▼Web会議ツールを選ぶ上で最も重要視するポイント

通信の安定性の高さ：24.6%
会議への参加・招待のしやすさ：22.8%
セキュリティ性の高さ：18.9%
音質・画質の良さ：12.7%
機能性の高さ：9.9%
カスタマイズ性の高さ：3.7%
アフターサポート：2.7%
アプリケーションインストールの有無：2.5%
その他：2.2%

ITエンジニアが使いたいエディタランキング 

Q.ビジネスやプロジェクトにおいて、自分にツール選定の決定権がある場合、どのエディタを選びますか？」（n=403）と質問をしたところ「サクラエディタ」と回答したITエンジニアが38.0％と最も多い結果となりました。

▼ITエンジニアが使いたいエディタ

サクラエディタ：38.0%
秀丸エディタ：20.8%
Visual Studio Code：9.4%
Atom：5.2%
TeraPad：5.0%
EmEditor：3.0%
Brackets：2.7%
Notepad++Vim：2.7%
Vim：2.7%
CotEditor：1.7%
Emacs：1.5%
Liveweave：1.0%
Sublime Text：1.0%
その他：5.2％

また、「Q.エディタを選ぶ上で最も重要視するポイントはどれですか？」（n=403）と質問したところ、「ソフトの軽さ」が34.2％と最も多い結果となりました。

 ▼エディタを選ぶ上で最も重要視するポイント

ソフトの軽さ：34.2%
機能性の高さ：28.3%
日本語対応：14.4%
外部ツールとの連携：8.9%
対応している開発言語：7.2%
アプリケーションインストールの有無：3.5%
その他：3.5%

ITエンジニアが使いたいIDEランキング

 Q.ビジネスやプロジェクトにおいて、自分にツール選定の決定権がある場合、どのIDEを選びますか？」（n=403）と質問をしたところ「IDEは使わない」と回答したITエンジニアが32.8％と最も多い結果となりました。

▼ITエンジニアが使いたいIDE

IDEは使わない：32.8%
Eclipse：21.6%
Microsoft Visual Studio：19.1%
AWS Cloud9：8.4%
IntelliJ IDEA *Android Studio PyCharm PhpStorm RubyMine WebStormなどを含む：4.7%
Claris FileMaker：3.5%
Xcode：3.5%
NetBeans：2.2%
SharpDevelop：0.7%
その他：3.5%

また、「Q.IDEを選ぶ上で最も重要視するポイントはどれですか？」（n=271）と質問したところ、、1位は「機能性の高さ」で30.3％、2位は「対応している開発言語」で26.9％となりました。 

▼IDEを選ぶ上で最も重要視するポイント

機能性の高さ：30.3%
対応している開発言語：26.9%
セキュリティ性の高さ：11.4%
カスタマイズ性の高さ：10.3%
アプリケーションインストールの有無：7.4%
アフターサポート：5.5%
他メンバーとの連携機能（チャット機能など）： 4.8%
その他：3.3%

＞＞ITエンジニアが使いたいプロジェクト管理ツールとクラウドは？

---

ITエンジニアが使いたいプロジェクト管理ツールランキング

Q.ビジネスやプロジェクトにおいて、自分にツール選定の決定権がある場合、どのプロジェクト管理ツールを選びますか？」（n=403）と質問をしたところ32.3％のITエンジニアが「Excel」と回答しています。 

▼ITエンジニアが使いたいプロジェクト管理ツール

Excel：32.3%
Microsoft Project：15.6%
Redmine：11.4%
Backlog：7.9%
Asana：7.4%
CroudLog：5.0%
Wrike：4.2%
Jira Software：3.5%
Trello：3.2%
kintone：2.5%
InnoPM：1.2%
Jooto：0.2%
その他：5.5%

また、「Q.プロジェクト管理ツールを選ぶ上で最も重要視するポイントはどれですか？」（n=403）と質問したところ、「操作性の高さ」が34.0％と最も多い結果となりました。

 ▼プロジェクト管理ツールを選ぶ上で最も重要視するポイント

操作性の高さ：34.0%
カスタマイズ性の高さ：12.7%
日本語対応：11.2%
セキュリティ性の高さ：10.4%
外部サービスとの連携機能：9.4%
社外との連携機能：8.4%
アプリケーションインストールの有無：5.2%
アフターサポート：4.5%
その他：4.2%

ITエンジニアが使いたいクラウドサービスランキング

Q.ビジネスやプロジェクトにおいて、自分にツール選定の決定権がある場合、どのクラウドサービスを選びますか？」（n=403）と質問をしたところ、1位は「Amazon Web Services」で38.5％、2位は「Microsoft Azure」で32.3％、3位は「Google Cloud Platform」で29.3％でした。 

▼ITエンジニアが使いたいクラウドサービス

Amazon Web Services：38.5%
Microsoft Azure：32.3%
Google Cloud Platform：29.3%

また、「Q.クラウドサービスを選ぶ上で最も重要視するポイントはどれですか？」（n=403）と質問したところ、「セキュリティ性の高さ」が36.5％と最も多い結果となりました。

 ▼クラウドサービスを選ぶ上で最も重要視するポイント

セキュリティ性の高さ：36.5%
ネットワーク：13.2%
データベース：11.2%
オンプレミスとの親和性の高さ：10.9%
ストレージ：10.9%
コンピュートリソース：8.9%
リージョン数：4.7%
その他：3.7%

まとめ

今回の調査において、それぞれの項目の1位は下記結果となりました。

PC：Windows
ビジネスチャットツール：Microsoft Teams
Web会議ツール：Microsoft Teams
エディタ：サクラエディタ
IDE： IDEは使わない
プロジェクト管理ツール：Excel
クラウドサービス：Amazon Web Services

今回の調査に関する内容は以上となります。今後もTECH Street独自のリサーチをしていきますので次回もご期待ください！

【イベントレポート】時短ITレシピ共有会vol.1

こんにちは！TECH Street編集部です！

今回は2021年4月8日（木）に開催した、 「時短ITレシピ共有会vol.1」のイベントレポートお届けいたします！ITを活用してタスクの時間短縮＆効率UPをするためのお役立ちTips盛りだくさんの内容となっています。

 本日の登壇者はこちらのお二人！

・KUMIさん
・Excel師 KTさん

 早速明日からすぐに使える時短テクニックを紹介していきます！

Microsoft Streamを活用した自動文字起こし＆議事録時短
KUMIさん

現在はコミュニケーションツールを使った業務効率化を担当しているKUMIさんからは、Microsoft Streamを活用した時短ITレシピの共有をしていただきました。

早速ですが、みなさん“議事録”は書いていますか？議事録は会議の内容や決定事項、Next Actionを共有することで認識相違を発生させないために必要なものですよね。しかし、議事録の作成は簡単ではないですよね…

下記は、KUMIさんが議事録を作成されていた際の手順。皆さまもこんな苦労されたことあるのではないでしょうか？

①議事録を所定フォーマットに記載
②先輩社員に記載の確認
③関係部署の皆さんに議事の確認依頼を展開
④期日通りに返信がないためリマインド
⑤この議事録を有効化するため押印リレーを開始
⑥押印済み議事録をPDF化して展開

 この手順で議事録を作成していた時は、議事録完成までに5日かかっていたそうです。とにかく時間も手間もかかりますよね…。

そこで、今回使うのは「Microsoft Stream」。

ビデオコンテンツの安全な共有が簡単にできるサービス。今回は、この「Microsoft Stream」の中でも「トランスクリプト」の機能を活用します。

ビデオの字幕が自動的に作成される機能で、会議の内容が自動で書き起こされていきます。こちらで書き起こされたものは、ファイル形式でダウンロードすることもできて、後から別途共有することも可能。

実際にどのように作成されていくかをさらに詳しく説明いただきました。

①Teamsでオンライン会議
→文字起こししたい動画を準備します。Teamsで会議をレコーディングすると自動でビデオが保存されます。
②OneDriveへ録画を保存
③Microsoft Streamにアップロード
④トランスクリプトで書き起こし
→Microsoft Streamにアップロードする際にオプションを「ビデオの言語：日本語」「キャプションの自動生成」をONにすると書き起こしができます。

イベントでは、実演動画も紹介いただきましたが、かなり精度の高い書き起こしが実現できていました！一方で、発話者の切り替わりの判定が難しく、「あ〜」「う〜」などの詰まった言葉や、声のどもり・重なりなどは聞き取りづらいところもあるよう。

大事な文字起こしを間違えるところは、大きな課題の一つ。会議においての決定事項や大事な内容を書き間違えてしまうことは避けたいですよね。その場合は、音声を確認して直接修正を入れているそうです。

また、もう一つの課題として、アップロードの手間がかかること。議事録を細かく書くことに比べると手間は少ないものの、ゆくゆくは自動化されるといいですね…！

さて、ここからは、このMicrosoft Streamを議事録の作成にいくためのアイディアをご紹介。そもそも、議事録の作成には、下記のような目的があります。 

・会議の目的の達成
・決定事項の共有
・Next Actionの共有

上記の内容をもれなく記載するためには、ヒトが書く場合も、機械に書き起こさせる場合も、“決まったフォーマット”があると便利ですよね。例えば、オンライン会議の際も、会議の最後にフォーマットに沿って口頭で「本日の会議のまとめです」「本日の決定事項は〜〜です」という会議内容を発言することで後から議事録を作成しやすい記録を作ることができるそうです。

まとめ

・Microsoft Streamで打ち合わせ内容の「自動文字起こし」は一定有効そう。

・基本的な用語の聞き取りは可能。一方で、会議中の不確定な会話など発話状況により聞き取れないものも多いので、適宜微修正が必要。

・従来の議事録は文字でしか残らないため、正しいかの判別が難しいが、Teams＋Microsoft Streamを利用することで、ビデオ・文字で証跡を残すことが可能。

・自動で書き起こしをしてくれるため、本来の会議に集中できる。

今まではヒトが手間暇をかけて作成していた議事録をシステムに任せることができるようになれば、会議で“ヒトにしかできない”クリエイティブな討論に集中することができますね！

今はまだ、精度に一部課題はあるものの、工夫しながら使っていくことで、業務の時短化・効率化を進めていけそうです！Office 365を利用している方は、ぜひお試しください◎

Excelの即効テクニックとPower Automate活用術
Excel師 KTさん

Excel好きが高じて、受講者がのべ6000人を超えるほどの人気コンテンツ「Excel塾」を開講するKTさんからは、Excelを使った時短レシピを2つと、Power Automateを活用する時短レシピを共有いただきました！ 

フラッシュフィル〜瞬間名簿作成〜

こちらは今回紹介する中でも最も簡単ですぐに実践できる技！ 

名簿を作成する際、下記のような作業をしたい、と考えたことがあるのではないでしょうか？

・名字だけを抜き出したい
・名前だけを抜き出したい
・社員番号の下2桁だけを抜き出したい
・複数の項目を連結させたい
・メールアドレスの@前の部分だけ抜き出したい
・名刺に使用できるようローマ字表記の名前にしたい　など

一つ一つ手作業で抽出していくのは手間も時間もかかりますが、ここでフラッシュフィルという機能を使うと、あっという間に名簿作成ができるそう…！

※どこかで見た名前ばかりですね（笑）

フラッシュフィルは、たったこれだけできます！

①上図2行目のように抽出したいデータのサンプルを入れる
②フラッシュフィル＝Ctrl+Eをする

10秒足らずで抽出・組み合わせがしたいデータが自動で生成され、名簿が出来上がりました！フラッシュフィルを使うと、どの列から抜き出すという指定をせずとも、あらかじめ入れたサンプルから規則性を読み取り、自動的に読み取ってくれ、抽出してくれます。

これはめちゃくちゃ便利…！もっと早く知りたかった技です…！

関数を使って抽出することもできますが、データが多いと関数を使うことでファイルが重くなってしまいがち…そんな際にもフラッシュフィルは有効。ただし、注意点としては、規則性のあるデータを元データとして抽出する必要があるので、その点はご注意ください。

複数のブックを一発で連結するExcel Power Query 

例えば、複数の日報がフォルダ内に存在し、それらを一つにまとめあげないといけないというシュチュエーションの場合。一つ一つ開いてコピペしていくのは大変ですし、ミスしてしまう可能性があります。

日報の中身を開いてみると、非構造データでセルも連結されている状態。ここでは、Power Queryを使うと一発で集計ができるようになります！

こちらがデモ用に作っていただいたExcel連結ツールです。手順は以下の通り。

①まとめ上げたいデータが格納されているフォルダをA2セルに入力
②D2セルに対象のシート名を入力
③「Ctrl + Alt +F5」で更新　※データ＞全て更新でもOK
④シート「date」に反映される 

「date」セルには上記図のように、どのシートから持ってきたデータなのかがわかるように縦につながって表示されていきます。一覧で見ることが出来てわかりやすい…！これも一瞬でデータ化できてとても効率的です。

こちらは、「フォルダにあるExcelのデータを一括で連結するツール」であるPower Queryを使用しています。マクロを使う必要はありません！

また、Power Queryはデータの加工機能も充実しています。

例えば、別のExcelのBookからデータをインポートし、加工する、という作業も可能。まずはデータをインポートし、Power Queryエディターで加工する必要がありますが、2回目以降はロジックが組まれているので、ワンクリックで集計ができるようになります。

テーブル形式（DB形式）以外もインポートすることも！また、100万件以上も対応しており、VBAよりずっと簡単に作ることができるので、おすすめ◎ 

会議自動化設定 Power Automateクラウドフロー+ Forms

テーマは「Formsで勉強会に申込みしたら、Outlookの会議に自動的に参加者を追加したい」というもの。これを実現するためのフローをご紹介します。

ポイント①Outlookの会議IDを取得する
ポイント②「イベント更新（V4）」で出席者を追加する

全体のフローはクラウドフローというフォーマットを使います。

さて、ここで使うのがPower Automateですが、Microsoftの業務自動化ができるツールの一つとなります。Office 365のライセンスがあれば使えて、テンプレートやAPIが豊富であるという特徴があります。

手順は以下の通り。

①会議作成と会議IDの取得

Outlookの予定表に予定を追加します。今後、この【TEST】Power勉強会に申込みをしてくれた人を自動で宛先に追加していくという内容となります。

追加するにあたり、Outlookで作成された会議に振られている固有のIDを取得する必要がありますが、これはクラウドフロー上で取得して自分にメールで送る、という流れで対応しているそうです。

②会議出席自動受付

こちらのトリガーはFormsになっています。

このFormsから申込んでくれた人のIDを裏側で取得し、先ほど取得した会議IDをここで指定します。

ポイントは、必須出席者（すでに出席者登録されている人）に加えて、今登録してくれた人のIDを追加していくことだそうです。

クラウドフローについてはまだ試行錯誤中とのことですが、様々なツールと組み合わせて使うことができるツールとして紹介いただきました！

参加者からの質問

（Q）フラッシュフィルについて、名前に半角スペースがないものを名字と名前で抜き出したい場合はどうすればいいですか？
（A）規則性がないので、その場合は抽出するのは不可能だと思います。名字の文字数が決まって入ればLEFT関数を使えば抜き出せますが、規則性がないと抜き出すのは難しいです。

（Q）フラッシュフィルは特に設定はいらないですか？
（A）はい。Excel2016以降のデフォルト機能なので、設定は不要です。

まとめ

今回は、今日からすぐに活かせるIT時短レシピを共有いただきました。

参加者の方々から「業務上のお困りごとを解決するテクニックをもっと知りたい！」というような嬉しい声があがっていました♪シリーズ化も期待（？）ですね！ 

イベントレポートは以上となります！
参加してくださった皆様、登壇者のお二人ありがとうございました。

次回のイベントもお楽しみに！

【イベントレポート】企業や組織において文化とは何なのか

こんにちは！TECH Street編集部です！

今回は2021年3月25日（木）に開催した、 「企業や組織において文化とは何なのか ～エンジニア組織のあるべき姿／今本当に考えるべきこととは？～」のイベントレポートお届けいたします！

エンジニア組織として考えなければいけないことは何か、リモートワークにおける文化形成とはなど、パネラーにお話いただきました。

登壇者はこちらのお二人！

鈴木 逸平さん／クリエーションライン株式会社
清田 馨一郎さん／パーソルキャリア株式会社

今回は、まずおふたりから今回のテーマについてのプレゼンをしていただき、そのあとにディスカッションという流れでお送りいたしました。
記事後半では、当日回答しきれなかったご質問についても回答しておりますのでこちらもご覧ください♪

清田 馨一郎さんプレゼン

清田さんからは、組織文化について様々な文献を用いてご説明いただきました。

組織文化とは

各書における組織文化は下記のように定義されています。

『エクセレント・カンパニー』：組織構成員がもつ共通の価値観
『シンボリック・マネージャー』：どのように行動すべきかを示す非公式な決まりの体系

さらに具体的に、E.H.シャインの『企業文化 ダイバーシティと文化の仕組み』においては、下記のように説明されています。

“文化とは共有された暗黙の仮定のパターンである。
　暗黙の仮定とは、外部に適応したり、内部を調整したりといった問題を解決する際に、
　組織が学習した方法である。
　それらは組織によって承認され、新しいメンバーが組織に加わった際には、
　問題に気づき、考え、感じるための正しい方法として彼らに伝えられる”

また、ここでいう“パターン”は組織によって異なります。

ベン・ホロウィッツの『Who You Are 君の真の言葉と行動こそが困難を生き抜くチームを作る』によると、“正しい答え”は組織によって違う、と説明されています。

例えば、下記のような疑問に対する“正しい答え”も組織により異なります。

・この電話は、今日折り返した方がいいほど緊急なものなのか？明日まで待っても大丈夫か？
・ライバル会社について、どのくらい必死に研究すればいいのだろう？
・勝つことは倫理よりも大切なのか？　など

このような、“組織としての判断基準”や“組織としての正しい答え”を明確にしていくことが、組織文化につながっていきます。

なぜ今、改めて組織文化を見つめ直すのか

先述した、『エクセレント・カンパニー』の時代は、トップダウンで、上が決めたことに従えばどうにかなる世界でした。しかし、今は不確実性が高く、変化に強い組織や、コラボレーションとチームワークの経営が求められている時代となっています。

一人一人の組織メンバーが何かのルールにしたがって自主的に動いていくことが求められていますが、ある日突然与えられたルールは、なかなか浸透しません。そういった環境で、必要となってくるのが、組織文化なのだとか。

トヨタの生産方式などで知られる野中 郁次郎氏の著書、 『全員経営 ー自律分散イノベーション企業 成功の本質』には、下記のように記されています。

“「何がよいことなのか」という価値基準をベースにしながら、その都度、状況に応じて最善の判断をする。もし、判断が結果的に間違っていたら、即フィードバックして修正し、次の目標に向けてフィードフォワードしていく。このサイクルを進めながら一歩一歩、自分たちの目指す「よいこと」に近づいていくのです。”

強い組織文化を作り出すには

須田敏子氏の著書、『組織行動: 理論と実践』によると、強い組織文化を作り出す4つの源泉は以下のように説明されています。

　・理念（Inner Values）
　・英雄（Heros）
　・儀礼と儀式（Rites and Rituals）
　・伝達（Communication）

しかし、やはり人間は新しいことを始めるときには抵抗を感じるもの。文化改革の阻害要因についても、以下のように説明されています。

　・未知に対する不安
　・利害対立
　・組織の構造的惰性

また、文化の継承も大切な要素となっています。新しいメンバーに対して、文化を理解してもらうプロセスを組織の社会化と言います。服部泰宏氏・鈴木竜太氏の著書『組織行動: 組織の中の人間行動を探る』では組織の社会化について、こう述べられています。

“組織内での役割を遂行することと、組織のメンバーとして参加することにとって不可欠となる価値観、能力、期待される行動、社会的な知識などを正しく理解していくプロセス”

組織の社会化で個人が理解していくものについては以下のようにカテゴライズされています。

組織文化という文脈においては、まず自分たちの文化や判断基準を明確にし、新しいメンバーに対して上記の項目を既存のメンバーが伝えていくという活動が必要なのだそうです。
言われてみれば、なんとなく大切だと感じていたようなことも多いですが、明文化されるとよりわかりやすく、意識的に組織の課題に取り組んでいきやすくなりそうですね…◎

清田さん、様々な視点からの組織文化のご説明ありがとうございました！続いて、鈴木さんよりお話をいただきます。

鈴木 逸平さんプレゼン

鈴木さんからは、時代の変化のスピードが加速している環境の中で勝ち抜くための組織文化についてお話をいただきました。

リモートワークと企業の文化について

Iometrics社とGlobal Workplace Analytics社が共同でコロナの影響を受けたテレワークの実態調査を実施したところ、自宅でやったほうがいい仕事と、オフィスでやったほうがいい仕事の種類が異なることが色濃く示されたそうです。

例えば、自宅の方が、良いパフォーマンスが出る仕事は、書き物などの長時間の集中が必要なものや、機密性の高いプライベートな会話、クリエイティブな業務など。このような業務は、自宅で、一人で取り組む方が、生産性が高いとされているようです。

一方で、オフィスの方が良いパフォーマンスが出る仕事としては、誰かの指導を受ける際や、チームの管理をする必要がある際の仕事、他人とのコラボレーションを必要とする仕事、組織の状況を把握しなければいけない仕事などがあげられるそうです。

このような特徴を、企業の文化として取り入れていく場合は、それぞれに適した仕事をハイブリットのような形で取り入れていく必要があり、今後はそのハイブリッド型が広まっていくのではないかと鈴木さんは語ります。

これからのリーダーシップについて

次の事例は、第5次産業革命と呼ばれるもの。こちらは2019年のダボス会議で初めて出てきた言葉。今、私たちは第4次産業革命の真只中におり、その先に第5次産業革命があるのだとか。第4次産業革命によるDehumanizationは企業の文化喪失につながると懸念されており、その先の第5次産業革命があることが議論されているそうです。

また、このような時代の中でリーダーとしての資質も問われてきます。

Menlo Innovations のCEOであるRichard Sheridan氏の著書、CHIEF JOY OFFICERによると、リーダーの3つの指針を以下のように説明しています。

　・意味のある、持続可能で、ポジティブな影響力を想像し、人に届ける
　・常に「誠実さ」と「真の自分」を発揮する
　・「思いやり」「愛情」と「喜び」を常に表現しながら行動する

クリエーションライン社におけるリモートワークツール

最後に、クリエーションラインで採用しているリモートワークツールについてのご紹介です。OKRの実施を強化したり、Google MeetやZoomなどのツールを使用したりするのに加え、oViceなど仮装のオフィスを使って会話をしているそうです。

また、OKRの手法としてウィークリーでチームリーダーミーティングや、全社で成功を共有し合うWinセッションを実施したり、パートナー企業とはリモートアジャイル開発に取り組まれたりもしているそうです。

また、それぞれのリーダーの強化には、Clifton StrengthsFinderを活用し、それぞれの強みを伸ばしていくような取り組みを実施しているのだとか。

クリエーションライン社の詳しい取り組みはこちらも参考にしてみてください◎
・oViceをバーチャルオフィスにしてみた
・OKR書籍についてのブログ

ここからは清田さん、鈴木さんお二人によるトークセッションです！

エンジニア組織の文化形成Talk

リモートワークにおける文化形成について

清田氏：GitLabはリモートで有名な会社だと思いますが、今後リモートとオフラインのハイブリットが議論されていく中で、「文化形成」「組織としての良いこと、悪いこと」はどのように伝達されていくのでしょうか。GitLabのような組織で、文化形成のためにやっているようなことはあるのでしょうか？

鈴木氏：GitLab社が毎年出しているワークガイドThe Remote Playbookに書いてあることは、全ての会社にコピー&ペーストできるようなもの、というわけではないという前提ですが、2つの重要なポイントが提唱されています。

1つは、透明性を持たせること。社内のポジティブなこと、ネガティブなこといずれも共通して重要な要素です。誰かを褒めたり、叱ったり、何かを修正していくことは、できる限り透明性を持ってやっていくことを強い指針としています。例えばSlack上で、みんなで共有する。特に、ポジティブなことを言う場合はみんなに伝えたいと思いますが、ネガティブなことを伝える時もポジティブな要素を付け加えて言う訓練も兼ねて伝えていくことが大事です。

もう1つの重要なポイントは、ほぼ全てのものをドキュメント化することです。議事録は全てドキュメントにして残すことを強くルール化しています。これは、透明性を保つ上でも重要です。議事録を残すと言うことは、全員に、どんな仕事をしているかを共有する意味を持ちます。さらに言うと、文字を中心の議事録を作成することが重要です。意外と、ビデオは見られないし、スライドは誤解を生む要因にもなってしまう可能性があるので、文字にすることは重要です。

清田氏：文化を醸成するには、リーダーの力が大きいのかと思っています。社会組織化でいう「新しいパターン」が入ってきた時、メンバーが組織や会社の良し悪しを学ぶフェーズがありますが、そういったときに学ぶ方法は、文章だけではないと思っています。リモート環境において、新しいメンバーが入ってきたときに、うまく伝わっているかわからないと感じることもあると思いますが、そういう場合は文章以外の他の何かを使って伝えていくのかなと思うのですよね。

Menlo Innovationsでは、オフラインでのコミュニケーションをすごく重視されていたようだったのですが、現状はどうなっているかご存知ですか？

鈴木氏：2ヶ月くらい前に、さきほど登場したCEOのRichardと電話会議をしましたが、現在は完全リモートでオフィスには誰も出社していないそうです。リモートでやりながら、コミュニケーションを深めていくことの難しさは我々と同様に感じているようです。彼らの強みであるPaired Programming （エンジニアを2人1組にしてプログラミングをさせる）という技法はオンラインでも徹底してやっているようです。

それから、インフォーマルな議論もオンラインで強化しているそうですよ。しかしやはり、心の奥底をのぞいていくと、オフラインで集まるコミュニケーションのレベルはなかなか到達しにくいとおもっているようですね。特に、悩んでいるのは新しいメンバーにいかに会社の文化を知ってもらうか、ということですね。

清田氏：最近日本のwork engagementを調べている学者のレポートを見たのですが、週に何回リモートワークをしているかを調査したところ、回数が増えるほどengagementは下がるという結果がでているそうです。しかし、フルリモートにまで振り切ってしまうと逆に上がるのだとか。

中途半端にやってしまうということが逆にどっちつかずになってengegementを下げてしまうのかなと思うのですが、やはりハイブリッドでやったほうがいいのか、完全に振り切ったほうがいいのか、という点についてはどう感じますか？

鈴木氏：そのジレンマはすごくよくわかります。我々も今200名の社員がいますが全てリモートで対応しています。なおかつ、アジャイル開発をお客様に対してやっていますので、全部リモートとする難しさはすごくありますね。もう一つわかったことが、リモートワークが得意な人、得意じゃない人がいるということです。リモートワークのスキルを統一させるためのトレーニングがあるわけじゃないので、苦しみながらやっています。

それから、新入社員のメンタリングについて。特にアジャイル開発は、得意な人と得意でない人がいますから、それぞれの役割分担とメンタリングをどうやってやるかは困っているところはありますね。なので、たまにこっそりリアルで集まって教えてあげるなど、ハイブリッド型を採用している状況ですね。逆に清田さんはどう思いますか？

清田氏：タスクが細分化されていて、ツールも全てオンライン上で使うことができるエンジニアとしてやっているぶんには完全にリモートでも大丈夫だと思っています。また、タスクが決まれば目的を持って話せるので、あまりインフォーマルなコミュニケーションは重要視されていないように感じます。一方で、ITプロジェクトに特化すると、そうではないかなと。ITプロジェクトのようにやることをこれから決めていくものに対しては、不向きだなと感じますね。　

逆に、生産性が上がっている要因として、移動などの余分な時間の削減ができるという理由があがっています。我々のような知識労働者は、時間を決めれば生産性が上がるというわけではなく、日常のなかで突然ハッとやりたいことが思い浮かんだり、アイデアが浮かんだりするので、時間を決められることで逆に生産性が下がるということもあると思います。

ただ、それを、リモートだからいつでもやって良いよ、とすることは知識労働者だと総合的に生産性は上がるかもしれませんが、常に仕事をしていろというわけでもなくて。仕事とプライベートの切り分けは難しいと感じている人が多いのではないかなと思います。

鈴木氏：すごくわかりますね。休息取れているのかな、と思う心配なメンバーがいることもあります。こういった部分のケアはHRの領域に入っていってしまいますが、やはりメンタル面で健全な気持ちで仕事ができているのかを評価する方法がないので、不安に感じることはありますね。

こういったリモートで働く環境は、ある意味では会社の文化を試されているものだと思いますね。文化があったのに、オフィスでは成り立つが自宅では成り立たないものだと、その文化は崩壊しやすくなってしまいます。それを解消する方法の一つが、リーダーシップです。

やはり、リーダーが強く牽引する力を持っていないと、組織は崩壊します。リーダーが率先して文化を実践する、それをみんなに行動を持って示すことがいかに重要かということはリモート勤務になって改めて噛み締めていますね。これはテクノロジーの話ではなく、まさに人と人とのコミュニケーションをどうしたら良いかというところになりますね。

清田氏：では、ここからは参加者の方々からのご質問を取り上げてみようと思います。

“海外やベンチャーはリモートで生産性を上げているから、エンジニア部門はリモートにしましょうという話を上司にしても、前例がないしパフォーマンスが心配と言われます。企業文化を変えるのは難しいと感じていますが、上司に理解してもらえる何か良い事例ありませんか？”

清田氏：どういうリーダーがマネジメントをするかが大事ですね。
パフォーマンスの成果について考えていないリーダーは常に見ていないと不安を感じることが多い。かといってそのリーダーを変えるのは難しい気がします。

可能性としては、リーダー（組織管理）とリーダーシップ（新しいことを率先する人）というのは違うので、メンバークラスであっても強みを活かして組織を変える手助けする体制づくりはできるのではないでしょうか。自らリーダーシップを張るのも方法論の一つかもしれないですね。

鈴木氏：一つ、スライドを紹介させてください。

ビジネスを、飛行機を飛ばすことに例えると、色々なベクトルで動こうとする力が働きます。これに関して、明確なゴール設定によって、前に向かう力が必要であり、それを共有することも必要ですね。また前提としては、前進するときに引っ張る逆の力＝恐れ、迷いが存在します。また、高く飛ぼうとしたときに、地面に引き戻す万有引力＝政治、慣習も存在します。

リーダーは操縦席にいるべき存在です。4つの力が何なのかを書き出してチーム内で議論し、空へ飛び立つ意思を明確にして恐れなどを上手くかわしていくことが方法の一つなのではないでしょうか。

“弊社ではそもそもこの文化の重要性について社員が意識していないように感じています。
ハイコンテクストな組織でありつつも、文化を言語化することについて価値を感じていないように思うのですが、この辺りはどのように変化させていくのが良いのでしょうか。”

清田氏：“なぜこれをやっているのか？”という当たり前すぎて気づかないような問いかけをし、言語化することも、必要なのではないでしょうか。価値観、目標に対してルールベースでパターンを作っていくことが文化だと思います。目指す目的を変える必要があれば、文化を知る必要がありますし、変える必要がないのであれば、文化を言語化することは大事ですね。

鈴木氏：文化はすべての面において、ポジティブでなければいけないですね。ネガティブなこともポジティブにしていく必要があります。これは、リーダーが牽引する要素が必要ですね。一つ例を挙げると、ボス（＝職制上の役職、強制的に指示する立場）とリーダーは違うということです。リーダーは、命令を出すのではなくやる気を出すために、空気を作る役割もあります。

ボスは職制上の役割ですが、リーダーは、職制上関係なく、素晴らしいリーダーになることができるのです。リーダーは全ての階層でいていいと思います。そのようなリーダーシップの価値や重要性を社内で啓発していくのはどうでしょうか。リーダーシップの定義は人によって違うので、それを揃えていくことも一つの方法だと思いますね。

清田氏：そうですね。僕も今、組織上のマネジメント（ボス）は別のものがやっていて、僕はボスがリソース的にできない部分をやったりしています。そのように、自由にリーダーシップをとっている状況をよしとすることも文化としてメンバーに見せることで、他のメンバーが「やりたい」を言える環境につながるのではないかと。いわゆる心理的安全性がないと文化を変えるのは難しいですね。

あとは、文化は部署やチームによって存在するので、まずは自分の見えるチーム内の文化を作っていくのも良いのかなと思います。

鈴木氏：一つエピソードを紹介させてください。ある会社の部長の話です。ある日、それぞれの子供を職場に連れてくる日があったのですが、その部長の娘が働いているお父さんの姿を見て、「お父さん偉い、みんなに命令をして、みんなに指図をしてかっこいい」といったらしいのです。

その部長は、ふとそこで立ち止まったそうです。自分の命令でみんなが動くという状況に娘が感心している事実から、チームのパフォーマンスが自分の決断に依存している状態になっていると気づいたのだそうです。言い換えると、チームのパフォーマンスは、自分の判断のスピードに依存しており、自分が働かないとパフォーマンスが落ちてしまう状況になっていたそうです。これは、ボスとしては良いのですが、リーダーシップとしては問題がある状況ですね。

清田氏：自己組織化というキーワードかなと思います。上が言ったことではなく、各自がルールに従って行動していく、ということが大事ですよね。他の質問も紹介します。

“今の文化を保ち続けるところと、メンバーに合わせて変えていくところの判断はどうしたら良いでしょう？(例などあると嬉しいです)”

鈴木氏：“Purpose driven culture”というものがあります。目的主導の文化、と日本語では言います。やはり目的が明確でなければ、日々の仕事がルーティーンになってしまいます。企業やチームの文化は、メンバー全員で共有でき、かつ快く受け入れる事ができる事が条件になります。

また、ビジネス状況により変わっていくものでもありますので、どうすべきか、という判断はチーム内で議論をする事が大事だと思います。その際に議論はもちろんすると思いますが、最終的に行き着いた結論は、全員が合意、そして遂行するというコミットメントをする事がとても大事です。

“個人の価値観とチームの価値観が合わない場合には、そのメンバーに対してどういうアプローチができるでしょうか？”

鈴木氏：人間はそれぞれ違うので、企業やチームの文化に合わない、というケースもたくさんあると思います。チームが歩み寄る方法もあると思いますが、最も大事なのはその個人が企業の文化に合わせていく事ができるようになるのか、という事だと思います。もちろん、自分の信念とずれた文化に合わせていくのは難しいし、良いことでは無いと思いますので、その場合はチームから離れる、という選択もケースとしては当然あると思います。

もし、価値観が合わない、という事がわかったのであれば、具体的にどこが合わないのか、意識を変えて合わせる事が可能なのか、負担はないのか、などの議論を持つ事が大事だと思います。そして、それはできるだけ早い段階で見つけて、解決する事も大事だと思います。

清田氏：リーダーに依存してしまうのは問題なので、全員がリーダーシップをはれるかという点は大切ですね。パフォーマンスの良いチームでも、最初はリーダーに依存してしまいがちなのだとか。

鈴木氏：ある会社を訪問したときに、その会社のボスやヒーローを見つけるのは簡単ですが、リーダーを見つけるのは難しい。リーダーというのは意外と隠れていて、見つかりにくいですが、いかにリーダーをいっぱい作るかは企業文化として重要視されています。リーダーとヒーローというのは、意外と兼ね合いが難しかったりします。というか、リーダーはヒーローになりにくい。みんなを持ち上げて、チームを引っ張る牽引力となるのがリーダーだからです。

“文化があることで嬉しい、嬉しくない、変わらない、人や組織の特徴がそれぞれあれば教えてほしいです。”

鈴木氏：会社にも学校にもそれぞれの文化がありますよね。その文化が好きだからそこで働いている、という人もいますよね。文化が合わなくても給料が高いから働く、という人もいますが、長持ちしにくいですね。給料だけで惹きつける文化を持っている企業は厳しい坂道を登っていくような状況になると思います。ポジティブな文化を持っていれば、労働環境だけでなく、働いていてやりがいがあるような環境になります。そういう意味では、経営の立場からも文化は大事だと思いますね。

企業文化を広める役割の人＝人をよく観察する人は、企業の文化を浸透する活動をする際に上手に進める事ができる、と考えられています。最初からドンピシャに企業文化に溶け込む事ができる人、というのはなかなかいないので、チームに新人が入ってきた時によくその人を観察して気がついた事を積極的に会話を持ちかける人はうまくいくと思います。

異なる企業文化に入った人＝既成概念や過去の成功に囚われず、新しい事を学ぼうという姿勢を持つ人は、新組織に入った時にその文化を吸収する能力を発揮できるはずです。

“客先に入って仕事するスタイルの企業はどういった文化を作っていくのが良いのでしょうか”

鈴木氏：これは難しい課題です。お客様のサイトは独自に企業文化やルールが徹底されている世界ですので、言うまでもなくそれを壊すような行為はよくないです。よくMenlo Innovationsでやっているのは、逆にお客さんに会社に来てもらい、Menlo Innovationsの文化を体験してもらうようなイベントを開催します。プロジェクトステータス会議、等を通して、メンバーがどのようにコミュニケーションしているのかを可視化することで啓発する事ができるようです。

清田氏：場合によっては、チームではなく一人で客先に行く場合もあると思いますが、その場合は客先の文化に染まってくる人も多かったですね。あとは、一人で客先にいると、今いる会社にいる意味がわからなくなったりします。そういう意味で、戻りたくなるような、アットホームな文化を築いて行く必要が大事ですよね。

鈴木氏：どう文化面で生産性を上げられるかを説明するのがリーダーの仕事だと思います。

“リモートにシフトした結果、残業が全体的に非常に増えています。やるべきことは減っていないのですが、メリハリがなくなっているのか、生産性が落ちているのかよくわからず原因としては何が考えられるのでしょうか。”

清田氏：オフラインだと、終電があったりするので強制的に仕事をやめるタイミングがあるのですが、一人だとやめどきがわからなかったりしますよね。やはり、やめるべきポイントを自分で作ったりチームで作ったりしないと、ズルズルしてしまいますよね。

鈴木氏：インフォーマルな雑談をする機会やオンライン上の場所を用意することによって、従業員の間の会話が活性化させる事ができるようになります。オフィス環境と違って、オンラインはそういった1on1の会話が極端に減ってしまうため、意識的にそういう場を作ってあげる配慮が大きな効果を発揮します。会話の中から、従業員の意識をもっと拾い上げ、生産を落としている原因、ついつい残業を超過してしまう要因などを確認する事が大事なのでは、と思います。

清田氏：このあたりで時間になるのでそろそろ締めようと思いますが、やはりリーダーシップによって文化はどうにでもなるかなと思いました。

鈴木氏：リーダーシップの定義は様々ありますが、清田さんのいうとおりだと思います。
リモートの環境において何より大事なのは、ドキュメント化だと思います。色々な記録が残り、共有できるリソースができるので、あとあと役に立つと思いますね。そういったところを意識して仕組みを作ったら、うまく回って行くかと思いますね。

まとめ

エンジニア組織の文化形成Talkはいかがでしたでしょうか。
自組織に持ち帰ってポジティブな効果が1つでもあると嬉しいなと思います！

参加者の声

・とても本日の対談は参考になることが多々ありとても良いものでした。
・2人の熱いトーク、面白い内容でとても参考になりました ありがとうございました。 すぐに使いたい、取り組みたいワードが たくさん聞けて大変良かったです。
・ボスとリーダーの違いについての説明から、リモートワークでこそリーダーシップがどれほど重要であるかを認識しました。

つづいて当日回答しきれなかった質問への回答を紹介します！

参加者からのご質問

“今日のお話は大変興味深く自部門にも活用したいと思っていますが、組織によってやり方は変わってくると思います。
組織での最適解を最初からメンバー皆で探した方がいいのか、文化をよく知っているリーダーが方向性を示す方が良いのか少し悩んでいます。今日のような話を組織でする時のお勧め進め方はあるのでしょうか？”

鈴木氏：まずは企業のリーダーが自分の考え方やどのようにそれを実現しようとしているのかを明確にする事だと思います。特にゴールの設定、定量的な方法があればベストですが、そういう指針を出して、みんなでそのゴールを目指そう、という動きになればいいと思います。

より具体的にそれをどのように実現するかは、確かに組織やチームによってやり方は違ってくると思います。文化をよく知っているリーダーが各チームのプランを聞いてアドバイスできるような仕組みがあれば良いと思います。

よく、OKR手法を使います。チームごとに期毎／年度毎のOKRを設定して、それを期末に達成できたのかを振り返る習慣をつけるようにしています。

清田氏：組織メンバーにて対話(ダイアローグ)を重ね組織の文化を理解するのが良いと思います。

“例えばなんですが、現在はコロナだからリモートしているというところが多いと思うのですが、コロナが完全収束したとした場合にリモートをやる目的とか理由とかって無いように思っています。そこらへん、どう思われますか？”

鈴木氏：リモートでやる方が、生産性が上がる業務、というのがある事が割と明らかになっています。もちろん、組織によって異なりますが、よくでてくるのは、一人で邪魔されずに開発や執筆作業などをする時、機密性の高いプライベートな会話、クリエイティブな発想、必要な時だけ人と繋がるような仕事、等です。

オフィスに戻ることによって、これらの作業の生産性が下がるのはもったいないので、うまくリモートとオフィス勤務のバランスを取りながら運営していくのがよいのでは、という提案は多いようです。

清田氏：リモートワークにより職場、通勤による場所、時間の制約が少なくなります。
今まで場所の制約によって一緒に仕事をすることが難しかった地方、海外の方との協業がし易くなります。育児や介護で時間的制約がある方の活躍も見込めます。
また、通勤で使っていた時間を家庭・趣味・学習などに充てることも可能になります。

“リーダー、ボス、マネージャー、ファシリテーターなどみんな違いますね。”

鈴木氏：それぞれ、職制上の役割と、チームビルディング上の役割がありますので、社内でこういった役割の違いについて理解できるような啓蒙活動ができるよう良いと思います。

“複数の部門が関わるPJで、かつ、部門によって文化が異なる場合、現状、部門間の文化の違いはクッション役を立てて対応しておりますが。ほかに対応策などございますか。”

鈴木氏：それぞれの部門のリーダーが一緒になって協業のやり方を決めていく必要性はあると思います。間に両組織の違いを知る調整役を入れるのは非常に有効な方法だと思います。プロジェクト自体の共通の視点というかゴール、があるはずで、そこを各チームが共有した上で具体的な進め方を決めていく事が重要だと思います。
共通のゴールは、大方はお客様の視点からみたプロジェクトへの期待で、お客様の最終的な満足度を定量的に計測する方法を決め、それを達成／超える事を各部門の目標として文化を見直す事が有効かと思います。

清田氏：組織文化は組織の目的、目標に異なります。つまり組織の目的・目標を知らないと、何故その組織がそのような行動を取るのかが理解できません。まずは、関わる部署の目的、目標を知り、何を重視して、どのような思考・行動をとるのかを知ります。その後、対話・議論を重ね、落とし所を探るのが良いと思います。

イベントレポートは以上となります◎今回も盛りだくさんの内容となりました！ご登壇してくださった清田さん・鈴木さん、ご参加頂きました皆様、ありがとうございました。
次回のイベントもお楽しみに♪

【イベントレポート】アジャイル開発エンジニア勉強会

こんにちは！TECH Street編集部です。

今回は、2021年3月18日（木）に開催した「アジャイル開発エンジニア勉強会」のイベントレポートお届けいたします！

レポート前半では、皆さまの発表内容をご紹介。記事後半では、当日の質疑応答の内容も紹介します！

doda Recruiters 1プロダクト複数チームスクラムへのチャレンジ
鳥居 旭洋／パーソルキャリア株式会社

鳥居さんは、2019年10月に、dodaが提供するダイレクトソーシングサービスであるdoda Recuritersのスクラムマスターに着任。現在は、パーソルキャリアのプロダクト領域へのスクラムプロセスを展開し、チームや開発プロセスの改善を推進されています。

doda Recruitersについて

doda Recruitersはdodaの持つ会員データベースに企業が直接アクセスし、転職希望者の登録情報を確認した上で、直接スカウトメールが送れるサービス。

doda Recruitersでスクラムを導入した背景

当時、下記のような課題を抱えていたことから、アジリティの向上や施策効果の最大化を狙い、スクラム化を図ったのだそうです。

①組織・人の課題
＜エンジニア組織＞
・プロジェクトごとにベンダー請負開発なので、仕様を把握しているエンジニアが内部に残らない
・新規アサインの繰り返しなので、既存に影響を与えないような増築ばかり
・言われたものを言われた仕様で作るベンダー気質

＜企画組織（ビジネス企画・プロダクト企画）＞
・事業計画と納期が最優先
・要件定義フェーズが終わった後はIT組織とベンダーにまるっとおまかせしてしまう

②プロセスの課題
・最初の要件定義が長引いてエンジニアとの最初の会話まで1ヶ月以上かかる
・基本的にウォーターフォール開発かつ、作るものを明確化して最初に予算承認を取っているので、プロジェクトの途中で状況が変わっても作りきるしかない
・顧客の状況が変わって、当初一番良いと考えて作ったものがリリース後に現場から批判を受ける状況も発生…！

③システムの課題
・課題の合わせ技で大小様々な技術負債が山積み
・技術負債を解消するために大規模プロジェクトが計画されるような状況

doda Recruiters スクラムチームのノウハウ

doda Recruitersのスクラムチームの構成は上記図の通り。各チームはスクラムマスターとPOと、企画側のプランナー、エンジニアで構成されています。

開発の流れはこちら。全体バックログチェックを中心にし、プロダクト関係者全体でデモとフィードバック、リリース判定、優先度検討を行います。そこから、バックログリファインメント、スプリントプランニングをし、スプリントを1週間で実施するそう。

毎日、全体デイリースクラムとチームデイリースクラムをしてアーキコミュニティは隔週に有志で開催しているそうです。スプリント開始から1週間後、スプリントレビュー・振り返りをし、また全体のバックログに戻ってくるという流れとのこと。

ノウハウ①：チームテーマとチームのバックログ

当初は、Large-Scale Scrum(LeSS)の考えをベースに1つのプロダクトバックログで優先度をつけ運営しようと試みていましたが、様々な問題でスクラムが健全ではない状態になってしまったのだとか。

ここで、プロダクトマネージャーを中心に、プロダクトビジョン、注力テーマ、中間KPIを設定。POはスクラムの中で話し合い、注力したいテーマに絞ってインセプションデッキを作成したそうです。

これにより、各チームが独自のプロダクトバックログを持ち、プロダクトのテーマに沿った施策をチームが受け持つ形をとることで、チームの中からもテーマに沿ったユーザーストーリーを出す形が実現できました。

また、チーム内での効果の最大化を狙って施策を考え、プロセスの改善を図ることができるようになるいい変化もあったそう◎

ノウハウ②：アーキコミュニティ

1チームのスクラムの場合は、経験の蓄積や振り返りをチーム全体で共有し、自チーム内で完結することができたので、改善が図りやすい状態となります。しかし、複数になると、経験や改善がチームで閉じてしまうため、コンポーネント共通化など他チームにも影響がある改善がやりづらい状況となっていました。

このような状況から生まれた様々な課題を解決するため、アーキコミュニティを導入したとのこと。
アーキコミュニティでは、チーム内の有志が集まり、隔週で各チームの取り組みを共有します。チームをまたがった改善案を出し合って議論し、アクションと主担当を決めることで、それぞれがチームに持ち帰って活かす・チーム間で連携して改善を実行することができるような体制づくりをしたそうです。

ノウハウ③：MVF（Most Valuable FURIKAERI）

MVF（Most Valuable FURIKAERI）は、クォーターごとに、プロダクト関係者全員がいる場所で、各チームでよかった取り組みを共有するのだとか…！これを実施することで、若手を中心に「次は表彰されるようにチャレンジしたい」という意識が出てきたそうです。

ノウハウ④：リモート下のスクラムで大事なこと

鳥居さんによるとスクラムで大事なのは、コミュニケーションをいかに活発化させるか、そして心理的安全性をいかに確保するか。これらを実現するため、doda Recruitersでは、下記のことを実践したそうです。（めちゃくちゃ具体的です…！）

・同じファイルをリアルタイムに、みんなで同時に編集できるOneDrive上のファイルをフル活用
・Slackチャンネルを分割＆用途を明確にして発言しやすい環境を作る
・昼会・夕会を作り、話す場を作る
・週2回アイスブレイクのためだけに集まる「おやつタイム」の開催
・毎朝のアイスブレイクで「トークテーマ出題スロット」を活用
・個別の1対1ミーティングで「自分がチームをリードする」という意識をメンバーに持ってもらう

doda Recruitersでは、この先、「全体最適で優先度を考えられる組織づくり」を目指していくそうです。理想は、「プロダクト関係者が、今チームでやっていることをしっかり把握」し、「今これをやったほうがいい！」をエンジニア含めてみんなで考え、「今やるべきもの」を「今のSprintでやっている」状態になっていること。

また、開発リードタイムをより短縮できるように、技術負債をより低コストで削減できる仕組みも導入も目指しているそうです。このためには、システムの現状の可視化の強化及びCI/CD環境の整備を実施していく予定だそうです。

最後に、スクラム化を進めていてよかったことを3つまとめていただきました。

✓スクラムチーム全体で技術負債の解消を行う意識を持ってくれた
リファクタリングを積極的にやり始めてくれるようになり、アーキコミュニティを通じてチーム間で連携し、より良いシステムになるように意識しているそうです。

✓エンジニアがプロダクトの成長に意識を向けてくれた
言われたものを早く作ることから事業成長に向かって技術をいかに使って解決するかが楽しい、と言ってくれるメンバーが出てきたのだとか！

✓リリースまでのリードタイムを大幅に短縮できた
小さく作って早く出す、が実現できたのでこれまでよりも短い期間でリリースすることができているそうです。

フルリモート x 副業メインな小さなスタートアップの開発現場
上原 将之／株式会社トラックレコード

上原さんからは、“アジャイルでやっていくしかない”初期のスタートアップの試行錯誤の現実をお話いただくとともに、フルリモートかつ、副業中心で進めている組織で工夫をしているポイントをお話しいただきました！

現在20名のメンバーが働いているトラックレコード社ですが、Slackアプリ「Colla（コラ）」の開発チームにフォーカスすると半分以上を副業のメンバーが占めているのだとか。

日々の開発は“いわゆるオレオレスクラム”で実施されているそう。厳密なスクラムの運用というよりは、1週間でスプリント、全体の週次会議、振り返り、デザイン定例という形で回しているのだとか。日々のタスク管理はnotionを使用、開発のコード管理はGitHub、CI/DeployはGitHub Actionsを使用しているそうです。

このような副業メンバーメインの環境の中で発生する日々の失敗や、それに対する工夫をご紹介いただきました！

権限管理機能の開発

要件

もともとCollaの設定には権限による制限がなく、誰でも設定ができていたため、大きめのWSだと設定の乗っ取りも発生していたそう。そのため、特定の権限を持った人のみが設定できるように管理機能の開発を実施。

課題

この機能の開発にあたり、副業メンバーとのコミュニケーションに問題が発生。Colla自体、シンプルな仕様となっているため、mini specや最低限の仕様書を元にタスクアサインをしたそうですが、レビューのたびに色々な例外条件を思いついてしまい、どんどん要件が複雑化、度重なる改修にレビューコストもどんどん増大していく事態に…！最終的に、進行中の別機能と一緒に検討しないと難しいということに気づき1ヶ月かけてやってきたものが全てひっくり返ってしまう状況になったのだとか。

何がいけなかったか

そもそも副業は本業もある中で時間制約が厳しい（週に1日程度、週によって変動）中で参加してもらっているのにもかかわらず、ドメイン知識の理解など、前提条件の共有にあまり時間を取れずにいたそうです。「自分だったらこれくらいできそうだから、きっとこれくらいできるだろう」と、コア機能を雑に依頼することは、だいたい失敗に繋ってしまうのだとか。

学び

影響範囲の大きいものについて、初期フェーズは特に、フルタイムでコミットできる社員が自らやるべきであると気づいたそうです。ドメインの複雑さにもよりますが、時間制約がある副業メンバーにとっては、例外ケースの考慮などがそもそも難しいのだとか。

また、「時間がないこと」を免罪符にせず、例外ケースなど含め十分検討できるレベルまでは要件を詳細化することも大切な要素であるそうです。こちらは副業メンバーのアサインには関係なく、タスクの見積もりやスケジュールにも関わってくる要素のため、今後は十分に時間を使うことに。

ルール化の重要性

課題　

色々なメンバーが関わってくると、色々な形でPull Requestが飛んでくる状況となりますが、概要説明や補足コメントがないと、キャッチアップに時間がかかり、バラバラな命名やファイル配置が問題になるそうです。また、Pull Requestだけでいつレビューするタイミングなのかわからない状態になってしまい、レビューコストの高さが問題になっていました。

この状況を解決するため下記のことに取り組み、レビューコストが劇的に改善したのだとか。

CI環境の整備

CI環境自体はもともとあったものの、なるべくPull Request時点で問題が発生しないように対応したそうです。

Pull Requestのルール化

WIPやReviewersの追加、コメントの仕方などをルール化。

設計方針の言語化

どういう構成にしたいか、命名規則はどうするかなどを言語化。

月イチ1on1

副業メンバーとも月に一回、1on1を実施しているそうです。直近のスケジュール感や今後の方針の説明だけでなく、「こういうことをしようとしているのだけど…」という会話から、本業で似たようなことをやった、などといった話も出てくるのだとか！単純に業務の共有だけでなく、それぞれが持つノウハウの共有をしてもらえる点でも非常に有意義なものとなっているそうです。

フルリモートならではの問題、学びについても共有していただきました。

少なくとも現状フルリモートが原因でチームの生産性が著しく下がった、という状況がないのですが、一番はトラックレコードで開発しているSlackアプリ「Colla（コラ）」の存在が大きいそうです！

Colla（コラ）とは？

Collaは、Botが社員インタビューをしてメンバー紹介をしてくれる無料Slackアプリ。コロナ禍におけるリモートワークで、コミュニケーションがどんどん減っていく中で企業が抱える課題を解決してくれるそう。

皆さんも下記のような課題をかかえているのではないでしょうか？

・コロナ禍でリモート前提の働き方にシフト
・チャットベースだとコミュニケーションが偏りがち（雑談がしにくい…）
・新メンバーのオンボーディングもなかなか対面で顔を合わせることが出来ない

そんななかでCollaはこのようにコミュニケーションをアシストしてくれます。

・Collaさんが勝手にメンバーに質問、毎日回答を発表。
・新メンバーがSlackにJoinしたタイミングで質問、回答するとみんなに紹介してくれる。

このCollaを使うことで、強制的に雑談の場が生まれ、全く接点のないメンバー同士でコミュニケーションができ、チームの一体感が生まれるのだとか。リモートワークでのコミュニケーションにお困りの方は、ぜひ利用してみてください◎ 

「くらしのマーケット」開発のしくじりとカイゼン話
Megumi／みんなのマーケット株式会社

 くらしのマーケットでプロダクトマネージャーを務めるMegumiさんからは、開発のしくじりとカイゼン話をご共有いただきました！

スクラム開発導入時の“やりにくさ”

3年前に初めてスクラム開発を導入した際は、誰も経験者がいない中、アジャイル開発の実践本である『カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで』に沿ってスクラムを取り入れ、1年弱開発を進めていったそうです。

しかし、やっていく中で、“やりにくさ”を感じるようになり、完全なスクラム開発はやめて、自社に合うように変化させていく方向にかじを切ったとのこと。

当時、開発チームでは、下記のような「やりにくさ」を抱えていたそうです。

①リリース日を出せない
②チーム内でやっているタスクがバラバラで、一緒のチームではなくてもいい感がある
③ドキュメントが溜まっていかず、新しいメンバーが増えた際に開発しにくい
④ミーティングの時間が多くなり、開発に割ける時間が少なくなる
⑤振り返りはするけど振り返りっぱなし

こちらは、他社の皆さんも共感する「やりにくい」なのではないでしょうか…！これに対して、Megumiさんは下記の方法で、カイゼンの取り組みをしていったのだとか。

①リリース日を出せない
→半年以上かかりそうなプロダクト開発や明確な期限のある開発はアジャイルをやめたそうです。この方針を採用することで、今の状態がいいのか悪いのか判断をしやすくなったそう。そして最初にすべて見積もることで考慮漏れも防ぎやすくなったとのこと。

②チーム内でやっているタスクがバラバラで、一緒のチームではなくてもいい感がある
→開発内容によってチームを組み替えることによって改善。スクラムを行うことでコミュニケーションは密になるものの、他のプロジェクト内容を全員が知っている必要がなく、メンバーが話半分で聞いていることがあったそうです。また、他部署からの依頼が多いため、計画通りに進まないことも多く、雰囲気が悪くなってしまうことも。

そこで、7〜9名体制のチームは、大きいプロジェクト1つ＋細かいタスクを、4〜5名体制のチームは、大きいプロジェクトを1つ、といったように、開発内容に応じてチームを組み替えていったそうです。また、小さいタスクは即応チームを作って対応したそうです◎

③ドキュメントが溜まっていかず、新しいメンバーが増えた際に開発しにくい
→月に一度、ドキュメントだけを書くドキュメントデイを設定することで改善。エンジニアがコードを書かない日を意図的に作ったことで組織の拡大にも対応ができるように◎

④ミーティングの時間が多くなり、開発に割ける時間が少なくなる
→スタンドアップミーティングからフルリモート環境に変化したことにより、話が盛り上がってミーティングが長くなりがちに。これに対して、デイリーミーティングに時間制限を設け、違うテーマについて話したければ別ミーティングを開くようなルールを設定し、改善を図ったそうです。

⑤振り返りはするけど振り返りっぱなし
→Tryは毎回でるものの、1回きりで終わってしまうなど、積み上がっていない状況だったためKPTでのTryに対して振り返りを実施し、Keepするかしないかを判断するようにしたそうです。これによって、チームの改善の定着スピードも上がったのだとか。

課題を明確にし、一つ一つ改善をしていけているのが素晴らしいですね◎また、このほかにも、やってよかったことをご共有いただきました。

✓自分が開発していない仕様をチームメンバーと話す場を作ったことで、細かい認識のずれを修正する会話が減った。これにより、PMとエンジニアが1対1で話していたことが誰に聞いても答えをもらえる状態になり、スピードアップにつながった。

✓ユーザーテストを1ヶ月に1度実施。そしてテスト日程を事前に設定することで、自然とタスクの優先度の見直しができ、完成させる意識も高まった。

今後について

今後は、2月よりエンジニアの目標がプロダクトの期限や数字から技術に対するものに変更になったため、自己完結できるチームでプロダクトを作りたいと考えているそうです。また、これまでの改善の積み重ねにより、臨機応変にチーム体制を変えていける土台があるため、より良い方法を模索していくのだとか！

今回は、やりにくさが何かを突き詰めていき、一つずつ潰していく作業を積み重ねることで改善に取り組んでいく、というお話をいただきました。「やりにくさ」は会社によって異なるため、自社に合わせて改善していくことが重要とのまとめで締めくくっていただきました◎

まとめ 

今回はアジャイルに取り組まれている各社の事例共有から、改善施策まで盛りだくさんの内容となりました◎　

参加者からの声

・アジャイルを導入したことによって発生した課題や、改善への取り組みなど、実体験に基づいた知見が聞けたのが良かった
・取り組むまでの経緯や、失敗など具体的な事例を聞けたため。
・登壇くださった方がご自身の経験（特にうまくいかなかったこと）を語ってくれたから
濃い実体験の話だったから。
・私は今年5月よりアジャイル開発に関わるため、アジャイル開発を取り組んだ方々の失敗談やノウハウ、マインドや参考本など色々な情報が得られて、大変参考になりました！

つづいて、各登壇者の方々へのQ＆Aを紹介します。当日ご回答しきれなかったものも紹介しております！

参加者からパーソルキャリア鳥居さんへのご質問

（Q）アジャイルで感じるデメリット教えてください。
（A）ミーティングの時間が多く縛られて辛いというところがあります。あとは、見通しが立てづらいところも。遅延を防ぎたい思いがあったので、アジャイルを入れることで作業が増えて遅延が発生することは、報告しづらいところもあります。あとは、課題やタスクを透明化するのでサボれなくなる＆なあなあにしていたことに対してしっかり考える必要が出てくるという点ですね。

（Q）みなさん、ウォーターフォールの経験ってどれくらいですか？ウォーターフォール経験がないとアジャイルの良さって語れないですもんね？
（A）ウォーターフォールは8年くらいです。2018年くらいに初めて「an」でアプリのスクラムマスターを初めてやって以降はスクラムマスターでやっています。

（Q）スクラム導入しても、設計者と実装者がぱっきり別れて、スプリントを切ったウォーターフォール開発になってしまいがちなのですが、どう回避すれば良いでしょうか？
（A）メリット多いのならそれでいいのですが、その状態が良いとメンバーが考えていないならば自然と振り返りの中で変えるために取り組みを実施すると思います。が、スクラム的な回答になります。
自分がそういう状況に直面したら、基本的に実装者の要件定義スキルが低い場合だと思うので、小さめのUSを一人に任せて設計→実装を体験させます。

（Q）アジャイルの何かフレームワークの儀式をやるだけではアジャイルではないと思いますが、アジャイルであるというのは具体的にどういったものでしょうか？ 何ができいれば「我々はアジャイルです」と言えるかについて何かあれば教えていただきたいです。
（A）改善、施策問わず、現状を見つめて次何をどの優先度でやるか、ということを常に考えて、常に実行している状態。

（Q）スクラム開発の場合、各メンバーが自律的に動くことが求められるかと思います。外部ベンダーが開発メンバーに加わるとなるとスライドにもありましたが指示待ちになってしまうことも多いかと思います。そのあたりを解決するために何か工夫されたのでしょうか？
（A）メンバー一人ひとりの人格を大切にして話をし、外部ベンダーの人も内部の人として考えて自律性を出してもらえるように試していくしかないと思います。外部・内部だろうがあまり変わらないと思います。

やはり一人ひとりに自律した行動を行うように1on1で声をかけたことが大きいかと思います。
あと、MVFなどの取り組みを始め、様々な場で自律的な行動をした人を褒めまくってます。
振り返りでKPT＋Goodというやり方をしていまして、そのGoodのところでちょくちょく褒めてます。

（Q）アーキコミュニティって興味あるけど毎回モチベーション高く参加してくれるかが課題だったり・・ 何名くらいで実施してますか？
（A）各チーム1名ずつと、スクラムマスターで合わせて4名ほど。現在は8名くらいになっている。
モチベーション低くなってきたら、やめて別の方法を探したほうが良いかもです。僕たちは一定うまくいってるので続けてますが、領域毎とかで分けて人数は減らしたほうがいいかな？と最近考えてます。

（Q）ウォーターフォールの前例しかない発注企業を説得するコツや、ご経験をお聞きしたいです。
（A）今後うちはこういうふうに変わっていこうと思っているから、それに対して協力してほしい。と伝えてきました。また、複数ベンダーに相談した上で、アジャイルな開発に付き合ってくれるベンダーを選んだ場面もあります。

（Q）企画部にいます。 企画の要望を開発スクラムに渡すところに課題を感じています(要望粒度・コミュニケーション方法、技術知識の差etc..) 企画部と開発部の連携のコツがあれば教えて頂きたいです。
（A）一度企画と開発それぞれで不満に思っていること、やられて困ることを腹を割って話すことをおすすめします。
あと、企画はここまで作らなきゃいけない、ここまでは企画の領域。などと線を引かずに、エンジニアが歩みよる（というか領域を食いにいく）とうまくいくと思います。
もちろんエンジニアの役割や領域について、企画側が歩み寄る前提ですが。

参加者からトラックレコード上原さんへのご質問

（Q）アジャイルで感じるデメリット教えてください。
（A）アジャイルしか経験していない立場ですが、スケジュール感もうまく組めない中、ボトムアップで進めることもあるので、業務が肥大化してスケジュールが進まないことが大変です。

（Q）上原さんの感覚で、今は少数精鋭だが、何名くらいになってきたら体制もろもろ刷新を検討しないと・・・と感じますか？
（A）少なくとも、常に刷新を検討しないといけないと感じています。あえて少数精鋭でやっているというよりは、やるしかないから頑張っているというニュアンスです。

参加者からみんなのマーケットMegumiさんへのご質問

（Q）即応チームは何名で誰がこれは「即応チーム」だねって決めているのですか？
（A）最初は5名くらいでスタートをし、CTOが主体となって決めています。

（Q）自分たちで「やりやすいやり方に変える」ことは、どのような経緯で進んでいったのですか？
（A）メンバーの一人が本を読んだりして勉強したことの中で「やってみるか」という一声で始まることも多いので、やりやすさはありました。

（Q）「小さいタスク」はその時々によって量に波があることが多いと思います。即応チームメンバーの稼働の変動についてはいかがでしたか？ 手の空いた時にしていたことや、手が回らなくなった時にどうしたかなどお聞きしたいです。
（A）依頼タスクやバグ修正などやりたいことはたくさんあり、タスクがなくなることはありませんでした。

（Q）やりにくさの共有すごくありがたいです。よかったこともあったという事で、模索中かもしれませんがスクラムもホンキでやる予定はある感じですか？
（A）スクラムも視野には入れています。今後の開発体制に関しては現在検討中です。

（Q）即応チームの人数設定、チーム構成の変更はどのようなサイクルで誰がジャッジしているのでしょうか
（A）CTOと即応チームのメンバーで、毎月新しい人が入る度にジャッジしています。

今回のイベントレポートは以上となります。
ご参加いただいた皆さま、ご登壇者の皆さま、ありがとうございました！次回のイベントもお楽しみに♪

【国内・海外】4月のテックイベント・エンジニア勉強会まとめ

本記事では、会員へのアンケートで興味関心があるキーワード・テーマに沿ったオンラインイベント・エンジニア勉強会などを紹介いたします（※開催状況は3月31日時点の情報となります）

国内のテックイベント

■Kotlin Tech Talk 〜Kotlin開発で経験した失敗事例や課題解決の知見共有会〜
開催日：2021年4月5日（月）19:30〜20:30
公式サイト：https://mercari.connpass.com/event/206751/
キーワード：Kotlin、jcenter、TIPS共有

■第22回 PostgreSQLアンカンファレンス@オンライン
開催日：2021年4月6日（火）19:30〜22:00
公式サイト：https://pgunconf.connpass.com/event/206380/
キーワード：PostgreSQL

 ■Mercari Platform Group Tech Talk #1 (Day2)
開催日：2021年4月7日（水）19:00〜20:00
公式サイト：https://mercari.connpass.com/event/207062/
キーワード：マイクロサービス

■#006カジュアル勉強会 ゆるく学ぶPython勉強会
開催日：2021年4月7日（水）20:00〜21:00
公式サイト：https://extech-casual-learn-sendai.connpass.com/event/207243/
キーワード：Python

■【Online】LINE Developer Meetup - Private Cloud
開催日：2021年4月8日（木）16:00〜18:00
公式サイト：https://line.connpass.com/event/202954/
キーワード：プライベートクラウド、パケットフォワーディング

■Developer eXperience Day CTO/VPoE Conference 2021
開催日：2021年4月10日（土）12:30〜19:00
公式サイト：https://cto-a.connpass.com/event/207121/
キーワード：ソフトウェア、DX

■データサイエンティストのためのMLOpsの実践
開催日：2021年4月14日（水）19:00〜20:00
公式サイト：https://quantumblack.connpass.com/event/208083/
キーワード：データサイエンス、MLOps

■DevOpsDays Tokyo 2021
開催日：2021年4月15日〜16日
公式サイト：https://www.devopsdaystokyo.org/
キーワード：ソフトウェア開発、ITインフラ運用

■10年以上続くSaaSプロダクトの開発戦略／オール仮想化、E2Eテスト、リファクタリング
開催日：2021年4月21日（水）19:00〜20:30
公式サイト：https://rakus.connpass.com/event/207767/
キーワード：スモークE2E、技術負債

■第30回 Japan IT Week 春
開催日：2021年4月26日～28日10:00～18:00（最終日は17:00まで）
公式サイト：https://www.japan-it-spring.jp/ja-jp.html
キーワード：AI、RPA、セキュリティ、マーケティング

海外のテックイベント

※日程はイベント・カンファレンスの開催国のものとなります。

■HANNOVER MESSE Digital Edition
開催日：2021年4月12日〜16日
公式サイト：https://www.hannovermesse.de/de/

■Dublin Tech Summit 2021
開催日：2021年4月21日〜22日
公式サイト：https://www.eventglobe.net/event/dublin-tech/

■Adobe Summit 2021
開催日：2021年4月27日〜28日
公式サイト：https://www.eventglobe.net/event/adobe-summit/

※本記事内の情報は各イベント公式サイトを参考にしています。詳細については公式サイトを御覧ください。

【イベントレポート】Javaエンジニア勉強会

こんにちは！TECH Street編集部です！
今回は2021年2月25日（木）に開催した、 「Javaエンジニア勉強会」のイベントレポートお届けいたします。

今回の登壇者は初代Javaチャンピオンの櫻庭 祐一さん！

今回は「モダンなJavaの書き方」をテーマに、ライブデモを交えながらセミナーをしていただきました◎

イベント冒頭では、参加者の皆さまにアンケートを実施。今回のイベントにご参加いただいた方々のJava活用歴は、、、10年以上活用されていると回答した方が最も多い結果となりました…！

ここからは櫻庭さんのセミナーをご紹介。記事後半では、質疑応答の内容もご紹介していきます！

「モダンなJavaの書き方」（櫻庭 祐一／初代Javaチャンピオン）

Java チャンピオン（Java Champioin）は現在、全世界におよそ300名いて、日本には5名のチャンピオンがいるのだとか。

今回のセミナーの講師である櫻庭さんは、日本で1人目のJavaチャンピオンで、なんとJava歴は26年！まずは、Javaが変革する背景からお話を伺いました。

Javaが変革する背景

まずはハードウェア面での変革について。20年前はシングルコアが当たり前だったものが、現在はマルチコアが当たり前になっています。マルチコアだけでなく、Vector ComputingやGPGPUが導入されて一つの命令で複数のデータを計算することができます。メモリも大量に増加し、通信も超高速となりました。

このようなハードウェアの変革に伴い、ソフトウェア側も様々な変革が起きました。システムが巨大かつ複雑となり、更新は頻繁に。技術的には、マイクロサービス・コンテナ・AI/MLなどの導入という変化があります。このようなサービスは、ハードウェアの変革があったからこそ生まれたものであると櫻庭さんは語ります。

Javaのトレンド

Javaには様々なトレンドがあるそうですが、今回は特に3つのトレンドをご紹介いただきました。

①可読性の重視
システムが巨大になり、ソースコードも増えていく中で、コードを見ただけで何をしているかわかる「可読性」は非常に重要なポイントとなりました。

可読性をあげる機能として、var、Switch式、ラムダ式などが追加され、簡潔に可読性のあるコードが書けるようになったそうです。可読性はいつの時代も重要視されており、Java 8、Java 11、Java 17で毎回機能が追加されています。

②関数の活用
Javaの場合ラムダ式で関数を表しますが、関数型言語の特徴を取り入れてきているそうです。ラムダ式をつかったStream APIや、Flow（Reactive Stream）などの機能が追加されています。関数については、Java11までである程度の機能が追加されているとのこと。

③Immutable
関数やImmutableは、マルチスレッドで動かす際に非常に重要な概念なのだとか。こちらは最近になってより重要になってきており、イミュータブルなクラスを簡単に作成できるRecord機能がJava17で正式に追加されるのだとか。

書き方のポイント

まずは、ラムダ式を自由に使えるようになることが非常に重要だそうです。また、オブジェクトの状態変化をなるべく避けることも重要なのだとか。昔のオブジェクト指向では、データと手続きがあり、データを変化させるようなイメージで語られていたそうですが、今は逆に、一度オブジェクトを作成した後は、状態を変えないように、そしてできれば変えられないようなクラスを作る方法が推奨されているのだそうです。

この背景としては、もちろん可読性を向上させるという意図もありますが、状態が変わらないとマルチスレッドになりやすいため、マルチスレッド化が容易になるという理由もあるそうです。また、処理の切り分けも容易になるのだとか。大きなシステムでは状態変化を完全に避けることは難しいとは思いますが、変化するところと変化がないところを切り分けて作る意識が大切なのだそうです。

ここから実践！

public classのメソットを使って、顧客リストから製品IDごと購買数マップに変換する様子をいにしえの書き方→Java5での書き方→Java8以降という流れで見せていただきます。

public class Customer {
…
// 購買履歴を製品IDリストとして返す
public List getHistory() { …

いにしえのJavaで書くとこんな感じとのこと。

-----------
public Map convert(List customers) {
　Map productCountMap = new HashMap<>();

　 for (int i = 0; i < customers.size(); i++) {
　Customer customer = customers.get(i);

　List ids = customer.getHistory();
　for (int j = 0; j < ids.size(); j++) {
　　int pId = ids.get(j);
　　Long productCount = productCountMap.get(pId);
　　if (productCount == null) {
　　　productCountMap.put(pId, 1L);
　　　} else {
　　　productCount++;
　　　productCountMap.put(pId, productCount);
　　　}
　　 }
　 } return productCountMap;
}
-----------

①顧客リストを受け取り、それをfor文で回す
②一つ一つオブジェクト、ヒストリーを取り出す
③二重ループでヒストリーIDを取り出し、マップから購買数を取り出す
④もしない場合は新しく作る、ある場合はインプリメントしてマップに入れ直す
という処理を行うとのこと。

これの何がいにしえかというと、

・ミュータブルなマップを使っている
・ループ制御とロジックが混在しており、わかりにくいループカウンターになっている
・Longを小文字のLongにするとNullPointerExceptionが発生するためオードボクシングができない

これを、Java 5の書き方にすると、下記の通り。for-each文に変更することで、スッキリします。

-----------
public Map convert(List customers) {
　Map productCountMap = new HashMap<>();
　for (Customer customer: customers) {
　　List ids = customer.getHistory();

　for (int pId: ids) {
　　Long productCount = productCountMap.get(pId);
　　if (productCount == null) {
　　　productCountMap.put(pId, 1L);
　　　} else { productCount++;
　　　　　 productCountMap.put(pId, productCount);
　　 　}
　　 }
　 }
　return productCountMap;
}
-----------

そしてこれをラムダ式とStreamで変えていきます。
ラムダ式とStreamと聞くと、難しいと感じる人もいるかと思いますが、段階的に変えていけばそれほど難しくないのだとか。

-----------
public Map convert(List customers) {

　Map productCountMap
　　= customers.stream()
　　　　　　　　 .flatMap(customer -> customer.getHistory().stream())
　　　　　　　　 .collect(Collectors.groupingBy(pId -> pId, Collectors.counting()));
return productCountMap;
}
-----------

これを使うことで、下記のことが実現。モダンなJavaを書くことがきます。

・マップの要素を変更しないのでImmutableにすることが可能。
・flatMapを使うことで、2重ループの展開
・collectメソッドを使うことで、トリッキーなif文の排除

このようにコードが書けるようになるためには、やはりある程度ラムダ式やStream APIを使う経験が必要なのだそうです。

まとめ

以下の3つのポイントを意識して、コードを記述することがおすすめとのこと。

・可読性の向上
・関数の活用
・状態変化を避けること

特に状態変化についてはRecord機能を使うとImmutableなクラスが簡単に書けるようになるのでそれを活用してほしいとのこと！

また、新しい言語仕様や機能もどんどん増えてきているそうなので、それらを積極的に試すことがおすすめだそうです◎

speakerdeck.com

まとめ

今回は、初代Javaチャンピオンの櫻庭さんによる実演から、たくさんの質疑応答（※次のページで紹介します）と盛りだくさんな内容となりました！Javaを使うエンジニアさんにとって役立つ発見や気づきも多かったのではないでしょうか。

参加者の声

・これだけ回答いただける機会はホントうれしい！
・Javaチャンピオンの櫻庭様のお話を伺えて、何よりの光栄でございました。最近のJavaのトピックや、アンケートのご回答など、とても勉強になり、モチベーションが上がりました。
・さくらばさん！親切丁寧！
・モダンな実装方法を知ることができて非常にうれしかったです。また、質問に答えていただく時間が多くあったため非常に勉強になりました
・櫻庭さんへの色々なアンケートやオンラインコーディングが見られてよかったです。
・実際に櫻庭さんのデモが実際にどういう感覚で書き換えているのか分かりやすく、勉強になったから。

続いては参加者からのご質問と櫻庭さんのご回答を紹介します◎

参加者からの質問

(Q)できることが多くて習得・活用方法がいまいち分かりません。
(A)今、ライブラリなどがすごく大きくなっているので、大変だと思います。逆にSpring Bootなどのフレームワークを使うことで、フレームワークに則った書き方をしていくことで、いつのまにか書けるようになったりもします。なので、ライブラリを使い、自分が困っていることを解決できるようなものを自分で作ってみるというところから初めてみるのがいいのではないかと思います。

(Q)最近は減りましたが、案件で採用されるJavaバージョンが2世代前だったりします。
(A)Javaの場合はJava8で止まっていることが割と多いと思いますね。

(Q)JDKのバージョンアップはどのような基準・頻度で行われていますか？
(A)やはりLTSが一つのタイミングとなると思います。LTSは3年ごとに出るのでそれを目安に行えばいいと思います。

(Q)Java、5年前といまで一番変わったところってどんなところですか？
(A)5年前というとJava 8ですが、Java 8の後は、言語仕様はかなり変わっていますね。
今、変わりつつあるもので一番大きいのはパターンマッチングなのですが、まだプレビューの状態で、正式にはなってないですね。しかしおそらく、それが正式に入ると多分一番大きく変わるのはパターンマッチングだと思います。普通のプログラムを書くのであればJava 10からSwicth式になったというが結構大きいと思います。

(Q)チャンピオンの立場で思う、Javaの好きなところ、嫌いなところを聞いてみたいです！
(A)Javaは歴史あるというのもそうですが、コミュニティが発達していて、コミュニティでJavaを盛り上げていこうというのが非常に強い言語。コミュニティがいろいろやっているのは面白いなと思います。最近もJavaはどんどん変革していって、新しいものをどんどん取り入れているところとかも好きですね。逆に嫌いなところですが、あまり嫌いなところはないのですが、過去との互換性にとらわれているところですかね。歴史が古いので、過去との互換性にとらわれて新しいのが入りにくくなっているという部分は、少し嫌かなというところがあります。

(Q)最近会社の先輩や知り合いのエンジニアから、これからはJavaではなくKotlinだと言われるのですが、どう思われますか？
(A)Androidを使うのであればいいと思います。いわゆるBetter Javaですね。全てをJavaという世界はもうないと思うので、要所要所で使い分けて、得意な分野で使えば良いと思います。

(Q)Jigsawがあまりライブラリ群含め普及している感じがしないのですが、最近この辺りはどのような動きあるのでしょうか？
(A)Jigsawはなかなか普及していないですが、ライブラリを書くのであればぜひ、Jigsaw対応してほしいと思います。

(Q)Javaを開発するのに最も適しているIDEは何でしょうか？
(A)今勢いがあるのは、IntelliJ IDEAですかね。今日も使いました。

(Q)櫻庭さんが今まで読んだ技術書の中で、印象に残っている/ためになった作品はなんですか？
(A)Javaに関係した本の中ではEffective Javaですかね。初心者には少し難しいですが中級・上級者になりたいのであれば絶対読むべき本だと思います。

(Q)Java Championにはどうなると選ばれるのでしょうか？
(A)チャンピオン同士の互選で選ばれます。まず誰かに推薦してもらわなければなりませんので、近くにいるチャンピオンを探しましょう。チャンピオン同士が次誰にするかを話し合いながら、推薦する人を選んでいます。

(Q)一番好きな Java のクラスは何ですか？
(A)Optionalクラスが好きですね、ストリームも結構好きですが。Optionalはなかなか使っていただけないので、ぜひ使ってほしいです！

(Q)他にも古（いにしえ）のJavaの書き方があればおしえていただきたいです！
(A)Genericsがなかったので、Genericsを使わないで書くというやり方でした。あとはif elseですかね。

(Q)JVMに苦手意識をもっています。。
(A)Javaのアプリケーションを書く上でJVMをそこまで意識する必要はないです。最近は早いので、前のように止まってしまうということは減っています。私もあまりJVMの構造はよく見ていないです。

(Q)テキスト一周したくらいのJava初学者が次に取り掛かることはなんでしょうか？なにか成果物を作るとしたら、どんなものがおすすめでしょうか？
(A)自分が使いたいものを作るのが一番いいと思います。好きなものを作ってみるのが、一番モチベーションが上がると思います。

(Q)Reactiveよくわからないです…。 
(A)Reactiveは使わないとわかりにくいところがあるのですが、Reactiveなフレームワークは色々出ていているので、そういったフレームワークを使った時に理解すればいいと思います。

(Q)プロダクトの規模などにもよるかもしれませんが、レガシーなプロダクトコード(副作用があるmutableなコード)を書き換えていくためのコツなどありますか？ テストコードなども作りにくく、新しくクラスを作って既存コードを新しいクラスを呼び出すように徐々に置き換えていく方法を行なっていますが、他に良い方法があれば教えていただきたいです。
(A)テストコードが書けないとやっぱり辛いですよね。いい方法は私も本業では研究に近いものをやっているので、古いものを保守するよりも、新しいものを作っていっているので、私も知りたいです。

(Q)櫻庭さんは「継承よりコンポジション」に対してどのようにお考えですか？ 肯定派ですか？否定派ですか？
(A)継承でしか書けない時しか継承は使わないです。ただ継承が絶対ダメというわけではなくて、やはり適材適所だと思います。昔ほど継承を使うと問題が簡単になるということは少なくなっており、やはりコンポジションで書くほうが多くなっているのではないでしょうか。

(Q)先ほどのfor文などをStreamやラムダ式に置き換えるのを覚えるのには、ひたすら書き換えるしか手段ないでしょうか？正直先ほどの説明では話してくれている内容は理解できましたが、自身で再度書き換えようとしても難しいです。
(A)初めはやはり書き換えからやるのがいいと思います。いきなりStreamで全部書こうとしてもどこから手をつけたらいいかわからないと思うので、一回手をつけてみるというのがおすすめです。あとは、何をやりたいのかをちゃんとスペックの中に当てはめられるようになれば、自分で書けるようになると思います。

(Q)Mapコレクションにはまだ現在Immutableにする(BigDecimalやStringみたいに)手段は無いですよね？[自分でオーバライドして用意でもしない限り]
(A)unmodifiableMapというメソットがあるのですが、これを使うとImmutableを作ることができます。どこまでImmutableかというと、Map自体を変更できなくなるところまではできます。

(Q)櫻庭さんはアプリケーションの開発の際にDDDのエッセンスを取り入れていたりしますか？
(A)私はアプリケーションを作っていないのであまりDDDは使っていないですが、要件定義を落とし込む時にはDDDを若干使ったりもします。

(Q)Java EE(Jakarta EEの方が今はいいのでしょうか)サーバーに関する動向など何か共有して頂ければ、知っておいた方がいいことあればお話し伺いたいです。
(A)どっちかというとSpring系の方が動きは活発なような気がします。新しいJakarta EEがJava 11に対応できたので、これからどんどん変わっていくのではないでしょうか。

(Q)ヒープダンプはMAT(Eclipse Memory Analyzer)が有名かと思いますが、スレッドダンプを解析する際に良いツールなどありますでしょうか？
(A)ミッションコントロールなどは使いますが、私自身はあまりヒープダンプをがっり調べることはないです。

(Q)Javaが過去の互換性を捨て去ることはありますでしょうか？
(A)それはないと思いますが、昔ほど互換性にうるさくは無くなってきています。

(Q)Stream API やラムダ式で実装すると、デバックやエラーログからエラーの原因をたどりづらいと思うのですが、なにか工夫している点はありますか？
(A)どうしてもエラーが出てしまう時は、Streamを一度切ってしまうといいでしょう。あとは、ピークメソッドという何もやらないメソットがあるのですが、そういったものを使ってエラーの原因を調べることはしています。

(Q)10年後の Java はどうなっていると思いますか？
(A)予想もつかないですね。昔、ビル・ジョイという有名な方がいたのですが、その方が10年後どうなっているかと聞かれた時も「わからない」と答えていました。今とは予想もつかないような状態になっているかもしれません。

(Q)抽象クラスってどういうときに使えばいいでしょうか？
(A)抽象クラスはあまり登場しないですね。インターフェースにメソットが実装できるようになったので、あまり使わないですが、実装クラスが複数あって、共通部分があるのであれば抽象クラスを使うのがいいと思います。

(Q)デバックを行う際に便利なツール、工夫されていることなどありますでしょうか？また、ライブラリ側、Java側など深いところでエラーになった場合、どのように解析すればいいでしょうか？
(A)デバックはIDAのデバッガを使っているだけですね。ライブラリはほとんどがJavaなので、ソースを読むことが多いです。JVMの内部に関してはあまり追うことはないですね。もしくは英語なのでハードルが高いですが、メーリングリストで投げてみるという手もあります。

(Q)アルゴリズムの勉強をされたことがある場合、どの様に勉強したのか教えて下さい。
(A)逆にアルゴリズムの方が好きで、Cの時代からやっていましたが、主に本を読んで勉強していました。あとは、何か解決したい問題があるのであればそれに関連した書籍を読むなどですかね。

(Q)ラムダ式・Stream API確かにデバッグしにくい。 デバッグするときストリーム切ると良いっていうのは、ストリームをfor文とかに置き換えて再度実行させてデバッグするってことでしょうか？
(A)

このような形でflatMapした段階でローカル変数に入れてしまってデバッガでトレースをするときもやりやすくします。

イベントレポートは以上となります◎
櫻庭さん、ご参加いただいたみなさまありがとうございました！
次回のイベントもお楽しみに♪

【イベントレポート】営業活動を下支え！事業会社のIT施策事例共有会

こんにちは！TECH Street編集部です！

今回は2020年2月18日（木）に開催した、 「営業活動を下支え！事業会社のIT施策事例共有会」のイベントレポートお届けいたします！

各社のビジネスアーキテクト目線で営業活動の効率化や生産性向上の取り組みやI施策事例について、各社の課題に対して自社開発も交えた事例をお話いただきました♪

今回の登壇者の方はこちらのみなさま◎

有村 真大さん／パーソルキャリア株式会社
大谷 祐司さん／ミイダス株式会社
亀田 重幸さん／ディップ株式会社
※登壇順に記載

今回は各登壇者同士でお互いの発表の最後にコメントをする！という進行だったのですが、同じ業界の登壇者がどんなコメントをするのか....そんなポイントにも注目してご覧ください。

「doda」代理店営業向け 基幹システム構築プロジェクト（有村 真大／パーソルキャリア株式会社）

プロジェクト概要

今回お話いただいたのは、「doda（デューダ）」の販売代理店営業担当者向けの基幹システムの新規構築プロジェクトについて。目的と目標は下記。

目的

　・代理店関連ご有無の工数削減／システム利便性向上
　・システム二重管理の解消

定量的な目標

　・年間約6400万円のコスト削減
　・「doda」代理店販売に伴う社内工数の削減

2016年12月にプロジェクトが発足、プロジェクトが大幅に遅れそうな出来事もあったそうですが、最終的には当初予定から1ヶ月遅れの2018年6月にリリースが完了できたのだとか。今回のプロジェクトは2名体制で実施したそうです。

doda事業部の課題について

当時、dodaの販売を担当していた事業部（上図右側）は直販営業のみを担当しており、代理店への販売チャネルを持っていない状況だったのだとか。そこで、別事業部内に代理店担当部署を新設したそうです。しかし、当時は下記課題があったのだとか。

　・業務フローが複雑。2011年から変わっておらずパーソルキャリア社内だけでなく代理店営業側も工数がかかってしまっている
　・「an」「doda」どちらかにシステム改修が行われると両方のシステム改修が必要となる

AsisとTobe

もともと「an」のために作成されたシステムを「doda」に転用していたため、「an」と「doda」の代理店基幹システムを分ける必要があったのだとか。
Tobeとしては、業務プロセスにおいて不要な申請プロセスを排除し、代理店側だけで完結できる簡潔な業務プロセスを作成することを検討してきたそうです。

もともとのシステムでは「an」の基幹システムである「AL/AL-P」に「doda」の機能が共存しており、不足機能が多いために業務フローが複雑で、代理店ユーザーにとって利便性が悪かったのだとか。

本プロジェクト対応後の媒体系システムでは上記に改修。「doda」代理店領域は「新システム」を構築し、AL-Pから分離、Wordやメール運用を極力廃止し、業務フローを簡潔化したそうです。

プロジェクトの効果について

プロジェクト実施における効果は下記の通り◎
合計で、当初年間6400万の削減を目標としていましたが、結果的に年間6,700万円の削減が達成したそうです！！

　・社内工数：削減コスト2,500万円
　・外部委託費用：削減コスト2,700万円
　・システム二重投資：1,500万円

特に社内工数に関して、法人申請件数、受注登録件数、メール起票件数は当初の目標通りの削減が実現。他の項目についても大幅にコスト削減が実現したそうです。

プロジェクト実施における難しかったポイントについて

有村さんが所属するBITAとは「Business IT Architect」の略称で、ITを活用して業務を変革させ事業貢献をすることを目的としているそうです。今回のプロジェクトも、「やれることはなんでもやる」をポリシーに、事業担当者に伴走しながら進めたそう。

プロジェクト当時、事業部内には企画部門が不在だったため、条件を決める際も誰かに聞けばわかるという状態ではなかったのだとか。また、事業部同士は完全に独立しており、連携がされておらず意思をもってすすめる人も不在な状態。ただし、今回のプロジェクトを推進するためには、二つの事業部から情報を得なければいけなかったため、事業部間の調整が大変だったそうです。

そんな中で、BITAとしてこのようなことに取り組んだそうです。

・成果物作成
　- 6ヶ月の時間をかけて要件定義・要件検討を実施

・代理店ユーザーヒアリング
　- 代理店に訪問して実施

・部署間調整
　- 事業企画における権限ルール決め、規約変更、運用調整を実施

・業務マニュアル
　- 関連部署に展開・説明会実施・問い合わせ対応

・UAT推進
　- 200ケースのUATシナリオを作成、3週間毎日つきっきりでUAT対応を実施

・事業部タスクの追いかけ
　- 毎週進捗確認＋メールでもリマインドを実施

このように、事業部間の連携がなく、情報も散在し、有識者がいない状態においても、ユーザーへのヒアリングから、マニュアルの作成、タスクの追いかけまでを実施し、無事システムをリリースすることができたそうです。リリース後も問題なく運用されているのだとか…！途方も無い作業に見えますが、大幅なリリースの遅延もなく、当初設定したKPIをほとんど達成することができているというのが素晴らしいですね◎

他の登壇者からのコメント　

大谷さん：私も実は以前インテリジェンスに在籍していて、その時に開発したミイダスが独立して会社になっています。なので、出てきたシステムや体制、dodaの皆さんすごく頑張ってらっしゃったことを見て、こうやって企画が形になっていくんだなというのをすごくいいなと思いながら聞いていました。

亀田さん：「an」の話がありましたけど、ディップでもバイトルというアルバイトの求人サイトをしており、ここにも代理店事業があります。まさに代理店事業が「an」と同じ状況でして、再構築したいなっというタイミングだったので、非常に参考になりました。

営業組織DX事例紹介（大谷 祐司／ミイダス株式会社） 

大谷さんからは、セールス組織IT導入成功のポイントをお話をしていただきました。

IT導入の難しさについて

海外の調査によると、ソフトウェアの機能の利用率は64%ぐらいにおさまるというデータがあるのだとか。大谷さんも、これまで5社で、約20以上のシステムの開発導入を担当されてきたそうですが、「作ったけど使われなかった」という失敗を多く経験されたそうです。

広告代理店では7つのシステム開発を行い、そのうち3つはほとんど利用されなくなったということも経験をしたのだとか…！そのようなご経験の中で、気づいた4つのポイントを押さえて進めるようになってからは、作ったものが着実に活用されるような仕組みづくりができるようになったそうです。

ミイダスのサービスについて

まずは、ミイダスについて。企業と転職者それぞれが、自分たちの分析を行い、その分析結果をもとに、適材適所のマッチングを行うというような転職サービス。すでに、利用企業数は17万社以上、登録者数も50万人を超えるサービスとなっています。

今回はミイダスの社内システム事例として、ミイダスの新規事業である採用代行サービスにおいて利用するWebシステムを内製開発をしたお話をうかがいました。

仕組みとしては、企業から採用依頼を受けてミイダスの採用代行チームがミイダス登録者に電話でスカウトをする、選考に進み最終的に入社をすると費用をいただく、というようなモデルなのだとか。チームは、事業責任者1名、スカウト担当8名、日程調整担当1名の少人数で構成されています。

ミイダス本体と連携して使うというこのシステムですが、2名のエンジニアで2ヶ月で開発をしたそうです！

事業成功のポイント

企業から求人をもらったとき、“応募してくれそうな方“に優先的に電話をかけて、応募率を上げるということがポイント。
応募数を増やすという目的のもと、下記2つを実行できるシステム開発に取り組みました。

・求人に対して応募確率が高い人材をリストアップ
・リストアップした人材に効率的に多くのアプローチできるようにウェブで架電をできるシステムと連携

今回は、最も重要なKPIに関わる「スカウトの改善」にフォーカスをしてシステム化を行ったそうです。ここで、大谷さんがこれまでのご経験の中から気づいた、IT導入のポイントを4つご紹介していただきます。

IT導入における4つのポイント

①業務理解を徹底的に理解する
現場から上がってくる課題に対し、それをITで解決することが正しいのかをきちんと判断するためにキーマンから業務内容を聞くだけでなく、その業務を2−3日程度自分でもやってみるようにするそうです。

現場から聞いていた課題の根本に、別の真の課題が隠れていることがよくあるのだとか…！現場の担当者は、その根本的な課題はもう自分たちで解決できない、ルールだから絶対にこれは無理、などと誤解をしているケースが非常に多いそうです。

実際に業務をすることで、業務側のメンバーと共通認識を持つことができ、より深い話をしながら、根本的な課題解決を一緒に目指すことができるようになるというポイントが◎

②できる限りコストをかけずにトライアルでやってみるということ
IT活用をするときに、未経験のことでもチャレンジをして、そのITに関するポイントを自分で体感するということも大切なポイント。

仮に、そのITを使いこなせるようにならなかったとしても、トライしたことで、用語や、できることが理解できるようになり、これを使えば課題の解決ができそうだという確信を持ってプロジェクトを始められるようになるそうです。この方法を取り入れることで、圧倒的に成功率が高いプロジェクト運営ができると考えていると大谷さんは語ります。

③システム導入を目的にしない
システムを作る事はあくまでも手段であり、最小の工数で最大の効果を出すということが大事だと考えているのだとか。

困っている人に手を差し伸べてシステムを作ったとしても、結局定量的な成果にこだわらなければ、結局根本的な課題解決できず、投資対効果が適正だと認めてもらえないと強く感じているそうです。

以前は、偉い人からの指示は「偉い人が言うんだから正しいんだ」と判断して取り組んだりもしていたそうですが、最近は一歩引いて本当に正しい選択かを考え、ロジカルに、かつ定量的により良いソリューションを提案するようにしているのだとか。投資対効果をクリアにしてより成果が出る方向に持っていくことを心がけているそうです。

④業務フローで必ずそれが使われる仕組みにするということ
作ったシステムが業務フローの中に組み込まれていなかったために定着しなかったという失敗も多くあったそう。もちろんしっかりと内容や必要性を説明し、重要性を理解してもらうことは行いますが、それに加えてこのシステムを必ず使わなければいけないというようにそもそものルールを変えるということを心がけているそうです。

例えば、Salesforceを導入した際は、もし案件が失注した場合は、必ず失注利用を記載してもらうための仕組みを導入。
理由を記載しなければその案件が失注したというステータスに変わらないという仕組みとし、意味があることをちゃんとやってもらえるようなルールに変更したそうです。

営業組織のIT導入は大変な作業ではありますが、導入したシステムがバチッとはまったときの投資対効果や事業の発展は非常に大きいもの。大谷さんからお話いただいた4つのポイントをぜひ活かして取り組んでみてください♪

他の登壇者の皆様からのコメント

有村さん：お話の中で、一つのプロジェクトを進める上で必須のツールを端的にまとめていただいていましたが、すごく重要だと思います。我々のようなシステム開発側の担当と、事業部側の認識の開きはやはりあると思います。ユーザー担当者が、結構そのシステムを導入することを目的としてしまうということは、私も実感しています。その際に、そうじゃないときちんと説明することが大事だと思います。やはり少ない工数で最大効果をしっかり目指していくことがすごく大事だなというのは、非常に共感が持てたところでした。ありがとうございました。

亀田さん：全てが共感できます。まさに僕もメンバーに話していることがそのまま書かれていまして、このまま教科書として提供したいなと思いました。同じ失敗も経験してきました。ここだけではなくもっと共有したいような内容でした！

SFA利用率99.9%を達成！ 営業になりきるコスプレUXを使おう（亀田 重幸／ディップ株式会社）

今回は営業のDXとUXデザイン観点からお話をいただきました！
亀田さんによると、「コスプレUX」は「ユーザーになりきること」なのだとか。有村さん、大谷さんからも「現場に行くことが大切」「ユーザーの課題を聞く」などのお話がありましたが、それと同じことなのだそうです。

冒頭では、最近よく聞く言葉「UXデザイン」について。実際にはどういうものなのかを改めて整理していただきました。

UXとは

デザインとは、絵などの何か美しいものというよりは、問題を解決する手段と定義されているんだとか！見た目ではなく、課題解決の考え方がデザインであると亀田さんは語ります。

DXは、ビジネス上の課題解決をし、売り上げを上げるためありますが、ここで使えるのがデザインなんだとか。

特に、人が活動する営業活動において、UXデザインは非常に重要であるそうです。
ここからはディップ社における実際の事例をご紹介いただきます。

ディップ社の事例からデザインの重要性を紐解く

現在、24期目となるディップ社ですが、CRM/SFAを導入したものの、なかなか定着しなかったのだとか。

CRMが定着しない理由ついては下記のような声が上がっていたそう。

　・顧客検索に10秒以上かかってしまい遅い
　・商談項目も多く入力が面倒
　・PC版のみで、VPNを張るのが面倒
　・入力して意味あるんですか？という疑問

ここで、UXデザインの知識を営業現場で使ってみたらうまくいくのではないかと仮説を立てて、作成したものがこちらのレコリン。

今行くべき顧客が可視化され、商談入力も簡単、入力するだけで上司に報告できるというような仕組み。このレコリンを導入することによって、目に見えて業務の工数削減が進んだのだとか。

これまでは、リストの整備やアポ獲得、商談などはExcel等を使って管理していたのだそうですが、この各工程にかかっていた時間をそれぞれ半分くらいに削減することに成功し、営業人員1人で1日1時間ぐらいのコスト削減に繋がったそうです。ディップ社には営業人員が1500人以上いるため、合計するとかなり大きいコスト削減に◎

このレコリンが1500人以上いる営業人員の99%、ほとんど全員が毎日使うシステムとなりました。

また、このシステムの中には、営業の行動データがどんどん蓄積され、数万件以上のデータが溜まっていく仕組みがあり、このシステムを作り上げるために実践したのが「コスプレUX」。

コスプレUXの実践

具体的には、有村さん、大谷さんのお話にもあったように、亀田さんも営業の現場に3−4ヶ月通いつめたそうです。亀田さんの場合は、一人の営業に完全密着し、業務を隣で見せてもらったり、一緒に営業をしたりしたのだとか...！そして、「この営業が一番楽になるツール」を作り上げたそうです。

最初はプロトタイプで作成したそうですが、それがどんどん進化していき、使ってくれる人も1人から3人、5人と増え、事業部単位で使われるようにまでなり、多くのデータが取れるようになったそうです。データの蓄積によって、営業活動のKPIを完全網羅、正確な数値と予測ができるようになったんだとか！

使いやすいプロダクトを作ることは、データを取得・蓄積を進めるだけでなく、どこにKPIのボトルネックがあるかわかるようになり、ビジネス課題の解決に繋がります。これが、UXデザインの考え方で、実際に人に寄り添っていくことが営業においても重要であるということがわかった事例となったそうです。

そもそも、データを取れなければビジネスの改善にはつながらず、データを活用しなければ営業効率化の糸口はないと亀田さんは語ります。

亀田さんは、データだけでは意味はなく、ビジネスだけでも意味がない。使いやすいプロダクトがあり、それがデータをとる、そこでUXを使う、一つ一つの概念が噛み合って初めて、DXが生まれ、新しい事業が回ると考えているそうです。

データファーストの考え方を実践するためには、まずはデータが取れる環境を整えることが大切であり、データを集めるためには、プロダクトの使いやすさが大切なのだとか。

「コスプレUX」では、特に3つのことを大切にし、実践したそうです。

①現場の声を必ず聞こう
現場に寄り添っただけではうまくいかないので、もちろん工夫は必要ですが、現場の抱える真の課題を求めるためには現場の声を拾い上げる必要があります。アンケートやインタビューを通して、下記のようなポイントを確認するのだとか。

　1.面倒に感じる業務：業務遂行に欠かせないが面倒に思う業務は何か？
　2.課題の大きさ：面倒に感じる業務が占める割合
　3.現在の解決方法：課題を解決するために現在どんな工夫をしているか？
　4.苦痛を取り除く糸口：どう解決したらいいと思うか？
　5.利用環境の確認：どのような業務システム・ツールを活用しているか？

特に心がけているのは、課題の大きさを確かめるようにしているのだそうです。本当に困っていることが何かを抽出するために、WANT課題ではなく、MUSTの課題を狙いにいくのだとか。その業務がどれだけ苦痛かを確かめるようにしているそうです。

②ユーザーの行動を分析する
現場の声を聞いた後は、行動分析を。ジャーニーマップを使うなどして、ユーザーの行動を探っていくそうです。

③課題と解決策をまとめる

亀田さんは図のようなピッチシートを作成してまとめていくそうです。
ペルソナを定義し、何に困っているか、どうやったら解決できるか仮説をまとめていきます。その際に今やっている解決方法や、新しい解決策の優れている点も一緒にまとめ、どれくらい楽になるのかをひたすら検証していくのだとか。これが「コスプレUX」だそうです。これをやっていけば、絶対に使われるシステムを作ることができるそう。1人が使えるものであれば、きっと3人、5人と使える人が増えていく可能性があります。このプロセスが、営業DXに繋がっていくそうです。

営業DXの後に起こったこと

レコリンを導入し、営業が非常に楽になり、データも取れるようになったそうですが、それだけではなく、もっと良いことがあったのだとか…！

社内にあったRPAの改善や営業DXの改善を元に、「コボット」という企業のDX支援をするサービスを新規事業として立ち上げることができたのだとか。

面接支援、人材派遣や不動産業界特化型、ホームページ作成支援など新しい事業も増えていき、社内DXの経験が新しいビジネス創出に繋がったそうです。

このような事業創出だけでなく、営業メンバーが開発にジョインした横断組織が誕生したことも。営業職のメンバーが営業をやりながら開発に関わり、自分の業務改善を推進し、営業目線で本当に使いやすいものを作っていくという部署が新設されたそうです。

まとめると、下記のポイントが重要とのこと！

　・ユーザーの使い方とデータが非常に大切
　・使われないシステムは全て無駄になってしまう
　・きちんと使われるシステムを作るためにUXデザインの視点を取り入れながら、「コスプレUX」を実践していく
　・そのためには現場に行って実践すること

みなさん、現場の声を拾い上げることは共通して重要なポイントとあげていただきました！その中でも、UXデザインの視点を取り入れることでより効率的にユーザーの行動を理解することができ、それがビジネス課題の解決から新規事業創出にまで繋がる…理想的な事例の後共有でした◎亀田さん、ありがとうございます！

他の登壇者からのコメント

有村さん：亀田さんはすごい深いところまで見ていらっしゃるんだなと思いました。皆さんの質問も出てましたけれども、営業さんにも3ヶ月密着するというのは、やっぱりなかなかできないことだと思いますし、個人の方の専用のシステムを作るっていうのもすごい行動だなと思います。営業を楽にする、といったキーワードは当社でも出るんですけども、それをやるには何をしたらいいか、ということを本当に理解されてらっしゃるんだなと感じ、感動いたしました。ありがとうございました。

大谷さん：私もすごく感動しました。本当にすごいなと思ったのは、やっぱり1人の課題を解決するというものをしっかり作って、それを広げていくっていうやり方です。本当にいいものじゃないと絶対広がらないと思いましたし、そこを1ヶ月ほどで作って、広めていくのは本当に素晴らしいなというふうに思いました。ディップさんは、すごくIT化や、テクノロジーの会社になると行ったことを推進されていて、すごい会社だというふうに思っていたのですが、内部でシステムを作ってる方も本当に素晴らしい方で、何かジェラシーを感じましたね。

『SFA利用率99.9%を達成！ 営業になりきるコスプレUXを使おう』 from Shigeyuki Kameda

www.slideshare.net

まとめ

今回のイベントでは、登壇者がお互いの発表に対してコメントをする・称賛をするという流れが素敵でした！

参加者からの声

・競合他社同士のDX状況が把握できた
・すばらしいですね！みなさん生々しいお話でこれはなかなか聞けないです！
・現状の仕事の役割として「お客様に対して営業のデジタル化」と「社内のDX化」に取り組んでいます。今日の講話内容をお聞きした上で、自身の考えや行動が大きくズレてはいないことを知れたのが良かったです。参考になる箇所もあったので、それも取り入れてアクションしていきたいと思います。ありがとうございました。
・どの登壇者の発表も、実際に色々経験されて苦労されてきた結果がにじみでていて非常に参考になりました！

続いては各登壇者の方々へのQ＆Aを紹介します。

参加者からのパーソルキャリア有村さんへのご質問

(Q)基幹システム、どんなシステム、なんの言語で構築されているのでしょうか。
(A)特定の言語というよりかは、いろいろな言語で作られてるっていうのが多いですね。

(Q)顧客情報を取り扱うって考えたら、やっぱクラウドでのシステム構築はできない感じでしょうか。
(A)実は、クラウド化は進めております。現状の先ほどの代理店様向けのシステムに関しては、データセンターの中に構築をしているのですけども、今ちょうど、クラウド化に向けて進めていこうという動きが出ております。おっしゃる通り、情報資産の扱いが難しくそこについてはかなり長い時間かけて議論が進んでいるのですが、少しずつ改修しながらクラウド化に向けて動いている段階です。

(Q)チームが異なると調整が死ぬほど面倒くさいですよね。 文化も雰囲気もちがう人達の間に立つうえでどんなふうに立ち回ったほうがいいとかありますか？
(A)当社パーソルキャリアで、掲げる価値基準が3つあり、外向きの視点を持つこと、自分ごと化していくこと、成長マインド持つことの3つを大事にしています。今回も、本当に面倒くさかったこともたくさんあったのですが、最終的には使っていただくユーザーの将来像を想像しながら、課題を自分事化し、自分がもし代理店の営業さんとして活動するときにこういうのがあったら楽になるだろうな、などと想像しながら、真摯に向き合ったというのがまず一つですね。また、少し精神論になってしまいますが、諦めない心を持って、一つ一つしっかりビジネスプロセスを作り、わからないところは、一つ一つしっかり細かく規定する、といったことを行なっていくのが地味ではありますが重要かなと思います。

(Q)なにからなにまで行われていたとの事、「正直やってられない！」など思う瞬間はありましたか？また、その時にどのようなセルフコントロールをされて乗越えましたか？
(A)セルフコントロールはすごく大事だと思っています。正直、今回のプロジェクトは2人で進めていたのですが、時間的にも業務的にも余裕もなかったので少し険悪になってしまったこともありました。そんな時も、例えば、その言葉尻の強さを意識するのではなく、相手が本当に伝えたいことは何なのかを、ちょっと落ち着いて考えてみたりするなどを行なっていました。あとは、ストレスをなるべく次の日に持ち越さないという意味で、その日のうちに解消するということも意識して行なっております。

参加者からミイダス大谷さんへの質問

 (Q)VPoE、はじめて聞きました。どのような役割なのですか？
(A)組織作りだったり、マネジメントだったりをエンジニア組織に対して行う役割になります。

(Q)営業さんに活用されているか、そうでないかの判断は主にどんな指標をみていますか？
(A)自前のシステムとパッケージシステムで違うのですが、自前でシステムを作ったときにはそのログを見ることもありますしログイン率を見ることもあります。全部の業績に対してシステムを経由して、データも見るようにしています。Salesforceのときは細かくチェックをしていました。失注理由、受注理由などもレポートを出して全部見ていましたね。アルファベットAとかだけ書いてあったら絶望したり（笑）

(Q)スカウトをITで改善するポイントはMiitel導入、分析等以外にありますか？ メールの改善も知りたいです！
(A)スカウトは電話中心なので、それこそトークや時間帯、どの電話番号からかければいいか、どんな人にどんな求人をご紹介すればいいのか、こういうときには1回アポを取ってもう1回かけたほうがいい、などのデータを収集していました。特に、録音データが見られるようになってからは、どういうふうにお話をすれば、いい形で案件の魅力を伝えられるかという点が改善してきているように思います。

(Q)「真の課題の発掘」が重要だと理解しましたが、実際にどの程度の割合で真の課題が出てきましたか？ざっくりで結構です。また、実際に業務をしてみる以外にもヒントになるアクションがあれば教えてください。
(A)オーダーの半分ぐらいは手段をお願いしてくる感じはします。解決したい課題ではなくて手段、例えばメーラーにこんなテンプレートの仕組みを導入したいです、など。よく聞いてみると、メーラーに何かを入れればいいわけではなくて、そもそもその前提として、それは、素早くメールを返すよりも、1回自動的返信しておいて後から返せばいいのではないかとか、そういった解決方法の方が増えてきたりとかそういったことはしょっちゅうありますね。同じような業務をしている情報だったりとか、類似企業の人を見つけて話を聞くみたいなことはすごく参考になります。

(Q)業務工数算出において、やりやすい方法や効果的に見せる方法があれば教えてください。
(A)%で見せるのがやはり大切です。

(Q)ITの施策をやる際にやる意義（必要性？）をしっかり説明することが大事になってきますが、「根本は変えられないという誤認」を変えていく簡単な方法を教えてください！
(A)例えば、中期経営計画何する達成するための重要なアクションKPI数字は何で、だからこそこれをこうしなきゃいけないところを理解をした上で、今の優先度は本当に正しいのか、という話はよくします。そういう意思決定の最も上のところをしっかり把握をし、現場の組織をしっかり理解した上でコミュニケーションとるっていうことですかね。

(Q)コスト削減は算出しやすいですが、例えば、接触率の改善から売上金額の効果試算をする場合はどのようにやっていますか？
(A)仮説を作ってデータサイエンティストにそれをお願いしています。例えば、よく話してたりするのが応募率や企業の契約継続率にどうインパクトあるかなど、サイトをどう使ってるかがどう業績にマッチするかといった話です。ある程度、こちらで仮説を作り、データサイエンティストにその仮説検証をお願いしています。

参加者からディップ亀田さんへの質問

(Q)UXデザインに着目したのはたまたま亀田さんがUXな人だったからですか？それともこの界隈で注目度上がってきてますか？
(A)実際、新規事業で失敗しまくった経験があり、使われるシステムをどうしたらいいのかなとひたすら考えたときにこのUXデザインという言葉について調べたっていうのがきっかけです。

(Q)ディップさん、先進的なイメージ！「ディップのここがすごいよ」「ディップ自慢」を教えてください。
(A)最近はテック企業っぽくなってきましたね。レコリンのようなシステムをみんな使っているので、新しいシステムをみんながどんどん使っていきたいという気持ちが高まってきているように感じます。

(Q)社内、自転車移動？！そんな広いオフィスなのですか？
(A)オフィスは普通のオフィスです。（笑）資料にあった自転車は営業用の自転車です。

(Q)密着している間、自部署の理解が得られていたのがすごいですね ディップさんの営業部隊は快く受け入れてくれる文化なのでしょうか。
(A)当時はそうでもありませんでした。レコリンを使う前は何か怪しい人って感じでしたね。なので、不思議に思う人、興味ある人、嫌だなと思った人がいると思います。やっぱりシステムの人がきて何するの、っていう疑問や期待があったと思います。普通はシステムの人は現場に来ないので、現場の人もあまり期待は大きくなかったと思います。

(Q)聞き逃しちゃったかもですが、密着していた営業マン専用のシステムってどのくらいの期間と人員で開発したんですか？
(A)本当にペーパープロトタイプ作りながらやったので、これ自体は多分1ヶ月間ぐらいで本当に簡単なシステム作りをしました。

(Q)営業メンバーが開発にジョイン！！！？ 希望者を募ったのでしょうか？営業とその他でどのくらいの割合なんですか？ もともと営業も開発知識がないとNG？
(A)レコリンを使っている営業担当の中から、改善案をどんどん出してくれる人を選びました。開発知識はゼロで、とにかく営業をもっと楽にしたい、業務改善をしたいという思いを持った人を選びましたね。

(Q)外部のお客様に対する営業のデジタル化に取り組んでいるのですが、社内のように誰かに張り付くということが難しいと思います。お客様を巻き込む場合のデータの取り方や成功するためのコツがあれば、教えてください。
(A)クライアントワークとなると、その社員の方にうまく動いてもらうようにするのがいいのかなと思いますね。声が見える形で情報が取れ、営業の信頼が得られるかどうかやっぱ大事だと思います。いいシステムを作っても営業が信頼してくれないと、使ってもらえないのでうまく顔が見える状態でコミュニケーションをとっていくのが大事だと思います。

(Q)現在、UXやデザイン思考を勉強しているのですが、参考になる本やサイト、セミナーなどを教えてください。
(A)今日のお話は『アフターデジタル オフラインのない時代に生き残るー藤井 保文 (著)』に同じようなことが書かれていて、参考になると思います。デザイン思考については、本はまだ少ないですが、Amazonで検索してデザイン思考やUXとつく本を一つ一つ全部読みました。時間はかかるんですが、それがいちばん早いと思います。

(Q)営業担当者にとってはデータを記録することは主たる業務ではないという側面があると思いますが、記録を促進するためにどのようなことが必要でしょうか？企画部門からのとりくみだとうまくいかないのでは、、と思っており、営業担当者にとってのメリットが難しいと思うのですが。
(A)これも実は工夫したポイントの一つで、僕らの意見に対してデータを入れてくれということは一言も言わなかったです。もちろんデータが増えた後に、レポートがすぐ配信されるなどの仕組みも取り入れていましたが、正直レポートは見ないので、それよりも顧客を探しやすくするという仕組みを工夫しました。いかに顧客を探しやすくするかを工夫することで、「このサービス使える」「顧客を探すならこれを使ったら便利」という風に思ってもらうことで、じゃあデータも入れようかという風に繋がって行ったと思います。

(Q)PJTの成功において、最も重要だと感じたことはなんでしょうか。
(A)対象となるユーザーを詳しく知ること、その人の仕事をマネできるくらい勉強する、何が1番苦痛なのか探る、解消されたらどのくらい嬉しいのか自分ごとにして考えるこの4点だと思います。

(Q)右も左もDXってワードがあふれてますね。ってことで、営業活動から実現できるDXって何かありますでしょうか？
(A)
有村さん：何を変えていくかっていうところになると思いますが、最終的には営業活動ってお客様を通して行ってるところになると思います。例えば僕らで言うと、最終的には求人があり、そこに対しての採用がその成功して、すごくいい形での採用成功体験を行ったのが提供すること、そこにどんどんフォーカスしていくことで、よりお客様と一体になっていくことが実現できていくんだろうなと思います。

大谷さん：世間一般のイメージだと、営業組織はDXと遠いと言われがちですが、営業組織こそ、DXを知ってる人間が、何か難しいプロセスを通さずにサクッと作れちゃうような状態になってくると、たくさんのすごくいろんなところでDXが生まれるんじゃないかなと思っています。そのためには、もしこのイベントを聞いてる営業の方がいらっしゃったら、無料で学べるITツールはたくさんあるので、ぜひ使ってみるのはといいんじゃないかと思います。

亀田さん：やはり先ほどお二方がありましたが、やはり課題解決をしてお金を儲けていくという形になっているかと思うのですが、営業活動って一番お客様と接してお客様から課題をきく仕事だと思います。なので、一番DXに入口になる職種だと思っています。営業活動がなければ、課題にも気付けない。一番大事な営業活動やっていけばDXはどんどん自然と生まれてくると思います。

イベントレポートは以上となります！
ご登壇してくださったお三方、ご参加いただきました皆さんありがとうございました◎
次回のレポートもお楽しみに♪