効率化の誤解

目標設定の要諦

SESと呼ばれる派遣や準委任契約では、プロジェクトを完遂することが難しいとしている。これはゴールが未設定であったり、曖昧になってしまう場合が多くあるからである。ゴールの設定や未来像は非常に重要で、プロジェクトマネージャーなどリーダーが必ず持っておくべき指針である。

真のリーダー像

システム開発に参画するメンバーは一般的に経歴書やスキルシートによって決まる。プロジェクト経験数が多かったり、扱える言語が多かったりするだけでは、本当のスキルは推しはかれない。やはり、確認すべきは不測の事態が起きたときの対処方法を豊富に持つリーダーが必要となる。

アジャイルの本質

犬小屋を建てるときに設計書はいらないが、マンションを建てるには設計書がいる。アジャイル開発といっても、例えばマンションを設計図なしに建てるといったことを考えるとある程度は見通しや知見などを持つメンバーが方向性を決めていく必要がある。システム開発はその時その時の条件によっていい悪いの判断軸が変わる。さらに時間の経過でも判断軸が変化していくのである。

部分最適の罠

日本には「カイゼン」という高度経済成長期を支えた力強い言葉がある。しかし、時と状況によって判断軸が変わるソフトウェアという無形財産の前では、「善」に「改」めることができているのか、変化してしまう背景がある。職人気質である国民性も相まって、どうしても部分改善、部分最適を繰り返してしまうというプロジェクト現場が少なくない。

まとめ

システム運用や保守における部分最適は必ずしも全体最適になるわけではない。むしろ、この部分最適が全体を考えたときの労働生産性を下げていることすらある。小回りが利く人であればあるほど属人化してしまったりするため、誰が全体最適を見るのがベストなのか、改めて考える必要がある。

関連記事

開発の相場

相場の不在

フルスクラッチでのシステム開発に相場はない。相場とは商品が一般的に流通している商品など数が多い場合は、競争原理も働き、金額がある一定の範囲に収まってくるものである。

建築との差異

たとえば、一戸建て建築であれば、建物の規模と資材、それに加えて職人の人工で金額が決まる。フルスクラッチのシステム開発は、つまり極めて特殊な特注品を作るようなものであるため、システム開発に相場という概念が基本的にはないのである。

人件費の実態

システム(ソフトウェア)は一戸建てのように、基本的には材料費はかからない。システム開発の費用のほとんどは人件費である。大工職人の人工と同じように人月単価と呼ばれるSE1人が1ヶ月働く金額で相場を知ることができるのである。

工期の変動

建物を建てることと比べるとシステムやソフトウェアは無形の物となるため、1ヶ月の労働力を推し量ることは困難である。個人のプログラミングの早さによって、納期が早くなったり遅くなったりするのである。

まとめ

SEは過去のプロジェクト参画実績から、同じようなプロジェクトに何度も参画していれば手練れでスキルが高いと評価される。システムに関わる人材の評価が困難な点は、プロジェクトに参画する経験値と、本当の意味でのスキルが比例するわけではないことである。本当の意味でのスキルとはプロジェクトを成功させられるかどうかを指すのである。

続きを見る >

オフショア開発における契約形態の選択と、重要なポイント

オフショア開発には、受託開発、ラボ開発、そして折衷型の3つの契約形態が存在します。それぞれの契約形態には特徴と課題がありますが、最終的にここで「折衷型」と述べているものに集約していく傾向があります。

受託開発契約とその特徴

受託開発契約は、成果物の納品を約束する契約形態です。この形態では、事前に成果物の定義を明確にし、それに基づいて開発を進めます。受託開発契約はソフトウェア開発においてシンプルな形態と言えますが、成果物の定義を明確にすることは容易ではありません。実際の開発作業では、概念上の定義と現実の制約との間で調整が必要となる場合があります。

ラボ開発契約とその特徴

ラボ開発契約は、クライアントが直接開発者に対して指示を出す契約形態です。クライアントは開発者を拘束し、その時間を購入します。この形態は、日本のSES契約に近いものですが、ラボ開発では開発者は非常駐となります。時間単位で開発者の貢献を購入するため、時間の品質によって成果物の品質が保証されるわけではありません。開発者によって同じ時間内でも成果物の差が生じることがあります。

折衷型契約の意義とその特徴

折衷型契約は受託開発契約とラボ開発契約の折衷案として採用されます。この契約形態では、成果物の定義を柔軟にし、一定の作業時間も確保しながら、基本的にボトムアップ型で開発を進めていきます。オフショア開発においては、ビジネスモデルやクライアントの要求を理解し、中核的な開発人材(例えば、ブリッジエンジニア)を確保することが重要です。中核的な人材はクライアントのビジネスについて深い洞察を持ち、長期的な関係を築くことができます。このような中核人材をラボ契約で時間拘束的に確保し、プロジェクトが大型化したときはスポットで追加の受託契約を行い、人を追加で確保するというものです。

折衷案に収斂していく実際のプロジェクト

受託開発としてスタートしたプロジェクトでも、ラボ開発としてスタートしたプロジェクトでも、ベトナムでのオフショア開発が成功し長く続いている案件は、最終的に折衷案に収斂していく傾向があるようです。多くの場合は海外開発拠点は、日本の開発プロジェクトの外付け工場という位置づけになりますので、クライアントのビジネスをよく知った開発者を確保しつつスケーラビリティを確保するという両方が求められることとなり、このような形に落ち着くのでしょう。

もしこの形をゴールとするのならば、下記の2点に注目するのが良いでしょう。

(a) 長期契約が必要なこと:クライアントのビジネスモデルや独自の用語を理解し、本当に重要な要素を把握するためには時間が必要です。クライアントのビジネスに寄り添いながら開発を行うためには、最低でも1年以上の長期契約が必要です。

(b) ブリッジエンジニアを始めとする中核的人材の確保が大切であること:中核的な開発人材は、クライアントのビジネスをよく理解し、ビジネスの要件に応じて開発を進めることができる人材です。彼らは長期的なパートナーシップを築き、クライアントのビジネス成果に貢献します。そのため、オフショア開発においては、ブリッジエンジニアなどの中核的な人材の確保が極めて重要です。

オフショア開発においては、契約形態の選択とビジネス戦略の統合が成功の鍵となります。ビジネスの長期的な視点と中核的な人材の確保を重視することで、効果的なオフショア開発を実現することができるでしょう。

続きを見る >

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黎明期からの導入支援経験をもとに、技術とビジネスの橋渡しを支援している。

続きを見る >