第13回RxTStudy勉強会の感想 #RxTStudy

第13回RxTStudy勉強会の感想をメモ。

【元ネタ】
RxTStudy #13 「Redmine再入門～達人に学ぶRedmineの徹底指南」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

【1】@g_maedaさんの講演では、Redmine初心者が必ずチェックすべき初期設定の内容と、farend_basicテーマの解説があり、すごく参考になった。

例えば、オフショア・ニアショアでRedmineを外部に公開して共有する場合、セキュリティの設定は必須だ。
「認証が必要」はON、「デフォルトで新しいプロジェクトは公開にする」はOFFにした方が安全だ。
実際、ググってみると、外部から丸見えになっているRedmineがあるらしい。
あな恐ろしや。

バージョン管理ツールのコミットログにチケット番号を記載して連携する場合、「refs」「fixes」にチケット番号を付けるやり方が普通だが、参照用キーワード設定画面で「*」を設定すると、コミットログに「#チケット番号」があるだけで自動でリンク表示してくれるらしい。
これは便利だ。

@g_maedaさん作成のfarend_basicテーマやfarend_fancyテーマは僕も便利に使っている。
お話を聞くと、チケットのコメントを削除する時に誤ってチケットそのものを消す誤操作をなくすために、枠を囲ったり、履歴を明確に表示する背景色を付けるなど、UI改善に力を入れている。
チケット更新の絶対日付表示、ページネーションのUI、チケット一覧の色分け表示などはとても便利。

Redmineを快適に使うためのおすすめ初期設定 from Go Maeda

【2】@sakaba37さんのプロセス支援のお話。
チケット駆動開発は、WF型開発やAgile開発の枠を広げようとする箇所で適用すると上手くいくのでは、という指摘は、なるほどと思う。
あくまでも、色んなプロセスの支援ツールなのだ。

【2-1】この後に@agilekawabataさんの講演もあったが、興味深い話もあった。
大企業で約1千人のユーザがRedmineを使っている現場を見ると、RedmineのあるプロジェクトはWF型開発、別のプロジェクトはアジャイル開発で使い分けて運用している所がある。
実際、Redmineでは、プロジェクトごとにワークフローやカスタムフィールドを使い分けれるし、各種の機能も選択できる。

つまり、一つの企業の中の開発案件に対し、それぞれの特徴を生かして、Redmineプロジェクトごとに開発プロセスを割り当てて、別々に運用することができる。

しかし、経営層や上司の観点では、WF型開発やアジャイル開発のプロジェクトを横断して、横串でプロジェクトの進捗状況を把握したい要望がある。
そこで、Redmineでは、プロジェクトの階層構造を当てはめれば、子プロジェクトのチケットを親プロジェクトで集計して見ることもできる。

すなわち、Redmineは、色んな種類のプロセスがあっても、別々にプロジェクト単位に管理できるし、親子プロジェクトを使って進捗状況を集計して横断的に見ることもできる。
したがって、Redmineは柔軟な進捗管理も可能だし、多様なプロセスをそれぞれに管理できる柔軟さも持っているのが面白い。

Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - from Makoto SAKAI

【3】僕の話は、Backlogsプラグインを使ってScrumを運用できるよ、という話。
実際に使ってみようと試しているのだが、Scrumのプロセスやロールごとの操作をRedmineの機能に上手くマッピングできているのがすごく面白い。

話が駆け足になってしまい、「リリース」という機能の詳細を説明できなかったけれど、「リリース」というBacklogsプラグイン機能は、上手く使えば、1日～1週間の短いリリースサイクルにも適用できる。
例えば、プロダクトバックログにあるストーリーを「リリース」ごとにカテゴライズして分別し、「リリース」にあるストーリーをいくつかの「スプリント」に割り当てて、順次リリースしていくように運用すれば良い。
そうすれば、JiraAgileのように、リリースサイクルが極端に短いアジャイル開発にも適用できるだろう。

【第13回RxTStudy勉強会】Redmine BacklogsプラグインでScrum開発！～Redmineでアジャイルに開発しよう from akipii Oga

【4】LT3人も含めて、パネルディスカッションを行った。
今回も経験者のお話がすごく興味深かった。

【4-1】「Redmineのインストールは超簡単」「すごく難しい」という質問に対し、@g_maedaさんいわく、bundlerで自動的にgemsがインストールされるので、なぜインストールが難しいのか、分からない、とのこと。
Rubyistの人は、問題ないみたいだ。

しかし、他の方に聞くと、WindowsにRedmineをインストールする人がすごく苦労されているようだ。
たとえば、WindowsにBitnamiでRedmineをインストールできたものの、チケット数が既に10万近くになり、性能が悪くなっている、というお話もあった。
また、社内ネットワークがボトルネックになっている、という話もあって、共感できる部分があった。

【4-2】「チケット管理のルールを事前に説明会を開いて説明する」「自然に馴染んでいく」という質問に対し、やはり「事前に説明していく」という人達の方が多かった。

@g_maedaさんいわく、社内のメンバーでRedmineの操作に慣れていない人がいるし、バイトの人が来ていると、先生に断りなくチケットを作って良いか、と聞いてくることもあるので、事前に説明している、とのこと。

【4-3】@agilekawabataさんいわく、ボトムアップでRedmineのチケット管理のルールを改善していく場合もある。
例えば、ある企業では、事業部ごとにRedmineサーバーが立っているので、社内にRedmineインスタンスが20個以上もある。
つまり、各Redmineは各事業部ごとに、独自のワークフローを作り、運用している。

しかし、全社で一つのRedmineで管理していこうという雰囲気が出てきて、その時に、各Redmineのワークフローを整理しようとし始めた。
すると、各Redmineのワークフローは似ているものがあり、それらをリファクタリングしながら、全社で統一的なワークフローを整備していく流れが出ている、と。
つまり、20個以上のRedmineごとのワークフローをリファクタリングすることで、全社共通のワークフローを標準プロセスとして抽出することができるわけだ。

この話は、標準プロセスをトップダウンで押し付けるのではなく、ボトムアップにプロセスをリファクタリングしながら標準プロセスを整備していくやり方もある、という指摘。
そういう考え方がすごく面白い。

RxSstudy第13回パネルディスカッション「Redmine再入門」 from akipii Oga

他にもLTで、「営業マンのRedmineの使い方」「工場でのRedmineの使い方」の事例もあり、参考になる話が多かった。
プラグインを24個も入れている点がすごく興味深い。

ある工場のRedmine from Kohei Nakamura

持ち運べるRedmineの構築例紹介 from Yutaka KOGURE

ブログを書き続けることの意味と効果

お知り合いの方から、こんな質問を受けたので、自分の考えを書いておく。
ラフなメモ書き。

【1】質問内容：
「２日に１度のペースで記事を書かれており、更新頻度も質も高いですが、どうやったら更新頻度を高めて、記事の質も高められるのでしょうか？（書き方のコツなどあれば知りたいです）」

こんなに書き散らし続けているBlogに読者がいるのがとても嬉しい。
以下、自分の考えを書いておく。
たぶん、そんなに独自性はないと思う。

【2】動機を大切にする

【2-1】ブログは日記に近い。
何かを書こうとする時、やはりパワーが要る。
僕の場合、ソフトウェア開発の仕事にすごく不満や疑問をずっと持ち続けている。
それが動機になっている。

なぜ、こんなに残業が多いのか？
なぜ、ソフトウェア開発はクリエイティブな仕事と言われるのに、実際は、大量のメンバーを投入して労働集約的にゴリ押ししようとするのか？

本来のあるべきソフトウェア開発プロセスは何なのか？
ソフトウェア開発には、どんな技術や思想が重要なのか？

ポジティブな動機と言うよりも、ネガティブな動機の方が多い。
そこから、問題意識を持ち、あるべき姿を調べたり、考えたりして、それをメモ書きしていく感じ。

【2-2】もう一つは、新しい技術やアイデアをメモしておくこと。
以前はRSSのフィード記事、最近はFacebookのタイムラインで流れる記事を見て、これはクリップしておきたい、と思う記事や内容をBlogにメモしている。
僕の場合、記事の内容にある技術やプロセス、思想は完全に理解できてなくても、まずはBlogに感じたこと、疑問点を書いておく。

Blogなら、外出先や会社でも見れるので、その記事を何度も読み直したり、調べたりして、理解を深めることもできる。
Blogが紙の日記よりも良い点は、リンクが貼れることだ。
Blogはリンク一覧だけでも有用だ。
そのリンクを辿ることで、たくさんの情報に触れることができる。

【2-3】僕の考えでは、Blogは日本人に向いたWeb構造を持つと思う。
枕草子や徒然草のように、日本人は古くから日記形式で記録を残してきた。
日本人には、日記という形式が向いているのではないか、と思う。

【3】メッセージを明確に持つ

【3-1】文章にはメッセージが重要。
自分の意見や主張を明確にすることが大事。

野口悠紀雄さん著の「「超」文章法」の最初にこんな事が書かれている。

「仕事を効率的に進めるには、書類の整理をうまく行う必要がある」はメッセージではない。
「書類は内容別に分類するのではなく、時間順に並べるのが良い」がメッセージだ。

なかなか明確なメッセージは書きづらいけれど、自分の意見や考えを明確にする、という作業は、他人と議論する時にすごく重要だ。
自分の立場や考えを明確に持つからこそ、議論が深まり、問題の本質が見える時があるから。

【3-2】ブログを何度も書いていると、似たような構造の文章を書く時がある。
僕の場合、問題の提示→解決の方向性→効果や課題　みたいな流れをよく書いていると思う。

例えば、「勝つための論文の書き方」によれば、「？から始まり！で終わる」とストーリーが流れるように書ける、とある。
確かに、疑問点や問題意識を最初に提示すると、それを解決するような考えを書きやすく、それをまとめると、結論やメッセージを出しやすくなる。

問題の提示は、そんなに難しいものを出す必要はない。
むしろ、当たり前と思っていることに対して、疑問を投げかける方がいいと思う。

論文作成の技法part1～論文の構造: プログラマの思索

論文作成の技法part2～論文作成の観点 : プログラマの思索

【3-3】ブログを何度も書くと、同じような接続詞を何度も書く時がある。
接続詞はすごく重要だ。
文章の流れが分かりやすくなるだけでなく、相手に、次はこんな流れになるのですよ、と事前に提示することにも使えるからだ。

僕の経験では、「では」「そこで」を大切にするようにしている。
「では」を使うと、現状に対し、こんな問題が提示できるのだが、皆さんはどう思います？みたいに使う。
「そこで」は、自分はこんなアイデアを考えている、するとこんな効果が出るのでは、みたいに使う。

この二つはなかなか使いこなせないけど、上手く使いたいと思っている。

また、「つまり」「すなわち」も多用する。
一つのアイデアや意見を、他の言葉で言い換えたり、他の状況で置き換えたりする時に使っている。
僕の場合、「つまり」「すなわち」を使いながら、自分の考えを深く掘り下げている感じ。
でも、多用しすぎると、文章がくどくなる感じ。

英語なら「that」に相当するから、自然に使えると思う。

【4】BlogはSNSのホーム

【4-1】「必ず結果が出るブログ運営テクニック100 プロ・ブロガーが教える“俺メディア"の極意」にも書かれているが、Webではログが重要。
ログはGoogle検索でいくらでも欲しい情報にアクセスできるし、ハイパーリンクがあれば、たくさんの記事と関係性を持てる。
Blogは記事(ログ)の蓄積の集合体なので、記事が多いほど、資産になる。

逆にTwitter、Facebook、LineなどSNS全盛だけど、それらの記事はタイムラインに流れて埋もれてしまう。
単に消費されるだけ。

最近は、SNS全盛だからこそ、Blogの価値が再認識されていると思う。
Blogが自己紹介のツールとして使えるのだ。
また、SNSにBlogの記事をリンクすれば、Blogへの流入も多くなり、相乗効果が上がる。

【4-2】Blogの記事を貯めておけば、色んな効果が出てくる。
僕の場合、Blogの記事は講演の元ネタになるし、最終的には出版した書籍のアイデアの宝庫になっている。
蓄積された思索やアイデアが残っているからこそ、色んな講演や記事執筆がやりやすくなる。

本屋でよく「書き下ろし」という文庫本を見かけるけれど、あのスタイルはすごく難しいと思う。
1冊の本は20万字必要と言われるが、Inputの情報は少なくともその10倍以上は必要なはず。
それらを圧縮して濃縮して、一つのアウトプットが出てくる。
ゼロから作り出すのはすごく大変なはずだ。
だから、日頃からたくさんのアイデアを貯めておかないと、ライターという職業はやれないと思う。

【4-3】個人的には、倉貫さんのBlogはすごいなあ、といつも思う。
「受託開発はディフェンシブ」「アジャイル開発では当初に想定した機能を”全部”つくらない」など、問題の本質を見抜いた記事をBlogでたくさん公開されている。
優れた記事をBlogでたくさん公開されているからこそ、たくさん講演できて、出版もできているのだろうと思う。

Social Change! ソニックガーデン SonicGarden 倉貫義人のブログ

上記のアイデアを今後ももっと煮詰めたいと思う。

「チケット駆動型進捗管理システムによるカーナビゲーション開発管理の効率化」のSQIP2012講演資料

「チケット駆動型進捗管理システムによるカーナビゲーション開発管理の効率化」のSQIP2012講演資料が公開されていたのでメモ。
資料はPDFでダウンロードできる。

【参考】
チケット駆動型進捗管理システムによるカーナビゲーション開発管理の効率化 | SQiPソフトウェア品質ライブラリ

はてなブックマーク - チケット駆動型進捗管理システムによるカーナビゲーション開発管理の効率化

【1】事例は、SQIP2012だから3年前の、デンソーという会社のチケット駆動開発の経験事例。
内容は、Jira＋Subversionを使って、チケット駆動開発を導入し、アジャイル型開発＋WF型開発の合わせ技でプロセス改善を試みた、というストーリー。

(引用開始)
我々が開発しているカーナビゲーションは、ソフトウェアの開発規模が1000万行を超え、1000人以上が関わる大規模製品となっている。
開発を取り巻く環境として、短納期開発、低コスト、仕様が固まらないなどの外部要因を抱えおり、要件変更が頻繁に起こる。
これは従来の製品開発で適用されているウォーターフォール型開発では、手戻りを発生させる要因となる。
要件変更が頻繁に起こる開発でも、手戻りの影響を減らす新たなプロセスの構築が必要であると考えた。

そこで、変更にすばやく適応することに主眼をおくアジャイルソフトウェア開発に着目した。
一般的にコミュニケーションを重視するアジャイル開発は、大規模開発には不向きとされている。
しかし、開発対象を細かな機能に分割し、開発のスコープをコミュニケーション可能な規模にする事で、アジャイル開発の適用が可能と考えた。

ウォーターフォール型開発にアジャイル的な要素を組み込む際に、進捗管理システムにチケット駆動型管理システムを採用した。
機能の開発計画を管理する計画チケットと、工程で発生する作業をコミュニケーション可能な粒度で管理する作業チケットに層別した。

本発表では、上記要件を備えたプロセスの構築と、それを製品開発に適用するためのプロジェクト進捗管理システムについて報告する。
(引用終了)

【2】上記のデンソー様の資料を読むと、どの箇所にチケット駆動開発を適用すると効果が出るのか、という点がよく考えられている。
社内標準のWF型開発プロセスにアジャイル開発の良さを適用するために、チケット管理ツールを上手く導入して運用したわけだ。
Jiraであろうが、Redmineであろうが、同じような効果を得たに違いない。

【2-1】ところで、最近、僕が「チケット駆動開発を実践したら、開発のリズムやアジャイル開発のプラクティスは、自然に出てくるものだ」と話したら、@sakaba37さんとこんな議論する時があった。

「チケット駆動開発の効果は、Redmineなどのチケット管理ツールを導入して自然に出てくるものではなく、問題や適用箇所を事前にきちんと把握しないと効果が出ない」
「チケット駆動開発の効果を自然に感じられず、失敗事例が多いとTwitterでよく見かけるのは、アジャイル開発やPJ管理の知識を持っていない前提で、いきなりRedmineを導入してしまうからだろう」

[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -: ソフトウェアさかば

[#TiDD] ウォータフォール型開発の問題点とチケット駆動開発 #seakansai: ソフトウェアさかば

その指摘を受けて、チケット駆動開発が自然に感じられない理由が別の所にあると気づいた。
僕はアジャイル開発を実践したくて、目の前にあるRedmineというツールを使ったら、既知のアジャイル開発のプラクティスがRedmineの機能に上手く当てはまると分かったが、これは、そういう意識を持っていたから気づいただけ。
普通は、そんな観点を持たないし、そういう発想も思いつかない。

そんなことを考えると、チケット駆動開発と今まで知られているソフトウェア工学の知識を比較したり、チケット管理ツールの適用範囲をまとめてみることが重要ではないか、と思う。

「ビヨンド ソフトウェア アーキテクチャ」は買い？

「ビヨンド ソフトウェア アーキテクチャ」がもうすぐ販売されるのでメモ。
興味がそそられる。

【参考】
ビヨンド ソフトウェア アーキテクチャ（LukeHohmann 岡澤裕二 和智右桂） ｜ 翔泳社の本

おおお『Beyond Software Architecture』訳されたのか！ これはとても良い本でした。 - t-wada のコメント / はてなブックマーク

(引用開始)
「アーキテクチャ」について技術的な観点から書かれている本は数多くありますが、ビジネスの視点からシステムを商品として見た時に考えるべきことを教えてくれる本が、実はありませんでした。
本書は、アーキテクチャにおけるビジネス（マーキテクチャ）と技術（ターキテクチャ）をつなぐ架け橋として、情報システム部の方全員に読んでほしい本（情シス必読書）です。
エンジニアにとっては、マーケティングの基礎を学ぶ上でも役に立ち、かつ、技術面でのアーキテクチャ論としても、経験豊富な著者の実体験に根ざす優れた考察に富んだ一冊となっています。

原書は2003年にMartin Fowlerシグネチャシリーズの一冊として刊行されました。Jim Highsmith、Mary Poppendieck、Ed Yordon、Craig Larman他から多数の賛辞が寄せられています。著者のLuke HohmannはOOPSLAやUML Worldの常連スピーカーとして、QUALCOMMなどを経て現在はConteneo,Inc.のCEOに就いていますが、それ以前には全米フィギュアスケート選手権のジュニアチャンピオンでもあった異色の存在でもあります。

最後に、訳者より一言「情シスの方はアジャイルやスクラムもよいですけど、こういうアーキテクチャのこともきちんと考えてみませんか？」
(引用終了)

(引用開始)
目次

第1章ソフトウェアアーキテクチャ
第2章プロダクト開発入門
第3章マーケテクチャとターキテクチャ
第4章ビジネスとライセンスモデルの共益関係
第5章インライセンステクノロジー
第6章可搬性
第7章デプロイメントアーキテクチャ
第8章統合と拡張
第9章ブランドとブランド要素
第10章ユーザビリティ
第11章インストール
第12章アップグレード
第13章コンフィギュレーション
第14章ログ
第15章リリース管理
第16章セキュリティ
補遺A：リリースチェックリスト
補遺B：戦略的プロダクトマネジメントのためのパターン言語
(引用終了)

本棚を見返すと、和智さんの翻訳本はほとんど購入している。
「エリック・エヴァンスのドメイン駆動設計」「組織パターン」「エッセンシャル スクラム」「実践テスト駆動開発」然り。
どれも分厚くて、何度も読み直して咀嚼し直すたびに、新しい発見がある。

今度の本もすごく楽しみだ。

翻訳された本の分野を見ると、アーキテクチャ設計やアジャイル開発にフォーカスされている。
僕が興味を持っている分野にドンピシャリだなと思ったりする。

「ビヨンド ソフトウェア アーキテクチャ」でググってみると、下記のPDFが見つかる。
目次がそっくりなのだが、関係あるのかな？

/ - alimnova - Grupo de trabajo ingenieria de software - Google Project Hosting

第43回IT勉強宴会「生産管理再入門－ＭＲＰを超えて」の感想～在庫監視推移方式はTOCの発想に似ている

第43回IT勉強宴会「生産管理再入門－ＭＲＰを超えて」の感想をメモ。
在庫監視推移方式はTOCの発想に似ているなあ、と初めて理解した。

以下、渡辺さん他の講演者の話をメモしながら、自分の考えもメモ。
ラフなメモ書き。

【参考】
生産管理再入門－ＭＲＰを超えて　＜第43回IT勉強宴会＞ : ATND

在庫は悪なのか善なのか: プログラマの思索

僕が理解した範囲で、在庫監視推移方式の方式設計・生産工程の設計・組織体制の内容をまとめてみた。

在庫監視推移方式の概念イメージ from akipii Oga

【1】MRPと在庫監視推移方式の方式設計の違い

【1-1】渡辺さんいわく。
生産管理にMRPを導入して成功している日本の製造業は少ないのではないか。
MRPは、部品表や工程情報、販売情報を元に、計画を立てた後に一気に受払(入出庫)や在庫推移、勧告オーダーを作成する。
だから、夜間バッチを行なっても朝になっても終わらない、ということがよくあった。

しかも、勧告オーダーが曲者。
MRPはご丁寧に、在庫推移がこういう状態になるから発注量と発注日はこうしたらいい、と勧告してくれるが、需要変動や工場のトラブルなどで、すぐに使えなくなる。
MRPのような計画主導のシステムは、融通が効かないので、実際の現場では正直使えない。

しかし、日本の現場を見てみると、彼らは販売計画を元にMRPを何度も実施しては、在庫推移の情報を出力している。
その理由は、在庫推移の情報を見て、人間が判断して、入出庫や発注の量を制御するように指示しているからだ。
つまり、MRPは在庫推移のシミュレーションを出力する用途に使い、最終的には人間の判断で発注や生産指示を出すようにしているのが分かった、と。
だから、その発想を生かして、MRPではなく在庫監視推移方式を編み出した、と。

【1-2】では、MRPと在庫監視推移方式では、どのように方式設計が違うのか。

MRPは、所要量の計算から勧告オーダーまで、一つのトランザクションとしてバッチ処理で行う。
つまり、最後の処理が終了するまで、処理が続くので、すごく時間がかかる。

すなわち、方式設計の問題は、トランザクションをどこで分割すべきか、という問題に置き換えられる。

在庫監視推移方式では、所要量の計算＋受払予定の計算と、在庫推移の再計算の二つでトランザクションを分ける。
つまり、受払い予定の計算の結果を元に、人間が判断して、Inputの情報を入れ直して、在庫推移の再計算の実行を人間が指示する。

この方式設計に至った理由は、現場の人がMRPを在庫推移のシミュレーションのために使っている風景を元に、日本風にアレンジした結果である、と。

このやり方は、なるほどと思う。
トランザクションスコープと実際の運用フローが対応するように、バッチ処理を再設計したわけだ。

【2】在庫監視推移方式に至るまでの在庫管理の制約条件

実際に在庫監視推移方式を実現している某製造業の中の人いわく。

制約条件としては下記がある。

・受注を元に生産しているので受注生産。
　製番管理もしている。

・MTS(Make To Stock)として、製品(完成品)を在庫として持つ
・製造は内製指向。国内の工場で作っている。
　だから、固定費が高い。
　また、工場の工程能力、工程負荷に在庫量がすごく関係する。

・需要の季節変動が大きい
　夏場はすごく売れるが、他の季節はそれほどでもない。

上記のような前提条件を見ると、受注生産と言いながらも、マーケットや顧客の要望がすごく我がままなために、生産にすごく苦労していることが伺われる。

「在庫は悪」と言われるが、売りたい時に製品がなければ販売機会を失って、売上を確保できない。
つまり、最低限の在庫は必須。
全ての在庫が悪者ではない。

必要な時に必要なだけの在庫を持っておき、売上を確保できるような生産工程の仕組みが必要になってくるわけだ。

特に昨今は、生産量の変動が大きいので、この辺りの調整が難しいのだろうと思う。
たとえば、iPhoneやiPad、AppleWatchのように、特定の期間に爆発的に販売しないといけない製品や部品を製造するメーカーは、すごく大変なはずだ。

【3】在庫・出荷・操業度の推移

中の人いわく。

製造の戦略としては、二つある。

一つは、操業度はあまり変動させない。
これには理由がある。

工場が2交替制で昼と夜の両方で作業者に働いてもらうために、人件費がかかる。
受注量が減ったからと言って、作業者をクビにしたり、労働期間を短くすることは、今の日本の法律では難しい所があるからだ。
また、国内に工場を持っているために、固定費が高い。
したがって、工場の操業度を最低限確保して、常に売上を確保するようにしなければ、赤字になりやすい。

もう一つは、閑散期に製品在庫を持って繁忙期に備える。
出荷量は繁忙期と閑散期で変動が大きいからだ。

だから、在庫をいつどれだけ保持すべきか、という生産計画がすごく重要になってくる。
無駄に在庫を持てば、倉庫の費用など無駄な費用が発生するが、かと言って、繁忙期に生産量を大幅に増やすのは難しい。

たとえば、2交替制を3交替制にすると、勤務する作業者のチームは4チームから6チームに増えて、その分人件費などが売上以上に膨れ上がる時もある。
つまり、繁忙期に生産量を一気に増やせない事情もあるのだ。

【4】生産工程の設計

生産工程の戦略としては、下記がある。
①ボトルネック工程(生産能力が最低)を故意に作る
②ボトルネック工程は、最初の工程1に作る
　(工程1がフル稼働。工程2以後は流すだけ。)
③ボトルネック工程の操業度を計測すれば、製品在庫量を制御できる
　ようにKPIを設定しておく
　(在庫∝ボトルネック工程の操業度∝ボトルネック工程の生産能力)

つまり、ボトルネックの工程を故意に作るのがポイント。
これは、TOCの発想と同じだ。
ボトルネックとなる工程が、時系列で移動しないように、必ず固定させて、そのボトルネック工程さえ監視しておけば、必要な生産量を確保できるような仕組みにしておく。

すなわち、ボトルネック工程があるからこそ、生産工程を完全にコントロールできるわけだ。

【5】在庫監視推移方式を実現する組織体制

中の人いわく。
基本は、需給管理センターみたいな需要と供給を調整する部署があり、受注担当者と生産計画担当者が協働で生産計画を作り、工場に生産指示を出す。
受注担当者は20名と多く、有期契約労働者が担当する。
生産計画担当者は数名で、工場で働いた経験のある人が担当する。

そして、センター内部では、受注担当者の精算指示を生産計画担当者がチェックして、工場の操業度や工程負荷を見ながら、工場の現場に見合った生産指示に変更する。

在庫管理担当者を組織に持つというよりも、生産計画の部門が担当して実施しているのが参考になる。

【6】在庫監視推移方式のまとめ

【6-1】在庫監視推移方式はMRPを使わず、人間系の運用でフォローする。
日本では、MRPを何度も回して在庫推移の結果を見たがる風景が多い。
そこで、MRPの勧告オーダーは使わず、人間が判断して発注する方針で在庫監視推移方式が生まれた。

【6-2】工場の操業度を保つ方が在庫を持つよりも重要。
内製指向で固定費(人件費・高価な機械)がかかるので、まず売上確保しなければならないから。

【6-3】故意にボトルネックの工程を唯一つに持たせる。
TOCと同じ発想だ。

ボトルネックの工程の操業度を見ながら、生産指示して製品在庫を持つようにする。
在庫監視推移方式で、発注する品目の数量を調整するわけだ。
つまり、「在庫∝ボトルネック工程の操業度∝ボトルネック工程の生産能力」という関係があるのがミソ。

佐野さんに聞くと、プロセス系(例：焼く・印刷するetc.)はボトルネックの工程を作りやすいらしい。
逆に、組み立て系(例：家電製品、自動車)はボトルネック工程を作りにくいのでは、と。

【6-3】組織体制を在庫監視推移方式に合わせるのが重要。
受注担当者と生産計画担当者が協働して、発注・生産計画を作る。
工場は生産指示を受けて、操業度の変動なしで働く。
だから、営業は顧客から早めに受注の内示や生産計画をもらうように動く。
実は、需要変動が大きいので、顧客も早めに発注量を提示してくれる事情もあるらしい。

【6-4】在庫監視推移方式は中小企業でしか使われないのではないか、という僕の質問に対し、中の人いわく。
日本の現場ではMRPはまともに使われている所はほとんどない。
むしろ、MRPを在庫監視推移方式みたいに使ったり、MRPそのものを使わずに、在庫監視推移方式を手作りで作っている所が多いのではないか、と。

システムに計算させて、現実に合わない勧告オーダーが出されるよりも、人間が判断して調整する方が速いし、精度も高い。
こんな事情を聞くと、日本人特有のすり合わせ技術、阿吽の呼吸でやる方が効率的、ということなのだろう。

すごく勉強になった。

Redmineで会議室の予約管理を行えるプラグインredmine-schedular

Redmineで会議室の予約管理を行えるプラグインredmine-schedularを見つけたのでメモ。

【参考】
pochi/redmine-schedular ・ GitHub

(引用開始)
RedmineでGoogleCalendar風のUIを利用して、予約管理を行うプラグインです。 数量が決まっている予約項目（会議室や限られたライセンスなど）を管理することができます。
(引用終了)

【1】インストール方法
Windows7＋JRuby＋Redmine2.6.5にインストールしてみた。

git clone https://github.com/pochi/redmine-schedular.git
move redmine-schedular schedular

jruby -S bundle exec rake db:migrate_plugins RAILS_ENV=production

但し、下記ソースに日本語が混じっているため、「invalid multibyte char (US-ASCII)」というエラーが出る。
日本語を英数字に変更すれば問題ない。

schedular/init.rb
schedular/db/migrate/012_create_schedular_custom_lists.rb
schedular/app/models/license_count.rb

【2】Redmineの「カレンダー」機能はほとんど使わないので、カレンダー機能を使って何かできないか、と考えていた時に、上記のプラグインを見つけた。
実際は、Redmineのカレンダー機能とは別に、会議室の予約を行えるカレンダー画面を別途用意している。

会議室やライセンスの名前、ライセンス数(＝会議室を予約できる最大数)を事前に登録しておくと、予約カレンダー画面上でポップアップ画面から予約登録できる。
もちろん、時間帯を指定できる。

Redmineのカレンダー機能は、未完了チケットの開始日・終了日を元に期間表示している。
しかし、実際は大量のチケットが表示されるだけで、あまり使い勝手が良いとはいえない。

個人的には、カレンダー機能はもっと使い道があると考えている。
例えば、CRMのように、営業マンのタスク管理に使う場合、その日のスケジュールを入力できるように、その日の時間帯を指定して入力できるようにしたい。
そうすれば、カレンダー機能を見れば、その人の1日のタスクが見える化される。

但し、プロジェクトに10人、50人のようにメンバーが多いと、カレンダー画面が見えにくくなるので、週表示するとか、人別・グループ別に表示する、などのカスタマイズが必要になるだろう。

Redmineで余り使われない機能として「カレンダー」の他に、「文書」「ファイル」「フォーラム」などがあるが、これらの機能は別の使い方を提案して、もっと使い勝手が良いように機能改善できる余地があるだろう。

今後も、Redmineの機能改善について考えてみる。

RedmineへのファイルアップロードをFTPファイルサーバーに置き換えるプラグインFTP File Server Plugin

RedmineへのファイルアップロードをFTP File Serverに置き換えるプラグインFTP File Server Pluginを見つけたのでメモ。

【参考】
jrupesh/file_servers ・ GitHub

FTP File Server - Plugins - Redmine

Redmineのアジャイル開発向けプラグイン - torutkの日記

ソースや設計書はGitやSVNなどのバージョン管理ツールの配下に置くだろうが、提案書や進捗報告書のように、一時的に作るドキュメントは共有ファイルサーバーに配置したくなる。
管理資料、warファイルは履歴管理の対象でないからだ。

でも、共有ファイルサーバーに配置すると、ファイルパスが忘れがちで、大量のドキュメントが散在してしまい、死蔵されてしまいがち。

そこで、Redmineの「ファイル」機能をFTPファイルサーバーで代用する方法が考えられる。
RedmineのFTP File Server Pluginを使う利点は、FTPファイルサーバー上のドキュメントのリンクをチケットやWikiに貼れることだろう。

ふりかえり、レビュー記録、顧客とのやり取りなどをチケットやWikiに記載する時に、Redmineの「ファイル」機能でアップロードされたドキュメントにリンクを張っておけば、経緯や変更理由をたどることができる。
リリースに至った経緯や変更理由は、たくさんの議論ややり取りに埋もれているので、コミット履歴の途中にそれらのリンクが欲しいのだ。

また、RedmineのFTP File Server Pluginの他の利点としては、アップロードされたドキュメントはRedmine上で一元管理できるので、消滅される危険性も減る。
ドキュメントに、Redmine上で説明文のコメントを付けておくと、ドキュメントの内容が何であるか、をすぐに判断することもできる。
つまり、一時的な管理資料やドキュメントも、Redmineで一元管理してしまえばいいのだ。

RedmineのFTP File Server Pluginを見ると、RedmineプロジェクトごとにFTPファイルサーバーを指定できるようなので、開発チームごとにFTPサーバーを分けてもいい。
共有ファイルサーバーはすぐに容量が爆発しやすいので、FTPファイルサーバーを分割しておくと使い勝手も良いし、セキュリティも良くなるかもしれない。

Redmineの「ファイル」「文書」機能は正直使いやすいとは言えないので、こういうプラグインの発想を取り込んで機能拡張されるといいな、と思う。

CSV形式のデータをSQLを使って解析する方法

CSV形式のデータをSQLを使って解析する方法があったのでメモ。

【参考】
Download and Install

Linux - CSV形式のデータをSQLを使って解析する - Qiita

Text as Data - q によるテキスト（CSV, TSV など）データの SQL クエリー操作

WindowsでもLinuxでも、qコマンドを入れると使える。
但し、UTF-8のCSVがデフォルトなので、MacやLinuxの方が使いやすいだろう。

実際に試してみたら、CSVをあたかもRDBのように見なして、SQLでいくらでもデータを抽出したり、整形できる。
これは便利だ。

データ解析をR言語で試すアイデアもあるが、SQLの方が慣れているので、使いやすい。
上記の記事では、日毎の売上集計、商品売上ランキングなどをSQLで出力する例がある。
簡単なSQLだけど、経営分析とか、プロジェクト管理におけるちょっとした実績集計処理に使えそう。

色々試してみる。

テストはソースコードの冗長化

「テストはソースコードの冗長化」という記事を見つけたのでメモ。

【参考】
テストというのは、ソースコードの冗長化だと思う - きしだのはてな

「ぼくはテストについて「同じものが作れるならテストが少ないほうがエライ」というのだけど、冗長化であると考えるとわかってもらいやすいのではないか。」

こういう発想があるのか。
冗長化にコストをかけれるぐらい、冗長化に価値がある場合と同じか。
品質とテストのコストのトレードオフ。

ユースケース駆動ではなくロバストネス駆動開発？

「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。

【参考1】
天使やカイザーと呼ばれて ≫ ロバストネス駆動開発？

天使やカイザーと呼ばれて ≫ ロバストネス図113枚!!

OOAD講座：第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking

ロバストネス図の使い道: プログラマの思索

ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。
この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。
確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。

ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。
単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バッチ処理があったりすると、ラフな設計がいるのだろう。

【参考2】
ソフトウェア開発の匠（1）：「ITエンジニアは職人気質を取り戻すべき」 (2/3) - ＠IT

ソフトウェア開発の匠（1）：「ITエンジニアは職人気質を取り戻すべき」 (3/3) - ＠IT

ユースケースの疑問: プログラマの思索

UML再考: プログラマの思索

ユースケースの善し悪し: プログラマの思索

でも、萩本さんの記事によれば、「ロバストネス分析に多大な工数をかけたが成果が出ない」という問題もある。

(引用開始)
ロバストネス分析から、シーケンス図などを使って動作検証を図り、分析モデルを作り上げる作業までには多くの工数を要した。
しかし、その結果作成された分析モデルは設計モデルにつながりにくく、何のためにシーケンス図などを使って検証したのか、作成したエンジニアたちにも分からなかった。

（1）ユーザーも開発者も理解しづらい産物を作りかねない
（2）分析モデルを作るまでに多くの工数を要する
(引用終了)

オブジェクト指向分析(OOA)の弱点は、分析モデルと実装モデルの乖離があるために、実装モデルに辿り着くまでの工数が大きくかかることだろう。
分析麻痺症候群に陥りやすい弱点があるのではないか。

概念モデル→論理モデル→物理モデルみたいな流れだと、中間成果物がやたらと増える。
しかもその成果物の保守も大変。

ロバストネス図がユースケースとクラス図の間を結ぶミッシングリンクであることは分かるが、仕様変更やソース修正と同じタイミングでロバストネス図も保守していくのは結構大変だ。
つまり、ロバストネス図も設計書やソースと同じく、構成管理の配下に置くべきである。
しかし、構成管理と連動したモデリングツールは結構使いづらい。

但し、astahは個人的には設計のスケッチツールとして使いやすいし、Subversionと連携して構成管理も可能だ。

【3】ロバストネス駆動開発は、個人的には結構イケているのではないか、と思ったりする。
簡単に書けるし、書いていくうちに、処理の粒度に気づいたり、他の人とのコミュニケーションにすぐに使えるからだ。

もう少し考えてみる。

WF型開発にチケット駆動を取り入れる時の考え方

アダプタブルWFや補完チケット方式について、考えたことをラフなメモ書き。

【参考】
「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOL

ソフトウェア開発の匠（3）：「現状のソフトウェア開発は間違っていないか？」（プロセス編） (3/3) - ＠IT

ソフトウェア開発の匠（4）：アジャイル開発と反復開発の落とし穴 (2/3) - ＠IT

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

裏プロセスは並行プロセス: プログラマの思索

【1】普通のSIなら、社内標準プロセスとしてWF型開発がガッチリ決まっており、アジャイル開発を取り入れる雰囲気すら無いだろう。
しかし、アジャイル開発のプラクティスは部分的に取り入れることはできるし、その効果を上げることもできる。

同様に、チケット駆動開発をWF型開発に部分的に導入して、チケット駆動の良さを実感したい、という思いもあるだろう。
チケット管理は障害管理の一つの手法と思えば、そんなに大層な問題ではないからだ。

【2】では、WF型開発のどこにチケット駆動を取り入れると成功する確率が高いのか？

その問題を問うた時、「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JSOLの記事がすごく参考になる。

(引用開始)
私がウォーターフォール開発での(チケット駆動開発の)適用として取り組んだものには大きく2つある。
（1）ウォーターフォール開発でも内部にある小さな開発サイクルでの適用　
と、
（2）プログラム改訂に関係するタスク以外のタスクや情報のチケット管理
である。
(引用終了)

【3】WF型開発プロセス内部にある小さな開発サイクルでの適用　

一つは、プログラム修正、自動テスト、自動ビルド、リリースに至るまでの小さな作業を繰り返し行う時に使う。
例えば、障害修正など。
これは、テスト工程などの下流工程で有効なことは既に知られている。

【3-1】一方、WF型開発なのでリリースは最後の1回だけだが、内部プロセスでは開始～終了のサイクルを持つものがある。
例えば、「要求の検証」「アーキテクチャの検証」「テスト工程の分割・反復」などの開発サイクルにTiDDを適用する。

つまり、ソフトウェア開発の匠（3）：「現状のソフトウェア開発は間違っていないか？」（プロセス編） (3/3) - ＠ITで語られている「ウォーターフォール開発には裏プロセスが存在する」のことだ。

裏プロセスとは、社内標準のWF型開発に即していない「要求の検証」「アーキテクチャの検証」「テスト工程の分割・反復」があげられる。
プロジェクトリーダーは、裏プロセスを故意に作らないと、プロジェクトが成功する確率が高くならないからだ。
リスクヘッジするために、裏プロセスを幾つか作り、リスクを分散する。

でも、裏プロセスは社内標準でないから、リーダーは故意に表面化させない。
裏プロセスを出してしまうと、社内標準の逸脱に見えてしまい、品質保証部から指摘を受けるからだ。

だから、裏プロセスが見える化されない限り、プロセス改善は進まない。
裏プロセスのノウハウが共有されないのだ。

【3-2】また、「組織パターン」の「最高傑作の欠点」でも裏プロセスの指摘がある。
いわく。
こういった裏プロセスは、実は、プロジェクトリーダーも開発者も認識している。
しかし、プロジェクトリーダーは社内標準のWF型開発に則しているように振る舞うために、裏プロセスを表に出さず、あたかも一つの標準プロセスとして忠実になろうとする。
そこに矛盾が生じている、と。

【3-3】チケット駆動開発の利点は、社内標準になっていない裏プロセスを見える化し、そのような裏プロセスのタスクをチケットで一元管理できる点だ。

裏プロセスは社内標準の成果物テンプレートやプロセステンプレートがないので、ノウハウがなく、適当に運営してしまいやすい。
でも、少なくとも作業を洗い出せるならば、チケットで全てのタスクを表現できるし、進捗管理もでき、作業履歴を追跡することもできる。

すなわち、チケット駆動開発は、社内標準から漏れた例外プロセスや裏プロセスを実装することに向いている。

【4】プログラム修正以外のタスクや情報のチケット管理

WBSからこぼれ落ちた情報を記録するためにチケット駆動開発を適用する。
例えば、設計工程での設計書のレビュー、開発工程のコードレビュー、各工程での課題やQAの記録など。

最終版の設計書だけでは、その仕様に至った経緯や要件の変更履歴が分かりにくい。
そのためだけに、変更履歴の資料を作っても、設計書が変われば、2種類の資料を修正する手間がかかる。
また、オフショアやニアショアなど、地理的に離れたチームとの開発では、QAのやり取りをしながらアウトプットのプログラムを作りこんでいく事が多いから、その経緯や履歴を残っているとすごく助かる。

こういう状況では、補完型チケット駆動開発が威力を発揮する。
すなわち、設計・開発・テストの各工程でこぼれ落ちた課題管理、残作業の管理、レビューの管理、障害管理などでチケット駆動開発を適用することで、チケットに全ての記録が集約される。
チケットの内容はいくらでも全文検索できるから、後から変更理由の経緯を追跡することができる。

特に、運用保守で本番ソースを修正する時、汚いパッチの意図を確認しておくのは重要だ。

【5】以上のように考えると、WF型開発にチケット駆動開発を適用する対象としては、下記があげられる。

(1)標準プロセスから外れた裏プロセスや例外プロセス
(2)WBSから漏れた残タスク・課題・レビューなどの管理

この事実を見ると、チケット駆動開発は例外的・突発的・変更が多いタスク管理に向いていることが分かる。

また、チケット管理を運用すると、いろんな効果が出てくる。
開発のリズム、見える化、バージョン単位の反復・漸進型開発、メンバーの自律化、開発ペースの安定など。

それらの効果は、WF型開発の弱点というよりも、チケット駆動開発を適用したから出てくるものであり、チケット駆動開発の運用ルールとして強制すべきほどではない気がする。
チケット管理を運用していく上で、現場ごとにその効果が色々見えてくると思うからだ。

そんなことを思うと、ソフトウェア開発ではプロセス標準という考え方は適用しにくいように思う。
むしろ例外や裏に隠れてしまったプロセスの方がすごく多い。
それらをいかに制御して、ソフトウェアをリリースしていくか。

まずは試してみて、実践知を貯めていきながら、製品を作り上げていくという適応型開発に、チケット駆動開発も当てはまりやすい性質があるのだろうと思う。

Redmineの親チケット検索機能とCSVインポーター機能

最近、Redmineで大きな機能改善がされているように思う。
リンク先の記事をメモしておく。

【1】Redmine 3.1新機能紹介: 親チケットおよび子チケットによるフィルタ | Redmine.JP Blog

Ver3.1からチケット一覧画面で、親チケットでフィルタリングできるようになった。
これはすごく嬉しい機能。
以前は、redmine-parent-issue-filter　プラグインを入れる必要があった。
redmine-parent-issue-filterの方が高機能ではあるが、Ver3.1の親チケットのフィルタリング機能でも十分に使える。

親チケットでフィルタできるRedmineプラグイン: プログラマの思索

Parent issue filter plugin for redmine の v1.0.1 をリリースしました。 - Enjoy*Study

親チケットの検索機能を使う場面としては、チケットをWBSのように深い階層で登録した状態で、WBSに紐づくタスクを洗い出したい時だろう。
Redmineに慣れていないプロジェクトリーダーは、バージョン機能を使わず、親チケットに工程を割り当てて、作業を子チケットへ階層化するように登録する場合が多い。
その時、親チケットをキーとして、子チケットのWBSを全て検索したい要望が多い。

Redmineのソースはまだ見ていないけれど、親チケットの検索SQLをどのように実現しているのか、が知りたい。
親チケットの検索処理は、いわゆる再帰処理であるが、Redmineの子チケットは無限の階層を許す。
うまいやり方でなければ、検索の性能が悪化するからだ。
おそらく、JPLはそれも考慮して実装しているのだろうと推測する。

なお、Redmineのチケットの階層化の実装方法は、入れ子集合という概念を上手く使っている。
だから、再帰SQLの処理も実装しやすいのではないか、と推測する。

Redmineチケットの階層化の実装方法: プログラマの思索

【2】akipiiさんはTwitterを使っています: "これは驚きかつ嬉しいニュースだ。RT @g_maeda: RedmineのtrunkにCSVインポートが入った。 ? http://t.co/iPq4PC7v8N"

リビジョン 14493 - Import issues from CSV file (#950). - Redmine

初期のRedmineの頃から、チケットの一括インポートのプラグインは必須だった。
WF型開発でもAgile開発でも、PJ計画時に大量のチケットを一括登録したい要望があるからだ。

Ver3.1までは、CSVインポートのプラグインか、Excelから一括登録できる「Redmineチケット★一括★」のどちらかを使えば解決できる。

zh/redmine_importer

RedmineチケットをExcelから一括登録できるアプリ「Redmineチケット★一括★」: プログラマの思索

上記の@g_maedaさんのTwitterを見る限り、次期Ver3.2でリリースされるようだ。
CSVインポート機能は、従来のRedmineには不足していてプラグインとして必須に近かった機能だったから、Redmineの発展に良い影響を与えるだろうと推測する。

今後もRedmineの動向を追いかけてみる。

ソフトウェア開発と経済学の類似性

経済学の本を読んでみて、ソフトウェア工学と経済学の類似性について考えたことをメモ。
ラフなメモ書き。
以下はラフなアイデアにすぎない。

【1】経済学の理論は、環境とテクノロジーで規定されているがゆえに、現実と合致しない場合が出る

【1-1】経済学の理論に、「セイの法則」というものがある。
「セイの法則は、「供給はそれに等しい需要を作りだす」という供給重視モデルを説明する理論です。」

金融大学 ＞ 金融用語辞典 ＞ セイの法則

セイの法則 - Wikipedia

いわゆる古典派経済学の理論の一つらしいが、世界大恐慌では、この理論に基いて状況を放置しても市場経済は復活しなかった。
彼らの言い分では、需要と供給は均衡するのだから、高い失業率が続けば労働コストが低下し、やがて労働需要も持ち直すから、恐慌は終わる、と。
しかし、恐慌はいつまで経っても終わらなかった。
それはなぜか？

その理由は、社会科学(たとえば経済学)の定説や理論は、その時代の社会構造やテクノロジーに規定されるという特徴があるため、かなり脆弱だから。

たとえば、社会構造の変化として、労働組合が強くなったために、労働者の報酬の下方硬直性が生まれたために、労働コストは需要の変動に対して簡単に下がらなくなった。
また、化学肥料や工業生産の拡大によって、農産物や工業製品が大量供給されて、かつての時代よりも供給量が大幅に需要を上回る状態になったために、この均衡が成り立たなくなったから。

すわなち、ある時代において現実をよく説明できた社会科学の定説は、社会構造の変化や技術革新によって、次の時代では現実をうまく説明できなくなったわけだ。
つまり、社会科学の理論は、ある時代のある前提に依存した一つの理論に過ぎない。

【1-2】この話は、ソフトウェア工学にもよく当てはまる。
ソフトウェア工学はわずか50年足らずの歴史しかないけれど、その中でたくさんの理論や経験則が編み出されてきた。
それら理論は、当時の開発環境や技術に規定されていたために、今の時代では使えないものもある。
あるいは、新しい現実にソフトウェア工学の理論がついていけず、今そこにある現実を説明できない時もあるだろう。

たとえば、アジャイル開発もそうだろう。
ある会合で「アジャイル開発は試行錯誤の行き当たりばったりの開発スタイルではないか」という指摘を受けた時があり、思わず、そんな発想を持つ人が今もいるのか、と驚くと同時に、古い理論とその当時の体験しか知らない人は、新しい現実を理解できないのだろう、と思った。

アジャイル開発が注目され始めた理由は、二つあると思う。
一つは、アジャイル開発を支える技術が普及したこと。
例えば、テスト駆動開発、継続的インテグレーション、仮想環境、チケット駆動開発など。
そのアイデアは昔もあったろうが、コンピュータの貧弱な性能やコストのために、使いにくかった。
しかし、今はGitHubやCircleCI、AWSなどのように、無料または低コストで、コンピュータ資源を使えるようになったおかげで、富豪的な発想で開発プロセスを組み立てることができるようになってきた。

もう一つは、ビジネスが変わったこと。
例えば、昔はメインフレームが隆盛で、企業の業務システムや基幹システムの開発がメインだったろうが、今は、Webサービス・ゲーム・SNSなどの周辺のビジネスの方が急拡大している。
そして、それらのビジネスでは、PCからスマフォへクライアント端末が変わった状況も後押しされた。
さらに、融通のきかない大企業よりも、少人数のベンチャー企業がどんどん新しい技術や開発スタイルを編み出すようになっている。

すなわち、ソフトウェア工学の理論も、その時代の現実を説明できるように、常にブラッシュアップすべきだし、新しい理論を打ち立てていくべきなのだろう。
ソフトウェア工学が発展するには、新しい現実に即した経験則を生み出していくことが必要ではないか。

では、ソフトウェア工学が新しい経験則を編み出すのに必要な条件は何だろうか？
僕は、新しいメトリクスを生み出すことが一つあるのではないか、と思っている。

【2】社会科学の中で経済学が科学として成功した理由は、各種の統計データが世の中に溢れているからではないか

【2-1】社会科学の中で、経済学が急激に拡大して政治的影響力も増やしている理由の一つは、各種の統計データが世の中に溢れているので、そこから現実を説明する新しい理論を作りやすくなっていたり、今後の経済動向を予測する作業がやりやすくなったからではないか、と思う。

これらの社会統計データは、政府が白書の形でたくさん出版しており、人口動態やGDP・GNPなどをいくらでも集めることが出来る。
また、帝国データバンクなどのように、民間企業が日本の企業の財務状況などを公開してくれているので、そのデータを元に今後の経済動向を統計学を使って予測することもできる。

経済学の発展を見ると、大量の統計データが溢れているおかげで、その統計データを元に、新しい指標(メトリクス)を作り出して、その指標を元に経済規模や幸福などを計測し評価しようとする動きもある。
また、統計学の理論を使って、データの相関性を帰納的に導く手法も使えるようになってきたので、帰納的な結果を元に新しい仮説を経験則として提唱することも可能になってきている。

【2-2】その発想をソフトウェア工学に当てはめてみると、実はソフトウェア工学で使える統計データが異常に少ない。
日本では、IPAが出版しているソフトウェア開発データ白書、IT人材白書、セキュリティ白書くらいしかない。

「ソフトウェア開発データ白書2014-2015」がより便利に使い易く
～PDF版とグラフデータを公開～：IPA 独立行政法人 情報処理推進機構

その理由は、日本の企業がこれだけソフトウェア開発をしているにも関わらず、守秘義務などの諸条件のために、統計データを公開できていないのが一番の理由だろうと思う。
他の公開できない理由には守秘義務もあろうが、個人的には、そもそも統計データを収集しようとする動機もあまりないのでは、と思ったりもする。
設計・開発情報だけでなく、進捗・品質・コストの情報も収集して、再利用できるデータに揃えるには、すごく手間がかかるからだ。

その状況は、今もあまり改善されていないように思う。

だが、一つの希望としては、オープンソースソフトウェアの隆盛と、GitHubの普及によって、それらで公開されているリポジトリ情報やIssue情報を収集することで、ソフトウェア工学の研究に役立てる可能性があることだ。

ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する: プログラマの思索

「金曜日のコミットにはバグが多い」という経験則があるが、その研究の対象は、EclipseやApacheのリポジトリ情報だったという話も聞く。
すなわち、オープンソースソフトウェアのリポジトリ情報やIssue情報を元に、ソフトウェア工学の新しい知見を見出して、今の現実に即した経験則を作り出していくことは可能なはずだ。

現在のソフトウェア開発の流れを見ても、技術革新の潮流を生み出す発生源は企業ではなく、オープンソースに移っている。
だからこそ、オープンソースソフトウェアが活発になるほど、ソフトウェア工学が発展できる余地はあると思う。

When do changes induce fixes? from Thomas Zimmermann

ユースケースの善し悪し

ユースケースの善し悪しについて、良い記事があったのでメモ。

【参考】
良いユースケースを書くための発想法

ユースケースの疑問: プログラマの思索

ロバストネス図の使い道: プログラマの思索

ユースケース駆動開発実践ガイド: プログラマの思索

ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき

ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき

最近、ユースケース記述を読む機会があり、システム要件がシンプルに上手く書かれていた。
その理由を考えている時、良いユースケースを書くための発想法を読んで、なるほどと思った。

僕もよく間違えるけれど、ユースケースを機能仕様としてシステム観点で細かく書いしまいがち。
本来のユースケースは、利用者の観点で、システムスコープを明確にすることだ。
また、ユースケースは、利用者とシステムの相互作用の観点として書かれるべきなので、シーケンス図でシステムと応答するような形で書くイメージになるべき。

ユースケースの善し悪し from akipii Oga

ストック型チケットは記憶媒体、フロー型チケットは流通媒体

「ストック型チケットは記憶媒体、フロー型チケットは流通媒体」というアイデアについてメモ。

【参考】
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

【1】Redmineのチケットは、ストックとフローの二面性を持つ。
ストック型チケットは、障害管理票や課題管理票、WBSなどの記録媒体。

フロー型チケットは、流通媒体。
例えば、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。

ストック型とフロー型のチケットシステムでは、どんな違いがあるのか？

【2】ストック型のメリットは、記憶媒体なので、チケットが蓄積されるほどナレッジ資産になる。
【2-1】下記の記事で、記憶媒体のチケットが集計されること、蓄積されていつでも検索できることのメリットが十分に明確にされている。

自分にとってのチケット駆動開発 @ アールケー開発

(引用開始)
最近だと主にアプリの開発ということが多いのですが、開発スタイルって色々ありますが、ここ数年、体になじんでいるものに、「チケット駆動開発」があります。

チケット駆動開発は、不具合だけではなく、タスクなども含めて、行う作業を全てチケットとして登録し、チケット単位でコミットを行います。SCMとチケット管理を連携させることで、コードの追跡もチケット単位で行います。

SCMには、Gitを使っているので、チケット単位でブランチを作るようにしました。そのおかげで、コミット自体はチケットの中で細かく行っても良くなりました。

数年、行って、やっと体になじんで、Gitの良さも感じられるようになってきました。最近思うのですが、このチケット管理という手法も語弊を恐れずに言えば、記録が残るということが最も重要な点だと思います。

開発中はチケット単位でタスクが管理されることで、現在の状況が整理されて、視覚化される。開発完了後は、どのように状況が推移していったかが検証できる。次のバージョンや関連する事象が起きたときには、当時はどうだったのか？何を行ったのかが記録に残っている。開発として重要な記録は、どのようなコード変更を行ったかだと思います。

そして、これらが蓄積されると資産になります。最近では、新しい機能の開発中に、影響することを調べるためや、特定のコードに対する理由を調べるのに、過去のチケットを参照することがあります。これも、チケットが蓄積されてきて、価値が出てきたからです。
(引用終了)

【2-2】しかし、記憶媒体のチケットの弱点はいくつかある。
入力項目が多くなりすぎたり、チケット内容を詳細に書く時間がかかりすぎるなど、チケット入力の運用が多少面倒になることだろう。
チケット入力のコストが大きくなるほど、チケット入力が億劫になり、チケットの保守ができなくなりやすい。

また、管理の度合いも強まるだろう。
本来は、チケットの精度が良ければ、いろんな観点のチケット集計機能を使うことで、多種多様なレポートやメトリクスを出力することができる。
それらレポートやメトリクスを使えば、プロジェクト運営のリスク管理に大きく役立てることができる。

でも、そのメリットも、メンバーがチケット入力を嫌がらずに作業してくれるのが前提だ。
この辺りの運用ルールはトレードオフになるかもしれない。

【3】フロー型チケットのメリットは、タスクがサクサク流れるので、作業のリズムが生まれることだろう。

【3-1】チケット駆動開発の最大のメリットは、開発のリズムが自然に出てくること。
朝に出社したら、チケット一覧で今日やるべき自分のチケットを決めた後、チケットに従って作業して、退社間際にチケットをCloseする運用になる。
この運用がメンバーごとにスムーズに流れるようになれば、チームの生産性は大きく上がる。

例えば、XPやScrumのように、イテレーション単位に小規模リリースする開発するスタイルでも良いし、カンバン駆動開発のように、WIPという仕掛り量の最大値に気を付けながらタスクを流すスタイルでも良い。

フロー型チケットシステムであるカンバン駆動開発の記事は下記がすごく参考になる。
やはり、ストック型チケット駆動を完璧にやろうとすると、開発プロセスが重量化しがちで、本来のチケット駆動の良さが失われがち。

カンバン駆動開発 - Trello, Slackで始めるKDD from Kazuya Takahashi

【3-2】しかし、流通媒体のチケットの弱点は、ナレッジ資産になりにくいことだろう。
タスクをサクサク流すことに注力するために、入力内容がおろそかになる時がある。
すると、完了したチケットには情報量が少ないので、蓄積されたナレッジになりにくい。

蓄積された完了チケットは、せいぜい、開始日や終了日、枚数の集計ぐらいしか使えないだろう。

【4】ストック型チケットとフロー型チケットでは、出力されるメトリクスが異なるように思える。

例えば、ストック型チケットは、ソフトウェア工学の品質管理やPMBOKのスケジュール管理・コスト管理で使われるメトリクスを集計しやすい。
例えば、信頼度成長曲線、障害のパレート分析などがある。
あるいは、EVM、要員表、稼働率、進捗遅れ日数などが出力できる。

フロー型チケットは、アジャイル開発で使われるメトリクスが多い気がする。
例えば、Velocity(イテレーション単位の開発規模、または開発速度)、サイクルタイム(ステータス更新にかかる作業時間)、スループット(チケット完了率)などがある。

ストック型チケットとフロー型チケットのメトリクスの違いを見ると、やはりストック型チケットの方がメトリクスの種類が多い。
管理者であれば、ストック型チケットの方が多種多様なメトリクスを、飛行機の操縦室にある計測器のように扱いたいだろう。

フロー型チケットのメトリクスは、チケットの流通量に関する指標が多い。
チケットが流れる速度が速いほど、作業はサクサク流れていることになる。

だが、チケットの流通量に関するメトリクスと稼働率や生産性の関連性があるのか、が興味あるところだ。
個人的な経験では、関連性は強いと思うが、それを実証することができるか？

いろいろ考えてみたい。

「Redmineで計測するEVM」の記事のメモ

「Redmineで計測するEVM」の記事が素晴らしいのでメモ。

【元ネタ】
Redmine備忘禄: Redmineで計測するEVM

Redmine備忘禄: Redmineで計測するEVM その2

Redmine備忘禄: Redmineで計測するEVM その３

Redmine備忘禄: Redmineで計測するEVM その４ （チャート表示をHighchartsへ）

Redmine備忘禄: Redmineで計測するEVM その５

imaginary-cloud/redmine_evm

momibun926/redmine_evm

momibun926/redmine_issue_evm

EVM - Plugins - Redmine

【参考】
第7回RxtStudy未発表資料「チケット駆動開発におけるEVMの考え方」

RedmineのEVMプラグイン: プログラマの思索

以前、RedmineのEVMプラグイン: プログラマの思索でOSSのEVMプラグインを紹介した時、EVMをリアル集計する機能しかなく、EVの履歴を保持する機能もなかった。
そのため、発展途上のEVMプラグインだった。

しかし、その後、ベースライン比較でEVMを比較したり、EVの履歴を保持する仕組みができたらしく、EVMがグラフ化されて良い感じで見れる。
プロジェクト単位やベースラインごとにEVMを見れたり、チケットごとにEVMのメトリクスを表示するプラグインもあるようだ。

Redmineが面白い点は、チケットに作業に関する情報が全て記録されているならば、欲しいメトリクスをいくらでも出力できることだ。
EVMのような複雑なメトリクスも、Excel集計では結構大変だけど、Redmineのちょっとしたプラグインでいつでもリアル集計できるのは面白い。

いろいろ試してみる。

【告知】8/29に第13回 RxTstudy開催 「Redmine再入門〜達人に学ぶRedmineの徹底指南」 #RxTStudy

8/29に第13回 RxTstudy 「Redmine再入門?達人に学ぶRedmineの徹底指南」を開催 します。

【参考】
RxTStudy #13 「Redmine再入門 ?達人に学ぶRedmineの徹底指南?」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

RxTstudy公式サイト

FaceBook RxTstudy

(引用開始)
【勉強会のテーマ～「Redmine再入門」】

今回のテーマは「Redmine再入門」です。
具体的には、Redmine未経験者、Redmine初心者向けに、Redmineのインストール・セットアップから基本的な機能・実践的な運用方法までをテーマとして、セッション・LT・パネルディスカッションを行います。

講演者は、日本のRedmineを開拓してきた下記の４人の方です。

Redmine.jpでお世話になっている書籍「入門Redmine 第4版」著者の前田剛様
2015/6に出版された書籍「Redmine実践ガイド」の著者代表である川端光義様
「Redmineタスクマネジメント実践技法」、「チケット駆動開発」の著者である阪井誠様、あきぴー様
(引用終了)

今回のテーマは「Redmine再入門」にしました。
理由は、前回のRxTStudyは大企業におけるRedmine活用事例、前回のredmine.tokyoはRedmineチューニング、という玄人向きテーマだったので、初心者向けのテーマが欲しいね～という話題が上がったからです。

また、Redmineの書籍も今年は「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」「Redmine超入門 増補改訂版 (日経BPムック)」「Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール (日経BPムック)」が出版されたので、著者に、Redmine初心者向けに講演してもらうのに丁度良い機会だと思いました。

個人的には、Redmineの使い方の話も興味がありますが、むしろ、Redmineのセットアップやインストール方法をもう一度おさらいしたいと思います。
Redmineのインストールやバージョンアップの方法は、何となく知っていても、結構時間がかかったり、手間取ったりする場合が多いからです。

例えば、WindowsでRedmineを構築するのは正直かなり大変と感じています。
CRubyやRailsのバージョンやGemの依存関係、MySQLのドライバがWindowsではインストールしにくいからです。

色んな人から、WindowsではVirtual Box上で仮想環境を作ってRedmineを構築するほうが簡単、という話もよく聞きます。
LTでも、DockerによるRedmine構築の事例をお話ししてもらう予定なので、楽しみにしてます。
また、前田剛さんに講演して頂くので、AMIによるセットアップとか、MyRedmineによるSaaSのノウハウなども紹介してもらえるのではないか、と期待しています。

久しぶりに、今までと違うテーマで盛り沢山なので、Redmineに興味のある方は是非ご参加下さい。

「Redmine実践ガイド」の感想を集めてみたpart1

「Redmine実践ガイド」の感想が素晴らしいのでメモ。

【参考】
『Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント』(株式会社アジャイルウェア)の感想(1レビュー) - ブクログ

(引用開始)
これまで「Redmine」というキーワードがつく書籍や雑誌は、かなり読み漁った方だと思うのだけれども、この本に関してはそれらの情報が見事に集約されている。

エントリー向けとしては、これ1冊で十分かも＆もう少し早く欲しかったかも。きちんと役割別に章立てされていて、かなり丁寧な内容だと思う。

Redmineと一口にいっても、いろんな技術や考え方が絡み合っており、その活かし方も殺し方も様々だと思う。個人がRedmineを使いこなせるレベルから、現場へ浸透してチームで活かせるレベルまでもっていかなければ嬉しくないので。

この実践ガイド本については、前者のレベルでつまづきにくくし、後者のレベルの第一歩を誘導してくれる本だと思う。

2年近く使ってる程度の私としては、6章のプラグイン紹介や8章の活用シーン紹介とか、MS ProjectやTracとの違いのコラムをもとに、自分でも検証して第二歩、第三歩と進んでいきたいところ。

チームにRedmineを「使ってもらっている」から「使いたくなる」と感じてもらえることが、今の私のひとつのゴールなのかもしれません。
(引用終了)

【1】「Redmine実践ガイド」が他のRedmine本と違う点は、利用者・マネージャ・システム管理者の3つのロールの観点でRedmineの利用方法が書かれている所でしょう。
プログラマやデザイナーがRedmineでチケット管理する操作や観点は、マネージャやシステム管理者とは異なるでしょう。

あるいは、マネージャがRedmineでチケット集計したり、進捗や作業内容をチェックする操作や観点は、利用者やシステム管理者とも異なるでしょう。

Redmineは、いくらでもロールを増やせること、権限制御が柔軟である特徴があるがゆえに、ロールごとの操作のポイントを説明するのは重要だと思います。
なぜなら、なぜそのような機能がRedmineにあるのか、という理由は、まさに、Redmineを利用するロールごとに異なるからです。
実際、Redmineのデフォルト機能やプラグインでは、プログラマやデザイナーがチケット入力した結果を、管理者が集計してチェックしたり、基本的な設定を行うなどの操作を権限制御できます。

Redmineのセキュリティや権限制御は、バージョンアップするごとに機能追加されているので、一度きれいにまとめてみたいところです。

【2】「Redmine実践ガイド」では、特に運用方法や運用事例の紹介に力を入れて書いていると思います。
個人的には、「第7章Redmineで始めるチケット駆動開発」「第8章 Redmineの運用の考え方」「第9章 Redmineの運用事例」は読んで頂きたいところかな。

例えば、「第8章 Redmineの運用の考え方」では、ITILのソフトウェア保守、ヘルプデスク管理、PC資産管理などの事例をあげています。
本当は、PMBOKのEVMによるコスト管理、要員表や稼働率などの人的資源管理、ガントチャートのクリティカスパスの計算方法なども触れたかったのですが、書く余裕がなかったです笑。

「第9章 Redmineの運用事例」では、島津製作所や三菱電機、フューチャーアーキテクトなどの会社の事例が詳しく紹介されているだけでなく、メリットやデメリット、Redmine運用の限界にも触れている点が興味深いところです。

日本ではRedmineがプロジェクト管理ツールのデファクトスタンダードになっているらしいので、今後もRedmineの運用事例がどんどん出てくると思います。
それらノウハウを一つの知識体系、あるいは、ベストプラクティス、あるいはパターン集としてまとめていきたいと思います。