2018/10/09

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

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

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

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

方法論科学研究会(情報システム学会) <第66回IT勉強宴会in新大阪> | IT勉強宴会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】そんな話を聞きながら、日本でデータモデリングに数多くの流派が発生している理由は、渡辺さんのようなシンプルなデータモデルに、あるべき業務イメージや業務フロー、組織構造などを入れ込む手法の方が多いから、その入れ込む観点や手法で数多くの流派が生まれているのだろう、と思った。

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

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

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

| | コメント (0)

2018/09/25

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。
以下、ラフなメモ書き。

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

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【1】以前、下記のツイートがあった。
最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。

【1-1】
akipiiさんのツイート: "ガントチャートはもう時代遅れなのかな?RT @kabukawa: Redmineはチケットからガントチャートが自動で作られて便利なんだけど、ガントチャートを目的に導入すると、Excelより入力が面倒で使わなくなるか、設計とか実装ってタイトルの中身が空のチケットか沢山できて、時々脱力する。"

門屋浩文@redmineeva☀️さんのツイート: "個人的には品質状態(中身)が見えないガントチャートは時代遅れだと思いますよ ごまかせるもの… "

あさこ@センチちうさんのツイート: "ガントはあくまでも、参照かなー。 誰がなんのために見るか、使うかを区別しないと手段が目的になってしまう。 時代遅れとかではなく、手段の違いだと思います。 ガントで見ることができるものをちゃんと区別していないと、ごまかしとかが生まれてくる。見るべきものを適切なもので。… https://t.co/aw4zR2QAQw"

門屋浩文@redmineeva☀️さんのツイート: "目的を理解して使ってる人 ほとんど見たことないよ(疲れていてネガティブです) うーん、見たことあるかなあ? 俺はWBS辞書 つまりチケット一覧をソートして見る派なので 期間にかかる工数も成果物の精度も見ないで何がわかるのかわからないから パッとみで安心したって意味ないもの… https://t.co/AAWOZvyaXo"

昌。さんのツイート: "まどさんがネガティブ!いかんですな。確かにぱっと見安心する使い方してる人たちいますけども。 私は最アジャイルさんのLycheeのおかげでRedmaineにおけるスケジュール見える化はプロセスわからない派にも使えるかもと思うことができましたさ。… https://t.co/4uE4LNBrDL"

門屋浩文@redmineeva☀️さんのツイート: "ネガティブ続きですが、、、ガントチャートが問題の早期発見や解決につながってないんじゃないかなと感じてるから時代遅れと言った 把握してる人に責任押し付けたって誰も幸せにならんから ガントチャートのみ見て改善につなげられる凄腕なら別だが 時系列で5つ並べてみたら気が付けるかなあ俺… https://t.co/fPxjDRBRLu"

あさこ@センチちうさんのツイート: "ガントだけだと、早期発見なんてほぼできないよね。その目的で使うならば間違いなく、「それじゃないっすよ」と答えるかなー。 ガントの強みってなんだろうねー。 タスク同士の流れとか、いつまでに何が終わるのか、どのくらい終わってるのかを見るだけのツールとして今は使っているかも。… https://t.co/xSecapQWwY"

昌。さんのツイート: "ガントに限ったことではありませんが、ツールに対してこれダメ!ってなる人は弊社の場合は大体が目的見失ってるかツールに夢見てるひとですかね。あなたが使ったようにしか使えませんよー、ってなる。… "

やっさん🍶さんのツイート: "管理者より担当者視点だと (関連あれば)チケットを前後で関連付けちゃうので、前後の関係とか、並列度とかを見るくらいですね。ガントチャートの利用って。… "

akipiiさんのツイート: "ガントチャートはメーカーの製造工程や発注作業の管理に向いていて、ソフトウェア開発のように、作業が不明確で、担当者がコロコロ変わり、管理単位が1日未満で粒度が小さい場合は向いてない。所詮、ガントチャートはマネージャがプロジェクト管理で使うビューの一つに過ぎないと思う。… https://t.co/wc6TLz0MKc"

【1-2】akipiiさんのツイート: "知りたい。RT @g_maeda: Redmineのガントチャート、実は社内では全く使ってない。ガントチャート機能を使ってる組織ってどのくらいの割合なんだろう。"

あさこ@センチちうさんのツイート: "うちは、お偉いさんたちが、プロジェクトのMilestoneとガントチャート、リスク管理表と合わせて見るということをしてくれています。 Milestoneに対してどうか、間に合うか、作業的にリスクがあるかという観点で使ってますね。 ガントチャート一本で何かを見るということは難しい…… https://t.co/uuNqP8gYWb"

あさこ@センチちうさんのツイート: "多分、そのリソースやスケジュール確認するのも、目的が合って、そこにたどり着くまでの一つのプロセスになってますよね、ガントチャート。 なので、みたい観点もある、って感じですかね?… "

昌。さんのツイート: "です。>みたい観点 個人的にしっかりプロセスてか目的に沿ってチケット運用してる限りタブ切り替えるだけで自分やメンバーのタスクが見える化されてるから便利〜なので、とりあえず朝イチとか進捗確認時に眺めたり確認したりな感じです。… https://t.co/pcMefEEx29"

【1-3】akipiiさんのツイート: "第3回 Lychee Redmineユーザ会 - connpass https://t.co/5O2rOzCMxx 「Redmine + Lychee導入のアンチパターン」の講演は、チケット管理が回っていたのに、Lycheeガントチャートを使いだしたら、空っぽのチケットが増えてチケット駆動でなくなった、というアンチパターンだろうか?笑"

【1-4】akipiiさんのツイート: "読み返したら、当初の目的が忘れられて、手段が目的化してしまった、という症状に思えてきました。チケット管理がうまく回っていたのに、ガントチャートの監視を厳しくしたら、チケットの中身よりチケットの進捗率が重要になって、チケットが忘れ去られた、みたいなイメージ。… https://t.co/u1P1tcsDZB"

りょうまさんのツイート: "そうですね。私はガントチャートは進捗の俯瞰とインデックスだと捉えてるので、その奥に詳細があるのが当たり前だと思い込んでいました。… "

昌。さんのツイート: "ひとは簡単に目的と手段が逆転しがちなので気をつけねばいけませんね。いつも、目的はなんだ?と自分にも問いかけるようにしてます。… "

【1-5】その真因は、本来のチケットは、プロジェクトで発生する変更要求、課題、作業、障害など、プロジェクトで管理すべき対象全てが起票されるはずなのに、進捗管理だけの側面だけ重視されてしまい、チケットの2重性がなくなって、スカスカの空っぽのチケットになってしまった、ということだと思う。

つまり、本来のチケットは、課題の検討履歴、変更要求の作業履歴というストックの側面を持ち、かつ、チケットの納期や作業進捗も合わせて管理できると言うフローの側面も持ち、2重性があったのに、担当者の作業進捗だけ気にするようになってしまい、フローの側面だけ残り、ストックの側面がなくなってしまった、というアンチパターンが発生したわけだ。

【2】以前、ISO9001のQMSの運用の現場を見た時、変更要求や変更管理に関するExcelの作業依頼書と、設計書やリリース手順書などのExcelドキュメントの2種類のExcel帳票が管理されていた。
その運用は非常に煩雑で、最新版のドキュメントが連携されなかったり、リリース漏れが発生したり、非常に手間がかかっていた。
今どき、Excel帳票で管理する現場はありえないと思うが、古い製造業ほど、Excel帳票がはびこっている。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

その原因も上記と同じ。
つまり、ISO9001で実現する時、Redmineでチケット管理せず、Excel帳票で管理する場合、作業依頼書という変更管理に関するフローの側面と、設計書やリリース手順書などの構成管理対象になるストックの側面は、2つのExcel帳票に必ず分かれる。
そして、その2種類のExcel帳票を常に最新化しながら、申請承認フローに沿って厳密に管理せねばならない。

【3】では、なぜ、Excel帳票の運用は必ず失敗するのか?

【3-1】なぜなら、昨今のように経営環境がすぐに大きく変化する場合、Excel帳票で逐一管理する運用は、その変化についていけないからだ。
変更管理の運用と構成管理の運用はシステム開発ではとても重要だが、2種類のExcel帳票で管理するのは煩雑すぎて、現実として運用できないだろう。

結局、Redmineのようなチケット管理ツールで、フローの側面であるワークフロー管理と、構成管理の側面であるソース管理連携機能の双方を実現しなければ、経営環境の変化のスピードにシステム開発そのものが付いていけいないだろう。

例えば、最初は課題チケットで起票したが、課題に対して複数の代替案を出して検討し、一つの解決案を決定した履歴を残す。
さらに、その対策の作業状況も履歴として残し、課題が解決されるまで、チケットに全ての情報が残す。
すると、そのチケットのステータスが変わるたびに、裏では、その時々の意思決定の状況が管理され、マネージャによる承認プロセスを経て、システムに反映されてリリースされていく。

例えば、最初は顧客からの変更要求の仕様変更チケットで起票したが、その変更要求の発端を記録しておく。
また、チームでそのアーキテクチャや実現方法を検討した経緯を記録しておく。
すると、そのチケットのステータスが変わるたびに、裏では、担当者の作業状態が管理され、マネージャや利害関係者の承認プロセスを経て、システムに反映されてリリースされていく。

つまり、当初は課題チケットや変更要求チケットだったのに、チケットが更新されるたびに、作業チケットの意味合いに変わり、チケットが進捗管理対象になる。
さらに、チケットが更新されるたびに、変更管理の承認プロセスの意味も込められて、チケットが変更管理対象にもなる。

すなわち、チケットはストックとフローという2重性の性質が一つの実体として実現されている。
チケット管理では、ストックとフローという2重性の性質を、マネージャやメンバーが深く意識しなくても運用できるような仕組みを提供しているわけだ。

【3-2】本来あるべき姿のチケット管理では、チケットに変更管理や進捗管理というフローの側面と、成果物の構成管理や課題や作業の履歴管理というストックの側面を故意に持たせることで、スムーズに運用させる。

一方、Excel帳票でそれらを管理しようとすると、フローの側面のExcel帳票と、ストックの側面のExcel帳票の2種類に必ず分かれてしまう。
なぜなら、ステータスだけ管理したいExcel帳票と、リリース対象の成果物として厳格に構成管理したいExcel帳票は、管理方法が大きく異なるので、具体的な実体として分けざるを得ないからだ。

すなわち、Redmineのチケット駆動開発は、2種類のExcel帳票の具体的な実体が1つのチケットに合体されている。
そういう背景を、チケット駆動で運用している人は、意識しているだろうか?

【3-3】Redmineでのチケット駆動開発では、メンバーはストックの側面のチケット管理を意識しているが、その背後では、変更に関する申請承認という変更管理、そして、進捗の作業状況の把握という進捗管理、というフローの側面も裏で持たせている。

2種類のExcel帳票で分けて二重管理している運用が、チケット管理では、チケットという1つの実体で管理できるので、非常に運用しやすくなる。

よって、Redmineのチケット駆動開発ではチケットに複数の意味を持たせて運用した方が上手く回る、と僕は思う。

【4】僕の経験上、メンバーはストックの面だけ意識してもらえばよく、フローの側面はそんなに気にしない方が、チケット管理は上手く回ると思う。
もちろん、変更管理や進捗管理は重要だが、その意識が強すぎると、チケットのライフサイクルが長くなり、チケット駆動のメリットが薄れるから。

チケットに対するフローの側面を意識し始めると、ストックの側面を忘れてしまう。
チケットのストックの側面こそが重要なのに、その部分が軽視された運用になってしまうのだ。
ガントチャート重視のチケット駆動開発が、空っぽのチケットを大量発生させるアンチパターンはまさにそれだ。

一方、ストックの側面ばかり強調すると、チケット入力の運用のコストが上がってしまう。
チケットは手軽に起票して、記録して欲しいのに。
誰も更新しなくなるRedmineは、ゴミ箱と同じ。

だから、チケット管理の運用では、フローの側面を強調しすぎると空っぽのチケットが増えて破綻するし、ストックの側面を強調しすぎると、誰もチケットに起票しなくなって破綻する。

チケットの2重性という奇妙な性質を活かすには、そのバランスが重要だ。
フローの側面だけ、ストックの側面だけ、という運用では、チケット駆動のあるべき姿を実現できないし、チケット駆動の効果が得られない。

そのバランスを維持するための運用ノウハウは、実は数多くの現場で暗黙知となっていると思うので、収集してみたいと思っている。

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。

| | コメント (0)

TRIZ(発明的問題解決理論)のリンク

マーケティング企画業の古典的本「アイデアの作り方」、メーカー技術者が創造的発明する時に使う手法「TRIZ(発明的問題解決理論)」に関する情報のリンク。
結論もなく、自分のアイデアのためのラフなメモ書き。

【参考1】
アイデアのつくり方(ジェームズ・ウェブ・ヤング) - Wikipedia

「アイデアの作り方」 ジェームス・W・ヤング 感想 - 人といる時にスマホを触るな

わずか100ページの薄い本。
率直な感想は、「アイデアとは、古いアイデアを新しい机においたものと同じ」みたいに連想した。

【参考2】
TRIZ(アルトシューラ) - Wikipedia

アルトシュラー『発明的創造の心理学について』(邦訳) | 産業能率大学 総合研究所

アルトシュラー『発明的創造の心理学について』(邦訳)

TRIZが普及していないわけ(歴史的背景) ? アイデアを出すためのコトバとイメージの使い方

TRIZの概要

【1】研修で、プロジェクトマネジメント技法の一つとしてTRIZが挙げられていた。
こんな説明だった。

「(TRIZ)とは、直訳すると発明的問題解決理論。ロシアの特許審議官が膨大な特許情報を分析して「相反する問題を同時に解決すれば発明になる」「現実の問題を一般的な問題に抽象化すれば解決策がいくらでも出る」といった発明の法則をまとめた問題解決の方法論。」

つまり、品質とコストの両立という、互いの解決策が矛盾するような課題であっても、TRIZを使えば、いくらでもアイデアが出てくるよ、という売り文句だった。
それが本当かどうかはよく知らない。

【2】でも、産業能率大学 総合研究所にあるアルトシュラーの原論文「アルトシュラー『発明的創造の心理学について』(邦訳)」を読むと、深い思索があることが何となく感じた。

【2-1】原論文PDFにある自転車の事例が面白い。

最初に発明された自転車には「伝動装置がなく、走行する時は両足で地面を蹴らなければならなかった」。
そして「前輪の軸にペダルを取り付けるという技術進化」が起きた。

次に、「ペダルによって走行速度の増加」による事故障害の課題に対し、ブレーキが発明された。
「その結果、駆動輪の直径を大きくし、これによりペダル 1 回転による自転車の進行距離を増大させるという形で、作業装置をさらに発達」したが、「駆動輪の直径をそれ以上増加させると、自転車走行の危険性が急激に高まる」課題が出てきた。

そこで、「伝動装置の変更(チェーン伝動の採用)」が発明されて、「チェーン伝動により、車輪の直径の大きさではなくて、足踏み回転数を増加させる方法で高速を得ることができるようになった」。

そして「空気入りタイヤが導入」されて、「伝動装置の新たな変更(フリーホイール機構の採用)」が行われ、現在の自転車が完成した。

【2-2】つまり、ある機能の改良は、各要素のバランスを崩すまで劇的に改良できるが、その矛盾が噴出すると、システムの全体的発展のブレーキになり、成長速度が止まる。
なぜなら、ある機能に関する課題があるが、その課題を解決すると、他の技術的課題が現れ、その矛盾は現状のやり方では解決できなくなる段階に到達するから。

しかし、その矛盾の除去が本来の意味での「発見」であり、その発見は、システムの機能の一部を根本的に変更することにつながり、その影響範囲が広いほど、他の部分にも抜本的な変更を施すことになる。

そういうストーリーであると理解した。

【2-3】TRIZの原論文を読んで、「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の一節を思い出した。

「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の感想: プログラマの思索

科学者とエンジニアの間には、宿命的な対立関係がある。

科学者の立場は、真実の探求、自然界の仕組みの探求、制約なしの研究の結果を重視する。
科学者は理想主義者。

一方、エンジニアの立場は、技術的課題の単なる解決ではなく、最も優れた方法で問題解決する。
限られた予算、開発スケジュール、納期の制約の下、「まずまずのところ」で折り合って解決する。
エンジニアはがんこな現実主義者。

つまり、エンジニアは、品質・コスト・納期のバランスという制約条件の中で、「ほどほどの品質」「ほどほどのコスト」「ほどほどの開発期間」で、最大の良い製品を生み出す。

その宿命的対立を乗り越えたら、すごく良い製品が生まれる、という話。
TRIZにも似たような雰囲気を感じる。

【2-4】但し、TRIZはソ連における膨大な特許から、そのアイデア発想方法を理論として生み出した背景があるので、そういう膨大な知識データベースがないと、本来のメリットを活かせない気もした。
課題を解決したい時、その課題に関連する技術情報が即座に収集できなければ、無い知恵をいくら絞っても、解決策は出てこないのでは、と思った。

つまり、「アイデアの作り方」と同じく、既存のアイデアを組み合わせるやり方に近い気もした。

TRIZ――10分以内に「それ、どうやって実現するか」を思いつく方法 (3/3) - ITmedia エンタープライズ

(引用開始)
筆者はTRIZの専門家から詳しいことを教えてもらう機会が幾度かあった。
TRIZを作った人々が分析した特許は非常に膨大であったが、その99%が40のパターンで表現できたと言われている。

逆に考えると「世の中にはパターンでは表現できないものが1%存在する」とも言え、人の知性のロマンチックな可能性をTRIZ創設者らが示唆しているように思えてならない。
真偽は定かではないが、筆者は少なくともこう考えている。目の前の100の課題に対して、この40個のパターンを使えばほとんど(99%)、何かしらの解決コンセプトが発案できる。
解ける問題は効率的にどんどん発案し、人間の知恵を絞るしかないこと(1%)にぜいたくに時間を使いたいものだ。
(引用終了)

【2-5】解決策をそういう組合せの問題に持ち込めるならば、その分野はソフトウェアが強い。
そういうアルゴリズムをプログラムで実装して、ひたすら組合せの結果を評価すればいい。

それは、機械学習、人工知能にも似たような匂いを感じる。
しかし、AIが全ての問題を解決できるわけではない。
たとえば、AIでも人間と同じく、過学習という罠にはまれば、そこから脱出できなくなる。

でも、量子コンピュータなら、トンネル効果を使えば、過学習から脱出できるかもしれない。


| | コメント (0)

WinSCPでトンネリングする方法のリンク

踏み台サーバーを経由してFTP接続する方法がWinSCPで実現できると分かったので、リンクしておく。
自分が後で参考にするためのリンク。
特に主張なし。

【参考】
WinSCPでトンネリングする方法: 小粋空間

踏み台サーバ経由でWinSCPを使ってSCP接続する方法 | 株式会社ビヨンド

WinSCPで多段階接続をする - 時雨に舞う

外部から踏み台サーバ経由の多段SSH接続をWindowsクライアントから行う | Developers.IO


| | コメント (0)

2018/08/28

Redmineにタグ機能を追加するパッチが投稿された

昨日、Marius BALTEANUさんがRedmine本家にタグ機能のパッチを投稿された。
次期Ver4.0で実現できたら、Redmineをより使いやすくしてくれるだろう、と期待している。
ラフなメモ書き。

【参考】
Feature #1448: Add tags to issues - Redmine

【1】なぜ、タグ機能が重要なのか?
それは、GitHub、Gitlab、Jiraなどの他のツールを見ればよく分かる。
Twitterのハッシュタグのように、「#○○○」を書けば、勝手にリンクできて、カテゴライズ化できる。
しかも、情報を探したい時に、タグで探しやすくなる。

(自動翻訳の引用開始)
私たちの問題の多くは複数のカテゴリにまたがっています。具体的には、単にカテゴリ以外のものよりも柔軟性のあるものを検索して管理したいと考えています。

問題にタグを追加する方法があれば素晴らしいだろう。
(自動翻訳の引用終了)

Redmineにタグ機能が欲しい、という要望は10年以上前からずっと言われていた。
そのため、熱心なユーザがタグ機能を実現するプラグインを開発してくれていた。
しかし、RedmineやRailsの度重なるバージョンアップに追随できなかった経緯もあった。

【2】ついに、Marius BALTEANUさんがパッチを投稿された。
そのコメントを読むと、Redmineユーザのニーズをすごく考えていることがよく分かる。

(自動翻訳の引用開始)
私は、プラグインhttps://github.com/ixti/redmine_tagsに基づいてRedmineにタグ機能を追加する作業を始めました(これまでの2年間で寄稿しました)。
私の計画は、第1段階で問題に簡単なタグ付け機能を追加し、機能がコアに承認/追加された後、他のエンティティ(ウィキ、プロジェクトなど)に拡張し、他のすべての機能を提案することです(バルク編集タグ、着色されたタグ)などがあります。

1.第1フェーズは、以下の2つのパッチで構成されています。

タグの追加/削除
タグの追加/削除タグの表示
タグの後にチケットをフィルター
チケット一覧の項目としてのタグ
タグ書き出し(pdf、csv)

添付されたパッチを使用してテストすることができます。
私はタグを管理する権限を持っているべきかどうか(私の見地からは、編集の権限は十分です)、何か他のものがなくなっていて、それがこの第1段階にあるはずなのかどうか疑問に思っています。

2. JSライブラリを追加してUIのタグを処理する(オートコンプリートを含む)添付のパッチでは、Jean-Philippe LangがSelect2をコアに追加したくないことを知っているのでSelectize.jsを提案します。
プラグインによって使用されることはもはや維持されません。
パッチは準備ができていませんが、私はこのライブラリを使用できることを最初に確認したいと思います(他の提案は歓迎です)。
また、プロジェクトからオートコンプリートでタグを提案する必要があるかどうか確認する必要があります。
プロジェクト階層、サブプロジェクトから)。

この機能は、Redmine.orgのチケット投票数のリストで1位にランクされ、120人以上のウォッチャー(この問題で80件、#2897で45件)、複数のコメントと関連する問題があります。
また、プラグインは、タグ付け機能がコアの一部である場合に役立ちます。
Redmine 4.0.0の後の次のバージョン(これはほとんど準備が整っています)でこれを行い、それを提供したいと思います。
(自動翻訳の引用終了)

【3】要約すれば、タグ機能が重要な理由は、2つある。
一つは、Redmine.orgのチケット投票数のリストで1位にランクされ、10年以上前からユーザの要望がチケットに記録され続けてきたこと。
もう一つは、タグ機能がRedmineチケットのカテゴリの代わりの機能になり、検索する時にも役立つこと。

Twitterのハッシュタグに慣れている人は多いだろうから、この機能が追加されることで、より多くのユーザがRedmineにチケットやWikiに情報を書き込むメリットを感じやすくなるだろう。
それら情報は、タグでカテゴライズでき、検索しやすくなるからだ。

このタグ機能も、Ver4.0またはVer4.1で取り込まれるといいなと思う。

また、Redmineの添付ファイルを全文検索できるパッチもVer4.1にセットされており、trunkにマージされることをユーザは待ち望んでいる。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

タグ機能と合わせてリリースされたら、Redmineユーザにとっても待ち遠しいと思う。
今後も、Redmine本家の動向はチェックしておく。

| | コメント (0)

«モデリング技術の習得とモデリングツールの習得は表裏一体