エンド企業とSlerの関わり方：システム開発の内製化のポイント@ANGEL Dojo

#目次
[1.はじめに](#1-はじめに)
[2.全体スケジュール](#2-全体スケジュール)
[3.ワークショップの内容-エンドユーザーとSIの関わり方-](#3-ワークショップの内容)
[4.キックオフを終えてみて](#4-キックオフを終えてみて)

#1-はじめに
###ANGEL Dojoって何？
>ANGEL Dojoでは次世代を担うAPNの若手のエンジニアの方々に、擬似プロジェクトを通じてアジャイル、DevOps、モダンなアプリケーション開発などのクラウドネイティブな手法と、様々なInnovationを作ってきたAmazonの文化と考え方を体験いただくことで、お客様にクラウドの価値を100%届けるための基礎的なスキルを実践を通して身につけていただきます。参加者の皆様はここで培ったスキルと、各パートナーの皆様がお持ちのそれぞれの強みを活かすことでお客様のビジネスを成功に導き、日本のITや経済をさらに成長させる主役、すなわち「APN Next Generation Engineer Leader」になっていただきます。
>（[ 「日本を元気にする」APN Next Generation Engineer Leaders(ANGEL) Dojo のご紹介](https://aws.amazon.com/jp/blogs/psa/apn-next-generation-engineer-leadersangel-dojo)　）より


簡潔に言うと__「AWSを使い、3か月間、少人数のチームで企画から実装までを体験する疑似プロジェクト」__になります。
同じ企業内の5名が1チームとなり、様々な講義やトレーニングを受け、企画開発、実装へと進んでいきます。
参加条件については、IT経験が1～3年目であることなど、幾つかあるので、気になる方は上記リンクで確認してみて下さい。

余談ですが、キックオフの説明で「ANGEL Dojo」はいろんなチャレンジができる場です。」というのがとても印象に残っていて、
私自身、インフラメインの業務に携わっていたので、フロント側など、普段業務では経験できないことをやってみようと思いました。

#2-全体スケジュール
ANGEL Dojoの全体スケジュールとしては以下の2つに分かれています
　__1 : 企画フェーズ__　
　　　6/3~6/25
　__2 : 設計・開発フェーズ__ 
　　　7/1~7/30(中間発表) 8/5~9/3(最終発表)

それぞれ詳細に説明すると、
###1:企画フェーズ
　ゴール：__企画書の作成__
　期間：6/3~6/25
　ここでは、Amazonの文化の1つでもある__「Working Backwards(お客様から考える)」__の手法をもとに、
　疑似プロジェクトで開発するサービスコンセプトを決定します。
>__「Working Backwards」の考え方__
>　1. お客様は誰ですか ?
>　2. お客様が抱える課題や改善点は明確ですか ?
>　3. お客様が受けるメリットは明確ですか ?
>　4. お客様のニーズやウォンツをどのように知りましたか ?
>　5. お客様の体験が描けていますか ?

###2:設計・開発フェーズ
　ゴール：__設計及び開発の完了__
　期間：7/1~9/3
　プレスリリース及び、FAQから実際に設計及び開発を行っていきます。

##1週間のスケジュール
　__毎週金曜日を1日ワークDay__とし、プロジェクトを進めていきます。
　その他月曜日から水曜日までは通常業務を行っています。
　　→　講義やワークショップもある為、毎週1日～2日がプロジェクトに充てる時間になります
　　→　場合によってはその他の時間でタスク管理や進捗確認を行います

　また、__週に2回程度、講義やワークショップ__が実施されます。（必須参加or任意参加）
　　例)エンドユーザーとSIの関わり方、Working BackWordsの考え方　など
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1595780/f4bb555a-b144-fa50-8cb7-01fc31d60ff4.png)
※上記はある週のスケジュール
##メンバー体制
###＜AWSからの支援体制＞
　・各チームにAWSジャパン のSolution Architect1名がメンターとしてサポート
　・AWSの様々なトレーニングを提供(講義やワークショップ)
　・疑似プロジェクトで用いるAWSリソースに対する$1000のAWSクレジット
　→　技術的な不安や、プロジェクトを進めるにあたって、AWSの方々に相談しやすい環境になっています
###＜参加企業のメンバー体制＞
　・1年目から3年目の若手社員5名 + 社内メンター(サポート役)1人　の計6名で参加
　→　各メンバーのバックグラウンドは自動化やフロントメインに携わってきた方、インフラに関わってきた方などそれぞれです。

若手が集まったチームということもあり、MTGでも気兼ねなくそれぞれが発言できていました

#3-ワークショップの内容
今回は、初回ワークショップで行われた__「エンドユーザーとSIの関わり方」__について簡単に紹介できればと思います。
このワークショップでは__「内製化」__をキーワードに__ユーザー企業の抱える課題、パートナー企業が可能な支援方法__をディスカッションしました。
###1.内製化の背景
説明する前に、内製化がなぜ求められているのか、簡単に説明したいと思います。
昨今、コロナ禍で様々な環境が変化していく中で、ぽっと出のビジネスモデルが急激に求められたり、従来のビジネスモデルが急激に衰退したりと、良くも悪くもビジネススピードの高速化が顕著に表れています。

そこで企業に求められるのが、__「素早いシステム開発」__です。

従来、多くのユーザー企業はシステム開発をする際、開発のほとんどをSIに委託するシステムでした。
しかし、このようなスタイルでは、企業間の距離や、SIのビジネスとの距離が遠い、などシステム開発までの時間がかかります。そこで注目されたのが「内製化」です。

そもそも__「内製化」__とは...
####__ITシステムの内製化とは「ITシステムの根幹の開発を自社内で行う」ことを指します。__
>ITシステムの内製化とは「ITシステムの根幹の開発を自社内で行う」ことを指します。
>?ITがビジネスの場に登場してから四半世紀ほどの間、日本企業の多くは自社システムの開発をSIer(システムインテグレーター)に外注していまし>た。資金的余裕もなく、IT人材を自社内で育成することもできない日本企業は、人材外注先の企業とのやり取りを繰り返しながら、自社システム>の改善を続けてきたのです。
>しかし、それではデータ活用などを見越して社内にIT人材を囲い込んでいる海外企業との競争には勝つことが出来ない、イノベーションが生まれ>ないなどの弊害が出てきたため、そのデメリットに気が付いた日本企業が、少しずつITシステムを内製化する動きに転換し始めているのです。
([ITシステムの内製（インハウス）化とは](https://www.internetacademy.co.jp/trends/it-strategy/it-system-selfmanufacture.html#:~:text=IT%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E5%86%85%E8%A3%BD%E5%8C%96%E3%81%A8%E3%81%AF%E3%80%8CIT%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0,%E8%A1%8C%E3%81%86%E3%80%8D%E3%81%93%E3%81%A8%E3%82%92%E6%8C%87%E3%81%97%E3%81%BE%E3%81%99%E3%80%82&text=%E8%B3%87%E9%87%91%E7%9A%84%E4%BD%99%E8%A3%95%E3%82%82%E3%81%AA%E3%81%8F,%E7%B6%9A%E3%81%91%E3%81%A6%E3%81%8D%E3%81%9F%E3%81%AE%E3%81%A7%E3%81%99%E3%80%82))より

###2.現在のユーザー企業の内製化状況
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1595780/5f3cc4ca-350d-2518-3aa1-859d55f807c6.png)
参考資料2018年：(https://www.i-learning.jp/service/dbiz/topics/dbiz_itt10.html)
ユーザー企業の内製化状況としては、全体の50%が内製化を進めているという状況
　→　上流工程から下流工程の内、企画・設計などの上流の内製化を進めている企業が多い

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1595780/94aa2bcc-5a32-2f7b-4971-7a89947324af.png)
参考資料:(https://mynavi-agent.jp/it/geekroid/2021/03/post-330.html)
ユーザー企業のIT人材の”質”に関する調査では、上流、下流含め大幅に不足しているといった状況

###3.内製化のポイント
ここでは、内製化が上手くいった事例について、大切なポイントを3つほど、紹介します。

####1.壁のないコミュニケーション（相互理解）
　内製化が行われていない場合、システムを開発する上では様々な壁があります
　　例えばユーザー企業とSIの壁、開発と運用の壁、営業側とIT部門の壁など

　スムーズに内製化が進んだ事例では、ユーザー企業、Slが同一の場所で開発、運用を行っていました
　その為、スピーディに意志決定、情報の連携が行えることが、内製化では大切です
####2.教育コストを加味した計画
　ユーザー企業側は上流工程に対し強みがあるが、下流工程に関して深く理解していないことがあります
　　例えば、開発やテストにかかる工数など

　この課題を解決するためには、ユーザー企業側はSIに対し、SIはユーザー企業側に対し、相互理解を深めることが大切です
　お互いの文化等を理解した上で計画することが、内製化を上手く進めるためのポイントになります

####3.進め方に対する意思決定権を持つ人の理解
　意思決定権を持つ人が内製化に対し、柔軟に理解していること
　ユーザー企業側の意思決定者が現場(ユーザー企業、SI）に対し、理解が深められていないと、ここにも壁が生じます

　その為、意思決定者が柔軟に判断し、理解することがスムーズに内製化を進めるうえでの鍵になります
　
#4-キックオフを終えてみて
ここからは私がキックオフ、初回ワークショップを終えてみての感想です。
参加する前は「3か月で企画から開発、、大変そう」というのが率直な意見でした。

初日を終えてみて、1つ貴重な経験をしたなと思ったのが、普段はあまり聞くことが出来ない「ユーザー企業」の生の声が聞けた事です。
普段はシステムの開発に注力している為、ユーザーの声というものはあまり実感する機会がありませんでした。
ただ、今回のワークショップで実際にどのような部分にユーザー企業は不安を感じるのか、ユーザー企業側の課題を知ることで、
今後のシステム開発へのアプローチの方法も考える余地があるなと感じました。

それと単純に面白く、楽しかったです。(まだ初日ですが...)

これから企画、開発と進んでいきますが、"Learn and Be Curious"をスローガンに挑戦をしてこれからも頑張っていきます。