思考と決断のPM力

PMの真価

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

従順の呪縛

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

失敗からの成長

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

判断力の真髄

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

まとめ

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

関連記事

SEのいうバッファとは

バッファの真意

見積りや作業スケジュールに際して、エンジニアやシステム会社から「バッファである」という回答を受けたことはないか。システム会社が言うバッファとは保険を意味していることがほとんどである。

不確実なバッファ

非エンジニアは見積りのバッファを聞いたときに、無駄なのではないかと感じる。「念のため」に必要なバッファは、裏を返すと知識がないから調べないと分からないので不安であるという意味である。知識があり、「念のため」が必要なければバッファはないと考えられる。

知識の不足

ほとんどのシステム構築プロジェクトは、バッファが多いほうが知識がないのに見積りが高くなるという矛盾が発生することになる。そう考えると「バッファ」とは「無駄」に聞こえるかもしれない。

本質のバッファ

さて、このバッファについて本来あるべき姿を説明する。本当にやってみなければ分からないといった高度な技術を使うときに、未知の領域に関するスケジュールの影響を勘案し、計画された期間のことをバッファと見るべきである。

まとめ

単なるシステム構築プロジェクトにおいて「無駄を削ればよい」というのは非エンジニアから見ると合理的でコストの軽減にもなる。しかし、研究開発分野において無駄を削ることは必ずしも合理的ではない。発想が乏しくなるからである。

続きを見る >

QCDの死角

失敗の正体

システムの失敗は見えないことがある。ブラックボックスであるがゆえに隠せてしまうからである。失敗かどうかの線引きができないところがシステム構築プロジェクトの難しいところである。

エンジニアの真実

もしかしたら、エンジニアが都合の悪いことは隠していることがあるかもしれない。しかし、決めつけてしまうとエンジニアはへそを曲げてしまう可能性がある。隠しているつもりはなくても隠れていることもある。

成功の境界

失敗の線引きは、納期が遅れることであろうか。バグが多いということであろうか。実は、状況によって一概に言えないのである。QCDという言葉があるが、品質と費用と納期のバランスを上手にとったとしても成功か失敗か、すぐにはわからないのがシステムという無形物である。

コスパの本質

コスパという言葉があるが、かけるコストに対して、どれだけのパフォーマンスが出せるかが問題となる。システム開発では、コストからやりたいことを計算するのではなく、やりたいことを明確にしたうえで、コスト内でリッチ度合いを調節することが重要である。

まとめ

システム開発においては、失敗が見えにくいため、失敗しないように見えるのかもしれない。失敗しないことは、成功であるということでもない。時間が経つにつれて失敗を感じることもあり得るのである。

続きを見る >

小規模AI導入ガイド

効果検証から始める

多くの人は、試しにAIを導入してみて、効果を見てから予算取りを行っていきたいと考えている。とりあえずツールを導入したいといった理由では、なかなか費用を使っていいとはならないだろう。このような慎重なアプローチは非常に理にかなっており、実際の効果を数値で示すことができれば、その後の本格的な導入に向けた予算確保もスムーズに進むはずだ。まずは小さく始めて、確実な成果を積み重ねることが重要になってくる。

UI重視の効果測定

AIの効果を確認してから検討することを考えたときに最初にやることは、実はUI(ユーザーインターフェース)の部分である。例えば、グラフの表示などだ。結果として何ができれば、どういった業務がどれくらい短縮されるのかを第三者が見ても確認しやすいからだ。データの可視化により、AI導入前後の変化を明確に示すことができれば、関係者全員が効果を実感できる。特に経営陣への報告時には、視覚的に分かりやすい資料があることで、プロジェクトの価値を効果的に伝えることが可能になる。

開発とAIの分離問題

UIを作るとなると、結局はシステムの開発が必要になってしまうのではないかという懸念が生まれる。あるいは、システム開発を行うことで、そもそも期待したAIの活用がなされなくなってしまったりすることもあるだろう。これは、目的をシステム開発とAIとに分けているからだ。本来であればAI活用による業務改善が目標であったにも関わらず、システム開発が主目的となってしまい、AI機能が後回しになってしまうケースも少なくない。このような本末転倒を避けるためには、プロジェクトの優先順位を明確にすることが不可欠だ。

統合的アプローチの重要性

AIはAIの会社に発注する、UIはシステム開発会社に発注するといった、区分けをしてしまうことに誤りがある。まず、やるべきことを分解するのではなく、ITに対する知見のある人に区分けから入ってもらい、技術的な判断も行いつつKPIを作っていくことが重要になる。これは市民開発と呼ばれるものに近く、自社内でローコードを使って軽く開発することを意味する。技術的な専門知識を持つ人材が全体を俯瞰し、最適な技術選択とプロジェクト設計を行うことで、効率的かつ効果的なAI導入が実現できるのだ。

まとめ

部署やグループを横断した視点を持つことがとても大切であることがわかった。ツールや部分的な技術を目的としてしまう前に適した組織体であることの確認が大切だ。AI導入を成功させるためには、技術面だけでなく組織運営の観点からも準備を整える必要がある。

続きを見る >