2017/04/28

第12回東京Redmine勉強会の見所

来たる5月の第12回東京Redmine勉強会の見所をメモ。

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

redmine.tokyo 第12回勉強会 - connpass

【1】今回のテーマは『みんなでRedmineプラクティスをシェアしよう』。

最近、IT業界にかぎらず、メーカーなどの他の業界でも、Redmineという言葉を聞く機会が多くなってきた。
チケット管理の適用シーンが増えていて、そのメリットを感じられる利用シーンも増えているのだろう。

そこで、Redmineの導入や運用の観点と、Redmineを支える技術面の観点の二つから、Redmineの利用事例を紹介できることになった。

【2】Redmineの導入や運用の観点では、まず、@Madowindaheadさんの「Redmineを活用したプロジェクトマネジメント技術向上について」がある。
@Madowindaheadさんは、PMOの立場として、プロジェクト管理の標準化や運用推進を担当されているとのことで、Redmineをベースにしたプロジェクト管理の社内説明会を過去2年以上実施されている、とのこと。
社内でRedmineの利用を推進して展開していくためのノウハウや、落とし穴に関するお話が聞けることを楽しみにしている。

過去のRedmine勉強会の参加者からも、社内でRedmineを使ってもらうにはどうすればいいか、という初歩的な質問も多い。
だから、Redmineを実際に導入したものの、全社的に展開していくためにはどんな手順やノウハウが必要なのか、という観点で聞けば、参考になるものが多いのではないか、と期待している。
3月のRedmine大阪のLT資料がダイジェスト版らしいので、参考にしたらと思う。

Redmineを活用したプロジェクトマネジメント教育について(ダイジェスト版)

【3】次に、宮本 陽一さん の「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」の講演がある。

「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JDMF2016講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になる: プログラマの思索

ソフトウェア開発における派生開発やプロダクトライン開発にRedmineが有効に使えるのではないか、というアイデアについては、僕も過去に色々考えてきた。
たぶん、同じように感じている人達も多いと思う。

派生開発やプロダクトライン開発については、昔から沢山の人が開発プロセスは考えられてきたけれど、そのプロセスの実装が非常に煩雑、という問題があると思う。
その問題点は、複数の開発ブランチを並行開発できる構成管理と、要件からソース修正に至るまでのトレーサビリティの2点をいかにプロセスとして実装するか、という点で置き換えられると思う。

つまり、その2つの問題点は、Redmineの構成管理ツール連携と、チケット管理のトレーサビリティというRedmineの特徴を活かせば、たぶん解決できるはず、と直感している。

また、派生開発やプロダクトライン開発の別の観点では、複数の組織をまたがったプロジェクト管理をどのようにプロセスとして実装すべきか、という問題もある。
たとえば、複数の製品開発チームとコア基盤の開発チームがいかにスムーズに連携しながら、並行開発しながら、順次リリースしていくべきか。
たぶん、たとえアジャイル開発であったとしても、そのプロセスの実装はそう簡単ではないはずだ。

なぜなら、派生開発やプロダクトライン開発では、マトリクス型組織になりやすいため、ワンマンツーボスシステムの組織になりがちで、メンバーの観点では二人のボスの指揮命令系統に従わざるを得ず、混乱しがちだから。

この問題点に対しても、Redmineの複数プロジェクト機能を組織構造と上手く対応付ければ、運用するプロセスの実装はかなり楽になるはずだ、と直感する。

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

すなわち、Redmineの柔軟な機能を上手くプロセスと組み合わせれば、プロセスの運用ルールをガチガチに固めなくても、自然に運用できるような雰囲気を作れるだろう、と直感している。
そういうことを考えながら、講演を聞いてみたいと思う。

【3】次に、須藤功平(@ktou)さんの「GroongaでRedmineを高速全文検索」の講演がある。
Redmineの全部検索を高速化するプラグインを実装公開されているので、利用者の観点でお話して頂く予定。

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

下記でも書いたけれど、Redmineのようなナレッジを蓄積するシステムでは、全文検索機能は他のシステム以上に重要な機能であると考える。
なぜなら、チケットやWikiにどんどん過去の作業の経緯や技術情報が記録されて蓄積されたとしても、その内容を即座に検索できなければ、過去の知見を有効活用できないからだ。
たとえば、3年前の障害に関連する情報を全文検索しようとして、3分以上も待たされたら、正直使いものにならない。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

よって、このRedmineの全部検索プラグインは、Redmineをナレッジシステムとして有効活用するために、またそう感じることで利用ユーザのモチベーションを高めるためにも重要な機能であると思う。

また、@ktouさんは、Rubyコミッタの方でもある。
そして、Ruby本家もバグ管理をRedmineで運用されている。
色々お話が聞けるのでは、と楽しみにしている。

kou (Kouhei Sutou) - Ruby Issue Tracking System

OOエンジニアの輪! ~ 第 39 回 須藤 功平さんの巻 ~ | オブジェクトの広場

Rubyist Magazine - Rubyist Hotlinks 【第 36 回】 須藤功平さん

【4】その他にも、@g_maedaさんの講演やLT7本もあるので、盛りだくさん過ぎるほどだ。
参加者も既に定員オーバーで、静かに盛り上がっている。
当日の勉強会が盛り上がるのを楽しみにしている。

| | コメント (0)

2017/04/13

Redmineを帳票ワークフローツールとして強化するstatus_buttonプラグインが面白い

Redmineでステータスに応じた担当者を自動設定するstatus_buttonプラグインなるものがあると知ったので、メモ。
稟議書申請・承認のような事務処理ワークフローで役立ちそうで面白い。

【参考】
QA #312: Redmineの画面上で、編集操作を行わずにステータスを変更+ステータスに応じた担当者自動設定 - Unofficial Redmine Cooking - redmine.tokyo

Status Button - Plugins - Redmine

fanzai0403/status_button: redmine plugin status_button

(引用開始)
Status Button プラグインで対応可能です。

・ステータス変更はボタン押すだけ(特に承認者)
・権限外のステータス変更は実行不可(標準のWF操作と同じ)
・次の担当者は最初にまとめて設定できる。(起票者が設定しておく)
(引用終了)

以前、Redmineを稟議書申請・承認のような事務処理ワークフローとして使いたい場合、どんな機能が必要なのか、を考察した時があった。

RedmineをBPMツールとして使うアイデア: プログラマの思索

Redmineは事務処理の申請承認ワークフローに使えるか?: プログラマの思索

Redmineにワークフローエンジンとして必要な機能~ワークフローに組織マスタの情報を持たせる: プログラマの思索

Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

Redmineの現状の機能でも、簡易な帳票ワークフローツールとして十分に使える。
しかし、細かな操作性が不足しているので、そこが気になる場合がある。

僕が一番気になる点は、ステータスごとに担当者を絞り込んで表示して欲しい機能が不足している点だ。
課長承認、部長承認、経理承認のようなステータスでは、役職や権限を持つ人は限定されているので、その人達だけが担当者に表示されて欲しいのだ。

この問題は、上記のプラグインで解決できるみたい。
status_buttonプラグインで面白い点は、管理画面であらかじめ、ステータスごとにロールを設定する点だ。

つまり、課長・部長・経理のようなロールをあらかじめ作っておき、status_buttonプラグインの管理画面で、課長承認、部長承認、経理承認のようなステータスに各ロールを割り当てておく。
そうすれば、各PJでロールを人別に設定できるので、ステータス遷移できるロールの人だけ、承認操作ができる。
次のステータスは誰か、逐一考えながら設定する必要はない。

また、status_buttonプラグインでは、完了までの全ステータスが表示されているので、今後、どのようなワークフローを経由するのか一覧できて便利だ。

このような機能がRedmineに取り込まれたら、事務処理ワークフローとしてRedmineはほぼ使えるレベルになるだろうと思う。

Redmineが面白いのは、Redmineのデフォルト機能で、タスク管理以外のありとあらゆる雑務をWeb化して一括管理できる可能性を秘めている点だ。
業務改善というBPRの観点で、Redmine導入や運用を考えてみると、さらに面白いかもしれない。

| | コメント (0)

2017/04/03

チケット管理システムは作業の構成管理と同じ

Redmineのようなチケット管理システムは「作業の構成管理」という機能を提供しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【1】2000年頃に「達人プログラマー」という黒本を買った。
当時は一流のプログラマになるためのバイブル本だった。

その中の一節に「ソースコード管理システムは、ソースのUnDo機能を提供するシステムである」という文言があり、すごく印象に残った時があった。

実際のプログラミングでは、自分の思考内容をソースコードに表すが、最初から一番良いソースが書けるわけではない。
試行錯誤しながら、ロジックを切り貼りしたり、分割したり、いじくったりする。
すると、その履歴を残したくなる。
途中で、テキストエディタでUndoやRedoするように、ソースコードも過去に遡ったり、途中のソースに戻りたくなるからだ。

つまり、ソースコード管理システムは「プロジェクトレベルでのタイムマシンというべき一つの巨大なUnDoキー」なのだ。

特に、昨今は、GitHubやGitを使っていると、masterとは別に、ブランチ上で新しい機能を実験しやすくなった。
また、たくさんのブランチを派生させても、あるタイミングでマージするためにプルリクエストを送ればいい。

【2】チケット管理システムがないプロジェクトで、作業管理を見ていると、作業の履歴やUnDo、ReDoが欲しくなる時がある。
ISO9001のQMSの運用を行なっている現場で、そんな状況を見た時がある。

ISO9001の品質管理マネジメントシステムでは、全ての作業は記録として残さなければならない。
普通は、作業依頼書のようなExcel帳票に、作業発生から作業終了までの履歴を記録する。

しかし、普通は作業依頼書だけでは話は終わらない。
Excel帳票としては、作業依頼書と、仕様変更の設計書やリリース手順書のような作業手順書とペアが必要になる。
実際の細かな仕様、詳細なリリース手順は、作業依頼書には書ききれないからだ。

それら2個のExcel帳票を、作業状況ごとに管理する必要があるが、これが結構面倒だ。
普通は、作業中のステータスで滞留しがちで、なかなか終了しにくい。
依頼する人と作業する人は別々なので、作業連携がすごく悪いからだ。
今、どの作業ステータスにあるのか、最新状態が反映できていない。

この問題の原因は、作業のステータス管理ができていない点にある。
それは、Excelの作業依頼書には判子欄があるが、それはRedmineのチケットのステータスと同じだ。
Redmineでやれば、すぐに解決できる。

また、Excel帳票の版管理で、依頼する人と作業する人が混乱する場合もある。

依頼する人は設計書を用意するが、割り込みの要望や考慮漏れで設計書を書き直したりする。
すると、どの設計書が最新版なのか、作業する人は混乱しがち。

この問題の原因は、設計書の版管理、つまり設計書のバージョン管理ができていない点にある。
結局、Excelの設計書もSVNやGitでバージョン管理すべき対象なのだ。

Excel帳票で作業依頼書と設計書をやり取りしているISO9001の運用では、プロジェクト数が増えるほど、混乱しがちになる。

【3】そんな状況を見ると、Redmineのようなチケット管理システムは、設計書のバージョン管理と同じように、作業のバージョン管理を提供しているように思える。

設計書のバージョン管理が必要な理由は、設計書の最新版がどれなのか、を明確にする必要があるからだ。
リポジトリを見れば、タグ付けされた設計書が作業対象だ。
設計書の履歴は、リポジトリのリビジョン履歴を見ればいい。

同様に、作業依頼がチケットとして発行されれば、チケットのログに全ての作業履歴が記録される。
作業中に課題が発生したり、設計者と実装手段を議論したり、間違った実装を障害として把握して直したり、色々あるだろう。
そういう履歴があるからこそ、作業依頼書の内容に記載された「作業」は、過去にいつでもさかのぼれる。

つまり、チケットは「作業内容のタイムマシン」だ。
「昔にさかのぼって、どんな作業が行われたのか、を追跡できる」点がチケット管理システムの最大のメリットだ。
これは「トレーサビリティ」という機能を提供している。

チケット管理システムが持つトレーサビリティは、本番稼動後の派生開発や障害修正で、大きな威力を発揮する。
本番稼動中の汚いソースコードには、過去の障害修正によるパッチの意図がある。
その変更の意図を無視して、ソースを勝手に弄ってはいけない。

また、プログラマは派遣契約で出入りが激しい。
3年前に書いたプログラマがいなくなれば、そのソースコードは、どんな意図で書かれたのか、その仕様はどういう経緯で決まったのか、誰も分からなくなる。
しかし、チケットにその作業履歴が残っていれば、その作業履歴に紐付くソースの変更履歴を辿ることで、パッチの意図を把握することができる。

ソフトウェア構成管理は、ソースコードのバージョン管理だけでは足りない。
作業の構成管理というべきチケット管理システムも必要だ。

IT化されていないISO9001のQMSで、作業依頼書と設計書という2種類のExcel帳票が運用上必要であるという事実は、ISO9001の背後にある構成管理には、成果物のバージョン管理と作業の履歴管理(トレーサビリティ)という2種類の構成管理が必要なのだ、という思想が背後にあるように思う。

【追記】以前、岡本さんから、「Gitポケットリファレンス新版」を頂きました。
構成管理の仕組みを理解する上で、Gitが分かれば、過去のバージョン管理ツールも分かるだろうし、チケット管理システムの必要性も見えてくるのではないか。
Gitポケットリファレンス新版」は、Gitを知る上でとても読みやすい本でお勧めです。

| | コメント (0)

2017/03/30

Redmineで日本語ファイル名の画像がPDF内で正常表示されるようになった

ver3.3.2のRedmineで日本語ファイル名の画像がPDF内で正常表示されるようになったのでメモ。
@naitohさん、ありがとうございました。

【参考】
Defect #22335: Images with non-ASCII file names are not shown in PDF - Redmine

akipiiさんのツイート: "Redmine3.3.2 で、PDF出力時に、日本語ファイル名の画像ファイルが埋め込まれない 。画像ファイル名がURLエンコードされた文字列がPDF出力される 。画像ファイル名が英数字ならば、PDFに画像が埋め込まれるのでOK。"

akipiiさんのツイート: "Redmine 利用の日本人にはありがたいです。RT @g_maeda: @naitoh @akahane92 Defect #24271 の件とともに修正ありがとうございます! PDF内で画像が正常に表示されることを確認しました。 喜ばれる方が多いのではないかと思います。"

akipiiさんのツイート: "ありがとうございます!@naitoh: @akahane92 @g_maeda Redmine 3.x で、日本語ファイル名の添付画像がpdf出力されない件、対応が遅くなり申し訳ありません。先程リリースした rbpdf 1.19.1にて修正しましたので、ご確認頂ければと思います。"

Kuniharu AKAHANEさんのツイート: "@naitoh @g_maeda 内藤さん、対応してくださったのですね。本当ありがとうございます。確認しますね。/ A good news for #Redmine CJK users! Thx a lot @naitoh san! https://t.co/HK2o7DnQwT"

Kuniharu AKAHANEさんのツイート: "@naitoh @g_maeda 当方の全環境にて、問題の解消を確認できました。とても助かります。ありがとうございました!/ Images with non-ASCII file names are not shown in PDF https://t.co/zITGox6odB"

Redmine 2.6のCHANGELOGのメモ: プログラマの思索

10年前のRedmineでは、PDF出力した時、日本語が文字化けする問題があったが、今はもう無い。
しかし、ついきさっきまで、Wikiに日本語ファイル名で画像ファイルをアップした後でPDF出力すると、PDF内に日本語ファイル名がURLエンコードされて表示されてしまい、画像が埋め込まれないバグがあった。

@naitohさんが、PDF出力Gemを更新してくれて解決した。
「bundle update」を実行すればOK。

(引用開始)
bundle update results:

Using rbpdf-font 1.19.1 (was 1.19.0)
Using rbpdf 1.19.1 (was 1.19.0)
(引用終了)

RedmineのPDF出力機能が活躍する場面は、Wikiに記載したマニュアルをPDFで出力したい時だろう。
たとえば、Redmineの運用マニュアル、業務システム開発PJの技術情報や用語集などは、Wikiに書いている場合が多い。

Wikiに書いておけば、メールにリンクさえ貼れば誰でも見れる。
Excelドキュメントに運用マニュアルや技術情報を書いても、すぐに内容が古くなるし、Excelファイルはすぐに散在してしまうから。

運用マニュアルや技術情報のように、版管理しなくてよいドキュメントは、Wikiにピッタリだ。
最新版のマニュアルさえ取得できればいいから。

Wikiに編集履歴が残るので、最新版さえ保守すればいいから。

マニュアル納品の時は、PDFで納品すればいい。
しかも、RedmineからWiki全てを一括PDF出力できるし、しおり機能も付いてくるので便利。

Redmine 1.4新機能紹介: Wikiの全ページを一括してPDFに出力 | Redmine.JP Blog

しかし、PDFではなく、Wikiの内容をOffice文書で出したい時もある。
Redmine本家には既に、ODT形式で出力するパッチがアップされている。

2016年5月のRedmine開発状況 | Redmine.JP Blog(WikiページをODT形式でエクスポート)

Feature #22923: Export Wiki to ODT - Redmine

WikiからOffice文書が出せるのはすごくいい。
ユーザマニュアルを納品した時に、ユーザが自分で加工できるから。
後はご自由に、みたいな感じで。

この機能も早くリリースできるようになればいいと思う。

【追記】
Windows上で、Ruby1.9、Ruby2.0では、rbpdf 1.19.1でエンコーディングエラーが発生する、として、JPLがチケットをRejectした。
それを受けて、まるやまさんが、Ver3.4で、Ruby1.9、Ruby2.0は廃止することを提案している。
実際、Ruby2.0以前は既に保守されていないからだ。
但し、RedmineがRuby2.0以前は対応しない、という意思決定がなされると、利用ユーザに大きな影響を与えるだろうと思う。

Defect #24271: htmlentities warning - Redmine

Feature #25538: Drop support Ruby 1.9.3 and 2.0 - Redmine

なお、その後、@naitohさんがRbpdfの修正バージョンをリリースしたので、Redmine本家に取り込まれた。

リビジョン 16520 - Use rbpdf 1.19.2 (#22335, #24271). - Redmine

JPLがこのように、細部までテストしてバグ出ししていること、それを受けて、レガシーなRubyを廃止することを検討していること、それらの動きをWeb上で全世界で参照できることにすごく敬服している。
Redmineの進化の方向性は、間違っていないように思う。

【追記】
RubyのPDFライブラリRbpdfに関して、@naitohさんの移植作業は下記で公開されている。

| | コメント (0)

2017/03/27

第54回関西IT勉強会の感想

第54回関西IT勉強会で、渡辺さんの生産管理データモデルを超高速開発ツールで実装してデモを見せてくれて、面白かった。
以下はラフな感想。
間違っていたら後で直す。

【参考】
データモデルを通して業務を理解しよう <第54回IT勉強宴会> | IT勉強宴会blog

データモデルを通して業務を理解しよう - connpass

【1】渡辺さんの生産管理データモデルは既に公開されている。
書籍では何度も読んでいるけれど、実際に動いた画面は見てないので、ピンときていない部分もあった。
今回、超高速開発ツールで実装してデモを見て、渡辺さんの生産管理データモデルはすごい!と改めて気づいた。
(レベルが低くてスミマセン)

【2】渡辺さんの生産管理データモデルで興味深い点はいくつかある。

【2-1】受注生産と言いながら、汎用部品の見込生産にも対応している

受注生産のシステムなので、製造するときには必ず受注番号が既にある。
受注番号から製造指図書が生成され、それに従って、原材料の発注、設備の作業時間の予約、作業員のスケジュール予約が自動設定される。
つまり、MRPの所要量計算が自動計算されて、必要なリソースが予定として計画される。
そして、次の業務へ移る。

だが、渡辺さんの生産管理データモデルでは、「特殊売上」「特殊仕入」という特殊な業務がある。
これは、汎用部品の売上処理や仕入処理を意味する。
なぜこういう機能が必要なのか、を推測すると、受注番号なしで製造指図書を発行したい、という例外的な業務があるからだろう。
そういう例外的な業務をシステム化しないケースもありうるが、その場合は、例外的な業務は従来の紙による運用になってしまい、生産データや売上データを別で入力する必要が出てしまう。
だから、このような例外的な業務に対応する機能も実装しておくと便利。

その場合、その例外的な業務に対応する機能は、ほとんど全ての例外業務を飲み込んでしまう。
たとえば、本来は、何らかの理由で追加生産する時に使う機能だったのに、汎用部品を事前に見込生産する、とか、サポート保守用の部品を事前に生産して準備する、とか、ありとあらゆる例外業務に対応できてしまう。
つまり、例外的な業務に対応する一機能にすぎないのに、実際は、受注生産以外の全ての生産業務に対応できるような仕組みを故意に作っておけば、中小企業のある程度の生産業務に対応できる、という背景があるのだろう。

そういう意図を読み取りながら、デモ画面を見ると、さほど複雑ではないシンプルな生産システムにも関わらず、このデータモデルを流用すれば、ある程度のシステムを構築できてしまうわけだ。
たぶん、渡辺さんの過去の経験から、こういうデータモデルがないと、現場の業務は回らない、という確信があるのだろう。

【2-2】製造指図書、発注明細などのFatなテーブルの項目には意味がある

公開されたER図をサラッと見ると、業務の中心にFatなテーブルがあり、その周囲に惑星のような小さなテーブルが配置されている。
まるで、太陽系のようなデータモデル。

T字形ERの人達から見れば、正規化しきれていないテーブル構造だと思えてしまうかもしれない。
だが、実際にデモを見ると、Fatなテーブルの項目は、それぞれの業務の画面項目に対応しており、データの生成→更新→終了に至るまでの経緯を保持するデータに対応する。
つまり、導出項目だったり、数量だったり、連番だったりする。

渡辺さんの生産管理データモデルで最も特徴的な在庫推移機能の画面では、業務が変わるたびに、在庫数量がその都度更新され、リフレッシュされる。
実際は、親画面からポップアップされた子画面で、ステータスや数量を更新すると、親画面の在庫数量がリフレッシュされる。

下記の質問はそんなデモを見た時に出た。

(引用開始)
・先ほどから画面を閉じるとひとつ前の画面がリフレッシュしてるように見えます
 最近追加した機能です。画面フォーカスが戻った時に自動リフレッシュ出来ます
 またルールエンジンも組込みましたので簡単な業務ならノンプログラミングになりました。
(引用終了)

在庫推移画面は実際に見たことがなかったので、そんな動きになるのか、とようやくイメージできた。
(レベルが低くてスミマセン)

つまり、Fatなテーブルは、各業務に必要な導出項目や更新する項目を保持するために必要であり、データ保守やデータ移行の手間を考えると、あえて、正規化しすぎないようにしているわけだ。
その分、カスタマイズもしやすいだろう。

【2-3】製造指示工程明細---●製造指示材料明細

製造指図書テーブルから、製造指示工程明細と製造指示材料明細の2つのテーブルが外部キーとして外部参照関係を持つ。
さらに、工程と品目明細のテーブル間で、「製造指示工程明細---●製造指示材料明細」という外部参照関係がある。

この意味は、原材料を「工程の始点から投入」だけでなく、「工程の途中から投入」できるようにするために、そのような関係を持たせている、らしい。
なるほど!

普通は、原材料は「工程の始点から投入」のパターンだが、工程の途中から投入する生産工程もあったりする。
そのような例外的な業務に対応できるように、故意に制約を緩めて汎用化しているわけだ。

工業簿記の総合原価計算では、「工程の始点から投入」のケースと「工程の途中から投入」のケースでは、加工進捗の計算方法が変わるため、加工費の算出が変わってくる。
つまり、この部分に対応することで、多様な原価計算パターンにも対応できるようにデータモデルを設計されているわけだ。

【2-4】発注明細●----入荷見出し

(引用開始)
発注の部分のERがすごく良くできています。
発注見出 -< 発注明細を作ります。
仕入が入ってくると発注明細ごとに仕入番号を更新することで入荷された単位で仕入れを発生させることが出来ます。
(引用終了)

僕の理解では、発注明細が複数個発生すると、そのたびに入荷処理するわけではなく、一括で処理したい。
そこで、一括処理する単位で、発注明細を束ねて、入荷処理する。
つまり、発注明細に、仕入番号という外部キーを挿入して、仕入番号の単位で入荷処理を行うように記録させる。
なるほど!

T字形ERでも、2個のトランザクションに先行・後続の関係を持たせる時、外部キーを持たせる。
また、T字形ERでは、先行のトランザクションを一括処理でまとめて、後続のトランザクションに渡す時は、親子キーの関係を持たせるが、渡辺式データモデルでは、実運用を考えて、外部キーで持たせている。
つまり、発注明細テーブルの仕入番号は最初はNULLであり、仕入という入荷処理を行うと、仕入番号が発行されてセットされる。

懇親会で実装した人に聞いたら、この部分のデータモデルはシンプルで汎用性が高いので、いろんな業務にカスタマイズしやすい。
よく考えられている、という話だった。

【2-5】ストアドプロシージャは、サーバーサイド・JavaScriptで実装する

今時、ストアドプロシージャをプログラミングするのは古いらしい。
サーバーサイド・JavaScriptで実装するが流行らしい。
確かに、サーバーサイド・JavaScriptで実装しておけば、どんなWebシステムでもクライアントアプリでも、公開されたAPI経由で自由に計算処理できる。

性能要件が気になるけれど、そこさえクリアできれば、保守性を考えると、サーバーサイド・JavaScriptで実装した方が良いのだろう。

【3】@sakaba37さんから、渡辺さんのデータモデルのようなモデリング手法に違和感がある、と聞いた。
あれは、論理モデルではない、物理モデルだから。
本来のモデリングではないのでは、と。
たとえば、オブジェクト指向モデリングならば、モデルは論理モデルを指すのであり、物理モデルはいろんな種類があるから、と。

たしかに、モデリングと言うよりも、実際に実装したシステムまで作ってしまった、みたいな感じだ。

この手の話は、以前、議論したことがあった。

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想: プログラマの思索

つまり、普通のモデリングで言われるモデルは「論理モデル」であり、論理モデルだからこそ、実装方法は色々ある。

一方、勉強会の途中で、渡辺さんの質問「業務に対するモデルの正しさはどのように判定していますか?」があがり、皆であれこれ議論して、結局、場面ごとに違うので、正しいモデルは一つとは限らないね、という話になった。
そして、渡辺さんいわく、モデリングはエンジニアリング技法の一つなので、品質やコスト、納期のトレードオフでモデルが決まるから、と言っていた。
その意図は、「モデルの判定は理想論ではなく、QCDやその時代の技術レベルの選択のすり合わせで決まるので、相対的なものである」という意味なのだろうと思う。

以前、@yusuke_arclampさんも似たようなことを言っていた。

akipiiさんのツイート: "アーキテクトは理想論を語る科学者ではなく、コストなど現実的な折り合いを付ける技術者であるわけか。RT @yusuke_arclamp: アーキテクトというのは「個別の技術論」ではなく「技術選択論(要件と技術のすり合わせ)」を語れないといかんのだけどね。"

でも、@sakaba37さんと同じく、何かすっきりしない気持ちもある。
上記の議論は、モデルのレベルを「実装モデル」に落としているために、技術選択論になっているのではないか、と。
この辺りは妄想なので、あとでまとめる。



| | コメント (0)

第16回Redmine大阪の感想 #RedmineOsaka

第16回Redmine大阪が盛況で終わりました。
講演者、参加者、スタッフの皆さん、ありがとうございました。
以下は感想をラフなメモ書き。
力尽きたので書きかけ。

【参考】
Redmine大阪 第16回勉強会 - connpass

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪: プログラマの思索

【1】参加者は約70人近く。
関西以外に、東京、名古屋、福岡、岡山など遠方から参加された人も多かった。
LTの5人のうち4人は、関西以外のエリアの人達。
それだけRedmineが注目されているのだろうか。

(引用開始)
東京から参加しました。機械メーカーの調達マネージャーでITには詳しくないため、ついて行けない場面も多々ありましたが、雰囲気も良く時間が短く感じられました。
東京でも参加したいと思います。おせわになりました。
(引用終了)

発表内容も、組込みソフトウェア開発プロセスや運用面から3.4の新機能、アンチパターンまで幅広く、色々議論できたと思う。

【2】「高信頼性ソフトウェア開発へのチケット駆動開発の適用事例」 宿口雅弘さん

組込みソフトウェア開発プロセスの機能安全という特性にRedmineを導入した事例のお話。
実際は、Redmineベースのパッケージ製品eWeaverをベースに、開発プロセスを構築したみたい。
但し、コミュニティ講演なので、製品紹介よりも、機能安全をベースにしたプロセスのお話がメイン。

Redmineベースの組込みソフト開発向けプロセス支援ツールeWeaverのリンク: プログラマの思索

イーソルトリニティ株式会社 eWeaver

昨今、IOT、インダストリー4.0、自動運転、人工知能のように、メーカーを巡る動きは激しい。
その中で、ソフトウェア品質特性の中で特に、機能安全をどのように保証するか?
もちろん、そのプロセス実装は、Excel帳票や人手でやるのは、大規模開発になるほど非常に難しくなる。

機能安全をプロセスで保証するメリットは、PL法への対処にもなる、という指摘は参考になる。
製品出荷後のクレームによる損害は、今の時代は非常に大きくなっていて、リスクも大きい。
だから、プロセスで十分に保証されているけれど、その損害は予知できないものだ、と主張できれば、損害賠償責任を免れるわけだ。

お話はソフトウェア工学がメインテーマなので面白いけれど、Redmineウォッチャーの観点では、そのプロセスをRedmineの機能にどのようにマッピングして、どのように運用したのか、という点が非常に気になる。
肝心のお話はサラリと流されてしまったので、ちょっと肩透かしかも笑

質疑応答で聞いてみると、プロセスの保証は、チケット駆動のトレーサビリティという性質を使う。
つまり、機能要件やセキュリティ要件などの要件は親チケットとし、そこから派生したタスクは子チケットへブレイクダウンする。
成果物はSVNの配下に置き、必ずチケットにSVNリビジョンとして変更履歴が残る。
話を聞くと、Officeファイルも全てSVNで構成管理する、とのこと。
確かに、この運用なら、トレーサビリティは確保できるだろう。

チケット駆動の弱点は、時系列の表現が弱い点だ、という指摘は、そういう見方もあるのか、と参考になった。
だから、eWeaverでは、タスク管理のビューとして、かんばんを採用しているわけだ。

面白いと思った点は、Wordの要件定義書にある各要件の番号から、Redmineのチケットを新規登録したり、リンクを張れること。
つまり、Redmineチケットに散らばった要件やタスクは、Wordの要件定義書に基づいて作成されて更新される。
すなわち、要件定義書がしっかり保守されていれば、Redmineと相互連携もできるし、Redmineのチケット一覧をわざわざ見なくてもいい。

【3】「乱立してるRedmineを一つにまとめる話」 堂端 翔さん

東京Redmine勉強会の再演。
今後、さらに大きいRedmine移行作業を控えている、とのこと。

【4】 @pinzoloさん、@g_maedaさんの「Redmine 3.4.0にアップグレードしよう! お気に入り改善点一挙紹介」

@pinzoloさんの資料の「おまけ」の部分が面白い。
レスポンシブテーマに対応したことが、逆に、プラグイン作者やテーマ作者は大変になった。

Ver3から、10年以上前のチケットの実装など、古いチケットが対応されてきた。
@g_maedaさんによれば、積極的に、新しいパッチはどんどん最新のターゲットバージョンに設定しているから、とのこと。

パッチ数が順調に増えている。
つまり、Redmineを機能改善したいと貢献する開発者が増えている。

マイナーバージョンアップの期間が長くなる傾向にある。

Redmineの機能改善はとても保守的。
それが逆にすごく有効に作用している。
品質が安定している。

RedmineがRails4.2に対応してから、Redmineの機能拡張がやりやすくなったみたい。
RailsのVerUpに追随している。
Rails4.2に対応するRubyのバージョンに対応しているので、1.9にも対応している。

Rails5は、Ruby2.2.2以上しか対応しないので、VerUpしたら影響が大きくなる。

【5】LT

「Location-Based Task Management with Redmine」の発表が面白い。
Danielさんは地図関係の事業をしている。
担当者が現地に行って作業するが、その作業をRedmineで管理している。

その時に、国土地理院から取得した地図と、GPSで把握した担当者の位置状況をチケット画面や担当者画面に表示して、このチケットはどこで作業しているのか、担当者は今どこにいるのか、をRedmineから把握できるようにプラグイン化したらしい。

【6】パネルディスカッション「RedmineのFAQとアンチパターン」

親子チケットのアンチパターンについて、パネラーや参加者と意見交換。
時間がなくてあまり深掘りできなかった。

WBSの最下層はタスクにする。
だから、親子チケットの最下層のチケットは必ずタスクになる。

eWeaverでも、Redmineで運用する前に、ユーザにヒヤリングしてプロセスを確定してからRedmineの親子チケットの運用を決めている。

他の資料はこちら。

| | コメント (0)

2017/03/22

日本の大企業におけるRedmineの利用事例の資料のリンク

最近、日本の大企業におけるRedmineの利用事例がPDFでネット上にかなり公開されている。
後々の自分のために、資料のリンクを貼っておく。

【例1】JAXA(宇宙航空研究開発機構)によるスパコン運用部門でのRedmine利用事例。
CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

主用途はソフトウェア開発ではなく、スパコンに関わるさまざまな運用業務の管理に使われており、課内のみならず関係ベンダーともRedmineで情報共有をしている、とのこと。
Redmineの機能をレイヤ構造で十分に分析した後で、業務へ適用した点が素晴らしい。

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

JAXAのRedmine運用に隠れている運用ルール: プログラマの思索

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

【例2】パナソニックにおけるソフトウェア開発のPJ管理の事例:
開発現場を救うプロセス改善の進め方 - SPIJapan2014

パナソニックの子会社におけるRedmineの利用事例が3つほど公開されている。
一つは、CMMIレベル4を目指して、Redmineを導入して課題解決を図っている。

改善前の状態の問題点として、下記が挙げられている。

・壮大な改善計画の立案のみが存在
・膨大な標準帳票が存在
・職人気質な優秀なメンバーに頼ったプロジェクト運営

この問題点の原因分析を読むと、日本のほとんどの企業に当てはまる問題ではないか、と食い入るように思えてしまう。

そういう問題点がRedmineを導入したことで解決の目処が経ったことを考えると、CMMIレベル4における定量データの収集・分析・是正のレベルは、Redmineのような定量的プロジェクト管理ツールという運用基盤が必須である事実を示唆しているように思える。

また、Redmineに不足した機能として、「親子チケットの関係を持った一括インポート」機能を別で実装した点も参考になる。
階層化されたWBSを一括インポートしたい意図は、WF型開発では十分にあるから。

【例3】パナソニックにおけるオフショア開発のPJ管理の事例:
海外開発拠点におけるソフトウェア開発プロセスの確立 - SPIJapan2015

こちらは、シンガポールのオフショア開発のPJ管理に適用した事例。
「ソフトウェア開発業界でデファクトスタンダードになっているRedmineを導入」という文章を読むと、そうなのか、と改めて気づく。
Redmineの適用方法として「No Ticket, No Commit」を徹底させた点がとても参考になる。

【例4】パナソニックにおける多部門連携のソフトウェア開発の利用事例:
複数部門にまたがったシステム・ソフトウェア開発プロセス改善の取り組み - SPIJapan2016

複数の部門と連携したソフトウェア品質改善のバックグラウンドで、Redmineを利用している事例。
資料のメインは、ツールよりも、組織面や運用面のお話。

【例5】島津製作所における大規模組織の内部統制へ適用した利用事例:
「効率・品質・統制」の共通課題に着目した現場主導による ITS 導入事例~OSS 運営ツールで効率的・低コストな導入を実現~ (IPA 「先進的な設計・検証技術の適用事例報告書 2016 年度版 」)

「効率・品質・統制」の共通課題に着目した現場主導による ITS 導入の効果検証~SQIP2014

ソフトウェアの品質向上に資する開発・運用現場の情報管理~現場主導によるITS導入~JASST関西2013

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

チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア: プログラマの思索

Redmineの理想と現実~RxTStudy #12 「ITS活用最前線~現場からの実践報告」の感想: プログラマの思索

@akahane92さんが中心で行われた大規模組織の内部統制の利用事例。
何度も内容は聞いているけれど、個人的にいつも気になる点がいくつかある。

一つは、ISMSやISO9001で要求されるOffice文書は、どのように構成管理されているのか?
普通は、共有ファイルサーバーに配置しているので、履歴管理されていない。
一方、SVNでOffice文書を管理するのは可能だが、SVNリポジトリが膨大なサイズになるし、大容量ファイルをコミットする時にSVNへ負荷がかかるデメリットがある。

もう一つは、チケットだけでなく、ソースやOffice文書も含めた全文検索のインフラはどのように構築しているのか?
ISMSやISO9001の内部監査では、1~2日の間に、内部監査員から要求された文書を証跡として、素早く提出して確認を取る必要がある。
その証跡が提出できなければ、正しいプロセスを踏んでいない、という印象を監査員から持たれてしまう。

つまり、障害や仕様変更などの事案に対し、それと関連付けられたチケット、ソース、Office文書を即座に検索して検索結果を得る必要がある。
そのインフラは、「No Ticket, No Commit」という手動の運用ルールに紐付けられたトレーサビリティだけで十分か?

【例5】電子楽器の商品価値を高めたモデルベース開発フレームワーク

組込みソフトウェアの派生開発、プロダクトライン型開発にRedmineを導入した事例。
プロセスよりもソフトウェア設計に力点を置いている。

「Redmineを変更管理に適用」、
「チケット駆動の大規模反復型開発」、
「コードのみならず全文書をSubversion管理とRedmine連動によるトレーサビリティ実現」
の部分がすごく気になる。

【例6】「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

Redmineをソフトウェアプロダクトラインの開発基盤として構築しようとモデル化してる、とても野心的な事例。
ソフトウェアプロダクトラインは、ソフトウェアモジュールをハードウェア製品の部品のように、共通部品と可変部品に分けて、部品を組み立てるようにモジュール生産したい、という発想。

その場合の課題は、ソフトウェアアーキテクチャを共通部分と可変部分にどのように分けるか、という点だろう。
ソフトウェアをそんなに綺麗に分けられるのか?

また、コア資産とアプリケーション資産に分別した場合、それぞれのソフトウェア資産に対する開発プロセスは明確に分けて、かつ、緊密に情報連携させるにはどのような仕組みが必要なのか?
その開発プロセス基盤にRedmineを導入した場合、コア資産とアプリケーション資産をどのようにRedmineにマッピングし、どのように運用するのか?

次回5月の第12回勉強会 - redmine.tokyoで講演していただくので、内容がとても楽しみ。

| | コメント (0)

«【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪