満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
静的オブジェクト指向は設計者が苦労を背負込むシステム
2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店 みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。 Javaは経済的事情をうまく捉えて普及した プログラミングの効率と経済で書いていると
システムはソースをみれば解かる?
Ognacの雑感 木漏れ日々 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1487 記事 - 0 コメント - 45664 トラックバック - 143 書庫 2014年5月 (6) 2014年4月 (13) 2014年3月 (14) 2014年2月 (12) 2014年1月 (12) 2013年12月 (13) 2013年11月 (13) 2013年10月 (11) 2013年9月 (13) 2013年8月 (14) 2013年7月 (13) 2013年6月 (14) 2013年5月 (15) 2013年4月 (13) 2013年3月 (14) 2013年2月 (13) 2013年1月 (15) 2012年12月 (14) 2012年11月 (14) 2012年10月 (15) 2012年9月 (14) 2012年8月 (13) 2012年7月 (13)
開発スタイルの違い
日本のベンダーとの打ち合わせのときのことだ。 パフォーマンスが出ない件で、それについて議論していた。 ベンダーの開発リーダーと、私とアーキテクトとでのやりとりである。 開発リーダー「...という設計になっています。」 私「ということは、ここがボトルネックになっている可能性がありませんか」 開発リーダー「少々お待ちください」 電話をかけに行く。 暫くして、 開発リーダー「すいません。先ほどの説明は間違っていまして、ｘｘでした。」 アーキテクト「では、なぜここにキューが二つもあるんですか」 開発リーダー「ちょっと待ってください。」 また電話。 開発リーダー「ここは、担当者が換わったので、それぞれでキューを設けてたみたいで」 アーキテクト「なるほど。これは無駄ですよね。」 開発リーダー「そうですね。」 という調子で、説明も二転三転するし、確認の電話が多い。 うーむ。典型的な展開だ。 全体像を把握
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
「メインフレームにこだわると，技術が伝承されなくなる」——JTBの野々垣氏が警鐘：ITpro
「もし情報システムのオープン化に躊躇している現場があるならこう言いたい。メインフレームにこだわるな。一刻も早くオープン化に取り組めと」――。 JTB情報システムの野々垣典男氏（執行役員 グループIT推進室長，写真）は29日，都内で開かれたセミナーでこのように述べ，メインフレームに固執する企業に対して警鐘を鳴らした。日経SYSTEMS主催の創刊1周年記念セミナー「変化に強いシステム基盤の条件～ITインフラの最適設計を目指して」の基調講演で語ったもの。“脱メインフレーム”の最大の理由を野々垣氏は「システムを再構築するプロジェクトを敢行しなければ，ベテランのノウハウが伝承されない」ことだと強調する。 もちろん再構築の狙いは「技術伝承」だけではない。JTBでは1970年代に構築した旅行予約販売システムの再構築を，2002年から5年計画で進めている。その主な目的は，インターネット販売への対応や，各店
受託会社とソフトベンチャーでは、そもそもスタートラインが違う - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） さいきん、 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む http://blogs.itmedia.co.jp/repedant/2007/06/post_c660.html というブログが話題のようだ この議論自体は、１０年以上前だったとおもうけど（雑誌名が思い出せないし、資料が手元にないので、いった人ははっきり書かないけど）某会社社長が「受託開発は麻薬である」といったのと、ま、似ていると思う（ちなみに、コレは当時、受託とパッケージの両方をやっていた会社があり、当時の人は、どこの会社を批判したことか明確にわかる話だった）。 で、上記のブログのお話は、 （以下斜体はブログからの引用） １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受
MS、Oracle、IBMも本格参入？ 注目されるビジネスルール管理システム
「Microsoft、Oracle、IBMなどが、ビジネスルール管理システムに強く興味を持っています。今後、この市場が盛り上がることは必至です」と話すのは、Forrester Researchのシニアアナリスト、ヘンリー・ペイレット氏だ。BRMS市場の重要性と今後の展開について、フランス・パリのILOG本社で取材した。 ビジネスルール管理システムとは、ルール設定、変更、操作、管理を包括的に提供することにより、企業の業務プロセスを効率化するシステムと定義される。例えば携帯電話のキャリアの場合、「3年以上利用しているユーザーの場合、基本料を10％割り引く」などがビジネスルールである。企業のシステムはこうしたさまざまなルールが集まって構成されており、それがシステム内でいわゆる「ハードコード」（関連記事）されているケースも多い。そこで、BRMSによって、ルールとシステムを分離して管理することにより
デスマーチになるのは、プログラムが書けないからでなく、”おじさんの運動会”だからだ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） さいきん、これ どうしてプログラマに・・・プログラムが書けないのか? http://www.aoky.net/articles/jeff_atwood/why_cant_programmers_program.htm がはやっているようだ。 この文を読んで。。 あー、この書いた人がプロジェクトマネージャーになったら、開発はデスマーチ、プログラマは地獄だろうなと思った。 どうしてか。。を書く前に、まず、ここで話題になっている話を１つ （以下斜体は上記サイトより引用） ここでは、「Fizz-Buzz問題」というのを取り上げている。 それは、 1から100までの数をプリントするプログラムを書け。ただし3の倍数のときは数の代わりに「Fizz」と、5の倍数のときは「Buzz」とプリントし、
「何かと便利」な設計方針？ - 設計者の発言
データベースの「正規化崩し」の理由としてしばしば聞くのが「何かと便利なのでこのようにした」である。 たとえば、次のような関数従属要件があるとする。 これが、たとえば次のように物理設計される。 なぜテーブルＤやＤＦに、本来並ばなくていい項目がごそごそ並ぶのかと問うと、「これらを置くことで、関連テーブルを読まずに値が手に入る。プログラムがシンプルになるし、何かと便利だろうから」と説明される。 この種の設計の妥当性を吟味するためには、「継承属性」と「スナップショット項目」の違いを理解しておく必要がある。継承属性とは、あるテーブルから見て多重度１のテーブル上に載っている項目（テーブルＤから見ればＡ、ＤＦから見ればＡとＤ）のことで、インデックスを張るとか参照キー制約を組み込むといった明確な目的にもとづいて実装される。実装された継承属性については、もともと載っていた項目の値が変更されたら、すかさず値を
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
販売管理システムの「会計３要素」 - 設計者の発言
卸売業向けの販売管理システムは、ソフト技術者がシステム設計を学ぶためには最良の案件である。まず卸売業の企業数が多いということがその理由のひとつだが、もっと重要なのは、骨格が共通している点だ。個々の企業の特性に合わせて販売管理システムにはさまざまな違いが生じるが、基本的な骨格は同じである。 その骨格とは、筆者が呼ぶところの「会計３要素」、すなわち「仕入」、「売上」、「受払」だ。販売管理システムはこれらの要素を周到に取り扱って、その数字を財務管理システムに渡さなければならない。それらが集計される過程で企業の特殊性は捨象されてしまう。そういうわけなので、その骨格を正しく理解しておけばシステム設計はぐっと楽になる。武道において腰や腹の安定が基本中の基本であるようなものだ。 「３要素」のそれぞれを説明しよう。「仕入」は買掛残高、「売上」は売掛残高、「受払」は在庫残高をそれぞれ増減させる取引である。も
仙石浩明の日記: なぜ人月見積もりが優れているのか
人月見積りでは生産性が上がらない。 IPA が警告するまでもなく、 ソフトウェア技術者ならば誰しも 人月見積りに嫌悪感を持っているのではないでしょうか。 生産性を上げれば上げるほど金額が低くなってしまうし、 そもそも開発者の生産性なんて人によって大きく異なる (私の持論は、 「ピンとキリでは 1000倍の差がある」、です) のだから、 「標準的な技術者一人が一ヶ月かかる仕事」なんて基準をおいたところで 意味がありません。 人月見積もりについては、 「人月見積もり、生産性について」に いろいろな意見へのリンクがまとめられているので参考になります。 このように人月見積もりがなぜ問題なのか、 それこそ掃いて捨てるほど主張が繰り返されていますから、 いまさら同じようなことを唱えても仕方がありません。 そこで、ここでは逆にあえて肯定してみることにします。 そもそもこれだけ嫌われ者の「人月見積もり」が
無視されているソフトウェアの価値の見積 - 酔狂人の異説(新館)
ソフトウェア開発における見積と言うと、ソフトウェアの開発コストの見積ばかりが話題になって、それと同等に重要な見積が無視されていることが多い。それは、開発するソフトウェアの価値の見積である。ソフトウェアの価値がソフトウェアの開発コストより低ければ、開発するのは無意味である。ビジネスとしては有害ですらある。 ソフトウェアの価値を無視しては、本来開発コストの評価などできない。 また、ソフトウェアの価値を無視しているから、単に開発コストを減らすことしか考えられず、ソフトウェアの価値を高めること、価値の高いソフトウェアを開発することを考えられない。結果として価格競争に陥り、ジリ貧になっている。
ウォーターフォール型開発が失敗する理由 - 酔狂人の異説(新館)
ウォーターフォール型開発が失敗する最大の理由は、コミニュケーションの難しさにある。 開発が成功するには意図を正しく伝える必要があるが、意図が正しく伝わっているか確認するには出来上がったもので確認するしかない。仕様書に意図が正しく反映されている保証はない。「プログラムは、意図した通りに動くのではなく、書いた通りに動く」というように書いた内容と意図した内容とを厳密に一致させることは極めて困難である。書いた内容と意図した内容とが仮に一致したとしても、その仕様書を正しく読み取ることもまた同じくらい困難である。 「ウォーターフォール」という言葉自体が、コミニュケーションの難しさをあらわしている。下記のページに書かれているように、ウォーターフォール型開発のもととなったのは Winston W. Royce の "Managing the Development of Large Software Sy
過剰品質の美学 : 小野和俊のブログ
レクサスは半ドアでも走行中に自動でドアがスーっと閉まる。 スーパーで売られている卵は保存が良いように尖った方が下に揃えられているし、パックの中身を確認しなくても、卵が抜けたり割れたりしていることはほとんどない。伊勢丹では販売員は売場をお買場と呼び、コンビニでは弁当の胡麻の数までチェックの対象になる。箱ティッシュには指を入れやすいように小さなミシン目がついており、トイレに行けばウォシュレットがある。 求められている品質を満たすのではなく、 求められていない品質を目指す。 それが過剰品質の美学である。 そしてそれがITの遅れの象徴であるかのように指摘する人もいる。 しかし一方で、 自分たちはオーダーメイドという最高の過剰品質を提供しているのだと誇る声も聞こえてくる。 私はパッケージ製品を開発している立場の人間であり、 オーダーメイドのための最高の部品を提供することが私の目指すところだ。 知人で
「復活」果たしたITサービス業界がこの5年間で失ったもの：ITpro
法人向けのITサービスを提供するソリューションプロバイダが，久しぶりの業績回復を果たしている。 2002年2月から続く日本の景気拡大局面は，4年6ヵ月目に入り，継続期間では戦後2番目の記録を更新中だ。その中で，ずっと景気回復の波に乗り損なっていたのがITサービス業界だった。 しかし，主要ソリューションプロバイダ各社の2005年度決算（2006年3月までの1年間に迎えた決算を指す）は，「4年ぶりの復活」と呼べるような好調さを取り戻した。日経ソリューションビジネス誌が，売上高100億円以上のソリューションプロバイダを対象に毎年まとめている業績調査から，この5年ほどの動向を紹介しよう。 「業界の縮退」と「利益なき繁忙」の4年間 まず，2000年に起ったITバブル崩壊を受け，ITサービス企業の業績に陰りが見えたのが2001年度のことだった。当時の調査対象企業150社で見ると，平均の売上高伸び率はプ
Matzにっき(2006-07-11)
<< 2006/07/ 1 1. ミッフィー展 2. 弟家族 3. 冷蔵庫 2 1. 第一日曜日 3 1. [Ruby] Ruby on Railsトレーニング 2. 風邪 3. 地上波デジタル 4. [Ruby] るびま原稿 5. [Ruby] Web 2.0の挑戦者:プログラマフレンドリーなバグトラッキングシステム16bugs 4 1. [Ruby] トレーニング2日目 2. 六本木ヒルズ 3. [Ruby] Award on Rails 4. W-ZERO3[es] 5 1. 帰宅、校正 2. [Ruby] 「ブレイク直前のLinux」を思い起こさせるRubyのマグマ 6 1. [原稿] 『たのしいRuby』前書き 2. 「かわいそう」 7 1. 歯医者 2. Pickaxe2校正 3. 『情報処理』 4. [知財] Open Tech Press | 知的財産推進計画2006によせ
儲からないSIから“逃走”する企業とSIで儲ける企業のコントラスト
SIは儲からない。だから、ビジネスの軸をパッケージソフト販売や運用サービスに変える必要がある----これは、ITサービス会社のビジネスモデル変革の公式と言ってよいだろう。富士通の黒川社長も経営戦略説明会などの場で、よくそんな説明をしているらしい。そのココロは「できるだけ作らない」である。だが、トラディショナルな受託ソフト開発会社で高い利益率を上げる企業もある。さて、その辺りのことを、どう考えるべきか。 ITサービスのビジネスのプロセス順に、パッケージ販売、SI、運用サービスを横に並べ、縦軸に利益率をとると“ITサービスのスマイルカーブ”が描ける。なんのことかと言うと、両端のパッケージ販売と運用サービスは利益率が高く、真ん中のSIは利益率が低いので、曲線で結べば、スマイルマークの口元のラインのようになる。 富士通なんかは、ITサービス事業の収益力向上策の説明でこの図を使う。儲からないSIの比
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「レクサス」動かす1000万行――ソフトの品質を議論すべき時が来た【新連載】 ビジネス-最新ニュース:IT-PLUS
