特許庁の議事録をちょこっと見てのよた話

Ryo 登山系ITエンジニア @RKTM

特許庁のシステムリプレイス中断の議事録が面白い。 ※PDF注意 >第１回特許庁情報システムに関する技術検証委員会議事概要 http://t.co/Ct4hj3ZJ

Ryo 登山系ITエンジニア @RKTM

『そういう関係を実現しようとすると、同じようなソフトウェアが作られることになるがそういうことかと確認したところ、ＴＳＯＬの回答は、コピーペーストするという話であった。』

Ryo 登山系ITエンジニア @RKTM

『そこで、修正が必要になったらどうするか聞いたら、それは大もとを直して、同じことを他の部分でもやれば修正できる、という回答をもらった記憶がある。普通に考えると、これはそのとおりである。』

Ryo 登山系ITエンジニア @RKTM

『大事なところは、では、どの業務のところにどの部分の元のソフトウェアをコピーペーストするのか、あるいは修正する場合において、どの元の部分の修正を他のどの部分の修正に展開するのか、その管理表はあるか質問したら、それはないという回答だった』

Ryo 登山系ITエンジニア @RKTM

第二回の議事録 ※PDF注意 >第２回特許庁情報システムに関する技術検証委員会議事概要 http://t.co/RH9UlCg6

Ryo 登山系ITエンジニア @RKTM

なんとも。 >『今回、設計書等の情報提供を行った際、後続業者になる可能性のあるベンダに意見を聞いたところ、とても受けられないという回答であったことから、心配したとおりの品質だったことは外部の目から見ても明らかだったといえる。』

Ryo 登山系ITエンジニア @RKTM

『もし結合テストとか、実施をやるときにトラブルが起こって元に戻ったときは、ＴＳＯＬはどうするという答は出ていない。そして、そこに責任がないということになると、動く保証がないということになる。』

Ryo 登山系ITエンジニア @RKTM

『一番大事なポイントは、ＵＡ業者が後に引き継いでできるかどうかということだが、これまでの話では無理。なぜかというと、ＴＳＯＬができないのに、これまでの経緯等を知らないＵＡ業者にはできない。』

Ryo 登山系ITエンジニア @RKTM

『元々の契約自体はこういうシステムをつくってくださいということを請負でＴＳＯＬにお願いをしたということに尽きており、請負というものの一般則に照らせば、成果ができればよし、できなかった場合にはできないということに対して何かの責任を負わなければいけない。』

Ryo 登山系ITエンジニア @RKTM

『担務の変更をＴＳＯＬが申し出てきたということは一体どういうことを意味するのかということについて、ＴＳＯＬが十分に考えて言ってきたのか分からない。』

Ryo 登山系ITエンジニア @RKTM

特許庁情報システムに関する技術検証委員会 > http://t.co/tYc0t7Lh

みかまま @mikantsuki

そんなおもろいのが！ RT @RKTM: 『大事なところは、では、どの業務のところにどの部分の元のソフトウェアをコピーペーストするのか、あるいは修正する場合において、どの元の部分の修正を他のどの部分の修正に展開するのか、その管理表はあるか質問したら、それはないという回答だった』

みかまま @mikantsuki

とりあえず、特許庁の件の議事録は全部ダウンロードだけはしてたんだけど、まだ読んでなかった。第１回目から飛ばしてんなー＜同じ動作はコピペでしかも管理してないよ！

わんこ (TOKUYA) @key_o

@mikantsuki ま、業務系 SE に、「OO って何？おいしいの？」って手合いはゴロゴロしてるワケで。(^.^)

みかまま @mikantsuki

@key_o 結合度、凝集性の話はOO以前ですう（OOはそれらがやりやすい仕組みを提供してるだけ） せめて関数使ってくれー局所変数と値渡しで局所化してくれええ

みかまま @mikantsuki

アプリが互いに疎でもライブラリつーかミドル層作れるじゃろ、コピペはないわあ。共通部分絞り出す前に個別業務アプリ実装走らせたの？えーなんで？＜第１回特許庁情報システムに関する技術検証委員会議事概要 でっかいものをでっかいまま抱え込んで崩壊したようにしか見えない件

みかまま @mikantsuki

配布資料の方の「意見」（haifu1_siryou3-1.pdf p.18）見るに、そもそも対象業務の分析してないんじゃないのこれ…「システム上のエラー処理のみならず、業務上のエラーについても設計されていない。このためシステム保守が困難」「「業務フロー」等が欠如」

わんこ (TOKUYA) @key_o

@mikantsuki あ、それはそうですね。でも、Java や C# で開発するのに OO を知らないのはいかがなものかと。文系 SE は撲滅したい．．．

みかまま @mikantsuki

@key_o 文系学部出ててもちゃんと勉強して概念理解してる人もいっぱいいますけどね（工学部でも専門違えばやはり知識はない） 概念を知らなければOO言語付けってもOOにならないのはそう（という話を講義で延々としてるわけですが）

わんこ (TOKUYA) @key_o

@mikantsuki 今迄一緒に仕事して「おぉ！」って思える人はまづ理系出身なんですよねぇ．．．文系出身で「おぉ！」って思える人見たことなくて。まぁ、見てる世界が狭いといえば狭いですが。(^.^;;;)

みかまま @mikantsuki

@key_o まあまず最近は数学ができるできないで理系文系分けちゃいますからね。数学が苦手ってことは抽象化が苦手ということなので。といえ、抽象ばかりでも現実相手ではダメなところがあって。抽象と具象の間をバランス良く行き来できるタイプが最強かな、と思う今日この頃

わんこ (TOKUYA) @key_o

@mikantsuki あ、そうですねぇ。抽象と具象のバランスか。確かに。「おぉ！」って思える人はみんなモデル化うまいものなぁ．．．

みかまま @mikantsuki

数万行あるクラスとか、数千行あるメソッドとか、引数が数十個あるメソッドとか、世の中には、何をどうしたらそうなるんだろうという不思議が転がってますね。リファクタリングの本の例題は短いけれどなかなか良く出来てるよなと、説明しながら思ったりした今日この頃

かろしま かろあき 📯 @karoshima

いちど動作確認済んだ箇所に手を加えるのって、とっても嫌われる。共通部をライブラリに切り出せないのは、そのせい。ライブラリ改修で関係者総スカンとかそれ以前に、ライブラリとして切り出すことすら憚られる。だからコピペ化が進む。船頭ばかり多いとトコトンつまらん。

みかまま @mikantsuki

なるほど、アジャイルで「変更する勇気」が勇気と言われる所以、と＜「ライブラリ改修で関係者総スカンとかそれ以前に、ライブラリとして切り出すことすら憚られる。」