  |
はてなキーワード: ステイクホルダーとは
努力不足でSESにしか行けなかったというツイートが話題になっていますね。
件の人に限らず、スクール卒業者が就職できないやら、採用したけど使えなかったとかという話をよく聞くので、そんな悲しいミスマッチを減らし、この業界を目指す人が希望と勝算をもってチャレンジできるようになることを願って思っていることを書いてみようと思いました。
業界に入って十数年、メガベンチャーで働きGAFAの関連企業から1X00万円のオファーを貰うくらいのスキルと経験はある。もちろん開発のスペシャリストとして。
新宿の雑居ビルにオフィスのある中国人が経営するSES会社からキャリアをスタート。最初の会社は雇用保険も払ってなかった。
新卒または第二新卒、文系または数学が苦手、プログラミング未経験者でスクールやサロンに入ってプログラミングを身につけて働きたいと思ってるひと。
理系やプログラミング得意な人は、学生ならインターン、働いてる人はなんでも良いからスクリプトで業務改善すれば実務経験になり、そこからならどうとでもなるのでこの記事は参考にする必要なし。
ふたこぶラクダ理論というものがあります。(https://ameblo.jp/bradnine/entry-11911830387.html)
要約すると、出来る人と出来ない人がいて、何が要因なのかわかっていないし、出来ない人への教え方も確立していないとのことです。
学び始めてすぐに判断を下す必要はないですが、スクールのカリキュラムを終える頃には周りとの成長スピードの差で自然に理解できるかと思います。
しかし、もし適正がなかったとしても悲観するのはまだ早いです。
プラグラミングの適性がない人にもこの業界にはポジションがある。QA、PdM、PjM、UIデザイナー、UXデザイナー、カスタマーサクセス、営業、採用、などなどいろいろあります。
なにはともあれ3割くらいは可能性があって外れても選択肢があるんですからポジティブに受け止めましょう。
エンジニアの生産性の差は10倍や100倍にもなると言う話は聞いたこことがあるかと思います、底辺と天才を比べた極端な話だと思いますよね？実はこれありふれた話です。超有名ベンチャーで難しい採用試験を潜り抜けて即戦力採用された人たちの中でも100倍の差があることもあります。それも瞬間風速的な話ではなく、年間の変更コード行数を計測してそうなります。10倍の差はもっとありふれた話です。
さてここまではプラス面だけの話ですが、マイナス面も考える必要があります。
あなたが無事現場に入ってわからないことを教えてもらう必要があるとします。面倒見のいい先輩がなんでも聞いて良いよと言ってくれたので、質問をして、3時間先輩の時間を使ってしまいました。先輩は100倍エンジニアだったとすると、その3時間であなたの二ヶ月分の作業量が消し飛んだ計算になります。あなたはそれに見合った成長をして恩返しできますか？
ちなみにそれくらい能力差があっても給与はあまりかわりません。良くて倍くらい。同じ給与ってこともまぁよくある話で、多重下請の現場では逆転してることも珍しくはありません。
そろそろ本題に近づいてきました。
ここまでの話を踏まえてどうするべきだと思いますか？
特別なことでも難しいことでもなく、いたってシンプルです。それは「足を引っ張らない」ことです。大抵の現場では初心者に毛が生えたような人にアウトプットを期待していません。ある程度の教育期間をとった後で普通の人の半分でもアウトプットを出してくれたら恩の字です。
あなたが天才でなければ、まずは自分でアウトプットを出すのは一旦諦めてください。先輩の時間を増やしましょう。例えば動作確認や他チームやステイクホルダーへの連絡、文書作成など、100倍エンジニアでも生産性が変わらない業務を肩代わりして先輩が開発にかけられる正味の時間を増やしましょう。これが現段階では正しいチームワークです。100倍エンジニアの時間を奪って質問するくらいなら、10倍の時間をかけて一人で調べた方が、10倍生産性が高くなります。聞くとしても調べた上での答え合わせと間違っていた時のヒントだけにしましょう。個人の学習効率をだけみてもそっちのほうが効率いいです。理解できない人には独学大全がオススメです。
ろくに動作確認をしていない可読性の低いコードをプルリクに出して、レビュワーになった100倍エンジニアが仕様確認したりローカルで動作確認したり、あまつさえバグを見つけてしまうなど、最悪です。
初心者だから間違えてもしょうがないというのは正論です。しかし、プロジェクトの時間とコストを考慮すれば逆の結論になります。あなたのアウトプットが数倍早くなろうが遅くなろうがプロジェクトには影響がないのです。学習時間とリスクを考慮してそういうふうにタスクを組んでいます。数倍時間をかけて慎重にやって良く、マイナスを生まない事を考えれば、初心者こそ絶対にバグを出してはいけないという結論になります。0は無理でもそういう気持ちでやりましょう。
ここまでは現場に入ってからの話でした。皆さんは現場に入る方法を知りたいと思いますが、もう少し辛抱してください。敵を知り己を知れば百戦危うからずの故事もあります。もう少し敵を知ってから戦術を立てましょう。
デスマーチと呼ばれているものには2種類あります。一つは定義通りのデスマーチ (https://ja.m.wikipedia.org/wiki/デスマーチ )。もう一つはデスマーチの要件を満たさないが、関係者の能力不足によってデスマーチの様相を呈しているもの。実は前者はとても希少で、世の中のきついプロジェクトというのはほとんど後者だと考えてください。
様々な点で両者は異なります。
真のデスマーチはほとんどの場合技術的な問題ではなく政治的な問題で発生します。そのため予算は潤沢ではないが常識的にはあり、技術は枯れてリスクが少なく確かな効果が確認されているものが採用されていることが多いです。工学的なアプローチで生産性を向上する仕組みなどが取り入れられていることもあります。管理プロセスも機能しておりコンプライアンス違反も少ない傾向があります。政治的な理由でプロジェクトが延長されている都合で、PMがプロジェクトを終わらせたいと思っていても、予算がある限り新しい要件が発生しつづけて終わらないという状況も発生しえます。こちらのタイプに参加するメリットとしては、よく管理運営されたプロジェクトを体験できる点、ドキュメントがしっかりしている点、低スキルの人が参加することを考慮して仕組み化されているのでキャッチアップにかかる時間が低いなどがあります。
なんちゃってデスマーチは技術力や要件定義能力、集団の合意形成能力などの不足によって起こります。PMやステイクホルダーは赤字を垂れ流すプロジェクトを早く終わらせたいと思っているので多少納期が伸びても必ず終わります。プロジェクトを終わらせるための提案であれば下からの意見でも柔軟に対応してくれることもあります。新しい技術と古い技術が混在していたり、新しい技術を採用しているのに使いこなしていないこともあります。CI/CDや自動テストが無い又は不十分な現場も多いです。こちらのメリットとしてはスタンダートが低いのでキャッチアップ戦力になれるまでの時間が短かったり、小さな労力で大きな生産性改善ができ職務経歴書に書ける良いエピソードが作りやすいといったことが挙げられます。
また両者には人の出入りが激しいという共通点があります。そのためドキュメントの有無にかかわらず新しい人が参加し、教育や環境構築を行いタスクを振って実務を行うという、一連の受入業務に現場の担当者が慣れています。またこれは両者それぞれのところで触れましたが、理由はそれぞれ違いますがキャッチアップして戦力になるまでの時間は小さいという共通点があります。
デスマーチでは残業が多いと思われていますが、新人は戦力として期待していないので残業する必要はないです。マネージャーからすると、無駄な残業代は払いたくないし事故って仕事を増やすリスクも嫌なので、1秒たりとも残業してほしくありません。早く帰ってリフレッシュするなり自習するなりしてプロジェクトのリスクを減らしてください。
そのため、デスマーチに入って残業というのは底辺層にとってはほとんどの場合杞憂です。テスト要員としてでも残業を頼まれたら戦力に数えられている事を喜んでも良いと思います。
翻って比較対照としてみなさんに人気のあるWeb系企業を考えてみましょう。GoogleやNetflixとまではいかなくても、ほとんどの会社ではそれらを模倣しています。共通点としてはだいたい自走・自律できることが求められます。辞める人は少ないので比較的受け入れ体制は整っていないケースが多いです。企業によってスキルレベルはピンキリですが、周りとのスキル差が大きくなるのでキャッチアップにかかる労力と時間は大きくなります。開発プロセスは整えられているため、あなたが工夫して改善できる余地は少ないです。
ここであなたが採用する立場になったと想像してください。「最新の技術スタックで言われた作業をやっていました。ついていくのがやっとで自分で工夫した点は特にないです。勉強はがんばりました」という人と、「技術スタックが古かったのですがXXを導入してXXをXX程改善できました」という人がいたとして、どちらが戦力になりそうでしょう？どちらを採用したいですか？
ここまで書いたことを理解して謙虚に面接を受ければそう悪い結果にはならないと思います。
現場の技術レベルが高い現場を望んでもメリットは無いので、少しでも自分が成果を出しやすい環境を探しましょう。
この辺の話。
まず最初に、下の記事のタイトル見た瞬間にすげえ嫌な感じがした。肉の盾的な手法だよな。「JKを誹謗中傷する卑劣なネトウヨ」みたいな感じのノリ。誹謗中傷があったことをピックアップすんのは別に悪いとは思わないけど、それを意見と絡めて方向性を作ろうとしてるのがすげえ嫌。誹謗中傷問題はそれはそれで別の扱いでやってほしいわ。
次に雑にcharge.org見た感じ、そこそこ反論も来てんなって感じた。正直、そこまで求めるか？って内容もあるけど、こんだけ署名集めたことアピールして企業にも言うなら、その辺の議論はあってもおかしくないって感じはする。署名集めた奴が答えてんのかは調べてすらないから知らん。そういう議論してたならこれはある種の中傷に何のかな。
最後に、別にこれに限らないけどネットの署名とかをあんまり重視すんのもなって感じがある。個人的にはネットの可否の数を素直に見れない。人気投票の票数操作を体験してきたし。それ以外にも老害的な意見だけどネットの投票って議論とか対話とかを蔑ろにして数でぶん殴ってる感じ強い。それとこういうJustice系の話題は特にだけど、ネットの投票って反対票が見えないから、その辺も嫌な肌感覚がある。
今回の件、上記の感じで雑に正義の力でぶん殴ってる感あって、なんかあんまり素直に見れないんだよな。あと署名集めてる側、賛同してる側ってユーザが見えてんのかな。
ぶっちゃけ企業側も何がニーズで誰がユーザみたいな事って全然捉えてないのに、それを求めるもの酷なのは分かってるし、焦点絞ってなんか言うのが悪いわけじゃないのも雑感としてある。けど、それらが複合化した結果、流れ弾的に不便になったり殴られたりする人が出んのもなぁ。ステイクホルダー？的な視点がいるんじゃないのという雑感とそんな視点誰も持てねえだろという雑感。
ユーザで言うなら、批判意見側の白血病患者みたいな話は捉えるべきユーザなのは間違いないとは思う。でもそれを大々的に取り上げんのも、それはレアケだしなぁと言う感じがある。こういうマイノリティの意見は考える必要あるけど、それだけ見ても商売成り立たんし。
SNSとかの悪魔合体でムーブメント的には数が力で力こそパワーみたいなノリだけど、それとは逆に、世の中で求められてんの、企業活動の主流となるのってやっぱ対話やすり合わせでステイクホルダー？的な、ユーザに焦点当てた視点なんじゃねえの。という雑な結論に
都道府県や市町村、もちろん国家だとか、公共性の高い観光協会だとか商工会だとかもそうですが、そうした団体が、アニメやゲームとタイアップとか、さらに言えばツタヤとタイアップとか、こうした事象が「社会問題化」しています。
なぜ問題になるのかその原因はというと、私は「デモクラシーが成立していないから」だと考えるわけです。
例えば市町村が、「萌えキャラ」にしろ「ゆるキャラ」でさえも、そうした広報、というかむしろ広告宣伝ですが、そういう行政をします。そうすると、市町村の構成員であり最も基本的な利害関係者（ステイクホルダー）は、そこの市町村民です。そこではたして、そこの市町村民の意思が、その広告宣伝活動に反映されているのでしょうか？
例えば武雄市などがツタヤと「タイアップ」したわけですが、これも市民の意思が反映されているのでしょうか、また、市民の利害に目を向けられているのでしょうか。
「選挙で勝ったから」という理由で、首長が何をしてもいいという風潮になっていますよね。その選挙でその候補者に投票した人がどのくらいの割合なのでしょうか？ そもそも、全員一致で当選したとしたって、個別案件で市民の意思を完全無視していいという理屈は立たないと思います。
それに、投票の拒絶されている人（例えば未成年者）の利害に目が向けられていますか？
また、その施策が実行された後、将来になってその施策の利害を負わされる人への眼差しにも欠けています。典型的には、日本の「借金」の件もそうです。世代間の「支えあい」モデルの破綻した公的年金もそうです。だから率直に言って、「こういう無責任な人たちには人間の血が通っているのか？」と思いますよ。強権的（ポピュリズム的）な思想と、儒教的な（年長者を尊敬し、子孫に責めを負うという）思想が混在し、致命的な矛盾を起こしていると思います。
さてともかく、「選挙で勝ったから」という発想でさえも問題があるし、「俺が責任をとる」と云われても、損害が出てからお前が腹を切っても損害が無かったことにはならないわけですね。
ましてや、具体的で個別的な施策決定はむしろ、首長ではなく職員が決めていることが多いと思われます。首長は、上がってきた案にサインするだけかもしれませんし、ましてや「聞いていない」ことすらありうるのではないかと思います。そうするとつまり、その施策には住民の意思を反映するプロセスがあるのか、ということが問題であるわけです。
例えば、東京オリンピックのエンブレム問題もやはりそうなんですね。東京都がやるんだったら、東京都民の意思を反映しないといけないのに、むしろ密室的に行われていたわけですよね。
このような問題はですね、そのまま、「日本国」の問題でもあります。政策決定にしろ、道路を敷くだのダムを建てるだの原発を建てるだのもそうですし、「消費税」を上げるとかいうのもそうです。さらには、広報ポスターやＣＭに誰を採用するかというところにも、１件あたりならばたかが個別案件でも、継続的に、特定のタレントとか広告代理店とかを使っていくことが慣例化するともう、個別案件だといって済むとは思えないと感じます。（ちなみに、こうした問題点を軽減するための手法に「パブリックコメント」の制度があるわけです。）
そして、例えば、市町村だとか商工会や観光協会が特定のアニメとタイアップすると、当該市町村はそのアニメのイメージを負うことになります。そうすると、市町村民もそのイメージと影響を負うことになってしまいます。市町村民は意思決定プロセスに関与していないのに、利害を負わされるわけです。
それがかりにどっかの中小企業が宣伝でタイアップしたというのならば、それはその企業の「自由」だということになるのでしょう。上場企業だったら株主に責を負いますが、少なからぬ株主は「儲けてくれればいい」と思っているので、実際に収益が出れば文句は出にくい、つまり問題化はしにくいかもしれません。
それでも例えば鉄道事業者がやったら、その列車に乗る人みんなが、その作品だかなんだかを（事実上強制的に）見せられたり、さらには車内アナウンスまでも差し替えられて聞かされたりするわけです。そうすると、たとえ私鉄、「民間事業者」であったとしても、無難な選択にとどまって、「大冒険」はすべきではないというのが原則だと思われます。
ですから、事業の性質や規模によっては公共性が高くなり、決してプライベートでは済まされないことがあります。
話が長くなりましたが、昨今の騒動をみると、「大冒険をするな（最大公約数的であれ）」という主張と、「大冒険を許さないと社会が改まらない」という主張の二極対立、デジタル的・バイナリ的なコンフリクトになっているように思います。
しかし問題の本質は、「大冒険」をしても良い場合でも、その決定プロセスで構成員や利害関係者の意思を聴き反映させなければならない、ということにあるのです。
それを言い換えればデモクラシーだというわけです。
問題の本質は通底しているのに、そうした事件一つ一つを分断して個別化し、洞察や反省をしない習性が今の「日本人」にあるように思えます。
これは愚にも付かないただのポエムだ。それ以上でもそれ以下でもない。増田にありがちな、特に読む必要の無い、駄文というものだ。登場するものはイニシャルとかではなくただの連番を振ることにする。
僕は心が壊れてリタイアをしたことがある技術者だ。今の会社にはちょっとした縁があって拾われた。技術自体は多少は持ってるもの実質未経験な上、コミュニケーションに難があるがそれでも良いということで採用された。
入社してすぐ上長である1.から「ほんとごめん」っていきなり謝られた。当時はいやな予感はしたものの全く何を謝られているのか理解できなかったが、配属されたプロダクト2.のことだった。2.はとにかくスピード勝負で立ち上げられたもので、度を超えて醜悪で、かつ誰も全容を把握していないという度しがたいものであった。
もちろんこれには事情もあって2.が立ち上がった時点で主流だった3.というプロダクトはかっちりしているものの開発スピードが極度に遅いモノだった。仕組み・制度・人員様々な事情はあったが、おそらくはプロダクトに対する依頼者4.と開発部署の人間関係に起因するものではないかと僕は推測している。推測する理由は、その後に深まる部署間の対立と、2.が度々抜け穴として使われていた事実からだ。
2.のプロダクトのリーダーをやっていてつらかったのは、プロダクトの実情と、周りの認識の乖離によるものだ。2.は抜け穴として扱われる以外にもスピーディな開発ができると期待されるものだった。だが、実際には極度の複雑性を持つために、何かを犠牲にしなければ高速な開発など到底望めないものだったのだ。しかも、なぜか「簡単」という印象も先行していたこと、そもそも僕自身がリーダーという未経験の業務を社会復帰直後に負わされたこと、前任担当者と入れ替わり入社したこともあって実質引き継ぎがなかったこと、ほぼ人員が割り当てられない (一時期は担当者が僕一人になっていた) こと、重要な機能を実現するにはふさわしくないにもかかわらず、3. の連携プロダクトとして、重要な機能を実現してしまったことなど…。書くにはきりが無いのでここらへんにしよう。
後ほど2.から離れた後に何人かから2.に関する外的な評価を聞いたが、「どうしてあんな簡単なプロダクトに苦労するところあるの？」みたい話に帰結していた。ぼくの評価に関してははまぁそのようなものだろう。1. からは「好きなようにしていいよ」と言われていたので、本当はチャンスだったのかもしれない。ただ、僕にはそれを好きなようにできるだけの経験が全く無かったのだ。またコミュニケーションの問題もあって、復帰直前などは対人恐怖が強かったのもあって、ステイクホルダーがあまりにも多く関わる2.のプロダクトを切り盛りするにはふさわしくなかった。
2.のプロダクトに関わっている間に社内情勢はがらりと変わる。技術者の部署が分割され花形となる主流派と傍流に散っていくことになる。また、給与レンジの変更があったときに実質引き下げを行われ、僕の給与は高卒と同程度となった。詳しいことは特に書く気はない。まぁ僕はつじつまさえ合っていればいいといういい加減な人間なので給与に対する不満はあっても、曲がりなりにも生活できてるのならそれでいいかと考えていた。
僕の不満はむしろ待遇に対するものだ。選択肢がどんどん狭まっていく労働を強いられているということが我慢ならないのだ。主流派には興味深い技術も多い。僕は最近悟ったのだが、技術的チャレンジに意欲が極度に強い反面、平凡な糞くだらない開発には全く興味もわかないのだ。そして、興味の無いことに対する作業効率がきわめて悪いのだ。まぁ一端その話は置いておこう。
2.のプロダクトから離れた後部署内の様々なプロダクトを転々とすることになる。あるプロダクトのリーダー5.は10歳年下だったが、僕のことを最初から見下して「○○君」と呼んだり「こんな程度の引き継ぎ、教えなくてもわかるだろ」と言ったりしていた。後ほど上長8.から窘められたのか「○○さん」と呼ぶようにはなっていたが。またプロダクトのメンバー6.には質問をしたときに「あうぇあうぇうぇうぇうぇー」とか意味不明な奇声を上げたりされた。詳しい台詞はもう覚えてないが、とにかくすごくふざけた感じの返答しかしてこなかった。別に6.は他の人に対してそのような言動をしていることは全く無かったのだが。
実際のところ、僕が今の会社でトラブルのあった人間関係としては、5.と6.と給与実質引き下げの直前の部長くらいしかなかったが、実は僕が認識していないだけでもっとあったのかもしれない。後ほど語る7.とは人間関係のトラブルはあったものの仕事では全くからみがなかった。
話を戻すが、5.と一緒に働くのはとにかく苦痛だった。思い出すだけで吐き気がしてきてつらいので詳しいことは書かないが、僕はとにかく精神的に荒れていてSNSに愚痴を吐露し続けたり、会社を休職しようかと思っていたが8.に相談をしたときに「休職すると、現時点ですでに下限の給与がアルバイト並に引き下げられることになるし、とにかくやめておけ。なんとかがんばって出社しろ」と言われた。8.との幾度かの面談で、大体2.や僕の評価について知ることになる。
もう詳しく覚えていないのだが、このタイミングだったか、入社以来友人関係のあった7.と喧嘩別れをした。7.の日頃の考え方、言動にとにかくムカついて反感を感じていたのだ。日頃から7.はSNSで僕に対する当て付けをエアーリプライで飛ばしまくっていた。まぁ7.の言動などから推察するに、彼も僕には反感を抱いていたのだろう。お互い、ソリの合わなさを我慢して友人関係を続けていたのだが、この時に「我慢をし続けるのは本当に良くない」と悟った。ただ、一つだけなるほどと思ったことがあった。
当時、待遇の不満に対して、転職を考えていたのだが、そのことを知る7.に「転職しても根本解決しないのでは？」と言われたことだけは確かにそうなのかもしれないとは思っている。後に別の人物にも近いことを言われたし実際そうなのだろう。もう一つ印象深いことを言い残していて「おまえは本当に開発が好きなのか？」と。先ほども書いたが僕が好きなのは技術的なチャレンジであって、平凡な開発には興味の欠片もないのだ。「コードを書いてさえいれば幸せだ」というタイプの人種とは全く違う。
さて、話を戻すと、僕はなんとか欠勤することもなく出社を続けた。その後、5.は別チームに飛ばされ、一時の心の平穏を得ることになる。この平穏な時期はほとんど「死にたい」と思うこともなく生きていられた。
だが、最近また精神状態が悪化することになる。実はそのトリガーが何だったのかを全く思い出せない。平穏期に意図的に待遇に対する不満を忘れていたのが再度噴出することになる。時期だけは覚えていて、大体6月末だ。7月以降、僕は考え方を切り替えた。「我慢すると、いつか破綻を来す」睡眠時間を削ってオフタイムに技術的なチャレンジをすることになる。
僕は人格的には最悪なタイプだ。客観的に見て僕は僕と仲良くしようとは欠片も思わないだろう。コミュニケーション能力は無くはないが、きわめて偏っているので、コミュ障と言ってもいいだろう。仕事に関する能力にしてもさほど高くはない。頭が良いわけでもないし、あまり効率的ではないし、何より興味の無いことに対して僕は露骨すぎる。狙ってやっているわけではないがどうしてもそうなってしまうのだ。
技術的チャレンジだけでなんとかやっていけないだろうか？と、考えている。ここで問題になるのが僕の学歴のなさだ。ドロップアウト組なので学そのものが無い。だが、僕は技術的なチャレンジにしか興味を持てないのだ。友人からは「贅沢な悩みだなー」と言われた。実際そうなのだろう。仕事をえり好みするというのはきわめて贅沢な悩みなのだろう。部署の壁もある。
さて、僕の生きる理由の希薄さについて説明せねばなるまい。僕は生きる理由が希薄なのだ。ドロップアウトした頃の後遺症なのか、未だに希薄なのだ。存命の父親に迷惑をかけたくない、痛いのはいやだ、技術的チャレンジをしたい位しか生きる理由もないのだ。趣味はなくもないが、生きたい理由になるほど強くもない。生きることに必死になれないのだ。贅沢な悩みで、死を選んでもいいかなと考えてしまう程度には。
僕はリミットを定めている。それは借金が限界まで行ったらというものだ。最近手持ちの金が尽きて、最大200万円のカードローンを契約した。これが限界までいったら、その時はもういいかなと思っている。それまではがんばろうという思いなのだ。
駄文につきあってくれてありがとう。別に何か取り立てておもしろみのある事件があったわけでもない。無能な男が、平々凡々な日々のやりとりや、しょうもないことに心が摩耗してしまって、心が悲鳴を上げていたので、誰かに聞いてほしくて文章を書いた。ただそれだけのしょうも無い駄文につきあってくれて、本当にありがとう。
大変ですね。わたしも同じような状況に何度も陥ってるので、わかります。
というか、クライアントが最大のステイクホルダーなのだから、そうするべきです。
クライアントもこのまま開発を投げ出されるのでは丸損ですし、何かアイデアは出るかもしれません。
例えば、開発チームが当然と考えて構築しようとしている機能で、クライアントが期待していないものがあるかもしれませんよ。一緒に検討して、削ぎ落としていい機能を抽出してみませんか？
それから、プロジェクト発足時に、リスク計画に割り当てたリソースがありませんか？開発チームに無くてもクライアント側にはあるかもしれません。
リスク計画での発動トリガーを満たしていなくても、相談次第では出てくる可能性がありますよ。
もうちょっと頑張って。
