サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

旧館より 開発プロセス

新規開発と保守開発に求められる要素の違い

投稿日:2008年4月16日 更新日:


システム開発の要素の1:新規開発(スクラッチ)2:保守開発(機能追加)があります。

#保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。

新規開発はその名前の通り「一から」システムを作り上げていき、生み出されるソースコードは全て新規で、バージョンもピッカピカの1.0です。
保守開発は既に稼動しているシステムに、新しく機能を追加したり既存の機能を改善するものです。

開発者にも新規開発、保守開発に対する得手不得手(適性的なもの)があるようです。
今回はこの新規開発、保守開発という2つの要素に、それぞれ開発者に求められることは何か?を書いてみます。

新規開発に求められる開発者の能力は何か?

1つは、要件仕様、外部設計に基づいてソースコード、機能を「生み出す」能力です。それは0から1にする感じで、その後の保守開発での1から5にするよりも色々なパワーが必要になります。
もう1つは、プログラムやシステム全体の統一感を持たすためにトータルコーディネート力といったバランス感覚みたいなものです。

保守開発に求められる開発者の能力は何か?

次に保守開発についてです。
新規開発(スクラッチ)とはまた違う意味でシステム全体を見る俯瞰的な視野が必要になります。
追加、修正したことで、既存機能が動かなくなり、ユーザが不利益を受ける状況は、避けなくてはなりません
そのため、修正箇所以外、できればシステム全体を完璧でなくても(薄くでも)広く知っておく必要があります。

もう1つは既存資産(ソースコードや環境周り)のどこを使えて、どこは使えないのか、またある程度修正することで流用できるか判断する能力です。

最後はその既存資産を有効利用する能力です。
2つ目の「判断する能力」と似ていますが、既存資産はメリット以外にも、過去のしがらみや既存の制約等ももたらすことがあります。
その中で、自分達のルールややり方を無理に押し通さず、既存資産の流儀に合わせるということです。
もちろん技術的負債を解消することも大事ですが、そのバランスを取りつつ進めていくというイメージです。

ある「やりたいこと」の実現方法はソースコードとしてはそれぞれメリット、デメリットを持った方法が複数あります。その状況で「こちらが得意」という理由だけで、システムの流儀からはみ出すと結果的にコストが大きくかかってしまったり、その後の開発のスピードにも影響が出てきます。
次にソースコードを読んだ人が、流儀に反したコードのため「なぜこうしたのか?」と背景が分からず、混乱を招いてしまい、その理解にムダなパワーを使うことになるからです。

どっちが良いとかでなく、その特徴を活かした開発をする

既存資産を使えるにもかかわらず、自分で一から組み上げた結果、既存資産との整合性が崩れてしまい、品質も悪く、保守性の低いものになってしまうシーンを時々見かけます。

逆に保守開発なら素早くポイントを見つけ、流儀に沿ったやり方で短時間で影響も無く仕上げるのに、新規開発を任せると、創造性の差なのか、ピタッとキーボードの指が止まってしまうシーンも見聞きします。

それぞれの特徴を考えて、適材適所でプロジェクトを進めていき、お客様や関係者はもちろん、携わるエンジニアもハッピーな気持ちで良い仕事ができるように意識したいものです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像:http://www.flickr.com/photos/raminf/2907291517/

-旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

自分のTwitterアイコンの変遷

Twitterアカウントのアイコンは干支をモチーフにしたものですが、元ネタはヨメさんが年賀状用に描いていたものです。 #コミュニティなどで使う個人名刺にも使っていて、名刺の作成は前川企画印刷さんのブロ …

嬉しい言葉「また一緒に仕事をしたいですね」

「またこのチームの皆さんと一緒にプロジェクトをしたいですね!」 システムのカットオーバーを無事に迎えたプロジェクトの打ち上げで、クライアントからこんな言葉をもらえるとすごく嬉しいものです。 こういう言 …

見える化

「可視化」と「見える化」

先日「プロジェクトファシリテーションパーティ2012」に参加してきました。 #参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました! 参加したセッション マルチセッション …

Redmineのチームでの使い方を紹介

Redmine Advent Calendar jp 2011の10日目になります。 私は(プラグインをガリガリ作ったりしてないので)「自分達のチームでの使い方」をいくつか紹介します。 コンテキスト …

社内勉強会

社内勉強会の難しさ

これまで(セミナーや読書会などの)社内勉強会をやったり、他社さんで社内勉強会のお手伝いをした中で、難しいところや思うところがあったので書いてみます。 ※注意:この記事は旧サウスポーなエンジニアの独り言 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。