2014年9月19日金曜日

発注者側から「なぜ価値創造契約がうまくいかないのか」を考える



永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

永和システムマネジメントさんでは、アジャイルらしいシステム受託開発の方式として、ソースコードを納品しないで、利用中も継続課金するという契約方式を試行しておられます。

それが実は苦戦しているそうだということが、永和さんの発表資料から話題になっています。

私もソフトウェア開発を外注することも良くありますが、たしかに発注者の立場からみると、開発中も利用中もずーっと継続課金させるという課金方法で発注するのは、かなりうまくできた仕組みでないと難しいかなと思います。

当たり前ですが、ソフトウェア開発・運用を考えれば、開発フェーズの方がずっと重く、運用フェーズの方がずっと軽いわけです。

ですから、通常の契約では開発フェーズは多くの費用を請求し、運用フェーズでは少ない費用を請求するということになります。それは理にかなったやり方だと思います。

もし納品しない方式であれば、「開発フェーズの金額は受注者が負担し、長期的に回収する方式」なら発注者にはリスク低減メリットがあるでしょう。もしそうではない(稼働時間分を全て請求するor請求金額分しか稼働しない)のなら、単に発注者に対して余計なコストを背負わせているだけということになります。

価値創造契約では、開発フェーズの負担は永和さんが負うように見えますが、その部分をどのような計算で、いくらくらいの開発費や工数を永和さんが負担し、その金額をどのように後日の請求に回していくのか、ということがウェブサイト上では明確ではないように見えます。

経済的に見て、誰がどのように開発費などを負担し、それをどのように償還していくのかということを、きちんと経済学やファイナンスの知見を踏まえて、経営者にとって分かりやすいように説明する必要があるかと思います。

「スモールスタートで」と言うことが書かれていますが、わざわざ支払を繰り延べしてリスク低減する必要があるシステムというのは、スモールスタートよりも社運を賭けた一大プロジェクトのようなものになるのではないでしょうか。

スモールであれば、べつに一括発注でも、普通に人月契約でプログラマを雇って作らせても全く構わんわけですから。失敗すればまたやり直せばよろしなので。

永和さんには、まずファイナンスやミクロ経済学の観点から(リース契約などに習って)契約形態を見直し、ウェブサイトの記述なども見直し、経営者から見てメリットがある形に整理する必要があるかと思います。

もちろん契約書などもかなり入念にレビューして、双方にとって妥当性のあるものにしなければならんでしょうね。

ではでは。

2014/9/19 追記: あと顧客にとって特定の契約形態を押しつけられて売り込まれても何のメリットもないので、プッシュ営業するのは無理だと思いますね。あくまで選択肢の一つという形で提示しておいて、引き合いがあれば提供するという形でないと無理かと思います。

2014年8月26日火曜日

悪徳を擁護する ― 私は今日をもって児童ポルノ擁護派に転じます

これまで私は、児童ポルノ規制反対という明確な立場ではなかったけれど、ここ数日の以下のニュースを見て、「児童ポルノ規制」というのは現代の魔女狩りであり、ナチスや北朝鮮を超える恐ろしい超監視社会の全体主義国家を誕生させる契機ともなりかねないと感じ、児童ポルノ擁護派に転ずることにしました。

MicrosoftのOneDriveに児童ポルノを保存していたら通報されて逮捕 - GIGAZINE

Gmailで児童ポルノを送信したと判断してGoogleが当局に通報、送信者逮捕 - GIGAZINE


2001年の航空機テロ以来、アメリカ合州国を中心として、自由社会や自由主義へのアンチテーゼとも言える動きが見られるのを目にしてきました。

テロとの戦いで、市民のプライバシーを侵害したり、空港で全裸スキャナーを稼働させたり、無駄な手荷物の規制などを導入したり、無関係な国に戦争を吹っ掛けたり、多くのことが起こりました。

動物愛護団体は、自分たちの主張を多くの人に信じ込ませ、単なる道徳的信条を法律による規制として他者に押しつけようとしています。それどころか日本がクジラを食べる自由を侵害するなど、内政干渉にまで及んでいます。

そして児童ポルノ規制は、欧米では魔女狩りじみた狂った状況になりました。児童ポルノは、ヘロインのように所持しているだけで重罪となるだけではなく、そのためならインターネットの大企業まで協力して、市民のプライバシーを完全に無視して行動しています。

現代のIT技術では全てのコンピュータはインターネットにつながり、極めて複雑なソフトウェアにより制御されています。そのため自分のコンピュータであっても、完全なコントロールを得ることは、ほぼ不可能です。

そうした状況下で、犯罪対策のためといえども、ITの主要な部分を握る大企業が、市民のプライバシーを自由に侵害できるとしたら、どんな社会になるでしょうか?

そして、もしそのプライバシーの侵害を、狂信的な政府が悪用するとしたら、どんな恐ろしいことになるでしょうか?

政府の許容する以外の一切の思想は取り締まられ、思想を持った瞬間に処刑されるような世界のできあがりです。


なぜプライバシーや自由を守るために、児童ポルノを擁護する必要があるのか? と思うかもしれません。単にプライバシーや自由の侵害だけに反対すればいいじゃないか、と。

しかし私は気づいてしまったのです。人間社会はしばしば抑圧的な社会を自ら作り出そうとするということに。

抑圧的な社会を作り出すために、「児童ポルノ」だとか「動物虐待」だとか「テロリズム」だとかいった悪役を生み出して、それを叩くという名目で抑圧を生み出すのです。

人々の怒りや善意の感情を巧みに動かして、抑圧を生み出します。

悪役への抑圧があるときに、単に個別の人権侵害事案にたいして立ち上がるだけでは、「抑圧を生み出す本質的構造」と戦うことができないと思うに至りました。悪役への憎悪や恐怖を生み出す構造自体と戦わねばならないと思います。

多くの人にとって児童ポルノは不愉快かもしれないが、それでも児童ポルノを所持して鑑賞することは犯罪にすべきでないと私は思います。配布することも犯罪にすべきではないかもしれないとすら思います。感情的になんでもかんでも違法にするのは間違っています。

たしかに、児童を使ってポルノを撮るなど言語道断でしょう。例えば、意味も無く動物を虐待する行為は、多くの人が不愉快に思うでしょう。ましてや飛行機を乗っ取って高層ビルに突っ込むなど、いかなる弁護の余地もありません。

しかし、だからといって、そうした行為への憎悪や恐怖が、独裁や抑圧へのフリーパスとなってはいけません。「児童ポルノなんて擁護することすらも許されない」というような考え方が蔓延することは、市民の権利にとって最も恐れるべき状況です。

どんなに憎むべき行為であっても、頭を憎悪に燃やし、怒りの余り何も考えられなくなるのは極めて危険です。

本当に規制されるべきものは何なのか、保護されるべき対象はなんなのか、冷静にそれを明確にしなければ、際限の無い抑圧を招くばかりです。

それを防ぐためにも、誰かが「擁護できないものこそを擁護する」立場に立つ必要があるのです。


テロリズムに関して言えば、飛行機を乗っ取られたり爆破されたりすることが防げればいいでしょう。しかし100%の安全性などというものは実現不可能なのですから、現実的な線で妥協をしなければならないのです。

多くの人が自動車の交通事故で死んでいきます。それに対して、飛行機は圧倒的に安全です。それを飛行機に余分な安全対策を課したがために、自動車に乗る人が増えれば、より多くの人を殺すことになります。

動物愛護に関して言えば、動物の残虐な取扱を禁止する倫理的根拠は極めて薄いように思います。「動物を愛護すべき」というのは、あくまで動物愛好家の信念にすぎないのですから、それを「動物を愛護したくない」という人にまで押しつけるのは、自由を不当に奪うものであると考えます。

もちろん現代では多くの人が動物を愛好していますから、動物を扱う産業などには動物の倫理的な取扱を定めるようなことは、それほどひどい自由の侵害とは言えないかもしれません。しかし「動物愛護」を金科玉条として、人間の価値を下に見て、医薬品の動物実験を規制するようなことがあれば、恐ろしい被害を人類にもたらすでしょう。

児童ポルノも同様です。

児童ポルノを所持して鑑賞したり、それを配布したりすることで、児童にどれほどの害が及ぶというのでしょうか? 児童ポルノを製造したり販売したりすることに比べれば、圧倒的に少ない害しか及ばないと言わざるを得ません。

私はリバタリアン(自由至上主義者)ではないので、「児童が自由意志において経済的対価をもらってポルノに出るのは自由じゃないか!」とまで主張するつもりはありません。

児童ポルノや児童買春は、児童の自由意志が十分に確認できないという点で、ある年齢以下は禁止して一定の罰を与えることはある程度の合理性があるとは思います。児童ポルノ製造も販売も禁止する合理性はあるでしょう。販売は製造のインセンティブになるので。

しかし児童ポルノの製造といえども、現状ではあまりにも幅広く捉えられすぎています。児童が自分のヌードを友人に送るだけで児童ポルノ製造罪と捉えられる恐れがあります。そのような間違った立法は直ちに是正すべきです。

また英米で児童ポルノ製造や児童買春が、大量殺人のような重大犯罪と捉えられるのは、あまりにも行き過ぎであると言わざるを得ません。日本がそのような社会にならないことを切に願います。


自由を制限する動きは、善意を装ってやってきます。

悪徳こそが自由にとっての炭鉱のカナリアです。悪徳にも寛容な社会こそ、普通の人にも寛容な社会であるのではないでしょうか。悪徳を擁護することが、自由社会を守ることだと思います。

だから、私は大手を振って自分の悪徳を認め、悪徳を擁護していきたいと思います。

こんなことを堂々と書いたらアメリカ合州国に入国できなくなりそうですけどね・・・

2014年6月22日日曜日

プログラミングで自分の人生を切り開く生き方

私は多くの日本の人とは違った生き方をしてきました。その視点からみて、若い人にすこし伝えられるメッセージがあるのではないかと思い、生き方について少し筆を執ることにしました。我ながら年寄り臭くて嫌になりますが。

私は2014年現在36歳の独身男性、東京生まれの東京育ち、中学校の途中で不登校になり、最終学歴は中卒、IT業界で短期間バイトや就職したのち、独立起業して今にいたります。

いまは自分が開発した製品群が年間数千万円の粗利を生み出していますので、まあ、働かなくても生きていける状況です。もちろん変化の激しいIT業界ですから、生き残るためには、もっともっと働き、もっと貯蓄を作らなければいけませんが。たくさん売上があっても手元に残るのは、ごく僅かですしね。

そんなわけで、世界を旅して踊りながら、自分の会社の製品アイデアをひたすら考えて、設計して実装して、そんな生活を送っています。


本稿では、わりと人生落第気味の人々に、なんとかこの社会を実力で生き抜いて、生き延びて、良い生活をして世の中見返してやるための話を説明していきます。

まあ、ここに来るまではさんざん苦労してきましたので、私と同じような道を歩むのはお勧めしませんけど、同じように人生苦労している人には参考になるかと思います。


# 学歴について

私は中卒で、日本の学校が大嫌いです。しかし理系の良い学校や学歴には大きな価値があると思っています。私の友人知人にも一流大学卒の人が多くいますが、やはり奴らは頭いいし、良い人生送ってんなと思います。

もしあなたが学校や試験勉強が嫌いでなくて、良い成績を残せるのなら、良い大学にいって学ぶことは間違いなく価値があることでしょう。まあ、しかし、そんな人はこの記事を読んでないですよね。

たしかに学歴が良いというのはプラスではありますが、それは単なるお墨付きであって、学歴が良くてもアホで無能な人は大勢います。学歴がなくても頭が良くて優秀な人は大勢います。言うまでもないことですが。


# 学ぶことについて

個人的な経験から言えば、プログラミングと経営を学ぶことは人生逆転に大いに役立ちます。もちろん英語も出来るべきですが、英語は単なる道具なので、お金があれば若いうちに語学留学でもしてさくっと学びましょう。

プログラミングは仕事に使えるだけでなく、現実世界を抽象的に捉える方法を教えてくれます。抽象的思考や論理的思考を身につけるために役立つのです。

この能力が、他の学問への道筋を開いてくれます。こうした基礎能力さえあれば、他のことは独学で学んでいけるのです。

数学や物理学を学んでもそうした能力は身につくかと思いますが、いかんせん学ぶのは骨が折れます。

プログラミングは、コンピュータさえあれば、実際に手を動かしながら学んでいくことができますので、たとえ独学であっても身につけることができるスキルです。

学校へ行けなくても、勉強が苦手でも、お金がなくても、プログラミングだけは誰でも学べるのです。

プログラミングスキルを磨いて、どんどん複雑なプログラムを作れるようになれば、それだけ抽象的思考や論理的思考のスキルはどんどん上がっていきます。

プログラミングを学ぶことは絶対に人生に役立ちます。


数学や物理学を学んでも、学んでいる最中は一銭にもなりませんが、プログラミングなら(いまのところ)初級者の段階から給料をもらって仕事をすることができます。

独学よりは人に習う方がずっと楽なので、できれば待遇が悪くても良い先輩がいる会社にでも潜り込んじゃうのがいいでしょう。待遇の良い会社には後から移れば良い話です。


経営を学ぶということは、経営学を学ぶということではありません。MBAなどクソの役にも立ちませんので。

経営を学ぶには、実際に自分が経営者にならなければ学べません。それを考えると、プログラミングを学ぶのと異なり、誰もが学べるわけではありませんね。(経営するのは大変ですので・・・)

プログラミングなどの理系のスキルだけを学んだ人というのは、視野が狭窄的になりがちです。人間や、実際の問題解決について幅広い視点から見られない人になってしまう恐れがあります。

経営をすることは、実際に人々の問題を解決してお金をもらうという、社会の基本原則を学ぶことです。この能力さえあれば、どんな境遇にあっても何とか生き延びていくことができるでしょう。

もちろん幅広い読書をしたり、経済学を学んだりすることでも視点は補うことができます。が、自分で経営することに勝る体験はないでしょう。(経営学と経済学は全く違う学問です。経営学はクソですが、経済学は教養レベルなら学ぶ価値があります)


# 就職について

就職については、私はあまり詳しくありませんが、一つ言えることは(この記事を読んでないと思いますが)新卒で旧来型大手企業に就職するなら、転職は一切考えない方が良いということです。年功序列型で同期の関係が物を言うような企業では、会社にしがみつくことが一番大事であり、転職は著しく不利になります。

実力主義で生きていきたい人は、外資系とかベンチャーとかに行くのも良いでしょう。でもそれで自分に実力がないことが分かったらどうすんだ、という感じではありますが。

プログラマーの良いところは、零細ベンチャー企業なんかでも、わりかしゆるくて給料もまあまあ貰えて楽しく暮らしていけるみたいな仕事が結構あることですね。そういうところなら、いくらでも転職できますし。

起業したい人は、やはり早めに起業するにこしたことはないでしょう。40歳過ぎて起業して失敗したりすると本当に悲惨なことになりますので。

若いうちは、がむしゃらで裸一貫で起業するのも良いですが、年を取ってから起業する場合は、顧客や取引先やスポンサーなどのステークホルダーをしっかり握って起業しないと悲惨です。

中高年サラリーマンが起業して良いのは、「満を持して」起業する場合だけです。多くの人があなたと仕事をしたいと思っており、金を出したいと思っており、もし失敗すれば転職先はいくらでもあると、そういうときだけです。それですら起業したら当てが外れたりするもんですが・・・


# 働くことについて

プログラマーってのは、今のところ世界最高の職業なんじゃないでしょうか。

プログラマーになるのは免許もいらないし、誰でもなれる初心者レベルのへぼプログラマーから、上級プログラマーまで、レベルに応じて多彩なポストが用意されています。さらには起業するにも大変有利です。

給料もスキルなどに応じてそれなりに貰えますし、なにより中卒や高卒の人がまともな給料を貰える数少ない仕事でもあります。また地方でも家族を養える給料が貰える数少ない仕事でもあります。

医師や弁護士も給料は良いかもしれませんが、プログラマーと違って休みは少ないし、世界のどっからでも仕事ができるというわけにはいきません。

プログラマーなら、実力さえあれば、世界中を旅しながら仕事をすることもできるし、一年の半分は休みみたいな生活もできます。

医者の友人が「医者になって最高の職業に就いたと思ったけど、あなたたちみたいに世界中好きなところに住んで仕事ができるなんて...。そんな生き方がうらやましい」と私と友人のプログラマに言ったことがあります。

もちろんプログラマーにもクソみたいな仕事や案件はいくらでもありますが、そこは本人の能力と世渡り次第です。それはどの仕事も変わりません。実力さえ身につければ、いくらでも転職できるので、ブラック企業にはまってもダメージは最小です。

私みたいに、他人の命令でプログラミングするのは大嫌いという人でも、起業すれば自分のプログラムを売って、好きなときだけ好きなところから仕事をするような生活もできるのです。

まあ、プログラマーにならないとしてもプログラミングのスキルは何にでも役立ちます。いまどきの事業や科学でコンピュータを使わないものなんてないんですから。


# 起業することについて

起業することについては、長くなりますので、また別途このブログかどこかに少しずつ書いていきます。


# 人生を楽しむことについて

私は、ひねくれた性格の持ち主で、他人と接するのも苦手だけど、さみしがりやというどうしようもない人間です。さらに重度の睡眠障害で朝起きられないので会社にも学校にも通えません。

10代~25歳くらいまでの頃は、自暴自棄でアル中寸前の生活を送っていました。

それが、いまは世界を旅しながら各国の美女と踊って暮らす最高の生活を送っています。

仕事も最高に楽しいです。仕事が最高の趣味といってもいいくらいです。最高の仲間にも恵まれ、ストレスもなく仕事をしています。弊社のプログラマーも在宅勤務でストレスなく仕事しています。

生きづらい人間にとっては、外国を旅するというのは良い気分転換になるものです。しかし外国に定住して仕事をして暮らすというのは、また新たなストレスがあります。外国人向けの仕事を見つけるのは難しいですしね。

その点、プログラマーならば、うまくやれば世界中の仕事をやりながら世界のどこでも自由に暮らすことができるという生活も可能です。また現地で就職するにしても、英語ができるプログラマーならいくらでも仕事があるでしょう。

踊ることについては、機会があればそのうち書きます。

精神状態を改善する方法についても、長くなるのでまた別稿で述べたいと思います。


# おわりに

まあ、とにかくプログラミングをやれ! ということです。

普通の人間にこんな生き方できるはずないだろ? と思うかもしれませんが、僕なんかはっきりいって平均よりも圧倒的に下ですからね。

36歳になってようやくCourseraを使って高校数学を全部終えようと頑張ってますし。それも受験勉強でいったらお話にもならないような基本的なレベルです。それですら微分の公式も暗記できず、いちいちウェブを参照する始末・・・

受験なんかやったら、まあ、ろくでもない大学にしか入れないでしょうし、朝起きれないからそもそも学校に通えないですし・・・

ぜひとも人生苦労している人こそがプログラミングと英語を極めて、良い生き方をして欲しいと思います。

おっさんになって今更転職なんてできないという人でも、エクセルのマクロやら何やらを駆使できるだけで仕事はずっと楽になります。

エクセルやらGoogle AppsやらAccessやらkintoneやらの類もバカにしたもんではないのです、というか本当は物凄いポテンシャルありますので。

だからプログラミングをやれ!

以上です。

2014年6月13日金曜日

コンドーム以外のHIV感染予防法 (PReP等)

【免責事項】本稿の著者は医師や医療関係者ではなく、本稿には間違いを含む可能性があります。本稿に従ったことにより受けた一切の不利益について著者は一切の責任を負いません。

HIV(エイズウイルス)の感染を防ぐ方法としては、これまではコンドームだけが有効であるとされてきました。

いまでもコンドームが最も高い予防効果を持っていることは変わりありませんが、それ以外にもいくつかの予防方法が出てきています。

こうした予防方法は、たとえばHIV陽性のパートナーを持つ人がコンドームと併用することで予防効果を高めたり、もしくは何らかの理由でコンドームが使えない/使いたくないのに複数の人と性行為を続けたりする場合に使うことができます。

先日、日本でのHIV新規感染者数が過去最多になったというニュースが報道されました。

とくに日本では男性同性愛者の感染が多いので、そうした高リスクにある方は、本稿の方法によってリスクをさげることができます。

日本では性感染症対策は遅れています。とくに性風俗店などは、警察の管轄にあり、きちんとした規制が行われていないために、性感染症対策や労働法規の適用などの労働者の保護や公衆衛生の管理が行われていません。政府はこの状況をすぐに変えるべきです。


HIVをコンドーム以外に防ぐ方法としてこれまでに成功しているものには、HIV治療薬による予防内服と、男子割礼(いわゆる包茎手術)によるものがあります。

男子割礼は臨床試験の結果からは、ある程度の効果があると考えられ、アフリカで実際に多くの人を割礼するプログラムなどが実施されています。先進国では今のところHIV予防手段として認可はされていないようです。陰茎のうち感染しやすい部分が除去されることで感染が減ると推測されています。

現在試験されており、今後が期待されるものとしては、HIV治療薬のジェルを膣に塗布する方法と、HIVワクチンがあります。

残念ながら、どの方法も100%の効果があるわけではないので、コンドームなどと併用しながら、徐々にHIVを追い詰めていくということになるでしょう。

HIV治療薬の予防内服はアメリカのFDAにより認可され、正式な予防方法となりました。本稿ではアメリカのガイドライン(注1)に基づいてHIV治療薬の予防内服(PReP)について説明をしていきます。


予防内服は、一日一回テノホビル(300mg)・エムトリシタビン(200mg)の合剤(ツルバダ配合錠)を服用するだけで、安全かつ効果的にHIV感染のリスクを減らします。

そのため予防内服は、性的に活動的な男性同性愛者、異性愛者の男女、注射で麻薬を利用している人などのうち、HIV感染のリスクが高い人に推奨されます。

HIVに感染している人は予防内服を開始してはいけないので、予防内服を開始する前に、検査を受けてHIVに感染していないことを確認しなければいけません。

予防内服はきちんと毎日継続して飲む必要があり、性交渉のときだけ飲むとか、飲んだり飲まなかったりしてはいけません。

予防内服をしている間は、開始時とその後6ヶ月ごとに腎機能の検査が推奨されます。


HIV感染のリスクが高い人とは以下のような人のことです。
* HIV陽性の性的パートナーがいる
* 最近、他の性感染症にかかった
* 性的パートナーの数が多い
* コンドームを利用しないことが多い
* セックスワーカーである
* HIVが流行している地域にいる
* 麻薬の注射器を共有している


予防内服の効果は、これまでの臨床試験の結果によれば、HIV感染のリスクを50%程度減らします。ただし、90%以上の日にきちんと服用していたと申告した人に限れば、73%のリスク低減効果がありました。

血液中に薬剤が検出された人に限れば、92%程度のリスク低減効果がありました。

統計的にみると、毎日確実に飲み続ければ、体内に薬剤が行き届いてからは、99%の予防効果があると推測されるそうです。

このように、きちんと毎日飲み続けることができれば、かなり優秀なリスク低減効果が得られることが分かります。もし日本の性的に活動的な男性同性愛者の全てが予防内服の恩恵を受けることができれば、日本のHIV新規感染者数は大きく下がるでしょう。


予防内服を行うことの障壁は二つあります。一つには、日本ではツルバダ配合錠は予防用には認可されておらず、おそらく予防内服を提供してくれる医師がまだいないこと。もう一つは、ツルバダ配合錠の薬価は一日当たり3863.60円と、きわめて高価なことがあります。(一ヶ月あたり11.5万円!)

「ジェネリック ツルバダ」などで検索して、海外の怪しげな闇薬局からジェネリックを買うという方法もありますが、悪い業者に引っかかれば、どんな偽薬を掴まされるか分かったものではなく、その方法には一定のリスクを伴います。

もし、あなたが高リスクで、かつ、予防に使えるお金があるのであれば、日本国内のHIV専門医を口説き落として、予防内服プログラムを実施してもらうのが一番ではないでしょうか。

副作用や安全性についてはツルバダ配合錠の添付文書を参照して下さい。


まだよく分かっていない点として、「どれくらい飲み続ければ効果がでるのか」という点があります。まだ良く分かっていませんが、体内で十分に薬剤が行き渡るまでには20日はかかるのではないかと考えられています。また危険な行為をやめてから飲むのをやめるまで、1ヶ月くらい飲み続けたほうがいいと考えられています。

そのため、飲んだりやめたりするのは現実的ではなく、基本的には常時ずっと飲み続けることが前提になっています。中途半端に飲んだりやめたりすると、中途半端になり、薬剤耐性ウイルスを生じさせてしまう危険性があります。


【免責事項】本稿の著者は医師や医療関係者ではなく、本稿には間違いを含む可能性があります。本稿に従ったことにより受けた一切の不利益について著者は一切の責任を負いません。

参考文献:
1. US Public Health Service, Preexposure prophylaxis for the prevention of HIV indection in the United States - 2014, A clinical practice guideline. http://www.cdc.gov/hiv/pdf/guidelines/PrEPguidelines2014.pdf

2014年5月14日水曜日

3分でDKIMの概念が分かる実践的ガイド

迷惑メール対策の仕組みとしては、SPF、DKIM、DMARCの3種類が主に使われています。

このうちSPFは日本でも広く使われていますが、DKIMは情報が少ないために殆ど使われている事例を見かけません。DKIMは決して難しすぎるわけではないのですが、概念を把握できるような情報が日本語で存在しないため、概要を掴むのに苦労します。

さて、DKIMとは何でしょうか。

一言でいうと、メールに電子署名を付与するための手法です。電子署名を付与することで、正しい送信者から送信されていることを証明し、送信者を詐称する迷惑メールに対抗します。

ややこしいのは、「誰が署名するのか」「署名を検証したらどう使うのか」ということが利用者の裁量に任されており、そのせいで概念が極めて掴みにくくなっています。


署名する方法と、署名を検証する方法はシンプルです。DNSにレコードを追加して、そこにRSA公開鍵をおきます。送信者は対応する秘密鍵を使ってメールに署名します。受信者はDNSに問い合わせして公開鍵を取得し、その公開鍵を使って署名を検証します。

DNSに記載するドメイン名は、(selector)._domainkeys.(domain)という形式になり、そのselectorとdomainは署名中で指定することができます。gmail._domainkeys.example.comというドメインであれば、example.comの持ち主が署名しているということが証明されます。

selectorは鍵の名前と考えれば良いかと思います。DKIMでは、異なるサーバーから送信する場合など、同じドメインに対して複数の鍵を使うことが多いので、鍵に名前をつけて管理できるようになっています。

このことから分かるのは、SPFはDNSに記載があると強制的に検証されますが、DKIMの場合は、あくまで送信されたメールに署名が付与されている場合のみ検証されるということです。SPFとDKIMは大きく違います。


「誰が署名するのか」ということですが、基本的にはFromアドレスの持ち主が署名するのが最も効果的な方法です。Envelope Fromなどが署名しても良いと思いますが、Envelope FromはSPFで検証できますので、DKIMではFromのドメインで署名する方がベターでしょう。

「検証した結果どうするのか」ということですが、いまのところは目立つ効果はあまりありません。DMARCと組み合わせてFromアドレス偽装を完全に防いだり、Fromアドレスを証明することで迷惑メールと認定されにくくしたり、そういった効果が期待されます。

最近はgmailを始め、各社のメールサーバーが迷惑メール認定を極めて厳しくしていますので、こうした手法を取り入れて迷惑メール認定を防ぐことはビジネス上、重要だと思います。

DKIMを付与するだけで、メールの送信に計算量がかかるようになるので、単純な大量送信迷惑メールとは一線を画することができます。


さて、DKIMの具体的な導入方法ですが、以下の通りです。

自分でRSA鍵ペアを生成する場合は、opensslを使って以下のようなコマンドで生成します。

openssl genrsa -out rsa.private 1024
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

ここで注意する点は、鍵長を1024bitにすることです。2048bitにするとDNSの1レコードに収まらなくなり互換性の問題を生じます。512bitは短すぎて受信者に検証拒否されます。

gmailのようなメールサーバーでは、鍵ペアを生成する機能を持っていますので、それを使って下さい。

DNSでは、(selector)._domainkeys.(domain)という形式のドメインに対して、以下のようなレコードを追加します。

v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB

署名したり署名を検証する方法については、メールサーバーやライブラリによりますので、それらの製品のマニュアルを参照して下さい。gmailなどは容易にDKIM対応が可能です。


DKIMについてより詳しく知りたい場合は、残念ながらRFCを読むしかないかと思います。

http://tools.ietf.org/html/rfc6376

2014年5月12日月曜日

真の人月商売こそが受託開発産業を救う ― 請負契約ではITプロジェクトは失敗する

私は自分では受託開発を原則として請けないことにしていますし、受託開発という産業にはあまり興味がありません。しかし現実問題として日本のソフトウェアビジネスの大半は受託開発産業です。

また自分では受託開発を請けないけれど、他人や他社にプログラミングを外注することはあります。今日は、受託開発のお話です。


受託開発産業でよく言われることに「人月商売からの脱却」などというフレーズがありますが、そうした発言はまさに愚の骨頂と思います。経済やビジネスの原理原則を知らない愚かきわまりない発言です。

受託開発というのは、プログラマーという専門職の時間を使って作業を提供して、その成果物を納品する仕事なのですから、コストは当然プログラマーの作業時間となります。

商品の値段というのは、通常はコストに利益を乗せて売られますから、プログラマーがどれだけ働いたかで算出されるのは、きわめて自然な値付け方式です。

「そうではなく、そのシステムが顧客にどれだけ価値をもたらすかで売りたい」という人がいますが、顧客の注文で作るシステムなのですから、その価値は顧客しか知りませんし、その顧客の価値を開発者が得られる理由がありません。

もしソフトウェアの価値でお金を取りたいのであれば、受託開発をやめて、自分で製品を作るべきです。もしくは受託開発で作ったものを、他社にパッケージ販売すればいいでしょう。そうしてみればソフトウェアの価値は良く分かります。

マッキンゼーなどの戦略コンサルタントから、建設業界まで、顧客の注文に応じてサービスを提供する企業では、基本的には労賃+材料費といった計算方法で価格を決めています。

その人月単価をいくらにできるのかは、プログラマーの能力と、企業のブランド力や交渉力/営業力次第でしょう。人月だからといって、プログラマが一律に同じ値段でなければいけない理由がありません。


日本の受託開発産業を悪くしているのは、人月計算ではなく、請負契約などによって受託企業に成果物への責任を負わせる契約慣行です。

あらかじめ完成品の総額を決めて、それから開発にかかるという方式の請負契約は、ソフトウェアのように細かい仕様が全て先に決まらない業界には全く適していない方式です。ソフトウェアの開発は、製造や工事よりも研究開発に近い性質のものであり、見積もりを前もって正確に行うのは極めて困難です。

そうして請負契約でプロジェクトが開始されれば、始まるのはお決まりのパターンです。

発注者は可能な限り多くの仕様を詰め込もうとし、様々な点で修正を求めてきます。それにたいして受注者は、リスク分を見積もりに大幅に上乗せし、仕様をなるべく簡略化しようとし、変更を拒否することを試み、なるべく安いプログラマを使って最小のコストで最低限動くものを仕上げようとします。

これはまさにlose-loseの状況です。

こうした契約形態のせいで、予算超過リスクを負える大企業がシステムを受注し、それを多重下請け形態で、プログラマのスキルとは無関係に、ただ大量の人を集めて、低い品質のシステムをでっちあげるという歪んだ産業構造が生まれました。

請負契約は、あらかじめ仕様を細部まで詰め切れるプロジェクトにしか適用できません。

数十万円の超小規模案件ならそれでも良いでしょうが、大きなプロジェクトになると、仕様策定自体が一大プロジェクトになってしまい、ウォーターフォールで多くの仕様の誤りが生じるので無駄過ぎますね。ルールの厳格な政府調達ならともかく、民間企業がそんな無駄をする理由はありません。


ソフトウェア開発というのは、建設業よりもコンサルティング業に近い産業です。

あらかじめ仕様と設計を細部まで定義して、それにもとづいて見積もりを立てるウォーターフォール方式が良い方法ではない以上、成果を約束させるのではなく、拘束時間に基づいてお金を払うしかありません。準委任契約/派遣契約などに切り替えるということです。

その場合、請負契約のように総額の予算や納期が契約で決まっているわけではありませんし、プロジェクトマネジメントは発注側で行い、発注側が予算や納期について責任を負うことになります。もし発注側にプロマネを出来る人がいなければ、ITコンサルタントなどを雇わなければなりません。

しかし、それにより、発注者と受注者は同じゴールに向かって歩むことが可能になります。「良いソフトウェアを作る」という共同のゴールを持つことができるようになります。

日本でも、いまどきのインターネット企業などでは、請負契約で業者にシステムを作らせているところはないでしょう。そんな方式では、開発速度も遅く、品質も下がってしまうので、競争を勝ち残れません。

一般企業にとってもITの重要性が増す中で、良いソフトウェアを作るためにソフトウェア内製化などに切り替える企業が増えているといった話もあるようです。


発注者側にとって、時間払いの新方式に切り替えるのは、そこまで難しい話ではありません。プロマネをしてくれるITコンサルタント企業さえ見つかれば、実現できるでしょう。

この新方式では総額が決まっていないので発注者にとって余分なリスクがあるようにも思われますが、実際は逆です。

できてもいないシステムの総額にたいして請負契約を結べば、受注者がへぼい仕事をしても途中でキャンセルすることもできず、結局はお金を払ったのにへぼいシステムしかできないというリスクが大きいのです。

それに対して、時間払い方式であれば、品質に満足できなければ合理的な予告期間のあとでいつでも契約を終了することができるでしょう。これはリスクを減らす方向に働きます。

とくに最近はシステムが完成しなくても、どんどん出来たところから動かしてみて、品質を顧客がチェックしていくことができるので、よりこうした方法は実現しやすくなりました。


受注側がこの方式に切り替えるためには、顧客側にも変化を要求することになるので、もっとハードルが高いです。

しかし株式会社ソニックガーデンのように、顧客にこうした方式を要求して、実践している会社もあります。

報われない、疲弊するといった悩みを抱えている受託開発企業は、契約形態を見直して、本当に顧客のためになる仕事をできるように変えていくしかないのではないでしょうか。

人月からの脱却ではなく、真の人月として、働いた時間に応じてお金をもらう、それがプロフェッショナルの働き方だと思います。ワインバーグは「コンサルタントの秘密」で何十年も前にそれを述べています。

では。

2014年4月21日月曜日

WEB+DB Press 80号にCourseraの記事を書きました


4月24日に発売されるWEB+DB Press 80号Courseraを紹介する8ページの記事を書きました。

Courseraを実際に受講するためのハウツーを具体的に記述してあります。

英語なので、かなり敷居が高いと思われがちなCourseraやMOOCsに少しでも実際に取り組む人が増えればと考えております。

そうはいっても実際問題、全部英語で学ぶというのは、かなり大変だとは思うので、どれくらいの人がやってくれるか分かりませんが...

この記事を見て、一人でも二人でもCourseraをやる人がでてきて、その人がまた友達にCourseraを広めてくれればいいなあ、と思います。

多額の費用を掛けて留学するとか、大学に入り直すとか、普通の人にはなかなかできることじゃないので。そうおもえば、「英語の壁くらいなんだ!」と思うのですよ。

あ、facebookでCourseraのコミュニティ作りましたので、よろしければ、そちらにも足をお運び下さい。

 

あと、朝日新聞の金成さんが書いた、こちらの書籍もおすすめです。良く取材されており、「なぜMOOCsがこんなに騒がれているのか」ということが良く分かるかと思います。ではでは。

2014年3月20日木曜日

経営者にも分かるAmazon Web Services (AWS)の利点

IT企業の経営者といっても全員が技術者であるわけではありません。

そうした方々はAmazon Web Services (AWS)の利点があまり深く理解できず、とりあえず安いからと適当なVPS, ホスティングや他社のクラウドを選んでしまうことが多いようです。

しかし、よほど予算に強い制約がある場合や、特殊な要件を除けば、現在ではAWSがファーストチョイスであることに疑問の余地はありません。現時点でAWS以外のクラウドやホスティングを選択する理由はないでしょう。

AWSは、他社とは異次元の圧倒的な高性能クラウドなのです!

なぜAWSを選ぶべきなのでしょうか。その理由は3つあります:

1. メンテ費用が下がる
2. 高い信頼性が容易に実現できる
3. 多機能によるエンジニアリングコストの削減


まずメンテ費用が下がるということですが、OS陳腐化に伴うシステム移行費用(数年間で数百万円以上)を無くせること、日々の保守作業を容易にできることの二点があります。

Amazonは独自のAmazon LinuxというOSを持っており、それを使うことでAmazon EC2の仮想OSとの適合性が保たれ、利用を続けたままで自動的にOSのアップデートをしていくことができます。

そのため、OSが陳腐化することなく、OSのアップデートに伴う移行作業などのメンテ作業を大幅に減らすことができます。システムの移行作業はエンジニアが数人月かかりきりになることも珍しくなく、そうなると数百万円の支出になります。

またサーバーの停止や故障が生じたときもエンジニアの手を借りることなく、簡単にウェブ上からサーバーの再起動や別サーバーへの移行などが行えますので、保守体制も縮小することができます。

サーバーのフルバックアップというと、通常はエンジニアが頑張って手作業でやるか、高価なハードウェアやソフトウェア(数百万円クラス)を購入して行う必要があります。しかし、Amazon EC2ならそれもワンクリックで行うことができます。


高い信頼性が容易に実現できるという点ですが、AWSでは様々な信頼性向上の仕組みを用意しています。

Amazon RDSでは複数データセンターにまたがるデータベースの冗長化(リアルタイム複製)と自動切り替えを標準でサポートしています。

いまやデータベースを運用すること自体は難しい作業ではありませんが、データベースの冗長化と自動切り替えを実現するとなると、一般のエンジニアから見ると、手間のかかる厄介で難しい作業です。

またAmazon EC2ではAmazon EBSという仕組みでサーバーのハードディスクをサーバーから切り離して運用することが可能です。そうすれば、もしサーバーが故障しても、すぐに同じディスクの内容で別サーバーから起動することができます。

先ほど述べたようにサーバーのフルバックアップも簡単に行えますし、データベースのバックアップも自動で確実に行うことができます。これだけでもシステムの信頼性が大幅に向上することは明白です。通常の技術者によるオペレーションでは、必ずミスが付き物ですから。


AWSの持つ圧倒的な多機能性は、エンジニアリングコストの大幅な削減につながります。

DynamoDB, ElastiCache, Elastic Load Balancing, Auto Scalingなど、エンジニアが手放しで多くの機能を利用することができるため、貴重なエンジニアの時間を本来の価値ある業務に注力させることができます。

こうした機能は、とくにゲームやソーシャルや金融などの高負荷なサービスを開発するには必須といえます。これを自社でエンジニアが頑張って運用するのと、Amazonにお任せで運用するのでは、開発スピードに大きな差がついてくるでしょう。


AWSを他社クラウドやVPSと比較して「割高」というのは、全く間違っています。

AWSは他社と比較しようが無いほどの高機能を備えており、値段だけで比較の対象とできるようなものではありません。

AWSがもたらす中長期的なコスト削減効果と信頼性向上を計算にいれた上で比較検討するべきです。