読者です 読者をやめる 読者になる 読者になる

myatsumoto blog

マツモティウスです

プロジェクトにおけるグレシャムの法則的なやつについて

あるプロダクトが人気なとき、大抵は

社会的な価値・表面的な価値

が人気の原因なので

内部のコードは質が良かろうが悪かろうが人気は出る。

その場合、作る人間にとっては最速で終わらせる方がお得。
自分の最速で書いたコードが良質なモノになる人はあまり居ないので
コードはどんどん複雑化していく。(それでも人気は出る)

要するに、
人気プロダクトでは糞コードが良コードを駆逐する

成功しているプロダクトやプロジェクトが
なぜか酷い構造になっていることが多くて疑問に思っていたが、
こういう感じなら説明がつく気がする。

間違っても、ゲンを担いで意図的に汚いコードを書いてはいけない。
人気が出ればコードは勝手に汚くなる。

ちなみにプロダクトが斜陽化しだすと
不調の原因を今まで見なかったことにしていたコードに見出して
急に作り直しを宣言したり、急にリファクタリングを意識するようになる気がする。

特許庁の情報システムについて - 技術検証委員会の議事録

特許庁の情報システムについて -
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554
で仕様については一通り調べ、内部フローの複雑さが障壁になったのではないか、という結論に至った。id:Dryad さんから技術検証委員会の議事録の存在を教えて頂いたので詳しい推移を調べている。

特許庁情報システムに関する技術検証委員会 -
http://www.jpo.go.jp/cgi/link.cgi?url=/shiryou/toushin/kenkyukai/jyouhou_iinkai.htm

技術検証委員会による審議会が全6回行われている。
まず、この審議会以前に設計について様々な問題が指摘されている。

特許庁情報システムに関する調査委員会報告書ご指摘に関する状況について -
http://www.jpo.go.jp/shiryou/toushin/kenkyukai/pdf/jyouhou_iinkai01_haifu/haifu1_siryou3-1.pdf

この資料によると

  • システム上のエラー処理のみならず、業務上のエラーについても設計されていない。このためシステム保守が困難。
  • 特許庁業務システムに知見のあるSEが見ても、設計書の内容理解に時間を要した。
  • 機能的に冗長な設計となっており開発規模が膨大となる。このため後工程でテストが完了しても、稼働後の保守が行えない。
  • ハードウェア等の設計を行う際に、業務量の日内変動(ピーク時)が考慮されていないため、過小なハードウェア調達となり、性能不足に陥る懸念がある

など基本的に設計的な問題点が指摘されておりこの時点で3000件ほどの残件があった。おそらく相当冗長な設計になっていたのだと思われる。

2011年9月8日に行われた第一回の審議会はこれら問題を踏まえて対応が検討されている。
第1回議事要旨 -
http://www.jpo.go.jp/shiryou/toushin/kenkyukai/pdf/jyouhou_iinkai/giji1.pdf

最初の方に残件の理由が書かれている。

東芝ソリューション(株)からのヒアリング>
残件の発生原因として、共通したものはあるか

通常、プログラミングでは「クローンの弊害」とかよく言われていて、クローンは作るべきではないのだが、このプロジェクトでは、設計段階でクローンを非常にたくさん作ってしまい、明らかにクローンの弊害が出ている。つまり、既に検証された部分をコピーペーストしてクローンを作るのではなくて、品質が検証される前の段階でクローンをつくってしまっているので、元の設計箇所に問題があると当然そのクローンの分だけ修正対象箇所が増えていく。

未完成のコードをコピペして使ってたことが残件の主な原因だったと言っている。
コードをコピペして使っていると、コピペ元に変更があるとコピペ先も修正せねばならず手間が掛かる上にコピペが増えていくと修正箇所が把握できなくなっていく。なので、コードを共通化して使うのは初歩的な手法だが、これを見るにTSOLは動く処理ならコピペすることを良しとしていたようだ。
これならコード量が膨らむのも納得できる。

TSOL社の共通化していくという提案自体はよかったと思う。だが、それを特許庁の設計の具体的な工程の中で、どのように実現し、どのスケジュールに沿ってやっていくのかというところが、肝心のTSOLから出てこなかったということで、これではこの共通化が目測どおりにできるだろうという見地には立てなかった。

とあり、TSOLからは膨大化した設計に対し「共通化する」対応策を提案されたが、現実的なスケジュールなどが提示されなかったようである。

最後の討議では

今日の各者の話を聞いていると、アクセンチュアは、もう思いの上では止まっていました、という感じなので、印象としてもうほとんど破綻しているのかなという感じがする。

TSOLすら、このプロジェクトを少なくとも今のまま進めていく可能性があるとはおっしゃらなかったし、アクセンチュアも手戻りすることを前提とした議論だったと認識している

と第一回の時点でかなり諦めに入っていることが分かる。

一週間後に行われた第二回では既に責任追及の会議になっている。
第2回議事要旨 -
http://www.jpo.go.jp/shiryou/toushin/kenkyukai/pdf/jyouhou_iinkai/giji2.pdf

担務の変更をTSOLが申し出てきたということは一体どういうことを意味するのかということについて、TSOLが十分に考えて言ってきたのか分からない。すなわち、最初の契約のところで請け負ったはずのことと違う方向へ行ってしまうわけであるが、TSOLは、それは大きな問題であるという認識がないのか。

担務の変更をする、しないとかも含めて、平成29年1月までにシステムができるかどうか分からないという状態自体が問題と思っている。外部の意見からは、設計書の品質が悪くて入れない、UA業者としては入れない、ということだが、基幹的なものも含めて平成29年1月にできそうかどうかは、まず明確にした上で、できそうでないということであればどういう対応ができるのかを検討したい。

平成29年(2017年)の1月でもシステムができるかどうか分からない、という状態だった。
本来の稼働予定時期は平成26年なので計画段階で3年延期されている。

要するに、ちゃんとしたものを早く作りたいわけだが、今までの経過からすると、TSOLに任せてできるのかといったら、TSOLはアクセンチュアが言ったことが渡りに船で、私はもうここから先はできませんとこういったわけで、それで29年1月というのは、根拠は何かと言えば、その中身はよく分からない。

第三回では今後の対応について検討されており、第四回では途中段階のシステムの利用可能性について検討されている。第五回、第六回の審議会は詳細が記されていない。

第四回で

現在の段階で一番バーを高くしているのは開発規模だと思う。アーキテクチャーの難しさと規模というのは相関があり、ある程度難しいアーキテクチャーでも、ある程度の規模であれば実現可能性は高いが、規模が一定程度を超えると、極めて簡素なアーキテクチャーでも難しい状況が出てくることは、ままあるので、その規模をどう考えるかだと思う。規模の壁をそのまま置いておいていいのかというのが一つの議論ではないか。できないことではないと思うが、それなりの体制、それなりの期間、それなりの費用が必要だと思う。

とTSOL側(発言者が書かれていないので推測)から発言されており、基幹系大規模開発の障壁が垣間見えたように感じた。

あまり技術的な部分を詳しく見ることは出来なかったが、前回の記事も含めてまとめると

  • 検索などのアルゴリズム面での仕様はそこまで難しくなかった
  • 複雑な内部利用ケースに対し、設計が膨大化したのが障壁だった
  • コードが凄い量になった上に残件が多かったのは処理をコピペしてた所為
  • このような体制で基幹系の超大規模開発をしてしまったことが原因

という感じだろうか。

技術的な原因をまとめたが、
なぜ大手は下請けに回すのか、とか、なぜ大手だけが公共事業の仕事を貰えるのか
など別な視点からの疑問は色々ある。根本的には業界の腐敗の構造が引き起こしているのだと思われるが、その構造自体もなぜ出来たのか、という点は大いに興味がある。こういう組織の腐敗を調べるのは非常にタメになるので、今後も機会があれば調べたい。

特許庁の情報システムについて

例の特許庁の情報システム刷新の頓挫について興味があるので調べている
http://itpro.nikkeibp.co.jp/article/NEWS/20120120/379019/?ST=cio

とりあえず、まとめブログで探したのだが
http://alfalfalfa.com/archives/5124175.html
mP78iXTkの言ってることが尤もらしいので参考にして
報告書と照らし合わせてみたら全然違った。

特許庁の報告書に不備が60M項目あると書いてあったろ?
オレの説明したのはその中の1個の話w

とりあえず2chは1,000レスしか出来ないが説明欲しいか?

60Mステップは開発規模の話であって不備の話ではない。
報告書には

開 発 規 模 に つ い て は 、平 成 2 2 年 1 2 月 、約 6 0 M ス テ ッ プ に 達 す る と の 見 積 も り が T S O L か ら 示 さ れ た た め 、 三 者 は 規 模 削 減 策 の 検 討 を 開 始 し た

と書いてあった。一般的にはステップは行、Mはミリオンを指す。
つまり当初は6000万行書く見積もりだったということである。6000万行は凄い。しかも、その後

T S O L か ら は 、 そ の 後 、 設 計 書 の 共 通 化 に よ り 、 約 3 1 M ス テ ッ プ ま で 削 減 可 能 と の 案 が 示 さ れ た が 、 同 時 に 、 当 該 共 通 化 を 含 め た 設 計 書 の 修 正 に は 追 加 的 に 約 2 年 を 要 し 、 結 果 と し て 、 シ ス テ ム の 最 終 稼 働 は 現 行 予 定 か ら 3 年 遅 れ の 平 成 2 9 年 1 月 に な る と の 試 算 が 示 さ れ た 。

TSOL(東芝)から3000万行削減可能という見積もりが出されており更に凄い。

再びEuP54fOGの発言から

特許Aがある。
出願されたBは特許Aに引っかかっつ特許にならなかった。

翌年馬鹿が出願Cを出したがまたダブり。

しかし審査官が示した拒絶引用は取り消された出願Bだった。
BをみればAの情報が引ける。

そんな調子で何百も階層が出来て行く。
深層化された時点でまずGoogleアーキテクチャはハイ消えましたw

ところが10年経って係争中だった出願Bが審判で逆転されて無事特許になりました。

Bを参照してた出願Cは見直し、
複合参照してた物、全部見直し。
そをやな深層化されたサーチ文献を一発1秒検索してたのがNTTデータの作った1400億のシステムだった。

これはリンク構造の話をしているのだと思われる。
もし数百万以上あるであろう特許申請の特定のノードから辿りつけるノード全てを割り出し、何ステップで行けるかを1秒で出しているシステムならば凄いが、どうもそうは思えない。
本当の仕様はどのように複雑なのか、機能面の仕様を調べた。

まず技術報告書には

技 術 的 に は 、 刷 新 後 の 運 営 基 盤 シ ス テ ム が 、 既 存 の シ ス テ ム 構 造 の 根 本 的 な 見 直 し を 伴 う 記 録 原 本 一 元 化 を 中 心 と し た 新 規 の シ ス テ ム ア ー キ テ ク チ ャ を 採 用 し た こ と 、 構 造 的 に は 、 刷 新 の 対 象 と な る 既 存 の 事 務 処 理 シ ス テ ム が 、 年 3 4 万 件 ( 特 許 ) も の 出 願 受 付 か ら 権 利 登 録 等 に 至 る 多 岐 に わ た る 業 務 を 対 象 と し た 複 雑 か つ 大 規 模 な シ ス テ ム で あ る こ と と が あ い ま っ て 、 本 プ ロ ジ ェ ク ト は 、 技 術 的 難 易 度 が 高 い も の と な っ て い る 。

とある。年34万件は一日900件ほどの登録。
数字自体はそんなに多くないが、このシステムはよくある掲示板のような単純なシステムではないはずである。

特許庁業務・システム最適化計画」(改訂版)について
http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm
ここに様々な概要が書いてある。

システム的な概要は

  1. 24時間365日のインターネット出願
  2. 公報発行のインターネット化
  3. インタラクティブ申請(申請書作成支援)
  4. 特許庁保有の出願情報等のリアルタイム提供・無料化
  5. 審査・審理関連情報の提供

とあった。詳しい説明を見ていく。

まずインフラ面は

現在、検索システムにおいて、年間2億アクセス以上の利用がなされているが、上記長期目標を実現する際のアクセスの増加に対応すること等により、審査業務のレベル(審査の質)を維持していく。

一日55万くらいのアクセスに耐えうるインフラを要求されている。これはサーバをそれなりに用意しなければならず、統合的な管理も必要なので、まあまあ面倒臭い。

次に実際のアプリケーションの機能部分
24時間365日のインターネット出願

いまは、出願受付は開庁日の9時から22時、発送、閲覧等は開庁日の9時から17時となっている

一般開放中に不具合が起きても対応が出来るように時間制限を設けていると思われる。そのクオリティを維持したまま年中無休の一般開放を実現するには、24時間体勢のサポセンみたいなのを入れる必要が出てくるだろう。

また、「検索機能の提供」については、現在、IPDLにおいても検索を行うことが可能であるが、これ以外に、特許庁の審査官が内部使用している検索システム(・Fターム検索に加え全文テキスト検索が可能 ・検索項目を自由に組み合わせる検索が可能 ・国内外の特許文献をシームレス、かつ、高速にスクリーニング可能等が特徴)が存在する。この検索システムは、サーバの負荷等の状況から、対外的に提供できる状態になっておらず、現段階では先行技術調査を専ら行う登録調査機関など、限定された形で対外的に提供されている形となっているが、産業界においては研究開発の戦略化などの観点から、検索機能の向上が重要であるとの意見も強い。

Fタームは特許文献の分類を示した記号である。1つの文献に対し複数つけられるのでタグ検索のような機能だと想像できる。全文検索とAND/OR検索と検索フィルタがあるようだが、対外的に提供できる状態になっていない、のでシステム自体は遅いのだろう。

インタラクティブ申請(申請書作成支援システム)の導入

現在、出願人・代理人が電子出願等のオンライン手続き(年間200万件以上)を行う際には、特許庁から提供される電子出願ソフトを、自己保有のパーソナルコンピュータにインストールすることが必要である。当該電子出願ソフトには、エラーチェック機能がついており、作成した出願等の手続書類に何らかの不備がある場合には、提出する前に警告がなされる仕組みとなっている。 しかしながら、現在のエラーチェック機能では、既に出願人から特許庁に提出された手続書類との連携を図ったチェック(例えば、特許の請求項数や申請人情報が既に特許庁に登録されている情報と一致しているか等のチェック)を行うことはできず、専ら出願人・代理人側で管理する必要がある。 このため、出願人の利便性を更に向上させる観点から、出願人が既に出願している同一案件に関する各種申請書類を作成する際に、特許庁のデータベースからオンラインでその出願内容に関する情報を予め申請書類に反映することにより、出願人の申請書作成を支援する機能(インタラクティブ申請(申請書作成支援システム))を新事務処理システム(平成23年1月を目途)により実現する。

要するにフォームに入力した時に既に取られたIDか、とか、既に登録した情報はフォームに入れておく、みたいなことをやりたいらしい。これはデータベースを参照してフォームの補完やエラーチェックを適宜行えば良いので大きな技術的障壁ではない。

データ提供のリアルタイム化

IPDLにおけるデータ提供については、現在、庁内データを再編集した「整理標準化データ」を用いているため、この再編集に要する期間(概ね2月程度)だけ公表の遅れが生じている。このため、複数の企業から「IPDLの経過情報の更新が遅い」との意見が出されるなど、データ提供をリアルタイム化することにつき産業界から要望されている。 また、登録公報に関し、現在、Xフォーマットのものについては、編纂外注期11間(概ね5週程度)が発生しているが、XMLフォーマットのものについては、自動編纂の対象となるため、Xフォーマットのものと比して編纂期間を概ね3週程度短縮することが可能である。 このような現状を踏まえ、新事務処理システムにおいては、システム構造の簡素化や公報自動編集の浸透等を通じて、再編集に要する期間をなくし、平成23年1月を目途にリアルタイム化することとする。

リアルタイム化、というので何かと思ったら登録から2ヶ月も情報公開が遅れているのをなくすということだった。

現在、IPDLから公報情報、リアルタイムではない経過情報等がインターネットを通じて広く一般に開放されており、毎月約450万件の検索が行われているが、企業における事業戦略や知財戦略の策定に有用な情報である包袋情報についてはIPDLを通じた無料提供が行われていない。 しかしながら、産業界からは、既に提供している公報情報、経過情報等に加え、包袋情報の無料提供を求める声が大きい。 欧州特許庁や米国特許商標庁においては、既に同様の包袋情報を無料で広く一般に提供しているという点も踏まえ、今後、包袋情報を公衆に対して無料で提供することとする。当面の措置として、平成 18年度初頭から試行的に無料提供を開始するが、本格的な提供は新事務処理システム(平成23年1月を目途)により対応することとする。

”包袋”とは、特許出願、商標出願等の出願経過で「出願以後の特許庁と出願人とのやりとり」を指す。これも構造としては指定された包袋の内容を文書として提示すれば良いだけなはずである。

検索機能の提供の拡大

現在、IPDLによって毎月約450万件の検索が行われているが、そこで提供されている検索機能は、特許庁の審査官が内部使用しているシステムと比較した場合、全文テキスト検索ができないなど機能が劣ることから、検索ツールの機能を充実させることが産業界から強く望まれている。

検索システムに関しては先程も出たが、一般向けのシステムでは全文検索が出来ない。一般向けに公開できない理由はおそらく遅くて止まってしまうからだろう。

以上、今後作られる予定であったシステムの主要な仕様に関してまとめた。
以前の仕様でもバッチプログラムで登録してるから1週間に1回しか更新が反映されないとか色々非効率な点があった。

この時点で以前のシステムは昔作られたものとは言え優秀であるとは言えない。この技術力では例の被引用探索などもっての他でありデマであると言えよう。そして、TSOLが対応するはずだった仕様に関しても技術的にはそこまで困難ではないと思われる。

次に業務体系の図を見てみたが、これは結構大変そうだった。
業務流れ図 -
http://www.jpo.go.jp/torikumi/system/pdf/system_optimize_re/shourai_1_3.pdf
f:id:myatsmoto:20120126074948j:plain
これは矢印の方向にデータを色々フォーマットして送っている図で、それぞれデータの内容を送信先に合わせて加工して送っている。どのようにフォーマットするかも上記資料に記載されている。
東芝の力量をよく知らないので何とも言えないが、頓挫の原因はこのあたりの内部利用ケースの複雑さにありそうだ。

ちなみに

本 プ ロ ジ ェ ク ト は 、 特 許 庁 、 T S O L 及 び ア ク セ ン チ ュ ア の 共 同 作 業 で は あ る も の の 、 受 注 者 た る T S O L の ス ケ ジ ュ ー ル 策 定 能 力 を 含 む プ ロ ジ ェ ク ト 管 理 能 力 ・ 設 計 開 発 能 力 が 十 分 で は 無 か っ た こ と が 、 プ ロ ジ ェ ク ト の 進 捗 を 大 き く 遅 延 さ せ た も の と 考 え ら れ る 。

とあり、特許庁アクセンチュアより東芝に怒っているようである。

コメントで技術検証委員会の議事録の存在を教えて頂いたので具体的な原因について調べた。
http://myatsumoto.hatenablog.com/entry/2012/01/27/040923

よかったこと、よくなかったこと

もうすぐ卒業する。

大学4年間のうち1年半は映像に費やし、2年半は情報工学に費やした。

情報工学の面で色々役に立ったことを書く。上の方ほど優先順位が高い。


行動的な面でやって良かったこと

  • 自前でサーバを建てる
  • 実際の現場でバイトする
  • 本を写経する
  • 本を買いまくる
  • 良いキーボードを使う
  • ツールは何でもデフォルトの状態で使う(例えばvimだったらプラグインは入れない)


行動的な面でやらないほうが良かったこと

  • 同世代の友達をつくる


思想的な面でやって良かったこと

  • とにかく常に考えてよく寝る
  • 何でも論理構造を見出すようにする
  • プロジェクトは絶対に他人と共同でやらない
  • とにかく何でも疑う


思想的な面でやらないほうが良かったこと

  • アイデアを人に話す


他にも大っぴらには言えないようなハックが色々ある。

誤解を招きそうなところだけ説明を加える


やって良かったこと : 本を写経する

やねうらお氏が三島由紀夫の小説をノート数冊分写経したというエピソードを話していたのを見て写経するようにした。

PCに打ち込んでも良い。慣れてくると怠けてアニメ見ながら打ち込んだりしていた。それでもやらないよりは数段良い。

最大だとハイパフォーマンスMySQLを写経した。最近はやらないが分からないものが出るとやる。


やらないほうが良かったこと : 同世代の友達をつくる

とにかく孤独にやり続けるとストイックになるし、だんだん頭がおかしくなってアイデアを生む。

逆に同世代のあんまり人生経験のない友達を多く作ると、そっちに染まってダメになる。

かずすけの予約とれた

かずすけの予約がとれた喜びを詩にしました
けいおんとかいう糞映画とは関係ありません。

    • -

「タン塩くえたよ!」

ねぇ 小腸のカケラに
名前をつけて保存するなら
”宝物”がぴったりだね

そう 胃(こころ)の容量が
いっぱいになるくらいに
過ごしたね 焦げ茶色の毎日

なじんだリポジトリの上書き
ダッシュボードの落書き
明日の入り口に置いてかなくちゃいけないのかな

でもね、食えたよ!すてきなタン塩
卒業は終わりじゃない
これからは社畜だから
一緒の写真たち
おそろいのキーボード
いつまでも輝いてる
ずっと その肉を ありがとう

    • -

かずすけ食い終わったら2番書く

GREE,DeNAへの謎の義憤について

ソーシャルゲーム界隈は糞というネットの認識があり
それは「情弱を騙して金を稼いでる」から、という感じ

「低学歴の人はやらない」という例のデマが流行るほど
「情弱を騙して商売する糞企業」という認識は強い

「情弱を騙して商売している」という批判は興味深い
なぜなら

そんなゲームに金を使う層より「自分の身分が上である」
という意識があり
なおかつ「その層を身分が上の自分たちが守る必要がある」
という意識もあることを意味するからだ

この言葉が批難である以上、義憤が少なからず存在する。
この差別と優しさ(?)の混じった身分意識を多数の人が持っているのは興味深い

これが社会的なタブーと紙一重であるために公の場などでは批難出来ず
モヤモヤとした感情を抱かせるのだと思われる。


これを解決する手段を2つ考えた

1.現状の階級社会を使う
現段階で公に差別できる階級は金以外に存在していない。
いいものはお金がないと買えず、税金は金持ちから多くとって貧乏人がもらえる
どちらも階級的な差別である。

貧乏人からしか金を取ってないことを証明すれば
金銭的弱者への冨の分配を妨げる社会的に非効率な企業である
としてビジネスモデルを叩ける

2.新しい階級をつくる
多数の人が差別と救済という清濁併せ呑んだ階級意識をもっているならば
新たな価値観の階級をつくることも可能である。

そもそも資本的階級しか公に認められていないことが、いまの状況を作っているとも言える

なぜなら、現段階で偉くなりたければ
公に認められている資本の階級を高めるのがもっとも正攻法である
そうなれば、頭のいい人間はそれを目指す。

階級的に偉くなる道はそこしかないから幾ら金を稼いでも、また金を稼ぐしかない
資本でしか公に評価されない所為で頭のいい人間がひたすら金を稼ぐように出来ている

別の評価軸も用意してやれば、そっちの道でも頑張ろうという優秀な人が出てきて
リソースやモチベーションが分散される。
もちろん、そういう評価軸が無いとは言わないが、皆欲しがるようなものが出来ていない

ゆるやかで且つ皆が窮乏するような階級を作れれば、行き過ぎた格差も少しは歯止めがかかりそうなものである
これが評価経済というやつか?