« 2015年4月 | トップページ | 2015年6月 »

2015年5月

2015/05/31

GitBookのメモ

GitBookのリンクをメモ。

GitBook・Markdownで書いて電子書籍/HTMLを生成 MOONGIFT

Gitbookで学生向け講座の資料を作った話 - モノクロタイム

Yukaary Craft: gitbook試してみる

GitHubのMarkdownで文書を書くのが最近は普通になった。
Markdownでテキストを残しておけば、Pandocなどの変換ツールで、epub・HTML・PDF・Docなど多種多様なファイルに出力できるメリットがある。

出力フォーマットが多彩であれば、Webで公開したり、スライド資料で使ったり、Office文書で配布したり、スマフォで見たり、紙に印刷したり、色んな用途に使える。

GitBookはGitHubのMarkdownに特化したepub変換ツールらしい。
今度試してみる。

| | コメント (0)

2015/05/23

在庫は悪なのか善なのか

@hatsanhatさんたちと飲んでいて、在庫の話が出た。
@hatsanhatさんたちの話をログとして書いて、考えたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
第39回IT勉強宴会の感想~花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

渡辺式データモデリングの復習: プログラマの思索

【1】在庫はエンティティなのか?

モデル初心者は在庫をエンティティとして作りたがる。
すると、複雑なモデルになりがち。

在庫は商品の状態、またはサマリ。
在庫は、入出庫テーブルからタイムバケットごとに算出される数量。

在庫をエンティティにすると、在庫からのトレーサビリティが難しい。
在庫が分かるだけでは意味がなく、その在庫はどこにどんな商品があるのか、という情報までさかのぼらなければならない。
そうすれば、在庫を削減して業務を効率化することもできる。

【2】なぜ実棚をやるのか?
帳簿と倉庫の商品数を合わせるため、というのは回答にならない。

実棚をやるのは、利益を確定したいから。
在庫数量が確定しなければ、月末または期末の仕掛資産を計上できず、利益を確定できない。

経営者が常に見るKPIは、売上と利益の二つしか無い。
売上はトータルで把握できるが、利益は、原価や費用だけでなく、在庫という仕掛り資産まで把握しなければ確定できない。
特に、小売業や製造業では、実棚は定期的に行う必要がある。

つまり、在庫は単に業務の効率性の指標だけでなく、利益を確定するための要素として非常に重要である。

【3】渡辺さんが提唱する在庫監視推移方式の事例を初めて聞いた。

【3-1】在庫監視推移方式のデータモデルは、受払テーブルの派生関係で実現する。
「受払△--発注」という派生関係で在庫の過去、「受払△--受注」という派生関係で在庫の未来を管理する。

在庫監視推移方式の利点は、在庫のライフサイクルを横断的に監視できるので、将来を見通して在庫の数量をコントロールすることで適正在庫に抑えることができる。

しかし、弱点は、普通の会社では、発注テーブルの保守は購買担当者、受注テーブルの保守は営業マンのように、責任が分断されているために、受払テーブルを保守するような強力な権限を持つ担当者をアサインできないこと。
組織構造が業務にそのまま反映されてしまうために、在庫監視推移方式を実現しきれないのだ。

【3-2】でも、在庫監視推移方式を実現している事例がある。

その事例では、発注・受注テーブルと受払テーブルの保守は、専門部署の担当者が担当している。
彼は、仕入れから出荷までを担当するので、必要な部材の発注日や発注数量もコントロールしているし、製品在庫もコントロールしている。

彼にとって、製品在庫は在庫ではない。
納期に製品を顧客に出荷する責任があるという認識。
製品在庫は、いつまでにどれだけ作るか、という製造計画に従って作るものであるから、無駄な在庫ではない。
在庫は悪でも善でもない。

【3-3】在庫監視推移方式モデルの事例を持つ会社のビジネスモデルは何なのか?

在庫推移方式対象の製品は、既存顧客向け。
既存顧客とは深いつながりがあり、既に顧客の製品計画も内示が出ており、受注時期も数量も知っている。
だから、精度の高い製造計画が作れるし、製品在庫を在庫監視推移方式のモデルに載せることができる。

営業は新規顧客向けに専門化している。
だから、営業は本来の仕事をしているし、すごく大変。
工場は在庫監視推移方式の専門担当者の指示に従って作るだけ。

こういうビジネスモデルが成り立つのは、大量製造というよりも、試作品やプロトタイプを作る場合が多いらしい。
また、製品のマーケットは小さく、ニッチ向けが多いらしい。

ゆえに、在庫監視推移方式モデルは大企業よりも中小企業の方が向いている。
大企業になるほど、部門同士の相互牽制が必要になるから、営業と工場で在庫数量で衝突が起きがち。
大きな組織になるほど、在庫は一人の担当者で管理できる責任や権限を持っていない。

一方、中小企業では、組織が小さく未分化のため、一人の担当者が発注から受注、出荷まで担当する時が多い。
すると、一人の担当者が製品のライフサイクルをコントロールする権限も持つから、在庫監視推移方式モデルが非常に有効になる。
彼にとって、在庫は極力少なすべきという観点ではなく、納期までに製品を出荷するために必要な要素の一つに過ぎない。

【3-4】そんなことを聞くと、渡辺さんは中小の製造業や小売業向けの業務モデルの事例をたくさん知っているからこそ、在庫監視推移方式を編み出せたのだろうと勝手に推測する。
在庫監視推移方式モデルが必要な現場があり、実際に試して成功したから、そのメリットやデメリットも把握されているのだ。

渡辺さんのモデリングでは、一意制約を上手く使ったり、マスタの属性に残高などの作出属性をあえて追加するなど、T字形ERから見れば異端に見えるようなモデリングが多いらしいが、長年の開発経験に基づいた知見が多い。
個人的には、渡辺さんのモデルは、データモデリングのテクニックの観点でもすごく面白いし、事例に基づくモデルが多いからすごく参考になる。


| | コメント (1)

2015/05/19

ThunderbirdとOutlookのRedmineアドオン

@yassan168さんから、ThunderbirdとOutlookのRedmineアドオンを情報提供してもらったのでリンクしておく。
ありがとうございます。

【参考】
Redmine連携 :: Add-ons for Thunderbird

Issue Tracker Addin for Microsoft Outlook and Redmine

やっさんさんはTwitterを使っています: "#redmineT #redmine Outlookからチケットを作成/更新出来るアドオン>ITOL: Issue Tracker Addin for Microsoft Outlook and Redmine http://t.co/rupXybvloM"

やっさんさんはTwitterを使っています: "#redmineT #redmine thunderbirdからチケットを作成/更新するプラグイン> Redmine連携 https://t.co/gmaPKE2KNI"

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

Redmineプラグインあれこれメモ: プログラマの思索

Redmineのチケットのウォッチャー操作に関する課題: プログラマの思索

いずれもThunderbirdやOutlookの受信メールの内容をREST API経由でRedmineチケットに登録するプラグイン。
例えば、顧客からの問合せメール、ZabbixやJenkinsなどエラーメールをチケット登録する時に役立つ。

Redmineが他のITSよりも優れている点の一つは、チケット登録のI/Fが豊富にあることだろう。
メールによるチケット自動登録機能もあるし、REST API経由でExcelマクロやメールソフト、外部システムから簡単に情報を流し込める。
画面から入力するだけでなく、ツールで自動登録するI/Fがあるおかげで、障害メールやインシデント情報をRedmineに集約しやすくなる。

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索にも書いたけれど、Redmineには、プロジェクト管理の顔だけでなく、オープンソースの開発基盤の顔もある点が面白い。
プログラミングできるプロジェクトリーダーならば、Redmineほど触りがいのあるツールはないだろうと思う。

| | コメント (0)

2015/05/17

第8回東京Redmine勉強会の感想 #redmineT

第8回東京Redmine勉強会の感想をメモ。
興味のあることだけ書く。

【参考】
第8回勉強会 - redmine.tokyo

第8回東京Redmine勉強会 #redmineT - Togetterまとめ

第8回redmine.tokyo勉強会に行って来た #redmineT - やっさんメモ

redmine.tokyo 第8回勉強会に参加しました(#redmineT) - torutkの日記

【1】今回の勉強会は、テーマが玄人向けの話が多かったので、Redmineを既に運用されている人にとってはツボにはまったと思う。
逆に、Redmine初心者の観点では、レベルが高すぎて理解しにくかったかもしれない。
でも、現時点のRedmineでのノウハウはある程度出し尽くせたと思う。

個人的に今回の勉強会で感じたことは二つある。

【2】一つは、Redmineのチューニングを駆使すれば、200万件のチケットでも業務で使える可能性が高い点。

【2-1】@akahane92さんの計測データでは、OOBGCのおかげでRuby2.2を使うと画面レスポンスが高速化される。
また、Rails4.2にするとマルチスレッド化による内部改善のおかげで、約7%ほど高速化されるらしい。
つまり、RubyやRailsのミドルウェアをバージョンアップする恩恵が受けられる。

【2-2】実は、Redmineは、Ver2.6に至るまで一貫して性能が劣化してきたらしい。
おそらくその原因は、度重なる機能追加と性能要件の対応が後回しになったからだろう。

しかし、3.0では、2.6よりもRedmineの性能が改善されているらしい。
つまり、Ver3以降では、Redmineの性能改善も改善テーマの一つとしてJPLは捉えられていると思われる。

【2-3】Redmineのミドルウェア本体のチューニング以外に、サーバーにSSDを使う対策もある。
SSDを適用すると、3.0では明確な性能改善があった、とのこと。
最近は、SSDも安くなってきたから、数年後にはサーバーにSSDをまるごと入れる手段もありえるだろう。

【2-4】但し、Redmineの性能要件で一番のボトルネックは、全文検索機能だろう。
全文検索だけは、SSDにしても効果がなかった、とのこと。
以前から、@akahane92さんはチケットが20万件を超えると、Redmineの全文検索機能の応答時間が大きくかかるようになり、業務に支障が出るとお話されていた。

おそらくJPLもこの点は気づいており、内部リファクタリングによるチューニングや、デフォルトでは全文検索しないように検索条件を絞っておくなどの改善を行なっているようだ。

Redmine 3.0新機能紹介: 検索機能の改善 | Redmine.JP Blog

@akahane92さんの講演では、Redmine本家チケットのどこかで、JPLがRedmineがMySQLからPosgtresSQLに近い将来変更する理由として、PostgresSQLのマテリアライズド・ビューを使って全文検索を高速化する手法を使うのではないか、と言われていた。

Oracleではマテリアライズド・ビューを使うことで、トランザクションテーブルの検索を高速化する手法はよく使われるが、PostgresSQLでもその機能はあるから、上手く使えば対応できると思われる。

PostgreSQLのマテリアライズドビュー

SIOS "OSSよろず" ブログ出張所: PostgreSQL : マテリアライズドビューを利用した設計

※@akahane92さんの資料では、下記チケットのコメントに記載があるらしい。
Defect #15781: Customfields have a noticable impact on search performance due to slow database COUNT - Redmine

【2-5】以前のバージョンのTracは1案件ごとに環境構築していたが、情報がサーバーごとに散在してしまう弱点があった。
一方、Redmineは一つのサーバーだけで、一案件だけでなく、一つの組織の全ての案件を管理できることで、情報をRedmineだけに集約できる。
つまり、Redmineは、ソフトウェア開発企業の基幹系業務システムになりうるわけだ。
それによって、開発案件の企画段階から、開発・保守に至るまで、全ての工程の作業と情報を一元化できるメリットが生まれる。

すると、Redmineが組織全体で使うとなると、ユーザも案件もチケットの数も膨大に増え、性能悪化によって業務に支障が出てくるリスクが出てくる。
せっかくRedmineに蓄積したデータも、好きな時にすぐに検索したり更新できなければ意味が無い。

しかし、以上の話を踏まえると、Ruby・Rails・DB、Apacheなどのミドルウェア、SSD導入や仮想環境でのCPUコア数の追加などによって、Redmineの性能改善は可能という評価といえる。
これは大きな希望だ。

はてなブックマーク - ledsunのブックマーク - 2015年5月17日 130 projects, 350 users, 3000 tickets/month の規模のRedmine運用って世界でも有数なのでは?

【3】もう一つは、Redmine本体の品質は割と高いのではないか、という点。

【3-1】@akahane92さんの話では、RedmineのException検知プラグインを使っているが、Redmine本体の障害は今までほとんど検知したことがない。
障害のほとんどは導入したプラグインばかりだった、とのこと。

Redmineプラグイン集 - r-labsを見ると、下記のプラグインと思われる。

PluginExceptionHandler - Redmine

【3-2】@g_maedaさんに聞いた所によれば、JPLのRedmineの開発スタイルは非常に保守的である。
大幅な機能追加はやらないし、FunctionalTestが通らないパッチは受け取らない。
テストカバレッジは基本は100%になるまでリリースしない。

また、redmine はバージョンが上がっても見た目はあまり変わってない。
でも、ソースの中身は細かく対応されている。

その保守的な開発スタイルが、逆にRedmineの開発では有効に作用している。
実際、今までRubyやRailsのバージョンアップに追随できたのは、そのおかげではないか、と。

【3-3】@agilekawabataさんの講演では、数多くのオープンソースのツールの中で、Redmine はテストカバレッジが基本は100パーセント。
他ではあまり聞かない。
だから、Redmineは安心してバージョンアップに対応できる、と。

※下記で、Redmineの自動テストのビルド結果が公開されている。
エンタープライズ開発の観点で考えれば、世界中の人にテスト結果を公開しているのはすごいことだ。
普通はテスト結果は恥ずかしくて見せられない。

Redmine build status
Redmine code coverage
marutosi/redmine - Travis CI

【3-4】以上を踏まえると、RedmineのFunctionalTest、自動テスト環境がしっかりしているおかげで、単体テストレベルのバグはおそらくほとんど無いのだろう。

但し、Ver3に入って、3.0.3まで小刻みにリリースされているのは、細かなバグが見つかったため、その対応をしていたからだ。
Ver 3.0.3でようやく機能も落ち着いたのではないだろうか。

【3-5】そんなことを思うと、Redmineはオープンソースの中でも品質がかなり優秀な部類に入るだろうと思う。
Redmine本体の品質が良いと思われることによって、ユーザもRedmineに対して信頼度が増すだろう。
また、品質に自信があるからこそ、頻繁なバージョンアップも可能になるし、今後の機能追加もやりやすくなるだろう。

特に、RubyやRailsのバージョンアップにRedmineが追随していくことは、Redmineの寿命の観点で最重要だ。

例えば、Rubyは既に1.9のサポートが終了しており、2.0も来年にはサポートが終わってしまう。
つまり、セキュリティホールが見つかったとしても、Rubyの古いバージョンはサポートが受けられないため、古いRubyを使い続けることは非常にリスキーになってくるからだ。

すなわち、RedmineがSIの基幹業務システムになったとしても、Redmineのバージョンアップに追随していくことで、安定して使い続けられることを意味している。
Redmineは今後も進化していける条件が整っているからこそ、信頼して使える。

その信頼感があることは、RedmineがRailsのキラーアプリとして、またRailsが生み出したアプリの中でも優秀な部類に入るものとして評価できるだろうと思っている。

【追記】
主な資料は既に下記で公開されている。

| | コメント (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)

Redmineの「チケット計測のススメ」の記事がすばらしい

Redmineの「チケット計測のススメ」の記事がすばらしいのでメモ。

【参考】
Redmine - チケット計測のススメ - Qiita

チケット駆動開発によるチーム力向上の事例 #Redmine: プログラマの思索

チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。
次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース&解析して、各種メトリクスを出力する仕組み。

仕組みは簡単だが、すごく良いアイデアだ。

従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。
アジャイル開発ならば、下記が既に知られている。
詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。

・累積フロー図:ステータス毎のチケットの枚数を時系列に並べたグラフ
・Velocity:チームの開発規模を表す
・リードタイム:平均のリリース間隔を表す。チケットの平均完了日数。
・サイクルタイム:ステータスが変更される平均時間を表す。

累積フロー図は、チケットの増減を通じて、チームの開発履歴を見る時に使う。
Velocityは、チームの平均の生産性を示す。
アジャイル開発が教える所によれば、Velocityは急激に増やすべきものではなく、安定させるべきものである。

リードタイムはチケットの平均完了日数だから、リリースサイクルに相当する。
リードタイムが長いほど、リリース日数が長くなるため、顧客の新規要望の実現は待たされるようになり、顧客満足度が落ちるだろう。

アジャイル開発の観点では、リードタイムは、XPのイテレーション、Scrumのスプリントの期間よりも短くなる。
そうでなければ、1イテレーション、1スプリントの終了直前までチケットが残ることになるから、リリースできない。
つまり、アジャイル開発では、リードタイムは2~4週間よりも短くなるように運用しなければ意味が無い。

サイクルタイムはチケットの更新間隔に相当する。
サイクルタイムが短いほど、チーム内で活発に作業がやり取りされていることを示す。
逆に長ければ、チーム内のコミュニケーションに問題があったり、開発プロセスが厳格すぎて開発ペースを落としているのかもしれない。

上記の記事では「ステータス別計測」を累積棒グラフにすれば、累積フロー図に相当するだろう。
また、「消化予測」はVelocityに相当するだろう。
「寿命」はチケットの平均完了日数だから、リードタイムに相当する。

さらに、「放置量」という図があり、「指定された区間より以前に作成されて、未だに完了していないチケットを生成時期別に表示」とある。
放置されたチケットが多いほど、Redmineがゴミ箱になっている事実が分かる。

Mantisでは、集計画面に「平均完了日数」や「最大放置日数」のメトリクスを出力する機能があったから、Redmineでも同様に表示できるといいと思う。

これらのメトリクスを手動で収集しなくても、自動計測できるのが素晴らしい。
これらのメトリクスをチームで共有できれば、Redmineによるチケット駆動開発を、現場主導でプロセス改善する動機になり得る。

この辺りのノウハウもまとめていきたい。

| | コメント (0)

5/16に第8回redmine.tokyo勉強会が開催されます #redmineT

5/16に第8回redmine.tokyo勉強会が開催されます。
既に満員御礼ですが、残りのLT枠2つに応募すれば、参加可能です。

【参考】
第8回勉強会 - redmine.tokyo

第8回redmine.tokyo勉強会 - connpass

第8回redmine.tokyo勉強会 懇親会 (夜の部) - connpass

今回の東京Redmine勉強会では、@g_maedaさん、@akahane92さん、@agilekawabataさんをお呼びして、主にRedmineの最新バージョン3.0のお話やRedmineのチューニングに関する事例で開催します。

僕自身が特に興味がある講演は、@akahane92さんのRedmineの性能改善の事例です。
今回の講演では、@akahane92さんが以前から精力的に研究されているRedmineのチューニングが主なテーマです。
@akahane92さんはSQIP2014でも、IT内部統制にRedmineを導入して成果を出した経験事例を発表されています。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

少人数で使い始めるならば、Redmineの性能が運用のボトルネックになることは少ないでしょう。
しかし、例えば、一つの事業部で自社社員・協力社員100名以上で50~100プロジェクトの運用を始めると、すぐにチケット数は数万を越えてきます。
日中のアクセス頻度もかなり増えるでしょう。

以前聞いた話では、Redmineの性能がボトルネックになってしまう機能として、Redmineの右上の検索ボックスがあげられていました。
チケット数が20万件以上に増えると、Redmineの全文検索機能の性能がかなり落ちてしまうのだそうです。
Redmineのようなチケット管理ツールのメリットの一つが、チケットやWikiに蓄積された過去の作業情報をいつでも探し出せることなので、検索機能が使いにくくなるのは困った事態です。
Ver3.0のRedmineでは、この問題がどこまで解決されているのか、聞いてみたい所です。

Redmine 3.0新機能紹介: 検索機能の改善 | Redmine.JP Blog

RedmineがSIの現場のプロジェクト管理ツールとして普及するにつれて、Redmineそのものがソフトウェア開発の基幹業務システムになっている所も多いでしょう。
すると、Redmineが止まってしまうと、文字通り開発業務に支障をきたすだけでなく、会社全体の業務に悪影響をもたらすリスクが出てきます。
また、長年の運用でチケット数が増えていくうちに、性能も劣化してしまい、使いづらくなる可能性もあります。

性能改善の問題は、Redmineがよりミッションクリティカルな業務に耐えうるためにも、解決されるべきテーマになるでしょう。

幸いなことに、RedmineはRubyやRailsのバージョンアップに追随する方向に進化しています。
Ruby2.2に対応したことで、GCの機能改善によって性能向上も見込めるでしょう。
また、Rails4.2に対応したことで、安定性も保証され、機能拡張もやりやすくなるでしょう。

つまり、RedmineがはRubyやRailsのバージョンアップに追随することで、最新のミドルウェアやライブラリの性能改善や品質向上の恩恵を受けられるメリットがあります。

ますごんさんはTwitterを使っています: "Ruby界隈、バージョンアップでダイナミックにAPI変わっていくとは聞いてたが、なかなか辛そう。 RedmineプラグインのRails4対応やってみて戦慄した。ちっちゃなプラグインならまだしも、大きなプロダクトは地獄やわ。 どうりで古いプラグインで動かないの多いとわけやわ。"

akipiiさんはTwitterを使っています: "なるほど〜RT @knjname: Redmine 3.0.0はRuby 2.2、Rails 4.2というスタックです。バージョンちょっとあがればすぐ非互換なRubyの世界ですから、保守派の皆さんにはきっとしばらくは辛いことでしょう…"

Redmineの開発履歴を見ると、テストカバレッジや自動テストがとても厳格である態度が見られます。
この厳格な開発作法のおかげで、APIや構造がバージョンアップのたびに大きく変わってしまうRubyやRailsにもRedmineが追随できるのでしょう。
そんなことを思うと、Redmineのコミッタは慧眼の銘があったように思えます。

オープンディスカッションで議論する時間も設けているので、参加者の方が持っている経験談も交えて、Redmineの今後のあるべき進化の姿も議論できるといいな、と思います。

| | コメント (0)

2015/05/06

システム設計よりも業務プロセスの設計をやっている

業務プロセス設計についてラフなメモ書き。
主張は特に無く、アイデアをメモ。

【1】業務システムを設計・開発していると最近、システムを設計しているという感覚がない。
むしろ、業務を設計しているという感覚に近い。

すると、既存の業務フローを簡素化してシステム化するという仕事になりやすい。
特にERP導入の場合はそうだ。
既存の手作業のフローがどこまでERPの機能に吸収されて効率化されるか、がERP導入の一つの目的だから。

しかし、既存の業務フローを変更するのがとても難しい経験を何度もしている。
現場にとって、長年の業務フローが変わると、担当者の作業が増えたり減ったりするために、組織に影響をおよぼすのはご法度なのだ。

組織構造に関わるBPRの場合、ユーザ企業の責任者に承認を得て、業務フローを変更しなければならない。
既存の業務フローが変わることをきちんと合意しておかないと、せっかく決めた要件はユーザ担当者に簡単にひっくり返されてしまう。

今の業務が変わるのは困る。
長年このやり方でやってきたのだから、皆に説明してくれ、と。

だから、ERP導入や業務プロセスの改善は、経営者からのトップダウンの指示でなければ成功しにくい。
既存の組織が抵抗勢力になってしまうから、トップダウンで解決するしか無いのだ。

【2】僕はアジャイル開発が好きなので、ボトムアップでプロセス改善していくのが好き。
現場の創意工夫を生かして、自分たちの業務プロセスを少しずつ地道に改善していく方が好きだ。

でも、ERP導入やBPRは、経営層の力を使って上からのトップダウンで進めないと成功しないという経験をしている。
組織の壁を打ち破るには、社内政治が上手くなければ、何も進まない。

【3】情報システムの設計は、画面や帳票を決めるだけではない。
ユーザの操作や業務フローも考慮して、設計しなければならない。

ユーザの操作は、システムと人間の相互作用であり、そのインターフェイスが画面や帳票になっているだけ。
システムと人間の相互作用の流れを一連の手続きとしてまとめたものが、業務フローになる。

UMLやDOAでは、システムの設計技法は整っているが、肝心の業務プロセスの設計技法が不足している気がする。
BPMNが業務プロセスの設計技法を目指そうとしているが、何か物足りない。

| | コメント (0)

2015/05/05

チケット駆動開発はチケット管理ツールから離れて定義できるか

チケット駆動開発はチケット管理ツールから離れて定義できるか、という問題についてラフなメモ書き。
思索のメモであり、特に主張はない。

【1】チケット駆動開発は、チケットを起点にして、ソフトウェア開発の作業の発生からリリースまでを記録して管理していく仕組み。
このアイデアはとてもシンプルだし、誰でも思いつきそうなアイデアだ。
このアイデアを何とか抽象的な概念で再定義できないか、とずっと考えていた。

チケット駆動開発の特徴や利点を話そうとすると、必ずチケット管理ツールの使い方が出てくる。
そのツールの機能や使い方から切り離して、チケット駆動開発を説明しようとすると、何かしっくりこない感覚がある。
チケット駆動開発のプラクティスをパターン化しようとしたけれど、PMBOKやXPの部分集合みたいな感じになって、自分が描いたイメージよりも矮小化された気がしていた。
だから、チケット管理ツールをベースに説明する方が具体的なイメージをつかみやすいし、説得力もあるように感じていた。

【2】チケット管理ツールの代表例はやはりRedmineだろう。
ワークフロー管理、チケット集計機能や構成管理ツールとの連携など、チケット駆動開発に必要な機能のバランスが一番取れていると思う。
Tracはチケットという概念を生み出し発展させたが、僕自身はRedmineの方が使いやすい。

しかし、チケット管理ツールはRedmine以外にも、Jiraもあるし、Backlogsもあるし、その他のツールもある。
Redmineの弱点は、Scrumのプロセス実装とGit連携だろう。

【2-1】Git連携の課題については以前書いた。

長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい~プルリクエストはJiraにあってRedmineにない機能: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

つまり、GitHubのように、Gitのブランチ管理とプルリクエスト機能をGitHubフローとして実現することが、Redmineは実現できていない。
GitHubが生み出したプルリクエストという機能は、アジャイル開発ととても相性が良いから、何とかして入れたいものだ。

【2-2】また、PivotalTrackerのように、よりアジャイルなかんばんとして運用する方法もRedmineでは実現できていない。
Scrumを実現するBacklogプラグインは最近、RedmineのVerUpに追いつけていないように思える。
また、PivotalTrackerのように、進捗率はToDo/DoneのBooelanで表示したり、ストーリーポイントで見積りしたり、かんばんを移動するステータス管理でリリース&受入確認する運用は、Redmineで簡単に実現できていない。

Pivotal Trackerとredmineの違い: プログラマの思索

チケット駆動開発の適用範囲part3~ストーリー駆動のチケット駆動開発: プログラマの思索

Redmine Backlogs :: Home

RedmineでもXPの小規模リリースは実現できるけれど、アジャイル開発らしいScrumやかんばんをRedmineの一機能として実現したいのだ。
そうすれば、もっとアジャイルなタスク管理がやりやすくなるだろう。

【3】Redmineはチケット管理ツールの中で有名かもしれないが、多種多様なチケット管理ツールの一つに過ぎず、チケット駆動開発の一つの実装例としてあげたい。

なぜなら、チケット駆動開発がチケット管理ツールに依存するプロセスだとしたら、せっかくの有用な概念はツールの一機能に過ぎなくなるから。
本来は、チケット駆動開発で見出した概念は、ツールに依存せず、大きな体系の枠組みの中で表現したい。

その体系の枠組みの実現例として、多種多様なチケット管理ツールがあり、それらの機能がある、という形で説明したい。
その説明によって、チケットとは結局何なのか、チケット管理の適用範囲と限界は何なのか、を明確にしたいのだ。

| | コメント (0)

« 2015年4月 | トップページ | 2015年6月 »