update it, Inc.社長のブログ

日本のソフトウェア産業に関わる人って、普通どの程度「ソフトウェア」について勉強しているのでしょうか？　こんなことを書くのも、職業プログラマの中にもあまりにも程度の低い、メンテナンス不能なプログラムを書く人が結構多いと感じるからです。

プレゼンテーション層(JSPとか)にごりごりロジックを書きまくる人。

クラス名や変数名に一貫性の無い人。

言語における「普通の」コーディング規約を知らない人。

インデントすら、まともに書けない人。

すべての処理をstaticメソッドで書き上げる人。

言語に標準で付いているライブラリを利用せずに、都度ロジックを自前で書いている人。

一度動いたら、自分の書いたソースコードの見直しをしない人。

意味を理解せずに、前の人と同じように書いているだけの人。

ソースコードのバージョン管理が出来ていない人。

ソフトウェアの技術動向に無頓着な人。

以前、SEとプログラマの対比をこのブログで書いたことがありました。私の持論としては、SEとプログラマの違いは職種の違いであって、上とか下とか関係ない、と思っているのですが、現状は違います。

その原因として、一般のプログラマのレベルがあまりにも低いことも原因のひとつではないかと感じます。

職業にするということは、プロフェッショナルなわけですよね。ところが日本のソフトウェア産業はプロフェッショナルを育てようという意識が希薄です。これではいつまでたっても日本のソフトウェア産業は世界に太刀打ちできないのではないでしょうか。

昨日のブログでは「なぜ上流工程を改善しようとしないのか？」というテーマで、開発プロジェクトを進める上で、みんなが最も改善すべきだと感じている課題は上流工程の問題なのに、それを改善しようと考えている人はあまり多くない、という話を書きました。そして今日は、上流工程を改善するにはどうすべきか、について考察してみます。

おそらく一番重要なのは、上流工程について「学ぶ」ことだと考えます。ここでいう「学ぶ」には２つの側面があると思います。

■システム開発というプロセスを学ぶこと

■ユーザの業務を学ぶこと

おそらく大部分の上流工程の設計者たちは、このどちらかに偏っているのではないでしょうか？　システム開発プロセスのプロです、という人はいます。またユーザ業務ならまかしておけ、という人もいます。でもその両方を十分理解して、最適な提案ができる人というのは非常に少ない、というのが私の実感です。

システム開発はバランス感覚が問われる、総合的な判断能力が必要な仕事です。システム開発プロセスを知っていても、ユーザの業務をきちんと理解していなければ必要な機能、不必要な機能の判断もできず、適切なリソース配分ができず、過剰な、もしくは使いにくいシステムとなってしまいます。一方でユーザ業務を知っていてもシステム開発プロセスを理解していなければ、度重なる仕様変更を繰り返し、プロジェクトを疲弊させ、最終的にはプロジェクトを失敗に導いてしまうことにもなりかねません。

この問題を避けるためには、まずは「学ぶ」ことが重要ではないでしょうか？　つまりユーザ業務を十分に知らないのであれば、それを徹底的に理解できるように学ぶこと、システム開発プロセスを知らないのであれば、それを徹底的に学ぶこと、何にも増して、まずは学ぶことが最も重要なのだと思います。

足りなかった部分を学ぶことにより、プロジェクトの様々な問題点・改善すべき点が徐々に見えてくると思います。その上で様々な方法論なりツールを活用すれば、鬼に金棒です。

私も何歳になっても、謙虚に学ぶ姿勢は大切にしていきたいと思っています。

TechTargetジャパンでプロジェクト管理ツール利用に関するアンケートを行った結果を公開しています。

これを見ると、開発プロジェクトを進める上で、最も改善すべきだと感じている課題は「不十分な要件定義(39.2%)」が突出して多く、続いて「頻発する仕様変更(18.1%)」となっています。

そうなのです。開発プロジェクトにおいて一番改善すべき工程は、要件定義や仕様変更を行う、いわゆる「上流工程」なのです。もちろんプログラミングやテストなどの工程で問題が出ることもありますが、でもそれも実は原因を分析してみると上流工程での結論に問題があった結果、それがプログラミングやテスト行程で問題が発覚した、というケースの割合が非常に多いのです。

でも不思議なことに、問題意識があるにも関わらず、その上流工程を改善しようと考える人はあまり多くありません。なぜなのでしょうか？

上流工程を別のチーム、もしくはベンダがやっていて、そこに対する不満がある、というケースも考えられます。この場合には不満を持つ人と実際に実施している人が異なるので、なかなか問題意識が実施している当人たちに伝わっていない、というケースもあるかもしれません。

もう一つの可能性としては、上流工程を改善するといっても具体的にどうしたらよいのかがわからない、ということも考えられます。いろいろな手法、ツールなどがあるのですが、どのような方法をとったら実際に良くなるのかがはっきりしない、ということです。

プロジェクト運営の方法はおそらく各社各様、同じ会社内でもチームごとにいろいろと特色があって異なるのが実情だと思います。そしてあるチームでうまくいったからといって、ほかのチームでそのまま同じように適用してうまくいくとは限りません。

こういったプロジェクト毎の違いにばかり目を向けていると、全体として上流工程を改善するやり方が見えてこない、というのが実情なのではないでしょうか？

じゃあどうすべきなのか、を明日考察することにしましょう。（できるかな？）

通常、会社は期初に予算編成を行い、それに従って事業を進めるという形式のところも多いと思います。このような会社の場合、期初に予算編成をする時点で、全体の枠が決まってしまい、システム開発についてもその枠に縛りがかかることになります。

システム開発においてこの方法が問題になるのは、その期初に予算編成する際にはまだ要件が確定していない、ということです。要件が確定する前に金額がざっくりと決まってしまうので、本来はその金額の枠内に収まるように要件を固めていかなければなりません。

しかしシステムの受注開発の場合、要件を金額の枠内に収めるためにはどうすべきかについて、明確な手法はありません。システム開発を請け負う側が頑張ってできる範囲がすべて要件の範囲となってしまい、結果としてその「頑張り」はすべて末端のプロジェクト・メンバの負担へと転嫁されてしまいます。

システムを発注する側としては、金額の枠が決められてしまっているのは事実で、いきおい「金はこれしかないけど、なんとかなりませんか？」という話になり、それが上記のような流れでシステム開発の現場は常に忙しい、となってしまっているように思います。

この循環を断ち切るにはどうしたらよいのでしょうか？

ソフトウェア開発に関するデスマーチについて調べているうちに、デスマーチには敵がいることがわかりました。そうですよね。何か敵がいるから、デスマーチになるわけです。

でもどういうわけか、あまりその敵について言及しているものは少ない気がします。遠慮？　体裁？　人間関係？　仕事？　いろいろな要因が絡んでいるのでしょうが、デスマーチが如何にひどい状態かが書かれていても、その敵について詳しく書いているものはあまり多くありません。

でも何が敵なのかがはっきりしないことには、対策が打てるわけがありません。（でも上記のようなケースは、敵ははっきりしているのだけれども、対策が打てない状況を表している気もする）

ここで言う敵とは、デスマーチに至った根源的な原因です。もちろんその原因だけではなく、いろいろな要因が絡み合ってその状態になってしまうのだと思いますが、でも誰もが声には出さないまま、心の中では、「これは×××のせいだー！」っていうのがあるのではないでしょうか？

敵をあぶりだすことは、デスマーチを減らすための第一歩でしょう。

でもそれを声高に言えないという点に、デスマーチが起こるそもそもの理由があるのかも。目的をきちんと共有するなど、風通しを良くするための努力をしていれば、起こりにくくなるかもしれません。

工事進行基準のレポートを以下のリンクで公表します。

工事進行基準レポート

実際にプロジェクトを回す側の立場として、自分達が知りたいと思った観点から調査し、レポートにまとめてみました。

ソフトウェアベンダーの経営者やプロジェクト・マネージャの方向けに、できるだけ現場の立場で書いたつもりです。

なお、この工事進行基準ベースでプロジェクト運営を行うためのコンサルティングを実施しようと思います。詳しくはレポートの最後の方に説明を載せましたので、ご興味のある方はご連絡ください。

工数を求める際、一般には「何人月」とか「何人日」といった単位で工数を求めることが多いと思います。これは対象の仕事の担当者だったら、どのくらいの期間でタスクを完了できるのか、という見積です。一人の人がすべての仕事をしている場合には、単純合計すれば全体のタスク量になることは明白ですよね。

でもこれが2人の人が担当する、という話だったらどうでしょうか？　例えば2人のプログラマー（Aさん、Bさん）が同じアプリケーションを作っていて、Aさんが担当の機能をBさんが利用しているような場合には、Bさんの都合でAさん側の機能の見直しをお願いする、なんてことは日常茶飯事に発生します。こんな場合にも、AさんとBさんで話し合って決めるための（コミュニケーション）時間や、BさんによってAさんのタスクが中断する時間、BさんはAさんが空くまでBさん側の該当するタスクを止めなければならない時間など、いろいろなオーバーヘッドが発生することになります。

1人で順次こなしていく場合に比べ、上記のオーバーヘッドが余計にかかるので、一般には1人で2人月かかる仕事を2人でやったも１ヶ月では終わりません。これがきれいに成り立つのは、2人の間のタスク間に互いに依存する部分がなくて、そのまま突っ走れるような仕事の場合のみです。

でも不思議なことにプロジェクトの見積を行う場合には、そのタスクを何人でやるか、ということをあまり気にせずに、何人月とか何人日だけで換算していると思います。これは上記のようなオーバーヘッドが実際にはどの程度なのかが見積もれないために、とりあえず無視しているからでしょう。

確かに2人程度ではそのようなオーバーヘッドはあまり大きくないと思いますが、これがもっと大人数で、しかも互いに絡み合っていたら、どうなのでしょうか？　当然このオーバーヘッドが非常に大きな値になってくるのは想像できますよね。

複雑な、絡み合ったものを対象とする場合、100人の人が1か月でできる作業量は100人月、1人の人が100か月かかってやる作業量も100人月ですが、実際にできることがどれだけ違うかはすぐ想像がつくと思います。おそらく後者の方は前者の数十倍の成果物をつくり出せるでしょう。逆に前者は出来上がったものの、使い物にならない代物になっている可能性すらあります。

上記の例は極端ですが、実際のプロジェクトでも同じようなことが良く起こっているのではないでしょうか？　もちろん実際のプロジェクトでは限られた時間の中で成果を求めらるので、やっぱり多くの人を投入せざるを得ないのですが、もし時間が許すならば、むしろ少ないメンバーでじっくり時間をかけたほうが非常に経済的に仕上げることができることになります。

少数精鋭のチーム、いいですよね。

株式会社チェンジビジョンの平鍋さんのブログAn Agile Wayに「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログというエントリーが昨日載っています。

ソフトウェアの修正コスト曲線にみんな洗脳させられていて、要求を最初に決めてしまわないと指数関数のように変更のコストが膨らむと思いこんでしまって、それがウォーターフォールを強固なものにしてしまい、アジャイルというやり方に気付くのに時間がかかってしまった、という話です。

そして結びの一文が良いです。

— 引用 —
ソフトウェア開発の先輩たちが、みんなウォーターフォールを悔い改めようとしている。。。ぼくらも、いまの産業構造の中で「契約がこうだからできない」ということを言わずに、原則論から考えて、構造自体を変えて行くことをしないか？
— 引用終わり —

システムはつかわれてなんぼ、のモノです。使いやすいものを提供する、そのためには変化を受け入れていく。これが自然な姿だと思います。

しかし一方で来年度から始まるソフトウェアの受注開発での工事進行基準においては、契約前の要件のＦＩＸが求められています。要件をＦＩＸするまでは開発をするな、と。これは上記のような観点とはある意味、真逆の方向を強制しています。

ただし工事進行基準も仕様変更を認めていないわけではなく、変化に合わせて仕様変更を重ねていく、というやり方はできるのかもしれません。おそらく米国ではすでに工事進行基準になっているはずなので、アジャイル開発ではどうやっているのか、調査してみたいですね。

ちょっと前に工事進行基準の話に触れましたが、正直なところ、実務的なところがまだよくわかっていません。特に

■赤字プロジェクトの予定見積総原価の見直しはいつ行う？

■仕様変更による収益の変更管理はどうすべき？

などなど、実際にやってみないとよくわからないことだらけです。

仕様変更は、あらかじめバッファというか費用のプールを用意しておいて、期間内で発生する仕様変更をそのプールから取り崩して行う場合が多いと思いますが、その場合でも1件1件きちんと収益管理していくことが求められそうです。現場はその都度正確な見積もりを作って計上し、管理していかなければならないので、これだけで大変なことになると思います。

また要件のベースライン管理も重要になってきます。どこまで要件の範囲か、ということをきっちり詰めなければならないからです。

こうなってくると、要件に対して実現(実装)方法がいくつか考えられるような場合、お客様にとって一番良い解決方法を探る、ということがやりにくくなったように思えます。やりたいこと=要件に対してその実現(実装)方法は1つではありません。それを要件定義段階で事細かに指定しなかった場合には、たとえ多少難がある場合でも要件を満たしてさえいればそれで押し切ってしまう（お客様からみれば押し切られてしまう）ケースが多くなるのではないでしょうか？

結局、システム開発においては準委任契約で行える上流工程の比重が増し、単なる開発工程が圧縮される形になるのかもしれません。

またこの形態が一般化すると、開発工程のオフショア化が一層進展する可能性もあるかもしれません。日本国内では準委任契約の工程のみを行い、開発工程はオフショアで行う、といった感じです。今まではオフショア開発で行う場合、いちいち事細かに要件を定義しなければその通りに作ってくれないという部分があったと思いますが、これからは国内でもそうしなければならなくなる、ということになり、国内での開発メリットが低下することが予想されます。

一方で、受託業務ではアジャイル開発はかなり難しくなりそうですね。研究開発的な要素の大きい自社のパッケージ開発のような場合でないとアジャイル的な仕事の進め方はできなくなってしまうのではないでしょうか？

いずれにせよ、いろいろとインパクトがありそうですね…

設計書を書く際にいろいろな用途でExcelを使っている人は多いのではないでしょうか？　私自身、それなりに活用しています。私の場合には設計書そのものというよりは、周りの資料を作成するために使っています。

例えば、表ベースで仕様をまとめておき、その仕様を元に実際にアプリケーションを構築するための何らかの要素を自動生成する、という使い方をされる人は多いのではないでしょうか？　私も例えば、Excelシート上にデータベースのテーブルの定義を書いておき、それをVBAでDDLに落とすようなことをよくやってきました。

昨日ある方にお会いしたのですが、その方のところではかなりExcelをうまく利用しており、いわばExcelがマスターデータのような扱いになっていて、それを元にHTML化したり、データベース定義を自動作成したり、コントロールするためのXMLを自動生成したり、などといったことをやっていました。

設計書の一部が実際のアプリケーション構築のための元情報となるという考え方は、情報の一元化という観点で非常に効率的だと思います。Excelを使うというのは、こういったことを実現するのにExcelが一番手軽だ、ということから普及しているのでしょう。

設計書を扱うと言っている以上、crossnoteでもこの手のサポートをうまく考えていきたいと思っています。