まだ続いていたんだという、驚き

　特許庁は２４日、２００６年から始めた新たな情報システムの開発を中断することを決めた。これまでに５５億円の予算を投じたが、別のシステムを考える。枝野幸男経済産業相は「大変申し訳なく思う」と謝った。

　新システムは特許の出願や登録に使い、中国の特許情報を調べられ、国際化への対応もねらっていた。開発の遅れで、特許を申請する利用者は、機能の低い古いシステムを使い続けることになる。特許庁は中国の情報検索などができる最低限のシステムに絞り、別の方式で開発する。

　新システムの開発期間は０６年１２月から１４年１月。設計を東芝ソリューションと、開発管理をアクセンチュアと契約した。

　開発の遅れは、主に設計の不備が原因。特許庁は検証委員会を設け対応を考えてきたが、委員会は２３日、中断を求める報告書をまとめた。業者が今までに作ってきた設計情報は、特許庁の別のシステム開発に生かしていくという。
朝日新聞デジタル：費やした５５億円、水の泡に　特許庁がシステム開発中断 – ビジネス・経済

この記事を見てまず驚いたのは、この開発はまだ続いていたんだ! ということでした。
「まだ」というのは、今を去ること2年前、特許庁のシステムはこんな事件で話題になっていました。

志摩被告の起訴状によると、２００５年８月ごろから昨年１１月ごろにかけ、新システム設計開発事業に関する情報を伝える見返りとして、ＮＴＴデータで当時、統括部長兼営業担当部長だった沖被告から計約２５０万円分のタクシー代をわいろとして受け取った、としている。
収賄罪で技官を起訴　特許庁汚職 – 47NEWS（よんななニュース）

特許庁発注のコンピューターシステム設計開発事業をめぐる汚職事件で、収賄罪で起訴された同庁技官のほかに職員３人が、複数のシステム開発会社側から飲食接待やタクシー代の肩代わりなどで計約９４万円近くの利益供与を受けていたことが２０日、分かった。
特許庁職員３人に利益供与　飲食、タクシーで９４万円 – 47NEWS（よんななニュース）

実はこの事件を受けての調査報告書では、利益供与問題の再発防止策と並んで、開発状況の調査も行なっています。

2010年8月時点での調査報告書の内容

調査報告書 特許庁情報システムに関する調査委員会(PDF注意)
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf

利益供与・文書流出の再発防止(事実解明チーム)

まとめは、P.34からになります。
最初の2項目は「倫理意識の徹底」「情報管理の整備強化」とありがちな内容でおもしろみがありませんでしたが、3つめが「入札手続きの改善」とあってなかなか読ませます。(P.36から)

供与した事業者の側には、短い提案期間でよりよい提案書をまとめあげようとする動機があった。
収賄した3職員は、受注のプロセスには携わっていなかったのですが、より良いシステムを作るために外部の専門家に意見をもらいたいと考えていたこと、背景にあるんだよ…という内容です。

よりよいものを作りたいと思いに、入札・応札のルールが足枷になっているのだったら、出すべき情報はとっとと出して、接待して情報を得ようとするようなことはなくすようにしたらどう? という、このような調査報告書としては、わりと具体的な提案がされている印象を受けました。

とはいえ、今となっては、この点はあまり重要ではなくなっていますね。

開発状況の分析(技術検証チーム)

この時点で喫緊の課題となっていたのは、開発の遅れということで、上記の利益供与の再発防止とは、独立した調査として、TSOLによる設計と、アクセンチュアによるプロジェクト管理、特許庁の取り組みについて分析が行われています。(P.63から)

「提言」という形をとっていますが、結論としては、

• 発注者の特許庁は責任感持って仕事しろ(P.68)
• プロジェクト管理支援のアクセンチュアは特許庁とTSOLの合意の上、対策案を実施させるまでが仕事だろ(P.72)
• 設計一次請けのTSOLは、今まで設計してきたメンバーで固定しろ(P.75)
• 特許庁は現行システム担当のNTTデータに対して、必要な情報を提示するよう、働きかけるように(P.76)
• 再開するなら、特許庁中心にプロジェクト憲章を作成して、役割分担と責任を明確にしろ(P.78)

となっています。

「技術」検証というわりには、プロジェクト管理に関する指摘が目立つ内容になっています。
外部の人が調査しても、中身が合っているかよくわからないから「品質管理プロセス」へのツッコミが多くなったのでしょう。
こんな状況だったので、てこ入れして、どうにかなりそうならGo、どうにもならなそうだったらSTOPの判断をすることになるだろうな。設計の品質もぼろぼろみたいだし、STOPがかかるんだろうな。
と思っていた次第です。

2012年1月時点での調査報告書の内容

技術検証報告書 ～フォローアップ結果とりまとめ～ (PDF注意)
http://www.meti.go.jp/press/2011/01/20120124001/20120124001-2.pdf

再開に向けて動き出したのでしょうが、それから、1年半経過して、やっぱダメ、ギブアップということになりました。
上記報告書で挙げられた「提言」に対して、ぜんぜん取り組めていないよね、という内容になっています。
それだけでも残念な事態ではあるのですが。

そもそも7年かけて開発してたら…

新聞報道だと、設計担当のTSOLの品質が悪者にされていますが、実際これだけお金をかけて、まだ動くものが作れていない…というのは、全部一括ではなくて、機能別に発注するとか別のやりようがあったんじゃないのか?という疑問です。

だって、そもそもの予定では丸7年もかけて、開発しようとしていたんですよ。
7年たってたら、外部環境は相当変化していますよね。

その点に関しては、報告書のpp.8-9が答えてくれています。

とりわけ国際的環境は大きくかつ急速に変化しており、その結果、早急にシステム構築の必要な新たな政策項目や、対応優先順位を上げなければならない政策項目が顕在化しつつある。例えば、特許審査においては外国文献検索の重要性が急激に増大しており、外国文献に対応できる新たな検索システムの構築が喫緊の課題となっている。

こうした外部環境の変化を踏まえると、プロジェクトの再開に当たり、現行の一括開発手法を引き続き採用するとなると、最終稼働までの間、今後複数年にわたって政策項目の実現が先送りとなってしまうことに加え、これまで同様、遅延等のリスクを伴う可能性も大きい。
そこで、特許庁において、プロジェクトの再開に当たっては、特許庁ＣＩＯ主導の下、このような外部環境の変化を取り込んだ改定最適化計画を策定するとともに、一括開発手法にこだわらず、実現性の高い新たな手法を採用することも視野に入れて今後のプロジェクトの進め方を検討する必要があると考えられる。

一括開発手法にこだわらないという、上記の結論に2010年の報告書の時点で至っていれば、55億円かけて、「設計書」なるものが大量に作成されて、動くプログラムができてないなんてことになってないのではないかなと考えるわけです。
特許をとりまく状況を受けて、優先順位が高い機能から細切れにして開発していくようにすれば、よかったんじゃないかなーと。

でも、ここでキッパリやりなおすのは英断だと思いますけどね。
埋没費用 – Wikipedia
http://ja.wikipedia.org/wiki/%E5%9F%8B%E6%B2%A1%E8%B2%BB%E7%94%A8

最後に

身近なところで、5年かけて開発して、動いているけどゴニョゴニョ…な例を聞いていたので、明日は我が身の思いとともに、そこそこ読みこんでしまいました。報告書を読んでなにを感じるかは、その人の経験に依存する部分も多いと思います。

外部要因で優先順位がころころ変わるなら、それに対応する手法を、契約、意志判断、設計・開発でとるべきなんだろうな…ということを、これからの私の仕事でも念頭に置いておきたいと思います。

Software Design 2011年12月号の特集「エンジニアの能力を引き出すMac活用術」のなかで、クックパッドでは、以前パッケージ管理にMacPortsを使っていたが、今はHomebrewでやっているとの記述を見つけたので、何人目の記事かはわからないが記録を残しておくことにした。

mac ports やめました! ー homebrew で快適 OSX 生活! – TokuLog 改メ tokuhirom’s blog
http://d.hatena.ne.jp/tokuhirom/20100625/1277435268

私にとってのポイントは、Emacs環境を維持することになるので、Emacsで導入しているlispのうち、MacPorts由来のプロダクトに動作に影響が出るものをインストールできることをひとまずの目標とした。

影響が出そうなもの

Emacs本体

Cocoa Emacs に migemo をインストールで整理したとおり、.emacs.d/lisp配下にlispはインストールしてあり、また.emacs.d/init.elでパスを通す設定をしているの、EmacsをMacPorts由来のものに入れ替えさえすれば、lispは動作するはず。

Migemo

Cocoa Emacs に migemo をインストールでインストールしたとおり、migemoをインストールしていたが、Formulaが見あたらないので、「cmigemo」をインストールすることにした。それに伴い、.emacs.d/init.elの記述を一部変更した。

auto-install.el

動作には、「wget」が必要なのでhomebrew環境でインストールする。

Wanderlust

HTMLメールを表示する際に、「w3m」を使っている。
ログイン時のstarttlsのために「gnutls」を使っている。
それぞれhomebrew環境でインストールする。

twittering-mode

twittering-mode更新でOAuth認証で整理したとおり、OAuth認証をするのに「GnuPG」を使っている。
タイムライン取得に「curl」を使っている。
それぞれ、homebrew環境でインストールする。

MacPortsアンインストール

以上を整理した上で、MacPortsをアンインストールする。
手順はMacPorts Guideのアンインストール手順のとおりに実施した。
おしまい。
インストールパスをいじっていないので特に問題なく終了。

Homebrewをインストール

Installation – Homebrew – GitHubを参考にターミナルから以下のコマンドを実行する。
Xcodeが必要になるので、新規に構築する場合には忘れずに…(未来の自分に向けて)

$ ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

途中で何度か「Press enter to continue」で止まるが、その度にEnterキーを押す。

==> Installation successful!

が表示されれば終了。

その後は、上記で整理したパッケージを順次インストールしていく。
もともとMacにインストールされているものはそのまま使うというコンセプトなので、環境構築までの時間が短くてすむのがメリットなんだねというのを体感できます。

w3mで苦戦

w3mのインストールで苦戦しましたが、Lion+homebrew で w3m が動かなかったのがなんとかなったヒャッハー: 麦汁三昧を教えていただいて、こちらの情報を参考に手順を実施しました。

w3mが依存しているbdw-gcのバージョンを7.2alpha6にすればよいとのことで、bdw-gcのFormulaを調べてみると

require 'formula'

class BdwGc < Formula
  homepage 'http://www.hpl.hp.com/personal/Hans_Boehm/gc/'

  if ARGV.build_devel?
    url 'http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.2alpha6.tar.gz'
    md5 '319d0b18cc4eb735c8038ece9df055e4'
    version '7.2alpha6'
  else
    url 'http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.1.tar.gz'
    md5 '2ff9924c7249ef7f736ecfe6f08f3f9b'
  end

  # patch to fix inline asm errors with LLVM, present in upstream SVN
  # some directory restructuring between 7.1 and 7.2a6 force us to have two
  # versions of the same patch
  def patches
    if ARGV.build_devel?
      DATA
    else
      { :p0 => "https://trac.macports.org/export/86621/trunk/dports/devel/boehmgc/files/asm.patch" }
    end
  end

  def install
    # ucontext has been deprecated in 10.6
    # use this flag to force the header to compile
    ENV.append 'CPPFLAGS', "-D_XOPEN_SOURCE" if MacOS.snow_leopard?

    system "./configure", "--disable-debug",
                          "--disable-dependency-tracking",
                          "--prefix=#{prefix}"
                          "--enable-cplusplus"
    system "make"
    system "make check"
    system "make install"
  end
end
(…略)

となっており、「if ARGV.build_devel?」の記述から

$ brew install --devel bdw-gc

とすれば、狙ったバージョンがインストールできることがわかりました。

w3mも上記の記事の記載通りにインストールしてうまくいきました。

.emacsの修正

migemo→cmigemo

migemoをcmigemoに変更したので、コマンドとコマンドオプション部分の記述を変更している。

変更前

(setq migemo-command "migemo")
(setq migemo-options '("-t" "emacs"))

変更後

(setq migemo-command "cmigemo")
(setq migemo-options '("-q" "--emacs"))

emacs-w3m

MacPortsでは/opt/local/bin配下にコマンドが配置されるが、Homebrewは/usr/local/bin配下に配置される。
よって、コマンドの在処の記述を変更。

変更前

(setq w3m-command "/opt/local/bin/w3m")

変更後

(setq w3m-command "/usr/local/bin/w3m")

Cocoa Emacsについてフォント設定を見直していたところ、Rictyというフォントがあることを知り、設定してみることにした。
環境はMac OS X Lion 10.7.2 / MacPortsでインストールしたGNU Emacs 23.3.1となります。

プログラミング用フォント Ricty
http://save.sys.t.u-tokyo.ac.jp/~yusa/fonts/ricty.html

フォント生成・インストール

まずFontForgeが必要ということで、MacPortsでインストール。

sudo port install fontforge

続いて、Inconsolataから”OpenType File”をダウンロードして、FontBook経由でフォントをインストール。
M+とIPAの合成フォントから、上部の”DOWNLOAD”をクリックし、ダウンロードページに進み、Migu 1Mをダウンロードして、FontBook経由でフォントをインストール。

cd
wget http://save.sys.t.u-tokyo.ac.jp/~yusa/fonts/ricty/Ricty-3.1.3.tar.gz
tar xvfz Ricty-3.1.3.tar.gz
cd Ricty
sh ricty_generator.sh auto

するとRictyディレクトリ配下に

• Ricty-Bold.ttf
• Ricty-Regular.ttf
• RictyDiscord-Bold.ttf
• RictyDiscord-Regular.ttf

の4ファイルが生成されます。

上の二つ、Ricty-Bold.ttfとRicty-Regular.ttfをインストールしました。

Emacsで使う

init.elでフォントの設定をします。

(set-face-attribute 'default nil
                   :family "Ricty"
                   :height 140)
(set-fontset-font
 nil 'japanese-jisx0208
 (font-spec :family "Ricty"))

としてできあがりです。
半角と全角の比が1:2というのはいいですね。

[追記]2012.01.29
フレームを開いたときに幅が二倍になるのが気になったので、下記ページを参考にEmacsを入れなおしました。

Cocoa Emacs で和文フォントをプライマリーに設定するとフレーム幅が二倍になる問題 – キーボードをたたくとき
http://d.hatena.ne.jp/yascentur/20110730/1311963061

システムを構築することを生業とする会社の新入社員研修では、プログラム書いてみようとか、シェルを書いてみようといった講義、実習が行なわれているわけです。

ところが様子を見ていると、viの使い方になれていない様子。
聞けば学生時代にEmacsは使っていたものの、viには触れていない人がかなりいるようでした。
であれば、サーバ上の設定ファイルやシェルをメンテするなら、これくらい使えれば苦労しないんじゃないかな…というラインを示すのも一興かと思い、本記事をおこす次第です。

なお、弊ブログではEmacs関連の記事がいくつかありますことからわかるように、自宅で文章を書くときには、Emacs使っています。この記事もEmacsで書いています。
そんな私がviをこれくらい使えれば、サーバ維持管理の仕事では大丈夫かなと思っているレベルです。
※ Emacsにもvi-modeが存在しますが…

vi ファイル名
でファイルを開くところから始めましょう。
vi を実行しても vim だったりする場合もありますが、とりあえず細かいことは気にしない。

困ったときには

いろいろな操作を覚える前に、困ったときの対処法を覚えましょう。
自転車でも、ローラースケートでも止まり方から覚えるようなものです。

Esc連打からの展開が基本

コマンドモード、コマンドラインモード、編集モード…とか言われますが、最初は理解するのは困難だと思います。
(いまだに自分がどのモードにいるのか確信を持てません)
「やばい…なんだか変になっちゃった…」という具合に困ったら、とにかくEscキーを連打しましょう。

Escキーを連打したあと「u」を入力すれば、編集を元に戻せます。(Undo)
Escキーを連打したあと「:q!」を入力すれば、元ファイルに編集を加えることなくviを終了することができます。

Escキーを連打すれば、おそらく「コマンドモード」にいるだろうという安心感があります。
一種のホームポジションですね。

文字を入力する

入力開始

Escキーを連打したあと「i」や「a」を入力すれば、文字の入力開始です。(編集モード)
キーボードで入力したとおりに、文字が入力されるはずです。

誤入力した！

あわてずさわがず、Esc連打です。
間違えて入力した箇所にカーソルを合わせましょう。
このカーソル移動がなにも見ずにできるようになれば、最初の壁は突破できたものと思います。

• h:左
• j:下
• k:上
• l:右
• 0(ゼロ):行頭
• $:行末

狙った場所にカーソルを置いて「x」を入力すると削除されます。
一文字だけ修正したいときには「r (修正後の文字)」と入力するとよいでしょう。

探して修正する

実際にファイルをメンテナンスする場面においては、

• 特定の文字列を探して修正
• 特定の行まで移動して修正

という場合が多いと思います。
エラーメッセージから特定の行に誤りがあるか、そのメッセージをてがかりに修正箇所のあたりをつける…といった場面が多い気がするので。

Escキーを連打したあと「/検索したい文字列[Enter]」と入力すると、下方向で検索して、ヒットすればそこまでカーソルが移動します。
Escキーを連打したあと「(行数)G」で狙った行へカーソルが移動します。たとえば「15G」で15行目に移動です。

保存する

編集が終わったら、保存をしましょう。
Esc連打のあと「:w」と入力して保存です。
終了もしたいなら「:wq」でどうぞ。「ZZ」派の方もいらっしゃるようです。

操作を忘れたときに備えて

チートシート(カンニングペーパー)を、ノートなりデスクなりに用意しておきましょう。

• 日本語版: http://www.namaraii.com/files/vim-cheatsheet.pdf [PDF注意]
• なんかかっこいい: http://www.smashingmagazine.com/wp-content/uploads/2010/05/VI-Help-Sheet-011.pdf [PDF注意]

こんな操作があるんだと学習することもできます。

コマンドリファレンス本もあります。

もっと使いこみたいなら

このような本で学習してみるのはどうでしょうか。

とことん自分用の環境としてつきつめていきたいのであれば、vimの設定ファイルである「.vimrc」について調べてみるとよいと思います。

Windowsにvimでも入れてみるかな…

詳細はTwitterでのハッシュタグ #librahack と、逮捕された容疑者がまとめられている下記サイトを参照

Librahack ： 岡崎市立中央図書館HP大量アクセス事件まとめ
http://librahack.jp/

Twitter / Search – #librahack
http://twitter.com/#search?q=%23librahack

ということで、この事件、結局不起訴に終わったようなのですが、正直よくわかりません。
自分のわからないことを整理するために、Twitterのハッシュタグ #librahack 経由で拾った情報を追いかけつつ、システム作り顧客に納品するという仕事をしている立場から、推測に推測を重ね、思うことを書いてみようと思います。

なお、

• 攻撃を受けたとされるシステムは図書館の資産
• システムの保守は管理会社に委託

という前提です。

疑問点

私が疑問に思っている点は1点。
警察に被害届を出すまでにシステムを運用している会社と図書館の間でどのようなやりとりがあったのか、です。
しかしながら、攻撃を受けた側の情報が圧倒的に不足していて、あるのは作った会社の情報と推測、憶測ばかり…。
攻撃を受けた側から引き出した情報としてあったのは、下記の記事でした。
↓

1. サーバの不調について、管理会社に調査してもらった
2. 管理会社の調査で、外部からの攻撃が判明
3. 警察に被害届を提出
4. 私(電話に出られた担当の方)が知る限り、警察からは2,3回、問合せがあった
5. サーバの調査等は、私が知る限り行っていない
6. 令状を持った捜査が行われたことは無い
7. 逮捕は報道で知った
サーバ管理者日誌 岡崎市立中央図書館に電話してみた

私が想像していたのは、システム側でアクセス遮断とか対策を施したんだけど、それでもしつこく攻撃されるから、警察に被害届を出した…という流れです。
上記2.と3.の間に、図書館が主体となってしかるべき判断なり対策があるべきだろうと。
しかし、上の内容では、図書館が主体になって何もしていないのでは、という疑問を抱いてしまいました。
なにもしていないのに、いきなり被害届を出したのでしょうか。

もし自分が管理会社の担当だったら

1. 「想定より多い量のアクセスがあった」旨、顧客に報告
2. 「数カ所のIPアドレスからのアクセスのようです」などとアクセス分析
3. 「対象のIPアドレスを持つプロバイダに問合せましょうか」と提案
4. 「場合によってはアクセス遮断しましょう」と提案
5. 上の作業について、お代はこれこれ…

システムを維持・管理している会社としては、もしかしたら、定型保守枠外の作業としてお金をいただくチャンスです。
私だったら、上の流れで図書館のシステム担当者に提案していると思います。

もし自分が図書館のシステム担当だったら

1. 外部からの攻撃があったとの報告を受ける
2. 他の利用者に迷惑かけている。どうにかならないか
3. その攻撃を防ぐことはできませんか?
4. 以下、管理会社のターン

図書館側としては、一般の利用者の利便を確保することが第一だと思います。
そのためにできることはなんでしょうと聞くでしょう。
知識があれば、上記管理会社に逆提案もできるかもしれません。

さて

ここでどういう行動を両者がとったのか、よくわからない。
#librahack タグでの情報もこの辺は推測でしかありません。
しかし、図書館側の行動に主体性がない(ように見える)ことへの批判が見当たらないのが不思議です。

最後に

ここでは、

• 1時間に3万アクセス程度で落ちるとはなんて貧弱な! どういう作りしているの?
• HTTP500が発生しただけで「停止」扱いですか?
• これだからコンピュータに詳しくないヤツが報道すると…

という観点からはなにも言いません。

日経のIT Proあたりに事件を取材していただいて、報道してもらいたいです。

Thoughts on Flashを自分のために訳してみました。
自動翻訳にかけてもわけがわからなかったのです…

だいたい意味はつかめているとは思うのですが、間違いやら、表記のバラつきなど、指摘あればコメントいただけるとうれしいです。
よろしくお願いします。

[4/30追記]
感想を。
最初に「技術的な問題」と言っておきながら、最後の結論部分は「ビジネス上の判断」になっているではないかと、眉に唾して読みたいところです。
H.264のくだりや、最新のプラットフォームに対応できない点などは特にそんな印象です。
しかし、第三の点、セキュリティや信頼性という点については、うなずける部分があります。
iPhone,iPod,iPadにインストールされるソフトはすべてアップルの管理下にあるということです。
Appleの審査を通過したものだけが、App Storeに並んでいることでセキュリティ・信頼を担保しているということですね。
Flashベースのゲーム、アプリを勝手にインストールすることまかりならん。
という言い分も誠実な感じがあり、わからなくはないです。
といっても、セキュリティを表向きの理由にAppleにとって都合の悪いアプリを排除することも可能ってことなんですけどね。

序

アップルは、Adobe社との長い関係があります。
我々はかの有名なガレージにいたころのAdobeの創業者に会っています。
アップルは、Adobeにとっては最初の重要な顧客でした。アップルのレーザープリンターのためにPostScriptを採用したのです。
アップルは、Adobeの株の20%前後を長年にわたって所有してきました。
両社は先進的なDTP環境のために長く協働してきたものです。
そんな黄金時代から、それぞれ別の成長をここまで遂げてきたものです。
アップルは一度死にかけ、Adobeは魅力的なAcrobat製品を世に送りました。
今日でも、両社はともに共通の顧客にむけて製品を提供しています。
(MacユーザはAdobe Suiteの売上のおよそ半分を占めているのです。)

私は、iPodやiPadやiPhoneでFlashの利用を許可しない考えを
顧客や評論家によりよく理解してもらえるようにしたいと思います。

Adobeはその理由を我々のビジネス的判断であると見なしているようです。
(彼らは、App Storeの保護のためだといっているのだから)
しかし、実際は技術的な問題に基づくものなのです。

Adobeはアップルは閉鎖的であり、Flash技術はオープンなものだと主張していますが、実際のところはその反対です。ご説明しましょう。

第一に『オープン』について

AdobeのFlashは100%独占的(プロプライエタリな)製品です。
FlashはAdobeからのみ購入でき、将来の拡張、価格設定などを決定する権限を持っています。
AdobeのFlash製品が入手が容易であるとはいえ、それはオープンであることを意味しません。
AdobeはFlashの全てをコントロールできるのです。Flashは閉鎖的なのです。

アップルも、多くのプロプライエタリな製品を作っています。
iPhone,iPod,iPadのOSはプロプライエタリなものですが、Webの標準についてはオープンでありたいと考えています。

Flashではなく、AppleはWebの標準である、HTML5,CSS,JavaScriptを採用しています。Appleの携帯デバイスは、高性能と低消費電力の実装をこれらオープンな標準で実装して出荷しています。
HTML5はアップルやグーグル他多くの企業い採用されている新しいWeb標準です。
Web開発者は、Flashのようなサードパーティ製のブラウザプラグインに頼ることなく、高度なグラフィックス、タイポグラフィ、アニメーションや画面遷移を作成することができます。
HTML5は完全にオープンであり、Appleがメンバである標準化委員会によってコントロールされます。

AppleはWebのオープンな標準を生みだしていきます。
たとえば、Appleは小さなオープンソースプロジェクトで始まったWebKit作りだしました。
完全にオープンソースのHTML5レンダリングエンジンで、Safariの心臓部となっています。
WebKitは広く採用されています。GoogleはAndroidのブラウザのために使用し
Palmもノキアも使用していますし、BlackBerryでも使用されるとのアナウンスがありました。
MicroSoft以外のほぼすべてのスマートフォンのWebブラウザはWebKitを使います。
WebKitの技術をオープンにすることで、Appleは携帯電話のWebブラウザの標準を設定しています。

第二に『Web全体』

Adobeは、Web上での映像の75%はFlashで提供されているため、アップルのモバイル端末は『完全なWeb』にアクセスできません、と繰り返し述べています。
Adobeが言わないことがあります。ビデオのモダンな形式はH.264です。
iPhone,iPod,iPadで見ることができます。
YouTubeはWeb上のビデオの推定40%を占めています。
Appleのモバイルデバイスにバンドルされたアプリケーションで最高の視聴体験ができるでしょう。
YouTubeにはVimeo, Netflix, Facebook, ABC, CBS, CNN, MSNBC, Fox News, ESPN, NPR, Time, The New York Times, The Wall Street Journal, Sports Illustrated, People, National Geographic 他にも本当にたくさんの方から動画が提供されています。
iPhone,iPod,iPadのユーザーは、映像が不足しているということはないでしょう。

もう1つのAdobeの主張は、アップルのデバイスは、Flashゲームをプレイできません、ということです。
本当ですね。幸いなことに、App Storeで5万以上ものゲームとエンターテイメント作品があり、多くは無料です。
こんなに多くのゲームやエンターテイメント作品が楽しめるプラットフォームは、iPhone,iPod,iPadなのです。

第三に、信頼性、セキュリティ、パフォーマンス

シマンテックは最近、2009年で最悪のセキュリティなのは、Flashであると強調しています。また、我々はMacがクラッシュする原因で一番多いのはFlashであると知っています。
我々は、Adobeと、これらの問題の解決に努めているが、何年も改善しません。
Flashを追加することで、iPhone,iPod,iPadの信頼性とセキュリティを低下させたくないのです。

また、Flashはモバイル端末上でうまく動きません。我々は、何年もの間繰り返し、モバイル端末上でまともに動くFlashをAdobeに求めています。でも、まだ見たことがありません。
Adobeはスマートフォン上で動くFlashの出荷時期をどんどん先のばしにしています。
今は2010年後半と言っています。
いずれ出荷されるとは思うが、期待して待っていなくてよかったと思います。
どう動くのかわからないですからね。

第四に、バッテリーの寿命

ビデオ再生時に長いバッテリー寿命を実現するために、モバイル端末はハードウェアで映像をデコードする必要があります。
ソフトウェアでデコードするとたくさんの電力を消費してしまいます。
モバイル端末向けの最新のチップではH.264のデコーダーが含まれています。

Flashは最近H.264のサポートを追加しましたが、ほとんどのFlashビデオは
チップに搭載されたデコーダーに対応していないため、ソフトウェアのデコーダーが必要です。違いははっきりとしています。iPhoneを例にあげるとH.264動画を10時間再生できますが、ソフトウェアデコードだと5時間未満しかバッテリーが保ちません。

Webサイト側でH.264で再エンコードしてしまえば、Flashを使う必要はありません。
SafariやChromeであればプラグインなしに完全に再生できますしiPhone,iPod,iPadでもばっちり見ることができます。

第五に、タッチスクリーンへの対応

Flashはパソコンのマウスでの操作を前提に開発されました。
タッチスクリーンを指で触って操作することは考えられていません。
たとえば、多くのFlashを用いたWebサイトは、特定の場所にマウスカーソルを合わせたときにポップアップする『ロールオーバー』に依存しています。
アップルの革新的はマルチタッチインターフェイスは、マウスを使っていませんが、『ロールオーバー』の概念もありません。ほとんどのFlashを用いたサイトは触って操作する前提のデバイスをサポートするために書き換えが必要になります。
Flashのサイトを書き換えるとき、HTML5,CSS,JavaScriptといったモダンな技術を用いないことはないでしょう。

Flashが動作した場合でも、触って操作するデバイスをサポートするために書き換える必要があることは変わりません。

第六に、最も重要な理由

今まで述べてきたことより、Flashを許可しない重要な理由があります。
我々はFlashを用いる不利な点をここまで議論してきましたが、AdobeはFlashを我々の製品で動作するアプリケーション開発のために、開発者がAdobeを採用することを望んでいます。

プラットフォームと開発者の間にサードパーティのレイヤーがサブ標準として存在することが、結局、プラットフォームの強化を妨げる結果になることを、痛みを伴う経験から知っています。

開発者がサードパーティお開発ライブラリとツールに依存している場合には、
プラットフォームで新機能を追加しても、サードパーティがその新機能を採用しないと開発者は利用することができません。

したがって開発者は最低限の共通部分の機能へのアクセスしかできません。
他社のプラットフォーム上で動作しないからといって、我々の技術革新と機能拡張から開発者が遠ざけられるのは、受け入れることができません。

Flashはクロスプラットフォームの開発ツールです。iPhone,iPod,iPadに最高のアプリケーションを開発する手助けをすることがAdobeの目標ではないのです。
クロスプラットフォームのアプリケーションを開発してもらうのが目標なのです。
そしてAdobeはアップルのプラットフォームの機能拡張対応が苦痛を感じるほど遅いのです。
例えば、MacOSXはここ10年出荷されているが、AdobeがCocoaに完全に対応したのは、つい2週間前に出荷されたCS5なのです。
Adobeは、主要ななかでは完全にMacOSXに対応した最後のサードパーティでした。

私たちの動機は単純です。私たちは開発者に最も先進的で革新的はプラットフォームを提供したい。
開発者がプラットフォーム上で今までで最高のアプリケーションを作成してもらいたい。

我々は、さらによいアプリケーションを作成できるように、継続的にプラットフォームを強化していきます。
我々は最高のアプリケーションがあるので、より多くのデバイスが売れる。
開発者はより多くの顧客にリーチすることができる。
ユーザーはあらゆるプラットフォームのなかから最高のアプリケーションを広く選択できる喜びがある。
これが全員にとっての勝利です。

結論

FlashはPCの時代にPCとマウスのためにうまれました。
FlashはAdobeにとって成功しているビジネスで、PCを越えてプッシュすることは理解できます。
しかし、モバイル時代は、低消費電力、タッチインターフェース、オープンなWeb標準が支えています。
Flashに欠けているものばかりです。

メディアが雪崩をうってアップルのデバイスでコンテンツを提供していることは
映像やWeb上のコンテンツを消費するのに、もはやFlashは必要ないということを明らかに示しています。
また、App Storeにある20万のアプリケーションは、何万人もの開発者が
ゲームを含むグラフィカルなアプリケーションを開発するのに
Flashを必要としていないということを証明しています。

HTML5のようにモバイル時代に生まれた新しいオープンな規格はモバイルデバイス上で勝利するでしょう。(それだけでなくPCでも)
Adobeはアップルへの批判をやめて、HTML5用のツールを将来にむけて作成することに注力すべきです。

2010年4月
スティーブ・ジョブス

システム開発現場の活気を取戻そう（中）ウォーターフォールからの脱却 ビジネス-次世代ＩＴ産業論考（浜口友一）:IT-PLUS
http://it.nikkei.co.jp/business/column/hamaguchi_it.aspx?n=MMIT2z000025072008

そしてよく考えてみると、ソフトウエアは製造工場で同じ形の製品を繰り返し大量生産するようなものとは違い、製品設計それ自体が生産物であり、２つと同じものを作ることはない。果たして、このような工場型の方式が向いているのかどうかという疑問もわいてくる。

だって、「生産」と「開発」は違うもん。

よく引き合いに出される自動車で言えば、工場でやっている「生産」というのは「同じものをたくさん製造する」ことでしょう。
「同じもの」つまり「製品」のコンセプトを決め、設計に落としていくことは、「開発」というのではないでしょうか?

そういう意味では、OSやパッケージベンダは自動車会社の「開発」に近い工程が回せているのかもしれません。コンセプトを決めるのは自分たちですからね。で「製造」はCD-ROMとライセンス文書のコピー。

SIというのは、顧客にコンセプトを決めてもらって「開発」に入るんだから、自動車産業のしかも「製造」をまねっこできないのは自明なんじゃないのか?
自動車の「開発」がどのように進められているのかは、参考になるかもしれませんが。

開発生産性が低い方が収入が多いって変だよね – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080723/1216790705

実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。

「開発の生産性」と言われると、ちょっと違和感を覚えてしまうのはこのせいだったか。

フローチャート関連の議論のあと、システムエンジニアってなんだろうと考えていて、ふと思い出した塩野七生氏の文。
分業についてです。

『ルネサンスとは何であったのか』(文庫版 P.87)

また、当時の工房が、美を追求することならば何でも引き受けるというシステムであったのも、フィレンツェ人の気質に合っていたのだと思う。絵画や彫刻にかぎらず、祭りに使われる旗から御婦人方の衣装や宝飾品、机上の置物から大建造物と、図面を引いたりデザインを考えたり金銀や銅を溶解したりと、あらゆる種類の仕事が工房では行なわれていたのです。その仕事の進め方も、専門ごとに分れていたのではない。見習い期間中はとくに、必要となればどこにも手助けに行かされる。絵具の調合をしていたと思ったら、金属を溶く火の前でふいごを手にしているという具合です。
(中略)
そして、何でもやれねばならなかった工房という学校で学んだ後に独立し、それ以後は得意な分野で才能の花を咲かせるのが、フィレンツェの芸術家の生涯のコースだった。

一方、ヴェネツィアは
『ルネサンスとは何であったのか』(文庫版 P.88)

画家は絵だけに、建築家は建築だけに専念していたヴェネツィア人とは大きな違いですね
(中略)
ヴェネツィアでは、効率性を重視したから専門化したのではなく、ヴェネツィア派の絵画の台頭が、フィレンツェ派の成功の後を追って成されたという事情によると思います。専門化とは、相当な成果があがった後ではじめて効果を発揮できるシステムだから。

今まさに、システム開発にとっての「専門」の定義が変わるときなんでしょう。
「ホスト」でのシステム開発で大きな成果をあげてしまった反動なのかもしれません。
分業体制とか、作りかたとか、ホストの名残りであることが多いですからね。

ホストでの開発も最初はフィレンツェ式で、みんななんでもやっていたんじゃないかなぁ。

もう一度、フィレンツェのような渾然一体に戻ってみる時期なのかもしれません。そうすればソースコードを書けないような人は淘汰されていくんでしょう。

私自身は思考も指向も、「フィレンツェ式渾然一体型」なんだと思います。
だいたい、専門職と言われるのが好きではありません。なんだよ基盤の専門職って。
製品買って組みあわせるのが基盤か?
システム作るのにやれることはなんでもやるんじゃないの?
データ設計とか担当外だからって口出しちゃだめなの?

やばい、愚痴になってきた。

SIerにおいて、システムをメンテナンスしていくのに必要なドキュメントとはなんだろう。

プログラミングファースト開発の必要性 – ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080721/1216607451

仕様が固まった後に作成するドキュメントは、プログラムと一対一になるようなドキュメントではない。そんなのはプログラムを見ればすむ話だから。メンテナンスする人が必要になるドキュメントを書く。メンテナンスする人にとってはドキュメントは必要ですよ。全部ソース読めはきつい。

まず、対内部 & 対顧客として
このシステムはなにをするためのものか
がわからないと引き継ぎ困難です。
『概要設計』と呼ばれるレベルのものでしょうか。
・機能リストのようなもの
・(他システムとの接続があれば)接続関係図
があるとメンテナンスが容易になります。
(どのシステムに影響があるかわからないと、事前の影響確認とかしてもらえない)

そう考えると、対外的には
・外部システムとの接続仕様(I/F仕様)
は残しておく必要があるかな。外部システムの担当が他社であれば、接続仕様がないと話にならないかもしれません。
Web画面で済むならこれも不要かも。

あと自社内担当分であれば
・内部の機能配置
・プロセス間通信(機能の間でのデータのやりとり)が発生するならその経路
・機能とソースの関連性
を図示しておけば、いじったときの影響を判断することが可能。
テスト年中まわしていれば気付くだろうしね。

障害発生時の動きを示した文書は、エラーメッセージがしっかりしていれば不要。
ただ、H/W障害発生時や停止したときの復旧方法など示した文書、再構築手順は必要か。

コード仕様書などは、「1=会社員」とか「2=公務員」などという内容にしなければ不要そうだ。
(ダイレクトに「会社員」「公務員」とかエントリーしちゃだめなの? こちらのほうが直感的ではあるんだけど)
現状、ホストのデータの持ちかたをひきずったシステムをどうすればいいのか…
外部から飛んでくるデータもこんなんだしなぁ。