(業務)システム開発入門

Agenda

• 開発の種類と業務システム開発
• 業務システム開発業界
• 業務システム開発は今後どうなる

開発の種類と業務システム開発

仕事として発生する開発の分類

ソフトウエア製品／サービスを開発する

AppleでiOSを開発する

AmazonのAWSで利用するサービス開発、など

組み込みソフトウエアの開発

家電メーカでのビデオ内蔵のソフト

携帯電話の中に組み込むソフト、など

特定顧客が使うソフトウエアの開発←ここのお話

顧客自身の業務遂行のために開発される

「受託開発」「ソリューション」などとも言われる

クイックに変遷など

古い時代はメインフレームなどと言われ…

多大な資金をかけてハードウエアを入手

メーカーや自社の多数のスタッフが開発し運用した

PC/オープンソースの台頭

ハードウエアの費用が激減、さらにライセンス料も激減

クラウドの台頭

もはや「受託開発はなくなる」とまで言われた

インフラよりも多彩なサービス提供がなされてきている点が重要

業務システム開発業界

どんな場面でお仕事が発生するのか

「PCは導入したけどなんか仕事が増えているぞ」

インターネット閲覧、メールの利用で止まっているユーザーは、中小企業ではかなり多い

「システムを導入すると売り上げが上がるらしい」

パソコンの使いこなしだけでは限界がある（たとえば、なんでもExcelなオフィス）

業務の改善をしましょう〜などとコンサルが煽る

戦略的なんとか〜みたいな言葉に踊らされる人はけっこう多い

「社員の誰も作れないのか？なら発注」

かくして、受託されて、誰かが開発する

業務システムのモチベーション

競争力の原動力になる

同業他社が「手作業」でやっていることを、IT化することで、売上増加や付加価値の増加

新規ビジネスの創出

限られた業者への卸売りから、全国への通販を実現

業務の効率化

徹夜で資料作りが、ボタン1つで終了へ

業務システムは誰が作るのか？

業務システムを請け負う業者さん

業者からの提案もあるかもしれないが、基本的には発注側が要望を出し、そのシステムを作るという仕事が発生する

「SIer」や「システムインテグレーター」という呼び方もされる

内製（エンドユーザー開発）

経営者が「いっそのこと、開発は社内でさせるべきでは」という考えの場合、社内の情報システム部門等で開発される

しかしながら、システム部門が業者に発注する場合があり、それは一般には「内製」とは言わない

エンジニアリング的視点

発注元（顧客）の要求がある

マーケティングで得られる要求ではなく、発注元特有の、極めて特殊な事情も含めたものが「要求」である

受注側は実装の責任を持つという考え方

かなりの高い割合で、「データベース」を使う

実装方法は受注側が選択できるので、「得意な手法」を使いがち

発注元の要求を満たす実装を行うのが基本であり、要求に基づくテスト等を計画して実施する

さまざまな開発モデル

ウォーターフォールモデル

要求定義→外部設計（概要設計）→内部設計（詳細設計）→開発（プログラミング）→テスト→運用

前工程に対応したテスト：単体テスト→組み合わせテスト→総合テスト

計画が必要なプロジェクトを客観的に進められる一方、前工程が正しい前提が求められる

スパイラルモデル

設計とプロトタイピングを繰り返す手法

アジャイルソフトウェア開発

適応重視の開発手法（誤解が多いのも特徴）

受発注特有の問題点

要求の変更

ビジネス環境が変わり、本当に変更することもあるが、…

変更というよりも当初は正しく伝わっていなかったということがよくある

要求の変更は、開発のやり直しが発生する。誰がコストを持つのか？

要求を正しく記述するには

発注元が協力的でないとかなりきつい

系統的な手法は存在するが、総じて聞き手の高いコミュニケーション能力が必要とされる

発注側も「現在の業務」を「論理的に系統立てて説明する」ことになり、かなりの労力が必要になる

多人数での開発

プロジェクトチームによる対応

1人で全てを行うこともあるが、チームでかかることも多い

有限の納期を考えれば、作業量が1人では難しいのが一般的

人数分に応じたパフォーマンスは出にくい

よくある話は、「進捗が遅いチームのてこ入れで人数を増やしたけど変わらなかった」

多人数でのパフォーマンス増大は難しい課題

一般には、「オブジェクト指向」のアプローチは多人数での分割作業に向く

要求や仕様があいまいだと、人数に関係なくなかなか収束しない

解決するためのアプローチ

契約重視の考え方

ある段階で、発注元と開発側で、開発結果に対する「合意」をすることで、開発側の責任を定義する

その結果、開発コストを見積もることができ、費用や納期の合意ができる

開発に入る前に作成する書類

RFP（提案依頼書）：発注側が作成

要件定義書：開発側が主体となって作られることが一般的

プロジェクトマネジメント

マネジメントの目標

期限内に予算内で割り当てられた資源を利用して顧客が満足する成果を出す

プランニングの視点

人的資源などをどう活用するかといった計画。Plan Do Check Actサイクル

リスク管理的視点

計画が遂行できなくなる要素の発見と対処

リーダーシップ論

組織マネジメント、開発のマネジメント

悲しい結果の数々

デスマーチ

プロジェクトマネジメントが失敗し、プロジェクトが破綻して前に進めない状態

長時間残業、休日出勤が重なり、スタッフが疲弊する

多大な労力を投下しても終了しそうにない状態

鬱病、行方不明者

突然、仕事を投げ出して、逃亡する（なぜかハワイに行ったことになっている）

開発という業務独特のプレッシャー、下請けや派遣といった労働体系の問題

末端のプログラマがプロジェクトの鍵を握るといった責任と階層の逆転

業界的な問題点

結局のところ営業しないと仕事は発生しないが、…

「営業はアホ！」と言い放つ開発陣

「開発の奴らは石頭！」と返す営業

結局のところ顧客は不満を持つ

顧客は多少とも「思った通りのものではなかった」「思った以上に費用がかかった」と思うものである

ベンダーロック

メンテナンスを他の開発業者にまかせられるケースは非常に少ない

受注側が意図しなくてもロック状態になり、不満を持つ

受託開発の崩壊

高い金を出した顧客が満足を得ていない

業界の構造的な問題か？　開発手法が未熟だからか？　他に理由があるのか？

得られるメリットに見合う費用なのかという点では、自由競争下では高い買い物に見える

2010年前後に受託開発の崩壊が言われる

デバイスやサービスが限りなく安価になり、人件費主体の受託開発経費の割高感が強まった

折しもスマホブーム到来、すわ神風！とばかりにそちらに移行した会社もある

新しい手法も登場

「納品しない開発」ソニックガーデン

緩い開発：Salesforce.com

業務システムの内製

比較的規模の大きな会社

一般には情報システム部門は、管理業務を行う部署という認識がある

いざ、内製をしても、業者とやるのと同じ問題は発生する。お金が動かないだけ、さらに問題は複雑かも

小規模組織での兼業

別の業務をかかえながらのシステム担当者になりがち

まとまった成果が出にくい可能性もある

業務システム開発は今後どうなる？

問題の本質は？

ソフトウエアは作ってみないと分からない

高い精度での予測、ボトルネックの発見と対処

要求は完全に伝達できない、完全に実現できない

予防的な仕様、ユーザーニーズに先回り

人件費が多大にのしかかる

開発作業の効率化、洗練化

プログラミングの話題がないぞ！

プログラムはしないわけではない

実装ができないと実現できないので、開発が重要なパートであることは疑いもない事実

プログラミングが中心ではない

コーディングは、業務システム開発の中では一部である

プログラミングを減らす努力

プログラミングには手間がかかり、時間や人手がかかれば、コストに跳ね返る

「品質の悪いプログラムは負債である」という考え方もある

クラウドが次世代のキーワード？

クラウドは業務システムのインフラとして注目

クラウドで新しい発注があるという考え方もあるが、むしろ、開発側の手札が増えたと考えるべき

思った以上に高コストである

スケール可能なメリットはあるが、ちゃんと計算すると、より高くなることは普通はわかる（分かれよ！）

「要求志向」の開発へ

顧客が満足しない業務はなくなる

受注側の業界は、「どうしようもない」などの消極的な理由で、改変を進めなかった

いろんな経済の波がある中、日本では受託開発が「安定かつ手堅い」仕事として長く君臨

しかしながら、開発結果とかかるコストの乖離が進み、発注が減ったのがここ数年の傾向

受託の目的は、要求の実現である

何を実現すればいいかという発想から、「なぜその要求があるのか」へと深める

エンドユーザーの参画による変革

開発プロセスが専門家しすぎていないか?

高度な訓練を受けた専門家しかシステムが作れないのだろうか？

そういう側面もあるが、だとしたら、「高価な買い物」しか存在しない

部分的な作業をエンドユーザーが実施

低い学習コストで習得できるスキルの範囲内で、開発作業に参画できることで、コスト構造を変革

例えば、開発は業者がしたとしても、メンテナンスはユーザーが行うなど

FileMakerが支持される理由の1つは、専門家でなくてもできそうな場面があるから

まとめ

• 業務システムとは、特定の顧客が自身の業務遂行のために利用するものである
• 業務システムの開発を受託する業者が存在し、SIerなどとも言われている
• ニーズは減らないが、御用聞き開発ではなく、満足度を高める開発をしないと生き残れない