かなり根が深い問題なのか、これは。どうしたもんだろう。

要求事項の整理からプロジェクト化する技術が足りない？

システムの上流工程に「要件定義」があります。簡単に言えば、システムにどんな機能を持たせるかを、自分たちが欲しい結果から逆算して決めることです。

そのため、要件定義に行く前に「自分たちが欲しい結果＝システムにやらせたいこと」という要求事項の整理が必要なのですが、ここで詰まってしまうケースがとにかく多いようです。

１つには、要求事項をどう整理すれば、正解のソリューションを見出すことができるのか。もう1つは、リソースをどう配分してプロジェクト化するか。この2つが両方できないので、・・・・という感じがします。

なぜ、このシステムを入れるのが正しいのか

一番都合の良い提案をして欲しいと思うのは人の常ですが、複数の選択肢が欲しいなら、それなりの情報を精査して提供しないといけません。「こいつら全然煮詰まってねぇ」とバレたら、どこからも塩対応必至です。

改めてこの問いに答えを出すには、理論武装が必要になります。

1.  解決したい問題を明文化する
2. その問題を解決するアプローチを作る(複数あるはず)
3. 各々のアプローチを比較検討する軸を整理する
4. 評価軸の是非を議論し、選ぶべき道を決める

特に重要なのは２です。1は総論レベルでは自明なことが多く、総論から各論に落としていく「アプローチ」の構築で詰まるケースが多いと思います。

アプローチの構築はタスクばらしと等価なので、タスクばらしで色々ぐぐると参考になると思います。倉貫さんの記事に明るいです。

システム移行を例に取れば、移行後の運用フローを先にイメージした上で、どこまで今までを踏襲するのか、改革したい点をどこに盛り込むか、データはどうやって移すのか〜みたいなのを考える必要があります。

プロジェクト化する技術

1. みんなにとって良いゴールを見出す
2. 成果物と手順を整理して、WBS引く
3. チームビルディングして、担当を決めて工数を積む
4. 成果が検証できる範囲で、手を動かせ。進め。

以上です。

重要なのは、チームビルディングをするときに、「経営/IT/事業部」のあいだに入る役目の旗振り役が必要で、そのヒトに手綱を握ってもらうこと。プロジェクトは想定外の雨あられですから、検討に追加するのか、スルーするのか、別の手段にするのか、そーゆーのを決めるためにどれを優先するかを決めるわけですけど、その優先順位を中立的に決められる人がいないと、自立しないので。

プロジェクトは飛行機の離着陸と同じです。着陸地点がないと墜落します。国内に行くのと外国に行くのでは、だいぶ違いますよね。え？自分たちが行こうとしている場所の距離感がわからない？ WBSはそのためにあるぞ。

検証できる範囲で進め

「あいつらができると言ったのに、こんなはずじゃなかった」みたいな話になると辛いですね。特にシステムのように形の見えないものは、なりがち。こういう時はエンジニアが内部にいれば、技術検証・運用検証ができるので強い。

NoCodeやローコードのソリューションはいっぱいありますので、それらを使ったプロトタイプなどがあれば、より確実に進めることができると思います。答えを自分たちで探していく時間も人もいないなら、素直に業者にお任せして下さい。

え？ベンダーの言いなりは困る？ ハーブかなにかやつておられます？？

出来ないことは多いが、マネジメントできることはある

私自身も、情シスのこと何もわからないと思うことばかりです。気づけば新しいやり方・価値観・ソリューションが生まれてるし、それを追いかけ続けるには人生短い。

出来ないことは多いですけど、求める結果に対する舵取り＝マネジメントは自分ができる・できないは無関係なので、そこで折り合いつけることにしています。

要求事項をまとめプロジェクト化する技術と共に、皆さんの現場でシステム導入が成功裏に終わらんことを。