« 2016年11月 | トップページ | 2017年1月 »

2016年12月

2016/12/28

チケット駆動の罠~複雑さはチケットの粒度に関連している

チケット駆動の罠の記事をメモ。

【参考】
JIRAに死を | TechCrunch Japan

(引用開始)
ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。
ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。
JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。
ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。
(引用終了)

tadashi-aikawaさんのツイート: "本文にも書いてあるけど JIRAをディスっているのではなく JIRAの使い方をディスっているだけ。 Confluence使えばおけ JIRAに死を | TechCrunch Japan https://t.co/pNEqwe12Ex via @jptechcrunch"

akipiiさんのツイート: "チケット駆動の罠か。なるほど。RT @arichika: 派手なタイトルの割にちゃんと読めば、チケット駆動が陥りやすいミスが書かれていると思う。プロダクト・サービスの全体像が見えにくくなる、という事。... https://t.co/TB8O1uTEA6"

宮乃ぺこ@木曜東ア34bさんのツイート: "JIRAに関してというより、システム全体をみようねって話 JIRAに死を | TechCrunch Japan https://t.co/Nk3mms8Ryg @jptechcrunchから"

Takeo Hashimotoさんのツイート: "煽りタイトル良くない。そのようにデザインされていない道具をそのようにデザインされていない目的に無理やり当てはめようとしてもうまくいかないのは、ある意味当たり前。原文見たら本当に death って書いてあって呆れた。/ JIRAに死を https://t.co/iEXy4qUFUm"

Mass Kanekoさんのツイート: "「ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。」 少なくともAtlassianはそれを推奨していないのでは。 JIRAに死を | TechCrunch Japan https://t.co/YfCfN4F9GW"

akipiiさんのツイート: "Redmineのチケットも同じ。「デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

akipiiさんのツイート: "「ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元するという考え方」「ソフトウェアプロジェクトをチケットの集合で表すという考え方」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

Takafumi Ikedaさんのツイート: "分かるよ。優れた要求仕様はエッセイのようになってるべきだと思う。ジョエルスポルスキーが言うみたいに。でもそうするといつ出来上がるのか予想できないプロジェクトになりやすいけど。経験上。 / “JIRAに死を | TechCrunc…” https://t.co/vzLYSENUZB"

Yamamoto hiroyukiさんのツイート: "ストーリーやタスクは完成しているかしていないかのいずれかと考えるのはアジャイルマネジメントのベストプラクティスだ。著者はそれに異論があるようだ。 | TechCrunch Japan https://t.co/9LjDHX09fI"

【感想】
Redmineのチケット機能はとても優秀だと思う。
理由は、チケット構造をツリー上に展開できるおかげで、WBSやタスクカードなどのような構造をチケットの関連として実現できるからだ。
WBSをチケットに一度登録できれば、ガントチャートであれ、ロードマップであれ、サマリであれ、好きなようにチケット集計のビューで色んな角度で分析できる。

しかし、チケット管理をやりすぎると、思ったほどの効果が出ない場合がある。
@arclampさんが以前、下記の記事を記載されていたのを思い出す。

チケット駆動開発で作業管理はしないほうがいい - arclamp

また、第11回東京Redmine勉強会のアンケート結果でも、「全てチケット化するのは非経済となるシーンもある点です」という声もあった。
たぶん、数多くの人たちが試行錯誤しながら、Redmineのチケット管理の可能性を試している。

個人的には、上記の記事のような指摘から発生する問題の根本には、チケットの粒度があると直感する。
WBSであれ、ソフトウェアやマスタの構造であれ、さほど複雑でなければ、少ないチケットの枚数で表現できる。
チケットの枚数が少ないならば、外部環境からの影響でチケットの構造に変化が発生したとしても、その修正コストはさほど大きくないし、受け入れられる。

しかし、WBSやソフトウェアの構造が複雑になり、チケットの枚数が非常に多くなれば、その構造を実現して、最新の現状と連動させるように同期し続けるのは非常にコストが大きくなる。
チケット保守のコストが大きくなってくるからだ。

ソフトウェア設計では、ソフトウェアの複雑さを複数のレイヤーで分割し、粒度や抽象度を上げることで、その複雑さを軽減しようとする。
チケット管理でも、チケットの親子関係や親子プロジェクト、バージョンなどの機能によって、大量のチケットをレイヤーで分割して、枚数を制限することで、チケット管理の保守コストを受け入れ可能なレベルまで落とす。

つまり、チケット管理が駄目なのではなく、複雑さをどのように手なづけるか、ということが本来の問題なのだと思う。
それは、ソフトウェア工学の古くからの問題であり、あちこちの場面で出てくる。

但し、Redmineのチケット管理では、複雑さを軽減するためのレイヤーとなる機能が限られている。
たとえば、親子チケット、関連チケット、親子プロジェクト、バージョン、カテゴリなどしかない。
それらの機能を増やした方が良いのか、それとも、それらの機能の使い方をもっと工夫すべきなのか。

今の僕の考えは、Redmineの既存の機能を使って、チケット管理の可能性をもっと研究してみたい。
まだまだ色んな可能性を秘めているはずだ、と思う。

| | コメント (0)

2016/12/23

Windows上でJRuby9+Redmine3.3.1を構築した時のメモ

Windows上でJRuby9+Redmine3.3をインストールした時のメモを残す。
自分用の参照。

【環境】
jruby 9.1.6.0 (2.3.1) 2016-11-09 0150a76 Java HotSpot(TM) 64-Bit Server VM 25.10
2-b14 on 1.8.0_102-b14 +jit [mswin32-x86_64]

Windows7+XAMPP

Redmine 3.3.1

【参考】
RedmineInstall - Redmine

Redmine本家の説明では「Redmine does not support JRuby because some gems do not support Rails 4.2」と記載されているので、Own your Riskということで。

【インストール】
C:\xampp\mysql\bin\mysql.exe -uroot -p
create database redmine331 character set utf8;

show databases;

cd redmineのルートディレクトリ

jgem install bundler --no-rdoc --no-ri

jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install activerecord-jdbcpostgresql-adapter

jruby -S bundle install --without test development sqlite3

jruby -S bundle exec rake generate_secret_token

jruby -S rake db:migrate RAILS_ENV=production

jruby -S bundle exec rake redmine:load_default_data REDMINE_LANG=ja RAILS_ENV=production

jruby bin/rails server webrick -e production

adminでログイン

環境は以下の通り。

Environment:
Redmine version 3.3.1.stable
Ruby version 2.3.1-p0 (2016-11-09) [java]
Rails version 4.2.7.1
Environment production
Database adapter MySQL
SCM:
Filesystem
Redmine plugins:
no plugin installed

個人のPCで使う場合は特に問題無さそう。
画面は通常に遷移できる。
但し、ログを見ると、Warningが数多く出ている。

Redmine3.3.1を構築したかったのは、DMSFプラグインを入れて、RedmineでISO9001のような運用が可能かどうか考えてみたかったから。

DMSF - Plugins - Redmine

danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf

また後で色々書く。

| | コメント (0)

2016/12/18

Pythonの記事のリンク~道具が理論にようやく追いついてきた

最近のバズワード「ビッグデータ」「機械学習」が知りたくて、Pythonの記事のリンクをメモ。
自分用の参照記事。
ラフなメモ書き。

【参考1】
Pythonでプログラミングを始めよう:新刊ピックアップ|技術評論社

(引用開始)
「もしコンピュータ言語をひとつも知らないのなら,まずPythonを学ぶことを勧める」。これは『How to become a hacker』(Eric S. Raymond著)の一節です。なぜ,Pythonを勧めるのか,それには様々な理由がありますが,筆者の経験や,世の中の動向を踏まえて説明してみます。
(中略)
工学系のエンジニアにとっても,プログラミングのスキルは設計作業に必要不可欠です。筆者もメーカーに勤務するエンジニアですが,入社以来様々な言語を使ってきました。シェルスクリプト,sed,Perl,C言語,C++,MATLAB/Simulink,Octave,Scilab,Mathematicaなど,作業内容に応じて使い分けています。テキストデータの整形をsedで行ったのち,C言語のプログラムから読み込んで処理し,その結果をMATLABで解析・可視化する,といった具合です。
(中略)
このような状況を変えつつあるのがPythonです。Pythonは,テキストデータの整形も,数値計算とその結果の可視化も得意です。すべての作業でPythonを使えば事足りる,という場面が多いのです。そのため,Pythonを使って設計をする機会が,日増しに増えています。

また,エンジニアにとって大切なことは,自分の設計内容や検討内容を完全に把握しておくことです。その点,MATLABのような有償のソフトを使うと,ライブラリのソースコードが公開されていないことが問題になる場合があります。Pythonと,Pythonの主要なライブラリの場合は,ほとんどがオープンソースプロジェクトです。そのため,すべてを自分のコントロール下に置いて,開発を進めることが可能です。
(引用終了)

(引用開始)
ディープ・ラーニングとビッグデータ解析での活用

次に,Pythonが実際に活用されている場面を見ていきます。

AlphaGoの快挙を支えたPython
ぶつからない車もPython!?
ビッグデータ解析でもPython
(引用終了)

【感想1】
R言語を色々触ってみたが、何か使いづらい。
たぶん関数型言語の特有の考え方に僕が慣れていなからだろう。
Pythonなら、RubyやJavaにも似ているので書きやすそう。

データの統計処理だけでなく、ファイル読み込み、グラフ表示、正規表現も一つの言語で処理できるのは便利。
プログラミングは歴史や英語のような暗記は不要だけど、APIの使い方とかテクニックは最終的には覚えるしか無い部分がある。

「エンジニアにとって大切なことは,自分の設計内容や検討内容を完全に把握しておくことです」という指摘は同意する。
「すべてを自分のコントロール下に置いて,開発を進める」ことが重要だから。
自分が使っている道具の特徴、癖を知っておかないと、自分が解決したい問題に適用する時に、落とし穴に落ちる時があるから。

道具の制約が、問題解決の可能性を制限する。
道具の制約が、問題解決の発想、アイデアの範囲や質を制限するから。

【参考2】
akipiiさんのツイート: "「断片的な情報を地図にまとめて大局的な視点を持つ」「人に何かやって貰いたい時は具体的に指示をだす」「今あるものを工夫して新しい道具を作り出す」といったエンジニアにとって大事なことがストーリーに織り込まれています。ルビィのぼうけんhttps://t.co/OaZHqw2E0w"

ルビィのぼうけん」のAmazon書評コメント欄に、下記のコメントがあってすごく納得した。

Amazon.co.jp: ルビィのぼうけん こんにちは! プログラミングの deko-papaさんのレビュー

(引用開始)
翔泳社の特設サイトで見つけて、帰宅途中で書店にて購入。10歳の娘に買って読ませてみました。
 夢中になって読んで、あっという間に前半のストーリー部分は読破。後半の練習問題は、夜遅かったので翌日へ。さらに寝るまでお母さんに読み聞かせを強請っていました。

 私はさわりの部分しかまだ読んでいませんが、それでも「断片的な情報を『地図』にまとめて、大局的な視点を持つ」「人に何かやって貰いたい時は、具体的に指示をだす」「今あるものを工夫して新しい道具を作り出す」といったエンジニアにとって大事なことがさりげなくストーリーに織り込まれているのが分かります。

 さらに、絵の中にさらっとプログラミング言語のキーワードが描かれています。もちろんそれについての説明は一切ありませんが、将来プログラミングに触れたとき、「あ!見たことある!」とこの絵を思い出す子どもが大勢いることでしょう。
(引用終了)

【感想2】
「プログラミングは実現したいことの手段に過ぎない」意見もあるが、僕はむしろ、プログラミングという道具が思考方法を規定してしまう側面の方を強く感じる。
既に確立した理論はあり、その理論の内容を実現したいのに、プログラミング言語やそのライブラリが貧弱であれば、やりたいことを表現するのにすごく手間がかかって、イライラしてしまう。

たとえば、配列やハッシュにデータを一時的に退避するとか、ファイルを読み込んで文字列を正規表現でマッチする部分を抽出するとか、そういうコンピュータの基盤に近い部分の処理は手短に書きたい。
そして、理論が本来言いたい部分をプログラミング言語で的確に表現したいのだ。

プログラミングにおいて、「断片的な情報を地図にまとめて大局的な視点を持つ」考え方は、理論で本来実現したい結果を得るための登山ルートを詳細に具体化する能力に対応するのではないか。
「今あるものを工夫して新しい道具を作り出す」考え方は、プログラミング言語とライブラリという「道具」で工夫して、理論で実現したい結果を得るためのアルゴリズムを作りだすのに使う、ことに相当するのではないか。

つまり、今ある道具を工夫する手間が少ないほど、コンピュータレベルではなく、もっと高次のレベルで物事を思考することが容易になるはず。

たとえば、統計学の理論は基礎数学で確立しているけれど、経済学者や心理学者は「大数の法則」「中心極限定理」「正規分布」などの定理や概念を数学的に証明するのに使いたいわけではない。
それらの定理や概念という道具を使って、経済現象や人間の心理現象を分析して、問題を解決したり、新たな観点をもたらしたいのだ。
昔は計算能力が貧弱だったので、統計処理はいかに簡便な手計算でやるか、という技術の説明をする本ばかりだったけれど、今は、優れたプログラミング言語やライブラリは揃っているから、計算処理はコンピュータに任せることが楽になった。

すると、理論がどのプログラミングのモデルに適用できるか、理論をどのプログラミングのモデルに適用すると手短にたどり着けるか、という考え方に発展するだろう。
つまり、問題のレベルが、単にプログラムが書ける、というレベルではなく、プログラムが表現するモデルが理論や現象を上手く説明できているか、というレベルに上がるだろう。
そこが面白くなってくる。

【参考3】
いまさら聞けないDeep Learning超入門(1):ニューラルネットワーク、Deep Learning、Convolutional Neural Netの基礎知識と活用例、主なDeep Learningフレームワーク6選 (1/2) - @IT

(引用開始)
 筆者がデータ解析に従事し始めた2010年ごろ、Deep Learningという言葉は一部のアカデミックな分野では流行していましたが、ユーザー企業でその言葉を聞くことはあまりありませんでした。

 今あらためて、Deep Learningの歴史をひも解いてみると、その歴史は決して明るいものではなかったことが分かります。Deep Learningの構成要素である、ニューラルネットワークとそれを単純に多層に組み合わせたものに関しては、それこそ1980~1990年代前後から盛んに研究されていました。しかし、その精度や処理量の問題から、同じく分類推定モデル構築によく利用される機械学習ロジックである「ベイジアンネットワーク」「サポートベクターマシン」の裏に隠れてしまい、冬の時代が長く続くことになったのです。

 再び脚光を浴びるようになったのは2000年代に入ってから。2006年にDeep Learningが発表され、その後2012年にトロント大学のHinton氏が「ImageNet」と呼ばれる画像セットを用いた画像識別コンペティションでDeep Learningを用いて2位以下を大きく引き離す精度を記録したことがきっかけです。このあたりからグーグルをはじめ、マイクロソフトやフェイスブックなどが注目し、ビッグデータのブームやGPUサーバーなどのハードウエア面の進化も伴ってDeep Learningは広くデータ解析者に広がっていきました。

 Deep Learningの最大のウリは何といっても、「人手で特徴量を抽出する必要がない」という点です。
(引用終了)

深層学習(ディープラーニング)を素人向けに解説(前編)―基礎となるニューラルネットワークについて

(引用開始)
ディープラーニングとは、適切な特徴抽出能力を持つ教師なしニューラルネットワークを多層にして構築したものです。
(中略)
まず、ディープラーニングを理解するためには、ニューラルネットワークを理解しなければなりません。逆に、ニューラルネットワークを理解してしまえば、ディープラーニングの概要自体はかなり分かりやすくなります。

ニューラルネットワークと言うのは、人の神経を模したネットワーク構造のことです。それを踏まえて、そう言う構造を持った人工知能のこともそう呼びます。このニューラルネットワークでは、神経細胞を模したパーセプトロンと言う小さな計算機をたくさん用意し、一つの計算を協力して行わせるように作られています。
(引用終了)

【感想3】
最近、囲碁でコンピュータが人間に勝ったニュースが流れたが、Deep Learningのアルゴリズムはニューラルネットワークであることは初めて知った。
30年以上前にニューラルネットワークは流行したけど、なかなか実用に至らなかった、という話は随分聞いた。
僕は、Deep Learningのアルゴリズムはベイズ統計かなと思っていたので、意外だった。

そんな話を聞くと、昔に確立した理論が、ようやく時代に追いついて花開いた、と感じる。
今ようやく、プログラミング言語の科学技術ライブラリ、統計処理ライブラリ、クラウドなどの開発基盤がそろってきたから、ニューラルネットワークのような理論が実際にプログラム上で実現できたわけだ。

ニューラルネットワークの理論は僕も詳細は知らないけど、古くから研究されて確立している理論なので、その理論をバックにした技術はそう簡単には廃れないだろうと直感する。
今後も、たくさんの応用用途も見つかるだろう。

実際、Deep Learningは、車の自動運転、顔認証システムなどにも使われている。
アイデアさえあれば、もっといろんなことが出来るはず。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

【感想4】
僕は「新しいアイデアとは、古いアイデアを新しい場所に置いたアイデアのこと」という言葉が好き。
既に知られた理論や知見(例:統計学、ニューラルネットワーク)は、新しい場所(例:人工知能、深層学習、自動運転、顔認証)で使われると、新たな発見を呼び起こす。
そういうことをやってみたい。

| | コメント (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/12/06

品質保証部はソフトウェア組織のボトルネックなのか、ソフトウェアチームに同化すべきなのか

平鍋さんの記事を読んで、品質保証部はアジャイル開発のボトルネックなのか、必要な組織なのか、いろいろ考えてしまった。
主張のないラフなメモ書き。殴り書き。

【参考】
QA to AQ: Quality Assurance から Agile Quality へ - Qiita

HARADA Kiroさんのツイート: "明後日開催です。英語で開催ですが、ゆっくり質問の時間はありますので、ぜひ。/ "品質保証からアジャイル品質へ入門コースー品質もアジャイルになるための価値、プラクティス、パターンー" https://t.co/m9eXSwIExq @Eventbriteさんから"

(引用開始)
よくアジャイル開発についての質問で、「品質保証はどうするのですか?」と聞かれることがあります。
日本の大企業の中には「品質保証部」という組織があり、そこが出荷判定をしたり、最終的な製品のQA(Quality Assurance)についての責任を持つことがあります。
その部署が、現場のアジャイル開発にどのように関わるのがよいのか、という質問です。
ひいては、メトリクスの取り方(既存の品質のメトリクスや、バグ収束曲線が当てはまらない)にはじまり、「どのタイミングで」、「どういった体制で」関わるのか、という質問です。
日本でアジャイル開発の導入が進まない、もしくは懐疑的に考える人が多いのは、この部分にあると思います。
(引用終了)

上記の指摘は、現場でよく感じる。
メーカーのソフトウェア子会社、メーカーの情報システム部門からスピンアウトしたSIであれば、品質保証部という組織が普通はある。

製造業では、品質保証部という部門はとても存在意義があるし、ものづくり日本の品質管理技法を発展させてきた輝かしい歴史があった。
しかし、ソフトウェア開発で品質保証部が絡むと、あまり良い話を聞かない。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

製造業では、3S活動によって、生産プロセスを単純化→標準化→専門化して、製品や生産工程の品質のばらつきを無くす。
そして、その活動をQCストーリーに落とし込んで、PDCAサイクルに組み込んでいく。

製造業の生産プロセスでは、品質が安定した製品を大量生産するために、プロセスを標準化する。
標準プロセスを作るために、各工程の作業へ細分化して、各工程の仕掛品の品質をチェックして、品質のばらつきを原因特定して解決していく。

しかし、ソフトウェア開発では「プロセスの標準化」という活動が有効に活用できない。
正直、効果が出ているとは思えない。
システムのインフラ、開発環境、プログラミング技術が日進月歩で変わるために、その変化に標準化活動が追いつかないのだ。
むしろ、古くなった開発プロセスを現場に押し付けるような立場になっていると思う。

では、ソフトウェア開発では品質保証という部門は不要なのか、と言われるとそうでもない。
SIにいると、形骸化した品質保証部の代わりに、開発案件の受注時の見積りレビューやリリース判定を行う役割をPMOのような組織が肩代わりしている場合が多い。
たとえば、見積りやプロジェクト計画が甘くないか、リリースしてクレーム対応に追われるリスクがないか、などを精査する。
つまり、製品の出荷判定を品質保証部がチェックするように、PMOがリリース判定を行っている。

そのPMOは、製造業のISOシリーズのように、CMMIなどの標準プロセスを策定して、ソフトウェア品質を確保しようとするが、実際はなかなか上手くいかない。

では何が違うのか?
ぼんやりしていて、その理由ははっきり分からない。

但し、上記の記事を読むと、「品質保証部」対「開発チーム」という牽制の関係ではなく、2つの組織をばらして、品質保証部メンバーが開発チームに混じって作業する方が上手くいく、という指摘をしているように思える。

つまり、運用チームと開発チームが組織的に分割され、チームが牽制し合うことで不正な作業をチェックする仕組みではなく、昨今のDevOpsのように、チームをシャッフルして、ペアプロのように共同作業していく方向性が良いと示唆しているように思える。

日本人も日本の組織も、QCサークルのような文化があったのだから、本来はペアプロのような共同作業は、日本人にフィットしているはずだと思う。
日本人は本来、トップダウンによる変革よりも、ボトムアップによる改善の方が向いているのだろうと思う。

しかしながら、そのやり方は、IT全般統制のような法律があるがゆえに、日本ではなかなか浸透できない現実もある。

ITに係る全般統制とDevOpsの緊張関係: プログラマの思索

昨今は、組織的不正を行わないように、組織が互いに牽制し合うように組織構造を作ることを勧められているために、日本の現場にそのような風潮を取り込むと、各組織の意思決定が部分最適化しすぎてしまい、全くうまくいってない。
なんだかな~と思ったりもする。

少なくとも、IT業界における世界の潮流は、サイロ型の組織構造をばらして、小さなチームに編成し直し、アジャイルに行動する方向へ進化している。

組織構成の考え方を変えれば、その潮流に乗れば、日本のソフトウェア組織も適応できるのではないか?
品質保証部はソフトウェア組織のボトルネックではなく、ソフトウェアチームの一部分に同化できるのではないか?
すると、ソフトウェア開発では、品質保証部は解体されて、ソフトウェアチームに同化されるべきではないか。
たぶん、DevOpsもその流れ。

この妄想をいろいろ考えてみる。

| | コメント (2)

Unofficial Redmine CookingプロジェクトでRedmineカスタマイズのノウハウを皆で集めてみよう

第11回東京Redmine勉強会で告知した通り、Unofficial Redmine Cookingプロジェクトが始まった。
これは、熱いRedmineユーザによる、Redmineをカスタマイズする非公式プロジェクト。
下記のサイトで見れる。

【参考】
概要 - Unofficial Redmine Cooking - redmine.tokyo

第11回勉強会 - redmine.tokyo

【Unofficial Redmine Cookingの目的】
@akiko_pusuさんの解説が分かりやすい。

Redmineを読み取り専用にしたいけど、どうしよう? - Qiita

(引用開始)
Redmineを運用されている方は、少なからず公式サイトでは載っていないような一部改造・カスタマイズするといった経験はお持ちではないかと思います。そういったノウハウを蓄積して、各自がRedmineをより効率的に活用できることを目指したサイトになります。

この記事は、上記サイトのアドベントカレンダー企画への参加として書かせていただきました。

過去の経験を元にしていますので、今ではもっと便利な方法があったり、クラウド環境だから気にしないという方も多いと思います。
「わたしの環境ではこういう方法を取っていますよ!」というのもあれば、ぜひコメントなどいただけると幸いです!
(札束で解決、というのももちろんOK!)
(引用終了)

【興味深い内容】
いくつかのチケットは興味深い。

【1】QA #252: メンテナンス / 移行 / バージョンアップのためRedmineを読み取り専用にしたい - Unofficial Redmine Cooking - redmine.tokyo

「サーバの移転・移行により新サーバにデータを同期させる間、データの整合性を担保するため、Redmineの参照は許可するけれど、更新は全て止めたい」ような運用をしたい。
Redmineを普通のミッションクリティカルなWebシステムと同様に運用したいわけですね。

Redmineを読み取り専用にしたいけど、どうしよう? - Qiita

【2】QA #246: Redmine 管理-「トラッカー」-「サマリー」の表示枠を固定にしたい。 - Unofficial Redmine Cooking - redmine.tokyo

サマリ画面のトラッカー・標準フィールド・カスタムフィールドの表示(ヘッダ行)を固定するように、Excelのウィンドウ固定機能を実現させたい。
確かに、この機能があれば、Excelライクに扱えるので便利。

Redmine本家には既にパッチがあるらしい。

Patch #20287: Administration: Using grids instead of tables - Redmine

【3】QA #254: ガントチャートの画面上で直接編集したい - Unofficial Redmine Cooking - redmine.tokyo

この要望はすごく多い。
MSProjectに慣れているほど、似たような機能が欲しくなる。

この改善要望は、Ver0.8の頃から、一部ユーザがパッチを提供していたが、今の最新バージョンにパッチはない。
たぶん、RubyよりもJavaScriptのプログラミングがすごく必要。

Feature #2024: gantt chart editing - Redmine

最終的には、有償プラグインを入れるしかないと思う。

【4】QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

社内に野良Redmineがたくさんあって、統合したい機運が高まった時、このノウハウは参考にしたい。
但し、野良Redmineの数が多くなると移行リスクが高くなるので、アジャイルウェアさんに依頼することになるのかな?

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

【5】QA #237: Redmineカスタムフィールド表示改善(CF1列表示、項目見出し、表示調整) - Unofficial Redmine Cooking - redmine.tokyo

QA #231: チェックボックスのカスタムフィールドを2列で表示したい - Unofficial Redmine Cooking - redmine.tokyo

チケットにカスタムフィールドをたくさん追加すると、レイアウトを色々変えたくなってくる。
テキストエリア欄を広くしたり、チェックボックスの配列を変えたり、とか。
ソース修正パッチ以外にも、ViewCustomizeプラグインで対応する方法もあるだろう。

Redmineの画面レイアウトの微修正にこだわる改善要望はViewCustomizeプラグインを使え!: プログラマの思索

【6】QA #241: カテゴリをサブプロジェクトで継承利用したい(バージョン同様) - Unofficial Redmine Cooking - redmine.tokyo

この要望は随分前からあがっていた。
この要望が実現されていないために、カテゴリ機能はほとんど使われない組織も多いのではないか。
そろそろRedmine本体でも実現して欲しい。

Feature #5358: Share Issues Categories for sub-projects - Redmine

【7】QA #251: チケットにユーザ情報の値を表示させたい - Unofficial Redmine Cooking - redmine.tokyo

REST API経由でTableauに読み込ませる運用をしているので、Redmine本体のチケットの属性(カスタムフィールド)に作出属性を保持させた方が運用が楽、という意図らしい。
確かに、Redmine本体のカスタムフィールドで作出属性を保持できれば、外部システムで集計する処理が楽になるだろう。

そんな機能を実現するcomputed_custom_fieldプラグインが使えるといいが、上記のコメントを見ると上手く使えないみたい。

Redmineのカスタムフィールドを導出属性にしてしまうプラグインredmine_plugin_computed_custom_field: プログラマの思索

【8】いくつかのチケットには、Redmine本家のコントリビュータである@g_maedaさんのコメントも見られる。
こういう場で蓄積されたアイデアやパッチが、Redmine本家に届けられたらいいなと思う。
もし気に入った機能改善があれば、Redmine本家のチケットに「+1」を追記して、その思いをJPLに届けてほしいと思う。

| | コメント (0)

2016/12/05

Redmine3.1のプラグイン一覧が参考になる

Redmine3.1のプラグイン一覧の記事がとても参考になるのでメモ。

【参考】
Redmineを3年間使い続けてお世話になったプラグインたち - Qiita

【1】Ver3.1.1で、下記のプラグインをインストールしたらしい。
少なくとも、これらプラグインは正常に動作したみたい。

clipboard_image_paste
easy_gantt
progressive_projects_list
redmine_absolute_dates
redmine_agile
redmine_backlogs
redmine_banner
redmine_checklists
redmine_code_review
redmine_default_custom_query
redmine_gantt_with_date
redmine_issue_templates
redmine_issues_summary_graph
redmine_issues_tree
redmine_japanese_help
redmine_maintenance
redmine_pivot_table
redmine_slack
redmine_wiki_extensions
redmine_wiki_lists
redmine_work_time
sidebar_hide

【2】いくつかのプラグインは、Ver3.3ではデフォルト機能に含まれているので、不要になる。
たとえば、redmine_gantt_with_date, redmine_default_custom_query とか。
また、farend_fancyテーマを入れれば、redmine_absolute_dates は不要になる。

【3】幾つか参考になる点がある。

【3-1】まず、redmine_backlogsプラグインは、「feature/redmine3」ブランチであれば、3.xでも動作したらしい。
この情報はありがたい。

(引用開始)
(redmine_backlogsは)
↓↓↓Redmine 3.xの場合は、「feature/redmine3」ブランチのものでないと動かないです。
https://github.com/backlogs/redmine_backlogs/tree/feature/redmine3
(引用終了)

【3-2】有償プラグインを提供しているベンダーの無償プラグインeasy_gantt、redmine_agileの感想も参考になる。
ガントチャート画面上で編集できるだけでもありがたいし、かんばんがRedmine上で使えるのも便利だ。

とはいえ、ガントチャートにMSProject並の操作感や、もっと高機能なかんばんが欲しくなれば、Lycheeなどの有償プラグインが必要になるだろう。

【4】「あとがき&ふりかえり」の文章が、とても心遣いが溢れている。

(引用開始)
プラグインを入れると実現したいことが叶います。
一方で、Redmine管理者の保守工数は増え、利用者には覚えてもらう操作が増えます。
プラグインを入れるだけでなく、プラグインを削除することも時には大事だと思います。
 
誰のためのプラグインなのかを考えることは重要です。
経営層やマネジメント層の声の力は強いかもしれませんが、週1や月1でしか使われないような目的のためよりも、毎日Redmineを使っている現場の人の声を大事にしたほうがいろいろと幸せになれます。
 
何のためのプラグインなのか、何のためのRedmineなのかを忘れてはいけません。
Redmineを使い始める以前のやり方を堅持するために、さまざまなプラグインを駆使するのはオススメしません。
可能ならば、人や業務にシステムを合わせるよりも、システムに人や業務を合わせることをオススメします。
(引用終了)

Redmineのようなツールに触れると、それにのめり込んでしまう。

たとえば、様々な人達の要望を取り入れて、プラグインを入れて、どんどん高機能化したくなる。
あるいは、組織やチームのワークフローを己の考えに従わせたくなる。
自分の理想のプロセスを実現すべく、Redmineをどんどんカスタマイズしたくなる。
Redmineのシステム管理者の保守工数もバカにならなくなる。

そんな時に、ふと足元を振り返って、Redmineの目的を思い出すのも大切なのだろう。

| | コメント (0)

AgileTourOsaka2016の感想

AgileTourOsaka2016に行ってきた。
知り合いも多くて居心地の良い場だった。
感想をラフなメモ書き。
メモを殴り書き。

【参考】
Agile Tour Osaka 2016 2016年12月3日 - こくちーずプロ(告知'sプロ)

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

【公開】AgileTourOsaka2010講演資料 "Why Ticket Driven Development is Agile? : No Ticket, No Commit!" #agileto2010 #tidd: プログラマの思索

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

【1】パターンの中で「デザインパターン」は最も有名だが、「デザインパターン」の最初に「これはパターン言語ではない」とはっきり述べている。
パターンとパターン言語は違う。

パターン言語は、もっと広い概念。
パターン言語は、全体性が特徴、と原田さんは言う。

【2】Scrumパターンは、「組織パターン」から生まれた。
7年経った今もなお作成中。
来年に完成すればいいね、という感じだね、と。

Scrumパターンを見ると、「防火壁」はスクラムマスター、「顧客の代弁者」がプロダクトオーナー、「ワークキュー」はバックログ、「スタンドアップ・ミーティング」はデイリースクラムという概念が自然に出てくる。
組織パターン」から、プロダクトオーナー、スクラムマスター、プロダクトバックログの概念が生まれた。

Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary

Scrumパターンは、パターンがつながっていて、一つの言語(ランゲージ)になっている。
つまり、パターン名を言えば、パターンの発生源となる問題や背景が自然に出てきて、人々で共有される。
パターンで問題解決されると、新たな課題が発生し、別のパターンが使われる時もある。

【3】アンチパターンはパターンなのか?
アンチパターンはパターンではない。
アンチパターンはパターンのコンテキストを表すものでしかない、と。

【4】パターンはベストプラクティスではない。
パターンは「Good practice」である、と変えた、と。

【5】パターンの中で、Forceを書くのが一番難しい。
Forceは、パターンの背後にある、利害関係者の力の衝突を表す。
たとえば、プロジェクトが遅延しているから作業方針を変更したいのに、マネージャが駄目だ、と拒否権を発動する場合、とか。
Forceはトレードオフを表す。

だから、パターン、コンテキスト、ソリューションを書くのを勧めている、と原田さんは言う。

この意見には、僕は違和感を持っていて、別の意見を持っている。
むしろ、経験者はForceから書き出した方がいいのではないか、と思っている。

実は、午前のプレセッションで、パターン・ワークショップがあり、Scrum道関西で有名な山本雄一郎さんたちと同じチームで、パターンを洗い出そうとしていた。
すると、僕も山本さんも、いきなりパターン名やソリューションを出したものの、そこから話が進まない。
コンテキストや問題がメンバーの間で違うので、議論が発展せず、深掘りされなかった。
結局、時間切れで、僕らのチームは、パターンを作り出すこともできなかった。

プロジェクト運営の経験があり、何らかの問題に対して自分なりのソリューションを持っている人は、パターン名らしき概念を既に持っている。
そんな場合、パターン名やソリューションを書き出した後、そのソリューションが使われる背景(コンテキスト)や、Forceのような力関係を洗い出し、そこから、もっと他のソリューションがあるのでは?、他の問題が出てくるのでは、という方向へ議論しても良かったのでは、と後で感じた。
なぜなら、自分が持っているソリューションのコンテキストを説明しようとすると、過去の案件ではこんな対立があった、とか、以前のチームではこんな人間関係があって対立していた、と言う内容を説明しやすくなるからだ。
経験者が持っていたリアルな現場感を伝えるために、Forceを使うわけだ。

なお、原田さんからは、もっとパターンを抽象的にしたら、というアドバイスをもらった。
その意味を考えると、ソリューションにこだわりすぎて、パターンというもう一つ上のレベルへ抽象化できなかったのではないか、と思う。

【6】チームでパターンを作った後、どうするか?
チームで、あるノウハウに名前(パターン)が付くと、良い傾向。
チーム内の良い習慣を、パターンで共有できる。

「おやつ神社」と言えば、日本人なら分かるでしょ?
ふりかえりミーティングでは、お菓子を持ち寄り、くつろいだ雰囲気を醸し出す、と。

僕も、チケット駆動開発のプラクティスをパターンとして表現できないか、狙っている。
今、日本各地でRedmineエバンジェリストの役割を担う人達が出現しているので、彼らのノウハウをパターンという名前で具体化して、皆で共有できるようにしたいのだ。

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

つまり、皆がバラバラに持っているノウハウをパターンとして抽出して、パターンカタログのような形式でまとめたい。
パターンはカタログではない、という意見があるのは重々承知だが、ボトムアップで経験知を整理して、誰もが共有できる形式知にしたい。

【7】その意味では、欧米人はネーミングが上手い。
同じような概念を時代に合わせて再パッケージングして、いかにも新しい流行のようなワードを作り出し、世の中に広めている。
アジャイル開発やXPのプラクティスは以前から知っていた、と日本の年上の技術者は誰もが言うが、僕ら若手はそんな技術はつゆ知らず、むしろ、アジャイル開発やXPを知って、すごく興奮した。

似たような例はたくさんある。
日本の製造業の品質管理(TQM)に対するシックスシグマ、トヨタ生産方式に対するリーン生産方式、ソフトウェア再利用の設計に対するマイクロサービスアーキテクチャ、とか。

日本から独自のパターンを生み出せないか?

【8】長沢さんに、エバンジェリストはどんな役割なのか、を聞いた。
彼の回答は明確で、「エバンジェリストは市場を作る人である」と。
僕のイメージは、エバンジェリストはツールや製品を宣伝する人と思っていたから、その固定観念を打ち砕かされて、しびれた。

また、キャズム理論や製品プロダクトライフサイクル理論では、市場の立上げ・成長期・成熟期・衰退期に応じて、イノベータ、アーリーアダープター、マジョリティ、ラガードなどの市場参加者の種類がある。
その中で、エバンジェリストは新しい製品を市場に導入して、パイを広げるべきと思っていたから、イノベータやアーリーアダープターに専念すべきと思っていた。

しかし、長沢さんによれば、エバンジェリストは市場の全体の人達にフォーカスする。
特定の人達にフォーカスするのではない、もっと広い層の人達に伝えるべき、と。

さらに、ツールや製品にこだわるべきではない。
一段上のレベルで話をすべきである。
ツールや製品は流行り廃りがある。

エバンジェリストは新しい技術の動向を伝えるだけでなく、それによって市場を拡大するように、方向性を示すべき、と。
だから、自分は、マイクロソフトやアトラシアンの製品だけにこだわってはいない、アジャイルやプロセスの話をしている。
RUPの頃から何も変わっていない、RUPにも既にアジャイルやDevOpsの萌芽はあった、と。

| | コメント (0)

« 2016年11月 | トップページ | 2017年1月 »