2015年2月 3日 (火)

日経SYSTEMS 2月号 「日本のソフトウェア契約はもう古い」

最新の日経SYSTEMS 2月号の表紙で、特集2「日本のソフトウェア契約はもう古い」が目に飛び込んできた。目次での絵を見たら、ペリーらしき人物が契約書を持ってるイラスト。誘導が上手くて^.^;、本文の方も読むことにした。

http://ec.nikkeibp.co.jp/item/backno/OS0262.html

タイムアンドマテリアル(T&M)契約など、米国で採用されている契約形態が表になってて分かりやすい。日本での請負契約やプロセスを絡めた説明も良くまとまっている。ただし、後半の米国ITコンサルタントからよく言われるという「なぜ日本ではこんな古い開発プロセス(ウォーターフォールモデル)を続けているのか」のあたりから、個人的に少しカチンときだした。新しい・古いという尺度しかないのかと言いたくなるし、じゃ「オバマケア」のトラブル状況はなんだったのかとか言いたくなってくる。

少し冷静になっても、後半部分に、じゃどうしたら良いかとか解決策の例示が無いのが残念に思えた。例えば、IPAでは「非ウォーターフォール型開発に適したモデル契約書」に対する案を公開している。(ちなみに以下は改訂版。)

https://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html

契約書案以外に、何年か前には、非ウォーターフォール型開発に関連して海外での契約形態をまとめた資料も公開されたはずだ。


結局、IPAでの案などいろんな形態の契約を参考にして、プロジェクトマネージャーが法務部門と掛け合って契約書にする必要がある。日本の契約が古いのなら、その辺りの交渉をちゃんと行おうという、気概のあるプロジェクトマネージャーへの提言があっても良かったと思った。

例えば本号に、IPAでの「基本/個別契約モデルの個別契約書案(請負型)」をベースにしたソフトウェア開発の雛形を法務に認めさせたなんていう事例が書かれていれば、もっとじっくり読んだんだろうけど、その辺りに踏み込んで書かれて無い。

さらに言えば、大抵の契約書には、”準拠法”と”第一審の専属的合意管轄裁判所”をどこにするかが書かれている。国内契約(東京都に本社のある企業)だと、日本国法律と東京地裁というケースが多い。これらは、ソフトウェアの使用許諾などに書かれていることが多いから、目にしたことがあるかもしれない。海外製だと、ニューヨーク州法が準拠法なんていうのが少なくない。

日本の請負と準委任が古い(問題)なら、準拠法をニューヨーク州法にするのも考えとしてはある。そこまで提言として踏み込んで書いてあっても良いかと思う。でも、国内のIT案件で、準拠法をニューヨーク州法にするなんて荒唐無稽。まずは法務が許さないだろう。やれアメリカの方が良いというのなら、裁判になってニューヨーク州法で対抗できるぞというプロジェクトマネージャーなら、どうにか法務を説得できるか、、。

アメリカの開発プロセスを良しとしたり向こうの契約が良いとしても、それを(特に後者)採用するには法律・判例とか裁判への対応が必要である。それらを踏まえての判断が必要だろう。


日本企業もグローバル化してるので、企業によっては海外SIの案件も増えてきている。あるいは、海外子会社での契約に目を光らす必要も出てきている。法務としてはいろんな契約形態があるだろうけど、雛形的には**と@@にするなどいくつかに絞っておかないと手間がかかる。契約雛形(ベース)を決めて必要に応じて後は記載社名の変更程度にするとか、個別での細部変更程度で済ませたい。法務だって、そう個別の案件に対応する時間はなく、買収など超ビッグな契約への対応も必要だ。それらも踏まえて、法務と掛け合うくらいの覚悟は必要だろう。


本号の見出しが少しセンセーショナルだっただけに、その辺りの踏み込みが無かったのが残念だ。

(個人的には、旧来の日本的契約をベースにしてプロジェクトに応じた変更を法務と交渉している人もいて、むしろそちらの方の対応の方が評価できると考えてはいる。)

2月 3, 2015 書籍・雑誌 | | コメント (0) | トラックバック (0)

2014年10月19日 (日)

ITプロジェクト成功率 30%→75%にアップ?

日経コンピュータ2014年10月16日号を読んでいて目に飛び込んできたのが、”高い成功率も油断は禁物”、”プロジェクト成功率は75%”。の文字。特集「3069人調査で迫る 情報システムのリアル」での、タイトルや見出しだ。

以前の日経コンピュータでは、成功率が30%程度だった。2008年12月1日号と2003年11月17日号での記事で、それぞれ31.1%と26.7%。以前”日経のプロジェクト成功率”としてブログに書いている。

つまり、ここ数年で成功率が30%→75%にアップしている。喜ばしい事だ。(ただし内心では、以前のブログの行間で述べたつもりだけど、数年前などでは回答側も分析側も失敗の方にバイアスがかかっていた気もする。)

数年前などでの日経の調査は、第1回と第2回の「プロジェクト実態調査」と題するものだった。5年ごとで、次は2013年と気にかけていたが雑誌には掲載されてない。なので今回の10月16日号が、それに代わるものと考えて良いだろう。ちなみにサンプルは全く同じかは不明だが、有効回答数は、2003年が1746、2008年が814、そして今回の2014年が3069なので、回答数自体は増えている。

個人的には、今回の方が実態と合致しているように思える。なお、工程での失敗率の分析や商習慣に対する回答、アジャイル導入比率などの分析も行われていて、参考になると思う。一読をお勧め。


ちなみに日経コンピュータ2014年10月16日号の目次ページは以下、
http://ec.nikkeibp.co.jp/item/backno/NC0871.html

日経コンピュータ2008年12月1日号の目次ページは以下である。
http://ec.nikkeibp.co.jp/item/backno/NC0718.html

10月 19, 2014 書籍・雑誌ソフトウェアプロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2014年8月 9日 (土)

マルスを振り返る

ここでのマルスは、国鉄時代の予約システム。MARS。

Facebookで知り合いが、急に昔の予約システムの”ピン”のことを述べたので、それはマルスだろうと2,3のURLをコメントした。

で、ふと、手元にマルスのことを書かれた本があったので読み直してみた。

マルス(正確にはその中での105というシステム)の開発プロジェクトで中心的な役割を担った名内氏の著作。

補論として31ページに渡って、マルス105プロジェクトのことが述べられている。

ちなみに名内氏は、その後日立製作所→日立システムアンドサービス(現:日立ソリューションズ)取締役社長に就任され、顧問を経て平成17年退任。


"業務機能仕様書"なるものが国鉄(発注側)から提出され、曖昧な所を日立側が指摘したそうだ。本には「システム稼動後、『こっちは客ではないか。なんで業者の担当からこき使われるかと思った』と懐かしげに話していただけたが、多分その時点では腹も立てられ、戸惑われたことと思うし、申し訳なかったと思う。」と記してある。

”線仕様”という言葉を用いているが、”**の時にどうする”は点仕様で、”**でない、@@の時”、”**でない、%%の時”のように非該当(非正常)の時の挙動を述べていくのを線仕様と称して、その記述を掘り下げたいったそうだ。(用語化してることや、その用語がなんかすんなり受け止められて、改めて驚いた。)

なお読み直して少し新鮮に感じたのは、スパイラル方式の方が優れていると言われているけど、一括請負などでは仕様を決めドキュメントを固めてから開発に入る方がよいとの記載。スパイラル方式→アジャイル方式と、置き換えて考えてみるのは良い事と思う。


一部は「国鉄との共同責任」という契約にしたそうだ。請負契約でもなければ、、、、。なるほど!と、ちょっと感心。ちなみに国鉄との共同責任という契約は、これっきりだそうだ。(逆に言えば、他のユーザーとはこのような契約もあったということ。) 

よくアジャイルなどで契約のことが話題になったりするけど、話題になるだけど、どう解決するとか前に進まない場合が多い。大昔に既にそんなことを解決してるのだから、現代人も自分たちで解決すればすむだろうにと思ってしまう。

あと”下ごしらえ”という言葉が登場する。結合テスト前に結合テストの項目が準備済み、そんな話。今だと、当たり前と思う人とそうでない人、後者の人がいるから厄介だ。なお、こっちの”下ごしらえ”という言葉もなかなか良い。

ほかに、ログのテストでの利用や「疎通」で喜ぶんじゃなくて「完通」で喜びなさいなど、実際実行してることが多いだろうが、確認する意味で役立つことがポツリポツリある。


ちなみに、日立ソリューションズのサイトに名内氏の特集ページがある。結構たくさんの種類の情報が掲載されている。(ただし、全部の回の閲覧のためには会員登録が必要。)
 http://www.hitachi-solutions.co.jp/psw/feature_list/nauchi.html


マルスは結構以前のシステムだし、その開発は文献やテレビ(特にプロジェクトX)に取り上げられている。温故知新で、他を含めて昔のプロジェクトを勉強してみるも悪くないと考える。なんか昨今は、プロジェクトは失敗するとのマスコミ記事を鵜呑みにしすぎてて、色んな過去の創意工夫を封じ込めてるような気がしてならない。マルスを振り返って、ふとそんなことを思った。

8月 9, 2014 書籍・雑誌電車プロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2014年7月 6日 (日)

ゴジラ特集 雑誌「pen」など

今年は、映画「ゴジラ」の封切りから60年。ゴジラ生誕60周年、そしてアメリカで公開されたハリウッド版「GODZILLA」の日本公開が近いことで、TVなどで往年の映画の放送や特集番組が組まれている。ちなみにハリウッド版の「GODZILLA」には1998年公開のものがあるが、従来のゴジラと形態的にも、そして作品のテーマとしても大きくかけ離れてて評判が芳しくない。なので、ここでの「GODZILLA」は、特に断らない限り今年公開の「GODZILLA」を指すものとする。

まず、書店で見つけた雑誌。本号での特集がゴジラで、映画一覧や自衛隊(防衛軍...)の兵器等がまとまっている。最初の「ゴジラ」製作でのエピソードや写真なども多い。

個人的にはお勧め。

以下は、BSの日本映画専門チャンネルでのゴジラのページ。全作の放送やゴジラ総選挙なるイベントを実施している。ちなみに7月19日には、全作が一挙放送される。

http://www.nihon-eiga.com/osusume/godzilla/

NHKでも映画が放送されたり、特集番組が放送される。まとまったページは無いようだが、報道資料を以下に記載。

http://www3.nhk.or.jp/pr/keiei/shiryou/soukyoku/2014/06/008.pdf

ちなみにウィキペディアには、結構詳しく各映画ごとにエピソードがまとめられてて、読んでいて楽しい。(というか全部だと結構なボリューム。) 例えば以下のページ。

http://ja.wikipedia.org/wiki/%E3%82%B4%E3%82%B8%E3%83%A9


BSでの映画放送を見て、自分にとって多少新鮮だったのは、ミレニアムシリーズ。2000年以降のシリーズで、新世紀版と呼ばれることもある。(正確には、シリーズ最初の映画の上映は1999年。)

特撮シーンが多く、しかも映像的にリアル性を高めていると感じた。自衛隊(防衛軍...)の兵器にも奇抜なものが多かったり、原子力(それに関連しての電力)や遺伝子工学などに関連するシーンが少なくないのも楽しめた。もちろん結構飛躍してるところもあるけど、その辺りは割り切り必要。DNAコンピュータなんてのも登場する。ミレニアムシリーズは、一通り見てみようかなと考えている。

3.11のことを含めて、改めてゴジラを見てみるのは、悪いことではないと思える。原子力以外にも、危険と隣り合わせの科学技術は少なくない。全部がそうだといってもいいのだろう。

また、映画製作での苦労話や作品間での違いなど、プロジェクト遂行という観点で参考になることも少なくない。これも自分にとっては、良い機会だ。


なお「GODZILLA」は、予告編などを目にしたけど、不気味さなど最初の「ゴジラ」と合い通じるところが少なくなくて、往年のゴジラファンでも楽しめそうな作品になっているように思う。自分が劇場まで出向くかは都合しだいだけど、機会あれば劇場で見てみたい。

7月 6, 2014 映画・テレビ書籍・雑誌 | | コメント (0) | トラックバック (0)

2014年6月 3日 (火)

福島原発の漫画「いちえふ」

一昨日何気に本屋さんに行ったら、漫画のコーナーに少し大きめに福島原発の漫画がディスプレイされてた。お試しみたいな小冊子もあって、中をチラチラ見た。面白そうと思いながらも、その時は買わず。そしたら、昨日2日の「クローズアップ現代」で他の漫画と一緒に取り上げられたらしい。

「いま福島を描くこと ~漫画家たちの模索~」 http://www.nhk.or.jp/gendai/kiroku/detail_3506.html

漫画は「いちえふ 福島第一原子力発電所労働記(1)」

福島第一原発で作業した人が描いたもの。会社名や人名などは仮名だけど、大きなとこはそれっぽく分かる。

そもそもハローワークで応募するところから、話がスタート。現実的な側面が多く描かれてて、いろんな意味で参考になった。(実際の作業はないけど、宿泊料は天引きされるとか、、、。さすがに、印鑑を預けるのはほんとかな~、というかその都度捺印するやる方でも認めてくれそうに思うんだけど、、、。)

放射線の被爆量の監視の仕方なども(今は違うのかもしれないが)結構細かく書かれてるし、作業員の息抜きみたいな話も出てくる。原発でなくても、労務管理などで参考になりそうな事が少なくない。

コミックには連載中のようだし、続編と言うか②巻も発行予定とのこと。②巻が出たら、そちらも購入しようと思う。

6月 3, 2014 日記・コラム・つぶやき書籍・雑誌 | | コメント (0) | トラックバック (0)

2014年3月 5日 (水)

再考 メイヤーズの三角形問題

知り合いのTwitterのつぶやきで、表題の「メイヤーズの三角形問題」が取り上げられた。ある数値の組み合わせが、どんな三角形の種類なのかというもの。つぶやきでの考えが自分の考えとちょっと違ってたので、「メイヤーズの三角形問題」をもう一度考えてみた/再読してみた。

メイヤーズの三角形問題とは、書籍「ソフトウェア・テストの技法」の冒頭で取り上げられている、読者への試験みたいなもの。

Myers_1st上のAmazonのは、日本語訳の第2版。左のが日本語の初版。もう35年以上も前の出版で、言わば古典。

なお、第2版ではXPの事などが追記されてるが、本三角形問題の細部で表現などが異なっている(後述)。また、Amazonでは”マイヤーズ”となっているが、ここでは訳本内でも書かれている”メイヤーズ”の表現を用いる。

問題は、第1版ではカードから/第2版では入力ダイヤグラムから、3つの整数を読み込んで、その数字の組み合わせで不等辺三角形、二等辺三角形、正三角形のどれかを印刷/表示するプログラムに対するテストケースを書きなさいというもの。

メイヤーズが記載しているのは、13個のテストケースと、1つの予想される出力を示したかというもの。13個の中に、1つの辺がゼロになるものをテストケースに含めているかとか、1つの辺が負数のものをテストケースに含めているかというのがある。14点満点だけど、プログラマの平均得点は7.8点であるとのこと。また、「全ての可能なあやまりを見つけられると保証はしないが」と述べてて、細部は自分で考えなさいとのスタンスだ。特に14番目でのエラー時のメッセージ(細部仕様)は、各自で考えなさいと暗に示していると個人的に考える。

さて、ここから細部になるけど、12として非整数の話しがある。第1版では非整数のこととしか書いてないが、第2版では”2,5,3.5,5.5”と例示がなってる。つまり数値が4つ。多分、本当は5.5は無いのだろう。(個数が異なるテストは13にある。ただし、例示は2つ。)

Twitterので知り合いとのやり取りでは、0詰め数値のことが言われていたけど、それをテストに含めるのは良いことかもしれない。0詰め数値は、3を”03”のように表記する方法。

ちなみに、例示されてるのは”3,3,4;3,4,3;4,3,3”のような表現。";"を便宜的なデリミタと考えて、3と3と4が1つのカードに書かれているなどと読めばいいのか、デリミタなども含めて記述されてるかによるけど、それらに関するテストも気になった。つまり、先に述べた4つ書かれているケースとか、デリミタまで含めて記述さていたら、”,”の代わりにスペースだったり別記号だった時のテストなどもあった方が良さそうである。

整数でないものとして例示は少数だけど、アスキー文字なども考えられる。

再度深く読んでみると、こんなテストケースもあった方が良いのとか思い付いたから不思議なものである。そもそも第2版は、GUIによるもので、GUIに絡むテスト項目は無いように思える。疑るような視点で再読してみることをお勧めする。(もしかしたら、検討した人とか検討した発表があるかもしれない。ちょっと探してみる。)

また、ここで示されてる条件でテストを請け負えるかとか、どんなテスト計画にするかとか少し膨らませて考えるのも悪くないかと思う。あるいは示されてることをRFPとして、十分と言えるか、あるいは何が不十分かと考えたりするのも悪くない。

なお、第2版と第3版は、カード→入力ダイヤグラムや印字→表示への変化以外に、有効な数値組み合わせという表現から、意味のあるという表現に変わっている。ただしこれは訳上の変更かもしれないが。久々に版による違いなどが面白いと感じた一時でもあった。


3月 5, 2014 書籍・雑誌ソフトウェアソフトウェアテスト | | コメント (0) | トラックバック (0)

2013年12月31日 (火)

今年印象に残った本 「働かないアリに意義がある!」

今年読んだ本で結構印象深かったのが、「働かないアリに意義がある!」。以前新聞で見かけて気にはなってたが、書店で平積みのコミック版を見かけた。1,2週ほどそのコミック版がなぜか印象に残ってて、何かの縁かと思ってコミック版を購入した。さらっと読んで(見て)、通常版の方で詳しく知った方が良いかなと考えて、結果的には文庫本とコミック版の両方とも購入した。

帯でのキャッチフレーズが、「サボるやつらが会社を救う!」、「7割は休んでいて、1割は一生働かない」。

そもそも自分が興味があってポツリポツリと本とかを買ってるものに、ミツバチなどの昆虫や動物が集団で組織体を形成する現象がある。「社会生物」とか呼ばれるもの。なお、最近は動物での自己犠牲的な挙動もあるようだけど、自分の興味はどちらかというと、そんなに賢くはなさそうな昆虫が共同作業できるメカニズムの方。そもそも遺伝子に組み込まれているのかとか、フェロモンのようなものに作業指示みたいなのがあるのかといった疑問が沸いていた。また、集団として統制が取れているように思えるが、その統制はどんなメカニズムなのかという疑問が沸いていた。


この本では、働かないアリは、いわばバックアップ要員だそうだ。ある閾値以上にならないと、働こうとはしない。ローテーションのようにしてるかと思ったら、キャッチフレーズにあるように、1割は一生働かないとのこと。個人的には、多少なんでだろうと思ったけど、その1割は非常に稀なリスクへの対応としているのかもしれない。(後述)

また、ある特定の作業しかせず(役目が決まってて)、それがアリのような小さな脳でも対応できる理由のように書かれていた。なるほど~と思った。つまり自分の読み解いたイメージでは、作業はプログラムされてて、非常にシンプル。ほんの少し、状況に応じて各自の判断で行動できるようになっているといったイメージ。

ただし、働くアリを集めて集団にしたら、そのうちの大半は働かなくなるそうだ。つまり、人間組織で言われてるパレートの法則(または「8:2の法則」)が当てはまるというわけだ。もともとパレートの法則が、アリのような小さな脳での法則と考えると、人間って案外進化してないんだな~と思ってしまった。

なお、アリは年代によって役目が変わるらしい。若いうちは幼虫の世話、巣の維持、そして年を取ると餌取りで外へ。これを「齢間分業(れいかんぶんぎょう)」と呼ぶそうだ。高齢化したアリを外に出すのは危険ではあるが、全体的には最適というわけだ。上手い仕組みだと思いながらも、なぜそうなるかに言及が少なかったように思った。そもそも役目をスイッチするように遺伝子に組み込まれているような次元の話なのか、女王アリなどからのトリガーによるのか?? ちょっと気になった。というのも、自分の視点としては、役目がプログラムされていると考えると、それを入れ替えるメカニズムやタイミングが気になってるというわけだ。

あと、餌場までの道筋のフェロモンはアバウトだし、それを守らずに行動するアリがいるとの話も面白かった。そのアリのせいでより効率的な道が発見されたりする(ことがある)。また、集団が均一化しすぎると外敵に脆い。これはプロジェクトでのグループメンバー編成にも当てはまることだ。

なお、本では「ハミルトンの法則」に結構なページを割いている。ハチやアリでの真社会性を遺伝子的に説明するものだが、それまでの分かりやすかった説明から、急に難しいというか偏った話に受け取った。著者の以前の著作なり論文が関係しているかと思える。いろんな種類のアリの話も登場して、ハミルトンの法則のような真社会性昆虫の普遍的な話なのか個別種の話なのかが混乱してしまう時があった。章立てなどの工夫が欲しいと感じた。(コミック版ではハミルトンの法則などには触れて無くて、”サボるやつらが...”と言ったキャッチフレーズの説明としては分かりやすい構成になっていると考える。)


ちなみに、この本を読む前に結構面白かったのが、NHKの「ダーウィンが来た」で放送された”ハキリアリ”の回だった。以下が公式ページ。
http://cgi2.nhk.or.jp/darwin/broadcasting/detail.cgi?sp=p320

以下は個人のブログだし、他での画像などもあるけど、番組内容が分かりやすい。
http://ameblo.jp/thinkmacgyver/entry-11546537205.html

道路整備担当のアリがいたり、情報収集のためのアリがいることなどが紹介された。また情報収集に関連して、音でのコミュニケーションを行っているらしいとの話もあった。思った以上に、分業が進んでいたり、集団活動のための術を用意していると感じた。


P7303063P7313067なお、2つの写真は、帰省した際に壷のようなものをひっくり返したら、ぎっしりとアリが巣を作っていたもの。ひっくり返した時にアリが右往左往(左の写真)してたけど、翌朝にはアリの卵を含めて一匹もいなくなってた(右の写真)。

こんな緊急時にも働かない=動かないアリがいるのか少し気になったけど、余りに多くのアリだし動かないことの観察をどうするかすぐに思いつかずに調べることはしなかった。ただ個人的には、このような緊急時には動かないアリも動いたのではないかと思う。また、代わりの巣を作ってそこへ卵を運ぶのが普通だろうけど、巣が必要とか巣の作成の指示がどう行われたかも気になる。

ふと個人的に思うに、1割のアリは一生働かないとの事だが、一生働かないアリの中に今回の緊急時に備えて巣になりそうな所を探したり、巣へ卵を運ぶためのフェロモンを出すなど役目のアリがいるのかもしれない。翌朝にはすっかりいなくなったアリの風景を目にして、ふとそんなことを思ったがどうであろう。


「アリはなぜ、ちゃんと働くのか」という、こちらの本も参考になった。ただし訳本で、アリゾナ砂漠での様子での記載のため少し距離感を感じるかもしれない。



思うに、昨今は目先のことはやるが、長期的視野で行動する人や場合が少なくなっている。(自分もそうだが)手紙などで考えを述べるのが億劫になり、メールや電話で済ませてしまう。今や、TwitterやLINEといった小文字数や絵文字でのコミュニケーションが主体になっている。普段の生活だけなら問題視する必要も無いが、会社や学校でのやり取りもそうなってるから厄介だ。マニュアルや本に書いてあることを鸚鵡返しすることはできるが、問題解決やそれ以前の問題把握や問題分析になかなか着手しない。端的には、人間がアリ化してるような気分になる時がある。

規格やBOKの類では、作成側はより良いものへとの考えだろうが、更新したり斬新な考えを盛りこむことに目が行ってしまう。企業内の管理部門は、規格の遵守や社内標準化、ツールの導入という手段を目的のように考えて、(本来の目標よりも)遵守や標準化やツール導入に熱が入ってしまう。

学術系の学生や先生、そして企業内でも論文作成がノルマになっている感じの人達がいる。研究成果なら分かるが、自分にとって身近なソフトウェア品質やプロジェクトマネジメントでは、改善などの視点の乏しい論文も少なくないように感じる。そんな論文は、色んな文献のコピペが多くて、実施したり改善点が曖昧だ。


なお結構街中で時々目にするのは、道路わきの空き缶や、ひどいときには食べ掛けのカップ麺の容器。所かまわずと言うか、、、。中国などの動画ではもっとひどい場面を目にしたりする。言わば、”服を着たサル”。(”服を着たサル”は、栗本慎一郎著の「パンツをはいたサル」を捩ったものだが、そのでのパンツは人間が生み出した制度みたいな意図。) そんなこともふと考えさせられた。


「働かないアリに意義がある!」を通じて、人を含めた集団活動の根本部分のヒントを学んだ気がする。また、昨今の人々との対比に目が行ったのは有意義だったと考える。なお、「齢間分業」が形成されるメカニズムや緊急時も働かないかなど、気になることも出てきた。自分なりの勉強もだし、この本の続編とかが出るのなら少し期待したいと思う。


12月 31, 2013 書籍・雑誌科学 | | コメント (0) | トラックバック (0)

2013年7月23日 (火)

情報処理学会「デジタルプラクティス」 ”ヘルスケアの現場を支えるIT”

今度の情報処理学会「デジタルプラクティス」の特集は、”ヘルスケアの現場を支えるIT”。さらっと読んだけど、面白い。実践分野の話しがほとんどだし、(デジタルプラクティスでも時々ある)論文のための理論こねくり回しが少ないように思う。

デジタルプラクティス単体でも、Amazonで購入できるそうだ。


実務を踏まえての論文が多いので、分かりやすい。苦労話や今後の課題と感じることも具体的に書かれている論文が多く、(他の分野でも)参考になるだろう。思い付くのは、カルテの閲覧への要望が多くて対応したが、対応したら対応したで分かりにくいとか医者の記載が横柄に思えるとの苦情があったそうだ。ある意味仕方ないと言えるが、その対策として、カルテ部分に内部用の欄を設けたとのこと。海外や地方への展開の際の、法律とか医師会への配慮のことなども書かれていた。

システムの構築と共に事業運営との問題や、虚偽データの扱いなど、結構本質的な問題にも触れている箇所があって考えさせられた。

また知らなかったシステムの紹介もあって、自分の健康維持などに役立ちそうなものがあった。具体的には、全国の血圧の上昇度合いが分かる”にっぽん血圧マップ”。時々アクセスして、自分の血圧データと比較してみたいと思う。(”にっぽん血圧マップ”への要望/切望としては、過去データを見ることができればと思う。せめて1月前程度はクリックか何かで見ることができればありがたい。)


興味あれば、購入して読むのも良いかもしれない。なお、価格が情報処理学会誌と同じような価格で、多少躊躇するかもしれない。今回の号はある程度見合ってるとは思うが、デジタルプラクティスの趣旨などを考えると、もう少し安価にするなども考えて良さそうに思う。

7月 23, 2013 書籍・雑誌技術ソフトウェアテクノロジー | | コメント (1) | トラックバック (0)

2013年7月22日 (月)

「モデルベース開発」 dSPACE Japan(監修)

副題に、―モデリングから、プラント・モデル、コントロール・モデル― と記載されている本。何気に本屋さんで見つけて購入した。帰りの電車の中で斜め読みして、買って良かったとの印象の本。

ちなみに以下での(P~)は、本書でのページ数。

まず監修になってる「dSPACE Japan」だけど、メカトロニクス制御のハードウエアやソフトウエアソリューションを手がけてるドイツ dSPACE社の日本法人。個人的には、コンサル的な活動も少なくないように思う。日本法人は2006年に設立されている。

本書は、dSPACE Japan以外に日産やスマートエナジーという会社の合計4人による共著に近い。結構分野が違ったり、数式的なモデリング主体の話しだったり機能安全を含めたモデル開発の進め方の話しだったりと、千差万別。それらの違いが多少違和感になる時もあるが、幅広く知ることが出来るメリットの方が大きい。ちなみにモデリングでのシミュレーションツールはほぼ、MATLAB/Simulink。また量産コード生成ツールとしては、dSPACEのTargetLinkによる説明になっている。


実務寄りの話しが所々出てきて、モデル開発を行う意味での注意点というか課題などが明確なのがよい。実務者にとっては常識的なことでも、少し違う分野の実務者とか、これからモデルベース開発をやろうかと思っている人にも参考になろう。

具体的には、量産コード生成ツールの高いコード効率への要求として、コントローラの1円コスト増が1億円/年の収益源になる例えの話し。ただし、1000万台/年で平均10台のコントローラでの算出。(P21) 変数のバイト数を固定小数点演算にして2バイトあるいは1バイトにすることでのコスト低減になる話し。(P47)  Simulinkでのブロック線図からCコードへの変換での、遅延処理まで含めた最適化の例の話し。(P47~) 計算負荷=実時間での計算での問題点。(P87) 実装での量子化された値への対応を行うためのアイデア。量子化での具体例として10ビット分解能のA/Dコンバータ。(P120) など。


欠陥生成ユニット(FIU)の話(P57)や、モデルベース開発と機能安全に関しては章を設けて説明している(第5章)。若干ではあるが、コンポーネントベース開発にも言及している(P128)。高信頼性化としても、参考になると考える。


数学モデルが所詮モデルであるし、精度の高い数学モデルを構築しても計算手法での限界があるとの意見も述べられている。(P194)  自動車会社の取り組みも紹介されており、本田技研のシミュレータで全ECU連携(P89)や日産の全てのエンジン制御ソフトウェアにモデルベース開発採用(P130)。 日産の事例は、どの部分/全部のモデリングかなど多少気にはなるが、モデルベース開発が浸透していると言うことだろう。

ソフトウェア技術者に一読を勧めたい一冊。

7月 22, 2013 書籍・雑誌ソフトウェア | | コメント (0) | トラックバック (0)

2012年11月 1日 (木)

「僕がアップルで学んだこと」

数年前から、時々品質関連の人と話題としたのが、アップル製品(当時だと代表的なのはiPod)の品質に対する感覚と自社製品を含む日本製品に対する感覚の違いは何?というもの。つまり、iPodを使っていると、(時々)音飛びが起きたりする。ところが日本製品だと、多分出荷NG。この違いはなんだろうかとか、判断基準をどう考えるべきかといった話題。実際アップルの製品を使っている人が少なくなくて、どう考えるか聞いたりした。

なかなか結論は見出せなかったが、アップルでの品質保証/品質判定の方法や基準は、その後も気になっていた。

左は、数日前に購入した本。著者の松井氏は、元・米アップル社品質保証部のシニアマネージャ。

実は、2,3ヶ月前とかに、本屋で手に取って見たことはある本。当時はパラパラ捲った程度だった。ところがiOS6でのアップル地図のゴタゴタをネットニュース等で目にして、色々検索。アップルの品質などの検索で、本著者の松井氏が引っかかってきた。そして、この本に品質保証部在籍当時のことが書かれていそうだったので購入した。内情暴露ではないだろうけど、ヒントになることが分かれば良いな~位の思い。

書評などでは、社内政治への対応やアップル回復のことが書かれている。それらの記載ページが多くて、品質保証絡みは所々。ただし、キーとなりそうなことが書かれていて参考になった。

品質保証部の役割は、品質を保証することではなくて、開発プロジェクトの状態を定点観測を行うということ。[P82] テストを行ってバグ分析をし、その製品がどの程度出荷可能レベルに近づいているかを測る。

バグ修正は重要度の高いものから行い、優先順の議論に時間が費やされることもある。[P79] また意見として、過剰品質を求めていないとの記載もある。[P84]

個人的には納得だし、優先順位の議論とかは知り合いなどの自分の回りで良く聞く話で、理解しやすい/当然と考える。

なお他に、マニュアルを少なくしたり無くしたこと[P69]や収益に対する研究開発費が2.3%と低いこと[P77]、デザインでブレが無いことと細部での変更とが書かれている[P64、P78]。

ちなみに、品質保証部門を担当した時の、メンバーの惨状の様子[P109]や整理整頓に心がけたエピソード[P112]に触れている。


先頭の方で記載したiOS6でのアップル地図問題は、iOSの開発統括のスコット・フォーストール上級副社長が来年退任するとのニュースで落ち着いた感じだ。代償が大きくなった。

実情は分からないが、松井氏が退社したことで、P109に述べてあるような惨状に戻ったのかも知れないとふと思った。また松井氏自身、今回のアップル地図問題をどう考えるか、彼のブログなどを注意しているつもりだけど書かれていない。(今は)書きにくいとか、書くべきではないとの判断かも知れない。 個人的には、アップル地図を出さざる終えない事情があるように思えて、申し送り事項(例えばαバージョン扱いにするとか)として明言などで対応する方法もあったように考えるのだが、、、、。

いずれにしろ、アップルを知る上で、個人的には読んで良かったと感じた本だ。


追記:以下の松井氏とのインタビューで、アップルも出荷判定会議をやってるとか、そのリハーサルの準備をした逸話が書かれている。

http://www.cyzo.com/i/2012/07/post_11040_3.html

11月 1, 2012 書籍・雑誌ソフトウェア品質出荷判定ソフトウェアテスト | | コメント (0) | トラックバック (0)

2012年10月12日 (金)

「プリウスという夢」

この本は、出版されて間もなく購入したと思うけど、ずっと本棚の隅に置いていた。パラパラと見た感じは車やメカの専門用語が少なくなくて、余り興味を覚えなかったためかと思う。

この夏に、何かのきっかけで気になって冒頭から読んでみた。”プリウス”の企画の段階から工場出荷までのノンフィクションと言える。しかも、当初はハイブリッドの乗用車での企画でもなく、出荷までの問題発生や対応が結構生々しく書かれている。車以外のプロジェクト、特にプロジェクトの高速化でも参考になることが多いと感じた。また、所々にトヨタ用語が書かれており、いくつかは知らないものがありその意味でも参考になった。

ちなみに、主人公と呼ぶべき登場人物は、プリウスの当時チーフエンジニア(CE:主査)の内山田竹志氏。2012年6月に、トヨタ自動車(株)の代表取締役副会長に就任した。


以下、感想などを、メモ書きのつもりで記載しておく。[]内は本のページ数。

1993年の9月に「G21プロジェクト」が発足する。21世紀の車を考えるトヨタ社内研究会。[P11] 後々のことを考えると、この研究会は車しかもセダンタイプの車体形態を検討するのが中心と捉えるべきだろう。当初のチームが発展解消して、1994年1月には選任チームとなる。その時のメンバーが内山田と石田の二人。[P18] 3,4ヶ月で同じプロジェクト名(で人数は限定的)ながら、研究会→選任メンバー選定にまでこぎ着けている。一般的な企業での製品化に於けるプロジェクトとしては、結構スピーディと思える。

しかも人数が増えて10人くらいになったチームは、1994年7月に企画をまとめる。その後、当初車の形態(のみ)だったのに、1995年の東京モーターショーにハイブリッドを搭載したコンセプトカーを出品するとの命になる。[P61] 言われたのが11月とのことなので、ショーへの出品まで1年程度。

1995年になると、第1次BRVFなる省燃費を探るチームが形成される。BRVFのBRはトヨタ用語で、ビジネスリフォームの略。 [P68]  BRは、横断的なタスクフォースと考えればいいのかもしれない。また省燃費を探ると言うよりも、ハイブリッドそのもの、あるいはハイブリッドにおける省燃費を探るチームと受け取った。第2次のBRVFチーム[P89]や第3次のBRVFチームが1996年3月に発足している[P166]ので、BRはプロジェクト専従でもなく、メンバーの入れ替えなどで洗練した方法にブラッシュアップさせるとの考えなのかも知れない。あるいは、設計を一旦終了/まとめさせて、色んな条件でのデータ取りをある程度時間を掛けて行い、それを次のチームに活用するようするようにしているのかも知れない。

なおトヨタのEV関連特許が2013年とか2016年に特許切れになるとの話題があるが、出願から20年という特許の有効期間を考えると、BRVFチームによるものや、その少し前に研究などにタッチしたメンバーでの出願によるものだったのかも知れない。

1995年秋には、「プリウス」と言う名前も誕生する。ちなみにトヨタでは、製品企画を「Z」と呼称するようだ。[P85] Zは、製品企画と言うよりも車開発での総合管理ポジションのようだ。[P100] 推進PMOとでも考えた方がぴったり来るのかも知れない。

ショー出展を絡めたこのあたりの流れは、先覚的な商品の場合に大なり小なり発生することで、興味深かった。過去を振り返って理路整然と商品化への筋道を描くことが出来るし、ドラマなどではそのパターンが多いが、世の中の動向や会社の都合などで回り道をしたり急がされたりすることは少なくない(はず)。

1996年のはじめには、デザインコンペを開催している。日本以外、アメリカやヨーロッパなどのトヨタのデザインセンターなども応募。[P110,P114] 1996年5月には2つに絞っている。[P138] うち1つがアメリカのキャルティのデザイン。[P115] 最終的にキャルティになったいきさつとして、副社長と専務が渡米の際に、キャルティでのクレイモデルを見て好感を持ったとの逸話も紹介されている。[P146]

バッテリーの、特にパナソニックEVエナジーのことにも触れている。(1996年半ばに基本合意して)1996年12月に設立して、1月には営業開始。[P194]

1997年9月頃から、高岡工場での生産のための試作(号試)開始し、1997年12月10日にラインオフ。号試では、設計者が工場に張り付いて不具合とかを対策する。その際の設計変更(設変)担当を、RE(レジデントエンジニア)と呼ぶ。プリウスの場合、高岡工場でのRE設変は百の単位で行われたようであるが、他のトヨタの車の場合は千の単位だそうだ。ラインオフのメールに対して、開発関係者は既に次のプロジェクトに参画していて淡々受け止めた人が少なくなかったのが印象的だった。[P209~P215]

商品化までの期間が短く、RE設変が少なかった。そのための布石が紹介されているが、一般的なプロジェクトやソフトウェア開発にも参考になると思われる。まず、2~3ヶ月に一度、試作車を最終状態にしていくというもの。[P105]  もう一つは、SE(トヨタ略称で、サイマルテニアスエンジニアリング)を徹底して行うというもの。SEは、前工程や後工程をクロスオーバーさせる方法。[P106] PMBOKでの”ファスト・トラッキング”と同じだろうが、このブログでの”スクラム”の原典「ラグビー方式による新製品開発競争」で記載した富士ゼロックスでの”サシミ(刺身)”とも相通じる。多くの企業で、大なり小なり実践している方法ではあろうが。

また、工場から製品企画へ出向させることも行っており、言わば「逆RE」。[P153] これもSE活動と言えると考える。新「G21プロジェクト」のメンバーはCADが使えることを条件とし、部屋にはCAD端末を2台用意している[P25~P27]ので、先覚的な環境整備は行われていたと考えるべきだろう。それらも設計時のスピードアップ化に寄与したのだろう。

なお逆説的だが、内山田はそもそも最初の試作車を早めに走らせようとするが、「2回の冬」を越させたかったようだ。[P93] つまり、冬の北海道のテストコースでのテストを2回行うということ。当初のスケジューリングで、商品化の場合のショー出品や、評価・テストを想定/重要視するのは非常に有効であると、改めて感じた。

もちろん、タイトなスケジュールへの反発[P94]や部門間の衝突[P172]も発生しており、(当然)一筋縄でいかなかったことが伺える。他にもエピソードはいくつか紹介されている。

他に、テスト走行に関しても書かれている。特にピークは1997年の7月~8月で、担当の一人は3ヶ月間で2万4千キロ走ったそうだ。当然3交替などになってくる。夜の8時から朝の4時まで500キロ走るなど。また、新しいタイプの車なので、テスト方法自体も新しく考えたとのこと。試作車の取り合いなども紹介されている。[P205~P207] このあたりも、自動車以外にも通じるところが多い。特に試作機の取り合いなどがそうだ。


トヨタの(生産ではなく)製品開発の本はいくつか出ている。自分の持ってる中には、海外で出版されたものを翻訳したものもある。この本は、物語風で分かりやすいのと、直近でのトヨタのSE活動にも言及していて参考になることが多いと考える。個人的には、ソフトウェア開発とかプロジェクト管理系の人にも一読を勧めたい。

10月 12, 2012 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年12月29日 (木)

ソフトウェアテストの見積り

知り合いとのやり取りで、”ソフトウェアテストの見積り”がちょっと話題になったので、メモのつもりで残しとく。そもそもソフトウェアテストの見積りって、テスト項目数がどれくらいになりそうかとかテストのための人員数がどれくらいを見積ることだが、記載されてる例が多くない。バグカーブやソフトウェア開発での見積りと比較すると、書籍や論文への登場は、がくっと減っている。

「基本から学ぶテストプロセス管理」では、11章で”テストのコンテキスト -予算、ライフサイクル、プロセスの成熟度”のケーススタディで、少しイメージしやいものが掲載されている。(ROIに関しても言及しているが、市場で発見されるバグをそこそこの数としているから、日本人には違和感はあるかも。)

他の章ではテストラボの設備などにも言及しているので、ソフトウェアテストの見積りを考える上で参考になるだろう。昨今は、C/Sシステムにしろクラウド利用のサービスにしろ、テスト環境構築をどうするかは大きな課題だし、実運用外のシステムでテストする場合はそれなりのコストが発生するので悩むところかと思う。

「テストプロセス改善」では、”7.4 見積りと計画”でキーエリアとして見積りのことを述べている。

テストケース記述での工数の考え方(ただしある意味当然)が記載されていたり、テスト自体の比率(準備、仕様化、、、)の筆者による経験値などが述べられている。

「ソフトウェアテスト見積りガイドブック―品質要件に応じた見積りとは」の方には、さらに具体的にイメージしやすい掲載もある。特に東京海上日動システムスの事例。テスト工数の全体に占める割合という概算的な数値である。ただし、まずはその数値で金額的な見積りを行うことは有効と、個人的には思う。(もちろん積み上げによる見積りとの併用が望ましいが。)

他にこの本では見積りでのパラメータが豊富に記載されている部分も多いが、具体的な数値とのペアではないのでイメージしやすいかは? 逆に、自組織でいくつかのパラメータを採用して、計測したり市場トラブルやリリース後のトラブル数などと対比することで、見積り精度の向上に役立てることはできるだろう。

ITシステムに対する受け入れテストの工数予想は、開発ベンダーによるインストールからカットオーバーまでの期間に関係する。組込みなどを含めてソフトウェアテストを請け負う企業もあり、そのような企業にとっては請負の見積り金額に関係する。ソフトウェア開発を請け負う場合でも、自テストの工数を加味する必要がある。それらを考えると、精度を高める工夫(と同時に予想との差異分析やその対応)が必要なはずだ。

IEEE829 208ではレベルテスト毎の計画という考えを入れているので、各レベルテスト毎に見積って積み上げることで見積り精度は上がっていくと思われる。レベルテスト(テストレベル)という概念を取り込み、ソフトウェアテストのためのコストを見積ったり計測することで、例えばコンポーネントテストでの自動テスト化/自動テスト拡張なども判断しやすくなると考える。

12月 29, 2011 書籍・雑誌ソフトウェアテスト | | コメント (0) | トラックバック (0)

2011年12月28日 (水)

日経のプロジェクト成功率

日経SYSTEMSの「さらば失敗プロジェクト」に関連して、日経コンピュータでのプロジェクト成功率を再確認した。5年毎なので、次回は2013年かと思われる。その頃にでもと思ってたけど、日経SYSTEMSの記事に誘発される格好で今のうちにまとめてみる。

日経コンピュータのプロジェクト成功率の記事は、2008年12月1日号と2003年11月17日号。ざっと表にしたものを以下に示す。

成功率 Q Q(母数比) C  C(母数比) D D(母数比) 送付数 回答数 回答率
2008年12月1日号 31.1% 51.9% -/212 63.2% 277/438 〔393〕 54.6% 239/438 〔392〕 8800 814 9.25%
2003年11月17日号 26.7% 46.4% -/1198 76.2% 1138/1493 54.9% 843/1558 〔1522〕 12546 1746 13.9%

母数比は、回答数と成功数。そこでの〔〕は、クロス集計上の回答数。2003年の11月17日号でのDの54.9%は、回答数1558に対して満足なのは843件で54.9%であったが、クロス集計上は1522件を回答としたことを示している。(なお、843/1558=54.1%であり、記事での数字はどこかが誤記かと思われる。 Qの成功数を”-”としているのは記事に明記がなかったためだけである。)

Q(品質)、C(コスト)、D(納期)で、成功としているのは以下。
Q:「計画通りのシステムが完成」しており、しかも「満足している」
C:計画通りあるいは計画以下のコストで完成 (次の選択は「2割未満の超過)
D:計画通りあるいは計画より前倒しで完成 (次の選択は「計画から2割未満の遅れ)


QCD全てをクリアしたものを成功としているし、Qはシステムに対する満足である。それを考えると、成功率3割は頷けなくはない。逆に成功の反対を失敗と捉えて、失敗率7割と言うのには違和感がある。(ちなみに良く引用されるアメリカのスタンディッシュグループでの調査も、3つともクリアを成功と定義しているようだ。ただし向こうでは放棄の%が少なくない。)

ちなみに、CQDの一部をクリアしている割合は明示されていない。あるいはQCDともクリアしていない割合が知りたい数字かもしれないが、そちらも示されてはいない。あくまで数値からの類推だが、2008年でのQCDともクリアしていない割合(駄目プロジェクトでも呼ぶべきか)は、1割程度ではないだろうか。これは各QCDのクリアが5割程度であるためである。(単純に1/2*1/2*1/2と考えると1/8。)


CとDでの計画通りに、1割程度の相違を含めるかも記事からは判明しない。回答者が判断しているのかもしれない。個人的には、1割程度の相違は計画通りに含めているような気がする。

このアンケートは、回答社での直近の1プロジェクトに関してのものである。えてして、その会社の画期的だったり大規模なプロジェクトになることが予想される。その前提で数字を考えるべきだろう。(一般的に、コストがかかったり期間が延びやすいと考えられる。)


なお、結構議論のある所に、計画時点をいつと考えるべきかがある。特に要求仕様追加などが発生した時の、”計画”時点。追加前の当初の計画時なのか、追加後の再計画時なのか。再計画時とすべきと考えるが、アンケートで明示されているのかも気になる。

アンケートの回答率が下がっていることも気になる事項である。2003年では他社との比較もあって積極的に回答したが、2008年時はプロジェクト失敗の数字が一人歩きして「IT部門は、、、」の材料になったりして、うんざりしたのかもしれない。あくまで個人的な推測。


次回のアンケートでは、CやDの成功範疇や、再計画との関係が明確になるか気になる。出来れば、CQDの一部はクリアしている割合の明示も期待したい。また、次回の有効回答率にも興味があるところである。

12月 28, 2011 書籍・雑誌プロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2011年12月24日 (土)

日経SYSTEMS 1月号「さらば失敗プロジェクト」

日経SYSTEMSの「さらば失敗プロジェクト」、知り合いのつぶやきから数日前に知ってたけど、今日雑誌の方を細部で確認。

いくつかの事例が書かれたルポの方は(失敗例として)頷ける部分もあるが、問題は最初の方の数値の列挙。「プロジェクトのうちに94.5%に深刻な問題が発生して、そのうち89.9%が同じ失敗を繰り返している」としている。

0.945*0.899=0.85 で、前プロジェクトのうち85%は、同じ原因で失敗していると読み取れる。

今となってはアンケートの原文がネットにないので何とも言えないが、今回の記事の本文でも質問は「あなたが現在または直近で関わったシステム開発プロジェクトについてお聞きします。そのプロジェクトでは、右に挙げる問題が発生しましたか?」。(右に挙げる)問題として、スケジュール遅延などがある。本アンケートは、ネットのITpro上で行ったものでその記事は以下。

http://itpro.nikkeibp.co.jp/article/Watcher/20111024/371258/

有効回答は73。上のURLでの記事で分かるように、そもそも、問題意識を持った人が回答したと言える。しかも、今回の記事では、問題がある→深刻な問題発生となっている。(アンケートの設問に、”深刻な問題”とあったのなら撤回すべきだろうけど。)

プロジェクトなので、あるいは定常の業務でも、日々問題は発生する。それを解決していくのが、ある意味プロジェクトマネージャーの仕事。日程遅れなども1割程度は許容範囲だろう。最初の日程は大枠であり、段階的な詳細化などを通じて具体的になっていく。最初の大枠での”案”に対して、1日遅れたら失敗との烙印は普通は押さない。(日経での別調査でも、1割の違いは失敗とはしていないはず。これらは他でのプロジェクト失敗率などと一緒に別途調査。)

また、別の設問は「現在または直近で関わったプロジェクトで発生した問題は、以前にも繰り返し発生しましたか?」。それが、記事では同じ失敗を繰り返しているとの表現になっている。同じ問題の発生と、同じ失敗は違う。多分回答者は、”以前もスケジュール遅れが発生したな~”程度で、Yesにしたのだと思われる。

なんか今回の記事での数字は、言葉で妙にバイアスがかかっているように思えてならない。気になっているのは、この類の数字が学会などでも利用され、まるでIT業界は駄目チームのように受け取られること。就職先として人気無くなるだろうし、社内には過度に反応して非常に細かい管理で対策しようとする所が出てくる。極論だろうけど、開発ベンダーの資金調達などにもマイナスになる。ぎりぎりセーフや上手く回っているプロジェクトが、たくさんあるのに/あるだろうに、、、。

12月 24, 2011 書籍・雑誌プロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2011年9月 9日 (金)

日経コンピュータなどの電子書籍化

本棚の整理で、ついに(というのもおかしいが)雑誌関係も電子ブック化することにした。いわゆる”自炊”と”他炊”。自炊なのは雑誌の一部分を残しているもので、日経エレクトロニクスとか日経コンピュータなど日経の雑誌が多い。他炊なのは、1冊のままで残していたものでBitなど。ちなみに、そもそも雑誌をスキャンしてくれるサービス会社が少ないし、切り抜きしたものを行ってくれるところは皆無。時々利用していたスキャンサービスの会社は、以前は雑誌OKだったのに最近雑誌などサービスの一部を中止してしまった。

日経エレクトロニクスは結構長く購読してたけど、ハードウェアとの関係が薄れたし、本屋さんでの購入や一部分の記事購入も可能となって年間購読は止めてしまった。そのせいもあって、思い切って電子化しておこうとの気持ちに。そうなると、ついでに日経コンピュータなどの方もとの気持ちになって、そちらも電子化することにした。日経コンピュータなどもファイルにしてると、取り出したり開いたりするのにちょっと体力が必要で、面倒くささを感じてしまうようになったためだ。(少し情けない。^.^;;)

ちなみに、雑誌の自炊での注意点は、表紙部分だろう。膠(にかわ)?の付き方が違うのか、表紙とその後の2,3枚はくっつきやすい。つまりスキャナーで重送になりやすい。思い切って幅を短めにカットすればいいが、表紙での文字まで切れてしまうことになって、実際やりながら改良するしかない。(スキャンサービスで雑誌が敬遠されるのも、その辺りが原因だろう。)

P90905962で、日経コンピュータの自炊前に撮影したのが左の写真。丁度創刊準備号から残していたので、懐かしくてパチリ。

上での一番左が、1981年の準備号(特別版春季号)の表紙、真ん中が1982年の1月11日号、右からはそれ移行の各年の初号表紙である。今から思えば初歩的なCGと言っても良さそうな画像の表紙が、10年ほど続いている。当時はCG自体が珍しかったが、こうして今の目線で表紙を眺めると時代の進歩を感じる。

また自炊しながら内容も眺めたりしたが、当時の記事や寄稿には、ITシステムの手作り感が多かった。ITシステムがプログラミングであり、品質を上げるために静的解析ツールを自社開発したり、ドキュメント作成での工夫点などの寄稿が少なくない。今よりも、システム発表の場になっているイメージ。また、システム化やツール化での割り切りの記載などもあって、個人的には今でも参考になりそうな事項も少なくなくて好感。(何となく、最近はなんでも出来るとか、100%達成みたいな内容が少なくない。)

また、長い期間で眺めると、流行の廃れや人物往来に思いを馳せる時も出てきて興味深い。大々的に取り上げていたものが急に話題から遠ざかったり今となっては不成功の烙印を押されたり、、、。人物に関する事項も、「そう言えばあの人は?」と行方などが気になる人も少なくない。なお、業界の浮き沈みという視点では、日経エレクトロニクスで取り上げられた製品群、技術や会社の落差が大きいような気がする。海外移転や空洞化の話題が増えているからなおさらだ。

今や代表的なスキャナーにはOCR機能がついてるので、自分の設定ではOCR処理済みのPDFファイルにしている。その辺りも、後の検索容易さなどで便利だ。もちろんOCR機能は十分な認識率とは言えないが、しおり(Bookmark)の作成には重宝する。

温故知新じゃないが、自炊しながら昔を振り返るのは悪いことではないと改めて認識した次第。

9月 9, 2011 日記・コラム・つぶやき書籍・雑誌ソフトウェア電子ブック | | コメント (0) | トラックバック (0)

2011年8月13日 (土)

「アジャイルサムライ」と「Agile Samurai」

洋書売り場で、ちらっと”The Agile Samurai”を見かけて、気にはしていた。左図で判るように、特に表紙の奇抜さ。

いつだったか翻訳版が出そうなつぶやきを読んで、待ち望んでいた。発売日に大きな本屋さんに行くチャンスが無くて、近所の本屋さんで探したけど(さすがに近所では)見当たらず。とある2日間の会合初日の帰りに大きな本屋さんに寄ろうと思ってたら、初日に懇親会というか飲み会に誘われてそちらへ。2日目の懇親会には翻訳者の一人を見かけて、買ってなかったことを猛反省。そしてつい数日前に、想定してなかったが、隣駅の本屋さんで購入できた。

”アジャイル”と”サムライ”。前者は英語で、後者は日本語という2言語による造語がタイトルなので、人によってはどんな本かピンと来ないかもしれない。本の中ではさほど強調してないが、アジャイルでの一手法の”スクラム”を中心としたソフトウェア開発方法の本と考えればいいのかもしれない。つまり、”スクラム”の元ネタが、野中郁次郎氏らによる日本の製造業における開発プロセス紹介であることから、”サムライ”との単語と結びつけられても違和感が少ないと言える。(なお本の監訳者あとがきで触れているが、原著者自身元々は別タイトルにしたかったようだ。) 蛇足だが、本の説明図で、相撲のポーズらしきものも書かれている。

”スクラム”をはじめとして、アジャイル手法を導入してすると課題が発生するが、それらに踏み込んだ記載が多い。また想定課題を「センセイ」と弟子が問答するシナリオとしていくつも掲載されているため、具体的に感じるだろうし読みやすい。その意味でも、多少スクラムなどのアジャイル開発を実践していると、参考になることが多い。もちろん、これから実践する人が読んでも役立つ。ちなみに、「センセイ」は原書でも”Sensei”(Master Sensei)。 

例えば、各イテレーションで正式受け入れテストを含めるべきか。P197。実は、既述の2日間会合で、関連することが話題となった。(リリース前)イテレーションの「テスト」には、一般的には受け入れテストは含めなくても良いだろうというのを自分の意見として述べた。アジャイルサムライを読んでなかったことがバレバレ^.^;。 ただし振り返ると、実際の自分のプロジェクトでは、正式リリース前に顧客との/顧客によるテストは何度も実施することが多かった。一般的にも、イテレーションでの「テスト」に、受け入れテストを含めるべきと考えるようになった。(組込みソフトの場合、どんな体制にするかは組織体で要検討だろうが。)

またP217では、スタンドアップミーティング無しにする場合のことが述べられている。価値を生むならやるべき、そうでなければ無くしても良いケースもあるだろうとの記載。個人的には、若いメンバーなら^.^;立ったままで実施すべきと考える。(ただし駄目チームは、単に朝寝坊したくてスタンドアップミーティングはおろか朝のデイリースクラムすら否定したがるので、要注意かな。)

センセイと弟子との問答では、このように組織体によって柔軟に運用することが述べられている。Aでも良いしBでも良いと書かれているように受け取り、悩みが出てくるかもしれない。ただ、各自やプロジェクトチームで考えたり、場合によってはアジャイルのコミュニティなどでやりとりして自分なりに解決していくしかないんだろうと考える。

3章では”インセプションデッキ”という用語が出てきて、プロジェクトの方向性を明確にするための設問(例)が記載されている。ここが、なかなか良い。表面的にはさらっと読める部分だが、実践の際には何度も読み返したり、実際のプロジェクト運営で細部を考えてみると良い。”インセプションデッキ”は、アジャイル系のコミュニティでも、最近話題になることが少なくないと感じる。

冒頭での”読者の声”というのも少し面白い。初版でありながら日本の読者の声もある。ちなみに原書での何人かの”声”と、10数人の日本読者の声という構成になっている。原書も訳本も、レビュアーの存在が大きいとの印象。またそこでのメンバーはアジャイル系のコミュに登場する人が少なくないので、”読者の声”は読んで損はない(/読んでおくべき)と考える。


ちなみに、原書も購入した。当初P6の”期待をマネジメントする”のコラムで日本語監訳者によると書かれており、コラム全てがそうなのかなと、ふと思ったためだ。”期待をマネジメントする”のコラムのみと判明したが、それ以外でも原語が何だろうと気になる部分が少なくなかったのが理由。前に述べた”センセイ”/”Master Sensei”は端的な例。円高ということもあり、興味あれば原書も揃えてはどうだろう。

8月 13, 2011 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年6月13日 (月)

「復興支援地図」

東北大震災での津波浸水範囲や道路の通行規制などを示してある。ネットニュースで発行予定を聞いてて少し心待ちにしていた本。

書店で見かけてすぐ購入しようと思ったけど、自分には思ってたよりも大きめ。天気が雨だったこともあって、最寄り駅の本屋さんにしようと考えてその日は止めた。ところが、2,3日後に最寄り駅の本屋に行っても無し。6月末に入るかもとのことだったので、今日最初に見かけた本屋さんで購入。

ぱらぱら見たけど、改めて震災が広範囲に及んだことを認識した。また、地域によって状況が結構異なり、高台に学校などを集めて難を逃れたと思われるところもあれば、海岸近くにぽつりぽつりと避難所も含めた施設を設定してあるところも。避難所も津波浸水範囲からほんの少ししか離れてないのも少なくなく、ある意味紙一重。海岸脇でも、回りや上流の方が津波に浸水されてるのに、浸水されずに済んでいるところもあった。(ちょっとした高台だったり防波堤があるのかもしれず、機会があったら調べてみようと思っている。)

ニュースとかを聞いて、気になった箇所とかがあったらこの地図で調べたりする予定だ。

6月 13, 2011 書籍・雑誌 | | コメント (0) | トラックバック (0)

2011年4月 8日 (金)

「はやぶさ、そうまでして君は」

昨年の年末には購入して、しばらく積ん読状態。2ヶ月近く前に読み終わった。そういえば感想を書いてなかったと思い、メモのつもりで記載。

「はやぶさ」のプロジェクトリーダー、川口淳一郎氏によるもの。

多少淡々と「はやぶさ」のプロジェクトのことが述べられており、熱狂的な”奇跡の生還”みたいな書き方とは一線を画す。個人的には、この方が冷静にプロジェクトのことを知ることができて有益だった。

プロジェクトスタート時の、成功するか失敗するか判らないような状況。ちょっとしたきっかけなどでのプロジェクト承認。場合によってはハッタリ。そうはいっても、いくつもの難関とか挫折。先覚的な商品化とかシステム化や、一般的なそれらでも遭遇しそうな事が発生している。

印象的だったのは「『尻を叩く』よりも『どこで手綱を引くか』を考えることが多かったと思います。」。(P64) 一般的なプロジェクトでも、管理/監査みたいなことが主目的になってしまうことがある。現場の創意工夫に気づくことも必要だ。

サンプル採取に関するトラブル(ソフトウェアトラブル)にも、多少ページが割かれている。P145~。ニュース等で、プログラムのダウンロードミス(番号違いの類)のように思っていたが、内部の処理は複雑にできており単純なダウンロードミスとは言えなさそうに感じた。 しかも本失敗が判明したのは、直前に着陸成功の発表をしたばかり。本にはこの辺りの苦悩の様子が書かれている。さらに言えば、その後の通信途絶、その復帰のための予算獲得の活動が必要で、その対応も参考になった。。

ちなみに、通信復帰のためには周波数を網羅的に探索しなければならないが、搭載している水晶発振器の温度の予想を立てて範囲を求めたとのこと。温度は、温度制御が上手く働いてないことを想定しての範囲算出。 この類の話がこの本には多く、場当たり的な復旧作業でなかったことが判る。データに基づく作戦立案。ソフトウェアでのトラブル対策でも参考になろう。ロジックやテストデータがない状態の危険性を、肝に銘じておくべきと考える。

リチウム電池の復帰(補充電回路)の部分では、補充電回路がOnになったことが不思議と。P170~。 Onにするプログラムは入っていなかったそうだ。 当時のニュースと若干違う気もするが、まっそんな事もあるんだろう。

また帰還の際には、”太陽光圧”も利用したそうだ。P169。しかも姿勢制御プログラムの変更も対応したと。 なお、今になって詳しく調べたら、イトカワに向かう際にも太陽光圧(太陽輻射圧)のことは検討されていたようだ。

http://www.muses-c.isas.ac.jp/j/index_26.html

この本には、プロジェクトチームの洒落っ気というか遊び心にもいくつか触れている。

・イトカワの粘土細工コンテスト P117など
・はやぶさにちなんだ運用室暗証番号 P118
・カプセルに貼り付けたメンバーのカード P8(写真)、P208

自分の持論みたいで悪いが、うまく行ったプロジェクトには宴会とか上のような遊び心がつきものだ。(主要なメンバー構成で、だいたい成功/不成功は決まるように思う。) はやぶさのプロジェクトでは、「そんなことまでやったのか~」と知り、ちょっと楽しくなった。

また最後の方には、「二番ではダメなんですか?」、一番と言い続けるアメリカ(NASA)、そしてリスクとの関係についての考えが述べられており、参考になる。既に述べた事などを含め、プロジェクトのケーススタディーとして非常に有益な本と言える。

4月 8, 2011 書籍・雑誌プロジェクトマネジメントプロジェクト管理 | | コメント (0) | トラックバック (0)

2011年3月23日 (水)

震災のシミュレーションコミックやスマートグリッド関連本

久しぶりに本屋に行って見かけた本。メモのつもりで残しておく。ちなみに、横浜ダイヤモンド地下街の有隣堂。

「ぼくの街に地震がきた―大震災シミュレーションコミック」

子供向け本のコーナーの棚に、平積みで置かれてた。すぐ隣にも2,3の震災関連の(子供向け)図書。

マンガということもあって読みやすいだろうし、どんな風に書かれているかも興味あって手に取ってみた。

前の方で、携帯電話が通じないことが書いてあった。ちなみに主人公の学校では携帯禁止で、故障かなんかしてるのを持ち込んだ子がいたとの設定。携帯電話不通は、今回の地震で震源地から離れている関東とかでも発生して、ついシミュレーション性が高いと感じてしまった。個人のエゴみたいなシーンもあり、結構参考になりそうに思った。


「スマートグリッドの構成技術と標準化」

こっちは、電気(強電)のコーナー。いくつかスマートグリッドの本があったけど、規格類が相当整理されていると感じた。自分としては、興味はあるけど実務にはノータッチなので、今回はメモで残しておく程度にする。

個人的なイメージでは、アメリカは相当な政府イニシアチブで推進。日本でも、いくつか実験や検証してたり企業取り組みもある。ただ、アメリカと対比的に考えれば、遅れてしまったと感じてしまう。今回の震災では電力の問題が深刻で、その意味でもちょっと残念/今後参考になるかもしれないとは思った。

3月 23, 2011 書籍・雑誌 | | コメント (0) | トラックバック (0)

「トヨタ語の事典」

以前、ぶらっと本屋に寄った時に見つけた本。1ページに数個の用語解説がある。車名、グループ会社名、海外拠点名が半分近くを占めている。また、初版は2003年出版なので、多少(結構?)今と変わっているかもしれない。

個人的に興味を覚えたいくつかを紹介しておく。(車名など上で述べた部分は個人的にはあまり興味なく、それ以外での用語。)

・「DPS」 Design Planning Sheet

「設計計画書」。承認図部品の場合は、サプライヤーが提出する図面作成スケジュールや部品作成予定日など。(承認図部品の場合)あくまでサプライヤーによる提出とのこと。

・「PPC」 Pre Production Check

号口(量産)車両の慢性的な不具合や問題を記載。改善提案。

・「さんかくアール」 ▽内にRの文字

RはRegurationの事で、法規特性(法規で規定されている)の旨を図面に残しておく。同じように、「さんかくイー」と呼ぶ排ガス規制の旨のマークもある。

・「CE」 Chief Engineer

チーフエンジニア。20人ほどいるとしているが、個人的にはもう少しいるのではないかと思う。

・「TQ-NET」

「統合品質情報システム」。市場品質情報とその対応状況の管理システム。


○○ってトヨタじゃどうやってるのかなと調べたり、ぱらぱら見て背景やソフトウェア開発等での利用を考えるとヒントになることもある。

3月 23, 2011 書籍・雑誌自動車 | | コメント (0) | トラックバック (0)