システム開発発注時にベンダー（SIer）にぼったくられない為のコンサルティングサービス

できること

こちらのサービスは、以下のような方を想定しています。

主に経営者や起業家の方で新しいサービスやプロダクト開発にシステム開発が必要な方

部長などの責任者でシステム開発プロジェクトをベンダーに発注する立場にある方

既に発注しているが炎上して困っている方

新しいサービスやプロダクトの開発を考えている経営者
システム開発が必要な起業家
システム開発プロジェクトをベンダーに発注する立場にある部長
プロジェクト管理にお困りの責任者
炎上プロジェクトの対処法を知りたい方
ベンダーコントロールの方法を学びたい方
効果的なプロジェクト進行を実現したい方
現在進行中のプロジェクトがスムーズでない方
コスト削減を図りたい経営者
時間とリソースを効率的に使いたいプロジェクトマネージャー
プロジェクトの成功事例を知りたい方
他社との競争に勝つための戦略を学びたい経営者
新しい技術を取り入れたいプロジェクトマネージャー
プロジェクトチームをうまくまとめたいリーダー
開発チームとのコミュニケーションを改善したい方

実績や強み

大規模ウォーターフォール案件からスクラムフレームワークを用いたアジャイル開発まで様々なプロジェクトを経験してきました。
ウォーターフォール開発PJTではPM、PMO、上流設計、ITコンサルタント、アジャイル開発PJTではプロダクトオーナー、スクラムマスター、RedHatのアジャイルコーチ等様々なロールを経験しております。
受注が欲しい受託開発会社目線の営業トークではなく、発注者様側のCTOとして一番コストが掛からない方法をお伝えできます。

このプランで提供できるサービスの概要

Facebookメッセンジャー、LINE、Slackにてチャットでいつでも相談にのります。
Slack及びGoogle meetを利用した1on1のビデオ会議

特徴

基本的に日本にあるシステム開発会社はほとんどが請負契約の受託開発会社です。そして大手になればなるほど社内にエンジニアがおらず、設計だけして下請けに投げる多重孫請構造が社会問題となっています。この問題は根深く、低賃金のエンジニアを生み出し日本のGDPが30年間横ばいになっている大きな原因だと私は思っております。この問題を解決するには発注者様自身が正しいITリテラシーを身に着けるしかありません。このプログラムでは現在の問題の背景や業界の産業構造、ベンダー側も発注者側もどちらも経験したことがある開発のプロの目線から一番コストの安い戦略をお伝えし、一緒に企業の経営戦略を考えます。

自己紹介

初めまして。株式会社アジャイルテクノロジー創業者の中井一機と申します。昭和62年生まれで現在35歳になります。
リクルート、日本マイクロソフト、NTTDATA等の会社にて経験を積んだ後、2019年に個人事業主として独立。
それからはプロジェクトマネージャー、スクラムマスター、プロダクトオーナー、アジャイルコーチとして数々のシステム開発プロジェクトに参画し、昨年7月に法人成りしました。

様々なシステム開発プロジェクトに参画する中で日本の産業構造に危機感を感じたのが創業のきっかけです。世界では2000年代初頭からアジャイル開発が当たり前になる中、日本は未だにベンダーに開発を丸投げしております。アジャイル開発とはトヨタのカンバン方式をルーツにした、振り返りと改善に主軸を置いたエンジニアのマネジメント手法です。ウォーターフォール型開発とは全く逆のアプローチで、最初に全体像の設計をせずに優先度の高い機能から小さく開発をし、できたら順番にリリースをします。

変化に強く、無駄なものを作らない事や、テストやデプロイ等人がやらなくても良い作業は徹底して自動化する事で、コスト減、工数減、人員減できます。ウォーターフォール開発に比べて明らかにアジャイル開発の方が全てのパフォーマンスが高い為、世界ではアジャイル開発が当たり前になっています。

しかし、日本ではアメリカの様に雇用主都合で正社員を簡単にレイオフできない雇用法の問題や、発注者（サラリーマン社長）のITリテラシーの低さ、及びITの重要性を本質で理解していない事が原因の根幹です。

私も以前大手ITベンダーにいましたが、彼らは自社にエンジニアを雇っておらず発注を受けても設計だけして下請けに丸投げします。またその下請けも孫請けに丸投げします。これが現在問題視されているIT業界における多重孫請構造です。

多重孫請構造とウォーターフォール型開発の問題点は沢山ありますが、
1.実際に作業するエンジニアの給与が少なくなる→スキルの低い人員で実装する為バグが多かったりUIがイケてないなど使い勝手が悪くなる。
2.沢山の仲介者が入る事でコミュニケーションコストがかかる→最終的に発注者が支払う事になります。
3.スピードが遅く変化にも対応できない→なにか致命的な欠陥が見つかっても手戻りができない為デスマーチで乗り切ろうとする。セブンイレブンのセブンペイが炎上した件もまさにこれです。

この課題を解決するには、発注者である企業の経営陣にITやシステム開発の正しい知識を啓蒙し、まず発注者のITリテラシーを上げないといけません。そもそもITは経営の根幹です。その経営の根幹を他社に丸投げしていて良い訳がありません。現在はそんな発注者とベンダーの高額裁判（直近だとZ会 vs 日立子会社、野村證券 vs IBM　等）も増えてきました。