BAMV合同会社

アジャイルソフトウェア開発宣言が2001なので、もう20年くらい経ってる訳ですが・・・。

導入が進まない背景としてよく、日本企業の決済フローの遅さや評価の減点主義からくるリスク回避傾向などがあげられますが、もっとわかりやすく目先の問題が２つあります。　


【ひとつめ】
スクラムの『プロダクトオーナー』は、非常に高いスキルを要求されます。しかしながら、アジャイル導入の進まない日本ではPOの経験者も少ない訳で。ましてやITでメシを食ってる訳ではないエンドユーザーがそんな高額な人材を雇用し得るでしょうか？　さらには解雇制限もあり、本来は必要な時のみピンポイントで雇用したいはずの『高度な専門性を持った人材』を高額で雇用する事が難しいという問題もあります。

POは業務側の知識に詳しく、その組織の背景を理解し、必要な調整を行うことができるので、バックログの優先順位を決めて行く事ができ、それを技術側であるスクラムチームに伝達していく能力を要求されます。できたらかなりのバケモノなお客様です。
出来なければ、業務側の要求の通りに『必要な時期までに全部作る』こととなる為、ウォーターフォールで作った方がマシだったという結果になりがちです。

このケースはとても多発します。その為か、国内の（ちゃんとしたい）アジャイルプロジェクトでは、開発チームのエンジニアのスキル要求がとても高いものになったりします。


【ふたつめ】
日本の多くのエンジニア・開発ベンダーがアジャイルにフィットしないという問題もあります。

高効率な分業は個のエンジニアの役割の明確化を。それに加え一括請負契約も守備範囲の限定を加速させます。分業はさらに『階層』を産み、技術者からプロジェクトに対する当事者意識を奪います。その上、階層は顧客に対して成果を明らかにする事や成果に責任を持つことを阻害します。さらにはここ数年のエンジニアバブルは『園児ニア様』なる新種も生み出しましたが、これもまったくアジャイルには適合しません。

これらの環境に適合したプログラマーは、スキル有無の以前に、マインドセットがアジャイル向きではない訳です。

※当事者意識を持ち、リスクと向き合い、成果を明らかにし責任をもつ、役割責任範囲を限定しない。どちらかと言うとリーダークラスのエンジニアには多く見られる特徴。リーダー格をいちメンバーでアサインするかと言えば、しないわなー。


【どうすんの】
どうすんのって、これもうビジネスチャンスの類でしょうよ。
採用と育成が強みであった会社【Trash-Briefing】は、【BAMV】と名前を変え、その育成したメンバー達と共に次の段階へ進むのです。

詳しくは・・・。つづく。（したのほうにある）

つづき。

アジャイルに適応できるエンジニアがそこそこ育ってきた以上、もはや他社は容易には追撃できない（すこし人種が違う）ので、オープンで言っちゃってもよかろうかなー。

【まず、市場構造。】
日本には解雇制限があり、エンドは安易に開発部隊を抱える事はできない。なので、SIerや派遣会社が必要になります。

《SIer》一括請負契約でエンドの代わりにリスクまでも引き受け、大規模システム開発を代行してくれる
《派遣会社》自社社員を投入しづらい『永続的ではない業務』に対し【解雇できる社員】としての派遣社員を貸してくれる

Sierはさらに効率化をすすめ、専門性が高い上流工程や切り離せないかつ利益率の高い保守工程。そしてマネジメントに特化。中流工程をアウトソース。こうして階層構造ができる訳ですが、この階層構造自体、【解雇制限から生じたエンドのシステム導入代替ニーズに最適化されたエコシステム】と言えるでしょう。


【SIerを競合として見てみる。】
強力なマネジメント能力と上流（特に大規模エンドの業務に強い）、巨大な資本力と社員数、既存の大手エンドから得ている信頼。そして、大規模システム開発を支えるピラミッド型業界構造と言うエコシステム。このような背景を持ったとても強力な存在です。SIerがいろいろ言われる事もありますが、実はビジネスモデルとしてはすでに完成系に近いのではないかと思います。ここ数年のエンジニアバブルの期間においても、彼らはスタンスを大きく変化させることなく最高益更新とかしていましたし。
こと、大規模エンドの大規模システム開発ニーズに対しては、後発の我々が戦いを挑んで勝てる確率はほとんどないんじゃないでしょうかね。

つまり、昔ながらのソフトハウスのスタンス《自分達もSIerになる事をめざす》では、我々は生き延びる事は難しいという事になります。《SIerを目指す》という事は、《SIerの領域でSIerを競合する》ことにほかならないのですから。


【我々がとるべきポジションとは？】
SIerとの競合を避けるには、彼らが追わない領域をターゲットとするのがベストです。競合しようがありません。SIerは上記に挙げた強みを活かしたビジネスを選択する訳ですし、また《ウォーターフォール型開発》に縛られるという制限もあります。

《ウォーターフォールに縛られる》
IT業界のエコシステムは、ビジネスプロセスの一部をアウトソースする事で成り立っている。これは《分業》の一種とも言え、工程ごとに分業する事が可能なウォータフォールモデルとの相性が特に良いです。SIerがアジャイル型の手法を実施不能と言う話ではなく、ウォータフォールモデルの方が経済性が高い訳ですね。ここ20年でアジャイル型の手法が普及していかない背景としては、解雇制限から発した現在のエコシステムとアジャイル型手法の不適合、そしてその不適合を乗り越えるほどのリターンが無いからであると考えています。


【と言う訳で】
・アジャイル型の方がニーズを解消しやすい。
・小～中規模の開発規模である。
・市場規模が大きすぎない。（例えば銀行の基幹業務とかは、大きすぎる）

我々は、このような条件を満たすビジネスを選択。自分達で行っていけばよい訳です。SIerはもちろん、その他多くのソフトハウスも、重厚長大なシステム開発に特化する育成手法を取りますし、それ以外の会社も《ナンチャッテアジャイル》で満足してたりするので、競合や追撃者は極めて少なく、多くのチャンスが予想できます。（むしろ競合と組めるレベル）

さらにつづく。（もっとしたのほうにある）

【スクラム導入期の問題】
さて、現実にスクラムを導入したときに起きる問題ですが、初めにお伝えした、『エンドユーザー側の人間であるプロダクトオーナーへの要求スキルが高すぎる』と言う物がありました。日本ではほとんどマトモなアジャイルプロジェクトはありませんし（多くは単なる超小規模ウォーターフォールをJiraで管理してるとかそういうの）前述の解雇制限もあるなかでエンド側が歴戦のプロダクトオーナーを雇用して用意するのはとても難しいことです。

多くの場合、PO周りの機能不全により、『すべての機能が優先度高。かつ決まった時期までに』開発するようなバックログになりがちです。この場合アジャイルのキモである、≪作らない≫ができない為、作業量が多くなり、開発チームは高い製造能力を要求されます。（本当は、チームやスクラムマスターもPOを支援しなくてはいけないのだが、SMはPOと同じく機会不足による経験不足。チームメンバーに至ってはスキル以前にマインドセット不適合で、守備範囲を限定したがる有様。　とかがよく見られる。）これが、和ジャイル案件への参画ハードルが高くなる要因と考えています。


【プロダクトオーナ補佐】
業務側のニーズやその背景の吸い上げ、ＰＯ間との情報流通の確保。
開発側との技術的な要素を加味した優先度調整や通訳。情報流通の確保。
ＰＯ側に立ち、ＳＭの支援を機能させ、開発の目的を達成させるポジションです。

アジャイルマインドを持ったチームだけではなく、このＰＯ補佐も弊社で育成。弊社1社に発注すれば、エンドユーザーの内製化の支援が実現できる状態に持って行きます。（このほか、エンドの採用・育成等の支援も可能になる。）このスキルセットは、エンド側に常駐するPMOやコンサルタントに非常に近しいものであろうと考えております。このニーズを解消する為、弊社でもコンサルティングセクションがスタートする事になりました。



【そこから派生する展開】
なにしろ、このＰＯ補佐は（その他の案件ではＩＴコンサルやＰＭＯとして）エンドの業務側のニーズや背景を、エンド内に常駐して、直接把握してくるわけです。アジャイル向きの開発ニーズのほか、ウォーターフォール向きのものや、エンドと組んでサービス開発等のニーズを獲得する事が出来ます。この段階に達すれば、弊社も多角化を行っていくフェーズへ移行していくものと思われます。

現段階では絵に描いた餅にすぎませんが、段階を踏んでいくためにも、ＰＭＯは《汎用機以外のプロジェクトやエンド側の経験》を。エンジニアは《自分達で自律したアジャイルチームを編成する》経験や実績をため込んでおくべきでしょう。


【その他発生した特性】
・PMはコンサルセクションのメンバーのキャリアパスの分岐の一つになった。（SEはPMにはならない）
・ビジネス色の強いコンサルセクションのメンバーと、エンジニアに接点が生まれた。
・エンジニア一本鎗のケースとは違った取引先が発生。（コンサルティングファームなど）
・自社の組織改善などに、PMOが活躍。（本職やし）

などなど。他社にはない特性が生えてきました。


このように、戦略や育成、重視するマインドなどにかなり特徴が出てきております。ご応募の際は、ぜひ本ページの内容をご理解頂き、自身とのカルチャーマッチ面を重視して頂けますと幸いです。採用時にもこの点を重視して選考しております。（逆に、開発スキルはあとから付けられるものでしかない為、採用時には基礎力を重視します。）