概念モデルの方が楽チンなこともあるかも?の例
例えば土地と所有者の関係をモデルで表すとします。
で、土地には所有者がひとりしかないと思っていたとします。
モデルで簡単に描くとこんな感じ。
でも、上の図を描いてるときにお客さんから、実は土地に対して同時に複数（3人まで）の所有者を許すんだよ。とツッコミが入ったとします。
その際の変更はこんな感じ。
データモデルでは、土地に所有者が一人しか居ないと言う前提で土地に持たせてしまっていたので、複数の所有者を表現するには別途その関係を示すものを出して紐付ける必要があります。対して、この場合に限って言えば、概念モデルでは多重度を変えるだけでいい。
“なんとなくこんな感じ？”ってのをお客さんの前で確認しながら*1ライブでチョコチョコ直していく必要がある時に、概念モデルだと結構サクサクできると言うのはあるような気がします。その場で「えーっと」となる確率が低いような気がします。
データモデリングの場数を踏んでいるとどうとでもなるような事かもしれませんし、厳密性や整合性を求めるとそうとも言ってられないかもしれません。また、この例がたまたまそうなだけで、逆のパターンも往々にして存在するでしょう。
- 追記
依存非依存リレーションシップだけで書くとこうなりますが、多対多を使うと普通に書けますねー。
*1:モデルをそういう用途のものだと位置づけた場合
TDDやりたいけど出来ない場合
プロジェクト管理者が嫌がるケース
- テストケースをコーディングしていると余分な時間がかかる
- テスト工程が増えるだけだ（どっちにしろテストしないとダメでしょ？）
- 教育コストかかるじゃん。そんなことしてないでさっさと作れ
-
- 解決案
- どっかからメトリクスを出して効果を説得する
- スケジュールを変更しなくていいからとりあえずやらせてもらう
- テスト工程が増えるのではなく、本来必要なのだという話や位置付けをartonさんの記事等を元に説明する
- 開発者が各々の裁量でこそっとやり、既成事実を作ってしまう（土台から固める）
プレゼンでやっちゃいけないこと
時間内に終わらないこと。
プロジェクトマネージャーとかITアーキテクトとか言う前に
こんなことを書くと胡散臭く思われるのですが・・・・
先日、飲みの席でとある方が「ITエンジニアはモテないとダメだ。それくらいじゃないと誰もついてこようと思わない。」というような話をしていて、まさにその通りだなぁと同感しました。
プロジェクトマネージャーやITアーキテクトとして、うまく仕事を回していく中で最も重要なのはヒューマンスキルだと思っています。（ITアーキテクトも開発者をマネジメントすると言う意味では一緒だと思うので）
今まで私が一緒に仕事をしてきた中で、この人は信頼できると思ったマネージャーやエンジニアの多くは、結構モテてそうな気がします。モテるという言い方はちょっと極端かもしれませんが、少なくとも
- 色んな趣味や経験がある
- 話をしていると面白くて飽きさせない。
- ちょっとした事でも敏感に気がつく
ような感じの人が多いような。
人間的魅力のないエンジニアやマネージャーが、メンバーをうまく回していけるかどうかはちょっと疑問。なかなかマネージするのは難しいんじゃないかと。
若いエンジニアはいっぱい遊んだり恋愛すべきだと思います。その為には当然お金も必要になるので、管理職の方はITエンジニアにもっとたくさん給料をあげて欲しいものです。
#もちろん“優秀⇒モテる”でもないし、さらには“モテる⇒優秀”とは全く限らないので要注意ですが。
