Ruby

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)

2016/12/17

WindowsのRubyのバージョン管理はuruを使う

WindowsのRubyのバージョン管理はuruを使うと良い、という記事を見つけたのでメモ。

【参考】
Windows7でRubyのバージョン管理!pikの代わりにuruを使う。 - 思い付くまでタイトル未定

pikの替わりにuru~windowsで複数バージョンのrubyを切り替える~ - Qiita

jonforums / uru / wiki / Downloads ? Bitbucket

複数のRuby環境構築はrvmかpik: プログラマの思索

もうpikは使えなくなった。
代わりにuruをインストールする。

uru_rt.exeを、C:\toolsに配置
環境変数PATHにC:\toolsを追加

cd C:\tools
uru_rt admin install

uru_rt admin add C:\Ruby-2.2\bin

uru_rt ls
220p0 : ruby 2.2.0p0 (2014-12-25 revision 49005) [x64-mswin64_100]

uruはRubyのバージョンだけでなく、Gemも切り替えてくれるので便利。

| | コメント (0)

2016/01/12

Rails製次世代型CRMのFat Free CRM

Rails製次世代型CRMと記載されていた「Fat Free CRM」のリンクをメモ。

【参考】
Rails製、次世代型CRM・Fat Free CRM MOONGIFT

fatfreecrm/fat_free_crm ・ GitHub

Rails Hub情報局: いま読みたいRuby on Rails3アプリ 10選

Fat Free CRM - Ruby On Rails-based open source CRM platform

日本Cloud Foundryグループ ブログ: Fat Free CRM を Cloud Foundry で動かす

どんな中小企業でも、個人事業主でも、営業していたら、見込客や既存顧客の状態を管理したくなってくる。
そこで、CRMに見込み客や既存顧客を登録しておき、営業で見つけた情報や引合の情報を登録して、後で精査したい。

フリーのCRMと言えば、SugarCRMやvTigerCRMが有名だろう。
でも、Railsアプリと言えば、RedmineやGitlabが有名だろうが、Rails製CRMがないか、探していた。
そんな時に見つけたのが、Fat Free CRM。

(引用開始)
今回紹介するオープンソース・ソフトウェアはFat Free CRM、次世代型のCRMを標榜するソフトウェアだ。

Fat Free CRMはRuby on Railsで作られたソフトウェアで、SQLite3やMySQLで利用できる。ごく手軽に導入できるのが利点だ。インタフェースは非常に見やすい。ラベルが色分けされているだけで随分見やすさが変わってくることが実感してもらえるはずだ。

主な機能はタスク、キャンペーン、顧客情報、案件のステータスなどを一元的に管理できる。顧客に対してタスクを紐づけることで、どの顧客が工数が多くなっているのか等も分かる。検索は各アクションに沿ってフィルタリングが可能で、細かく検索できるようになっている。
(中略)
一般的なCRMというと入力項目がとても多く、面倒な感じがしていたがFat Free CRMについてはすっきりとしたインタフェースも手伝ってそんな印象はない。また、スケジュール管理とかぶる機能が多いのも一般的なCRMでは多かったが、Fat Free CRMではタスクくらいだ。次世代型にふさわしい、進化したCRMと言えそうだ。
(引用終了)

パッケージ製品のCRMは、どうしてもUIが使いにくいし、見栄えも良くない。
一方、Rails製のCRMの方がUIも先進的だし、最新の技術も反映しやすいはず。
Fat Free CRMの画面キャプチャや概要を読むと、使いやすそうに見える。

DBに顧客情報や問合せ情報が登録されていれば、そのDBを直接参照することで、他システムとも連携しやすくなるはず。
個人的には、CRMにおけるサポートデスクの問合せ管理はRedmineの方が使いやすいと思うので、Fat Free CRMとRedmineが相互連携できるといいなあと思ったりする。
色々調査してみたい。

| | コメント (0)

2015/07/18

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか

Redmineを導入したいという話を受けて、Redmineを導入した時、後で気づくのは、ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか、という問題。
ラフなメモ書き。
結論はなし。

【参考】
akipiiさんはTwitterを使っています: "改めて読むとなるほどを思う。「ツールは高速道路だが、その上を時速何キロで走れるのかはチームの成熟度に依存しているのだ。」書評 アジャイルソフトウェアエンジニアリング http://t.co/mwzki9EZGi @ryuzeeさんから"

OjaさんはTwitterを使っています: "管理者受けし易い代わりに、うまく使えるかどうかも管理者次第なので、管理者の実力と評価がそのままRedmineの評価になるんじゃないかという仮説 RT @t_yoshi_tomi 何故、 Redmineを気に入る人と Redmineを毛嫌いする人がいるのだろうか・・・"

よしむさんはTwitterを使っています: "@kawanishi_ameya プロジェクトによって運用具合もバラつきがありますし、管理者次第というところが影響してくるんですね・・・(泣)"

akipiiさんはTwitterを使っています: "同感。RT @n_enot: チームでのソフトウェア開発って本当に難しくて、だからみんなPullRequest駆動やチケット駆動、あるいはもっと単純に相談&告知、最悪な例だと申請&ハンコ承認といった、とにかく協調して作業する方法が探られているわけです。"

みずのり(みずののりゆき)さんはTwitterを使っています: "個人的に。 プロセスとツールの両方を同時に変えるのは難しいので、まずはEXCELな従来ツールで展開ツール活用時に近いプロセスを実装。 そこから”ツールの方が便利ですよ”とやってみると導入しやすい感。 前者のプロセス変更に対応出来ないチームにはツール導入しても使われないっす。"

みずのり(みずののりゆき)さんはTwitterを使っています: "最近やったのはプロセス導入の段階で、かなり苦労して試行錯誤して枠組み作ったけど、そのプロセスの安定した形態はすぐにツールに置き換え可能なものでしたとさ。 チケット駆動の考え方をプロセスにしたので、redmine置き換えがすぐに出来るのは当たり前なのですが^^;"

僕個人の経験では、Redmineというツールを導入した後に、こういうふうにプロセスを回すのだな、と気づきながら運用していた。
だから、ツールを使いながら、あるべきプロセスを導き出したように思う。

でも、実際はそうではなかったかもしれない。
ツールの導入前は、アジャイル開発を実践した経験はほとんど無かったけれど、アジャイル開発の知識は持っていたし、こういうふうに運用したい、という思いはあった。

WF型開発できちんと変更管理するやり方も、色んなSIを渡り歩きながら、学んでいた。
SIer特製の障害管理Webシステムへの障害票の書き方、コミットする時には障害管理番号を記載すること、CVSのコミットログに変更理由を記入すること、などの運用ルールはある程度分かっていた。
だから、Redmineを障害管理からタスク管理へ発展させて使う方法はマッチできた。

実際は、プロセスが確立されたイメージを持ってツールを導入していたのだろう。

ツールは高速道路であり、上手く使えば、ゴールまで速く到達することはできる。
でも、高速道路の走り方も多少はあるし、車のエンジン(=チームの能力)が性能を出し切れなければ、国道を走っている時と変わらないかもしれない。

色々考えてみる。

| | コメント (0)

2015/05/10

IntelliJでRailsソースをリモートデバッグ

IntelliJでRailsソースをリモートデバッグする記事を見つけたのでメモ。

IntelliJ IDEA 13.1 + Ruby plugin 6.5.0.20140314 DE リモートインタプリタ Rails開発 - Qiita

EclipseやVisualStudioでも、JavaやC#の環境でデバッグ時に、ローカルサーバー上のWebサービスのソースをデバッグできる設定がある。
RubyのIDEでは、IntelliJ+RubyプラグインまたはRubymineが優れていると聞いているが、同様にできるみたい。
Rubyのようなインタープリタ言語でリモートデバッグできるとはすごいな、と思ったりする。


| | コメント (0)

2014/01/04

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代

2014年になって、ITの地殻変動がどこに起こっているのか、を考えてみる。
#ラフなメモ書き。

【1】最近感じることは、Webアプリをプログラミングするアプリケーションエンジニアよりも、サーバー基盤を構築するインフラエンジニアの方が目立つというか輝いて見える時が多い。
何故なのだろう?

また、先月の日経BP主催のITアーキテクト カンファレンスでは、エンタープライズシステムの構築に携わるITアーキテクトを対象にしているが、その内容はすべて、クラウドがキーワードだった。
DOAやOOAは全く含まれていない点が衝撃だった。

ITアーキテクト カンファレンス 2013

最近の流れを見ると、アーキテクチャ設計の技術では、DOAやOOAは既に古い技術であり、クラウドが席巻しているように見える。

【2】最近のバズワードである「クラウド」には、否定的な意見を持つ人も多い。
ITの歴史の延長線上にあるだけで、そんなにすごい価値があるわけではないだろう、と。
単に仮想化なんでしょ、と。

クラウドサービスも、大昔のデータ計算センターや電算受託から始まったシステムサービス提供形態の現時点での変化形に過ぎない、と。

実際、ERPやメールサーバなどをクラウドへ構築する場合でも、フィットギャップ分析、セキュリティレベル、運営のコンセプト確認、負うべきリスクの整理、サービスレベル(SLA)の定義、など、従来の手法で検討する必要がある点は変わらない。
システム、ネットワークなどの利用面の進展があっても、利用に当たっての検討項目は本質的には同じである。

【3】しかし、クラウドが新しい観点をもたらし、アーキテクチャ設計に大きな影響を与えた点は2つあると思う。

【3-1】一つは、インフラ構築もアジャイルにプログラミングで開発できること。
その意味については、下記の記事で色々考察した。

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例: プログラマの思索

「Infrastructure as Code」というキーワードがまさにそうであるように、サーバー構築手順は全てプログラム化できる。
従来は、サーバー購入や構築手順をあらかじめ計画段階で入念に実施し、レビューしてから作るというウォーターフォール型開発っぽいやり方しかなかったけれど、クラウドのおかげでサーバー構築もアジャイルに開発できる。

アジャイルに開発できる利点の一つは、失敗を何度も許容できる点があるだろう。
特に、サーバーの障害テストや負荷テストを何度もやり直せる利点はとても大きい。
従来なら、サーバーの負荷テストや障害テストは、準備も実行もすごく手間がかかりすぎて、何度もやり直すべき作業ではなかった。
アジャイルに障害テストや負荷テストを実施できることで、最初の計画を完璧にしなくても、プロトタイプのようにサーバーを構築して実現可能性(フィージビリティ)を調査したり、運用に合わせてハードウェア構成を柔軟に変える、などのオプションを持つことができる。

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

また、クラウド化することで新たに判明する点は、ソフトウェアの品質がそのままコストに跳ね返ってくる点だろう。
例えば、CPU使用量やメモリ使用量を10%削減できれば、請求代金を10%削減できるのだ。

クラウドではソフトウェアの品質が課金の差として出てくる: プログラマの思索

つまり、クラウドでは下記の公式が成り立つ。

ソフトウェアの品質の差=パフォーマンスの差=課金の差=コストの差=利益率の差

従来は、一度、サーバーを構築したら、そのハードウェア構成を変えるのは、次のハードウェアリプレースまでできなかったが、クラウドなら、柔軟にハードウェア構成を変えることができる。
したがって、クラウドによって、ソフトウェアの品質特性として、特に効率性(パフォーマンス)がより重要になってきた側面があるだろう。

他にも、クラウドによって、システムの移植性が高まる、信頼性の観点は壊れないシステムよりもすぐに直せるシステムの方が重要、など、品質特性の観点が変わってきた。
今後は、クラウドとエンタープライズのシステムの組合せでは、機能性や信頼性よりも、保守性・移植性・効率性の品質の方が重視されてくるだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

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

なお、クラウドで使われるツールで注意すべき点は、Chefなど、Rubyで書かれたプログラムが多いこと。
クラウド時代のサーバー構築では、Rubyという技術が必須になってきているように思える。

【3-2】もう一つは、DOAやOOAやサーバー構築の設計では、その時代の技術の制約があったために、バッドノウハウになっていた箇所に対し、クラウドを使うことで本来の目的がクローズアップされたこと。

クラウドを使ったサーバー構築の設計では、クラウドデザインパターンがまとめられているので、参考にすべきだろうと思う。

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

クラウドアーキテクティング原則 - AWS-CloudDesignPatternに掲げられた下記の原則は、クラウドの使い方について的確に示していると思う。

◆できるだけサービスを利用
◆机上実験よりも実証実験
◆スモールスタートからスケールアウト
◆変化に対し全レイヤで対処
◆故障のための設計(Design For Failure)
◆最初だけでなく周期的なカイゼン

また、DOAでは、サマリ系テーブルは夜間の日次バッチ処理(特にCobol)で作る、とか、正規化しているために参照関係の複雑なテーブルを結合して参照するしかない、などの弱点が従来はあった。
でも、クラウドが出てきて変わった点は、MapReduceのような並列処理と相性が良いので、大量データを短時間で処理できる設計も可能になったこと。

更には、RDBを使うとパフォーマンスが出ない場面では、クラウドと相性の良いNoSQLを組み合わせて、KVSやドキュメント指向DB、列指向DBなどを使うことで、問題解決できる場面があること。
よく聞く場面は、SNSやソーシャルゲームのログイン時にユーザ情報を参照する処理のように、単純な参照処理だが大量のアクセスが発生する状況で使われる。

データベース技術の今後の動向: プログラマの思索

最近「ビッグデータ」というバズワードが頻出される理由は、クラウドが並列処理と相性が良く、大量データを短時間に処理できるために、大量データから意味ある論理を導くデータマイニングが注目されているからだろうと思う。
従来のDOAでは、データウェアハウスのような設計思想もあったけれど、パフォーマンスが悪くて、なかなか手軽に使えなかった状況があったからだ。

現場の業務システムは、運用後にかなりのトランザクションをためているものの、それらのデータを解析(データマイニング)して、そこから得られた知恵を再利用する手法はほとんど取られていない。
よくある例は、購買履歴から顧客の購買動向を分析するCRMが欲しいという要望が多かったが、その仕組みが従来はなかなか作りにくかった、という弱点があったと思う。
Amazonのおすすめ商品のような協調フィルタリングを実装するのは敷居が高い。

他にも、従来のDOAでは、製造業向け生産管理システムのMRP(部品の所要量計算)、会計システムの自動仕訳とPL・BSレポート出力も、普通は日次バッチ処理で1日1回(または月次バッチで月末1回、年次バッチで1年に1回)作られるだけだった。
従来のDOAを支えるRDBMSの制約、バッチ処理プログラムの性能が出ないなどの制約などの理由で、夜間バッチ処理でしか対応できなかったのだ。

「オンプレミス・システムの終わり」の始まり~AWSでのミッションクリティカルシステムの稼働 - 急がば回れ、選ぶなら近道

基幹系バッチ処理をHadoopで高速化: プログラマの思索

Hadoopの本質は分散I/Oにあり~クラウド時代の非同期処理: プログラマの思索

クラウドのもう一つの本質~ソフトウェアの可搬性を確保する: プログラマの思索

でも、クラウドとデータマイニング・データ集計の並列処理を組合せることで、CRMのデータを手軽に作り出せる。
MRPによる原価計算や、自動仕訳後のPL・BS出力も1日数回以上実施できるようになる。
そうすれば、原価計算や会計処理、CRMなどの経営分析も、アジャイル開発っぽく、何度も試行錯誤しながら仮説検証していくスタイルを実施しやすくなる利点がある。

最近、リーンスタートアップという経営手法が注目されている。
その理由は、経営手法でもアジャイル開発のやり方を実践して効果が出せるからだと思うが、その背景には、クラウドを使って、少人数でWebサービスをリリースすればすぐにビジネスを開始でき、スケールアップも容易である特徴を生かしているからだと思う。

クラウドという単なる一つの技術が、従来のDOAやOOAでは解決しにくかった問題に対して有効である場面が増えてきている。
それら効果についても今後、追いかけてみる。

【追記】
クラウドとセットで語られるNoSQLについては、7つのデータベース 7つの世界の本が個人的にはお勧め。
7種類のDB(PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4J、Redis)の特徴について、広く深く記載している。サンプルソースもあるので、とっつきやすい。

| | コメント (0)

2013/07/02

メールからRedmineのチケットを自動登録する時の注意点

メールからRedmineのチケットを自動登録する時の注意点をメモ書き。

【1】第8回RxTStudy勉強会で、@g_maedaさんは、顧客からの問合せメールをRedmineのチケットに自動登録する機能によって、ヘルプデスク管理をチケット管理に置き換える事例を紹介している。

第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

メール対応に付随する苦労の多いヘルプデスク管理をRedmineのチケット管理に置き換えたことによって、チケット管理の恩恵が得られる利点を強調されていた。
その反面、下記の課題がまだ残っていると話されていた。

(1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。
(2)メールソフトとRedmineを行ったり来たりして面倒。
 メール対応という一つの目的で2つのツールを使っている。
(3)古いメールに新たな問合せを返信メールで送る顧客もいる。
 古いチケットNoがSubjectに入っている場合が多い。
(4)サポート担当者からメールを発信する場合、SubjectにチケットNoがないので、チケットが登録されない。
 顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを、一つのチケットでまとめたい場合がある。
(5)ステータス変更し忘れる。
 忘れた頃に、終了チケットへ返信メールが追加されるが誰も気づかない。
(6)発信元アドレスがチケットに記録されない。
 メールによるRedmineチケット登録機能では、匿名ユーザとしてチケット登録されるため、メール送信者(顧客)の情報がチケットに残らない。

上記の課題のうち、手運用でカバーせざるをえないのは、(1)(3)(5)だろう。
(2)は、Redmine画面上で返信メールを送信できる機能をプラグインで作るべきかもしれない。

そのうち、(4)と(6)の解決策について、考えてみた。

【2】サポートデスクからの送信メールと顧客からの受信メールで、同一のチケット番号を振るようにするプラグインを@yusuke_kokuboさんが公開されている。

Redmine Mail Intergration plugin - こくぼ@Everything is the experience.

(引用開始)
◆背景
Redmineにはチケットが更新されたときなどにメールで通知してくれる機能があります。さらにその通知メールに返信することで注記を書けたりします。
さらには、Redmineのメールアドレスを宛先に含めておくだけでRedmineがメールを受信してチケットにできる機能もあります。
いろいろ便利な機能がそろっているのですが、うちの会社の使い方ではちょっと痒いところに手が届きません。

◆なにに困ってるの
マネージャ「お客さんからこんなこと頼まれたんだけど、Aさんこの作業お願い!」
とお客さんからの依頼をAさんのメールアドレス宛にRedmineのメールアドレスをCCに入れて転送しました。*1
Redmineはメールを受信してチケットに起こして通知メールを投げます(投げったっけ?)。

◆Aさんが受け取ったメール
この時点でAさんはマネージャからのメールとRedmineからの通知メールを受け取っています。
AさんがRedmineからの通知メールに返信すればRedmineは注記として処理できます。しかし元々のマネージャからのメールに返信すると、Redmineは返信元のチケットを特定できないので、新たにチケットを作成してしまうのです。注記にできないどころか無駄なチケットが作られてしまいます。困りました。

◆そこで作ったプラグイン
Redmineがメール受信したときにメールのMessageIDと処理したチケットNoを覚えておくプラグインを作りました。
この場合でいうと、最初にマネージャが投げたメールを処理したときにMessageIDとチケットNoをDBに保存します。
そしてAさんからの返信を受信したときに、メールのin-reply-toからMessageIDを検索して処理元のチケットを特定します。

◆まとめ
これでRedmineを意識できない人でもとりあえず宛先にRedmineのメールアドレスを含めておいてもらえば、チケットに履歴が残っていってハッピーになれるかもしれません。
(引用終了)

つまり、(4)顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを一つのチケット番号でまとめる機能は、上記のプラグインで実現されている。

但し、MessageIDとチケットNo、ユーザ名を保持する新規テーブルが1個増えるので注意。
また、GitHubのemail.rakeを見ると最新版よりも古いので、パッチを当てるなどの動作検証が必要と思う。
だから、すぐに上記のプラグインですぐに解決できるとは限らないのが残念だ。

YusukeKokubo/redmine_mail_intergration

redmine_mail_intergration/lib/tasks/email.rake at master ・ YusukeKokubo/redmine_mail_intergration

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

上記のプラグインの機能をRedmine本家に取り込んでもらえないのだろうか?

【3】(6)発信元アドレスがチケットに記録されない課題については、RedmineはCRMソフトとして使えるか?: プログラマの思索にも書いたけれども、顧客問合せメールからRedmineチケット登録時に、顧客を新規ユーザとして登録する機能を使う方法もある。

メールからチケット登録する場合のRedmineのオプションはRedmine本家のWikiに書かれている。

RedmineReceivingEmails - Redmine

Redmineのソースemail.rakeを読むと、下記のオプションがある。

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

(引用開始)
General options:
unknown_user=ACTION how to handle emails from an unknown user
ACTION can be one of the following values:
ignore: email is ignored (default)
accept: accept as anonymous user
create: create a user account
no_permission_check=1 disable permission checking when receiving
the email
no_account_notice=1 disable new user account notification
default_group=foo,bar adds created user to foo and bar groups
(引用終了)

つまり、「unknown_user=create」オプションを追加すれば、Redmineのユーザーが作成されるのでメールアドレスを保持できる。
さらに、「default_group」オプションを追加すれば、作成されたRedmineユーザのユーザグループまで設定が可能だ。

従って、あらかじめ顧客ユーザだけを含むユーザグループ「顧客」を作っておき、顧客問合せメールからRedmineチケット登録時に、顧客をRedmineユーザとして新規登録するだけでなく、新規Redmineユーザとして「顧客」ユーザグループに属するようにオプションを使えばいい。

つまり、Redmineのユーザグループ=取引先企業、ユーザ=企業の担当者としてマッピングすれば、「企業◇--担当者」の関係を実現することができる。

例えば、外部サーバーからメールサーバーへIMAPで問合せメールを検知する場合、下記のようなrakeコマンドになるだろう。

#supportプロジェクトにbugトラッカーでチケット登録し、ユーザは顧客のメールアドレスで新規登録する。
#さらに、新規ユーザは、fooユーザグループに属する。

rake redmine:email:receive_imap RAILS_ENV="production" \\
host=imap.foo.bar username=redmine@somenet.foo password=xxx ssl=1 \\
project=support \\
tracker=bug \\
unknown_user=create \\
no_permission_check=1 \\
default_group=foo \\
allow_override=tracker,priority

但し、TO・Ccアドレス、Subjectの情報はチケットに登録してくれない問題はまだ残る。
Redmine本家に対する今後の改善要望となるだろう。

【3】「メールからRedmineのチケットを自動登録する」機能に注目する理由は、メール駆動の業務をチケット管理へ置換できる可能性を感じるからだ。
普通の社会人ならば、毎日数十~数百通のメールを受け取って、その返信に追われていないだろうか?
実際の仕事は、顧客からの問い合わせメールやシステムの障害検知メールなどが起点となって始まる場合が多い。
すると、メールの履歴を追いかけながら仕事せざるを得ず、メールという古い機能に縛られた流れでしか仕事できない。

メール駆動の仕事の弱点は下記に書いた。
メール駆動はExcel駆動と同様に、何らかの解決策が必要ではないだろうか?

メール駆動開発は時代遅れではないか: プログラマの思索

管理のためのExcelをチケット管理が駆逐しているように、外部とのやり取りはメールというインターフェイスで行っていたとしても、社内ではチケット管理で回せる仕組みが作れないか?
今後も考えてみる。

【追記】@sakaba37さんが、(1)(3)(5)の問題点に対し、返信メールを受け取る時に「ステータス=New(新規)」でチケット更新すればよいのではないか、と提案されている。
新規ステータスならば、問合せタスクが終了していないので、必ず対応状況のチェックで引っかかるから、現実的な解決策になると思う。
rakeコマンドにstatus=newをセットすればいいので実装は問題ない。

但し、rakeコマンドではデータをロードできないため、結局はシェルスクリプトでメールのヘッダ情報を取得する処理を作りこむしか無い。
From・To・Ccアドレスをrakeコマンドだけでチケットに表示できない課題はまだ残る。

[#Redmine] Redmineによるメール対応管理 - 第8回 #RxTstudy -: ソフトウェアさかば

(引用開始)
さて、前田さんの発表で課題とされていたものに、チケット番号が間違っているものや、クローズしたものの場合がありましたが、これは、関連チケットのステータスをnewか適当なものにすれば良いと思います。
ステータスを変える方法には色々あると思いますが、メールハンドラーを修正しなくてもメールの最後に「Status: New」という行を追加するフィルタのスクリプトを、メールハンドラの前にかませれば良いと思います。
こうすると、クローズされていないメールを管理するだけで、番号違いなども拾う事ができるでしょう。
(引用終了)

svn.redmine.org/redmine/trunk/lib/tasks/email.rakeを読むと、statusのオプションがあるので、実現可能だ。

(引用開始)
Issue attributes control options:
project=PROJECT identifier of the target project
status=STATUS name of the target status
tracker=TRACKER name of the target tracker
category=CATEGORY name of the target category
priority=PRIORITY name of the target priority
allow_override=ATTRS allow email content to override attributes
specified by previous options
ATTRS is a comma separated list of attributes
(引用終了)

【追記2】
@sakaba37さんが上記の課題に対して、幾つかの方法を試されている。

[#Redmine] Redmineによるメール対応管理(その2) - 検証編 -: ソフトウェアさかば

| | コメント (0)

2013/06/30

第5回品川Redmine勉強会の感想 #47redmine

第5回品川Redmine勉強会にスタッフとして参加してきました。
盛り上がって楽しかったです。
資料をリンクしておきます。
感想をラフなメモ書き。

【参考】
第5回勉強会 - shinagawa.redmine

第5回品川Redmie勉強会 2013/6/29 - Togetter

【1】@sakaba37さんの資料。
共通結合、データ結合などのソフトウェア結合度の観点と業務フローの類似性のお話と、社内業務にRedmineを適用した事例のお話。
構造化設計のお話は、今では情報処理試験に出るくらいしか使わないから、ピンと来る開発者はいたのかな?
社内業務で、PC資産のタスク管理にRedmineを使った事例は興味深かった。
ある業務でタスクが発生して、そのタスクを管理したい時、チケット管理は有効であるように思う。

【2】その後、「マネージャ」「開発者」「運用担当者」「Redmineシステム管理者」の観点でワークショップ形式で議論した。

いろんな議論が出てきた。
皆同じような問題を持っているのね、と共感している人も多かった。

僕が興味を引いたのは、顧客との打合せ管理にRedmineを使っている人の話。
顧客との打合せや会議の準備で、タスク管理と工数管理をチケット管理で実施している。
トラッカー=顧客単位でチケットを発行し、全て打合せや会議の工数を記録し、月末に工数集計して顧客報告して請求するという流れ。
実績工数の作業分類にも、打合せの作業の種類に分けて、実績工数に色付けして入力・集計しているらしい。

この事例は、RedmineをCRMソフトとして使おうという発想であり、更に工数集計ツールとしても使おうとしている。
このアイデアは、第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索にも書いたけれど、顧客問合せ(つまり、コールセンターやサポートデスクの管理)の管理機能にも関連する。
この辺りのアイデアはあとでまとめる。

他には、@naitohさんのRedmineシステム管理者としてのノウハウや事例が面白かった。
RedmineのVerUp作業は結構面倒だ。
Redmineを導入すると、開発チームはRedmineなしでは作業できなくなるので、気軽に改造したりVerUpして正常動作しなくなるのが怖いので、VerUpするのが難しくなる。

@naitohさんの話では、Ver1.4からBundlerでRubyGemをインストールするようになったおかげで、インストールしたRedmineの単位でRubyGemを管理できるようになった。
だから、Ver1.4以降では、異なるバージョンのRedmineを併存するのも問題ないとのこと。
特にVerUpするための検証作業で、既存の古いバージョンのRedmineと、検証中の最新バージョンのRedmineを一つのサーバーに入れている時は、Ver1.4以降なら問題ないみたい。

但し、プラグインはRedmineのVerUpで動作しなくなるので要注意とのこと。
Redmineは2.1になるまでに、Rails2→3、Ruby1.8→1.9、Prototype→JQueryへアーキテクチャが変わったために、追いつけていないプラグインが多い。

第8回RxTStudy勉強会で@marutosijpさんが言っていたように、プラグインと言えどもテスト自動化して日々ビルドする環境がなければ、ミドルウェアやライブラリのバージョンアップ作業に追いつけずに破綻してしまう危険があるのだろう。
改めて、TDDとCIの強みを印象づけられた。

また、Redmineのバックアップはやってますか?という質問もあった。
@naitohさんは、SQLiteなのでファイルコピーでやってます、とのこと。
@akiko_pusuさんからは、MySQLならDMP出力、Redmineの添付ファイルはrsyncでお手軽にやっています、というお話もあった。
DBのDMP出力、ファイルの同期作業は、Cronで日次に夜間に実施するなどすればよいだろうと思う。

【3】@tkusukawaさんのテーマ説明やLTでは、ヘッダに電子公告のように流れるメッセージが面白かった。

Twitter / hiyoshism: 勉強会の真っ最中に上司から「Redmineの導入は見送ります」というメールが届いた俺が来たよ。 #47redmine

【4】日経システムズの記者さんのLTでは、記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITproの記事の裏話を少しだけ聞くことができた。
読者アンケートを取った結果では、Redmineの読者評価が高いらしい。

Twitter / akiko_pusu: Redmineの特集は何回もやってます。なぜか読者評価が高いです。アンケートでは普及率22% #47redmine

日経システムズという雑誌は、IT業界でしか読まれないだろうし、日経の雑誌を購入する層を考えると、SIの中堅~大企業の30代以降のSEやPM層が多いだろうと思う。
20代の開発者はそもそも購入する人はかなり少ないのではないだろうか?
また、日本のSIではアジャイル開発を採用している会社はほとんどないだろうし、おそらくウォーターフォール型開発が主流の会社で、Redmineを使っている現場が多いのだろう。

そういう読者セグメントを考えると、Redmineは日本のSIの開発現場で好まれやすいツールなのではないか、という仮説が思いつく。
ウォーターフォール型開発が主流の中では、XPやScrumを実践できないけれども、それでも軽量かつ規律ある開発をやりたい現場にチケット駆動開発がマッチしているのではないか、と想像する。
その議論については、以前、本来のチケット駆動開発(TiDD)とは何なのか? - Togetterでまとめた。

Twitter / quicy: あえて残念な言い方をすれば、チケット駆動開発は、XP/Scrumを実践できない現場、それでも規律的なライトウェイト開発をやりたい、という現場開発者のための、救済なんちゃってアジャイル手法だと思う。

Twitter / quicy: 自分がBugzillaでチケット駆動開発と呼ばれる以前のものをやっていた時には、チーム外からは「ツール使ってるのね」という認識だけで、そこにある軽量さと規律の両立の妙を、なかなか理解してもらうことができなかった。名前と体系化は重要ですね。

この辺りのアイデアも色々まとめてみたい。

| | コメント (0)

2013/06/12

Rubyのガントチャート生成ツールTaskJuggler

フリーのマインドマップFreeMindをいじくっていたら、エクスポート機能にTaskJugglerという項目があった。
TaskJugglerはRubyのコマンドラインによるガントチャート生成ツールらしい。
以下メモ書き。

【元ネタ】
taskjuggler/TaskJuggler · GitHub

TaskJuggler 3 超入門 - 目次とTaskJugglerのインストール:プロジェクト管理 -- フリーソフトでやってみよう:So-netブログ

TaskJuggler - A Free and Open Source Project Management Software - About TaskJuggler

TaskJuggler 3.4.0 on Windows/on MacOS X:プロジェクト管理 -- フリーソフトでやってみよう:So-netブログ

TaskJuggler|オープンソース・ソフトウェア、ITニュースを毎日紹介するエンジニア、デザイナー向けブログ

Taskjuggler を mac にインストールしてみた - takenoko1977の日記

Bluetooth詳説 - TaskJugglerについて

TaskJuggler を触り始めた

nDiki: ガントチャート - 今日のさえずり: 男性が1人でするならマンションで、複数でするならメンションです (2012-02-07)

nDiki: ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)

【インストール方法】
Rubyはインストール済み

gem install taskjuggler

tj3 --version
TaskJuggler v3.4.0 - A Project Management Software

【使い道】
サンプルファイルtutorial.tjpに対し、下記を実行すれば、HTML出力される。

tj3 tutorial.tjp

DSL風に、WBSやら期間、工数、担当者を入力すると、ガントチャートやバーンダウンチャート、リソースグラフなどを出力してくれるらしい。
出力形式はHTMLもあるし、色々あるみたい。
但し、PDF出力はない。

Product Burndownのサンプルは下記の通り。

Scrum Example Project - Product Burndown

コマンドラインしか使えないので、スケジュールに関するデータをテキスト形式に書かないといけない。
また、TaskJugglerのためのマクロを覚えないと、希望通りに出力されない。
でも、逆に言えば、テキストファイルでスケジュール管理できるので、バージョン管理で簡単に履歴管理できる。

元ネタのスケジュールをテキストで履歴管理するだけでなく、Webサーバー上へ定期的にHTML出力して公開するようにするやり方もある。
つまり、スケジュール管理も継続的インテグレーションで定期ビルドしてしまえばいいのだ。

使い道を色々考えてみる。

| | コメント (0)

2013/05/19

テスト駆動開発による組み込みプログラミングも良い本です

テスト駆動開発による組み込みプログラミング」を頂きました。
ありがとうございます。
既に色んな方が感想を書かれています。

【元ネタ】
「テスト駆動開発による組み込みプログラミング」 - Yasuo's Notebook

[書評]テスト駆動開発による組み込みプログラミング | Ryuzee.com

O'Reilly Japan - テスト駆動開発による組み込みプログラミング

書籍『テスト駆動開発による組み込みプログラミング』:柴田 芳樹 (Yoshiki Shibata):So-netブログ

"これこそ私の探していたものだった" - テスト駆動開発による組み込みプログラミング: 菊と書評

テスト駆動開発は設計技法である~組み込みアジャイルコーチ James Grenning さんインタビュー: プログラマの思索

C言語でTDDをやる場合、JavaやRubyに比べると、リフレクションやモックのプログラミングが難しいため、C特有のテクニックが必要になる。
テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」では、テストダブルのようないくつかのテクニックが公開されているので、組み込み系の人にとっては注目すべき内容だろう。

TDDによる設計の観点では、SOLIDという設計原則でまとめられている。
アジャイルソフトウェア開発の奥義」に詳しく書かれている。

・単一責任の原則(SRP)
・オープン・クローズドの原則(OCP)
・リスコフの置換原則(LSP)
・依存関係逆転の原則(DIP)
・インターフェイス分離の原則(ISP)

詳細は「オブジェクト指向の法則集@石井勝さん」のページが詳しい。

TDDでプログラミングする利点の一つは、テストしやすいインターフェイスを考えることで、自然にプログラム設計でき、しかもプログラムの品質も良くなることだろう。
手続き型言語でガリガリ書くと、どうしても長いメソッドになり、後からテストしにくい設計になってしまいがち。
ドライバやスタブでテストできるようにするには、そのようなインターフェイス設計にしなければならないからだ。

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」は組み込み系の人だけでなく、JavaやRubyの人にも参考になる本だと思います。

| | コメント (0)