ソニーの開発18か条というのが、Twitter上で流れてきました。
内容は以下のとおりなんですが…

これは、ウォークマンの開発に携わった大曽根さんという方のチームで唱えられていたものだそうです（出井さんCEO就任前に）。まずはご覧下さい。

ソニーの『開発18か条』

第1条：客の欲しがっているものではなく客のためになるものをつくれ

第2条：客の目線ではなく自分の目線でモノをつくれ

第3条：サイズやコストは可能性で決めるな。必要性・必然性で決めろ

第4条：市場は成熟しているかもしれないが商品は成熟などしていない

第5条：できない理由はできることの証拠だ。できない理由を解決すればよい

第6条：よいものを安く、より新しいものを早く

第7条：商品の弱点を解決すると新しい市場が生まれ、利点を改良すると今ある市場が広がる

第8条：絞った知恵の量だけ付加価値が得られる

第9条：企画の知恵に勝るコストダウンはない

第10条：後発での失敗は再起不能と思え

第11条：ものが売れないのは高いか悪いのかのどちらかだ

第12条：新しい種（商品）は育つ畑に蒔け

第13条：他社の動きを気にし始めるのは負けの始まりだ

第14条：可能と困難は可能のうち

第15条：無謀はいけないが多少の無理はさせろ、無理を通せば、発想が変わる

第16条：新しい技術は、必ず次の技術によって置き換わる宿命を持っている。それをまた自分の手でやってこそ技術屋冥利に尽きる。自分がやらなければ他社がやるだけのこと。商品のコストもまったく同じ

第17条：市場は調査するものではなく創造するものだ。世界初の商品を出すのに、調査のしようがないし、調査してもあてにならない

第18条：不幸にして意気地のない上司についたときは新しいアイデアは上司に黙って、まず、ものをつくれ
120131_52_フリーランスとか大手とか言ってないで「ソニーの開発18か条」を今こそ振り返ってみよう！ – Onigiri.blog

ただ、コメントを見ていると「今のソニーでは失われた」とか「アップルのこと?」的なコメントがたくさん見られました。
でも、私には「失われた」のではなくソニーの現状がこの18か条の延長線上にあるような気がしてならなかったのです。

裏目に出るとき

第1条：客の欲しがっているものではなく客のためになるものをつくれ
第2条：客の目線ではなく自分の目線でモノをつくれ
第3条：サイズやコストは可能性で決めるな。必要性・必然性で決めろ

客のためになると考え「もっと小さなサイズを客は求めているんだ!」と自分目線で考えて、「このサイズは必然です、部品も独自の小さなネジやコネクタ、乾電池より小さな電池を作るんです」とコスト高になることを恐れず、独自の部品などを開発。

[イケイケのとき]
ステレオミニプラグやガム型電池は広く受けいれられる。
部品のコスト高も製品がもっと高く売れるので問題なし。

[裏目に出ると]
ステレオマイクロプラグは受けいれられず。
独自部品のコストが負担になる。

第9条：企画の知恵に勝るコストダウンはない
第10条：後発での失敗は再起不能と思え
第11条：ものが売れないのは高いか悪いのかのどちらかだ
第12条：新しい種（商品）は育つ畑に蒔け
第13条：他社の動きを気にし始めるのは負けの始まりだ
第17条：市場は調査するものではなく創造するものだ。世界初の商品を出すのに、調査のしようがないし、調査してもあてにならない

数々の独自規格…メモリースティックなどはこのスピリットが元になって生まれたのだろうなぁ。
うまくいけばAIBO、裏目にでればROLLY。

第16条：新しい技術は、必ず次の技術によって置き換わる宿命を持っている。それをまた自分の手でやってこそ技術屋冥利に尽きる。自分がやらなければ他社がやるだけのこと。商品のコストもまったく同じ

第16条などは「枯れた技術の水平思考」と裏表の関係になりそうですね。。
コストと新技術のバランスをどのように取るのか、そのバランスが新技術のほうにぐっと傾いていたら?

ものとサービス

「商品」にはサービスも含まれるはずなんですが、18か条で登場する「商品」の定義は、「もの」に象徴されるようにハードウェアに限定されている感じがします。その結果が今のソニーなのかなと思う次第です。

18か条の「商品」「もの」を「ユーザー体験」「サービス」に置き換えられたのが、アップルやGoogleであったと。
アップルで言えば、iPodというハードウェアを売るのではなく、iTunesも含めたサービスを売っているわけですよね。
そこいらへん「ハード」「もの」にこだわってしまったのがソニーなのではないかと。

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

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

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

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

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

この記事を見てまず驚いたのは、この開発はまだ続いていたんだ! ということでした。
「まだ」というのは、今を去ること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年かけて開発して、動いているけどゴニョゴニョ…な例を聞いていたので、明日は我が身の思いとともに、そこそこ読みこんでしまいました。報告書を読んでなにを感じるかは、その人の経験に依存する部分も多いと思います。

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

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

ところが様子を見ていると、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でも入れてみるかな…

コンピュータのシステムを作るという仕事をしていると資料なるものをたくさん作るはめになります。
正直この時間で動くコードを書けばいいのにと思いますが、なぜかそういうことになっています。

打ち合わせの相手もいろいろです。
自分の肩書は「営業」ではありませんが、お客様のところに赴き、説明することもありますし、サーバのセットアップ作業を行うベンダーや、ネットワークの構築を担当する人に作業のお願いをする…なんていうシチュエーションもあります。

仕事ではロクにプログラムなどを書かないSEが、どのようなことに気をつけて打ち合わせの資料を準備しているか、自分の備忘もかねて、

• 打ち合わせ調整
• 資料作成
• 打ち合わせ当日

で気をつけていることを書いておこうと思います。

打ち合わせ調整時

打ち合わせの目的をはっきりさせておく

打ち合わせの調整時に意識していることはひとつ。
打ち合わせの目的をあらかじめ決めてしまう…ということです。

たとえば顧客相手であれば、その打ち合わせは…

• プロジェクトの途中経過の報告
• エライひとから開発Goサインを得る
• 開発内容の調整

といったものになるでしょう。

電話などで日時の調整をすると同時に、打ち合わせの位置付けもいっしょにメールを送ることで握っておきます。相手かたの窓口さんは目的に応じて、出席者を調整してくれるでしょう。
これで、資料の方向性をぶらさずに準備することができます。
当日のアジェンダを用意するときの参考になります。

資料作成時

誰に向かって話すか決める

誰にむかってメッセージを伝えたいのかを決めます。
紙であれば1枚ごとに、パワポでのプレゼンであれば1枚ごとに誰に対してメッセージを伝えたいのかぶらさないでおくのがいいと考えています。

• エライひと: お金まわりのこと、なにがうれしいのか…など
• 現場のひと: そのシステムで仕事がまわるのか、要望にこたえているか、現場の問題は解決するか…など

ベンダーとの打ち合わせであれば

• 営業: 費用感、期間…など
• SE: 実際にやる作業のイメージ…など

話す相手によって使う言葉も変える必要があります。
技術に興味のない、顧客のエライひとに技術用語使いまくっても、睡眠導入の助けになるだけです。
また、顧客のシステムの話をするのに業界用語や顧客社内で使われている用語を誤って使うことがないようによく意味を確認します。

言いたいことは資料の最初のほうに

言いたいことは早めに伝えてしまいましょう。
序論→本論→結論、起承転結の流れだと結論が最後に来ますが頭でも結論じみたことを伝えてしまったほうが頭に残りやすいと思います。
複数の議題が設定された打ち合わせでも、言いたいことを最低限伝えて資料はあとで読んでもらう…という次善の流れに持ちこむことができます。

接続性を考える

ストーリーを考える、とも言いかえられると思います。
たとえばお客さんに開発のGoサインをもらうための打ち合わせであれば「導入→結論→内容→判定」

打ち合わせ間の接続性

「前回の打ち合わせを受けまして…」という入りになる場合には、話のフックとして前回の打ち合わせの資料でキーになるページや、前回の議事録を参考資料として用意することで相手の頭が話題に入りやすいようにしておきます。

資料内の接続性

紙であれ、スライドであれ前のページ、前の項との間で矛盾や漏れ抜けがないかどうか確認しておきます。
内容がよく理解できないと、そういった間違いがないか一生懸命探すことに精力を費す出席者がまぎれることもありますので注意しておきたいところです。

数字はひとり歩きする

数字の扱いには慎重にします。

数字はひとり歩きするものです。
いつぞやの資料で書いてあった夢物語のような数字が、あとになって蒸し返されないとも限りません。
予期せぬひとり歩きを防ぐためには

• 数字には根拠を持たせる
• 数字の精度を上げるための作業に顧客を巻き込む

紙や電子媒体などの証拠になるものについては、数字は明記せず、口頭で伝えてしまうのも手だと考えています。
もちろん確証のある数字であれば、どんどん使います。

紙かプロジェクタか

打ち合わせ時の資料の媒体が

• 紙
• プロジェクタ

によって、字の大きさ、配色を考えます。
プロジェクタのときは、スライドの内容を補完するような細かい内容を記載した紙の資料を配布するというのも理解を助けることになると思います。

打ち合わせ当日

アジェンダを準備する

打ち合わせの目的、準備した資料などを記載しておきます。
調整時に伝えたことの再確認です。

目的は最初に宣言する

アジェンダでも書いてあることですが、あらためて
「本日はこの内容で開発着手の承認をいただくためにまいりました。まずは開発のきっかけになった課題の振り返りと対応する開発案から説明します」
「本日はプロジェクトの途中経過の報告となります。一部遅れはありますが、全体的には順調です。遅れに対する対策を中心にお話しします」
「先日発生したシステムトラブルの件でご報告にあがりました。ご迷惑をおかけしたことをおわびいたします。発生した事象とそれに対応する改修案をご説明いたします」
「現在、開発を前提に話が進んでいる○○の件で、御社にお願いしたい事項をおつたえします。見積をお願いするための説明となります」
などなど。口頭でも議題設定して念を押します。

相手の反応を見る

資料作成時に設定したメッセージを伝えたい相手がどのような反応をしているか、観察しながら話します。
うなずいているか? 今説明をしているページを読んでくれているか? などです。
今まさに話をしている相手が想定していない動作をしているときは、「今○ページです」などとページを読むように導くようにします。

最後に

もっといろんなことを気にしているような気がするのですが、ぱっと思い出せるだけでこれだけあります。
気がついたことがあれば、随時追記していきたいと思います。
まとめてしまうと、相手にどれだけ気をつかった資料になれるか、ということなんですけどね。

詳細は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あたりに事件を取材していただいて、報道してもらいたいです。

システムエンジニアという仕事をしていると「上流工程」とか「下流工程」という言葉を使うことがありますが、この言葉は嫌いです。

人月での見積りでは「上流工程」には単価が高いとされる要件定義などをし、「下流工程」には単価が安いとされる開発やテストなどを含むのも一因でしょう。
上流や下流のように「上下」が熟語に含まれるとそこに「上下関係」があるような錯覚を抱いてしまいます。別に上流工程ができるからってエライなんてことないのに。

運用こそが上流工程，開発は下流工程 – 記者の眼：ITpro
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020916/1/

だからこそ上記のような記事も登場していたわけです。
でも「どっちがエライ」のレベルから抜けられていないですね。

それに「上流工程」に至るまでには、日々の運用での気づきや問題点が大事なinputになるというのに完全に軽視しているような印象もあります。作れば終わりだと思っているから、日々の運用のことなんか考えないシステムができあがるのではないでしょうか。

そこで、上流、下流なんてせこいあらそいから一歩引いて、水の循環にまで視野を広げてしまえばどうでしょう。

上流、下流なんて全体のごく一部の話で海に流れてから、雲になり、雨となり、地下水となって、やっと河川の上流という表面に出てくる。
このように考えれば、日々の運用も「次の案件へつながることなんだ…」と軽視されることはなくなるし、開発にあたる河川の上流から下流というのは一部のことだというのが理解できるのではないかと思うのです。

私はそのように考えて仕事をしているつもりです。

［XDev］「COBOLは現役バリバリ」，東京海上日動がシステム全面再構築でCOBOLを選んだワケ：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20080906/314277/

「システムが複雑になったのはビジネスが複雑になったため」とぴしゃりと言う。「システムトラブルの原因を“COBOLを使っているからだ”などと話す人や“COBOLは化石”などと話している人を見ると，ビジネスに携わる技術者として見識を疑う。

トラブルの原因が「使用言語」のせいという人には確かに見識を疑う。まったく同意なんですが。
「ビジネスが複雑になってもシステムはシンプル」という作りになっていなかったのも。
○○区分が横にたくさん並んでいるテーブルが温存されていたら、保守性は低そうだよなぁ。

プロジェクトの要件では，「プログラミングと単体テストを5カ月で終了しなければいけないスケジュールを乗り切るには，これまでのノウハウや人材を生かしきらなければならないと判断した」という。

COBOLしかわからない人を大量に抱えていたら、こうせざるを得ないだろうなと思う。
これまでのノウハウを活かしたということは、新しい知見を入れられていないということかもしれず。

となると、

稲葉取締役は「開発1年・保守10年」と東京海上日動内で伝統的に伝わる「戒めの言葉」（稲葉取締役）を引いた。「システムは開発して終わりではない，いかにそれを高い効率と信頼性を保って保守していくかが欠かせない」

ここが気になる!
どのようにして「高い効率と信頼性を保って保守」しようとしているのか。

当然そのための工夫とか、COBOLでもテストを自動化する仕組みとかいろいろあるんだろうけど。
記事がCOBOLに焦点当てすぎているせいか、表に出ていないですね。

今度チャンスがあれば質問してみたいところです。

「どんなに悪い事例とされていることでも、それが始められたそもそものきっかけは立派なものであった。」
(ユリウス・カエサル)

犯行予告の収集・通報サイト – 予告in
http://yokoku.in/

予告.inのことを見ていたら冒頭の言葉が思いだされました。
「数億円かかるとか大臣はのたまうが、うちがすぐにつくっちゃる!」
と完全な善意で構築されたものですが…

予告.inもそろそろ威力業務妨害 – novtan別館
http://d.hatena.ne.jp/NOV1975/20080805/p2

予告.in自体に悪意がない、ということがいつまで免罪符になるのかには興味がある

しかし、批判の記事も出てきた今「なんでこんなことになってしまったのか」「批判されるような現状に陥いらずにすんだのか」を考えてみたくなったので、みました。

スタートライン

以下、孫びき。

矢野さとるは数億円の税金の無駄遣いを止めたのかもしれない。 – VENTURE VIEW

http://v.japan.cnet.com/blog/murakami/2008/06/12/entry_27004188/

[2008/06/11 20:57:32] satoru.netの発言:
たぶんソリューションとコミュニティーの２つの要素でやるべきと考える..
[2008/06/11 20:57:48] fukuyuki MURAKAMIの発言:
と、ゆーと？
[2008/06/11 20:57:54] satoru.netの発言:
つまり人海戦術で集める情報とロジック的に　殺す　殺人予告　とかであつまってくるＵＲＬを分析する２軸でやったほーが確実だとおもう

孫引きここまで。

・システムで対応する部分「殺すなどのワードでひっかかったURLの分析」
・コミュニティで対応する部分「人海戦術で集める情報」
が明示されています。

問題が起きているのは後者の運営、運用のようです。

運営の問題

今となっては、結果論ばかり。

他人の善意を頼る運営の危険性

犯罪予告を取り扱うというのは、センシティブなことですから、

• コミュニティ側の人間は実名で活動する
• ユーザ・パスワードによる認証をする

といった回避策が必要だったかもしれません。

匿名の悪意なんだか善意なんだかの様相を示しています。

通報に関する基準を作らなかったこと

通報に関する基準を設けて、できれば警察のひととコンセンサスをとっておけばよかったんじゃないでしょうか。
脊髄反射で通報を行なっているようにしか見えない、現状では。

犯行予告を共有するサイト「予告.in」はもう限界に達している – GIGAZINE
http://gigazine.net/index.php?/news/comments/20080731_yokoku_in_limit/

つまり、「犯行予告を収集する」のが本来の目的であり、それを見て通報するかどうかは利用者の判断にゆだねられるべきであって、たった一人の個人が判断すべきものではない、というわけ。判断できる限界を突破してしまっているがゆえに、拡大解釈を行って、犯行予告っぽいものは警察にとにかく通報しまくる、という現状になっているのです。

運用のことを考えるコスト(時間・費用)

システムを企画するとき、サービス、機能と同時に、「運用を始めたら、どういうイベントがあるのか?」ということを考える必要があると思います。イベントをリスクと言い換えてもいいかもしれません。
これを考えておかないと、あとで痛い目を見ます。
もしかしたら、盛りこむべき機能・設計に跳ねる事項かもしれないからです。

たとえばgoogleであれば、たくさんのユーザが同時に検索したり、サーバを追加したりなどといったイベントを考慮しないで設計・実装していたら…
検索結果の評判を聞いたユーザが殺到した時点で、レスポンスが落ちて、それ以上ユーザが増えなかったかもしれません。
Webページの情報を増やすことができなくなって、そもそもの売りであった検索結果の品質が下がってしまったかもしれません。
現在のgoogleではなかったでしょう。

身近でも、隣のサーバが保守期限切れで更改されることを考えていないシステムとか、Oracleのサポートが切れることを考えていなかったりとか、あるからなぁ。

もしかしたら、「数億円」のなかにはそういった「運用開始後のことを考えるコスト」も含まれていたのかな…と考えてみたり。

おこがましくも評価

予告.inが俺も死ぬほど嫌い
http://anond.hatelabo.jp/20080803232429

それで解ったんだけど、ああ、この人は自分が運営しているサイトが起こす問題を
仮定して、検証する作業もしてなかったんだなーとびっくりした。

予告.inの場合、スピード重視で機能面を満たしたシステムを見事に作りあげました。XSSへの対応も迅速だったと思います。
ただ、XSSに対応したような労力を多少なりとも割いて、先に上げた2点について、途中で軌道修正することもできたと思うのです。
運営を続けていくのなら、今からでもやるべきだと思います。

ただ、予告を集める場を作るということをやっても、ほとんど役に立たないということがわかった点は、それほど「悪い事例」ではないとは思います。
2億円の無駄遣いを防いだわけですから。

予告なしで凶行を実行する輩には、まったく無力でしたし。
悲しいけど。

システム開発現場の活気を取戻そう（中）ウォーターフォールからの脱却 ビジネス-次世代ＩＴ産業論考（浜口友一）: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)

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

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

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

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

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

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