予算ブレの原因

開発の変動要因

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

目標変化と予算

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

計画型開発法

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

柔軟な開発手法

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

まとめ

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

関連記事

技術的負債の返済方法

負債の本質

技術的負債には、設計負債やコード負債がある。金銭的な負債であれば借入金やマイナスの表記で数字化できるのだが、技術的負債においては数字化できないことがとても難しい点である。経営に関するほとんどのことは定量化や定性化が可能だが、たとえば企業創業者の発想する「野生の勘」を直接的に数字化できないように技術的負債も一筋縄では見える化しない。

設計時の対策

技術的負債の中でもコード負債については、システム開発の現場からよく発想されるリファクタリングや再構築などを行うことで比較的わかりやすい返済方法となる。知らない人が作ったプログラムや古くなったプログラムのバージョンなど、リスクを表現し対応することができる。何よりも最初の企画設計段階で負債が積みあがりにくい仕組みを考えることが大切である。

高負担な設計

技術的負債の中でも利息の高い負債が設計負債である。単体機能における設計であれば、モジュールごとの再設計によって返済が可能である。しかし、プログラムは複数のモジュールが絡まり合っていることがほとんどなので、複雑なオペになってしまう。また、稼働中のシステムにわざわざ再設計したプログラムを導入するリスクに対して、得れるメリットも少ないので見過ごされがちである。設計能力は例えば、紙というオブジェクトのメソッド(振る舞い)とプロパティ(保持する情報)を聞いて正しい答えが帰ってくれば多少安心であろう。紙の振る舞いは燃えるであり保持する情報は面積などがある。

根本的解決

しかし、技術的負債はこのように目に見えやすい設計負債やコード負債が致命的になることは少なく、やはりその上層でどのような指針に基づいてシステム運用がなされてきたか、また長期視点で一貫したメンテナンスを行うことが必要である。システムの維持には保守費用や運用費用を払っていることが多いと思うが、これだけでは将来の負債を減らしていくことはできない。やはり、鳥の目を持つITコンサルタントやITアナリストなどの役割を持つメンバーが必要である。

まとめ

ITコンサルタントやアナリストは、すぐに利益も生まない、経費を削減するわけでもないといったコストセンターとしてのポジションなので、あまり起用していない中小企業も多いようである。投資に対する効果が見えにくいのは、料理でいう香辛料と同じなのかもしれない。その少しの投資が未来を大きく変えることになる。IT技術は日進月歩で発展するからである。

続きを見る >

日本の技術人材不足とオフショア開発

セクション1: 日本のソフトウェア開発人材不足の背景

日本のソフトウェア開発業界は50年以上の歴史を持ち、多くの経験豊富なエンジニアが存在します。しかし、現在の日本では開発人材の不足が深刻な問題となっています。この人材不足は、企業が即戦力となるエンジニアを安価で求めるという要望に由来しています。そのため、日本の人材不足はしばしば「即戦力を安く求める欲求」として揶揄されることもありますが、この言い方には一面の真実も含まれています。企業が効率的な開発を行うためには、即戦力のエンジニアが必要なのは当然のことです。

また、この人材不足の問題は、単に日本だけに限ったものではありません。他の海外でも同様の人材不足が起きています。したがって、オフショア開発を検討する際には、都合の良い人材を海外で見つけることができるという考え方は一部正解であり、一部誤解とも言えます。

セクション2: 日本とベトナムのエンジニアの特徴

日本のエンジニアは、特にWeb関連のエンジニアにおいては、1990年代からのキャリアを持つベテランが多く存在します。そのため、文字コードやバイナリ、組み込み技術など、古いOSや低レベルの知識を必要とする開発においては、日本の技術者は強みを持っています。一方、新しいフレームワークや概念の習得には、国民性よりも年齢が影響を与える傾向があります。そのため、ベトナムのエンジニアは若さを活かして新しい技術を素早く学ぶことが得意と言えます。

また、コンピューター業界においては、上流と下流、低レベルと高レベルといった言葉が中立的に使われますが、この意味において日本は低レベル開発に向いており、ベトナムは高レベル開発に向いていると言えます。そのため、バランスの取れたオフショア開発を行うためには、日本のエンジニアのジェネラリスト的な能力とベトナムのエンジニアのスペシャリスト的な能力を組み合わせることが重要です。

セクション3: 日本とベトナムの開発手法の違い

日本のソフトウェア開発では、納期を守るためにウォーターフォール型の開発手法が主流です。アジャイル開発が概念的には取り入れられつつありますが、完全にアジャイルな開発プロセスを採用しているケースはまだまれです。一方、ベトナムのソフトウェア開発は、日本の開発手法と大きく異なるわけではありません。基本的には納期を守るためのウォーターフォール型の手法が一般的ですが、OSSの影響を受けて開発手法が変化しつつあります。

日本の開発現場と比較して、ベトナムの開発手法の利点は、新しいフレームワークや技術の習得において素早い反応性を持つことです。ベトナムのエンジニアは若く、学習意欲が高いため、最新の技術に対する理解が早く、柔軟に対応できるという特徴があります。ただし、ベトナムの開発現場においては、アジャイル開発の完全な導入はまだ一般的ではないことに注意が必要です。

セクション4: 言語の壁以外の考慮すべきポイント

ベトナムのエンジニアを活用する際に言語の壁を乗り越えるためには、円滑なコミュニケーションを図ることが重要です。英語がビジネスコミュニケーションの共通語となっているため、日本の企業がベトナムのエンジニアとのコミュニケーションを円滑に行うためには、英語教育の強化や翻訳ツールの活用などが有効です。また、文化やコミュニケーションスタイルの違いも考慮すべきポイントです。異なる文化背景を持つエンジニア同士が協力する場合、相手の文化に対する理解や尊重が求められます。

セクション5: 成功へのカギはバランスと柔軟性

ベトナムでのソフトウェア開発のオフショアを成功させるためには、日本とベトナムのエンジニアの特長を組み合わせることが重要です。日本のエンジニアはジェネラリストとして幅広い知識と経験を持っており、プロジェクト全体の管理や技術的な統括を担当することが得意です。一方、ベトナムのエンジニアはスペシャリストとして特定の技術に精通しており、新しい技術の習得にも素早く対応できます。

オフショア開発においては、開発現場のバランスと柔軟性が求められます。例えば、日本のエンジニアがジェネラリストとしてプロジェクトを牽引し、ベトナムのエンジニアがスペシャリストとして特定の技術領域を担当する役割分担が効果的です。また、現代的な開発手法を用いることも重要です。ウォーターフォール型の手法に加えてアジャイル開発の一部を取り入れるなど、柔軟に適切な手法を選択することが目的達成(コストダウン実現)へのカギとなります。

続きを見る >

効率化の誤解

目標設定の要諦

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

真のリーダー像

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

アジャイルの本質

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

部分最適の罠

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

まとめ

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

続きを見る >