神々が見ている〜ソースのコメントは保守担当者だって見る〜
ギリシャの彫刻家フェイディアスの話だった。
紀元前４４０年ごろ、彼はアテネのパンテオンの屋根に立つ彫像郡を完成させた。
それらは、今日でも静養最高の彫刻とされている。
だが、彫像の完成後、フェイディアスの請求書に対し、アテネの会計官は支払いを拒んだ。
「彫像の背中は見えない。誰にも見えない部分まで掘って、請求してくるとは何ごとか」と言った。それに対して、フェイディアスは次のように答えた。
「そんなことはない。神々が見ている」〜P.F.ドラッカー：「プロフェッショナルの条件」より抜粋〜
私たちが作るソフトウェアは、ユーザからしてみれば、ユーザの要求どおりに動けばよいのかも知れません。ソースコードのコメントは、いくら書いてあってもユーザの目に触れることは無くシステムは動いてしまいます。
しかし、保守をする場合は違ってきます。
ユーザーからすれば見えていなくても保守をする側からすれば必要な情報です。
確かに、作成者と保守担当者が同じならば大丈夫なのかもしれません。
しかし、作成者と保守担当者が違うことなどよくある話です。
ソースコードにコメントが無いと、保守担当者は迅速な対応ができません。
それどころか、満足いく対応すら出来なくなってしまう可能性もありまし、いくら設計書があったとしても、設計書とソースコードのトレーサビリティ(追従性)が著しくさがるかと思います。
ソースコードのコメントを見るのは神々だけではありません。
作成者とは別の保守担当者も見るのです。
ソースコードのコメントをしっかり書くことは、時間やお金を掛けてでも非常に重要なのではないでしょうか。
ソースコードのコメントはユーザからしてみれば、必要ないように思えます。
しかし、コメントが無い事が原因で保守がうまく行かない場合もあるということを知っておく必要があるとおもいます。
そして、SEは、それをうまくユーザにも説明しなければならないのではないでしょうか。
フェイディアスはプロとして最高の仕事をしていた(しようとしていた)のではないでしょうか。
私たちソフトウェアエンジニアも最高のソフトウェアをめざして、また、全体的(最終的)なコストダウンを目指して、やるべきことをやる必要があるのだと思います。
※今回は、ソースコードのコメントに焦点をあてていますが、設計なども同じです。神々だけでなく保守担当者も見ます。
プログラマの数学
- 作者: 結城浩
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2005/03/24
- メディア: 大型本
- 購入: 41人 クリック: 707回
- この商品を含むブログ (387件) を見る
Executable UML
この本は、、、実は私も未だにほとんど理解できていません。
私が理解した範囲でまとめると、プラットフォームや開発言語に依存しない、実行可能なUMLモデルを書くためのルールブックのようです。
実行可能な図を描くためにクラス定義・属性・関連・ロールなどの細かい説明が書かれています。
どのような人にオススメか？
本書の裏表紙には中級車〜上級者と書かれています。
まさにそのとおりだと思います。入門者クラスの方が読んでもほとんど理解できないかもしれません。
ですが、あえて、入門者や初心者でも読んで見ても良いと思います。
私は入門者時代に読みました。しかし、それでも、参考になる部分はいくつかありました。
それに、初心者から中級者・上級者にレベルアップしたあとにもう一度読むことで新たな発見があるのだと思います。
ですので、オブジェクト指向開発に携わる人であれば、だれでも読んでみて損は無いと思います。
私がこの本から学んだこと
分析モデルと設計モデルの違い
この本では、MDAについても解説されています。
MDAは、モデルを作るだけでソフトウェアを作るというモノです。
ですので、MDAはPIM（Platform-Independent Model：プラットフォーム独立型モデル）、要するに機能を実現するためのモデルで実装に影響されないモデル を作ればソフトウェアが出来てしまいます。
また、MDAはPIMと実装の間にできる中間モデルであるPSM（Platform-Specific Model）
も定義しているようです。PSMとはつまり、実装に依存したモデルのことです。
このMDAの考え方をオブジェクト指向開発に当てはめると、ちょうど分析モデルがPIMで設計モデルがPSMとなるのだと思います。
ですので、この本を読むことによって、分析モデルでは機能をモデリングし、設計モデルでは分析モデル＋非機能をモデリングすればよい。のではないかという考えに達しました。
「分析モデルは静的なモデル」という言葉に惑わされてはいけない
私は、先輩や講師の方に「分析モデルは静的で動きを意識してはいけない」と散々言われてきました。
しかし、Executabl UMLを読み、MDAの考え方を知ったとき、「分析モデルは静的で動きを意識してはいけない」ではなく「分析クラス図は静的で動きを意識してはいけない」ということに気がつきました。
分析フェーズでも、コラボレーション図を描いて動作を検証しています。
つまり、分析モデルもやっぱり動かなければ意味がないのです。
静的に描くのはクラス図のことだったのです。
これに気がつくまでは、「なんで、静的モデルなのにコラボレーション図を描いて動作検証しているんだ！ 動的じゃないか！」と思ってました。が、講師や先輩が言っていた分析モデルとは分析クラス図だけを対象にしていたのだと思いました。
UMLによる オブジェクト指向モデリング セルフレビューノート
- 作者: 荒井玲子
- 出版社/メーカー: ディーアート
- 発売日: 2005/04/01
- メディア: 単行本
- 購入: 2人 クリック: 25回
- この商品を含むブログ (33件) を見る
オブジェクト指向を学ぶ上でUMLもセットで学ぶのが一般的なのではないでしょうか。
しかし、「モデルをUMLで書いたはいいけど、それが正しいのか分からない！」という人も多いと思います。
そんな人にオススメなのがこの本です。
オブジェクト指向開発の各プロセスで作成する成果物が、正当性を客観的に判断する指標が書かれています。
特にどのような人にオススメなのか？
入門者*1・初心者*2に向いていると思います。
さきにも書きましたが、「モデルをUMLで書いたはいいけど、それが正しいのか分からない！」という人にオススメです。
しかし、この本に書いてある指標も、あくまで一般論だと思います。
ですので、どのような場合もこれでOKだ！ということにはなりません。
それでも、入門者・初心者の方であれば、まずはこの指標に沿ってモデルを書くことにより、自分の書いたモデルに自信がつくと思います。
この本で私が学んだこと
正しいモデルの大まかな基準
この本に書いてあることが「絶対」ではないと思います。
それでも、具体的な指標があることによって、モデルを見て”なんとなく”ではあるのですが、良い･悪いを見分けることが出来るようになりました。
組み込みUML eUMLによるオブジェクト指向組み込みシステム開発
組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発 (OOP Foundations)
- 作者: 渡辺博之,堀松和人,渡辺政彦,渡守武和記
- 出版社/メーカー: 翔泳社
- 発売日: 2002/06
- メディア: 単行本
- クリック: 15回
- この商品を含むブログ (9件) を見る
eUMLのeはEmbeddedで、訳すと「組み込みUML」です。
これは、組み込みの現場に特化した開発手法をまとめた本です。
どのように要求分析〜テストまで行っていくのか、その一例がかかれています。
そのため、全体の概要を知ることができます。
また、組み込み開発においてどのようにUML・オブジェクト指向を活用していけば良いのかが書かれています。
そのため、組み込み開発でオブジェクト指向を取り入れた場合に、どのようにUMLやオブジェクト指向を利用すればよいかという点で参考になる本だと思います。
ただ、どの項目も説明が薄いように思いました。
ですので、各フェーズごとに特化した書籍もあわせて読むとより、理解が深まると思います。
オブジェクト指向は幅広く知識を必要とする技術です。
私の場合は、勉強する上での”とっかかり”になる本となりました。
どのような人にオススメなのか
オブジェクト指向入門者*1〜初心者*2の間にいる人・初心者・組み込み開発時のオブジェクト指向開発の方向性を知りたい人などの方々に向いているのではないかと思います。
この本では、各フェーズごとに関して深くは書かれていないため、オブジェクト指向の全体が良くわからないひとが、オブジェクト指向開発の全体像を知るのに役立ちそうです。
また、オブジェクト指向の流れの全体を読むことによって、自分がどの部分の理解が足りないのかが分かると思います。
それをきっかけに次の勉強ターゲットの指針に出来るのではないかと思います。
私がこの本から学んだこと
開発プロセス全体の開発の流れ
私が、この本を読んだのは、オブジェクト指向がどんなものなのか理解していなかった時期でした。そのため、全体の流れと成果物がわかりました。
ただし、開発プロセスは、すべてのプロジェクトに対応できるものではありません。
そのため、この本を読んだ当時に担当していたプロジェクトと、いくつものズレがありました。
ですので、「このやり方が唯一だ」と考えるのではなく、あくまでも参考にする程度がいいのかなと思います。
開発プロセスは、プロジェクトごとにカスタマイズしていくものだと思います。
分析クラス作成時にはDB設計知識が役に立つ
クラス図を作るうえで、情報（データ）が重要ということは聞いていたのですが、この本を読むまではピンときていませんでした。
この本では、分析モデルを作る方法のひとつとして、ドメイン（分析対象領域）にある情報をDB設計のように、第一正規系→第二正規系→第三正規系というように、情報を整理していきます。
そして、途中成果物として出てきたクラス図は「これ、ほとんどE-R図だろう！」といったモデルが登場しました。
このとき、オブジェクト指向分析を行ううえで、DB設計の知識は非常に役に立ちそうだということを理解しました。
※まぁ、もともとUMLのクラス図はE−R図を元に作られているので当然といえば当然なのかもしれません。
その後
資産は順調に減っています。
具体的には２００万を運用して３０万ぐらい減りました。
私の周りの人々からは、よく「やめたほうがいい」「危険だ」「運が悪い男だからやめておけ」といわれます。
確かに今は３０万減っています。
しかし、毎月の「ゲームセンターでの浪費」・「暴飲暴食」などよりも有意義のある出費と思っています。３０万払った代わりに、いろいろと知識の幅を広げる良い機会になりました。
「百聞は一見にしかず」これは、確かにそのとおりですね。まずはやってみて、そして困り、そこで何とかしようともがいた時にいろいろなことがわかる気がします。
これから先、資産がプラスになるよう試行錯誤します。
まずは、「目指せ資産１億円！」
