システム開発の話

久々に仕事ネタでも書こうかと。
受注型のシステム開発、カスタマイズなんていう仕事を
かれこれもう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ツール使うのもありだし、
使えるツールは有効利用していきましょうということ。
○気力だけではシステムはつくれない
修羅場になればなるほど体力もモチベーションも下がるし、
そうなると開発のミスも多発して悪循環になりやすい。
どうも忘れがちだけど、自らも含め開発してるのは人間です。
人間は生物です。生物は活動し続けると疲労するものです。
物理的にそれは避けようがないです。
どんなに状況が逼迫していても、休むことは重要ですよ。
公式に休めないなら、仮病でも使ってサボるべし。
まぁサボるにも限度はあるけど、
疲れていると感じるときに体を休める為のサボりは
むしろ必要なものだと思いますね。
…などと、今は思ってます。
（数年後はどう思ってるか。思い出すとき用に備忘録）