記事

運用の昇華

開発現場の想定外

基幹システムの開発現場では、最初に想定した仕様とは異なる業務フローが後から発覚することが多い。

マネジメントの試金石

後から発覚した業務フローは、すでに構築が進んでいるシステムに組み込むことが難しいため、どのように対応するかがプロジェクトマネージャーの腕の見せ所である。

プロジェクトの舵取り

プロジェクトマネージャーとは何かと問われたときに、一言で言い表すならば、不測の事態にどのように対応できるか、ということではないかと考える。プロジェクトが何の問題もなく、完遂できることは少ない。したがって、イレギュラーケースが発生した時にどのような手立てを打てるか、迅速に行動できるかがプロジェクトマネージャーのレベルとなる。

パートナーシップの重要性

プロジェクトマネージャーがシステムの完成しか考えていなければ、途中から発覚した仕様は「運用でカバーせよ」とユーザー側に責任を押し付けてしまうことがある。しかし、より良いシステムを目指す、パートナーとしてであればこの回答は好ましくない。

まとめ

どのような事象がきっかけで、途中で使用漏れが発覚したのか、プロジェクトの進行状況を見ながら、ひも解くことが重要である。運用でカバーというユーザー側だけにだけ負担をさせるのではなく、運用をカバーするようなシステムを構築できるのが理想である。

マニアの逆効果 前の記事 フルスクラッチは体力 次の記事

関連記事

記事

小規模AI導入ガイド

効果検証から始める

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

UI重視の効果測定

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

開発とAIの分離問題

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

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

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

まとめ

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

続きを見る >
記事

要件定義のアプローチ

要件定義の基本

すべてをシステムで解決してしまおうとする要件定義には注意が必要である。システムの成功の可否は要件定義にかかっていると言っても過言ではない。しかし、十分に要件定義の時間を使ったにも関わらず、ITプロジェクトが失敗することがある。

規模別の要件定義

システム構築の規模によって、要件定義の粒度が変わる。小さなITプロジェクトの場合は要件定義をせずにプロトタイプを作りながらシステム構築を進めるといった方法がある。これをアジャイル開発、プロトタイプ開発と呼ぶ。

要件定義の本質

要件定義の粒度は時間を掛ければ細かくなるわけではない。ユーザー側でも要件定義を進めるにつれて、想定している機能の矛盾点が出てくることがある。この矛盾点を解消していくこと自体を要件定義としてはならない。要件定義はあくまで本質的なコアとなる部分から膨らませることが重要である。

対話型要件定義

要件定義フェーズで失敗するパターンは、ユーザー側との対話ではなく、システム会社側がヒアリングに徹する場合である。ユーザー側はITを利用してどのようなことができるかを知らない可能性が高いため、システム専門家がそれを鵜呑みにした仕様で要件を固めてしまうと、製造工程で無駄な工数が発生し予算をオーバーしてしまうことがある。

まとめ

本質的な要件をコミュニケーションによって、はっきりさせていく作業こそが要件定義と言えるのである。さまざまな視点から何度も繰り返し要件をなぞることで粒度が落ちていき、適切な要件定義書となる。何でもかんでもシステム化せず、オペレーションとの関係性を見合わせながら進めることが望ましい。

続きを見る >
記事

Power Apps対kintone

比較で迷う現場

中小企業のDX担当者が必ず通る道が、ローコードツール選びである。なかでもPower Appsとkintoneは、どちらも「現場が自分でアプリを作れる」と評判で、調べるほど甲乙つけがたく感じる。営業に聞けば「うちが一番」と言われ、社内では「結局どっちなのか」と問われる。情報は多いのに決め手がない。本記事では費用・機能・学習コスト・拡張性の4軸で両者を整理し、迷わず選ぶ基準を示す。

比較の4軸

比べるときは、軸を決めると霧が晴れる。本記事の4軸は、費用・機能・学習コスト・拡張性だ。まず費用から見ていく。Power AppsはPremiumプランが1ユーザー月20ドル前後で、最低契約人数の縛りがなく、作れるアプリ数も無制限である。一方kintoneは、スタンダードコースが1ユーザー月1,800円、最低10ユーザーからの契約となり、最低でも月1万8千円から始まる。少人数なら割高に見えるが、サポートや国産ならではの安心感が価格に含まれていると考えると、印象は変わってくる。

機能と学習コスト

ここで視点を変える。費用の次に効いてくるのが、機能と学習コストの関係だ。kintoneは、ドラッグ＆ドロップで項目を並べるだけでアプリが完成し、ITに不慣れな現場担当者でもその日から使い始められる。立ち上がりの速さは大きな魅力である。対してPower Appsは、Excelに近い関数や画面設計の考え方を覚える必要があり、最初の学習コストはやや高めだ。しかしMicrosoft 365をすでに使っている企業なら、TeamsやSharePoint、Outlookとそのまま連携でき、覚えた先にできることの幅が一気に広がる。手軽さを取るか、伸びしろを取るか。ここが、両者を分ける最初の大きな分岐点になる。

拡張性が決め手

最後の軸、拡張性が、実は選定の決め手になる。kintoneは外部サービス連携やプラグインが豊富で、追加開発なしでも業務に合わせて育てやすいのが強みだ。Power Appsは、Power AutomateやAI機能、Dataverseと組み合わせることで、基幹システムとつながる本格的な仕組みまで一気通貫で作れる。ここまで来ると見えてくるのは、「どちらが優れているか」ではなく「自社の起点はどこか」という問いである。すでにMicrosoft 365が社内に根づいているならPower Apps、まずは小さく現場主導で始めたいならkintone。この軸で考えると、4つの比較が一本の線でつながり、迷いが消えていく。

まとめ

Power Appsとkintoneは、費用・機能・学習コスト・拡張性の4軸で性格が分かれる。手軽さと現場主導ならkintone、Microsoft 365を活かした拡張ならPower Appsだ。大切なのは、自社の起点から逆算して選ぶことである。

続きを見る >