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

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

旧館より 開発プロセス

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執筆者:


comment

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

関連記事

「名前」で呼んでいますか?

仕事、プライベートを問わず人をどのように呼んでいますか? TPOによりますが大きく分けると2つに分かれます。 1:「鈴木さん」「佐藤君」「田中ちゃん」(笑)と固有の名前で呼ぶ人。 2:「君(きみ)」「 …

リーダーには説明責任がある

リーダー『論』なんていう大げさな話題ではありませんが、数年前、ある上司と「リーダーとメンバー(特にサブリーダー)との関係」について話したことをふと思い出しました。  「目的を達成するために人を動かす必 …

「感謝の言葉を伝える」アクティビティ

少し前、グループでフリカエリとこれからの活動について、半日時間を取って、しっかり議論しました。 夜は、(それまでの活動が一区切り付いたこともあって)打ち上げをしたのですが、そこでちょっとしたアクティビ …

SCRUM BOOT CAMP THE BOOKを読みました

「SCRUM BOOT CAMP THE BOOKはいい本です!マネージャーも開発者もみんな読んでみてください!」で終わらせようと思ったら・・・ @yohhatu それでもいいけどw もうちょっとww …

テーブル設計の指針(備忘録)

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。 サロゲートキーとナチュラルキー 主キーの設定時に大きく2つの設 …

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