Asp・PHP・Vb・Javascript・oracle・ mysqlなど、エンジニア必須技術の最新情報や、あなたの技術をより磨くためのお役立ち情報が満載です。

編集者: たーとる | このブログのURL |この記事のURL

編集者: ぽせい丼 | このブログのURL |この記事のURL

編集者: satonaoki | このブログのURL |この記事のURL

ファイルまたはアセンブリ 'System.Data.SQLite, Version=1.0.63.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139'、またはその依存関係の 1 つが読み込めませんでした。

編集者: aspplus | このブログのURL |この記事のURL

編集者: ふも | このブログのURL |この記事のURL

クラウド大全 サービス詳細から基盤技術まで

• 作者: 日経BP社出版局
• 出版社/メーカー: 日経BP社
• 発売日: 2009/04/23
• メディア: 単行本（ソフトカバー）

クラウド化する世界

• 作者: ニコラス・G・カー
• 出版社/メーカー: 翔泳社
• 発売日: 2008/10/10
• メディア: ハードカバー

編集者: たーとる | このブログのURL |この記事のURL

編集者: づか | このブログのURL |この記事のURL

Hacking:美しき策謀―脆弱性攻撃の理論と実際

• 作者: ジョン エリクソン
• 出版社/メーカー: オライリージャパン
• 発売日: 2005/06
• メディア: 単行本

ファジング:ブルートフォースによる脆弱性発見手法

• 作者: Michael Sutton
• 出版社/メーカー: 毎日コミュニケーションズ
• 発売日: 2008/05/28
• メディア: 単行本（ソフトカバー）

編集者: たーとる | このブログのURL |この記事のURL

最近僕が意識しているのが、変化に強いシステムだ。近年のシステムはビジネスモデルの変化の早さに付いて行かなければならないため、システムの改変が多い。そうなると、今までのように「作ったらおしまい。後は二年に一度大きいリリースがあるだけ」のようなシステムはビジネスモデルについて行くのが比較的難しい。
さて、そうなるとどんなシステムが変化に強いのだろうか？僕なりに理想をまとめてみる。

■コード量が少ない
変化に強いシステムで外せない条件の一つとして、コード量が少ないという条件が挙げられる。コード量が多いということは、それだけ変化に合わせた修正箇所が増えるということである。また、修正箇所が多いということはコードを修正する際に影響範囲を調べるのに時間もかかる。
コード量を減らすという手法は昔から幾つもある。
例えば「サブルーチン」と言う、今で言う「ファンクション」や「メソッド」の位置づけに近い（？）ものだ。平たく言えば同じコードをあちらこちらに記載するのではなく一箇所に纏めて書こうというものである。
今でこそ当たり前の手法だが、N88-Basicのプログラミングを行っていたときに「サブルーチン」を知ったときは戦慄が走ったものだ。（僕がコーディングしていた時代は既に「サブルーチン」と言う手法はあったのだが、僕がそこに行き着くまでに時間がかかったのだ。なんせその時の僕は幼年期（小学生）だった上に、文献は分厚いリファレンスマニュアルだけだったので・・・。(*1)）

他にも僕が最近勉強しているCoC（Convention Over Configuration：設定より規約）と言う概念もコード量を減らすために一躍買ってます。
これは、何でもかんでも設定ファイル（XML等）で制御するのではなく決まりごとを作ってその通りにコーディングすることでコード量を減らすというものです。

コード量が減るということは、それだけシステムが単純化されているということにも繋がります。（纏まっていないシステムはコードが冗長になっていたり、継承関係がぐちゃぐちゃになっていたりします。）

■データモデルの変化に耐えれる設計

ビジネスモデルが変化するということは大抵においてデータベースも変化するということです。すなわち、動いているアプリケーションのスキーマを変更するということです。これを行うためには、既存のデータを消さずにスキーマを変える方法を考えなければなりません。

一番に思いつく方法がバッチでSQLを流してスキーマを変更させる方法です。

この方法はオーソドックスですが、いくつか欠点があります。

・開発者同士の同期をとるのが難しい。

開発者内部でもバッチを流したり、SQLを変更させたりするためどのバッチが最新であるかを把握することが難しい。（また、どのSQLは流してどのSQLは流していないという管理が比較的難しい。）

・差分管理ができない

プログラム管理で良く使われるCVSやSVNといったツールではSQLの管理が難しい。SQLの差分管理が出来てもそのSQLをスキーマに対して流したか、を変えたか変えてないかの管理が難しい。

僕が大きく直面した問題はこの二点です。

リリースされたDBの管理は比較的難しく、DBAも居ない状態が多いのでどうしても混沌としてしまいます。

そこでスキーマ管理をしてくれるようなツールがあるかと言うと・・・僕が知る限りではRailsのマイグレーションが思い当たります。（DBの知識は薄いため、他のツールをほとんど知りません。）

マイグレーション機能はバッチの履歴管理をしてくれます。どこまでのバッチを流したかをDBに情報として持っているため、開発者同士の同期がとれます。また、スキーマ更新（UP）とスキーマ更新取り消し（DOWN）があるためスキーマの変更履歴をプログラムと同様にとっておけます。

しかし、欠点もあります。それはテーブル数と比例して管理するファイルが増えてしまう事と、履歴の古いファイルの修正を行うとそれまでのスキーマ更新を全て取り消さなければならない点です。

僕の知っている限りでは、この点を解決するためにはプロジェクトで決めごとをするしかないかと思っています。

（Version毎にファイルを凍結させたり、変更した場合は一斉にDOWN→UPを行わせたり・・・）

現在の僕の見解では、スキーマの変更に強いシステムを作るためには上記のようなツール＋工夫をしなければならないということです。

後、初期の設計をある程度詰めておきスキーマの変更はカラム追加かテーブル追加以外が起こらないようにする方法がベストだと思う。

■体系化されたコードを書く

みんなバラバラなコードを書くとどうしても可読性が落ちます。そのため、先ほど記載したCoCの概念を取り入れる事やMVCモデルを使う、オブジェクト指向に徹する等の方法が考えられます。

これらの方法を使うことによって可読性の良いコード、すなわち改変し易いコードを書くことができます。

可読性の悪いコードは変更する時に他のコードに影響を与えるかどうかの判別が難しくなります。

ただし、これらの方法の欠点は開発者みんながどのように体系化されているかを知っている必要があるということです。

■情報の伝達をスムーズに

システム自体には関係ないのですが、情報の伝達が遅いと改変に時間がかかります。いくつもの組織が階層化されて入って開発を行う場合は、情報の伝達がネックになる場合もあるので理想は少数精鋭です。

僕が思うに、システム開発は大体において人が多すぎるのです。

僕自身の中でもまだ纏まってない状況で、模索している部分である。

情報社会が来ている今、ビジネスモデルの変化するサイクルが短くなることはほぼ間違いないと思っている。だから、このような考え方は重要なのではないかと僕は思う。

*1・・・今思えばよくあの頃にあの分厚い本を読めたなぁ。ちなみに、文献と言えばBasicとか言う雑誌からも情報を集めていました。買うお金がなかったので、もちろん立ち読み（苦笑）

編集者: 傲慢SE | このブログのURL |この記事のURL

僕が最近失敗したので備忘録的にここに書いておきます。

僕は見積もりで手を抜いてしまって非常に安価な見積もりを出してしまいました。すなわち、この後どんなに大変な仕事が待っていたとしても基本的には見積金額を変えることは出来ません。

今回の失敗は以下の点です。

お客様から仕事の依頼に対してアバウトな見積もりをしてしまい、どのようにでも取れるような見積書を作成してしまったのです。

その後にもう少し依頼の内容を確認したところ、、、実は見えない作業が発生していたのです。

僕はそれに気づかずに「●●機能　○円」のように機能全般的に受けてしまったのです。（実際はもう少し詳細に見積もっていますが、話を分かりやすくするために簡単な記述をしてます。）

そのため「●●機能」と言う括りの中で、僕の考慮していなかった機能が発生すると当然お客様には請求できません。つまり、僕が自己負担で仕事を引き受けるしかないのです。

仕事を受ける際に重要なのは、本当に必要だと思う項目を可能な限り洗い出すことです。そして、その洗い出した項目でお客様の合意を得ることが重要になります。合意を得た見積もりで機能漏れがあった場合は双方のミスになるため交渉の余地があります。

ただし、この洗い出すという作業が曲者なのです。見積もりを出来るだけ詳細に洗い出そうとするとその間にコーディングした方が早い場合が出てきます。そのような場合に見積もりが通らなければその見積もりをした時間は全てパァになってしまうのです。

この折り合いが僕としては難しいところだと思ってます。

最後になりますが、見積金額を途中で変更するということは基本的にやってはいけません。

これは、法的にどうこうではなく信頼関係にヒビが入ってしまうからです。見積もりを元に予算を組むので、途中で見積もり内容が変わってしまうと予算を組みなおす必要が出てしまうのです。すなわちお客さんに迷惑をかけてしまうのです。

なので、見積もりをおろそかにしてはいけないのです。

（僕のような技術者上がりは本当にこの点が甘い・・・。）

見積もりは現状では確固たる手法が確立されていないため、難しい仕事の一つだと思います。

みなさんも見積もりを行う場合には重々注意をしてください。

P.S.

ここには記載しませんですが、あまりにお客さんの事ばかり優先すると見積もりを出す方に煽りが来てしまいWin-Loseの関係が築かれてしまうので注意。

リクエストがあれば、この辺の事をもう少し詳しく書きます。

編集者: 傲慢SE | このブログのURL |この記事のURL