IT本

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

ソフトウェア部品化の幻想: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その経kながソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

2015/06/14

【告知】「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」がついに出版

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」が来週6/22に出版されます。
過去に出版されたRedmine本の中で、幅広い読者層と記載内容の広さは、一番だと思います。
その分、本の値段も過去のRedmine本の中で一番高価です笑

僕も、Redmineの運用方法やチケット駆動開発の解説など、一部の章を支援しました。

【参考】
「Redmine実践ガイド」が出版されます - 推薦文公開 -: ソフトウェアさかば

【目次】Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント(株式会社アジャイルウェア) | 書籍 本 | ソシム

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」の内容は、Redmine初心者からプロジェクトマネージャや上級者まで広い読者層を対象に、利用手順から実践技法、国内製造大手のRedmine運用事例まで書き切ってます。
過去のRedmine本と比較すると、下記の特徴があります。

1)Redmineの利用者・プロジェクトリーダー・システム管理者の観点で、Redmineの使い方や設定方法を解説。
入門Redmine」と内容は似ている部分があるが、使用者の観点で書いているので、ストーリーは違う。

2)Redmineでアジャイル開発・WF型開発・チケット駆動開発を一通り解説している。
また、Redmineの運用方法として、課題管理・障害管理・ヘルプデスク管理・PC資産管理なども解説している。
さらに、島津製作所や三菱電機など、日本の大手製造業で実際にRedmineを導入・運用した事例も紹介している。

Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の内容と似ている部分があるが、Redmineの使用者の観点で網羅的に記載している点と、実際の日本の大手企業の事例を詳細に記載している部分は違う。
特に、日本の企業の事例では、Redmineの特徴をすごく生かしている会社もあれば、Redmineに頼り過ぎない方が良い部分もあると冷静に分析している会社もあり、すごく参考になると思います。

3)Redmineシステム管理者の観点でRedmineのインストールや移行方法、利用者の観点で数々のプラグイン紹介、開発者の観点でRedmineプラグイン開発のコーディング方法を詳しく解説している。

Redmine超入門 増補改訂版」「Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール (日経BPムック)」と比較すると、記載の範囲が広く、プラグイン開発者にとっては貴重な解説資料になっている。

というわけで、是非手に取って読んで頂ければと思います。

今年は「入門Redmine」「Redmine超入門 増補改訂版」「Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール (日経BPムック)」についで、4冊も日本でRedmine本が出版されたことになります。
これだけRedmineを利用する読者層が日本に多くなっている事象を見れば、日本でもRedmineの利用事例が増えており、チケット管理ならびにチケット駆動開発のメリットやデメリットも把握しているのだろうと思います。

その辺りも、RxTStudyやredmine.tokyoのようなRedmineコミュニティで皆と共有したいと思います。

【追記】
目次が下記で公開されていますのでご参考下さい。

【目次】Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント(株式会社アジャイルウェア) | 書籍 本 | ソシム

| | コメント (0)

2014/11/24

書籍「実践反復型ソフトウェア開発」へのフィードバック資料のリンク

実践反復型ソフトウェア開発」の著者の方がフィードバックの資料をまとめていたのでメモ。

【1】「実践反復型ソフトウェア開発」は、アジャイルな開発環境作りに興味のある開発者にお勧めだと思う。
理由は、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念が整理されてまとまっているからだ。

SIの現場では、「実践反復型ソフトウェア開発」に書かれているような概念が暗黙知になっており、本来はベストプラクティスないし守るべき規律としてチームが実践すべきルールが徹底されていない場合が多い。
あるいは、10年以上も以前の古い技術に固執しすぎて、アジャイルな開発を阻害している原因になっている時も多い。

だから、そんな現場には、構成管理・チケット管理・ビルド管理・テスト管理に必要な概念や、ベストプラクティスから得られた形式知をチームで共有して実践すべきだと思う。

僕の感想は以前書いた。

実践反復型ソフトウェア開発を読む part1~ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2~マージの戦略: プログラマの思索

実践反復型ソフトウェア開発の読書会ログ: プログラマの思索

実践反復型ソフトウェア開発を読む part3~再現可能なビルド管理: プログラマの思索

「反復型ソフトウェア開発」はソフトウェア工学の良書: プログラマの思索

【1】「実践反復型ソフトウェア開発」の良い所の一つは、ブランチ管理のポリシーやメインラインモデル、マージ手法について一通りの説明がされていることだ。
構成管理はソフトウェア開発者なら誰もが必要とするお作法なのに、構成管理に関する本は「実践反復型ソフトウェア開発」以外には「パターンによるソフトウェア構成管理」ぐらいしかまともな本がない。

【2】また、「実践反復型ソフトウェア開発」では、チケット駆動開発という言葉は明示していないが、チケット駆動開発に必要な概念やプラクティスが暗黙的に紹介されている点も良い。

例えば、障害管理の下記の運用ルールは、チケット駆動開発のプラクティスにそれぞれ対応している。

・バグを発見したらすぐに起票する→バグをタスク全般に拡張すれば、「Ticket First」
・一件一葉の原則(バグ1件に対し1枚のバグ票を起票する)→「One Matter, One Ticket」
・バグ報告票というボールでキャッチボール→「ペア作業」
・コミットして完了にするタスクは、そのチェンジ番号をタスク票に記入して閉じる→「No Ticket, No Commit」
・バグ報告票がなければ作業を開始しない→「No Ticket, No Work」

【3】個人的には、バグ追跡システム(BTS)が仕掛けかんばんの構造に似ている(P.204)という指摘が一番役立った。
「かんばんがなければ部品の製造を開始しない」「かんばんを通じて、部品や工程の作業実績と追跡する」という仕組みは、まさにチケット駆動開発そのものだ。

とはいえ、仕掛けかんばんがBTSと全く似ているわけではない。
TPSの仕掛けかんばんが、かんばんの流通量で在庫を制御するのに対し、BTSでは、障害票はふやしたくもないのに、いくらでも後から湧き出てくるから、障害の件数を人為的に制御することはできない。

だから、障害票の優先順位付けやチケットのトリアージ、担当者のアサインポリシーで制御する必要がある、という指摘は全く同意する。

トヨタのかんばん方式とバグ追跡システムの密接な関係: プログラマの思索


| | コメント (0)

2014/10/04

プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」を買って読んだ。
プロダクトマネージャに必要なスキルが書かれている気がした。
感想をメモ書き。

【参考】
『世界で闘うプロダクトマネジャーになるための本』8月22日発売です。:シロクマ日報:ITmedia オルタナティブ・ブログ

【1】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」は、アメリカのシリコンバレーで、プロダクトマネージャとして働きたい人に対し、採用ノウハウを提示する本だ。
Google、Apple、Amazon、Microsoft、Facebook、Yahooのような大手IT企業がどんなプ資質のロダクトマネージャを求めているのか、という裏事情がよく分かる。

少なくとも、世界の最先端の企業では、受託開発案件のプロジェクトリーダーではなく、世界の最先端のソフトウェア製品を生み出すためのプロダクトマネージャを必要としているわけだ。
だから、日本でこのノウハウがすぐに使えるかどうかは分からない。

【2】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」の目次を見れば分かるが、後半では、履歴書の書き方、転職の面接で受けるであろう質問について詳細に書かれている。
面接の質問の種類として、プロダクトマネージャに必要とされる行動、見積り、プロダクト、ケース(事例)だけでなく、コーディングに関する質問もあるのが面白い。

コーディングに関する質問では、計算量やアルゴリズムに関する内容が多い。
おそらく、ビッグデータによる分析の実現方法の能力を問われているのだろう。
練習問題があるので、解いてみると面白いかもしれない。

【3】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」を読むと、「採用基準」や「ビジネスリーダーへの キャリアを考える技術・つくる技術」の内容を連想させる。

採用基準」では、日本人がグローバルリーダーになるにはどんなスキルが必要なのか、を提示していた。
ビジネスリーダーへの キャリアを考える技術・つくる技術」では、若手社員が管理職や経営者にステップアップするにはどんなスキルが必要なのか、マネジメントの断層を提示していた。

では、「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」は何を提示しているのか?
世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」では、プロダクトマネージャに必要なスキルは何か、を提示している。
注意すべき点は、プロダクトマネージャ≠プロジェクトマネージャだ。
受託開発案件のプロジェクトリーダーに求められる能力とは完全に一致しない。

実際、「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」の第2章「プロダクトマネージャの役割」では「プロダクトマネジメントに対する誤解」として、「プロダクトマネージャはプロジェクトリーダーである」という説明がある。

プロダクトマネージャの職務は「チームが優れたプロダクトを出荷できるようにする」ことだ。
簡単に言えば、「プロダクトのミニCEO」だ。
つまり、プロダクトのビジョンと戦略、ロードマップを提示し、チームに対する直接的な権限も持つ。

【4】プロダクトマネージャは顧客側に立つ。
この意味は、プロダクトを使う顧客の観点で、プロダクトに必要な機能は何か、を探り、決定し、リリースすることだ。
プロダクトの種類には、GoogleのWeb検索エンジンもあれば、iPhoneのようなスマートフォンというハードウェア製品もあるし、Facebookの一機能もある。
それらプロダクトを使うユーザが何を求めているのか、そのニーズを見極め、プロダクトのゴールと機能を実現する。

そんな話を聞くと、プロダクトマネージャは、Scrumのプロダクトオーナーに似ている。
製品のロードマップや製品の戦略、ROIの観点から、プロダクトバックログを決めて、開発チームへ作業を指示するわけだ。
もちろん、プロダクトオーナーはプロダクトのアーキテクチャに詳しくなければならないし、アーキテクチャの実現や選択にも権限と責任を持つ。

【5】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」で最も興味深いのは、米国の大手IT企業が求めるプロダクトマネージャのスキルや理想像だろう。
たとえば、Google、Apple、Amazon、Microsoft、Facebook、Yahooの事例が挙げられている。
一部抜粋してみる。

【5-1】Google
・他企業に比べて、組織全体の透明性が高い。
 フルタイムのGooglerは、ほとんどのコードとドキュメントにアクセスできる。
 エグゼクティブチームは、全てのGooglerから質問を受ける機会がある。

・主にコンピュータサイエンス先行の新卒者を積極的に採用する。
 MBAホルダーよりも、修士号や博士号を重視する。

・Google、Microsoft、Facebookなどは、気軽で楽しい職場。
 無料の食べ物や飲み物、無料のマッサージなどの素晴らしい待遇が自慢。

・Googleのプロダクトマネージャ(PM)は、分析スキルが非常に重視される。
 データ分析がPMの主な仕事。
 検索と広告部門のPMは、利用状況のログから新しいプロジェクトのアイデアを考え出す。

【5-2】Apple
・トップダウンでサイロ型。
 プロダクトの方向性はエグゼクティブチームとデザイナーが厳しくコントロールしていて、社内のエンジニアはそのビジョンを実行するマシンのように働く。

・Apple製品を熱狂的に支持している人を求めている。
・ハードウェアとソフトウェアの両方を知っている人を積極的に採用する。
 コンピュータサイエンスだけでなく、電子工学や機械工学も知っていると良い。

・社員に長時間働くことを期待され、倹約が重視される。
 自社のミッションに駆り立てられているため、週末出勤や真夜中の電話対応もいとわない。

【5-3】Microsoft
・プロダクトマネージャは、MSでは「プログラムマネージャ」と呼ばれている。
 他企業に比べて、プログラムマネージャとプログラマの比率は1:3であり、プログラムマネージャがかなり多い。
 他企業では、プロダクトマネージャとプログラマの比率は1:10くらいらしい。

・プログラムマネージャには、大局的な視点で考え、問題を解決し、きちんと仕事を完成させることを求める。

・製品のビジョンと戦略はトップダウン。
 部門内におけるプロダクト戦略は、とてもまとまりがある。
 複数チームが同じゴールに向かって進んでいる感覚があり、2つのチームが競合する機能に取り組んでいることはめったにない。

【5-4】Facebook
・他企業に比べて最も技術面を重視し、技術に明るいプロダクトマネージャを求めている。
 実際、プロダクトマネージャ自身がプロダクトの初期プロトタイプを自作することは珍しくない。

・他社の従業員を雇用する目的で、その会社を買収する場合が多い。
 すると、その企業の設立者やCEOがプロダクトマネージャとして迎えられる場合が多い。

・ユーザがどのようにFacebookを使い、どんな問題にぶつかっているか、を観察することから多くのアイデアが生まれる。
 だから、Facebookのプロダクトマネージャは、ユーザの大量の行動履歴を分析し、注目すべき課題を見つけ、シナリオを作り、何を作りたいか、を提案する能力を求められる。

【5-5】Amazon
・MBAホルダーが重視される、など。

こんな内容を読むと、、Google、Apple、Amazon、Microsoft、Facebookの企業文化がうかがい知れる。
すごく面白い。

【6】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」で更に興味深い点は、プロダクトマネージャに求められる能力が一覧されていることだろう。

【6-1】新卒者は以下のスキルを身につけよう。
・コンピュータサイエンスを主専攻または副専攻にしよう。 

・専攻を2つ選ぼう。
 コンピュータサイエンス以外に、ビジネスやマーケティングがよい。
 ソフトウェア技術とビジネスの両面に興味を持とう。

・グループ研究、リーダーシップのスキルも身につけよう。
 チーム運営で役立つ。

・MBAはプロダクトマネージャとして役立つ。
 ビジネスやマーケティング、グループ研究、リーダーシップ発揮などでいろんな知識が得られる。

【6-2】エンジニアはプロダクトマネージャに転身するのに、適した立場にいる。
プロダクトマネージャは、技術的な経験をベースにビジネスやマーケティングの観点が必要とされるから。

エンジニアあがりのプロダクトマネージャに必要な観点は以下の通り。

・顧客本位に考える。
 この意味は、プロダクトを使うユーザの観点で、プロダクトの機能を考えたり、プロダクトのコーディングを考えること。
 顧客本位の姿勢を身につけるには、実際にプロダクトを使っているユーザと話すのが一番良い。
 それができないなら、システムのログを解析したり、カスタマーサポートのチケットを読むことから始めよう。

・大きく考える
 この意味は、プロダクトのビジョン、ゴール、戦略、ロードマップなどを大局的に考えること。
 どのように作るのか、ではなく、これまでにない新しいプロダクトを作るために必要なことを考えることに専念する。
 
 世界を変えるには?
 もし私が魔法の杖を持っていたら、という仮定のもとで、ブレインストーミングする。
 プレスリリースを書いて、製品のロードマップを書く。

・説得力あるコミュニケーションを身に付ける
 論理的な説明方法とちょっとしたカリスマ性も身につけよう。
 リーダーシップを意識的に発揮して、チーム運営することが求められる。

他にも、アメリカの実際のプロダクトマネージャのインタビューが記載されていて、なるほど、と頷く点もあった。


| | コメント (0)

2014/08/09

「APIデザインの極意」のメモ

APIデザインの極意」の感想Blogがとても素晴らしいのでメモ。
APIデザインの極意」を買おうと思ったら、台風で警報が出ており、買いに行けないのが残念。
ラフなメモ書き。

【元ネタ】
アジャイルAPI設計時代の到来!?APIデザインの極意を読みました。 - シスアーキ in はてな

ソフトウェア再利用の概念: プログラマの思索

ソフトウェア部品化の幻想: プログラマの思索

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

【1】ソフトウェア再利用の概念としては、ホワイトボックス再利用、ブラックボックス再利用の2種類の区別がある。

ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。
よくある例は、GUIコンポーネントや数値演算ライブラリなど。
例えば、DLL、Jar、Exeなどのバイナリの実行ファイルが相当するだろう。

ホワイトボックス再利用とは、再利用資産を要求に合わせて部分的に変更して使用する。
よくある例は、オブジェクト指向設計によるフレームワークなど。
例えば、Struts、Hibernate、Rails、Playなどの有名フレームワークが相当するだろう。

2000年代初頭の頃までは、コンポーネント指向開発が今後進むべき道だ、と言われていた。
オブジェクトを再利用資産として持ち、その資産を触らず、接着剤の部分だけソースを書けばよい、と。

【2】しかし、実際は、再利用できる部品を作り出すのが難しい。
再利用できる部品になるような設計が難しいのだ。
実際は、部品そのものに手を入れてしまい、中身はスパゲティコードになり、破たんする。
ソフトウェアプロダクトラインも、ドメインから再利用できる概念をコア資産として抽出しようとしたが、開発コストがかかり過ぎる割には、効果が薄いという評価が多い。

最近の傾向としては、フレームワークを使った開発手法を取るのが多い。
受託開発では、アーキテクチャ設計時に、どのフレームワークを採用するか、という決断が大きなウェートを占める。
良いフレームワークを採用すれば、開発効率や品質を担保できるし、知名度が高ければ、開発者の要員確保も楽になる。
その後の保守もやりやすいはず。

特に、Webシステム開発では、工期短縮のために、その時に有名なフレームワークを採用して、一気に作り上げる開発スタイルが多いと思う。

【3】しかし、フレームワークの利用にも癖がある。
SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索にも書いたが、大手SI独自のフレームワークを作りこんだ場合、保守が非常に大変だ。

俺様フレームワークはなので、中身が公開されていないので自分たちでパッチを当てることもできない。
フレームワークの修正を依頼しても拒否されたら、仕方なく、非常にダーティなパッチを当てて、その場限りの障害再現の回避を取らざるを得ない。
そんなことをしていくうちに、本番稼働中のソースを修正するのは忘れ去られて、ソースがどんどん汚くなる。

しかも、フレームワークのバージョンアップに追随できなくなる。
パッチを当てた箇所に影響が出るかもしれないから。
つまり、フレームワークのバージョンアップのたびに回帰テストの工数が増えて、顧客から見れば、何の価値も生まないバージョンアップに多大なコストを強いる。

【4】「APIデザインの極意」では、外部公開されるAPIのプログラミングに力点を置いて、そのノウハウが書かれているらしい。
内容を推測すると、ブラックボックス再利用の観点と思われるが、ホワイトボックス再利用の観点でも役立つだろう。

APIで思いつく例としては、SOAやWebサービスが思いつく。
よくある例は、クレジット会社が提供するクレジットカード支払いサービスがあるだろう。
カード支払いサービスのAPIを使えば、ECサイトの支払方法でカード支払いのロジックを作りこむ必要がなくなる。
特に、カード支払いサービスの利用事例が多いほど、パフォーマンスや品質も枯れていると推測できるから、下手に自分たちで作りこんで本番障害を発生させるよりも楽だ。
最近は、カード情報のような個人情報を自社で資産として持つ危険性の方が高いので、外部サービスを使った方がリスクが減るメリットもある。

アジャイルAPI設計時代の到来!?APIデザインの極意を読みました。 - シスアーキ in はてなを読んで、僕が、なるほどと思った点は以下の通り。

・APIの後方互換性の担保が重要。
 APIを長持ちさせるには、ソース互換性、バイナリ互換性、特に機能互換性が重要。

・APIが後方互換性を維持しながら健全に発展できる為の具体的な手法の一つとして「不変型を指定するためにJavaインタフェースを使用する」「メソッドを安全に追加できる型としてfinalクラスを使用する」

・Decoratorパターンは問題になりやすい。
 APIは使用者向けと提供者(サービスプロバイダー)向けに分けて提供する。

・テストをサポートするテストAPI、テスト互換性キットは、仕様書の代わりになる。
 APIの後方互換性の維持のために非常に役立つ。

・今後APIはより、宣言型プログラミングや関数型プログラミングに向いて進化する

APIに関する実際のノウハウが公開されているのは興味深い。

| | コメント (0)

2014/04/08

「チーム開発実践入門」が発売されている

チーム開発実践入門」が発売されているので、目次をリンクしておく。

チーム開発実践入門──共同作業を円滑に行うツール・メソッド:書籍案内|技術評論社

目次
第1章:チーム開発とは
第2章:チーム開発で起きる問題
第3章:バージョン管理
第4章:チケット管理
第5章:CI(継続的インテグレーション)
第6章:デプロイの自動化(継続的デリバリー)
第7章:リグレッションテスト

目次をみると、Gitのワークフローとして、git-flow, GitHub-flowが紹介されている。
チケット駆動開発も紹介されているが、特に、継続的デリバリーの章が興味深い。

ちょっと分からなかったことは、ブートストラッピング(Bootstrapping)、コンフィグレーション(Configuration)、オーケストレーション(Orchestration)という言葉は、継続的デリバリーのパターンなのかな?

ここ数年、開発環境の周囲は大きな技術革新が生まれている。
チケット駆動開発もその一つの流れに入っているが、「チーム開発実践入門」は、最近のクラウド技術や継続的デリバリーの部分も最新の内容が詰め込まれているみたい。
読んでみたい。

| | コメント (0)

2013/06/15

MEDIA MAKERSの感想

MEDIA MAKERS」を読んで面白かったのでメモ。
著者は、リクルート、ライブドアの広報関係を経て、NHN Japanにいるらしい。
自分のBlog、Twitter、Facebookを持っている人は参考になると思う。
ラフなメモ書き。

【参考】
[書評]MEDIA MAKERS―社会が動く「影響力」の正体 | ごりゅご.com

書評『MEDIA MAKERS 社会が動く”影響力”の正体』(田端信太郎)がめっちゃ勉強になる | Last Day. jp

[書評]ブロガーも必読。MEDIA MAKERS―社会が動く「影響力」の正体 - 拡張現実ライフ

Facebookはセルフブランディングの最強ツール: プログラマの思索

ビジネス特化SNS「Linkedin」から見えるもの~人脈はデータマイニングで作られる: プログラマの思索

Twitterは最速のメディア: プログラマの思索

真のIT企業はメディア企業を目指す: プログラマの思索

Google、それは強大な広告代理店: プログラマの思索

【1】メディアリテラシーがマネージャや経営者にも必要になった現代という時代

経営資源といえば、人・モノ・金・情報。
過去はお金がボトルネックになりがちだったが、現代はかなり変わった。
リーンスタートアップのように、小さなビジネスから始めて大きな会社に変わる事もできる。
シリコンバレーのIT企業がその典型例。
FacebookもGoogleもいつの間にかMicrosoftと肩を並べる企業になった。

すると、「War For Tarent」のように、メディアを使って、いかに優秀な人材を集めるか、ということが企業にとって死活的に決定的に重要になってきた。
メディアは、人の注目を集め、優秀な人材(タレント)を引き寄せて、タレントを動機づける機能を持つ。

現代では、マネージャという管理職、組織を動かす経営者は、メディアという機能をもっと知る必要があるし、効果的に使う方法を知る必要もある。
それは丁度、経営者やマネージャのレベルの人は、減価償却やキャッシュフローの意味を知っていて、会計やファイナンスを理解しているのが当然のように。

【2】メディアが存在する意味~予言の自己実現能力

メディア自身が保つ意味は、予言の自己実現能力。
大手新聞や大手テレビが、現実はそうなっていないのに、こうなるだろう、と予言すると、その方向へ現実が変わってしまうこと。
例えば、企業の倒産につながる大事件などのようなスクープは、そのニュース自身が政治的に大きな影響力を持つ。
沢山の人、集団を巻き込んでしまう。

そして怖いのは、その発言(予言)は間違っていたので訂正します、という作業が不可能なこと。
予言が現実になってしまった後に、現実を訂正することはできない。
予言の自己実現能力の的中率が大きいほど、政治的影響力も大きくなるから、それ自体が権力にもなる。

だから、メディアは信頼性や高潔さ、ブランドが重要視される。
誰もそのメディアの情報を信じなくなったら、メディアには存在意義がない。
編集権の独立は、メディアにとって死活的に重要な要因。
広告主や株主の意向で簡単に変わるようなメディアであれば、ユーザはすぐにその意図を感じ取り、メディアの影響力は限定的になる。
メディアの信頼性が他メディアの差別化要因にもなる。

【3】メディアの種類

メディアの種類は、3種類の軸がある。
一つは、ストック型・フロー型。

メディアの情報がストックされるのか、フローとして流れていくのか、の違い。
ストック型は例えば、源氏物語のような古典小説もあれば、WikipediaのようなWebメディアもある。
Wikipediaはgoogle検索と相性が良い。
実際、google検索エンジンの上位にはWikipediaがあり、Wikipediaはたくさんの人の目に触れて、更新されることでその存在価値を増している。

フロー型は例えば、TwitterやLINEなどもあるし、新聞も同じ。
新聞は1日しか賞味期限がない。
(Twitterは現代のメディアの中で最速のメディアだと思う。その分、Twitterの政治的影響力は大きい。大阪維新の会の橋下氏はTwitterを有効に使っていると思う。)

2つ目は権威型・参加型。
例えば、権威型はミシュラン、参加型は食べログのような違い。
権威型メディアは、内容を恣意的に制御することで、メディアの内容の価値や信頼性を高めようとする。
参加型メディアは、Googleの検索結果のように、集合知に特徴がある。
カカクコムにおける製品の感想、Amazonでの商品の感想も同様。

Googleがその検索アルゴリズムに恣意性がないことを保証することが彼らのビジネスで決定的に重要であったと判明した事象が、中国から除外された事件。
GoogleのPageRankアルゴリズムに恣意性が混じっていると判明したら、Googleの存在価値はかなり落ちてしまうだろう。

3つ目はリニア型・ノンリニア型。
メディアに触れる時に時間を縛るかどうかの観点。

例えばリニア型は映画。
映画館で2時間も拘束する。
そして、映画監督はCMディレクターなど似たような職種の中で最も権威が高い。
書籍もリニア型に近い。

ノンリニア型は、Web。
主権はユーザにあり、マイクロコンテンツ化される。
サイトマップを作って、Webにストーリー性を入れても、SEOでリンクから入った画面しか見ない時が多い。

今のメディアは、フロー・参加・ノンリニアへどんどん重心が移動している。
それが良いかどうかは別として、その傾向がある。

【4】メディアのビジネスモデル

稼げるメディアは自由になれる。
貨幣とは鋳造された自由。
編集コストを気にしなくていいし、イベントの広告宣伝もできる。
株主や広告主のような外部の利害関係者からも自由になれる。

Webメディアの利益は、(PV当たり売上-PV当たり費用)* 全体PV という簡単な公式。
だから、KPIとしては、PVを増やすためにUU(ユニークユーザ)を増やしたり、UU当たり売上を増やすなどの方法がある。

新聞やWebなどのメディアの弱点は、売上回収のビジネスモデルが不安定なこと。
新聞もWebメディアも広告モデルに依存していた。
しかし、広告主自体がメディアを持つのが簡単になり、TwitterやFacebookなどで告知する影響力が大きくなったから、広告を出す必要もない。
(個人メディアとしてはBlogにGoogleやAmazonのアフィリエイトが普及したことにより、個人メディアでも広告モデルが成り立つようになったのは大きい事象だ)

そこで、メディアとしては課金モデルの確立が課題。
最近は、個人メディアとして有料メールマガジンが流行している。
メールマガジンという最も古い媒体で課金モデルが有効であるのは興味深い。

【5】メディアはアーキテクチャに支配される~媒体手段が人間の経験形式を規定する~

メディアの内容は媒体手段というアーキテクチャに大きく支配される。
CDが74分なのは、カラヤンが第九が入るだけの容量にして欲しいとソニーにお願いしたから。
そこから音楽CDが流通手段として普及し、音楽の聞き方も変えてしまった。
特に90年台。
サビ頭の曲が増えた。例えばZard。
音楽CDはリモコン片手に好きな曲だけつまみ食いできるから。
以前のように、後半にサビを持ってくるような曲は減った。
iTunesになって、更に曲はバラ売りされるようになった。

WebメディアはPVを稼ぐように最適化されている。
例えば、タイトルや見出しは、SEOで検索されやすい言葉を並べるように変わってしまった。
スマートフォンのようなデバイスが普及して更に変化した。
だから、新聞のような大手メディアも、いつの間にか時代遅れの路地裏の店に変わらないとも言えない。

新聞はプラットフォーマーなのか、プレイヤーなのか?
GoogleのCEOが話したように、ネット上のプラットフォーマーは、Google・Amazon・Apple・Facebookのたった4社だけ。
プラットフォーマーは莫大の個人情報データを持っているのが最大の強み。
しかも、AmazonやAppleはクレジットカード番号の個人情報も持つので、ユーザが興味を持てばすぐに支払ってくれる基盤すらある。
そこからより効果的な広告を表示したり、レコメンドエンジンで商品を誘ったり、色んなビジネエスができる。
プラットフォーマーに新聞がないだけでなく、マイクロソフトやヤフーすらいないのも興味深い。

【6】メディアの怖さ~個人メディアは無限責任、組織メディアは有限責任

商業メディア、組織メディアは株式会社であるからには、有限責任になる。
しかし、「誤報すら自己実現化してしまう」メディアと有限責任は相性が悪い。
組織メディアの最終責任は会社の倒産だが、個人の責任まで及ぶことは稀。

でも、メルマガやBlog、Facebookなどの個人メディアで同様のことがあれば、その個人の社会的地位や評判、名声を否定され、社会的な抹殺までされてしまうだろう。
つまり、個人メディアは無限責任。

個人メディアは、そのメディアを発信する個人が持つ信頼や影響力に大きく依存している。
その信頼や影響力を評価資本と呼ぶこともあるらしい。ある意味では個人ブランド。

個人メディアを持つ人は、ある分野において信頼と影響力を持つ個人型メディアといかに付き合うか?
そこで披露される知見を他メディアとどのように差別化していくか?

【7】「MEDIA MAKERS」を読んでみて、BlogやTwitter、Facebookが、個人メディアになる可能性があり、影響力を持つツールであることを改めて痛感させられた。
最近は、「メディアが予言の自己実現能力を持つ」意味をよく理解していて、うまく使いこなしている人も多いように感じる。

特に、社長のような経営者や政治家は、BlogやFacebook、Twitterを上手く使って、自分の考えを発信することが重要になっていると思う。
ITベンチャー企業のような小さな会社は、アナログの営業よりも、BlogやFacebookで開発者や潜在顧客へリーチする手法を使った方がより効果的だろう。

でも、メディアにはその影響力の行使と表裏一体の怖さもある。
今後、ITリテラシーと同様に、メディアリテラシーも普通の一般人にも必須の能力になってくるのかもしれない。

| | コメント (0)

2013/05/31

IT人材白書2013を読んだ感想

日本のIT業界でも、日本のIT技術者も、アジャイル開発へ大きくシフトし始めているようだ。
IPAが公開したIT人材白書で気になった箇所を見つけたのでメモ。

【元ネタ】
情報処理推進機構:プレス発表:記事:「IT人材白書2013」のポイントを紹介 ITベンダーからユーザー企業へIT人材の流動が明らかに ~中途採用でユーザー企業のIT部門に配属された人のうち40.5%は直前の職場がITベンダー~

IPA 独立行政法人 情報処理推進機構:IT人材白書

IT人材白書2013 製本版・データ編は、アンケートに回答すればPDFを無料で取得できる。
6部あるうちの「IT人材白書2013~強みを活かし多様化の波に乗れ~グローバルIT人材、WEB人材に求められるスキルとは」(ITjinzai2013_Hires.pdf)の280ページ、288ページには、開発プロセス別のIT人材に対する興味深い調査内容が掲載されている。

Q. 日々の開発業務において開発プロセスの改善を意識しているか
 アジャイル型:   「よく当てはまる」→20.4%
 ウォータフォール型:「よく当てはまる」→9.2%

Q. 今の仕事に一生懸命取り組んでいる
 アジャイル型:   「よく当てはまる」→28.4%
 ウォータフォール型:「よく当てはまる」→12.5%

Q. 仕事が好きである
 アジャイル型:   「よく当てはまる」→23.4%
 ウォータフォール型:「よく当てはまる」→9.9%

Q. この仕事をしていることを誇りに思う
 アジャイル型:   「よく当てはまる」→19.9%
 ウォータフォール型:「よく当てはまる」→7.3%

上記の調査結果では、アジャイル開発を実践している技術者の方がWF型の人よりも、より高いモチベーションで、開発プロセスの改善を意識している事実を示唆している。
しかも、アジャイル型人材の方がWF型人材よりも2~3倍の違いがあるから、かなりの差があることになるだろう。

この傾向から知られる事実は、管理職よりも経営者の方が目ざとく知っているように思える。

Twitter / akipii:1月24日号日経コンピュータのマネックス証券CTOの記事が面白い。「OSS、アジャイル開発といった新技術を取り入れることが、結果的に優秀な技術者が集まり、プロジェクトの成功が高まる」

とは言え、アンケート調査の母数が偏っている可能性もあること、アジャイル型人材に未踏プロジェクトのような日本のSIとは全く別の高度な人材が入っていること、WF型人材が日本のIT業界のほとんどを占めていることを考えると、あまり比較にならないかもしれない。

でも、XP祭り関西のLTでは、プログラミングの勉強のためにIT勉強会に顔を出していたら、皆がアジャイルの話をしていて最初は分からなかったが、自然にアジャイルに興味を持ち始めて、勉強し始めたという話もあった。

アジャイル開発は、チームによるソフトウェア開発を支援するプラクティスやプログラミングテクニックがたくさんある。
アジャイル開発に触れれば、プログラミングだけでなく、開発プロセスやソフトウェア工学にも自然に興味を持ち始めるきっかけになる。

アジャイル開発には、プログラマを力づける雰囲気があるのだと思う。

| | コメント (0)

2013/05/19

Jolt Awardsのリスト

Jolt Awards は プログラマ向けのソフトウェ関係の書籍を扱う総花的なアワードらしい。
1990年からの20年間でどんな本がアワードとして選ばれてきたのか、興味を引いたのでリンクしておく。

【元ネタ】
Jolt Awards の 20年 - etc9

steps to phantasien t(2007-07-14)

【1】個人的な興味はオブジェクト指向設計やアジャイル開発プロセス。

アジャイルソフトウェア開発 (The Agile Software Development Series)」には、アジャイルマニフェストが生まれた背景が書かれているらしい。
今度読んでみたい。
SpolskyとBobおじさんの対決にも、「アジャイルソフトウェア開発の奥義」で有名なRobert C Martinが発起人となり、いろんな議論をした経緯が書かれていて面白い。

アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか - kawaguti の日記 (id:wayaguchi)

【2】Steve McConnellも意外に沢山の本を出している。
彼の本で有名な著作は、「Code Complete第2版〈上〉―完全なプログラミングを目指して」「Code Complete第2版〈下〉―完全なプログラミングを目指して」と、「ソフトウェア見積り―人月の暗黙知を解き明かす」ではないだろうか。

ソフトウェア見積り―人月の暗黙知を解き明かす」では、マネージャやリーダーが必ずぶつかる見積り技法について詳しく書かれていて、とても参考になった。

Steve McConnell著作の下記の本「「ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)」」も読んでみたいと思った。

【3】技術的な流れを見ると、プログラミング言語はC++→Java→Ruby→Scala、Lispなどの関数型言語へ進化している。
開発プロセスもPSPなどからアジャイルへ、設計技法もオブジェクト指向からWebのUIへ、と移り変わっているようだ。
こういう流れを見ると、今後、ソフトウェア開発はどのように進化していくのか、を色々考えるのが楽しい。

| | コメント (0)

2013/05/11

わかりやすいAgile開発の教科書はお勧めです

わかりやすいアジャイル開発の教科書」を献本して頂き、じっくり読んでみた。
アジャイル開発を実践する時に最初に参考にするガイドブックとして使えるのではないかと思う。
感想を箇条書きでラフなメモ書き。

【1】アジャイル開発が目指すものは何なのか、というWhyを説明してくれている。
アジャイル開発そのものを自己目的化しないためにも必要。

【2】ソフトウェアの価値とは何なのか?
この部分は、日本のIT業界が遅れている所だと思う。
理由は、受託開発案件が多いために、プロジェクトを納期までにとにかくCloseさせることに精一杯であり、納品したソフトウェアやシステムが顧客に役立っているのか、という観点まで頭が回らないから。

普通は、1次開発で赤字を出しながらも何とか本番稼動させて、2次開発や運用保守で、顧客の業務と実システムの不一致や、業務の改革まで目を向けるようになる場合が多いように思う。
本来は、システム導入によるIT化によって、ユーザ企業の業務改革に役立てたいのだが、肝心のシステムを稼働する品質に持って行くのが、現場ではとにかく大変なのだ。
アジャイル開発はその問題への対処の一つとしてあげられているわけだ。

では、価値づくりのプロセスとして具体的にどのようにやれば良いのか?
わかりやすいアジャイル開発の教科書」では、要求開発におけるコタツモデルを参考にしながら、経営者・IT技術者・業務担当者の観点で、あるべきシステム像を見出そうとしている。
この考え方はなるほどと思う。
但し、立場が異なる3つの組織を束ねて何らかの結論を導く必要があるから、高度なファシリテーション能力やマネジメント能力が必要とされるだろうと思う。

【3】「わかりやすいアジャイル開発の教科書」で面白いのは、実体験に基づいた事例がふんだんに紹介されている点だ。
著者の方の深い経験がすごく感じられる。

「価値が分からないストーリーカード」は要件定義に慣れていない人がはまりやすいアンチパターン。
技術者という立場を離れて、顧客の立場で考えることができるか、という点が大切。

「タスクカードの書き方がバラバラ」も、プロジェクト管理やタスク管理に慣れていない人に多いアンチパターン。
どんな作業をして欲しいのか?
アウトプットは何なのか?
作業しやすいタスクの粒度に注意しているか?
この辺りは、チケット駆動開発を実践しているととてもよく分かる部分。

「%マジック」もありがちなアンチパターン。
ウォーターフォール型開発では、1機能の進捗を工程別に%で計算する時が多い。
特に工事進行基準でプロジェクトの売上計上を実施しているなら尚更だ。
90%まで終わりました、と報告を受けたのに、いつまで経っても作業が完了しない場合が多い。
アジャイル開発の観点では、いくら設計書を作ったとしても、プログラムを書いたとしてもテストしていなければ、動くプログラムがなければ進捗はゼロに等しい。
チケット駆動開発を実践していると、ワークフローをどのように決めて運用するのか、という問題に置き換えられるだろう。

「サインアップの注意」としては、本来は、担当者自らタスクを取りに行くハッピーサインアップであるべき。
とは言え、プロマネの立場としては、プロジェクト運営上、役割が漏れていないタスクがないか、常に確認する必要はある。

「KPTが飽きられた」ケースもよくある。
チームで毎週いくら問題を出したとしても、問題が解決されて問題が減らないと成長している実感が無い。
KPTが上手く回っている時は、Problemにあがった問題に対し、Tryでいくつかの解決案が提示されて、実際に実行した結果、解決されて、そのノウハウがKeepに入り、最後は暗黙知としてKeepから消える。
KPTを上手く回すには、チームに変化や成長が必要だと思う。

「ペアプロがトレーニングになってしまう」場合もよくある。
特に、ペアの二人の能力差が大きい場合は特にそうだ。
だから、ペアを固定せずに、チームメンバー全員に技術ノウハウや業務ノウハウが共有されるようにどんどん回すべき。
ソフトウェア開発では一人で作業することはほとんどなく、ペアプロや本番リリース作業の立会のように同一時間帯に同一の場所で二人で作業するときもあれば、コードレビューや受入検証のように非同期で二人が成果物を作ってチェックし合う(ペア作業)時もある。
ペアプロやペア作業を意識してチームに浸透させれば、メンバーの作業の能力が平均化されるため、トラックナンバーが1となるリスクを減らすことができるし、ジョブアサインの選択肢が増えるのでプロマネとしても助かる。

【4】第4章「アジャイルを現場に定着させよう」の部分は、ファシリテーターとしてチーム運営する時に役立つノウハウが詰め込まれている。
アジャイル開発の面白さは、TDDやCIのような技術面と、チームビルディングの観点があると思う。
各メンバーの専門能力を組み合わせて、チームをいかに有機的に形成していくべきか、という手法について、アジャイル開発にはたくさんの事例が今までたくさんあげられてきた。
プログラマ出身のプロジェクトリーダーやプロジェクトマネージャにとって、最も役立つ部分ではないだろうか?

わかりやすいアジャイル開発の教科書」を最初に読んだ時、読者層は開発者が対象と思ったけれど、何度も読み直すうちに、現場リーダーが本来読んで欲しい対象なのかな、と気づく場面が多かった。
色んな人が、自分の役割や立場の観点で読めるのだろうと思う。
また、チケット駆動開発をアジャイル開発のタスク管理の事例としてあげられていたのも嬉しかった。

個人的には、「わかりやすいアジャイル開発の教科書」に描かれている絵が可愛いので、内容が難しくない印象を受けるのも良い点になるかなと思う。

| | コメント (0)

より以前の記事一覧