記事

思考と決断のPM力

PMの真価

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

従順の呪縛

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

失敗からの成長

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

判断力の真髄

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

まとめ

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

熱意の共有 前の記事 リーダーの多忙による弊害 次の記事

関連記事

記事

ローコード開発とAI活用

AIとローコードの融合

ローコード開発プラットフォームの普及により、非エンジニアでもアプリケーション開発が可能になった現在、生成AIの活用が大きな注目を集めている。ChatGPTやCopilotなどのAIツールを組み合わせることで、開発スピードがさらに向上すると期待されているが、本当にすべてのローコード開発にAIが必要なのだろうか。コスト、品質、保守性など多角的な視点から、AI導入の真の価値を見極めることが、企業のDX戦略において極めて重要になっている。

コード生成の現実

生成AIによるコード生成は確かに魅力的だが、実際の品質には課題がある。AIが生成するコードは、単純な処理であれば高品質だが、複雑なビジネスロジックや例外処理が絡むと、不完全なコードが生成されることが少なくない。さらに深刻な問題は要件定義の壁である。AIは与えられたプロンプトに基づいてコードを生成するが、曖昧な要件や暗黙の前提条件を正確に理解することは困難である。結果として、開発者は生成されたコードを詳細に検証し、修正する必要があり、期待したほどの効率化が実現しないケースも多く見られる。

保守性のコスト

AIを活用したローコード開発において、最も見落とされがちなのが保守性の課題である。AI生成コードは、その時点では動作しても、後から読み解くことが困難な構造になっていることがある。変数名が不適切だったり、処理の意図が不明瞭だったりすると、半年後に修正が必要になった際、開発担当者が変わっていた場合、大きな手戻りが発生する。また、AIツールのバージョンアップや仕様変更により、過去に生成されたコードとの互換性が失われるリスクも存在する。初期開発のスピードを重視するあまり、長期的な運用コストが膨らんでしまっては本末転倒である。真のDX推進には、目先の効率化だけでなく、持続可能な開発体制の構築が不可欠なのである。

適切な見極め

ローコード開発におけるAI活用は、すべてのケースで必須というわけではない。定型的な画面開発や単純なCRUD操作など、パターン化された開発にはAIが有効だが、複雑なビジネスロジックや高度なセキュリティが要求される領域では、人間による丁寧な設計と実装が重要である。重要なのは、プロジェクトの性質、チームのスキルレベル、長期的な保守計画を考慮した上で、AIを活用すべき領域と従来手法を維持すべき領域を明確に区分することである。段階的にAIツールを導入し、効果を検証しながら適用範囲を拡大していく慎重なアプローチが、失敗リスクを最小限に抑え、真の生産性向上につながる。

まとめ

ローコード開発へのAI導入は、万能の解決策ではなく、適材適所で活用すべきツールである。コード生成の質、要件定義の難しさ、保守性の課題を十分に理解した上で、自社の開発体制に合った形でAIを取り入れることが成功の鍵となる。短期的な効率化だけでなく、長期的な運用まで見据えた戦略的な判断が求められている。

続きを見る >
記事

予算ブレの原因

開発の変動要因

システム開発は長期にわたることが多く、また未来の不確実性の中で予算を策定しなくてはいけないことがある。セキュリティーをはじめ動作環境の変化や人員の欠如、予期していなかった仕様の発覚などが原因だ。

目標変化と予算

進捗率は目的地が明確に設定されていれば数字を負うことで予算達成率を算出することができる。しかし、目的地が近い遠いのは無しではなく、根本的な目的地がなくなったり、複数になったりすることがシステム予算の策定の難しいところである。

計画型開発法

システムに未来を見ることができればブレない、見えないことをすべて調査の上で着手できれば確実な予算と実行が可能である。進捗率の報告が可能になる。フォーターフォールモデルなのでコストがかかることと時間がかかることの覚悟が必要だ。途中での方向修正は原則できない。

柔軟な開発手法

逆に低予算で早く導入するなら、見えにくくなるデメリットがある。状況によって対応を素早く変化させる必要があるため進捗率を算出しにくい。アジャイル開発と呼ばれるものであり、社内開発であることが理想である。途中で出てくる条件に対しても柔軟に方向性を変化させることが可能である。

まとめ

アジャイル開発で予算を立てるときは、1.5-2.5倍くらいを目安に余裕を持って設定することを推奨する。

続きを見る >
記事

業務可視化によるDX推進

真の業務改善への道筋

いきなり顕在化しているアナログをデジタル化するだけでは業務改善とは言えない。真の業務改善を実現するためには、表面的な問題解決ではなく、根本的な業務の見直しが必要である。業務を可視化して正しい業務分析を行うためには、ある程度のステップを踏む必要がある。単純なデジタル化は一時的な効率化にとどまり、長期的な競争力向上には繋がらない。

目的とゴール設定

まず、目的とゴールを明確にする必要がある。なぜ業務分析をするのか、何を達成したいのかを明文化することが重要である。例えば、「手戻りを3割減らす」「問い合わせ対応時間を半分にする」「余剰コストを1千万円削減する」などの具体的な数値目標を設定する。曖昧な目標設定では、後の分析や改善施策の効果測定が困難になってしまう。定量的で測定可能な目標を立てることで、分析の方向性が明確になり、成果を客観的に評価できるようになる。

業務の可視化技法

現在の作業タスクのすべてをまずは網羅的に洗い出して、分類を行う。複数担当者で付箋にタスクを書き出し、重要度マトリクスや緊急度マトリクスで整理する方法が非常に有効である。また、必ず用意しておきたいのが、業務フロー図と業務の分担表である。誰が、いつ、どこで、何をしているかを図式化することで、無駄や重複、ボトルネックが浮き彫りになる。このプロセスにより、今まで見えなかった非効率な作業や不要なプロセスを発見できるのである。

根本原因の探求

課題の本質がまとまったら、重要な事項と緊急の事項などを切り分けて、本質的ではない事項は思い切って削除や軽減を検討する。また、抽出した課題は小さな原因に分解していき、根本原因を探る（要因分析）。リソースが限られる場合には、ABC分析（例えば顧客ランク別）で、重要顧客に注力できるよう業務配分や訪問頻度などを見直す。定量データや日報などのログ、クレームデータの活用も効果的である。AIで課題を解決するより前に、膨大な過去データをAIに処理させるのも良いだろう。

まとめ

定量化・定性化できれば、効果検証につなげる改善策と実行計画を策定する。正しい業務分析とは、単なるデジタル化ではなく明確な目的に基づいて、ボトルネックを可視化し、データと構造化された分析を行うことなのである。継続的な改善こそが真のDXを実現する。

続きを見る >