昨夜の関西IT宴会「２人の方法論者によるデータモデリング激レア対談」が開催された。 自分が後で読み直すために、殴り書きのメモ。 自分の感想も入れておく。 DOA屋さんから見れば、理解してないな、と思われるかもしれないが、気にせずに公開しておく。 ２人の方法論者によるデータモデリング激レア対談 - connpass ２人の方法論者によるデータモデリング激レア対談＜第62回IT勉強宴会in新大阪＞ | ＩＴ勉強宴会blog 【1】By 佐野さん オブジェクト指向は、ゲームや組込みシステムには向いているだろう。 しかし、業務システムのように、帳簿組織を起源に持つシステムには、オブジェクト指向は向かない。 帳簿組織の業務はデータモデリングすべき。 【2】By 佐藤さん 昔はT字形ERだったが、今はTMと呼んでいる。 中身は別物。 （注：その意味は、後述） （注：僕はT字形ERの本しか持っていないの

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。 ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。 以下は書きかけ。 【参考】 第0回：人月の神話とはなんなのか？（解説編）｜本気で読み解く”人月の神話” | GiXo Ltd. 第2回：銀の弾は無いけど、”銃”はあるよね｜本気で読み解く”人月の神話”（第16章） | GiXo Ltd. ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間 【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。 「過剰と破壊

Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。 チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。 【参考】 golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log Big Sky :: コマンドラインからredmineを扱える「godmine」作った。 【1】(引用開始) SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします. 面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....et

図書館で借りた「グロービスMBAリーダーシップ」を読んで、サーバントリーダーシップになぜ違和感があったのか、その理由が何となく理解できた。 以下ラフなメモ書き。 知っておきたいIT経営用語 - サーバントリーダーシップ：ITpro 明日を変える働き方：「サーバント・リーダーシップ」という考え方 (1/2) - ITmedia エンタープライズ リーダーシップ考（４）～サーバントリーダーシップ /戦略ノート２５/プロジェクトマネジメントＯＳ本舗 アジャイル開発への壁は価値観の壁: ソフトウェアさかば サーバントは革命の言葉。ビジョンを示せ！ - サーバントリーダシップ私論 - : ソフトウェアさかば 【1】サーバントリーダーシップでは、リーダーはサーバント(召使)であり、奉仕する→導くという順でリーダーシップを発揮すると言う。 でも、僕の中ではずっと違和感があった。 リーダーシップと言うと、

第39回IT勉強宴会に参加してきた。 大阪にDOAの一流モデラーが集まり、お互いのモデルを見せて、議論するというイベント。 聞いた内容を元に、感想をラフなメモ書き。 間違っていたら後で直す。 【参考】 第39回IT勉強宴会in大阪 : ATND 花束問題のしおり 花束問題V1.2 [#benkyoenkai] WHATとHOWの溝をモデルでつなぐ - 三要素分析法を考える -: ソフトウェアさかば 競演モデリング発表会＜第39回ＩＴ勉強宴会in大阪＞ | ＩＴ勉強宴会blog PHPメンターズ -> IT勉強宴会「競演モデリング」の感想 nmrmsysさんはTwitterを使っています: "今回もエコまっしぐら省エネ感想ブログをキメたw ”第39回IT勉強宴会in大阪 競演モデリング発表会” http://t.co/YNoSvkkT7x #benkyoenkai" 【0】花束を作る花屋の業

SIerはお客様の業務をIT化するのがお仕事なのに、自分たちの業務は意外とIT化しきれていない。 大量の印刷した紙、手作業の多い仕事に囲まれている。 ソフトウェア開発のインフラを考えると、最低3個の環境は必須だ。 一つは、ソースコード管理。 二つ目は、検証可能なビルド環境。 そしてBTS。 この3つについて考えてみる。 【1】ソース管理 プログラミングで仕事するならば、ソース管理(SCM)は必須だ。 ソース管理システムの本質は、前回のプログラムへUndoができること。 つまり、プログラムの履歴が残っているからこそ、前バージョンへUndo、Redoができる。 ソース管理は、MSならVSS、普通は、CVSかSubversionを使うのが普通だろう。 ソース管理で重要な作業はブランチやタグ付けができること。 ブランチは、枝分かれしたバージョンツリー。 タグは、ある時点でバージョン付けられたソース

astahを使って、T字形ERによるデータモデリング手法を解説した資料があったのでメモ。 これはすごくためになる。 自分なりの理解をまとめるためにメモ。 間違っていたら後で直す。 【元ネタ】 Twitter / akipii:凄く良い資料！dddosaka勉強会の人は必読でしょう笑 RT @hatsanhat: データモデリング入門ーastah*を使ってTMの手法を使う http://www.slideshare.net/mobile/inamiK/ss-36665472 … 大変親切にわかりやすく解説されています。 【1】T字形ERのデータモデリングをastahProfessionalのER図でどのように表現すべきか、を解説している。 非常に丁寧で分かりやすい。 個人的には、既存システムのリバース・エンジニアリングの設計技法を選択するとしたら、T字形ERが最強だと思っている。 既存の画面

「わかりやすいアジャイル開発の教科書」を献本して頂き、じっくり読んでみた。 アジャイル開発を実践する時に最初に参考にするガイドブックとして使えるのではないかと思う。 感想を箇条書きでラフなメモ書き。 【1】アジャイル開発が目指すものは何なのか、というWhyを説明してくれている。 アジャイル開発そのものを自己目的化しないためにも必要。 【2】ソフトウェアの価値とは何なのか？ この部分は、日本のIT業界が遅れている所だと思う。 理由は、受託開発案件が多いために、プロジェクトを納期までにとにかくCloseさせることに精一杯であり、納品したソフトウェアやシステムが顧客に役立っているのか、という観点まで頭が回らないから。 普通は、１次開発で赤字を出しながらも何とか本番稼動させて、２次開発や運用保守で、顧客の業務と実システムの不一致や、業務の改革まで目を向けるようになる場合が多いように思う。 本来は、

アジャイルサムライ著者のインタビューを読んで、心の琴線に触れるフレーズがいくつもあった。 感想をラフなメモ書き。 【元ネタ】 Jonathan Rasmusson さんインタビュー ( 前編 ) Jonathan Rasmusson さんインタビュー ( 後編 ) 【1】Jonathan さんが「アジャイルサムライ」を執筆した動機の一つは、アジャイル開発をコーチングや導入する時に使いたいためだったらしい。 というのも、新たな会社にアジャイル開発を導入する時には、7冊のアジャイル本を読んでから説明しなくてはならなかった、と。 ユーザーストーリー、計画、見積りについても10ページの説明で十分だ、と。 「アジャイルサムライ」の良い所は、アジャイル開発の概略を網羅的に知ることができる点にあると思う。 「アジャイルサムライ」はXPやScrumにも触れているけれど、XPやScrumを全て説明していると

第50回SEA関西プロセス分科会の放談会で話しながら、2012年末時点で、ITの地殻変動がどこに起こっているのか？を考えてみた。 ＃ラフなメモ書き。 【1】日本のSIもアジャイル開発を最近は積極的に取り入れようとする流れがある。 2000年代前半、XPをコミュニティ中心で実践したものの、日本のIT業界のメインストリームにならなかった頃に比べると隔世の感がある。 ニュース - NTTデータと楽天が共同でアジャイル教育コース作成、両社で180人育成へ：ITpro その理由は、欧米を中心にScrumを中心としたアジャイル開発が主流になったため、日本でも従来のウォーターフォール型開発にこだわらず、最新の開発プロセスを取り入れようとしたいからだろう。 だから、アジャイル開発が日本のソフトウェア開発の現場に合っているかどうかは、過去の経緯からして、まだ未知数の段階だろうと思う。 でも、リーマン・ショッ

DOAに関する技法で理解できた内容をまとめるために今後いくつか書き留める。 1回目は、情報無損失分解についてラフなメモ書き。 【1】DOAの基本はテーブルの正規化だ。 第1～5正規化まであるが、どのDOA本も無味乾燥で、本質的なことを書いていないように思う。 第3正規化で十分とか、関数従属性からどのように正規化していけばいいのかという手法まできちんと説明した本はあまりない。 また、正規化しすぎると良くないので、あえて正規化を崩す技法を勧める時もあり、正直分かりにくい。 特に思うのは、ほとんどのDOAの本の内容が20年前の時代のまま変わっていない気がすること。 そもそもDBサーバーの性能や価格も大幅に変わったし、DBMSも高機能化してオープンソースDBMSも業務系システムに十分に使える時代になったのだから、DOAの技法もどんどん進化していいはずだ。 OOAですら、UMLと絡めたモデリング手法

「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い

先日、DevLove関西でお会いした@papandaさんのご好意でアジャイルサムライDevLove道場に参加してきた。 「アジャイルサムライ」と同じく、ユーザストーリー洗い出し→バックログ作成→プラニングポーカーによる見積り→受入基準作成までのレシピで、とあるチームに途中参加させて頂いた。 感想を思いついたまま書く。 【参考】 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索 Scrumの見積りと計画づくりは何故優れているのか？: プログラマの思索 チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索 【1】途中参加したチームは、Androidで緩いタスク管理のツールを作るのが目的だったらしい。 ユーザストーリー洗い出しで、メンバーから案があまり出なかったので

ソフトウェア開発の初期コストと保守コストのグラフの良い記事があったのでメモ。 Miros?aw Jedynak - professional .NET blog: 6 steps to successful Continuous Integration (引用)それぞれの方法について，初期コストと維持コストの対比が提示されているところが印象的。感覚的だけど，このグラフは同意できる。 6つの観点の比較だが、経験的に非常に共感する。 この記事の主張は、「統合ビルドは重要！」の一言。 1. Use source code repository (引用)「SCM使えって当たり前だろ」と思いつつも，未だにOSのファイル共有だけってのもあるからなぁ。現実は小説より奇なりダ。 これは鉄板。SCM使う発想がない時点で，そのプロジェクトは終わってる。 非常に同感。 開発の現場は、教科書よりも奇なり。 SCM

astahにタイミング図がサポートされたのでメモ。 【参考】 astah* 9.2リリースノート | astah タイミング図 | astah* 機能ガイド plantumlでタイミング図が描けるらしい: プログラマの思索 astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索 astah* Mermaid Pluginが公開された: プログラマの思索 Timing図 わかりやすくUMLタイミング図とは 【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。 感覚的には、シーケンス図を横型にしたイメージを持っている。 ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べ

先日、アジャイルサムライ渋谷道場に行ってきた。 Velocityについて議論しているとき、速度という概念があるなら加速度みたいなものはあるのか？という質問があった。 そこから考えて、@daipresentsさんのBlogの意味がやっと分かったのでメモ。 間違っていたら後で直す。 ※追記：Focus FactorやTargeted value Increaseの定義も解釈も間違っているので、後日直す。 【元ネタ】 Redmineでアジャイルチームのスピードやパワーを見える化する | 世界 - @daipresents XP with Kanban instead of Scrum | Zsolt Fabo'k's Page InfoQ: ストーリーポイントは複雑さや時間と関係があるか？ 【1】Velocityとは、1スプリントでチームが開発できる開発規模(ストーリーポイント)を表している。