ぺぷしのーげん

アプリケーションエンジニアによる雑記ブログ

ソフトウェア設計とは何か?設計にプログラミング経験は必要不可欠だ

f:id:hazakurakeita:20160429120932j:plain

「ソフトウェア 設計」でググると、トップに出てくるブログ記事に「開発プロセス」も「UML」が1度も出てきません。あり得ない。この国のソフトウェア開発の7割は失敗していると言われていますが、これもそれを表しているようです。今回はこの記事に対して反論というか補足できればと思います。

 

「ソフトウェア 設計」でググってみた

というのも、前の会社で開発プロセスについてコンサルに相談する機会がありまして。そこで、「まず君の開発プロセスの理解を教えて」と言われたんですね。なので当時の開発プロセスをそのまま伝えました。

  1. ユースケースおよびユースケース記述(要件定義)
  2. クラス図
  3. シーケンス図
  4. ユニットテスト実装
  5. コーディング
  6. シナリオテスト

これでフルボッコ。

  • ユースケースからどうやってクラス図を導き出すのか?
  • そのクラス図が正しいと何で判断して次に進めるのか?

ということでした。シーケンス図でクラス図のデバックをして、クラス図とシーケンス図を何度か更新して最適設計に近づけるという考えだったんですけど、コンサルに「開発プロセス勉強し直して来い」と一蹴されてしまいました。それでまずはググってトップに出てきた記事がこちら。

 

kuranuki.sonicgarden.jp

嘘やん…。

僕の開発プロセスのほうが断然高度ですね。これがググってトップな上に、

  • はてなブックマーク 580件
  • Facebookシェア 859件
  • Pocket 858件

と、反響も上々です。この国のソフトウェア開発現場はどうなっているのでしょうか…。

 

コーディングは全開発工程の5%しかない

開発プロセスの一般論として、きちんと開発プロセスをプロジェクトに適用した場合、全開発工数に対するコーディング(プログラミング)の工数は5%しかないと言われています。

  • プログラミングに付加価値はない
  • プログラミングに付加価値はないから外注、オフショアしろ

という考えは、あながち間違いではありません。しかし、これは開発プロセスを正しく適用した場合です。多くの企業や組織は開発プロセスを正しく適用していない、いやむしろ「開発プロセスってなに?」状態なので、話になりません。当然のごとく、外注やオフショア開発で失敗・炎上しています。彼らの多くは、5%のコーディング工数以外も外注・オフショアしているからです。(コーディング工数以外を外注・オフショアすること自体は間違いではありません。しかし、そこも含めてコーディングと呼んでいると問題が起きるのです)

 

設計が不可能なのは成熟度が低いだけ

f:id:hazakurakeita:20160506195826j:plain

UML クラス図: リファレンス

先ほどの記事に下記のような記述があります。

もし、変数名のひとつひとつ、アルゴリズムや処理の分割もすべてソースコードで表現する前に、なんらかの形で設計書として作ることが出来るならば、ソースコードにする部分だけをコーディングと呼んで、アウトソーシングすることも可能でしょう。

しかし、どう考えてもそれは非効率です。そこまで精緻な設計書を作れるとしたら、ソースコードを作る手間と変わらないはずです。むしろ、実際に動かすことが出来ない分、うまく作れないでしょう。

 うーん。著者はUMLを知らないのでしょうか…。これらの多くはUMLで記述できますし、アルゴリズムもフローチャートなど記述方法は多々あります。確かに、全てをUMLで設計してコーディングをアウトソーシングするのは非効率です。でもそもそも全工数の5%だけをアウトソーシングするのは非効率でしょう?それだけの話です。設計そのものを否定する理由になりません。

更には「そんな詳細な設計書を作るのは不可能」と言わんばかりです。不可能ではありません。もし不可能であれば、それは自身のスキル不足です。

 

なぜそんな勘違いを生むのか?

そこまで精緻な設計書を作れるとしたら、ソースコードを作る手間と変わらないはずです。

たぶんここの認識が誤っています。そもそもUMLを使って設計するということは、今までのコーディング工数を「UMLによる設計工数」と「コーディング工数」に分割するということなんです。

f:id:hazakurakeita:20160506200628p:plain

こんな感じ。コーディングしながら考えていたことを設計のときに考えてしまうので、コーディングの時間は大きく削減されます。コーディングしながらクラス構成や継承関係などを考えていると、視野が狭くなってしまうので、

  • あー、このクラスはこういう構成にしておいた方がいいな
  • あー、この継承いらなかったなw
  • なんでここFactoryパターンにしなかったのよ…

なんてことが後々起きてしまいます。そして手戻りが発生してコーディング時間が延びる。UMLならすぐに修正できますし、問題もすぐに発見できます。

 

だから設計にはプログラミング経験が必要不可欠

当たり前ですが、UMLでソフトウェアを設計するにはプログラミング経験は必要不可欠です。世の中には、

  • パワーポイントで書いたマンガ
  • 百科事典のようなエクセルの仕様まとめ

を設計書と呼んでいる人たちもいます。だからSIerと呼ばれるシステムインテグレーターでは平気で「プログラミングの知識がなくてもSEができる!」なんて言っているのです。でもこれ、設計じゃありません。設計とはクラス図やシーケンス図などプログラミングをUMLで表現するものなので、プログラミングの経験や知識は必要不可欠なんです。

以上から、僕はプログラマーとエンジニアを区別して呼び分けています。

  • プログラマー プログラミングができる人
  • エンジニア 設計とプログラミングができる人

プログラマーは設計を否定しがちです。そんなものは結局プログラミングすることと同じなんだから時間の無駄だと。それは成熟度が低いプログラマーの発する言葉です。

 

開発プロセスの答え

じゃあ結局最初の開発プロセスの答えは何だったんだよってことで、現在の僕の答えだけ載せておきます。

  1. ユースケースおよびユースケース記述(要件定義)
  2. 各ユースケースの振る舞い図(シーケンス図や状態遷移図等)
  3. 概念図(オブジェクト図等)
  4. 分析構造図(クラス図等)
  5. 分析振る舞い図(シーケンス図等)
  6. 詳細構造図(クラス図等)
  7. 詳細振る舞い図(シーケンス図等)
  8. ユニットテスト
  9. コーディング
  10. シナリオテスト

ですね。4~5を繰り返して分析モデル、6~7を繰り返して詳細モデルを作り出します。正確には分析モデルや詳細モデルを作成する際には、前工程で作成したユースケースやモデルとの比較などの作業も含まれます。

 

まあ、しかし、上記のプロセスすら適用できている組織ってのは極めて少ないようです。特に分析モデルを作るのは高いスキルを要するようで。僕もまだまだ修行中で、詳細モデルをまずはちゃんと作れるように勉強をしている最中です。皆さん、くれぐれも設計は無駄なんて情報に惑わされませんように。設計を省くというのは、開発期間やリソースが限られていて、かつメンバーの設計スキルが不足している場合のみです。まれに期間やリソースの問題で省くって主張もありますが、あれはただのいいわけです。スキルが低いだけですのでご注意を。僕も言い訳しないよう自分に言い聞かせています。

 

 

おしまい。