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

2019年5月

2019/05/31

IOTは組立加工工場を中央制御型工場へ変える

ラフなメモ。
IOTはなぜ流行るのか?
下記の記事を読んでようやく分かった。

【参考】
お知らせ:「化学工学」誌に論文『ディスクリート・ケミカル工場の生産システムを考える 』が掲載されました : タイム・コンサルタントの日誌から

90年代までに日本の製造業の工場は、FA、FMS、CIMなどで既に、生産工程はほぼ自動化されている。
しかし、上記の記事から推測すると、組立加工の製造業のほとんどはたぶん、中央制御型工場ではなく、現場や各工程に分権化されている。
一方、化学プラントなどのプロセス系工場では、中央制御室による中央制御型工場が既に実現されていた。

では、なぜ、組立て加工の工場は、化学プラント工場のように、中央制御型にできないのか?
上記の記事では、工場設計の「アーキテクチャーの差異が、じつは扱うマテリアルが流体か固体かという、単純な違いに起因する」と主張する。

しかし、昨今のIOT技術を用いると、「従来モジュラー型でしか設計し得なかった組立加工系の工場を、インテグラルなシステムに変える潜在的可能性を持っています。この可能性に早くから着目したのが、ドイツの「インダストリー4.0」構想でした」。

つまり、IOT技術を駆使すれば、工場は完全無人化、完全自動化を実現できる可能性があるわけだ。
実際、Amazonの物流倉庫は完全自動化を目指しているわけだから、工場でも可能なはずなわけだ。

一方、日本の製造業の現状として、バブル崩壊後ずっと、過剰生産による設備投資に悩まされてきたので、生産設備の改善が停滞していた。
しかし、昨今のIOT技術の隆盛によって、ドイツがこの可能性にいち早く着目して政府主導で行った結果、実は日本は遅れていたのではないか、という見方が日本のメーカーでも強まってきた、というストーリーなのだろう。

| | コメント (0)

規模の経済と経験曲線効果のメモ

規模の経済と経験曲線効果は、どんな事業を起こすにしても、必ず使うビジネス上の経験則と思う。
以下は自分が理解したラフなメモ書き。
間違っていたら後で直す。

【1】規模の経済と経験曲線効果の違いは何か?

「規模の経済」とは、生産規模の拡大により、単位当たりの生産コストが低くなる事。
「経験曲線効果」とは、製品の累積生産量が増加するに従い、製品1単位当たりの生産コストが一定割合で減少すること。
つまり、規模の経済はハード面、経験曲線効果はソフト面に相当する。

規模の経済は、大企業なら大規模な資金を設備投資に振り向けることで実現できるが、中小企業には難しい。
しかし、経験曲線効果なら、中小企業でも、同一の製品の生産を繰り返し行うことで、作業員の経験値が上がることで、コストを下げることができる。

【2】規模の経済は、どんな業界に使われているのか?

たとえば、製造業のように、工場の設備投資と生産工程の標準化活動で成果を出しやすい。
また、規模の経済と経験曲線効果は製造業だけでなく、他の業界でも通用する場合が多い。
たとえば、コンビニや外食チェーンのようなフランチャイズ系列でも、大量仕入れによる原価低減と多店舗展開における販売サービスの標準化にも見られる。
つまり、小売・卸売業などでも、規模の経済の発想は使われている。
労働集約型の業界でも、経験曲線効果をいかに引き出すか、という視点の改善活動は必要らしい。

【3】規模の経済は、資本主義にとってどんな意義を持つのか?

おそらく資本主義というシステムは、設備投資効率を向上させてきた歴史がある。
その要因の一つには、規模の経済によるコスト低減効果があったからではないか。
実際、20世紀の歴史を振り返ると、銀行が全国民から貯蓄を収集し、そのお金で製造業へ大規模な設備投資を行い、大量生産してきた。
その結果、企業も政府もどんどん大規模になり、最終的にはとてつもない大規模な官僚制組織になった。

資本装備率(しほんそうびりつ)とは - コトバンク

(引用開始)
労働量に対する資本量の比率。正しくは労働の資本装備率,あるいは資本集約度という。
資本装備率は個別企業としても,また産業別にも,あるいは国民経済全体としても計測されるが,いずれにせよ雇用労働者数を L ,資本設備額を Kとすれば,この比率は K/Lとして表わされる。
資本装備率の上昇は生産力の増大を意味し,資本主義的経済発展は絶えずこの比率を上昇させる傾向にある。
(引用終了)

よって、規模の経済は資本主義の要となる重要な考え方ではないか?

【4】規模の経済に限界はあるのか?

ある一定規模までは、設備投資や経験曲線効果は有効に作用するが、いずれ壁にぶち当たる。
その壁にぶち当たるまでは、企業は価値連鎖となる工程や活動だけでなく、付随する活動も自社で内製化・内部保持する事で、規模の経済を活かそうとする。
たとえば、以前の日本の製造業では、本業の自動車・電気製品の事業だけでなく、従業員の出張サービスや娯楽サービスなどに至るまで事業として内製化してきた。
そういう事業として内製化した理由はおそらく、規模の経済のメリットを活かすためだったのだろう。

しかし、『プラットフォーム革命』によれば、人員や有形固定資産に縛られること、組織が大規模化することで複雑化する為に、規模の経済の効果は限界にぶち当たる。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

【5】規模の経済が活用できない業界はあるのか?

労働集約的な業種では、規模の経済・経験曲線の効き目は小さいだろう。
サービス業や、会計事務所・病院などのようなプロフェッショナル官僚制組織では、組織の大規模化による規模の経済のメリットが薄いかもしれない。

特に、ソフトウェア開発では、人月の経験則のように、大量の人員による開発は生産性のさらなる低下を生み出すことは既に知られている。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

一方、IT業界では、限界費用がゼロに近くなり、収穫逓増の法則になる。
たとえば、『プラットフォーム革命』のストーリーでは、IT業界におけるGAFAやBATのようなプラットフォーム企業では、人員や設備などの有形固定資産が無い為、限界費用はゼロとほぼ同じくなるので、規模の経済の限界がないと考えられる。
よって、プラットフォーム企業による自由競争の結果、唯一の企業による自然独占になり、市場と同規模になるまで成長することで、小国のGDPに相当するくらいの独占企業が生まれることになる。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

【6】規模の経済は経済学の考え方と矛盾するのか?

マクロ経済学のどこがヤバいのか

ミクロ経済学の基本的な考え方の一つに、「需要と供給の均衡」がある。
一般に、消費者の需要と生産者の供給量は、交差する1点、均衡価格に必ず落ち着く。

その考え方の前提には、「限界効用の逓減」「限界費用の逓増」の2つがある。
「限界効用の逓減」は分かりやすい。
たとえば、消費者にとって、生ビールの1杯目は美味いが、5杯、10杯と飲み続けると限界効用は低減する。

「限界費用の逓増」は「収穫逓減」と同じ。
たとえば、農業のように、肥料や労働者を増やしても、土地の面積は限界があるので、費用の増加分よりも産出量は少なくなる。

一方、規模の経済の概念はまさにその真逆で、たくさん作るほど「限界費用は低減」していく。
生産者にとって、同一製品を大量生産・同一原材料を大量仕入れすることは、規模の経済により限界費用は低減し、コスト削減につながる。
つまり、「限界費用の逓増」は規模の経済と矛盾する。
この部分はどうつじつまを合わせるように考えたら良いのか?

おそらく、平均費用のグラフを使って、ある一定規模までは「限界費用は低減する」が、上限を超えると「限界費用は逓増」する、と考えることで折り合いを付ける。

| | コメント (0)

2019/05/29

redmine trunk changesブログが参考になる

最近、redmine trunk changesブログが公開されていて、参考になるのでメモ。

【参考】
redmine trunk changes

/ - リポジトリ - Redmine

Redmine本家のリポジトリやチケットを見た後で、 redmine trunk changesを読むと、より理解が進むので便利。

著者の方は知らないけれど、福岡のRuby会議でRedmineをハックした開発者の方らしいので、いつか会ってお話してみたい。

akipiiさんのツイート: "おお、この内容は詳しく聴きたいな。RT @hanachin_: コード懇親会でRedmine本体のテストを動かしてみたらrubyがtrunk・2.6、RDBMSがMySQL・PostgreSQL・SQLite3の3環境で同じテストが落ちてrubyのバージョンやRDBMSの違いではなさそうというのが即座にわかった #rubykaigi"

Miyagiさんのツイート: "RubyKaigi参加されてますか?頭が緑色なのでもしお見かけされたらお話ください!(もし参加されてなければアルコール抜けてからリプライします…!)… "

Miyagiさんのツイート: "こういう感じです。今システム環境の時刻が日本時間のマシンでGitHubのredmine/redmineをcloneしてきてbundle installしてマスターブランチで bin/rails test test/functional/issues_controller_test.rb:358 すると再現すると思います。 https://t.co/cVqQWS1QN4… https://t.co/nONOkLU9lR"

Miyagiさんのツイート: "@yancya さんと @watson1978 さんと @jimlock さんと #rubykaigi の2つかめのあとの @speee_pr さん提供のコード懇親会でもくもくしていて見つけた感じです。 https://t.co/rODISb3AyE 時間内にバグレポ出来てなかったので今https://t.co/uLs49iin5xのアカウント登録したところ...です!… https://t.co/IBBIlOtgGw"

akipiiさんのツイート: "@hanachin_ さん、ご連絡ありがとうございます。確かにRedmine本家にパッチを送る時に、プルリクで無い事が面倒だ、という弱点はありますが、GitHubのパッチのリンクをTwitterに流してもらえれば、 @g_maeda さん他、Redmineユーザが必ず見つけてくれます。… https://t.co/6Debb5HOAd"

MAEDA Goさんのツイート: "これに関連してそうでしょうか。 Defect #30288: Group name and group count are incorrect when grouping by date (TimeWithZone) https://t.co/JHXZopn9L2… https://t.co/JprKwHV2zn"

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索にも記載したけれど、他の競合のチケット管理ツールに対し、オープンソースのRedmineが競争優位性を保つには、もっと多くのRuby開発者を巻き込む必要があると考える。

なぜなら、Jira、Backlogなどの有償ソフトウェア製品、Gitlabなどの大規模なオープンソースソフトウェアに比較すれば、Redmineの立場はすごく弱いと思うからだ。
一方、日本ではRedmineコミュニティが盛り上がっているので、コミッタやユーザとRuby開発者の間で有意義な議論ができるといいな、と思う。

今後もRedmineの機能改善に注目していく。


| | コメント (0)

Redmineにチャート画面が追加された

Redmineにチャート機能を追加されたのでメモ。

【参考】
Feature #31418: Stacked bar charts in the issue details report - Redmine

redmine-trunk-changes 2019-05-24 - redmine trunk changes

redmine-trunk-changes 2019-05-26 - redmine trunk changes

(引用開始)
チケットのサマリーから更に虫眼鏡アイコンを押した先の画面にissueの積み上げ棒グラフを表示するようにしています。
(引用終了)

※画像は、Redmine本家のチケットからリンク。

Redmineのサマリ画面では、チケットの集計情報が表示されるのですごく便利だが、数字の羅列なのでちょっと読みにくい。
しかし、チャート機能の追加により、一目でチケット集計結果が分かるようになるので、初心者や管理職にアピールしやすくなるだろう。

日々チケット運用している現場では、チャート機能がなくてもあまり困らないけれど、Redmineを時々しか見ない管理職や経営層にはインパクトが大きい機能だろうと思う。
こういうかゆい所に手が届く機能改善が頻繁にRedmineに取り込まれる点は、オープンソースならではのメリットなのかもしれない。

【追記】
2週間前の東京Redmine勉強会で紹介されたmessage_customizeプラグインの事例がさっそく公開されていた。
色々遊べそう。

Redmineの notice/error/field/setting/permission/button メッセージに”にゃん”を付加する(今のところPostgresだけ) - Qiita

| | コメント (0)

2019/05/19

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

昨日の第16回東京Redmine勉強会の感想をラフなメモ書き。
疲れているのでラフなメモ。

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

第16回東京Redmine勉強会『Ver4に上げよう Redmineのさらなる進化と多用性!』 #redmineT (18ページ目) - Togetter

第16回redmine.tokyo勉強会 まとめ

redmine.tokyo 16 感想 - アカベコマイリ

redmine.tokyo 第16回東京Redmine勉強会に参加してきました。 - みずりゅの自由帳

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【1】昨日のRedmine勉強会でちょっと嬉しかったことは、@rechiba3 さんに初めてお会いできたことと@ohnukiさんに5年ぶりにお会いできたこと。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。講演者、スタッフ、参加者の皆様ありがとうございました?? 懇親会の参加率が約7割で50人で盛り上がりが凄いと思います。今回は7年越しに @rechiba3 さんとお会いできたのが収穫でした。ユーザー層も老若男女、開発者からPMOまで幅広くて来る度に面白い"

@rechiba3 さんの下記の資料を以前読んでBlogに感想を書いたことがあったので気になっていた。

TiDDでウルトラハッピーな開発フロー実践しちゃおう!

WebディレクターによるRedmine運用事例: プログラマの思索

また、@ohnukiさんは、5年前の勉強会が大雪だった時にLTで講演して頂いたことを覚えていたから。

第6回勉強会 - redmine.tokyo

他にも@MzRyuKaさんから、懇親会でこんな話もあって盛り上がった。

みずりゅさんのツイート: "#redmineT https://t.co/XfSENoynLn 初参加、どれも凄く楽しかったけど、あえて一番を選ぶとしたら懇親会でakipiiさんとお話しできたこと。 数年前に会社のブログで書いた記事を取り上げてもらったことに、やっとお礼を言うことができました。"

チケット駆動開発の運用例part4: プログラマの思索

BlogやSNSのおかげで、実際に会ったことがなくても、すぐに仲良くなれる。
そういう場をコミュニティが提供してくれて本当にありがたい。

【2】10個以上の講演があったので、記憶に残った所だけ書き残す。

【2-1】@netazoneさん「ある工場の Redmine バージョンアップ」では、プラグイン作者にVer4.0対応を自らお願いしまくった結果、そうなったからには自分のRedmineをバージョンアップしなくては、という行動に至った気概に強く共感した。
数多くの日本人プラグイン開発者が対応してくれたからこそ、Ver4.0に安心してバージョンアップできるからだ。

つまり、Redmine本体だけでなく、主要なプラグインがVerUpに追随することは、Redmineユーザにとって非常に重要な要素である、という事実を明示していると思う。
よって、RedmineコミュニティがRedmineプラグイン開発者を巻き込んでRedmineを盛り上げていくことは、非常に重要な活動なのだ、と改めて感じた。

【2-2】@agilekawabataさん「LycheeカンバンとRedmine運用の事例紹介」では、Lycheeプラグインの機能紹介が多くなってしまったけれど、メーカーのRedmine利用事例の話に興味を惹かれた。

akipiiさんのツイート: "#redmineT 複数案件を複数チームで進捗管理するにはどうする?メーカーなら、エンジンチーム、ボディチームなどの複数チームがあるが、トラックプロジェクトと乗用車プロジェクトの親チケットから派生した子チケットは、それぞれのプロジェクトで管理したい。"

例えば、自動車メーカーでは、トラックプロジェクト、乗用車プロジェクトの2つのプロジェクトが別々にある一方、エンジンチーム、ボディチームの2チームも別々にある。
トラックプロジェクトの機能(親チケット)には、エンジンチーム、ボディチームの開発タスク(子チケット)でぶら下がるが、チームごとのプロジェクトで扱いたい。
理由は、チーム単位のタスク管理がしたいこと、各プロジェクト単位で他者には情報を見せたくないことがあるから。
現状の標準Redmineでは、Redmineプロジェクトを跨ぐ親子チケットや関連チケットは作ることができるので、ある程度は運用できるだろうが、もっと細かなニーズを実現して運用する場合は、色々問題が噴出するだろう。
おそらく、それら問題となる利用シーンでは、Redmineのカスタマイズやプラグインによる機能拡張が必要になるだろうと想像する。

つまり、複数プロジェクトと複数チームのタスク管理を横串でプロジェクト管理する手法を、Redmineが支援できる可能性がある。
そうすれば、組織をまたいだ複数案件のPJ管理のように、より大規模なPJ管理もRedmineがカバーできるようになるだろう。
本来、Redmineという一つの箱にWF型開発案件もAgile案件もデータが格納されているので、横串のデータ集計はRedmineのようなチケット管理ツールが得意な所。
その機能をさらに大規模なPJ管理にも適用していくには、Redmineにどんな機能が標準で必要になってくるのか、という問題を提起してくれた点が面白かった。

【2-3】@yassan168さんのLTでは、クラウド上でDockerを使って、Redmineを含めたサーバー構築を行った、という点が興味を惹いた。
Redmineサーバーだけでなく、リバースプロキシやDNS設定などは、オンプレサーバー上のインフラ構築作業と全く同じなのに、クラウドの方がものすごく簡単に構築できるわけだ。
オンプレミスのインフラ構築は、本当に面倒な作業だった。
たとえば、iptableをいじったり、hostsをいじったりしていたから。

しかし、@akabekobekoさんと話しながら、簡単に構築できる理由は、DockerでOSに依存しないミドルウェアの構築ができるので、後はそれらをつなぐ構成をすればいいだけ、ということで理解した。
よって、今後はAnsibleよりもDockerの方が有用だろうという気がした。

【2-4】hin-tさんのLTでは、定期的にチケット登録するプラグインを紹介していた。
営業事務の定形業務で、物忘れせずに役立つんですよ、という発言があった。
どのプラグインか忘れたので後で探しておく。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【2-5】石川さんのLTでは、message_customizeプラグインが興味を引いた。
このプラグインは、ymlに書かれた文言を修正して表示できること。
メリットは、ymlを書き換えなくても、管理画面で修正できるので、viewCustomizeプラグインに似た感覚で管理者が操作できることだろう。
すると、@netazoneさんが発した問題「海外ユーザと1個のRedmineインスタンスを共有する時、ステータスやトラッカーを日本語・英語で併記しない方法はあるか?」に対応できないか、考えてみたくなる。
一方、@g_maedaさんの話では、Redmineの画面をリロードしたらhtmlからlang=ja,enは取得できるので、その情報を元に、ログインユーザ毎に修正文言を表示できるはず、と言っていた。
たぶん、message_customizeプラグインとviewCustomizeプラグインを駆使すれば、その問題は解決可能だろうと思う。

GitHub - ishikawa999/redmine_message_customize: This is a plugin for Redmine.

GitHub - onozaty/redmine-view-customize: View customize plugin for Redmine

【2-6】堂端さんのLTでは、Redmine大阪で話したGitHub連携プラグインの続きだった。
興味を引いたのは、RedmineチケットとGitHubブランチを紐づけた後、Github上でプルリク受付、プルリク承認、masterマージという一連の作業ごとに、Redmineチケット一覧画面でチケットのアイコンが更新される機能があったこと。

つまり、GitHubからRedmineへフックさせているわけだ。
裏では、GitHubのクローンがRedmineサーバー上にあるので理解できるが、Redmineチケット一覧でプルリクのステータスをアイコンで判別できる機能は良いな、と思った。

但し、RedmineチケットとGitHubブランチを紐づける時に、「xx@#チケット番号」のようにブランチ名にプレフィックスを付ける手順がいる点は注意。

GitHub - agileware-jp/redmine_github

【2-7】@miokakusuさんのLTでは、MSのVisualStudioからTFSへチェックインする時に、Redmineチケットと同期させる仕組みを作った事例。
TFSの通知メールからRedmineとREST APIで連携する処理が面倒ですね、という話が興味を引いた。
仕掛けについては、@ryouma_nagareさんからアドバイスをもらったので理解できた。

akipiiさんのツイート: "#redmineT TFSの通知メールをRedmine がキャッチして、RESE APIで、チェックインとチケットを紐づけた。ごめん、この辺りがよく分からない。"

りょうま@redmine.tokyo終了でRedmineロスさんのツイート: "ですね。 メールサーバで受信したメールを標準出力でスクリプトが受け取る 本文解析して、チケット番号、内容、ステータスを生成 REST APIでRedmineサーバにアクセス です。メールサーバかRedmineに同居している必要もないです… "

【2-8】@naitohさんのアンケート集計では、Git利用率が下がっている点が気になった。
たぶん、Git中心で開発する場合、GitHubやGitlabだけの運用に流れているのかもしれない。
つまり、RedmineとGit連携の機能が弱い点は、今後、Redmineの弱点になってくるかもしれない。

【3】@ohnukiさんから、コミュニティ運営を褒められたことは一スタッフとして嬉しかった。

Hiroshi Ohnukiさんのツイート: "久しぶりの参加、第一印象ですが運営が素晴らしい #redmineT"

【4】Redmineコミュニティに関わって8年経つが、なぜRedmineコミュニティを継続できたのか、とふと疑問に思う。
僕はコミュニティ経験がまだ浅いけれども、過去を振り返ると、コミュニティの浮き沈みはとても激しいと感じる。
長期に渡って熱気を維持できるコミュニティは正直多くない。

その理由は、Redmineというツールが、日本における市場の潜在ニーズをうまく汲み取ってきたから、ではないかと考えた。
つまり、日本の官公庁や大企業における非効率な業務にRedmineが当てはまるケースが多いのだろう、と考える。

たとえば「プラットフォーム革命」にはこんな一節がある。
プラットフォームビジネスの機会を見つけるには、「取引コストが高い所」「複雑で見過ごされているネットワーク」「大規模で分断された未活用な資源がある所」に注目せよ、と。

この言葉を念頭に置いて、以前、CoderDojoの関係者と話していたら、まさに日本の教育業界はとても非効率な業界なので、ベンチャー企業が参入しやすいという印象を受けた。
実際、日本の学校ではIT化が進んでおらず、プログラミング教育や英語教育などの外部環境の大きな変化に揺さぶられていて、教育者だけで自力解決できず、袋小路になっている印象だ。
そんな非効率な業界だからこそ、CoderDojoなどのITコミュニティやITベンチャー企業はちょっとした改善ツールを導入するだけでも、すごく通用する。
そういう話を聞きながら、CoderDojoは本当に良いマーケットを持っているなあ、今後しばらくはその業界でビジネスをやっていけるだろう、という印象を持った。

同様に、日本の官公庁や大企業は、メールやExcel帳票の文化で凝り固まっている現場が多いので、昨今の最先端のIT企業から見れば、非効率極まりない利用シーンが非常に多く見受けられるだろう。
だからこそ、そういう業務にRedmineを単純に導入するだけでも、それなりの改善効果を得やすい状況があるのだろう、と思う。
よって、そういう非効率な市場が残っている限り、まだ今後しばらくは、Redmineは日本で根付いていくだろうと思っている。

| | コメント (0)

2019/05/16

GSNの利用事例のリンク

 

astahブログにGSNの利用事例が紹介されていたのでリンクしておく。

GSN広めよう活動奮闘記?三菱電機エンジニアリング株式会社様? | astah in 5 min

GSNは組込みシステムの機能安全の設計で使うツールと思っていたので、タスク管理に使う発想がなかった。
なるほど、変更要求からタスクまでのトレーサビリティを明示できる特徴を生かして、こういう使い方もできるのは面白いと思った。

 

 

 

 

| | コメント (0)

2019/05/07

第16回東京Redmine勉強会の見所 #redmineT

来週末に行われる第16回東京Redmine勉強会の見所を書いておく。

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

第16回redmine.tokyo勉強会 みどころ

「エンジニアの知的生産術」読後メモ(自分用) - Qiita

【1】今回のテーマは『Ver4に上げよう Redmineのさらなる進化と多用性!』。
テーマに関しては、スタッフ内で議論が色々あった。
ViewCustomizeプラグインをもっと使った事例が欲しいね、という話から、多様な講演内容がそろったと思う。
Redmineの利用事例がかなり増えたおかげで、色んな人達が自分なりの改善ノウハウを持っているみたいだ。
そんな話が聞けるのが面白い。

【2】いくつか興味深い講演はある。

一つは、アジャイルウェアの川端さんの講演「LycheeかんばんプラグインによるScrum開発事例の紹介(仮)」。
最近、Lycheeかんばんプラグインの評判がいいので詳細を知りたい、という話から講演が決まった。

チケットボード | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

標準Redmineでは、チケットという元ネタはあるが、それを多種多様な利用目的に応じて集計表示できるビューの機能は少ない。
そこで、チケット集計に関する数多くのプラグインが生まれてきた。
その中で、かんばんというビューは、色んな使い方ができる可能性がある。

本来、かんばんはアジャイル開発に最も適した進捗管理用のビューだ。
たとえば、タイムボックス形式で、タスクをフローで管理する。

しかし、WF型開発でもかんばんは有効な場面が多い。
特に、結合テストや総合テストなどのテスト工程では、障害管理とかんばんは非常に相性が良い。
日々溢れ出てくる障害を一つずつ潰していくには、かんばんのように、日々の作業ステータスがリアルタイムに見れる方が管理しやすいからだ。

一方、かんばんは担当者の手持ちの作業が明確に判別しやすい。
日々の作業がスムーズに流れているならば、特に朝会とセットで運用すればいい。
WIPを導入すれば、チームの能力に合わせたリソース管理がしやすくなるはずだ。

「Lycheeプラグインは500社以上の導入事例がある」とWebページで記載されているので、個人的には、日本の企業はRedmineにどんな事を期待しているのか、そして、Redmineの標準機能のどこに不満を持っていて、Lycheeプラグインがどうやって上手く適合してきたのか、という点が知りたい。
つまり、日本企業とRedmineがなぜ相性が良いのか、という本質を聞いてみたいわけだ。

【3】もう一つは、多様で盛り沢山なLT。

@forenoonMさんの「ViewCustomizeのHTML埋め込みによるRedmineの機能拡張」は、一時期ツイートで有名になった「Redmine上で動くティラノサウルス」のことかな、と思う笑。

akipiiさんのツイート: "面白すぎる!RT @netazone: Redmine に例の「暴れ回るティラノサウルス」降臨。 ありがとう @forenoonM 。 そして view customize plugin をこんなことに使ってごめんなさい https://t.co/5L3jSWuPV5"

akipiiさんのツイート: "元ネタはこれでしたか!RT @forenoonM: Redmineに例の「Wordで暴れ回るティラノサウルス」をそのままリアルタイムレンダリングしてみた。さすがはView Customize Pluginとthree.jsだぜ! https://t.co/xZZG0efuji"

他にも、Git連携や構成管理ツールTFSに関するLTが3本もあるので、やはり構成管理ツール連携の機能はニーズが多いのだろうと思う。

【3】@MadoWindaheadさん「カスタムクエリーを使って状況を見やすく斬る」、@yuki476さんの「チケット文化定着までに気をつけたこと」、hin-tさんの「(仮)毎月のTodoを自動チケット作成プラグインでもっと簡単に」のLTは、Redmineの運用方法に関する講演で興味がある。

@MadoWindaheadさんと話しながら、「エンジニアの知的生産術」本にある一節「タスクの優先順位付け」を思い出していた。
その本では、タスクの優先度付けの話があり、優先度をつける観点1の最優先、または、観点2の最優先が本当の全体最適ではなく、観点1と観点2の中くらいが利益最大になる場合もある、という話があった。
つまり、制約条件が複数の場合、全体最適な解は線形計画法で計算するパターンになる。
よって、人間の頭ではすぐに全体最適の解を見つけるのは難しいので、あえて1次元に落としているのかな、と思った。
1次元に落とせば、ソート順に並べるだけで優先度が即座に決定されるからだ。

実際、タスクの優先順位付けこそがプロジェクトリーダーの最大の仕事だ。
しかし、タスクの優先順位付けの解空間は、そのパラメータの個数分であるN次元空間になるが、変数の個数が多かったり、説明変数が相互依存していたりするなど、人間の頭では処理しきれない。
よって、あえてN次元→1次元へ射影して単純化することで、スピーディに優先順位付けできるようにする手法が、特にScrumのProductBacklogなどのアジャイル開発で発達してきた、と考えている。

一方、解空間の次元を落とすことは、必要な情報も削ぎ落としているリスクがあり、それにより優先順位付けを間違えている可能性も大きい。
その辺りのトレードオフをどのように解決するのか、@MadoWindaheadさんが自身の経験談を元に、どのように解決してきたのか、を聞いてみたいと思う。

【追記】
着々と準備は進んでいるみたい。


neta@ 5/11(土) Redmine 4.0 化(まもなくしぬ)さんのツイート: "Today I upgraded my main #redmine to 4.0 ! I am grateful to all Redminers (developers and plugin authors, users)! :) … https://t.co/fxwhF8o7HI"


第16回redmine.tokyo開催前夜に、仲間と愉しきやり取りをメモした。
ときめくバグチケットとは? 第16回redmine.tokyo開催前夜の眠れぬ夜の会話- Togetter

| | コメント (0)

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