記事

思考と決断のPM力

PMの真価

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

従順の呪縛

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

失敗からの成長

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

判断力の真髄

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

まとめ

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

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

関連記事

記事

従来開発 vs ローコード開発比較

基本概念

企業のデジタル化が加速する中、システム開発手法の選択は事業成功の鍵を握る重要な決断となっている。従来開発は、プログラマーがコードを一から書き上げる伝統的な手法で、高い技術力と豊富な経験が求められる。一方、ローコード開発は視覚的なインターフェースを活用し、最小限のコーディングでアプリケーションを構築する革新的なアプローチである。両者の特徴を正しく理解することで、プロジェクトに最適な選択が可能になる。

費用対効果

従来開発では高度なスキルを持つエンジニアの確保が必要で、人件費が開発コストの大部分を占める。特に大規模プロジェクトでは、設計から実装、テストまで長期間の人的リソースが必要となり、総コストは数千万円規模に達することも珍しくない。対してローコード開発は、専門知識が少ない人材でも短期間でアプリケーション構築が可能で、初期投資を大幅に削減できる。しかし、プラットフォームのライセンス費用や将来的なカスタマイズ制約を考慮すると、長期的なコスト効率は慎重に検討する必要がある。

開発速度

開発期間において両手法の差は歴然としている。従来開発では要件定義から本格運用まで数ヶ月から数年を要するケースが一般的で、複雑な機能実装には綿密な設計と段階的な開発が必要である。一方、ローコード開発は既存のテンプレートやコンポーネントを活用することで、数日から数週間での迅速なプロトタイプ作成が可能である。特にビジネスアプリケーションや内部管理システムでは、従来開発の10分の1以下の期間で実装できる場合もある。ただし、複雑なロジックや高度な機能が必要な場合は、結果的に従来開発と同等の期間を要することもあるため、プロジェクトの性質を見極めることが重要である。

品質と制約

システムの品質面では、それぞれ異なる特徴がある。従来開発は細部まで制御可能で、パフォーマンス最適化や独自機能の実装において高い品質を実現できる。セキュリティ要件が厳格なシステムや大量データ処理が必要な基幹システムでは、従来開発の柔軟性が威力を発揮する。ローコード開発は標準化されたコンポーネントを使用するため、一定の品質は保証されるが、プラットフォーム依存による制約がある。また、複雑な業務ロジックの実装や外部システムとの高度な連携において、期待する品質レベルに到達できない可能性もある。品質要件と開発リソースのバランスを慎重に評価することが成功の鍵となる。

まとめ

最適な開発手法の選択は、プロジェクトの目的、予算、期間、品質要件を総合的に評価して決定すべきである。ローコード開発は迅速性とコスト効率に優れ、内部業務システムや簡易的なWebアプリケーション開発に適している。従来開発は高い技術的要求や独自性が必要なシステムに最適である。重要なのは、どちらか一方に固執するのではなく、各プロジェクトの特性に応じて柔軟に選択することである。

続きを見る >
記事

AIチャットボットの現実

チャットボット幻想と現実

人手不足や生産性向上が叫ばれる中、多くの企業で「問い合わせ業務の多くはAIチャットボットで代替できるのではないか」という期待が高まっている。確かに、人間と自然に会話できるAIの実現は、多くの技術者が長年抱き続けた夢でもあった。しかし、過去には言語理解や文脈の把握に技術的な限界があり、実用化には程遠いというのが現実だった。こうした期待と現実のギャップが、AIチャットボット導入の失敗要因となってきた。

チャットボットの進化

2000年代には、ルールベースやシナリオ型のチャットボットが登場し、定型的なカスタマーサポートなどで徐々に実用化され始めた。とはいえ、自然な対話というより「決められた会話」に近く、限定的な使い方にとどまっていた。ところが2020年代に入り、ディープラーニングの飛躍とともに自然言語処理の精度が格段に向上し、Google、Facebook、OpenAIといった技術企業が次々に大規模言語モデル（LLM）を発表したことで、チャットボットは“おしゃべりマシン”から会話パートナーへと進化した。

ChatGPTの衝撃

ChatGPTのような生成AIが登場し、誰でも使えるようになったことで、AIチャットボットの活用は一気に加速した。従来のようなFAQへの対応だけでなく、長文の文書作成や要約、翻訳、さらにはプログラミング支援など、より複雑で創造的な作業もこなせるようになっている。人間の知的作業領域に深く入り込み、単なる効率化ツールにとどまらない存在となった。もはや「使えるかどうか」ではなく「どう使うか」が問われるフェーズに突入している。

業界全体への波及

AIチャットボットの導入は、ビジネスだけでなく教育、医療、自治体など、多様な分野に広がっている。学生の学習サポートから医療問診の補助、行政窓口での自動対応まで、AIは生活の一部に組み込まれつつある。この変化は、かつてITインフラを支えてきた旧世代のエンジニア像を超える大転換だ。業務が高度化し、かつ柔軟性が求められる現代において、AIと協働する力が企業と個人の双方に求められている。

まとめ

AIチャットボットは、単なる業務効率化ではなく、人間の知的作業を補助する“共創”のパートナーである。ただし誤情報、倫理、プライバシーといった課題も存在する。こうした課題を踏まえ、社会全体でのルール整備と、使い方の成熟が必要だ。AI導入を成功させるには、「AIも使い様」という視点が欠かせない。ITの導入に乗り遅れてきた企業ほど、AI活用でも二の舞になりかねない。アタラキシアDXは、AI黎明期からの導入支援経験をもとに、技術とビジネスの橋渡しを支援している。

続きを見る >
記事

賢いコスト削減

投資と競争力

バックヤードのシステム開発は収益と直接結びつかないため、できるだけケチりたいものである。にもかかわらず、バックヤードのデジタル化には大きなコストがかかる。しかし、新しいインフラに適切な投資ができない企業は競争力を失うのである。

要件定義の罠

バックヤードのシステムをできるだけ安く抑えようと思うと、要求定義や要件定義をしっかり作って依頼すればよいと考えがちである。もちろん、間違ってはいないが、入り口が安くなるわりに、システム開発の途中で追加工数が発生してしまい、結果としてシステムが高くなってしまうのである。

未来志向の要求

システム開発の途中で追加予算がかかってしまうのは、最初の要求定義や要件定義のときに想定される未来が見えていないことが原因である。これを見通すには要求定義や要件定義を行う背景や、未来の目指すところまでをエンジニア出身のアナリストに情報共有しなければならない。

投資の真価

導入時の金額だけをケチることは、保守運用などのランニングコストに跳ね返ってきてしまい、システムの寿命が短くなる。そうならないために、第三者のIT業者やITコンサルタントを入れるほうがよいと言われている。うまくDX化できれば生産性が上がり、投資を大きく回収できる。ことIT投資については、竹槍戦か空中戦かくらいの違いを生んでしまうのである。

まとめ

システム設計やプログラミング作業と同じようにITコンサルタントも1人の能力に偏りがちである。それゆえ、PMOと呼ばれるチームを形成することで、集合知を活用して、さらに未来を予測できるような体制を構築することが望ましい。

続きを見る >