上流工程やUMLの勉強が必要な理由のひとつは大規模システム開発が関係か

最近仕事内容的にSEの上流工程と言われる部分の勉強の必要性を痛感するようになってきました。

 

上流工程という言葉があるということは下流工程という言葉もあるわけですが、下流工程とは一般的には「プログラミング」とか「テスト」を指すと言われています。

 

対して上流工程は、「要件定義」とか「基本設計」と言われる部分を指します。ですから近頃は、上流工程の入門書とか要件定義、ソフトウェア文章作成術、UMLなどに関する本を購入して読み始めています。

 

以上のような上流工程に関する本を読み始めるようになったのですが、この分野に関する勉強が必要な理由として最初の頃は次のように考えていました。

 

「要はユーザーからの要望を正確に聞き取ってその中から必要な機能を取捨選択したりして、システムに正確に反映させられるようにするために必要な知識なんだろう」

 

しかし、いくつかの本やインターネットで上流工程に関するサイトを読んでみると、どうやらそれだけではないように感じるようになってきます。もちろんそういった理由もあるのでしょうが、それ以外の理由のひとつとして

 

「大規模システムをつくるときに必要な知識になるから」

 

ではないだろうか、と考えるようになってきました。このことについて最近の考えを書いてみようかと思います。

SEの上流工程に対する世間一般と自分のイメージ

仕事が変わってからは、SEの上流工程の分野についてよく勉強するようになり、その分野に関して様々な情報を調べるようになりました。その中で、インターネット上におけるSEの方たちの上流工程に対する評判はあまり良くないようです。

 

というのも上流工程というのは、他の人と折衝をしたりするケースが多くなってくるので、コミュニケーションの上手さとか相手にいかに技術用語などをわかりやすく伝えられるかが重要になってくるからです。

 

これはまだ経験が浅いのでよくわからないのですが、一般的にSEとか技術系の職に就く人たちは他の人とのコミュニケーションが苦手な人が多いと言われており、そういった要因からSEが上流工程を忌避する人が多くなる理由のひとつとなっているようです。

 

その時の自分としては「そういうものなのかな」と漠然と考えていましたが、最近になってこの分野について考える機会が増えたというか、「なぜSEには上流工程の勉強が必要なのか」といったことも考えるようになりました。

 

そういった意識で日々勉強していると、様々な用語が目に入るようになってきます。例えば先に冒頭部分で書いた要件定義とか仕様書の書き方、ソフトウェア文章作成術、UML、データモデリング等、ExcelVBAを勉強していた時とは全く違う言葉です。

 

それらの言葉に関する本もちらっとではありますが、いくつか読んでみました。どの本もそれぞれの分野を勉強する理由について納得する理由が書かれています。その中でも印象に残ったのが「UML」に関するサイトで書かれていた理由でした。

なぜUMLを使うのか?

UMLとは Unified Modeling Languageの略です。日本語に訳すと「統一モデリング言語」となりますが、主にオブジェクト指向分析や設計のための記法の統一がされたモデリング言語です。

 

主にSEがシステムをつくる前の設計図を作るときに使われるようです。

 

この分野は最近になってからやっと少しずつ勉強し始めたので、自分から何か経験的なものを言えるわけではないのですが、ちょっと前にこのUMLに関して印象に残ったサイトを見つけたのでここで取り上げてみます。

 

それはオブラブというサイトなのですが、そのサイトには次のような文章がありました。

■ レベル1
プログラミングを始めてしばらくすると,動くプログラムを書くことがシステム開発だと誤解することがあります。完全な間違いではありませんが,仮に一人で書いていたとしても,プログラムの規模が3,000行を超えたあたりで壁にぶち当たるはずです。行き当たりばったりでコーディングしていたのでは見通しがたたず,つぎはぎだらけのプログラムになってしまいます。

 

これを乗り越えるには,自分の考えを整理することが必要になります。プログラムだけを見ていたのでは,どうしても視点が小さくなりがちです。このようなとき,プログラムをUMLで図解してみましょう。UMLはプログラムの構造や動きを図でとらえることができるため,見通しよく全体を目で捉えることができます。

最初この文章を読んだ時は「プログラミングというのはそういうものなのか」と驚きました。

 

自分はまさに「動くものができれば良い」と思っていましたし、「コードの行数の壁」なんてものがあるとは全然考えもしませんでした。まるで自分の考えが見透かされているような思いです。

 

でも言われてみると確かに「そうかもしれない」という気持ちもあります。というのも、最近は仕事で実際にプログラミングをしていくつかシステムをつくるようになってきたのですが、ただやみくもにコードを入力していくだけではあっという間に行数が増えてしまうのです。

 

以前は全然気にしなかったのですが、例えばちょっとした機能の追加でもすぐに行数が増えていくので「どこにどんな機能のコードがあるか」がわかりづらくなってくるのです。そういった状態になると細部まで目が行き届かず、自分が想定した動作をしてくれなかったり、テストで見落としが出てきたりします。

 

ですから、withステートメントを使ったり、重複するコードは共通化させたり、とにかくコードを見やすく、増えないような工夫をするようにはなってきました。

 

とはいっても、これが複数人で使うような大規模なシステムになってくると「今までとは何か根本的に違うやり方が必要になってくるのでは?」という考えも浮かんではきていました。そのような不安からいろいろと調べていて見つけたのが引用したサイトになります。

 

引用したサイトではさらに「30,000行の壁」も存在すると書かれており、ここまでくると一人で開発するのが難しくなってチームを組む必要性が出てくるようです。

 

要は、より多くの人により良いシステムを提供するには、コーディングだけの知識だけではなくて、全体を俯瞰的に見られるようにする視点が必要であり、それが「UML」であるということです。

まとめ

SEが上流工程を勉強した方が良い理由というのは、もちろんこれだけではありません。ただ、最近の自分の仕事内容から印象に残ったのが「UML」とか「大規模システムをつくるときに必要な知識になるから」といったものです。

 

このような「段階」があるのはおもしろく感じます。新しい何かを見つけて勉強して、その分野に本格的に進もうと思ったらまた新しい何かが見つかります。

 

以前は経理の仕事をしていて、とあるきっかけからExcelVBAというプログラミング言語の有用性に気づきました。そこからExcelVBAを勉強してプログラミングによってシステムをつくる仕事に就きましたが、そこでまた上流工程という分野に出会いました。

 

経理の仕事以前にも以降にも何度もこういった経験があります。その時は「えっ?まだ勉強しなければいけないことがこんなにあるの?」と否定的に感じていましたが、今は「おっ?今度はこっちの方に進めばいいんだな?」という風に肯定的に受け止められています。

 

なぜそのように考えるようになってきたかというと、企業同士で日々競争しているのと同様に個人同士でも日々競争しているからです。企業が他社の商品に負けないようにいかに良くできるか、いかに安く出来るか日々努力しているように、実は個人でもそういった競争に晒されています。

 

企業が努力を怠れば熾烈で底のない「価格競争」をしなければならなくなるように、個人でも努力しなければ利益の少ない長時間のきつい肉体労働をせざるを得なくなります。

 

この点については以下のような過去記事も書いています。

 

今の時代は年功序列とか上司からの承認とか当てにならないものはいつまでも待たずに自分でどんどん進んでいってしまった方が良いです。そっちの方がむしろ楽になってきます。特に新しい分野に進んでいけばいくほど。

 

これからも自分の知らない「段階」が待ち受けているのでしょうが、それが自分にどういったものをもたらしてくれるのか、どういった世界を見せてくれるのか、多少の不安もありますが期待もしているのです。

あわせて読みたい

こんな記事も読まれています

コメント