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

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

2016年下半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

book

上半期に引続き、2016年7月~12月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。

2016年下半期に読んだ本を並べてみた

https://www.instagram.com/p/BHhQId1jJ0Q/https://www.instagram.com/p/BH_XALBjaWg/https://www.instagram.com/p/BIkbpzZjmuS/https://www.instagram.com/p/BIpmBcSjrTg/
https://www.instagram.com/p/BI7lUbLDmfW/https://www.instagram.com/p/BJIgECCjFqM/https://www.instagram.com/p/BJdMxE8DYbM/https://www.instagram.com/p/BKDppjfjLdb/
https://www.instagram.com/p/BKQeHwCDc6t/https://www.instagram.com/p/BKVg1czDJBn/https://www.instagram.com/p/BKlHGokDj_N/https://www.instagram.com/p/BK3PBcvjeZu/
https://www.instagram.com/p/BK8D13WjST5/https://www.instagram.com/p/BK8QIQijFc7/https://www.instagram.com/p/BLFF4FXDjUB/https://www.instagram.com/p/BLgY150DUlg/
https://www.instagram.com/p/BLvwJVhDDGn/https://www.instagram.com/p/BLOX3XdjzEU/https://www.instagram.com/p/BLvxCjnD2rc/https://www.instagram.com/p/BMBupc9DhXR/
https://www.instagram.com/p/BMRMDA5Dcxu/https://www.instagram.com/p/BMRQi-YDpic/https://www.instagram.com/p/BMl1EJuD3kq/https://www.instagram.com/p/BMxdeffgokE/
https://www.instagram.com/p/BNBAb5vDzc4/https://www.instagram.com/p/BNIbTH2DZTR/https://www.instagram.com/p/BNQFqC7DWXh/https://www.instagram.com/p/BNZe4sbDvWb/
https://www.instagram.com/p/BNhGZNCjh7b/https://www.instagram.com/p/BNhHJAHjEj4/https://www.instagram.com/p/BNqcLyyjcTy/https://www.instagram.com/p/BOOELVtAftg/
https://www.instagram.com/p/BOWljD3Ata7/https://www.instagram.com/p/BOe5RjLAyZ6/https://www.instagram.com/p/BOmjBNlAMuJ/

オススメ文芸書編

2016年もいろいろ読んだのだけど、小川洋子さんの『猫を抱いて象と泳ぐ (文春文庫)』が最も素晴らしかった。2009年の本なのでもの凄くイマサラ感があるのだけれども、数ある書評にあるように『博士の愛した数式』を超えているという実感あり。チェスを題材としたお話ですが、チェスの知識はまったく必要ない。

その他としては、『聖の青春 (角川文庫)』『楽園のカンヴァス (新潮文庫)』も非常に良かったのだけれども、どちらも前提知識(将棋や美術)をそれなりに備えていないと楽しみきれないかもしれないというところで次点。しかしこの2冊も「読まずに死ねるか」という本である。

オススメビジネス書編

こちらも新旧織り交ぜて読んでいるのだけれども、一つだけ選ぶとしたら『LIFE SHIFT(ライフ・シフト)』をプッシュしたい。前作『ワーク・シフト ― 孤独と貧困から自由になる働き方の未来図〈2025〉』で非常にわかりやすい形で新たな働き方について提示した著者が、近年の具体的な傾向である「長寿化」をテーマに書いた本である。親世代の高齢化は今まさに直面している問題であるが、それを超えてさらに変化がやってくるという事を改めて認識する事ができる本である。

LIFE SHIFT(ライフ・シフト)

LIFE SHIFT(ライフ・シフト)

次点としては『サイロ・エフェクト 高度専門化社会の罠』も切れ味鋭く、新たな視点観点を付け加えさせてくれる良書。なお本書はテーマだけでなく、人類学者的アプローチで物事を分析するという点でも興味深いものになっている。

サイロ・エフェクト 高度専門化社会の罠

サイロ・エフェクト 高度専門化社会の罠

オススメ技術書編

すっかり技術書の近著を読めていない(もしくは、積読になっている)のだけれども、『システムテスト自動化 標準ガイド CodeZine BOOKS』は有用度の高い本であった。ツールやテクニックだけでなく戦略的な考え方まで学べる良い読書だった。

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

それでは、テスト自動化のベンダーという魔法使いにお金を払い、問題を追い払うテストツールという魔法の道具を受け取ってはどうでしょう。ひとたびテストを作ってしまえば、後はツールに任せればいい。なぜそうしないのでしょう。それは、技術が「十分に発達」していないからです。修行を経た者でなければ、魔法の道具は使えません。魔法使いが触れないと、道具は力を失い、腐り始め、バグを見つけるという仕事から完全に離れていってしまうのです。
システムテスト自動化 標準ガイド CodeZine BOOKS

その他、例えば古典的名著と言われる『☆』がKindle化されていたので読んだのだけれども、興味深くはあったがさすがに内容も古く、教養が増した以上の効果は感じられなかった。

オススメしないけど面白かった本

ぶっ飛んでいる作品としては『最後にして最初のアイドル』が良かった。SF小説なのだけれども、内容的にも時空的にも期待をはるかに超えるスケールである。ちなみに本作はラブライブ!2次創作らしいのだが、知識なしでも問題なく楽しめた。

最後にして最初のアイドル

最後にして最初のアイドル

あと以前から興味を持っていた筒井康隆氏の書くラノベビアンカ・オーバースタディ (角川文庫)』を読んだのだけれども、いろんな意味で想像以上だった。ネットで見かけた評「帯には「それは2010年代の『時をかける少女』」とあるが、さわやかなラベンダーの匂いではなく栗の花の匂いがする」が秀逸すぎる。全力でオススメしない。

2016年の読書振り返り

技術書を中心に、Kindleセールでうっかり購入するペースに読むペースが間に合っておらず、雪だるま式に積読が増えている。非常にまずい状況。現時点でお恥ずかしながら積んでいるのは次の通り。計画的に読み切りたい。

加えていくつかセールになったら購入しようと考えている本もあるわけで、ちょっとペースを上げていかないとまずい。

なお読書にはKindle Paperwhiteの第五世代(2012年)をあいかわらず使用中。最新モデルにするといろいろと便利なのだと思うのだけれども、別に不具合もなくバッテリーも調子が良いので、故障するまでは使い続けそうな予感。

カーゴ・カルト・ソフトウェア工学とか

Agile Project Management

そもそもソフトウェア工学が死んでいるという議論もあるかもしれないが、これとは別にカーゴ・カルトソフトウェア工学的な問題が拡大している実感があるので、それについて考えたことをちょっと整理してみるもの。国内で技術者教育の手法の主力となっているOJTカーゴ・カルトを増産しているのではないだろうか。あとカーゴ・カルトアジャイル開発について
Burning Man 2013: Cargo Cult

カーゴ・カルトとは

カーゴ・カルトあるいは積荷信仰とは、主に第二次世界大戦後に南海の先住民に発生した宗教のことである。

カーゴ・カルトという語句は、元々は第二次世界大戦後の南太平洋で見られた先住民の宗教に由来している。これらの人々は、戦時中素晴らしい積荷をもたらしてくれた神のような飛行機を呼び出そうと、一心不乱に精巧な飛行機の模型や滑走路を作り上げた

転じて、背景にある仕組みを理解せずに行動を過剰に(そしてその多くは無意味に)繰り返し実施することを「カーゴ・カルト」と評するのである。

「まるでカーゴ・カルトですね」と、依頼主である彼女の上司に進捗を尋ねられた私は、正直にそう言った。その会社の会議室には灰皿が置いてあったので、私は遠慮なく煙草に火をつけた。「ようするに、あのシステムを最初に作った白人は、ミクロネシアの奥地に飛行場を作ったんですよ。後任の彼女はそこで飛行機を初めて見た。そして、白人が去った後、彼女はあなたに飛行機を作るように言われたわけです。」戸惑う上司の前で、紫煙を吐き出す。「やり方は教わっていない。ソースコードしか手がかりはない。だから木の枝や藁で、無線機や、滑走路を作って、飛行機を呼ぼうとしているんです」

カーゴ・カルトソフトウェア工学

もともとプログラマの隠語として「カーゴ・カルト・プログラミング」という言葉はあったようだけれども、Steve MaConnell は著書「ソフトウエア開発プロフェッショナル」で これを拡張した「積荷崇拝的ソフトウエア・エンジニアリング」という概念について警鐘を鳴らしていた。

ソフトウエア開発プロフェッショナル

ソフトウエア開発プロフェッショナル

積荷崇拝的ソフトウェア・エンジニアリングの見分け方は簡単だ。そんなプロジェクトでは、全く意味のない作業でも、「いつもこうしてきた」とか「会社の規則でこうせねばらなない」と正当化している。また、プロセス指向の開発や、実力主義方式でのソフトウェア開発には、トレード・オフがあることを認めない。どちらの開発方式にも、長所と短所がある。さらに効率の良い新方式があっても、積荷崇拝的なソフトウェア技術者は、掘っ立て小屋にとどまり、大昔から伝わり快適だが何の役にも立たない儀式を続けるのだ。
ソフトウエア開発プロフェッショナル

  • コードレベルの無意味な風習というより、開発プロセス全般の無意味化された慣習
  • たとえばプロジェクトの特性を無視した不必要な手順
  • ソフトウェアの特性を無視した標準化
  • 実態に即していない、文書化やテストに関するプラクティス

あたりがイメージできる。うーん、あるある

OJTカーゴ・カルト

どちらにしろ「カーゴ・カルト」的なものが忌むべきものであるという点には議論の余地がないと思うのだけれども、残念ながら現状の(国内の)ソフトウェア開発を取り巻く状況はこれを増長させるものとなっている印象がある。

  • 専門的教育を受けていないソフトウェア技術者が多い。IT人材白書2016を見ても「開発プロセス」をいつどこで学んだかというアンケートに対して「会社の実務経験を通じて」という答えが大多数
  • ソフトウェア技術者の育成については、OJTに頼っているのが現状。こちらもIT人材白書2016にて確認
  • IT人材白書:IPA 独立行政法人 情報処理推進機構

別にOJTを否定するものでもないけれども、察するに・・・

  • OJTを担当する上級者が必ずしもソフトウェア開発のエキスパートではない
  • 理論はさておいて、実践中心の指導となっている。というと聞こえは良いが、今やっていることを見真似することから教育を始めてしまう
  • 「とりあえず、チュートリアル・ガイドの通りにやって。わかんないことがあったら聞いて」

という状況が想起されてしまう。もちろん実践をしながら独習や研修などによって補完的に理論や仕組みを学ぶ人もいると思うのだけれども、実際にそういった人がどの程度の割合になるのだろう。けして比率は大きくない気がする。
その結果、カーゴ・カルト的なものが増えていくのではないか。SIerとか受託開発方面では特に・・・

ソフトウェア開発プロジェクトは、その前提となるビジネス側の要求も千差万別だし技術的な側面もプロジェクトによって大きく異なる。過去に学んだ知識を繰り返し活用することはできず、常に学習を継続しく必要もある。モチベーションを維持できず足を止めてしまうと、すぐにカーゴ・カルトの闇に落ちることになるのだろう。また、カーゴ・カルトによって実際には生産性が落ちたり品質が低下するはずなのだけれども、そのスピードが緩やかなので問題視されにくいという構図もある。どうせ人月単価の世界だしね・・・


そんな状況の中で茹で蛙にならないためには

  • 自分自身が学習を継続する
  • OJTを通じて後進教育をする場合は、表面的な作業説明だけではなく、背景について説明をする
  • OJTを受ける場合は、作業の背景についても興味を持ち調べる
  • 自分が実施している作業がカーゴ・カルト的かどうか常に疑問を持つ

ということが必要なのではないかと思った次第。常に実施できるかどうかは別にして

カーゴ・カルトアジャイル開発

さて一方で、世の中的には「カーゴ・カルトアジャイル開発」というものも増えてきているような話がある。

最近Twitterメーリングリストでは、ルールに従うことこそ全てと信じているような人たちが、自分の満足いくようにルールに従わない相手に対して「あなたはアジャイルじゃない」と主張しているのを当たり前のように目にするようになりました。調査と順応の概念は一体どこへいってしまったのでしょう。近い将来起こり得る問題に対処できるよう手法の革新を図ろう、新たなやり方を導入しようという考えは、どうなってしまったのでしょう。よく用いられる正統派なアジャイル開発手法は、本質的には10年以上何も変わっていません。私たちは型にはまってしまっているのです。

プログラミングの仕事をしている現在の職場をやめ、別の職場を探すべき9つの兆候をInfoWorldの記事でAndrew C. Oliver氏がまとめている。 Oliver氏によれば、9つの兆候は以下のようなものだ。プログラミングの仕事に限らず、スラドの皆さんが転職を考えるべき兆候というのはあるだろうか。
(中略)
6. アジャイル開発を表面的にまねただけのカーゴカルトアジャイルが行われている

本来のアジャイル開発プロセスであれば、定期的な振り返りの実施によって常に改善を行うプロセスが組み込まれているのでカーゴ・カルトの発生は抑えられるような気もするのだが、

  • トップダウンで導入された開発支援環境にロックインされ、作業プロセスが容易に変更できない
  • 強力なコンサルタント/コーチによって導入されたプロセスを自発的に変更できない
  • 目の前のバックログに圧倒されてしまい、改善するモチベーションが無くなる/現状継続を選択してしまう

ということは実際ありそうな気がする。

(良し悪しは別にして)ソフトウェア工学的、計画駆動型のアプローチは「どうしてこうなったのか」を分析することが容易である。一方でアジャイル開発におけるプラクティスはその実証主義的傾向から「どうしてこうしているのか」がわかりにくく、かつ時間が経過してしまうと、どうやって意思決定したのかも記憶の彼方に消えてしまうような気がしてならない。人が変われば経緯も忘れ去られてしまう。そういう意味では、カーゴ・カルトが発生する傾向は計画駆動型アプローチより高いのかもしれない。そんなことを想像した

Kindleで翔泳社新刊「レガシーソフトウェア改善ガイド」含め、50%ポイント還元中(12/8まで)

Kindle book

表題通りAmazon Kindleで大規模セールになっているようだが、新刊「レガシーソフトウェア改善ガイド」も対象になっている点に注目。さっそく購入。

レガシーソフトウェア改善ガイド (Object Oriented Selection)

レガシーソフトウェア改善ガイド (Object Oriented Selection)

この本のスコープは欲張りなもので、放置されたレガシーコードベースを、あなたの組織に価値をもたらす保守が可能で十分に機能するソフトウェアへと変身させるのに必要なことを、すべて伝授しようというのです。
レガシーソフトウェア改善ガイド (Object Oriented Selection) この本について、より引用

なかなか興味深そう。旧著レガシーコード改善ガイド (Object Oriented SELECTION)に比べるともう少し戦略的な事が書かれていそうな印象。技術面だと

ただし、この本に技術的な内容がないというのでは、まったくありません。本書は、Jenkins,Findbugs,PMD,Kibana,Gradle,Vagrant,Ansible,Fabricなどといった、広範囲なツールを扱います。数多くのリファクタリングパターンを詳細に取り上げ、モノリスからマイクロサービスにいたるさまざまなアーキテクチャにおける関連メソッドを論じ、コードをリライトするときにデータベースを扱う戦略も見ていきます。
レガシーソフトウェア改善ガイド (Object Oriented Selection) この本について、より引用

というカバー範囲になっている模様。

その他のオススメ本は以下記事などを参照いただきたい。

Kindleで「熊とワルツを」他のデマルコ本、「ソフトウェア要求」などが50%オフセール中

book Kindle

観測の範囲で、ポイント還元により「熊とワルツを」他のデマルコ本、「ソフトウェア要求」などがAmazon Kindleで50%オフセール中の模様。先日書いたDIAの記事に興味があれば「熊とワルツを」を購入するチャンスかも。

デマルコ関連

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

実は今読んでいるところ。ソフトウェア開発におけるリスク管理に関する名著。最近はどのソフトウェア開発プロジェクトもリスク管理はやる流れになっていると思うけれど、形骸化しがちでもある。というわけで見直すきっかけによいのでは無いかと思っている。

デッドライン

デッドライン

あまり技術書になじみの無い若い方によくオススメしている本。PMのやり方に不満がある時などに読むといいと思っている。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

プロジェクトあるあるな失敗パターンについて書かれた本。中堅以上の方にオススメ。

こちらはデマルコさんではなくヨードンさんの書いた名著。

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

パーフェクトソフトウエア

パーフェクトソフトウエア

こちらはデマルコさんではなくワインバーグさんの書いた名著。

オススメ高額技術書関連

ソフトウェア要求 第3版

ソフトウェア要求 第3版

要求定義関連の古典ですが、第三版ではアップデートされてアジャイル開発プロセスもフォローされている。

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

さすがにいまどき読むのはコスパが悪いという評判もあるけど、一冊持っておくならセールのタイミングに買いたい。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

こちらも名著なのだけれども、今でも皆が読むべきだと思っている鉄板本

その他

90年代MicrosoftWindowsNT開発に関するドキュメンタリー。非常に示唆が多く、大好きな本のひとつ

上記以外にもいろいろセールになっているので、ちょっと調べてみると良いと思う

DIA(デンバー国際空港)の自動手荷物処理システム

Project Management

有名なソフトウェア開発の失敗事例(トム・デマルコの「熊とワルツを」では「ろくでもないソフトウェア開発の象徴」とも呼ばれる)である DIA(デンバー国際空港)の自動手荷物処理システムについて、勉強がてら整理してみる記事。名前は知ってたけれど、ちゃんと考えてみたのはこれが初めて。この事例はIT 技術者として押えておきたいと思ったところ。メメント・モリ

主要な情報源

DIA(デンバー国際空港)の自動手荷物処理システム

さてどのような事件だったのか、上記の情報源から改めて整理してみたい。

  • 新空港の着工は1988年
  • システム開発の着手は1991年
  • 当初の開港予定日は1993年10月31日だった
  • しかし、予定日には自動手荷物処理システムは完成できず開港が出来なかった。空港設備はシステムを前提に構成されており、システム無しの乗客受け入れは不可能だった
  • 結局1995年にやっと部分開港にこぎつけた。遅延コストは1ヶ月につき3300万ドル必要となった。また動かない自動手荷物システムのバックアップシステムを構築するために5千万ドルが必要となった
  • 2005年にシステムは完全に廃止、マニュアルの搬送方法に切り替えられた。それまで一度も正常に稼働したことはなかったという。また運用を停止しても、リース料は25年の契約が切れるまで残ることとなる
  • 開発当時、自動手荷物処理システムは既に他の空港で実用化され稼働していた。しかしDIAは他の空港に比べて規模が大きかったため、システムの規模は既存の同種のものより10倍以上複雑で、要求される処理スピードも高かった
  • 開発基盤はOS/2オブジェクト指向技法で設計されること、とされていた。空港全体の情報システムとしては独立して稼動し、各航空会社の予約システムとは連携していた
  • 開港予定日が政治的な理由で先に決定されていた。最初から開発期間が大きく不足していた。請負会社は開発期間として当初与えられた期間(2年)の倍が必要と主張していた。また先行する類似システムの試験導入に成功していたミュンヘン当局はDIAに対して2年のテスト期間と6ヶ月の24時間運転による調整をアドバイスしていたが、DIAはこれに従わなかった
  • そもそも、受託会社も無理なスケジュールと考えていたため入札には応札しておらず、ベストエフォート・ベースで契約していた。また早い段階から再三納期に間に合いそうにないと告げており、かつ新たな変更が加わるごとに遅延は拡大していった

整理するだけでお腹が痛くなる事案である。

各種の論評

  • 1994年 Scientific American での論評

ソフトウェア工学の規律は、情報化時代の社会の要求を満たすために必要な成熟した工学の規律より数年、いや、おそらく数十年は遅れている

プロジェクトが失敗した原因は、DIA のリスク管理の方法にあるのではない。リスク管理の努力がまったくなされなかったことにある。

現在の視点で考えてみる

上記がトラブルのあらましなのだけれども、自分がもしこのプロジェクトにアサインされたら、という前提でいろいろ考えてみた。もちろん「必要な開発期間の半分しかスケジュールが与えられない」という無理ゲーなので逃げるが勝ちな気がするけれど、それでは思考トレーニングにもならないのでやる前提で。

まずはパイロット調査

そもそも全体規模が巨大かつ、性能要件が厳しいというシロモノなので完成できるかどうかもわからない。というわけで何はともあれ金をドブに捨てるとしてもパイロット調査を計画するのが最優先だと思う。時間とカネはさておいて、完成可能かどうかの検証が一番大事。

  • パイロット版システムを作成する計画を立案して、リスクが高そうな要件の実現可能性を評価する
  • パイロット版システムをイチから構築する時間が無いので、出来れば稼動しているシステムを買ってきて改良して作る。時間はカネで買う
  • コストはいったん度外視。無理ゲーである時点でそんなことは気にしてはいられない
    • 作成したプロトタイプはそのまま本番システムに流用可能です、とか何とかいってとにかく上層部を説き伏せる
  • 動くシステムによって、プロジェクトが完了できるかどうかを見極める。

これを実施したうえで、そもそも現時点の地球の科学力では完成できないレベルの要件があったら、交渉する。もしくは逃げる。

システムを分割する

完成できる見通しが立ったと仮定して次にやるのはシステムの分割だろう。一枚岩の巨大システムを作るのはリスクが高すぎるので、業務観点と技術要素観点で複数のサブシステムに分解しないとどうにもならない。失敗が発生したとしても全部が倒れないような分割はすべきだと思う。

  • 美しい設計とか、深い分析をしている暇は無いので仮説をたててザックリと分ける
  • 技術的負債になることはいったんは厭わない
  • とにかく分割統治可能にする

といっても、当時も似たような議論はしていそう。

デッドラインはいったん忘れてスケジュールを立てる

そもそも着手の段階で開発スケジュールが本来必要な期間の半分しか許容されていないので、当初の開港予定日が守れる可能性は100%無いだろう。というわけで、いったんデッドラインは無視してスケジュールを再考し、そこからどれだけ前倒し出来るかをコントロールしたほうがマシな気がする。

  • デッドラインを無視することを利害関係者が受け入れない可能性は高い。その場合は外向きには遅延管理しながら、内部的には引き直したスケジュールで管理したほうがよさそうな印象
  • ただし、注意しないと新しいスケジュールに合わせてメンバーが個人余裕を持ち出す可能性がある(夏休み症候群)ので、CCPMなどを取り入れたバッファマネジメントをするのが良さそう

達成不可能なスケジュールを前提として、プロジェクトメンバーに強いプレッシャーをかけても生産性は低くなるだけである。むしろ達成可能なスケジュールに対して、どれくらい元のデッドラインに戻せるかに対して努力したほうが成果も見えやすいし、モチベーションは上がりそう

とまあ、いろいろ考えてはみたのだけれども、実際にはもっと難しいものなのだと思う。とはいえ、いろいろとアイデアを考えたりするのは訓練としてはなかなか良い印象。皆さんはどのようなアイデアを持たれるのだろうか。

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

Software Runaways: Monumental Software Disasters

Software Runaways: Monumental Software Disasters

情報システムの障害状況ウォッチ(2016年前半)

Project Management

SEC Journal46号で2016年前半の情報システム障害状況まとめが公開されたので読んでみる記事。2015年度の分については以下のエントリを参照。生々しい話を読むと、自分がトラブルを引き起こす確率が減るんじゃないかと思っている。

SEC Journal最新号の入手はこちらから。

Zombies

情報システムの障害状況ウォッチ(2016年前半)

詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例を例年通りニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案ばかり。

障害とは違うけれども気になる2016年前半の事件

情報システムの本番障害ではないが、マイナンバーの件[1606]以外にも今年はいくつかの大きな開発トラブル(システム開発の中止や賠償)の話も目についた。このあたりも詳細続報は報道されることは無いけれども気になるところ。

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

失敗学のすすめ (講談社文庫)

失敗学のすすめ (講談社文庫)

ITエンジニアと法的要件の考慮

Project Management Professional Engineer

XP祭り2016で発表された「巷にはびこる間違ったUX論へのヘイトをぶつける集い」という発表をめぐる一連の議論を読みながら考えた事。ちなみにUXについては門外漢であるし、そこについての意見は無い。ただ、この中で出てくる「UXデザイナーは法律の考慮も行うべきなのか」については異論を唱えたいところ。

rosetta

なお一言断っておくと、「巷にはびこる間違ったUX論へのヘイトをぶつける集い」講演者の@takigawa401は知人である。だからと言って擁護するような意図は無いし、多分そういう内容になっていない。
また、もともとの議論はUXデザイナーに関するものなのだけれど、本記事ではより広義な事を書いているつもりなので記事タイトルは意図して「ITエンジニアは〜」というビッグワードを使っている。

プロフェッショナルを名乗るのであれば法規の遵守は第一の要件である

まあこの一言に尽きるのだけど・・・

2016年の現在においては、ユーザーニーズだけでなく(このブログで取り扱っているように)既存の各種法律や慣習もユーザーニーズと同様に機能使用や情報の構造に影響を与えるファクターとして存在しています。確かに16年前ではユーザーニーズを検討しておけば十分だったと思います。しかし現在ではITサービスの社会的需要の拡大により、サービスと既存法制との接点も十分に検討すべき課題として挙がっていると個人的には考えています。このような状況の中で、あくまでUXデザイナーの業務はUXだけに限るのか、よりよいサービス(の仕様書)を作るためにUXだけでなく法律や慣習まで業務範囲に含めていく必要があるのか、その辺りUX界隈の人たちがどのように考えているのか興味があります。

もちろん業務を行う上で、法律や商習慣の知識はあった方がいいでしょうし、その方が物事は早く進みます。ですが、UXデザインはそれ自体が非常に大変で専門的な役割であり、だからこそUXデザイナーはUXデザインに注力すべきでしょう。専門外のところまでフォローしようと思ったら、1日24時間どころか72時間あっても全然足らなくなってしまう。法律や商習慣、業務の細かな内容の確認は、それぞれのスペシャリストに任すべきです。だからこそ我々はチームを組み、協業して製品やサービスを開発するのです。

もちろん法的要件の適格性を最終的に確認するのは専門家の役割であるとは思うのだけれども、「UXデザイナーはUXデザインに注力すべきでしょう」という点には同意しかねるのである。職業プロフェッショナルを名乗るのであれば、当然のように法的要件および政治的・文化的要件に配慮すべきである。UXデザイナーに限った話ではなく。

これは職業倫理の問題なのだけれども、ちょっと長いが「ソフトウェア・エンジニアリングのための倫理ならびに専門職実務綱領(日本語訳)」の序文が素晴らしいのでこれを引用して説明したい。

コンピュータは商取引,産業,行政,医療,教育,娯楽,社会全体において中心的な役割を果たしており,その役割はますます増大しつつある。ソフトウェア・エンジニアはソフトウェア・システムの分析,仕様決定,設計,開発,保証,メンテナンス,テストに,直接的な参加あるいは教育を通じて貢献している。ソフトウェア・エンジニアは,ソフトウェア・システムの開発に対して果たすその役割ゆえに,
・自らが善いことをするのか,害をもたらすのか,
・他者が善いことをするのを可能にするのか,害をもたらすことを可能にするのか,あるいは,
・他者が善いことをするよう影響を与えるのか,害をもたらすよう影響を与えるのか,
を決定づける,重大な機会に直面する。自らの取組みが善いことのために利用されることを可能な限り確実なものにするために,ソフトウェア・エンジニアはソフトウェア・エンジニアリングを有益で尊敬に値する専門職の仕事とするよう最大限の努力を投じなければならない。こうした責務に従い,ソフトウェア・エンジニアは以下の倫理ならびに専門職実務綱領を遵守すべきである。
(中略)
倫理的な対立状況では,詳細な規則を盲目的に信頼するよりもむしろ,基本的な原則について注意深く考えることによって,それに最もよく取り組むことが可能となる。そうした原則とは,ソフトウェア・エンジニアに以下のようなことをするよう促すものである:
・誰が自分達の仕事に影響を受けるのかについて広い視点で考え,
・自分達ソフトウェア・エンジニアが他の人々を,当然払うべき尊敬の念をもって扱っているかどうかについて考察し,
・社会の人々が自分達の決定を,もしその内容がきちんと知らされるならば,どのように思うのかについて考え,
・最も権限・権力のない人達が,自分達の決定によってどのように影響を受けるのかについて検討し,
・自分達の行動がソフトウェア・エンジニアとしての理想的な専門家の仕事であると判断されるに値するものであるかどうかを考える。
これらのすべての判断において,社会の人々の健康,安全,福利への関心・配慮が最も重要である。すなわち「公共の利益」こそが,この綱領の中心に存在するものである。

類似のものとしてはITに限定しないエンジニア全般のものとして「技術士倫理要綱」、ソフトウェア開発については「認定情報技術者 倫理要綱」もあるのだけれども基本的には似たようなことが書かれている。要は「専門外なので知りません」とは言うべきではないのである。

ただ、もちろんこれは姿勢の話であって、最終的には専門家に頼らざるをえないとは思う。それでも取り扱う領域において、配慮すべき論点についてのリサーチは行うべきだし、それをすることが本来の職務の妨げになることは無いだろう。