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

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

旧館より 開発プロセス

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執筆者:


comment

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

関連記事

ニコニコカレンダー

先日、チームのフリカエリをして、その時の(自分の)ネタに半年前から付けている「ニコニコカレンダー」を見てました。 「ニコニコカレンダー」の説明はこちらで。 私の今の使い方はデスクの卓上カレンダーにちょ …

こんなPMOはいらない

私のキャリアの中に、数年ですがPMO(Project Management Office)的な経験があります。 #PMOの役割や定義も組織においてまちまちなのですが…。 当時はそういう組織がなかったの …

会議の費用対効果

IDEA*IDEAのミーティングで使えるちょっとした話法いろいろを読んで会議の費用対効果について考えたことです。 会議の目的 一口に会議といっても、色々な種類や目的があります。 1:ディスカッションや …

チームへのRedmineの効果

Redmine Advent Calendar jp 2011の25日目になります。 #余談。本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。一方、 …

会社を移ることになりました

2012年6月末で会社を移ることになりました。 (何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。 思い出1:Rubyとの出会い 入社後しばらくして …

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