システム開発の話

| コメント(0) | トラックバック(0)

久々に仕事ネタでも書こうかと。

受注型のシステム開発、カスタマイズなんていう仕事を
かれこれもう10年以上やっているのだけど、
その経験や現在進行中のプロジェクトをやってる中で
私が個人的に思ってること、感じたことを書いてみる。


○もっとも重要なのは要件定義

何をつくればいいのか、という開発の動機であり最も根本。
ここがしっかりしてないと大抵のプロジェクトはガタつく。

ただ、お客さんも“本当につくって欲しいもの”のイメージを
要件定義の段階で持っていないことが多いから面倒。

そこでキモなのは、システムを使って何をしたいのか?
ということをお客さんから聞き出すこと。

既存システムのリプレースの場合は
何を改善したいのか、何を効率化したいのか、ということ。

そこが見えてくれば、お客さん側と開発側とで、
一致した最終形のイメージをしやすいのではないかと。

システムは、“仕様ありき”ではなく“要件ありき”だ。


○材料をケチるな

HDDやメモリの容量をギリギリに見積もったり、
CPUも一番良いのではなく2番目か3番目だったり、
DBサーバとバッチ処理のサーバを同じ筐体にしたり、
冗長化やDMZの設置を省略したり…

それで開発段階はまだ良いけど、実運用の段階で
そのケチったツケが回ってくることになる。

開発費用を抑えたいという気持ちはわかるのだけど、
後々の保守コストを考えたときにどちらがお得か。

あと、ソフトのチューニングにコストを割くよりも、
ハードで解決できるならそうした方が安上がりなことも多い。

最近は昔ほどハードも高価じゃなくなってるんだから、
予算が許す限り、下手にケチるべきでない。


○基本設計を固めてから実装しろ

当たり前ですが…。これが意外と守られない。

製造、テストのフェーズになってから
基本設計が変わる、ということが多々ある。

2、30人規模のプロジェクトでその状態になると
経験上それはほぼデスマの始まりです。

プログラムの詳細設計は良い。どうでも良い。

…いや、どうでも良くはないけど、
プログラム設計は開発者の機転で何とでもなるところで
最近のRADフレームとか簡易なスクリプトをもってすれば
ちょっとしたルーチンや構造の変更ならどうにかなる。

しかし、基本設計はダメ。変えちゃダメ。

そこが変わると、システムの設計思想が変わるので
多大なバグを埋め込むことは必定。

基本設計が変わるということは
大抵、要件定義がしっかりしてないということなので
一番最初の話に戻る。

そこはお客さん、実際のユーザ、開発者の全員で
しっかりレビューしてガッチリ合意したものにすること。

その上で設計が変更となるなら、それは仕様変更なので
その分の費用と期間を別途請求すればよろしい。


○アーキティクチャ選択に先入観を持つな

Javaは遅い。.NETは遅い。VBはクソ!
C/C++は速い。WebならStrutsだろJK!
Perlは時代遅れ。PHP一択だよね!

まぁいろんな開発現場でいろんな先入観を見てきました。

大抵ひと昔前の話だったり、自分で使ったことないのに
世間でいわれていることを鵜呑みにしてたり、
何というか、その根拠が薄過ぎると感じることが多い。

Javaも.NETも、例えば5年前の視点で語っちゃいかん。
C++が速いか遅いかは書かれるコードによる。
Java F/Wの選択は要件による。Webサービス型ならAxisとか。
今スクリプト言語のスペックはどれもほとんど同じ。
レイテンシが問われるならスクリプトという選択はない。

例えば、C#は遅いからC++を選択、という場合、
C#でカプセル化されている処理をC++で自作することになる。
その自作部分がC#の実装よりも高速、高効率にできるか
というのは、それを実装するプログラマ次第。
当然、それをつくる工数というのも発生してくる。

アーキティクチャの選択を間違うと、
主にそれを実際に組むプログラマが不幸になれます。


○実質的な改善が伴わない反省会は無駄

土日も休みなし。週2、3度の徹夜なんて当たり前。

そんなのを勲章のように自慢するエンジニアもいますが、
むしろ、何故そうなった?と問いたいわけで。

しかし、よくある形だけの反省会とか必要ないです。

レビュー不足とか、コミュニケーション不足とか、
テスト不足とか、最後にはリーダの力不足でスミマセンとか、
そんなの吐き出し合っても不毛なだけです。

分かってて、また同じことやるでしょ。

大きなプロジェクトが破綻する原因は、
要件定義が曖昧なために仕様がいつまでも固まらないこと、
そして開発ボリュームに見合わない短い開発期間、
私の経験ではこの2点であることがほとんどでした。

あとは、理不尽なお客さんに、理不尽な営業、PM。

お客さんはある程度しょうがないにしても、
開発陣内部にガンがいると痛いんですよね。

渉外担当なのに全然ブリッジ役を成してない人とか、
開発リーダーなのに技術的知識が皆無の人とか、
大規模プロジェクトになると大体仕事しないのが数名いる。

タチの悪いことに、そういう人ほど全く反省がない。
自分は悪くない。悪いのはヒトのせいだと思ってる。

本当の病巣ってのは、なかなか取り除けないもので、
それを理解させてやることのできない反省会は無駄です。
逆にいえば、もしそれができる反省会なら有効でしょう。


○プロジェクトのエクセル管理はやめてくれ

まぁ、これはケースバイケースとは思いますが
Excelでの課題管理とか進捗管理とかは
プロジェクトの後半で大抵陳腐化して破綻する。

中にはそれでしっかりやってたプロジェクトもあったけど、
管理方針(ポリシー)がしっかりしてないと、
課題が置き去りになったり、更新されなくなったり、
それをメンテする労力が必要以上にかかったりと、
本末転倒な状況になりやすい。

最近はプロジェクト管理用のツールもフリー、有料共に
いろいろあるんだし、そういうのを有効に使いましょう。

個人的には、手軽にスケジュールや課題を
複数のメンバ間で共有、管理できるというところでは
Webベースのトラッカーがお薦め。

総合ツールとしては Redmine マジオススメ。

BTSなら Mantis や Trac でもありだし、
wiki や xoops みたいなSNSツール使うのもありだし、
使えるツールは有効利用していきましょうということ。


○気力だけではシステムはつくれない

修羅場になればなるほど体力もモチベーションも下がるし、
そうなると開発のミスも多発して悪循環になりやすい。

どうも忘れがちだけど、自らも含め開発してるのは人間です。
人間は生物です。生物は活動し続けると疲労するものです。
物理的にそれは避けようがないです。

どんなに状況が逼迫していても、休むことは重要ですよ。
公式に休めないなら、仮病でも使ってサボるべし。

まぁサボるにも限度はあるけど、
疲れていると感じるときに体を休める為のサボりは
むしろ必要なものだと思いますね。


…などと、今は思ってます。
(数年後はどう思ってるか。思い出すとき用に備忘録)

トラックバック(0)

トラックバックURL: http://sphere42.mlexp.com/mt5/mt-tb.cgi/2829

コメントする

2018年2月

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28      

アーカイブ

Powered by Movable Type 5.2.10
MLEXP.サイト内を検索
Loading