思考と決断のPM力

PMの真価

スキルシート上にあるPMというのは、どういった開発言語や開発環境などを使ってきたかという内容であることが多く、SEの延長という意味合いが強く残っている。もし、期待するポジションが発想力や提案力にあるとすれば、姿勢をみることが大切となる。

従順の呪縛

就職氷河期と呼ばれる世代より上の年齢層では、常に従うことを幼少期から叩き込まれていると考えられる。日本では「禁止」か「許可」かを常に意識しながら仕事をしており、「許可されるまでは禁止されている」と考えているのではないかと推察される。

失敗からの成長

正しいか、間違っているか、の判断基準しか持ち合わせていない場合、何か問題が発生したときに時間を遡ってどこで判断を間違えたのかを追求する。それは大切なことであるが、実際のプロジェクトでは誤ったことを反省しつつ修正しながら進むことが大切である。

判断力の真髄

エンジニア出身のPM(開発プロジェクトのPM)だと、禁止か許可かというデジタルのような見方をしている人もいる。特に今日のシステムに関するプロジェクトでは、ゼロかイチだけでは判断できないような、ウエットでアナログな状況判断が必要となる。

まとめ

たとえ能力の高いPMだったとしても、仕事になると発想することや作ることの楽しみより、ミスによる懲罰を恐れたりするために、無難で当たり障りのない判断をしがちである。システムに関するプロジェクトがなかなか前へ進まない理由でもある。

関連記事

DX成果が出ないときの処方箋

焦りの正体

「DXを推進しているのに、目に見える成果がまったく出ない」。そんな焦りに押しつぶされそうになっていないだろうか。ツールを導入し、業務フローを見直し、社内への説得に奔走する毎日。それでも経営層からは「結局なにが変わったの?」と聞かれてしまう。中小企業白書においても「具体的な効果や成果が見えない」はDX推進の代表的な課題として挙げられている。この焦りを抱えているのは、あなただけではない。

成果が出ない真因

DXの成果が見えにくい最大の原因は、成果が表れるまでの「時間軸」を正しく認識できていないことにある。DXは売上のように短期で数字に直結する取り組みではなく、業務プロセスの再設計や組織文化の変革を伴う中長期的なプロジェクトである。経済産業省のDX推進指標でも、定量的な成果測定の難しさが指摘されている。たとえば紙帳票を電子化しても、その効果がデータとして蓄積され意思決定のスピードに影響を与えるまでには数か月単位の時間がかかる。焦りの根本は「すぐに大きな成果が出るはず」という期待値のズレにあるのだ。

小さな成功の見える化

では、どうすれば成果を「見える化」できるのか。鍵となるのは「小さな成功の可視化」である。いきなり全社的な大変革の成果を求めるのではなく、まずは一つの業務改善にフォーカスすべきだ。たとえば「請求書処理の時間が週5時間短縮した」「問い合わせ対応のスピードが30%向上した」など、数値で語れる改善を一つずつ積み上げていくのである。具体的にはKPI(重要業績評価指標)を事前に設定し、改善前後のデータを比較できる仕組みをつくることが有効だ。作業時間の短縮率、エラー件数の減少、コスト削減額といった定量的な指標を継続的に追いかけることで、経営層にも現場にも「確かに前に進んでいる」と伝えられるようになる。小さな数字の積み重ねが、やがて大きな説得力を持つのである。

組織を動かす一歩

小さな成功を積み上げることには、もう一つ大きな意味がある。それは「組織全体の巻き込み」だ。一つの部署でDXの効果が数字として証明されれば、他部署からも「自分たちの業務でも試してみたい」という声が自然と上がり始める。DXは「推進する」ものではなく「広がる」もの。そのためには最初の成功事例をモデルケースとして社内に共有し、横展開していく流れをつくることが重要である。社内ミーティングや掲示板で改善実績を発信し、成功体験を共有する文化を根づかせるべきだ。焦って大きな成果を狙うよりも、小さく始めて確実に成果を示す「スモールスタート」の姿勢こそが、結果として全社的なDX推進を加速させるのである。目の前の焦りに負けず、一歩ずつ着実に前進していくことが大切だ。

まとめ

DXの成果が見えないと感じたときこそ、「時間軸の見直し」と「小さな成功の可視化」に取り組むべきである。KPIを設定して改善を数値で追いかけ、スモールスタートで着実に実績を積み重ねていく。大きな変革は、小さな一歩の先にある。この順番を意識するだけで、漠然とした焦りは確かな手応えへと変わるはずだ。

続きを見る >

システム開発の混迷

営業依存の弊害

業務システムがうまくいかないのはベンダーやSEの問題だけではない。SEを取り巻く環境もシステム開発には重要である。業務システム開発を依頼するベンダーであれば営業担当者が挟まる。日本の縦割り社会の中で営業担当者は非エンジニアである場合が多く、プロジェクトの成功が目的ではない場合がある。

役割の細分化

SEをプロジェクトマネージャーとしている場合も注意が必要である。日本ではシステムエンジニアは細分化されておらず、建築でいうと参加者の全員が職人という扱いであることが多い。システムに関わる人全員がSEとしてしまっている間違いである。

開発の本質

SEやベンダーのプロジェクトマネージャーはそれ自体がプロジェクトと考えていることも多く、ビジネスとしてのプロジェクトとして捉えることができていないことがある。本来はビジネスが中心にあって、その中に業務システムが位置するはずである。それが見えているか否かで、業務システム開発の成功の確率は変わるのである。

相互理解

逆に、システムのことはSEに任せているというような場合も注意が必要である。システムのプロジェクトを経験したことがある、というだけでは、システムに関連するプロジェクトを成功させるのは困難である可能性が高い。プログラミングの経験がなければ、SEやベンダーが持つ心境を察することができないからである。最も重要なことはシステム導入時のイメージである。

まとめ

欧米では当たり前のように、間接的に関与する売上や利益の向上を管掌する部門や役職があるが、日本では良くも悪くもロジカルであり、数字がなければ行動に移せない厳密なルールがある。

続きを見る >

ノウハウはタダじゃない

IT導入の難しさ

IT導入では、どの程度のコストをかけるべきか、その費用がどのように効果を生むかの判断が難しい場面が多い。正解が存在しないため、常に試行錯誤が伴うのが実情である。導入後も改善や調整が続き、理想の形を追い求めて進化し続ける必要がある。これこそが、IT導入のハードルを高める最大の要因である。

「導入=完成」の落とし穴

「導入すれば終わり」と考えると、ITプロジェクトは失敗しやすくなる。IT導入には明確なゴールがないため、段階的なチェックポイントの設計が重要となる。導入途中で要件が変化することも少なくないが、それを「失敗」とみなすのではなく、「成功への第一歩」と捉えるべきである。柔軟な対応と継続的な見直しこそが、成果につながる道である。

見積もりが難しい理由

目に見えるモノを作る場合とは異なり、ITシステムの見積もりには高い不確実性が伴う。業務の関連性、将来的な拡張性、外部環境の変化など、検討すべき要素は無数に存在する。したがって、本格的なIT導入には、実際の開発にかかる時間の2倍ほどの準備期間を設ける覚悟が必要である。余裕を持つことが、後のトラブル回避にも直結する。

DXがカオスになる訳

システム構築やDXのプロジェクトは、時間の経過とともに当初の目的を見失いやすい。最初に定めた要件が現場の混乱の中で忘れ去られ、後から新たな要求が持ち込まれることで、プロジェクトが迷走していく。現場も対応に追われ、全体が混沌としていく。こうした事態を避けるには、目的の定期的な再確認と明確な進行管理が不可欠である。

まとめ

ITに苦手意識があるからといって「なんとかしてくれ」と丸投げする姿勢では、プロジェクトは成功しない。目的や進捗のチェックポイントといった、数値化できないノウハウの積み重ねこそが、成功への鍵となる。

続きを見る >