アプリの情報を検索していると、たまにどうどうと、アプリをクラックする情報を載っけてるブログを見つける。
本当に、阿呆だなと思う。
虫酸が走る。
制作者に対する冒涜でしかないよね。
こういう奴らは、自分の部屋のモノが突然盗まれて無くなっていたり壊れていたりしたらどう思うんだろうか。
10日閣議決定された著作権法の改正案では、これを明文化。ただし、違法となる条件として、「配信コンテンツが違法であることを知ってダウンロードした場合に限る」としたほか、「個人レベルでの行為は軽微なため、罰則は設けなかった」(文化庁)。
罰則規定無しだと、全然意味ないよね。
路上喫煙禁止な条例が守られていない状況と変わらない。
違法である以上、罰則は必要でしょう。
とりあえず、これで、違法となる前にやめてくれるとうれしいんだけど。
「ニンテンドーDS」ソフトを不正コピーしたデータを利用できる機器「マジコン」の販売差し止めを任天堂とゲームソフトメーカーが求めた訴訟で、東京地裁は2月27日、業者に対しマジコンの輸入販売禁止と在庫廃棄を命じる判決を言い渡した。
購入して利用している人達にも何らかのペナルティが与えられたら良いのに。
結果的に、消費者の首をしめているという事に気づかないのかな。
たまに、「簡単に破られるプロテクトをかけているほうが悪い。」みたいな開き直りのような意見を見る事があるが、自分の部屋の鍵を破られて同じ事を言われたとき、「はい、簡単に破られる鍵をかけていた私が悪かったんです。」と言えるのかな。
結局のところ、運用・保守フェーズ前に稼げる金額なんてたかがしれています。
売上が10億あがろうが、コストが10億かかっていれば、利益は0です。
だからといって、運用に至るまでは運用するべきシステムを作成するために手を動かさなければいけません。
だからコストが0になる事はありませんし、見積もりが適正化されていれば、莫大な利益を上げるという事もできません。
比較して運用・保守フェーズの期間あたりの売上は開発フェーズに比べて微々たるものでしかありません。
しかし、運用フェーズはそれ以前のフェーズより圧倒的に長期間なことが多いです。
そして、運用・保守フェーズは何も問題が発生していない間はコストが0とはいいませんが、限りなく0に近くなります。
コストが0に近くなるという事は売上の大半が利益になります。
だからこそ、運用・保守フェーズをいかに円滑に送るかが重要になります。
以上の理由から、運用・保守フェーズをメインとして考える必要があります
管理しなくてはいけない項目をできるだけ減らします。
運用・保守フェーズにそれ以前のフェーズと同じ人が担当するとは限りません。
管理項目が多いと
1.読まなくてはいけない資料が増える。
2.資料をメンテナンスする機会が増える。
といったことにつながります。
ミスの発生する確率が同じだとすると、人が動けば動くほどミスの発生件数が増えます。
1.読まなくてはいけない資料が間違っている。
2.資料をメンテナンスする事を忘れる。
といった事も起こりやすくなります。
しかし、その読まなくてはいけない・メンテナンスしなくてはいけない管理項目が最初から無かったとすると人が動く機会が減りますので、相対的にミスが減ります。
また、動く機会が減るという事はそれだけコストがかからないという事になります。
複雑な事というのは、シンプルが積み重なる事で発生しますので、管理しなくてはいけない項目が少ないという事はそれだけシステムの理解がシンプルにできるようになるという事に繋がります。
管理する項目が減る→やるべきことが減る→トラブルも減る
という事です。
第2項で「管理する項目が減る→やるべきことが減る→トラブルも減る」と結論づけましたが、この行為は結局運用・保守フェーズだけではなく、それ以前のフェーズにも効いてきます。
やるべきことが減るわけですから、それぞれのフェーズに費やさなくてはいけない労力も減るわけです。
結果的に運用・保守フェーズをメインと捉えて考えた結果、システムのライフサイクル全体が最適化されるようになるわけです。
それは結局のところ、各フェーズの作業が終わった時から、その作業の成果に対する保守が始まっているからじゃないでしょうか。
つまり、システム開発は1歩進んだ時から保守が始まっているという事です。
だから、運用・保守フェーズに効く事は全体に効く事になるのだと思います。
追記:
なんでもかんでも、無理矢理減らせば良いという事ではなく、二重管理をやめたり、管理しなくても良い事も同じレベルで管理したりするのをやめようということです。
結構、ありますよね。
youtube.com YouTubeなら、無料でPVを見放題! お気に入りのPVを見つけよう。
サービス側が、このあおり文句を言ってはいけないのでは?
まぁ、確かにオフィシャルなPVもあるにはあるけど、そのスポンサーリンクからは、オフィシャルなもの以外もひっかかってくるんだよね。
O'Reilly Japanが発行する書籍を、これまでの紙媒体に加えPDFによる電子媒体でも販売いたします。可搬性と検索性に優れたEbook版を、ぜひご活用ください。販売タイトルは順次追加して行く予定です。PDFドキュメントを閲覧するには、お使いの環境に対応したAdobe Readerが必要です。
なんと、オライリーのEbook Storeに日本語版が登場したようです。
今はまだ24冊のみで、PDFでの提供ですが、これで重たい本を持ち歩かないでiPhone等で読む事ができます。
嬉しいですね。
というわけで、早速EBookで前からほしかったけど重いから買わないでいた
を購入してみた。
PDF自体は16MBくらいあったけど、Webからダウンロードしての表示であれば、ちゃんと展開してくれたので良かった。
ちなみに、PDF自体の内容を印刷する事はできず、コピペも出来ませんので、リファレンスやクックブックを購入する場合は少し躊躇するかもしれません。
私自身、社内のシステム開発用フレームワークを一人で設計・開発していて、ちょっと前までは、自分の参画するプロジェクトでのみ採用していた。
最近、私が参画しないプロジェクトでも採用するようになり、いろいろとサポートをする必要が出てきたのだが、その過程でフレームワークを理解するために最も重要な事というのが何なのかが分かったような気がする。
それは、
「フレームワークの機能に何があるかを知る」
事ではない。
勿論、フレームワークの機能を知る事で、ある程度フレームワークの能力を発揮する事が出来るかもしれない。
しかし、フレームワークの設計者が知っているであろう最適な使い方にはならないだろう。
だから、「まず最初にフレームワークの詳細な機能について知ろう」と思う必要は無い。
もっと大切な事を理解してからでも遅くない。
むしろ、その方が個々の機能について最適な使い方とセットで理解できるので有益だ。
では、何が最も重要なのかというと、
「フレームワーク自身が持っている思想を知る」
という事である。
どんな意図でフレームワークが存在しているのか。
どんな意図でフレームワークの設計がこのようになっているのか。
どんな開発手法を想定して作られたフレームワークなのか。
それを理解する事が最も重要な事であるように思う。
これが理解できれば、各機能の最適な使い方は自ずと知る事ができるはずである。
だから、フレームワークのセットだけポンと渡されても困るし、リファレンスだけ渡されてもなかなか最適解にたどり着けない。
むしろ、フレームワークとしては中途半端である。
ちゃんと、フレームワークを作った理由や設計思想、最適な開発手法まで一緒に渡してあげる必要がある。そこまで渡して初めてフレームワークとして機能するのではないだろうか。
なんて事を昔から思っていたのだが、より一層強く思うようになった。
下手なメタファは有害だが、それを覚悟で喩えるなら、
「言語が分かっても、その背景にある文化が分からないと、なかなかうまくコミュニケーションが取れない」
という事。