第15回redmine.tokyo勉強会の見所

第15回redmine.tokyo勉強会の見所をラフなメモ。

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

第15回redmine.tokyo勉強会 - connpass

第15回redmine.tokyoの見所　マドびっ！ Madosan's View

（引用開始）
redmine.tokyo の第15回勉強会を開催します。 今回のテーマは『出るぞ４．０！Redmineの活用ノウハウをみんなで共有しよう！』です。

昨年のメジャーバージョンのリリースから1年経ち、今年末頃にVer4.0がそろそろリリースされるようです。 そこで、次期バージョン４．０のリリース前祝いとして、Redmineの活用事例やより良い使い方のノウハウに関する勉強会を行います。

具体的には下記になります。

・次期バージョン４．０の機能紹介
・Redmineを利用する組織能力向上の事例
・RedmineとJiraの機能比較に関する事例
・LT枠を大幅増枠して、Redmine活用ノウハウに関する「大LT大会」

グループディスカッションでは、Redmineの初心者も気軽に質問できたり、Redmine経験者の経験談を共有できる場を設けます。 是非、参加者同士で、Redmineの疑問点を質問したり、運用ノウハウや技術ノウハウを共有してみて下さい。
（引用終了）

【1】勉強会の内容は、講演者5名、LT10本（増えるかも？）なので、Tipsやアンチパターン、運用事例、最新機能紹介など幅広くなった。
最近は参加者が多いので、多様なユーザのニーズに答えられるだろうと思う。

個人的に興味があるのは、いくつかある。

【2】@onozatyさんの講演「View customize 1.2.0 の紹介」では、ViewCustomizeプラグインのカスタマイズ事例が説明される。
Redmineの画面UIを即座にカスタマイズしたい時、ViewCustomizeプラグインは必須なので、いろんな利用事例がユーザ同士で共有されるといいな、と思う。
ちょっとした画面UIの改善は、特に、Redmine導入時や、運用の推進に大変役立つから。

【3】@MadoWindaheadさんの講演「redmine導入における効果的なヒント 組織の成長と難敵に対応する作戦と特技ついて」は、「Sqip2018 チームビルディングにおける心理的障壁の傾向と緩和策の提案」の改訂版と聞いている。

Sqip2018 チームビルディングにおける心理的障壁の傾向と緩和策の提案 from Asako Yanuki

asakoyanukiさんはSEPGで標準化を推進する立場として、たぶんたくさんの苦労されていると想像する。

（引用開始）
Redmine.tokyo勉強会で行われるグループディスカッションでは、参加者同士が 現場での問題や悩みごとを話し合う。
⇒ Redmineの利用の仕方よりチームビルディングに問題あり
A：チームの成熟度の問題 B：上司が問題 C：ツールリテラシーの低さ など
⇒Redmineの利用の仕方よりチームビルディングに問題あり
（引用終了）

上記の資料を読むと、Redmineの利用推進よりも、チームビルディングに問題があった、という指摘が非常に面白いと思った。
組織構造や個人の能力が問題ではなく、チームの成熟度に真因があったわけだ。
おそらく、現場の問題がたくさんあって、Redmineを上手く使えば、それら問題はある程度解決できるはずなのだが、チームとして未成熟なため、なかなか運用が根付かない、という状況があるのだろうと推測する。
そういう問題を、チームの成熟度のレベルに合わせて、解決方法を変えて実施する、という話なのだろう、と思う。

そういう話を聞くと、リーダーシップのSL理論（状況対応型リーダーシップ）を連想させる。

SL理論 ? リーダーシップインサイト

リーダーシップのSL理論とは

つまり、プロジェクトリーダーはメンバーの成熟度に応じて、リーダーシップの発揮方法を変えるべきである、という古典的理論。
おそらく、Redmine運用の方法も、チームの成熟度に合わせて、指示的→コーチング→支援→権限委譲のようにかわっていく、いやむしろ、変えていくべき、という発想になると思っている。

【4】@forenoonMさんの「Redmine使いが注目したJIRAの機能」も興味がある。
「Redmine使いが業務でJIRAを使って注目した機能を紹介します。」という紹介がすごく興味がある。

世界的にはRedmineよりもJiraの方が有名だし、有償ツールのため、機能も豊富。
しかし、僕自身としては、RedmineにはOSSだからこそのメリットが多々あると思っている。
日本でRedmineが広がっている理由には、ネット上に数多くの情報があり、ユーザコミュニティが活発であることもあると思う。

その場合、他のチケット管理ツールのベストプラクティスやTipsをRedmineにも横展開できるはずだし、Redmineの使い方をより進化させてくれるはず。
そんな事例かな、と思っている。

【5】他にもたくさんのLTがあるので楽しみ。

なお、最後に僕もちょっとだけLTさせてもらう予定。
Redmineコミュニティを通じて、僕も、オープンソースとの関わり方、コミュニティを持続させていくのに必要な心構え、などをたくさん経験させてもらった。
そこで、東京と大阪のRedmineコミュニティに携わる一スタッフとして、今後のコミュニティはどうあるべきか、私見を述べてみたいと思った。

Redmineのバージョン機能に別の意味を与える改善に関するアイデア～バージョン機能はリズムという恩恵を利用者にもたらす

Redmineのバージョン機能に別の意味を与える改善チケットが起票されていた。
以下、ラフなメモ書き。

【参考】
機能＃17907：バージョンに別の意味を与える - Redmine

（Google翻訳開始）
Redmineはプロジェクト管理に適しています。しかし、実際のソフトウェア開発だけでなく、だから、バージョンはソフトウェア開発プロジェクトではあまり意味がありません。

私の提案：バージョンがバージョンかマイルストーン、ターゲット、フェーズ、ステージなどであるかどうかをユーザーに選択させる。

実現は非常に簡単です。'バージョン'のタイプを指定する別のフィールドを追加するだけです。ユーザーがドロップダウンで選択する必要のあるバージョンを作成する場合は、そのタイプを選択します。理想的には、いくつかのアイコンを追加して、ロードマップなどのバージョンタイプを視覚化することができます。

さらなる開発では、バージョンタイプを構成可能にすることができます。しかし、これは私の場合はそれほど重要ではありません。私は人がバージョンを使うのが好きではないことに気付くだけです。これがちょうど別の名前を持つことができるのであれば、はるかに明確になります。
（翻訳終了）

【１】僕にとって、Trac、Mantis、Jiraなどの他のITSの運用では分からず、Redmineを運用して初めて理解できた機能が「バージョン」だった。
つまり、Redmineの「バージョン」をXPのイテレーション、Scrumのスプリントとして扱う事で、タイムボックス的なアジャイル開発プロセスを簡単にRedmine上で実装できる。

脱Excel！ Redmineでアジャイル開発を楽々管理 (1/5)：エンジニアがお薦めする 現場で使えるツール10選（3） - ＠IT

しかし、この事実に気づいて運用して以来、１０年も経つと、もっと色々考えたくなる。

【２】上記の改善チケットでは、「バージョン」の名称をユーザが選択できる機能を追加することを提案している。
理由は、ソフトウェア開発以外の場面で、タイムボックス的なプロセスを実現したいからだ。

僕自身は、ソフトウェア開発では、バージョンとマイルストーンは一致させる運用で良いと思う。
開発チームは、本番リリースの運用サイクルを起点とし、本番リリースのサイクルを自分たちの開発リズムとして捉えれば良い。
なぜなら、ソフトウェアにとって本番リリースすることが、顧客にビジネス上の価値をもたらし、開発チームに売上をもたらすので、本番リリースのタイミングを「バージョン」として名付けて、その開発リズムを大切にすることが重要だからだ。

むしろそれ以外の、たとえば、上司への月次の定期報告のようなマイルストーンは不要だと思っている。
本番リリースに直結しない報告タイミングなど、タイムボックスとして無意味だからだ。

【３】一方、ソフトウェア開発以外の利用シーンでは、バージョンという言葉が適合しにくい場面があるのは確かだ。

たとえば、「入門Redmine」に掲載されている事例として、毎年の農業の作業履歴をチケットとして記録し、四季や月ごとにバージョンを設定している事例があった。
すなわち、農業の「タイムボックス」は四季や月が相当するわけだ。
同様に、その他の業務でも、「タイムボックス」を表す名称として、マイルストーン、フェーズ、ステージなどの言葉の方がしっくり来る時もあるだろう。
そうであれば、ja.ymlで「バージョン」に該当する文言は、各業務のタイムボックスを表す名称に一括置換した方が、ユーザフレンドリーになるだろう。

【４】僕は、Redmineのようなチケット管理システムでは、「バージョン」という機能は単なるチケットを分類する機能ではなく、チケットにタグ付けする機能でもない、と思う。

チケット管理システムの「バージョン」は、利用者にチケット運用の「リズム」という恩恵をもたらす。
そのリズムがあるからこそ、チケット運用はスムーズに流れるし、そのリズムが心地よいと感じる。
そのリズムが生まれる背後には、タイムボックスという概念が隠れているからだ。

チケット駆動開発のモチーフ: プログラマの思索

TiDD：チケット駆動開発: ソフトウェアさかば

[TiDD] 出版裏話１：没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -: ソフトウェアさかば

（引用開始）
実際、あきぴーさんとSPESの論文を書く際には「チケット駆動開発」以外の名前を検討するべく提案しました。

しかし、あきぴーさんの答えは明確で「チケット駆動開発」は譲れないとのこと。当時は、しぶしぶながら承諾しましたが、この理由は、のちに私がチケット駆動開発を実践してみて、ようやく分かたのでした。それは

　　チケットがプロジェクトをテンポ良く推進してくれる

ということです。本の中では「リズム」と言う表現をしていますが、チケット駆動開発を実践していると、

　朝：チケット一覧を見て、作業計画を立てる
　昼：チケットの作業を順にこなしていく
　夕：チケットの進捗を登録する(完了チケットのクローズ)

という、開発パターンに体がなじんで、プロジェクトがリズミカルに進んでいきます。これは、体験してみないと分からない感覚でした(もし、チケット駆動開発を実践しているのに感じられないなら、備忘録のような細かなチケットをもっと発行してみてください)。

この「リズム」を感じる個人のプロセスは、チケット駆動開発のアジリティとも関係する大切なものです。ぜひ、チケット駆動開発を実践して体験してみてください。
（引用終了）

一方、そういうリズムが感じられないチケット管理システムは、単なる強制ツールに過ぎない。
タイムボックスという概念のないRedmineは、運用していてもたぶん楽しくないだろう。

上記の改善チケットが生まれる背後には、Redmineの利用シーンがソフトウェア開発以外にも広がっている事実が世界中で発生していることを示唆していると思う。
ソフトウェア開発以外で、そういうリズムが感じられるRedmineの利用事例も集めてみたいと思う。

組織文化はトップが作るのか、ボトムアップで作られるのか

僕はアジャイル開発が好きなので、組織文化はメンバーから自然発生的に作られるものと思っていた。
でも、組織論を勉強していたら、そうではないらしい。
今の自分が理解できたこと、考えたことをラフなメモ書き。

【参考】
制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

【1】トップがリーダーシップを発揮しすぎている場合、メンバーや社員は言われるがままの存在で自発的になっていない状況が多い。
トップがリーダーシップを発揮せざるを得ない組織文化になっている。
そういう組織文化を作った責任は誰にあるか？

組織文化を生み出す責任は社長にある。
もっと社長が汗をかけ。

従業員の意識変革は、従業員ではできない。
社長が自ら説明し、共通目標を掲げ、貢献意欲を引き出し、コミュニケーションを円滑化させなければ、組織文化は変わらない。

つまり、組織文化はそう簡単に作れないし、変更もできない。
その会社の歴史から生まれた側面の方が大きい。
いわゆる、経路依存性。

組織文化は、今までの会社の経営の中で、こんないいものがあったではないですか、と社長に気づかせる方が大事。

一方、組織構造は思い切って変更できる。
たとえば、会社の特徴として商品企画が弱いなら、思い切って商品企画の部署を作る。

たとえば、生産工程ごとの機能別組織では、市場の変化に即応できないならば、事業部制組織へ思い切って変更してみる、とか。

つまり、組織文化は社長に優しくアドバイスし、組織構造は思い切って変更して下さい、と社長に諫言する。

この発想は、マッキンゼーの７Sフレームワークがよく当てはまると思う。
組織のハード部分は思い切って変革できるが、組織のソフト面は、浸透に時間がかかる。

【2】企業における人事施策は、会社全体の人事施策として策定してはいけない。
従業員層ごとに人事施策を細かく分けて策定する必要がある。

たとえば、正規社員と非正規社員では、人事施策が全く違う。
正規社員には能力向上や人材育成、非正規社員にはすぐに辞めさせないような仕組みとして、衛生要因の対応やモラール向上、人材の確保の観点になる。

たとえば、女性社員と新人社員では、人事施策が全く違う。
新人社員には人材育成の観点で能力開発、女性社員には人材確保のため、時短制度や出産後の仕事復帰の支援制度など衛生要因への対応が重要になる。

あるいは、管理職とヒラ社員でも違う。
管理職には、社長が考える経営戦略を理解してもらい、自分の持ち場で部下にその内容を伝えて共有してもらう、という制度的リーダーシップを発揮する役割がある。

【追記】
門屋浩文@redmineparty🌅さんのツイート: "製品特性で組織体系が変わるから 例えば鉄道会社がボトムアップで文化が作られるのは個別の部分ではあるかもしれないけどトップダウンが多いでしょう 芸術系ならトップダウンは絶対ないでしょう… "

akipiiさんのツイート: "芸術系でもソフトウェアベンチャー企業でも、社長が、社員個人が自由に能力を発揮できるような環境（ファシリティ）を作っているから、とか、自由にコミュニケーションを取っていいよ、と言う組織文化を許しているからでは？　組織文化は社長が作っている、という気が最近してます。… https://t.co/3qSXWFqhMO"

門屋浩文@redmineparty🌅さんのツイート: "なるほど、そうかもしれない 理解があるから環境、文化を作るような… "

akipiiさんのツイート: "川端さんの会社や倉貫さんの会社を見てると、社長がソフトウェア企業に合った組織文化を知っていて、あえてそういう組織文化を作り出してる気がしました。それを知らない社長はたぶんソフトウェア開発に向いた組織文化も組織形態も理解できてないのかなと… "

やっさん🍶さんのツイート: "私もそう思います。ボトムアップな組織は、トップが権限を移譲させてボトムでも意思決定出来るように、ボトムを信頼出来る文化がもともとあるような、初期の段階からトップが文化を形成してそれを「貫き通した結果」だと思います。 また、ボトム→トップへの移行は簡単に出来るけど、（続く）… https://t.co/xzGUYkgqum"

やっさん🍶さんのツイート: "トップ→ボトムへの移行は、ボトムからは起こすのはとてつもなく難しいと思います（＆痛感してます。多分無理。） ボトム→トップを気づかせるのは、もともとボトムが出来てる文化じゃないと実行までは行かないかなぁと思います。自分の持ってる既得権益を手放せなんてトップ思考では出来るのかなと。… https://t.co/21O1quS1Xp"

第66回IT勉強宴会の感想～データモデリングに数多くの流派が発生している理由

先週土曜に、関西IT勉強会に行ってきた。
渡辺さんの話を聞きながら、日本で、なぜ、データモデリングに数多くの流派が発生しているのか、そんな理由が垣間見えた気がした。
以下は、とりとめもないラフなメモ書き。

【参考】
予算テーブルと実績テーブルを分ける？: 設計者の発言

方法論科学研究会（情報システム学会） ＜第66回IT勉強宴会in新大阪＞ | ＩＴ勉強宴会blog

【1】渡辺さんのデータモデリングの最大の特徴は、ER図に描かれるデータモデルは、関数従属性だけの観点で書き切ること。
つまり、あるべき業務イメージやあるべき業務フロー、あるべき組織構造とは全く無関係である点。
また、現状の業務フロー、現状の組織構造の観点も入れない。
あくまでも、関数従属性だけの観点でモデリングする。

こういう基本に忠実なデータモデリング手法は、実は普通ではない、という事実が、パネルディスカッションで明らかになったのが面白かった。

どうやら、熟練のデータモデラーも含めて、一般人も、関数従属性だけに従ったデータモデルを更に細かく分割するのが普通らしい。

例えば、小関さんのモデリング手法では、最初にAsIsの業務フローをヒヤリングしながら、頭の中ではデータモデルの項目群を関数従属性の束でまとめながら、ER図をイメージしていく。
そして、ToBeの業務フローを描く時に、データモデルを具体化して確定させる。

たぶん、普通のモデラーならば、小関さんと同じように、AsIsとToBeの業務フローを描きながら、ToBeのデータモデルを描くという同時並行スタイルが普通だろうと思う。

でも、渡辺さんのデータモデリング手法である三要素分析法では、業務フローのヒアリングはしない。
データモデルを描くためのヒヤリングに限定し、業務の問題点や課題、ToBeの業務イメージは聞かず、あくまでも関数従属性の情報だけを集めることに注力する。

【2】では、なぜ、渡辺さんは、そういう手法にこだわるのか？

なぜなら、データモデルをその場で聞きながらモデリングするためには、関数従属性の観点だけに絞った方がやりやすいから。
そこに、ToBeの業務イメージやAsIsの業務フローの話が混じると、モデルを描くという目的とズレた議論になってしまいがち。

聴衆の方からも、渡辺さんのライブモデリングを側から見ていると、切れ味が鋭くて気持ちいいくらい。
なぜなら、ユーザは自分が抱えている課題や問題点を他人に話したい習性があるので、モデラーにそれらをぶつけたい気持ちがあるが、それを表に出すと、渡辺さんはそれは議論の範囲外です、とバッサリ切ってしまう、と。
面白い。

また、そういうライブモデリングにこだわるもう一つの理由は、データモデルさえ確定すれば即座に画面UIが決まり、プロトタイプのシステムが作れるから。
そうすれば、ユーザにプロトタイプを見せて、早くフィードバックがもらえて、より明確なシステム像が見えてくるから。

【3】では、渡辺さんのデータモデリング手法では、あるべき業務やあるべき組織構造はモデルに表現できないのか？

実は、渡辺さんのデータモデリングである三要素分析法では、データモデルは関数従属性の束の観点に絞るが、業務を担当する組織構造や業務フローの要件は、機能や業務という別の側面で捉えて分析する仕組みになっている。
たとえば、三要素分析法では、「業務」「データ」「機能」の3次元の絵で説明される時が多いが、それらの次元の軸がそれに相当する。

つまり、業務システムは3次元の軸で実現されるものであり、データ軸はあくまでも関数従属性の束だけでよく、それ以外の要件はそれぞれの次元の軸で捉えれば良い。

この分析手法のメリットは、データモデルの構造とデータモデリング手法そのものがシンプルになること。
つまり、渡辺さんがこだわる「ライブモデリング」に大変適しているし、モデリング手法も関数従属性の束だけ考えれば良いので、業務知識を知らなくても描けるメリットがある。

一方、パネルディスカッションの議論を聞いてみると、TM手法（T字型ER）やTH手法では、データモデルにあるべき業務イメージや業務フローの要件も組み込んでいる。
おそらく、一般のデータモデラー、普通の設計屋もそういう手法を取るだろう。

しかし、そういうデータモデリングは多分、初級者や中級者には難しい。
あるべき業務イメージや業務フローを描くには、その業界の業務知識、あるいは簿記1級レベルの会計知識が必要にならざるを得ない。
また、そういう業務知識とデータモデリングの整合性を取るのは、相当難しいのだろうと思う。

【4】渡辺さんのデータモデリングを見ると、システム設計を多少でも知っている人ならば、違和感を感じる所がある。

たとえば、直近のメーリングリストでは、予算実績テーブルという、予算と実績の2つのデータが1つのテーブルにまとめてもよいのか、分けた方が良いのか、という議論があった。

渡辺さんのモデリング手法では、関数従属性の束の観点だけなので、ユーザのヒヤリングでそういう要件だけならば、予算と実績のテーブルに別々に分ける必要はない。
だから、他のデータモデラーから見ると、すごくFatなテーブル、太ったテーブルのように見えて、とても違和感がある。

予算テーブルと実績テーブルに分けるべきではないか、と。
疎結合の設計思想、クラウドとの親和性、データ管理のライフサイクルの観点では、予算実績テーブルで一つにまとめるのはおかしいのでは、と。

しかし、関数従属性の束だけの観点だけのデータモデリング手法の立場であれば、関数従属性がないのに、テーブルを別々に分ける方がおかしい。

渡辺さんが描くデータモデルでは、太陽系みたいに、トランザクション系のFatなテーブルが中心にあって、その周囲に関連するマスタ・イベントのテーブルが配置されるシーンをよく見かける。

たとえば、佐野さんもブログに書かれているように、商品マスタに在庫数という導出属性が混じっていて、すごく違和感を感じた、というのと同じ。
普通は、商品マスタから在庫数は外し、サマリ系テーブルに在庫数を入れて、定期的なバッチ処理で集計するのが普通だろう。

しかし、渡辺さんの商品マスタのモデルでは、倉庫がない中小企業の事例なので、そういうモデルになった。
今後、倉庫を新たに持つのであれば、在庫数を持つ倉庫テーブルが出てくるのでしょう、と。

でも、そういう考え方を知って、渡辺さんが描いてきた過去のデータモデルを振り返ると、なぜ、すごくFatなテーブルが多いのか理解できた。
そして改めて、そういう技法にあえてこだわる理由も理解できた。

【5】そのパネルディスカッションの中で、@sakaba37さんから、こんな質問があった。

我々システム屋は、分割統治の手法が身に染み付いているので、何でも細かく分割して最終的に組み合わせるという設計手法に慣れている。
だから、渡辺さんのデータモデリング手法では、分割統治されていないように見えるので、違和感を感じるのではないか、と。

また、そうは言っても、渡辺さんの頭の中には、過去の経験を踏まえて、業務パターンのような暗黙知があるので、ライブモデリングのように素早くモデリングできるのではないか。
その業務パターンを形式知化できるといいですね、と。

その話を聞いて、確かに、モデリングでも分割統治して、モデルの対象となる粒度は細かい方が良いのだ、という先入観が強すぎるのかもしれない、と感じた。

【6】他に、パネルディスカッションでは、関数従属性の束でまとめたとしても、それら項目の中で特別な属性で、何かしら強いイメージを持つような「強属性」のものはありますか、という質問があった。

意図としては、項目の関数従属性でテーブルとして洗い出した時、主キー以外にも、特別な役割を持つ項目があるのではないか、ということ。

渡辺さんの回答では、ありますね、と。
たとえば、この属性は主キーではないが、参照は可能だが更新は不可である、という特徴を持たせたい時があります、と。
たとえば、サロゲートキーが主キーであっても、複合キーを主キーとして同格に持たせたい時に使いたい場面が考えられる。
渡辺さんが作ったX-TEA Modelerには、そういう機能をあえて作っている。

データモデリングしてますか？ - TECH BLOG | 株式会社テラスカイ

Salesforceのデータモデリング手法の記事のリンク: プログラマの思索

【7】そんな話を聞きながら、日本でデータモデリングに数多くの流派が発生している理由は、渡辺さんのようなシンプルなデータモデルに、あるべき業務イメージや業務フロー、組織構造などを入れ込む手法の方が多いから、その入れ込む観点や手法で数多くの流派が生まれているのだろう、と思った。

初心者の僕から見れば、データモデラーとは、渡辺さんのように関数従属性の束だけに着目してデータモデルを描くのが普通の人なのだ、と思った。
けれど、実際はそうではなく、色んな考え方を持つ人が多い、ということは分かった。
あるべき業務、あるべき組織構造を考えるには、それなりの業務経験や業務知識が必要で、データモデリングそのもの以外の内容も含まれるだろうから。
そこにコンサルティング会社としての価値もあるのだろう。

だからこそ、たぶん、データモデリングの初心者がモデリングを習得するには、渡辺さんのようなシンプルな技法に特化した方が良いのだろうと思う。
業務知識を知らなくても、関数従属性だけにこだわって、データモデルを描くことに注力すればいいから。

そんな話が聞けて面白かった。