開発費用値下げの危険性

開発手法の選択基準

大がかりなシステム開発においては、ウォーターフォールモデルという開発手法がとられ、設計書などのドキュメント類も整理してから、プログラミングへ着手する。逆に中小規模なシステム開発においては、アジャイル開発と呼ばれ、プログラミングをしながらシステム開発が進められたり、ドキュメント類は簡易にして、プログラミング工程へ着手するといった方法がとられる。状況に応じて開発手法は使い分ける必要がある。

設計書の必要と課題

建築では図面なく建物を建てることはないが、中小規模のシステムについては簡単な概要だけでシステムの開発ができてしまう。もちろん設計書をしっかりと書いて、要件を詰めてシステム開発を進めることができれば、トラブルもなくていいのではないかと言われる。しかし、設計書を作成するにはシステムをプログラミングすることと同じくらい費用が掛かる。

設計書の粒度と要因

中小規模のシステム開発において設計書が簡易になってしまう理由は、ユーザー側や発注側の予算が乏しいという理由がある。建築のパターンの場合は、法律によって作成しなければならない図面や、施主から同意をもらうべき書類などが決められている。システム開発には法的に作成しなければならない書類が明確にされているわけではないため、この粒度が各社・各エンジニアによりバラツキが発生する。

文書管理の現状

中小規模のシステム開発において、最悪の場合は設計書がないケースもある。小さなプロジェクトの場合は予算も少なく特にドキュメント類がないが多くある。あるいは、システムはアップデートされ続けているのにドキュメントはアップデートされていなかったり、ひどい場合にはシステム保守ベンダーが紛失している場合もある。

まとめ

システム開発に時間がかかる理由は、設計書から作成することでプログラミング作業の2倍以上の時間がかかると言われる。いわゆる動作検証の工程まで入れるとプログラミング作業の3倍程度は時間がかかる。また、システム開発はほとんどが人件費である場合が多く、かかる時間に応じて費用が上がる。つまり、非エンジニアが単純に開発費用を値切ると、プログラミング以外の重要な情報を削っていくことになる。

関連記事

小規模AI導入ガイド

効果検証から始める

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

UI重視の効果測定

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

開発とAIの分離問題

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

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

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

まとめ

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

続きを見る >

内製化人材戦略

内製化の壁

システムの内製化が重要ということは、どこでも聞くと思う。しかし、具体的に内製化していくための段取りを整理して教えてもらうのは難しいのかもしれない。業種業態によって様々なケースが存在するからである。内製化を成功させるには、単に技術的な知識だけでなく、組織全体での戦略的な取り組みが不可欠となる。

経営コミット

システム開発の内製化を行っていくには、まず経営層からのコミットメントが必要不可欠である。これが必要であるから諸外国ではCRO(Chief-Revenue-Officer)という部門を横断した権限を持つ人を据えている。その上で、まず内製化の目的を明確にする。おおむねコスト削減、スピード向上、ナレッジ蓄積などであろう。目的がきまると、企画、開発、保守、インフラなどのどの範囲で内製化するのが見えてくる。組織全体での合意形成が内製化成功の基盤となるのである。

失敗回避策

よく聞く失敗例では、権限のないIT戦略室、デジタル推進部などを作ってしまうことである。あるいは、適切な人員の配置や育成がなされないパターンも同様である。大きな権限を持つことになることを前提に考えると、実施するプロジェクトについても小さなプロジェクトにおいて実績を積み上げたほうがいいだろう。たとえば、小規模低リスクである業務改善ツール(例:Power AppsやExcelマクロ)から市民開発を実施していくなどを計画することをお勧めする。段階的なアプローチが組織の信頼獲得につながる。

仕組み化

小さなプロジェクトで実績を積むと、こなれてきてしまうため、やはり属人化の危険性が伴う。ここで、いかに永続的に考えることができるか、内製化のための仕組みを構築できるかは、システム開発経験者などの知見のある人も交えて人材育成に取り組むべきである。定期的な振り返り(レトロスペクティブ)やナレッジ共有会、現場からの改善提案を吸い上げる文化を育て、仕組化していく。持続可能な内製化には組織文化の変革が欠かせない。

まとめ

開発基盤とガバナンス整備、ソース管理やドキュメント管理などの定性的な内製化は簡単に作ることができる。しかし、そのマインドや仕組み、自然とDevOpsをはじめとしたPDCAサイクルにもっていくには、システム知見だけでも難しくある。持続的な内製化にたどり着くためには最初の企画や構成段階で知見をもつメンバーを入れておくのがよいだろう。

続きを見る >

SEのいうバッファとは

バッファの真意

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

不確実なバッファ

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

知識の不足

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

本質のバッファ

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

まとめ

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

続きを見る >