書籍・雑誌

2020/04/09

ソフトウェア・ファーストの感想

「ソフトウェア・ファースト」を読んだので、感想をラフなメモ書き。
非常に良い本だったので、自分の気づきをメモしておく。

【参考】
ソフトウェアファーストを読んで開発組織と外部委託について考えた | masaytan's blog

『ソフトウェア・ファースト』読書メモ その1 - Qiita

ノンプログラマーの機械屋が読んだ「ソフトウェア・ファースト」

【1】「ソフトウェア・ファースト」は良い本だ。
「ソフトウェア・ファースト」のターゲットは、特にメーカーの経営陣、中間管理職の人達だと思う。
そういう言葉は書かれていないが、トヨタの話やメーカーの生産管理とソフトウェア開発の比較、などの話が多いので、メーカーの人にはとても響くだろう。
特に、メーカーにいて、ITに詳しくないが、ITが経営に直結している立場の人達、つまりメーカーで経営上の意思決定をする人達が読むべき本だ。
どのメーカーも、トヨタが生み出したJIT生産、なぜなぜ分析、自働化など数多くの概念を自社に取り入れようと努力してきたから、あのトヨタも変わっているのか、と気づくだろう。

【2】IT技術者として「ソフトウェア・ファースト」を読んで興味を惹いた部分はいくつかある。

【3】メーカーがソフトウェア開発を内製化していない点を痛烈に批判している。
メーカーの生産管理では、自社の工場で生産計画・生産統制をできるだけ内製化し、その品質管理だけでなく、外部取引先から調達する部品の品質管理も徹底的に行なっている。
「手の内化」というトヨタの言葉はその通り。

たとえば、日本の元請け企業は自社の技術社員を、下請け企業に派遣して、調達する部品の品質管理や進捗管理を行うだけでなく、わざわざ下請け企業の社員に技術指導まで行っている場合が多い。
つまり、日本のメーカーは、自社の工場だけでなく、自社の製品に関わる下請け企業までを生産管理の対象とみなし、一連のサプライチェーンを品質管理することで、品質向上を図ってきた。
だから、日本の製造業が生み出す製品の品質はとても高い。

一方、メーカーのソフトウェア開発では、自社でソフトウェア開発は内製化しないだけでなく、外部からの委託・調達したソフトウェア製品やソフトウェア成果物の品質管理すらも全くできていない。
つまり、メーカーは製造プロセスのサプライチェーンまで自分でコントロールしているのに、なぜ、ソフトウェア開発ではまともな品質管理すらせず、コントロールしないのか、と。
IT技術は知らないから、というのは言い訳に過ぎない、と痛烈に批判している。

たとえば、「ソフトウェア・ファースト」の一節に、トヨタの豊田章一郎社長が社長に就任した時に、企画開発チームに実際に赴いてその知見を乞うたが、あのトヨタの社長でもそうならば、ITが経営上重要になっているならばソフトウェア開発の現場に経営陣も自ら赴くべきではないか、と。
3現主義と言いながら、ソフトウェア開発の現場は見ていないでしょ、と。

【4】SaaSはソフトウェアの特徴をうまく活用している、という主張は本当に興味深い。
SaaSの最大の特徴は、ユーザの生の声をフィードバックで収集できる点だ。

自動車であれ大半のメーカーでは、工場や最新機械などの固定費が膨大な為、資本を減らすために、販売店などを切り離している。
よって、メーカーは販売した製品に関する消費者の生の声を集めるチャネルを持っていない弱点がある。
この弱点は、昨今のGoogle・Apple・Facebook・Amazonを見る通り、メーカーにとって致命的。
トヨタのようなガソリン自動車メーカーは直販プロセスを持っていない一方、後発の電気自動車メーカーであるテスラは、直販チャネルを持っている上に、さらに、自車の運行データをユーザから収集して自動運転に活用しようとさえしている。

Saasでは、ユーザの生の声はカスタマーサポートからシステムのアクセスログに至るまで、数多くのチャネルがあるので、それらを収集して分析することで、より良い製品へ改良するきっかけになるし、開発チームにとっても、製品改良のモチベーション向上にもつながる。

特に、GAFAは、ユーザのフィードバックの収集・分析・改良・リリースという一連のプロセス構築がうまいのだろう。
その一連のプロセスは、アジャイル開発そのものだ。
従来のメーカーが大事にしてきたPDCAサイクルとは本質的に違っていると思った方が良い。

僕自身が持つアジャイル開発の認識も古くなっていると思った。
僕は以前は、アジャイル開発の本質は小規模リリースだ、と思っていたが、今は1日数十回もリリースできるような高速な開発プロセスにまで洗練されている。
そのアジャイル開発の本質は、DevOpsだ。

DevOpsは単に、運用も開発もチームが一体化したもの、という認識だけではないと考える。
ソースを機能改善したら即反映できるリリースプロセスを整備したもの、と認識すべき。

以前のアジャイル開発のボトルネックは、リリース工程にあったと思う。
継続的インテグレーション、継続的デプロイなどがXPのプラクティスにも含まれていたが、それらが重要なプラクティスであった理由は、リリース工程がソフトウェア開発の最大のボトルネックだったからだ。

実際、今でもWF型開発でソフトウェアを開発していれば、製造工程よりもテスト工程とリリース工程で膨大な工数がかかっているはずだ。
多くのプロジェクトマネージャは、テスト工程でリリース工程で手を焼いているはずだ。
つまり、下流工程と呼ばれるテストやリリースの工程がソフトウェア開発のボトルネックであり、それを制御するのは難しい、という現実を示唆していたのだと思う。

しかし、今では、クラウド上でカナリアリリースやInfrastructure as Codeのように、本番環境やリリース作業を構成管理の配下でコントロールできるようになったおかげで、自信を持ってソースの機能改善ができるし、新機能に挑戦できる心理的メリットも生まれているはずだ。
つまり、システムの機能改善という、ソフトウェアの本質的な価値を具現化するものにより力を注げる開発プロセスを構築できるようになったわけだ。

【5】メーカーがソフトウェア開発を内製化した時の組織構造や組織文化の話も非常に興味深かった。

一読した限りでは、メーカーの組織文化とソフトウェア開発の組織文化は水と油なので、ソフトウェア開発は別の組織で分社したり、企画開発に特化したり、マトリクス型組織にする、などの示唆があったのは興味深い。
たぶん、著者自身も数多くの試行錯誤をされているのだろう、と思う。

メーカーではないが、サイボウズの組織構造の変化のコラムが興味深かった。
サイボウズも中小企業だった頃は、機能別組織であって、開発・運用基盤・企画営業など縦割りの機能に分かれていた。
しかし、SaaSを販売してユーザのフィードバックをSaaSに反映していくようになると、そういう縦割りの機能別組織では、社内のコミュニケーションが取れず、現場が混乱した。
そこで、製品別組織に立て直し、企画から開発・運用に至るまでのプロセスを一つの部門で担当できるようにしたら、上手く回るようになり、組織文化も良くなっていった、という。
つまり、機能別組織から事業部制に変化したわけだ。

この話を読んで、チャンドラーの「組織は戦略に従う」という文言を思い出させる。
チャンドラーの組織発展モデルでは、企業内部の組織は事業の発展によって、単一の機能別組織から事業部制組織、そして分社化した子会社・関連会社を持つコングロマリットという多国籍企業へ変わっていく。
ソフトウェア開発の組織構造も、メーカーと異なっているとしても、組織構造のモデルという自然法則に従わざるを得ないわけだ。

【6】ソフトウェア開発組織の職種として、エンジニアという技術専門職だけでなく、プロダクトマネージャーとエンジニアリングマネージャという管理職も上げている点が興味深かった。

僕の理解では、エンジニアリングマネージャはアーキテクトかつプロジェクトリーダーのイメージ。
プロダクトマネージャーは、Scrumのプロダクトオーナーのイメージ。

プロダクトマネージャは、ソフトウェア開発の経験があるのは良い点だが、その経験が逆に邪魔する時がある。
本来の製品のあるべき姿は、その時代の技術の制約から離れて考えるべきなのに、ソフトウェア開発の経験が邪魔して、その時代の実装方法に依存した製品イメージを描いてしまい、本来の姿とかけ離れてしまう弱点もある、と。
そういう指摘は非常に参考になった。

| | コメント (0)

2019/12/27

捏造された聖書の感想

とても面白い。
キリスト教が誕生して、カトリックと三位一体説が正統派として確立するまでの間、数多くのキリスト教の流派があり、それぞれで議論して闘争していたのがよく分かる。

つまり、中国の諸子百家、インドの仏教とジャイナ教の対立のように、原始キリスト教も数多くの流派がそれぞれの自説を主張して生存競争をしていたわけだ。

「捏造された聖書」を読む前に、下記を読んで、キリスト教における三位一体説を理解していたので、聖書が改ざんされた意図や背景が良く理解できた。

キリスト教の発展、分裂後の東西ローマ帝国 http://www.geocities.jp/timeway/kougi-19.html

論点は「イエスは神なのか?人間なのか?」
現存のキリスト教は、三位一体説を奉じるので、イエスは神であり人間でもあるが同質である、という立場。

原始キリスト教の世界では、イエスは人間だったという養子論、イエスは神であるが旧約聖書にあるユダヤ教の神とは違うという仮現論、イエスは人間イエスと神キリストの二つの物理的存在に分割されているという分割論、など多数の流派があった。

しかし、三位一体説を奉じる流派が唯一生き残ったことにより、それら流派の解釈を許さないように、聖書の文言を改ざんしていった、というストーリー。

だから、最近になって、三位一体説を否定するキリスト教の流派、たとえば、エホバの証人、とか、モルモン教などが、現存のキリスト教はおかしいのであって自分達が本来のキリスト教なのだ、と主張しているわけなのか。

こういう理解ができた後、今のキリスト教を信じている人は、この本は信仰を否定するような内容になるので、危険な本だろうな、と思う。
読んでいてハラハラした。

捏造された聖書では、他にも、現代から真の聖書を探していく作業、つまり文献分析学の話を相当詳しく説明してくれているので、とても分かりやすい。

| | コメント (0)

失敗の本質―日本軍の組織論的研究の感想

旧日本軍という当時最先端の高度な官僚組織が日本を破滅に陥れた原因を、組織論に求める、という内容だった。

(1)7つの失敗事例の詳細は、地図を見ながら読まないと完全理解できないと思うけど、失敗に至った話を読むと、とても身に沁みるように感じるのは、たぶん、自分も古い日本の大企業にいるからかもしれない。

改めて思うのは、80年前も今日も、日本のトップは、巨大な官僚組織を上手く使いこなすのが下手、ということ。
一人ひとりの部下を動かせても、「組織を動かす」という能力が足りない、という感触を受ける。

日本の大手企業や官公庁のトップは、その大きな組織の重みをコントロールできず、誰も舵を取らないまま暴走してしまい、破滅に向かう。

一方、アメリカや中国は、官僚組織を使いこなすのが上手い感じはする。
その違いは何にあるのだろうか?

| | コメント (0)

お金2.0 新しい経済のルールと生き方の感想

自然界のあらゆるものは時間の経過と共に価値が減っていくのに、通貨のみは価値が減らないどころか、金利によって増えていく。それは欠陥だ。
だからスタンプ貨幣を導入して、通貨にマイナス利子率をつけよう、というゲゼルの主張。

ビットコインは、報酬設計が秀逸。
インセンティブを強調しすぎて崩壊する金融市場。
誰が得するのか不明な新技術。
理論の美しさのみで実現する気のない思想論文。
しかし、ビットコインは、経済、テクノロジー、思想のそれぞれが役割を果たして、うまく報酬設計がなされている。
ビットコインの発案者は理想主義者ではなく、動くものを作りたい現実主義者ではないか、と。

| | コメント (0)

2019/02/11

「サピエンス全史」「ホモ・デウス」の図解のリンク

一世を風靡した本「サピエンス全史」「ホモ・デウス」を図解した記事があったのでリンクしておく。
書籍を一度読んだ人であれば、この図解を見れば、そういうストーリーだったことを思い出せるはず。

【参考】
サピエンス全史図解(詳説版)|きょん|note

ホモ・デウス図解|きょん|note

akipiiさんのツイート: "この図解はすごく分かりやすい。plantUMLで書き換えてみたいな。サピエンス全史図解(詳説版)|きょん @kyon_hcj|note(ノート) https://t.co/kpZUiXCvgR"

akipiiさんのツイート: "利害関係者の図をPlantUMLで書く事例。分かりやすい。面白い。2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない https://t.co/8B15anmKAj"

【1】「サピエンス全史」「ホモ・デウス」は歴史好きの人にはたまらない本ではないか、と思う。
欧米人の学者は、歴史上の数多くの事実を一つの理論や体系、思想を元に整理して、一つの壮大な絵巻物で表現するのが上手だと思う。
でも、その膨大な量に圧倒されて、結局何が言いたいのか、を掴むのに結構時間がかかる。

そこで、上記の図解を読めば、まずは一つのストーリーを即座に理解できるので、その理解をもとに書籍を読み直すと理解しやすくなると思う。

【2】最近、歴史や法律など文系の知識をモデル化する事例に興味がある。
たくさんの文章に、言いたいことが埋もれてしまっていてすぐに理解できない時に、図解やモデリングの技術を使って、概念を鳥瞰して理解したいのだ。

例えば、利害関係者の図はパッケージ図やクラス図、歴史の流れはシーケンス図、といったモデルで表現すると、実は意外に分かりやすくなる。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

akipiiさんのツイート: "この発想はいいな。歴史や政治、法務はモデル化したい。RT @naruyo_t: UMLで図を描くというのはおもしろい。ただ見栄え気にしたい派の私としてはpptがなじんでて下書きでの整理に良さそうと思った。 “2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない” https://t.co/8B15anmKAj"

色々試してみたいと思う。

【追記】
hekitterさんはTwitterを使っています: 「「サピエンス全史」「ホモ・デウス」の図解のリンク https://t.co/6KSKQH4Dph 今日UMLのことを調べてたら、思いがけず興味深いのがあるやんとみてたら、やはりakipiiさんの記事だった。(まだちゃんと読めてないので改めて読む)」 / Twitter

| | コメント (0)

2014/07/05

出版システムや文書共有システムを作った事例

出版システムや文書共有システムを作った事例の資料が最近たくさん出ている。
以下リンクしておく。

注目点は、いくつかある。

1)GitHubやBitbucketを執筆データのリポジトリにする。
2)執筆データはMarkdownのようなテキストファイルで保存
3)ReViewやSphinxなどのツールでPDF・EPUBに変換する
4)定期的にビルドしてDropboxなどに配布する

昔は手書きの原稿用紙に書いて、その後、推敲して修正して、組版に載せていた。
僕も小学校の頃、ガリ版で卒業文集を書いた経験がある。

でも、今は、Wordでもなく、テキストに書いて、即座にビルドして配布する仕組みが普通だろう。
スマフォへ定期的にビルド&配布すれば、通勤や待ち時間でも、著作物をレビューできる。
そのフィードバックを受けて、著作物をさらに洗練させていくことができる。

執筆環境ももっとアジャイルになるべき。

| | コメント (0)

2011/12/17

ユーザの力を利用するアジャイル開発

グーグルで必要なことはみんなソニーが教えてくれた」を読んで思ったことをメモ。

グーグルで必要なことはみんなソニーが教えてくれた」の著者は、元ソニーのエンジニアの方がソニーで四苦八苦したプロジェクト内容とグーグルへ転職した時の雰囲気について書いていた。

気になった文章は、「走りながらユーザーの力を利用して製品の完成度を継続的に上げていく」「ネットの群衆の英知を使って問題発見と問題修復をやっていく」の二つ。

前者は、製品をすぐに作ってはユーザへフィードバックして評価してもらい、その結果を製品に取り込んで機能改善していくこと。
後者は、すぐに作った製品の完成度があまり良くなくても、ほどほどの品質で早めにリリースして、ユーザにバグ報告とバグ検証をしてもらうような仕組みを作ること。

いずれの文章もAgile開発の発想にとても良く似ている。
ポイントは、「ユーザの力を利用して継続的に製品の完成度を上げる」「ユーザの力を利用して問題発見と問題修復を継続的にやっていく」ということ。
つまり、単なる継続的改善だけでなく、ユーザのフィードバックを吸い上げてその内容を製品へ反映していく仕組みも必要なことを示唆している。

Agile開発の発想がソフトウェア業界だけでなく、ソニーのような家電製品などの業界でも必要とされている。
その事実に正直驚いた。
しかし本を読む限り、その発想を著者が在籍していた時代のソニーは理解できていなかったらしい。
著者は「日本人の完璧主義が足を引っ張っている」と言っている。

アジャイル開発の発想をITエンジニア以外に他業界の技術者が理解して実践していく環境は、現在も揃っていないのではないかと思ったりする。

その中でも、「ユーザの力を利用する」仕組みがとても難しいのだろうと思う。
製品の購入ユーザには熱心な人も入れば、アンチなユーザもいる。
彼らの声を全て正しいと仮定して製品に全て取り込むには現実的に難しい。
また、彼らの声がたくさんあるほど、重要なメッセージを見落としやすい。
そして、ユーザの声を反映した製品を更にユーザに使ってもらえるように、届ける仕組みも大事。

最近流行しているFacebookやTwitterは、そういうユーザの声をリアルタイムに集めやすい。
だからFacebookファンページでユーザの声を収集してはユーザへフィードバックしていく手法で、マーケティングをやっている会社も多いのだろう。

チケット駆動開発でよく使われるRedmineやTracも、高機能化したBTSやITSを単なるバグや課題を収集するシステムではなく、一つのポータルなシステムへ拡張していると思う。
例えば、収集したデータを各種の観点でレポートしたり、問題修復した製品をアナウンスしたり、ユーザと議論するフォーラムがあったり、製品のTipsを公開するWikiがあったりする。
それらの機能があるおかげで、ユーザと製品の開発者がリアルタイムに議論して、より良い製品へ改善していく仕組みが整うはず。

アジャイルという発想は僕はとても自然だと思う。
でも、実際の組織に当てはめて運営していくには、まだまだ何かが足りない。

| | コメント (0) | トラックバック (0)

2011/11/03

日本のIT業界のホラー小説「人形つかい」

一部で有名だったシステム開発の読み物(全23話)を読んでみた。
あらすじはネタバレになるので書かないが、いくつか感想をメモしておく。

【元ネタ】
Press Enter■: 人形つかい(1) 未知との遭遇

日本のIT業界で働いた経験がある人なら、リアリティがありすぎて思わず引き込まれるだろう。
他の業界の人が読んだら、何故今の日本で奴隷のように働くのだろうと不審がるだろう。

感想を二つほど書く。
一つは、日本の製造業に特徴的な多重下請構造をIT業界が真似たことで、技術者が手配師になるか一匹狼の技術者になるかどちらかしか選択肢がない状況になっていること。
この件については過去にも色々考えた。

手配師になるか技術屋で生き残るか: プログラマの思索

個人的には、松原友夫さんの指摘「しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、成果責任を負わない派遣形態がかくも横行しているのは日本だけである。 」が最も本質を突いていると考える。

人月ビジネスの特質~成長しないこと: プログラマの思索

日本のソフトウエア産業、衰退の真因 | スラッシュドット・ジャパン

日本のソフトウエア産業、衰退の真因 - 真髄を語る:ITpro

もう一つは、SIが独自に作る俺様フレームワークに技術上だけでなくマネジメント上も致命的な欠陥があること。
この件も過去にも色々考えた。

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

SIerの俺様フレームワークは最悪だ

SIが俺様フレームワークを作りたがる理由は、昔のCobol開発のように、上流工程の設計さえできればプログラムは自動生成すればいい、という発想があるのだろうと思う。
その考え方は多分アジャイル開発とは相容れないと思う。

Continuous Delivery~TDDとCIの次に現れた自動化の概念: プログラマの思索

SIerは自動化する対象が違っているのでは? - Togetter

IT勉強会カレンダーを見る限り、日本のIT技術者は向上心があるし、RubyやSeasarなどを日本人が生み出したのだから、技術的に劣っているとは思えない。
オープンソース活動やコミュニティ活動が日本の変革の鍵を握っているように直感している。

| | コメント (0) | トラックバック (0)

2010/10/06

「Redmineによるタスクマネジメント実践技法」 詳細目次 #TiDD

翔泳社のHPから詳細な目次が公開されたようです。

【元ネタ】
[#TiDD] 出版裏話5:「Redmineによるタスクマネジメント実践技法」 詳細目次: ソフトウェアさかば

さかばさんが書いているように、実際はもう少し多めに書いたのですが、分量が多すぎると言うことでいくつかの章は削除になりました。
でも、その裏話もどこかのコミュニティで少しずつ講演していこうかと思ってます。

さっそく著者には本が届きました。
表紙の艶もよく、白と赤のコンストラストがとても綺麗で、まるで光沢のある曲線的なデザインのiPhoneみたいでした(笑)

RedmineやTracなどのBTSのツールのインストール方法については、既にたくさんの良書が出版されています。
しかし、それらのツールの背後に隠れているチケット駆動開発というプロセスの説明、そしてチケット駆動開発の背後に更に隠れているAgile開発を見出して詳しく説明した本は他にはないと思っています。

Agile開発の運用につまずいている人、ソフトウェア開発のプロジェクト管理に悩んでいる人は是非読んでみて下さい。

Redmineによるタスクマネジメント実践技法 -株式会社翔泳社:SEShop.com

はじめに
   まえがき -平鍋健児-
   まえがき -倉貫義人-
プロローグ -開発現場で試行錯誤した経験談-
   Redmine導入前の問題点
   Tracは使いこなせなかった
   Tracによるチケット駆動開発
   Redmineによるチケット駆動開発で運用を工夫した点
   Redmine導入後
   Redmineによるチケット駆動開発でさらに気付いたこと
   Redmineによるチケット駆動開発の可能性
   まとめ

第1部  チケット駆動開発技法 -BTSによる作業管理-

第1章 障害管理ツール(BTS)
   1. 1 節 ソフトウェア開発の難しさ
   1. 2 節 BTSの歴史
   1. 3 節 オープンソースBTSが選ばれる理由
   1. 4 節 障害管理の目的
   1. 5 節 障害管理からチケット管理
第2章 BTSとツールの連携
   2. 1 節 構成管理ツール
   2. 2 節 構成管理ツールの歴史
   2. 3 節 ブランチとメインラインモデル
   2. 4 節 他の支援ツール
第3章 チケット駆動開発 -チケットによるタスク管理-
   3. 1 節 チケット駆動開発が生まれた背景
   3. 2 節 チケット駆動開発の誕生と発展
   3. 3 節 チケット駆動開発とは
   3. 4 節 TiDDのチケット
   3. 5 節 BTSのチケットの特性
   3. 6 節 チケット駆動開発とソフトウェア工学
   3. 7 節 Redmineの構造とWBS
   3. 8 節 チケットの候補
   3. 9 節 コミュニケーションと見える化
   3.10節 日々のプロセス
   3.11節 マネジメントとトレーサビリティ
   3.12節 見えるものは制御できる
第4章 チケット駆動開発(TiDD)のはじめかた
   4. 1 節 チケット駆動開発の運用方式
   4. 2 節 チケット駆動開発の権限ポリシー
   4. 3 節 [事例]下流工程でのチケット駆動開発
   4. 4 節 [事例]XPのプロセス改善
   4. 5 節 TiDDはプロジェクトのアジリティを高める

第2部  Redmineによるタスク管理

第5章 Redmineの運用方法
   5. 1 節 Redmineの特徴
   5. 2 節 Redmineのインストール
   5. 3 節 チケット駆動開発の運用サイクル
   5. 4 節 Redmineチケットの概念モデル
   5. 5 節 Redmineチケットの状態遷移
   5. 6 節 Redmine運用フロー
   5. 7 節 有用なRedmineのプラグイン
   5. 8 節 バージョン0.9の新機能
   5. 9 節 【速報】最新バージョン1.0.1
第6章 Redmineの高度な使い方
   6. 1 節 チケット
   6. 2 節 バージョン
   6. 3 節 プロジェクト
   6. 4 節 ワークフロー
   6. 5 節 レポート出力
第7章 チケット駆動開発の実践的な運用方法
   7. 1 節 アジャイル開発と組み合わせて運用する方法
   7. 2 節 並行開発と組み合わせて運用する方法
   7. 3 節 チケット駆動開発のプラクティス
第8章 チケット駆動開発を発展させるアイデア
   8. 1 節 PMBOKのEVM
   8. 2 節 測定できれば制御できる
   8. 3 節 Redmineと外部ツールを連携
   8. 4 節 ITILと組み合わせて運用する方法
   8. 5 節 大規模プロジェクトで運用する時の注意点

第3部  RedmineとTestLinkの連携

第9章 TestLinkの運用方法
   9. 1 節 TestLinkの概要
   9. 2 節 TestLink運用前のテスト工程における問題点
   9. 3 節 TestLinkの概要モデルと運用サイクル
   9. 4 節 TestLinkの運用例
   9. 5 節 TestLinkの運用後
   9. 6 節 TestLink運用のまとめ
   9. 7 節 TestLinkのプラクティス

エピローグ -チケット駆動開発の魅力-
参考文献
参考資料
索引

| | コメント (0) | トラックバック (0)

2010/10/05

「Redmineによるタスクマネジメント実践技法」を平鍋さんに紹介して頂きました

Redmineによるタスクマネジメント実践技法」を平鍋さんに紹介して頂きました。
ありがとうございます。

【元ネタ1】
チケット管理システムをつかってみよう!:An Agile Way:ITmedia オルタナティブ・ブログ

平鍋さんには推薦文も書いて頂いたのですが、下記の文章が一番惹かれます。

(中略)
私は2000年から10年以上、アジャイル開発やプロジェクトファシリテーションを提唱しながら、チームのパワーをどうやって引き出すか、ということに焦点をあてて活動してきました。
プロジェクトを生産的に、協調的にするには、人の力とモチベーション、コミュニケーションを引き出すことが一番重要である、ということを2000年代にアジャイル開発が発見しました。その「人の力を活かす」という原則の裏には、実は、徹底的に「マシンの力を使う」という原則が隠されています。
(後略)

Agile開発には、開発者が生き生きと開発できる環境づくりという目的から、人間同士のコミュニケーション重視とマシンによる徹底的な自動化と言う相反する二つの観点が混じっていることに改めて気付かされました。

又、いつもお世話になっているRedmine.JP さんにも紹介して頂いてます。

書籍「Redmineによるタスクマネジメント実践技法」10月13日発売 | Redmine.JP Blog

又、倉貫さんからもTwitterで推薦してくれてます。

Twitter / Yoshihito Kuranuki: No Ticket! No commit! ソフトウェア開発はもっと近代化できる。オススメです。 RT @hiranabe: プロジェクト ファシリテーションにもオススメの一冊。「Redmineによるタスクマネジメント実践技法」

ソフトウェア開発をもっとIT化するための道具の一つとして、チケット駆動開発のアイデアが普及するといいなと思います。

| | コメント (0) | トラックバック (0)