先日スノーレンジャー開発部隊ブログにて「プログラム開発」について話を振ってもらいましたんで．．．
基幹系アプリ開発からの視点になりますがプログラム開発苦労徒然話をしようかと思います。
（ちなみに話題の発端はこちらのブログです。http://sanyo-ind-blog.blogzine.jp/syk_shinki/2011/03/post_ca98.html）
当社基幹システムは開発言語にＣＯＢＯＬを使った内作プログラムの集合体。
内作ということで要件定義からＤＢ設計、実際の作り込みまで全てやります。
しかも大規模なシステム開発な場合でもひとりのＳＥで設計から施工（？）までこなしてしまいます。
システム開発って要件定義とＤＢ設計が仕事の８０％は占めていて、ここまでうまくいけばプログラム開発ってそんなに苦労しないものです。
つまり「何を作ればいいか」が決まってしまえば開発言語を問わずプログラム作りのはそう難しいものではないわけです。
ここでポイントなのが「全てが内作」「設計からプログラム開発、実装テストまでひとりのＳＥでやる」というところなんです。
地産地消じゃないですが自分たちで考え作り込みユーザーも社内にいるという特殊性が存在するわけです。
システム開発能力が社内にない企業であれば当然、パッケージシステムを買ってくるかベンダーさんにスクラッチ開発してもらうという選択肢しかないことになります。
これが厄介なんです。パッケージシステムは「パッケージ」というだけあり、標準的な機能を搭載していて自社にどうしても合わない場合は自社に合わせてプログラムを修正する必要が出てくるわけです。俗にいう「カスタマイズ」ってやつ。
．．．ベンダーさんと「要件定義書」なるものを作り、そこから走り出すんですが「要件」という呼び名からも分かる通り「何をどうする」「何をやるために何がいる」ということを厳密に定義することになります。
さて、「厳密」と書かせてもらったのは、この時点で厳密にしておかないとプログラムが作れないからなんです。
「よく分からないけど良いもの作ってよ」じゃプログラムは作れませんから。
よく聞く話。出来あがったプログラムがユーザーニーズに合わず使われない、動かないということがよくあるそうです。
これ、典型的なコミュニケーションロスが起こす問題と思ってます。要件定義が不幸にもうまくいかなったんでしょう。
お願いする側は言葉に出来たことを伝え、作り込みするベンダーさんは「言葉に表わせたこと」で作り込み。
私、ＳＥやって十余年。「全てを伝えられるわけじゃないし、全て聞けるわけじゃない」。
システム作りって経験上これに尽きます。
全てシステムを内作しているんであれば、聞き直して作り直す、そして確認してと簡単にやれるわけです。しかもＳＥひとりで設計からプログラム開発までやっていれば尚更。
プログラムレベルになると判断条件、パラメータなんていいますけどそこまできっちり決めないといけないわけで厳重に確認しないといけないパラメータも要件定義書に記載されていなければ安易にプログラマが判断して補完することもあるでしょう。というか判断しないと先に進めないんです。
社内で全てやっていれば実情も分かりますから余り細かいことを言わなくても何とかなることがたくさん有るなと感じることはプログラマの視点から見ても多々あります。
どうでしょう、かきぴーさん。
プログラム開発ってこんなところにむずかしさがあるんです。社内にプログラム開発スキルを持つってのも、この点からいうとメリットがあるかもしれませんよ。
ただ．．．「プログラム作成前のアルゴリズム考察は いかに想像してデータによる裏付けをしっかりやるかがカギなんですよね。」とブログに書かれてるように、「何するの？」ってのが決まらないとプログラマは手が動かせないっていう認識は正しいと私は思います。
これがあって初めてプログラム開発スキルが活きてくるってもんです。
うーん。久しぶりに真面目にブログ書いてみました。
「おいおい、そうは言ってさー」「そうそう、プログラム開発って大変よね」などのご意見、お待ちしております。
