ソフトウェア工学

2019/11/03

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

第17回東京Redmine勉強会が無事に終わりました。
参加者、スタッフ、講演者の皆さん、ありがとうございました。
感想をラフなメモ書き。

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

第17回勉強会 - redmine.tokyo (2019/11/2) - Togetter

第17回redmine.tokyoで自動化の極意と形式知を育む #redmineT | マドびっ! Madosan's View

【1】Redmineコミュニティは1年のうち、大阪で2回、東京で2回、合計4回行われる。
この定期的なリズムが非常に心地よいと感じている。
Redmineを通じて、運用プロセス、プロジェクト管理、インフラ周りやプラグイン開発などの情報をユーザ同士で共有できる場があるのは非常に役立つし、何よりも楽しい。
今回の勉強会で心に残った箇所だけ書いておく。

【2】前田剛さんの発表では、ファーエンドテクノロジー版RedmineであるRedMicaの発表があった。
意図としては、Redmine本家のメジャーVerUpが年1回になっているので、最新機能のパッチが取り込まれているのにユーザに使ってもらえない問題に対し、Redmineの安定版バージョンにtrunkのパッチを当てて、定期的にリリースする、とのこと。

実際、Ver4.1には200個以上の機能改善が含まれているが、1年以上リリースされていないため、せっかくのパッチが使われていない。
この問題意識は重要と思う。

(1) akipiiさんはTwitterを使っています: 「#redmineT ファーエンド版Redmine では、半年ごとにtrunkプラスで最新機能パッチを定期リリースする。リリース計画のお話。気になるのは、Redmine 本家との互換性だが、trunkベースで、相互に移行できるようにする、とのこと」 / Twitter

(1) akipiiさんはTwitterを使っています: 「この考え方は重要。RT @akahane92: 今朝リリースされた Redmica(レッドマイカ) https://t.co/bXt3Pl37Lt Redmine本家のFork版ではない。独自の機能開発は行わず、Redmine本家の機能を先行して提供することに特化するつもり。 #redmineT」 / Twitter

(1) akipiiさんはTwitterを使っています: 「#redmineT Redmine 正式バージョンのリリースが遅い問題意識あり。そこで、ファーエンドテクノロジー版Redmine として、最新機能を盛り込んだフォーク版を公開した。なるほど、パッチを取り込んだ最新機能を早く使えるようにしたいわけか」 / Twitter

一方、Redmineプラグイン開発者の観点では、RedMicaにプラグインを追随させることで、メジャーバージョンアップに事前に対応できる、というメリットもある。

(1) akipiiさんはTwitterを使っています: 「なるほど、プラグイン開発でむ有用なのか。RT @agilekawabata: RedMicaのLychee Redmine対応ですが、本家Redmineのバージョンアップに追随はインパクト大きくて急に大変になるので、定期リリースしていくRedMicaに追随していこうと思います #redmineT #LycheeRedmine」 / Twitter

気になる点は、過去にRedmineをフォークしたChiliProjectのように、Redmineコミッタとギクシャクした関係になったりしないか、という点。
この辺りは、前田剛さんももちろん考えておられて対処している、という印象を持った。
Redmine本家に追随しながら、Redmineの発展を支援していく方向になるといいな、と思う。

【3】アカベコさんのRedmineテーマの開発も興味深い。
テーマは、RedmineのUIを手軽に改善できる手法の一つだ。
沢渡さんの「Redmineをお化粧する方法」という言葉がまさに的確と思う。

(1) akipiiさんはTwitterを使っています: 「お化粧の言葉がいいですね!RT @amane_sawatari: アカベコさん @akabekobeko の講演。「あなたも作れる!Redmineテーマ」 →CSSとJavaScriptでRedmineのUIをお化粧する方法 #redmineT」 / Twitter

SCSSやDockerコマンドの説明は、初心者にも分かる様にすごく丁寧に話されてる点が良かったと思う。

RedmineのUIが古い、UIが使いにくい、という話は以前からよくあがっていた。
Redmineテーマの種類が増えたり、テーマの開発が活発になることで、よりユーザフレンドリーなUIに進化できるきっかけになるといいなと思う。

【4】@akahane92さんの全文検索プラグインのお話は、過去のIT全般統制の事例、性能チューニングの話を振り返りながら聞くと思い出深い。

akipiiさんはTwitterを使っています: 「#redmineT @akahane92 さんは、7年前にRedmine によるIT全般統制の事例を紹介された。その後、性能チューニング、そして全文検索プラグイン開発、と着々とプロセス改善されてる。そういう経過を振り返るとすごいですね」 / Twitter

僕が理解したストーリーとしては、メーカー情報システム小会社の立場として、Redmineを社内システムのPJ管理基盤として導入し、IT全般統制も取り入れて、プロセス基盤を固める。
すると、Redmineが持つチケット管理機能やトレーサビリティの恩恵を受けた後、次に出てくる課題は、チケット40万以上の蓄積されたデータを活用して、ナレッジシステム化していくこと。
もちろん、Redmineが肥大化することで、性能チューニングの課題も出てくる。

そこに、全文検索プラグインを導入することで、Redmineのチケット、Wiki、果ては添付ファイルやSVN配下の文書に至るまで全文検索の対象になり、Redmineは真のナレッジシステムになったわけだ。

@netazoneさんが全文検索プラグイン導入のLTをしてくれたが、@akahane92さんの話を聞くと、単に全文検索プラグインを入れるだけでなく、ChuperTextによる形態素解析、検索Jobの設定などミドルウェアの設定もかなり多い。
つまり、全文検索の精度向上や性能チューニングの為に相当なノウハウが込められている点は注意。

【5】パネルディスカッション「チケットを切れる人切れない人/なじむ文化なじまない文化」にパネラーとして参加させてもらった。
沢渡さんのお話は非常に軽快で楽しかった。
沢渡さんの発言から刺激を受けた内容を話したいという気持ちが強すぎて、言いたいことの半分も話せず、あっという間に終わってしまい、消化不良感が残ってしまった笑。

akipiiさんはTwitterを使っています: 「経験に基づくので参考になります。RT @amane_sawatari: 経験から学ばない残念な組織「4つのない」 ?言わない ?既知か未知か判断できない ?記録しない ?クローズしない (パネルディスカッションでの沢渡のキーメッセージ サマリ) #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redmineT 今日は皆様ありがとうこざいました。いつも熱気があって元気づけられます。久しぶりのパネラーで、Redmine には組織の色が出る、一方Redmine 導入でチームが活性化し、メンバーの貢献意欲を引き出してRedmine が組織文化を変える時もある、話までしたかったのに時間切れで消化不良でした笑。」 / Twitter

自分が話したかった事をここで書き残しておく。

【5-1】Redmine導入の成功パターンは経験上2つある。
一つは、トレーサビリティの概念は経験済みであったこと。
つまり、すでに開発プロセスのイメージは僕の中で持っていたので、後はRedmineにプロセスを実装するだけだったので簡単だった。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart17: プログラマの思索

もう一つは、システム保守のように、ルーチン作業と突発的作業が混在している環境だったこと。
こういう環境では、チケット管理ツールのような基盤がないと、正直仕事がやってられない。
沢渡さんはチケット管理ツールの特徴として「備忘録のようなもの」という発言をたびたびされていたが、システム保守の現場ではまさに備忘録の基盤が必要。
「備忘録」というキーワードは、@sakaba37さんもチケット駆動開発の説明でも使われていたので、既視感を感じた。

【5-2】チケットには「ストック」「フロー」という2つの特徴を持つ。
物理学における光が粒子と波動の二重性を持つのと同じように、チケットはフローとストックの二重性を持つ点が非常に重要と考える。

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

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

チケット管理の上手な人は、チケットをストックだけ、フローだけで回すのではなく、チケットという1個のインスタンスを状況に応じてストックで扱かったり、フローに見せたりして、2つの性質を同時に使わせようとしていると考える。
一方、Excel管理では、この二重性を持たせるのが非常に難しいので、上手く回らない。

WBS駆動チケットというアンチパターンは中身がスカスカのチケット、と紹介して、他のパネラーも共感してくれた。
チケットをトップダウンでフローだけで扱おうとして、ストックにならないから、中身がスカスカになってしまうわけだ。

【5-3】沢渡さんの話で、オフショアチーム連携では、チケット管理ツールとチャットツールの2つあれば回るという経験談が興味深かった。
NTTデータのお仕事のときは、自社製のITSやチャットツールで運用されていたらしい。

akipiiさんはTwitterを使っています: 「#redmineT 今日はお忙しい中パネルディスカッションありがとうございました。オフショアチーム連携では、チケット管理ツールとチャットツールの2つ有れば回ると言う話は共感しました。」 / Twitter

僕は、沢渡さんの考えでは、仕事をする環境では、タスクや課題を共有する基盤とリアルタイムにコミュニケーションする基盤が必要なのだ、と理解した。
沢渡さんの発言の中ではたびたび、口頭でのやり取りでは後に残らないので仕事にならない、チケットに残して安心して忘れるべきだ、と話されていたが、それを実現する基盤がそれらなわけだ。

今ならば、Redmine はストック、Slackはフローで役割分担するだろう。

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT Redmine はストック、Slackはフローと言う役割分担ですね。」 / Twitter

個人的には、そういうチケットやコミュニケーションする環境を作るためには、心理的安全性という概念が重要になるだろうと思っている。
チケットには、課題やリスク、バグなど、プロジェクトの悪い話が出やすい。
そういう内容をどんどん見える化して、一つずつ解決する必要があるのに、悪い話を出すと周りから叩かれてしまう、という雰囲気では、チケットを切る文化は生まれない。
この辺りも同意してくれる人が多くて嬉しかった。

akipiiさんはTwitterを使っています: 「#redmineT パネルディスカッションのチケットを切る文化の話の中で、心理的安全性の言葉に反応してくれた参加者もいてくれて、嬉しかったな。チケットにはプロジェクトの悪い話が出やすい。そういう話題を1人が抱え込まずに見える化して、皆と共有できる場にしたい。」 / Twitter

【5-4】Redmineは組織に従う、という経験則があると思う。
特に、日本では、Redmineには日本の組織の色がすごくにじみ出る。
自分たちのプロセスに強いこだわりがあるため、Redmineのワークフローやトラッカーだけでなく、RedmineのUIや機能を組織に合わせようとして、カスタマイズして作り込んでいくパターンが非常に多い、と経験上感じる。
この点は、メリットなのか、デメリットなのか?も、参加者に問うてみたかった。

僕の考えでは、メリットもデメリットもある。
デメリットは、Redmineがカスタマイズされすぎた結果、Redmineの運用プロセスが複雑になりすぎてメンバーが使いにくくなること、VerUPの追随が難しくなることがあげられるだろう。
SAPなどの業務システムがいい例だ。

また、会社標準の単一Redmineを導入したとしても、複雑すぎて、現場に合わなければ、各チームごとに立てたRedmineインスタンスが乱立し、野良Redmineがはびこってしまい、標準プロセスから逸脱してしまう状況にもなるだろう。

だが、気象庁や田村さんの事例のように、各部署にRedmineインスタンスを配布して各部署に運用を任せた方が上手く回る、という事例もあった。
つまり、Redmineインスタンスは社内標準の1個がいいのか、各部署が複数個のRedmineインスタンスで個別運用したほうが良いのか、という課題が出てくる。
この辺りも、参加者に問うてみたかった。

一方、メリットは、Redmineが組織文化を変えてくれる場合があることだ。
既存のプロジェクト管理ツールのパッケージ製品には、その会社のプロセスが埋め込まれているので、自分たちのプロセスとフィットしない弱点が多い。
しかし、Redmineは非常に柔軟なので、自分たちの組織のプロセスにフィットさせやすいため、メンバーは慣れ親しんだやり方を変える必要がない。
Redmineの導入や普及の敷居は非常に低い。

すると、Redmineを導入することで、チームが活性化したり、オフショアチームとの信頼関係が強化されたりする場面がよく見られる。
マネジメント経験の浅いリーダーが、Redmineというツールを通じてプロジェクト管理を経験して成長する場面を僕も見てきた。
つまり、Redmineという一つのツールが、リーダーやチーム、そして組織を変化させていく力を持っている。
すなわち、Redmineは組織を変革する潜在能力を持ったツールなのだ、とみなせる。

むしろ、Redmineを導入したい人は、Redmineにそういう効果を期待しているはずだ。
そういうRedmineが人や組織を変化させるような話や事例をもっと集めたいし、聞いてみたいと皆思っているはず、と思っている。

【追記】
akipiiさんはTwitterを使っています: 「#redmineT チケットを切る文化の話が定着すると、次に出てくる問題が放置チケットやチケット棚卸しになる。ぼくはここがマネジメント層の腕の見せ所と考えてる。アジャイル開発はこの辺りのノウハウが上手いと感じる。」 / Twitter


| | コメント (0)

2019/06/16

マイクロサービスにおける決済トランザクション管理のリンク

マイクロサービスにおける決済トランザクション管理の記事をリンクしておく。
まだ完全に理解できてないので、じっくり考える。

【参考】
マイクロサービスにおける決済トランザクション管理 - Mercari Engineering Blog

BASE: An Acid Alternative

以前、カード会社のトランザクション処理で、Recovery commitなる共通関数を作った経験があった。
それは、トランザクションが途中で失敗した時、失敗した時点までは確実にコミットするが、その時点以降はロールバックする仕組みだった。

上記の記事を読みながら、補償トランザクションの考えに似ているな、と感じた。
ただし、メルカリのCtoCの膨大なトランザクション処理を支える基盤だけあって、冪等性やBASE特性などよく考えられている。

現在のプラットフォームビジネスでは、こういうトランザクション基盤が必須ということがよく分かる。

| | コメント (0)

2019/04/22

IT企業が経済学者を雇い始めた理由が面白い

最近、IT企業が経済学者を雇い始めた理由を解説する記事をちらほら見かける。
記事が面白いのでリンクしておく。
以下は、自分の理解のラフなメモ書き。
間違っていたら後で直す。

【参考】
IT企業はなぜ経済学者を積極的に雇い始めたのか | HBR.ORG翻訳マネジメント記事|DIAMOND ハーバード・ビジネス・レビュー

米アマゾンらが経済学者を雇う理由~デジタル経済学者のシェアエコ化(石角 友愛) | マネー現代 | 講談社(1/3)

IT企業による経済学の活用 : 遠い呼び声の彼方へ!

(引用開始)
第一に、最先端の経済学の理論は、IT企業が必要とするサービスの要素技術になり得るからです。
例えば、日経ビジネスに掲載されたハル・ヴァリアン教授のインタビューによれば、ヴァリアン教授が主導し、広告オークションの設計にオークション理論を取り入れ、AdWordsの設計を行ったそうです。
(中略)
第二に、最先端の経済学者はIT業界が必要とする統計のエキスパートであるという点です。
最先端の研究では、経済学者は統計理論を活用し、事象をモデル化することが要求されます。
結果、経済学者は統計によるデータ処理のエキスパートとなっています。
一方でIT業界も、データを活用するためのは統計処理が不可欠です。そしてビッグデータの時代になるほど、高度な統計処理が要求されます。
結果、ITサービスの開発やグロースに必要なデータ処理やそのモデル化に、統計学者の知見が活かされているのです。
(引用終了)

【1】昨今のAIや機械学習の隆盛を見ると、心理学や経済学のような文系の学問とIT技術の組合せが非常に相性がいいのだろう、と感じる。
その理由は2つある。

【2】一つは、心理学や経済学が過去数百年に渡って蓄積してきた理論や知見は、「市場や社会集団に対し、どのような社会制度や経済政策を整備すれば、人にインセンティブで動機づけさせて、あるべき正しい方向に人の行動を律することができるか」という問題をずっと考えてきたからだ。

その手法は、政治、経済の分野だけでなく、ショッピングサイトやオークションサイト、Uberやエアーアンドビーなどのマッチングサイト、などの多数のWebシステムに簡単に適用できる。
特に、マッチングサイトでは、情報やサービスを提供する生産者とそれを購入する消費者の間で、お互いに最大の利益を得るようなマッチングを計算する必要があるが、まさにそのアルゴリズムは、どのような仕組みをWebサイトに導入すれば取引が全体最適化されるか、という問題に置き換えられるからだ。

あるいは、SNSや広告エンジンのマーケティングでは、どのようなターゲット層にどんな広告内容を表示すればマーケティング効果が得られるか、という問題に対し、心理学の知見を活かすことで、ターゲット層に具体的なペルソナを作り出して、ABテストでマーケティング手法を実験する、ということも簡単に実行できるからだ。

つまり、既存のIT技術を使った結果に、心理学や経済学の過去の知見を適用すれば、そのデータに価値観を与えることができる。

まあ、振り返ってみれば、経済学はマンキューによれば「インセンティブの学問」でもあるし、一方、心理学も人間の性格に関する理論を数多く生み出してきたので、その内容を昨今のWebシステムに適用できるのは当たり前ではある。

【3】もう一つは、心理学者や経済学者は統計のスペシャリストであること。
実際、心理学や経済学の学部の卒論、修士論文は、アンケートから統計的有意性を評価したり、膨大な行動・経済データから因果関係を導いて理論化するなどの内容ばかりだ。
つまり、彼らは、統計学を自分達の学問で理論化するときの手段として普通に使っている。
その作業はまさに、最近もてはやされるデータ・サイエンティストの作業と全く同じだ。

昨今のコンピューティングパワーのおかげで、統計処理という煩雑な計算は全てプログラムで代用できる。
それにより、心理学や経済学が本来やりたかった「人にどんなインセンティブを与えると、あるべき方向へ行動を誘導できるか」という問題を簡単に実験できるようになった。

実際、Uberでは、ミクロ経済学の授業の最初に出てくる需要曲線や消費者行動曲線をリアルに導き出すことに成功した事例があった。
需要曲線が分かれば、供給曲線は生産者自身が制御できるので、均衡する価格を生産者自身が誘導する事ができる。

他に、たとえば、税金をどのように表示すれば、消費者の需要を損なわずに購買意欲を引き立てることができるか、という行動経済学の実験もあった。
この実験で得られた内容は、まさに政府の経済政策に取り入れれば、消費税率が上がったとしても景気の腰折れをさせないような効果を生み出す可能性があるだろう。

【4】他方、個人的には、機械学習やニューラルネットワークなどのAI分野において、昨今のIT技術で、過学習の問題をどう解決しているのか、に興味がある。

いくらコンピューティングパワーが上がったとしても、間違った方向で計算して過学習の状態、つまり鞍点に陥れば、本来の全体最適された結果が得られない。
この問題は古くから知られていて、解決方法も色々あげられているが、まだしっくりと来るものは感じない。

【5】「心理学や行済学のような文系の学問とIT技術の組合せが非常に相性が良い」事が分かれば、今後、IT技術者には、心理学や経済学の学習も必要にされてくるかもしれない。

IT技術者はプログラミングという道具には詳しいが、ビジネス上の問題を解決する手法は知らない。
たとえば、「eショッピングやマッチングサイトでどんな設計にすれば売上が増大するのか」「生産者や消費者にどんなインセンティブを与えれば、売上向上につながるような行動を誘発できるか」という問題を解決するには、心理学や経済学の知見を使って、ユーザを誘導するシステム設計を実現することが求められるからだ。

一方、心理学や経済学は膨大な理論を蓄積してきたので、彼らの手法をIT技術で実現するだけで、簡単にその有効性を評価できるはず。
手当たり次第、彼らの手法をIT技術で試してみてもいいわけだ。

そんな事を考えると、面白い時代だな、と思う。
文系の学問は役に立たないと昨今言われるけれど、実は、こういう場面で非常に有効と分かるからだ。

【6】でも、心理学や経済学の理論によって「人のインセンティブで行動を誘発させる」手法を悪用すれば、甚大な影響も起きるだろう。

たとえば、アメリカのトランプ現象、英国のEU離脱などの政治現象を見ると、FacebookのようなSNSを使って民衆の政治行動を悪い方向へ誘導させることも実現可能になったのかな、とも思う。
また、炎上マーケティングのように、過激な発言に数多くの人が「いいね」「リツイート」させられることで、莫大な広告収入が得られるなら、そういう方向へどんどん過激化させていく方向に進んでしまう。
つまり、売上向上の最適化を図るアルゴリズムが暴走すれば、「人のインセンティブに故意にエネルギーを注ぎ込むことで、過激な行動へ走らせる」方向へ進んでしまうわけだ。

実際、一人の人間として知性があったとしても、集団心理学の観点では、リスキーシフトのように、より過激な意思決定に進んでしまう事例は、過去の日本の敗戦や米国のベトナム戦争のように、既にある。

今は、ビジネスに限らず、政治経済の分野で、心理学や経済学とIT技術の組み合わせによる壮大な実験が平行で行われている時代のように思える。

| | コメント (0)

2019/02/24

RedmineとAIエンジンを連携する事例のリンク

RedmineとAIエンジンを連携する事例があったのでリンクしておく。
以下は自分が理解した内容のラフなメモ書き。
間違っていたら後で直す。

【参考1】
その問い合わせ、AIが解決します!~Redmineチケットレコメンドシステムのご紹介~ | Future Tech Blog - フューチャーアーキテクト

社内ヘルプデスクをAIで! | Future Tech Blog - フューチャーアーキテクト

【1】後者の事例は、チケットの内容をAIエンジンが自動判断して、カテゴリ振り分けを自動設定する。
前者の事例は、チケット登録時の情報を元に、AIエンジンが類似チケットを自動で関連付ける。

上記の例で興味深い内容は、下記の点だ。

(引用開始)
検索アルゴリズムは、「類似文書検索」と「キーワード検索」のハイブリッド手法を用いることにより、より精度を向上させる試みを行いました。
類似文書検索は、機械学習のトップカンファレンス1 で発表されたSCDV(sparse Composite Document Vector)と呼ばれるEmbedding手法を用い、キーワード検索は現在有力とされているBM25を用いました。
本システムのもっとも肝な部分は、SCDV(文書検索)×BM25(キーワード検索)のハイブリッドアルゴリズムを実装した点にあります。
(引用終了)

なるほど、類似文書検索とキーワード検索を元に、チケット内容の類似度の度合いを相関関数で測定して、精度を高めているわけだ。
類似文書検索だけ、キーワード検索だけ、ではなく、2つを組み合わせた多重度分析にして重みを教師あり学習で精度をさらに高めている点は、面白いな、と思った。

【2】アーキテクチャとしては、AWS上にRedmineとJenkinsとAIエンジンがあって、Jenkinsが定期的にRedmineをポーリングしてAIエンジンに連携し、カテゴリ振り分けや類似チケットを推定して、Redmineへ情報を返却する流れみたい。
Redmineのチケットにカテゴリ振り分けや類似チケットを関連チケットとしてリンクさせる処理は、RedmineプラグインまたはREST APIで実装しているみたい。

確かに、Redmineの外側にAIサーバーを置いて、Redmineのデータを定期的に渡すようにするサーバー設計ならば、既存の仕組みを組み合わせるだけで作れそうな気がする。
Redmineのデータをやり取りするI/Fの部分だけは、REST APIやRedmineプラグインで実装すればいい。

この発想は、Redmineの外部にBIサーバー(例えば、Tableauとか)を置いて、Redmineのデータを定期的に集計表示させる仕組みにも似ている。
つまり、Redmine単体はチケットというデータ収集基盤とみなし、AIサーバーやBIサーバーがRedmineのチケットを定期的に取得して、類似データを分析したり、いろんな観点のメトリクスを集計する仕組みが作れるわけだ。

【3】上記の事例は非常に面白い。
なぜなら、「少人数・短期間で、簡単に構築することができた」からだ。
つまり、RedmineとAIエンジンを組み合わせる手法は、昨今のOSSライブラリを上手く流用できれば、そう難しくないのだろう。

現在、Redmineを長年運用してチケット枚数が数万~数十万件まで蓄積された開発現場はたぶん、割と多いのではないか、と思う。
AIサーバーで類似チケットを自動設定したり、カテゴリ振り分けを自動設定したりする事例があるならば、他に、別のチケット振り分けの観点でチケットの属性にデータを設定する機能も実現可能だろう。
つまり、@ktohさんが以前話していたように、Redmineにスマートナビまたはコンシェルジュのようなエンジンを実現することで、チケット入力者に事前に情報を提供したり、チケット入力を支援することも可能だろう。

この辺りのアイデアは色々考えてみたいと思う。

| | コメント (0)

2019/01/11

【告知】2019/3/2にSEA関西で「気象予報システムを支える技術」の見所 #seakansai

【見所】
今年度のSEA関西では、2月・3月に3回連続で、ビッグな講演が目白押しです。
第3弾は、3/2土に気象庁 予報部 数値予報課の技術者の方が来て下さって、「気象予報システムを支える技術」を講演される。

実は、この講演の発端は昨年のRedmine大阪で、気象庁の方が講演してくださったのがきっかけ。

第66回 SEA関西プロセス分科会&第18回 Redmine大阪 「チケット管理システムによるソフトウェア開発支援と今後の課題」 - connpass

昨年のRedmine大阪では、気象庁の数値シミュレーションシステム開発において使われている、Redmineの複数インスタンス運用がメインテーマだった。

一方、今回の講演では、気象庁内において、スーパーコンピュータを使った天気予報の数値シミュレーション開発の話そのものがメインテーマになる。
気象予報のシステム開発に、並列計算や機械学習など数多くの技術を紹介してくれる。
この部分だけでもとても興味がある。

また、システム開発の運用基盤に関わる話の一つとして、RedmineやGitなどの話も含めてくれるらしいので、Redmineユーザも要チェックでしょう。

そう言えば、昨年のRedmine大阪の講演では興味深い内容がいくつかあった。
たとえば、気象庁では「プログラマ」という官職があり、給与人事制度があるので、プログラミングに専念する技術者という地位が認めらている。これは、官公庁という発注者の環境でも存在できる、という点で興味深い。
また、そういうプログラマがいる雰囲気のせいだろうか、気象庁内ではFortrunだけでなく、インフラ運用などでRubyが頻繁に使われている、という話もあった。
最近は、海外の技術者の影響を受けて、Pythonにも挑戦している、という話もあったな。

気象庁の技術者の講演を聞くチャンスは少ないので、興味のある方は是非お越しください。

【参考】
第70回 SEA関西プロセス分科会 気象予報システムを支える技術 - connpass

(引用開始)
気象予報システムを支える技術
講師: 
 雁津 克彦 氏(気象庁予報部数値予報課プログラム班)

概要: 
 気象庁では、風や気温などの時間変化をスーパーコンピュータで計算し、将来の大気の状態を予測する「数値予報」を用いて、日々の天気予報や防災気象情報の作成を行っています。

気象庁はTop500で28位・29位(2018/11現在)のスーパーコンピュータを整備して数値予報を行っており、運用中のスーパーコンピュータシステムについて紹介した後、C, Fortran, Ruby等で内製している数値予報のプログラムについて、並列計算やソフトウェア技術といった側面を中心に紹介します。併せて、予測結果を天気予報に利用できる形に翻訳する「ガイダンス」では各種機械学習を用いたプロダクトを作成しており、こうした機械学習の利用についても紹介します。

また、これらのソフトウェアは複数の課室で開発を分担していますが、実行プログラムや読み込む定数ファイルなど多くの部分を共有して利用しており、これらを齟齬なく維持管理する現在のルーチンシステムの管理手法や、バッチ処理のためのスケジューリングソフト(ROSE)、開発管理としてのRedmine, subversion, git 等の利用についても併せて紹介します。

主催:  ソフトウェア技術者協会(SEA)関西支部 (http://sea.jp/)

開催日時:  2019年3月2日(土)14:00~16:45

開催場所: 
 〒540-0031 大阪市中央区北浜東3-14
 エル・おおさか(大阪府立労働センター) 7階 701号室
 http://www.l-osaka.or.jp/index.html
(引用終了)

| | コメント (0)

【告知】2019/2/16にSEA関西でIPAの方の講演「IoT時代のシステム開発アプローチ」の見所 #seakansai

【見所】
今年度のSEA関西では、2月・3月に3回連続で、ビッグな講演が目白押しです。

第1弾は、2/09(土)に、Node-REDのワークショップ。
Nodeから手が出るNode-RED - connpass

第2弾は、2/16に、IPAの方が大阪まで来て下さり、「IoT時代のシステム開発アプローチ」の講演会です。

1本目の講演は、IOTシステム構築に必要な要件であるセキュリティ要件や信頼性の観点のお話。
2本目は、IOTシステムが、組込製品からクラウドシステムまでも含むシステムズ・オブ・システムズの観点であることから、システムエンジニアリングのアプローチが有効である、というお話。

IPAの最近の活動をネットで見ると、日本の製造業の技術力強化には、組込製品のソフトウェア開発だけでなくIOTシステムも重要、という認識の元、製造業と密接に関わるソフトウェア開発の話が多いように思う。

「日本のモノづくりは高品質」という神話があったけれど、現代は、ハードウェアよりもソフトウェア開発の方がはるかに重要になってきてる。
だから、日本の製造業はもっとソフトウェア開発に目を向けるべきだ、というメッセージが込められているように思える。

IPAの方の講演は関西ではそう簡単に聞けないので、興味のある方は是非お越しください。

第3弾は次のブログで紹介予定。

【参考】
第69回 SEA関西プロセス分科会 IoT時代のシステム開発アプローチ - connpass

(引用開始)
IoT時代のシステム開発アプローチ
講師: 
 宮崎 義昭 氏(独立行政法人情報処理推進機構 社会基盤センター 産業プラットフォーム部 研究員)
 端山 毅 氏 (独立行政法人情報処理推進機構 社会基盤センター イノベーション推進部  主任研究員)

概要: 
本セミナーでは、IoT製品の開発者が開発時に考慮すべき安全性やセキュリティ観点でのリスクや対策と、品質の確保・維持に必要な考慮ポイントを説明したうえで、多様な専門領域にわたる取組みが求められるIoTの開発に役に立つ開発アプローチである、システムズエンジニアリングについて、その基本的な考え方を解説します。

主催:  ソフトウェア技術者協会(SEA)関西支部 (http://sea.jp/)

後援:  独立行政法人 情報処理推進機構(IPA)

開催日時:  2019年2月16日(土)13:30~16:45

開催場所: 
 〒530-0001
 大阪市北区梅田1-2-2-500 大阪駅前第2ビル5階
 大阪市立総合生涯学習センター 第1研修室
 http://osakademanabu.com/umeda/

講演1: つながるシステムの安全安心に向けた課題と対策

講師: (独)情報処理推進機構 社会基盤センター 研究員 宮崎 義昭 氏

IoTと呼ばれる製品・サービスの普及が進み、個人生活や生産現場など様々な場面での 活用事例が報告されています。一方で、IoTシステムは、セキュリティやセーフティの観点で、これまでとは異なるリスクを含んでおり、システム提供者には、開発や運用の場面において、十分なリスクの洗い出しと対策が求められます。本講演では、IoTの安全安心に対する課題と高信頼化に向けた考慮ポイントや品質確保の取り組み方について、具体的な事例を交えて解説します。

講演2: 成功事例に学ぶシステムズエンジニアリング

講師: (独)情報処理推進機構 社会基盤センター 主任研究員 端山 毅 氏

IoT時代における製品やサービスは、利用者からの要請や期待に応えるため、製品やサービス自体が複雑化・高度化し、その実装には多様な専門領域にまたがった取組みが求められます。
このような状況には、航空宇宙分野で培われてきたシステムズエンジニアリングのアプローチが役に立つと考えられます。本講演では、特にシステムズエンジニアリングの考え方を理解する上で重要な4つのポイント(「目的指向と全体俯瞰」、「多様な専門分野を統合」、「抽象化・モデル化」、「反復による発見と進化」)や、システムライフサイクルプロセスの上流プロセスについて、実践的な解釈と事例を交えて解説します。 また、システムズエンジニアリングのアプローチが有効に機能したと評価できる日本企業の開発事例を紹介します。
(引用終了)

| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

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

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

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

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

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

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

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

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


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

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/03

ソフトウェア開発に心理学や行動経済学の概念を適用した記事のリンク

ソフトウェア開発に心理学や行動経済学の概念を適用した記事がとても素晴らしいので、リンクしておく。
このアイデアを育ててみたくなった。

【参考】
ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita

ソフトウェア開発に、製造業や生産管理のベストプラクティスを適用しても、あまり有効でない。
むしろ、認知心理学や行動経済学の知見を適用して、開発者の心理や開発チームの行動に着目した方が、うまくコントロールできるのではないか。
そんな感触をずっと持ち続けてきた。

上記の記事はまさにピッタリ。
そう、こういう記事が読みたかった。

現場の開発者や開発チームは、独自の存在であり、全ての存在が同じではないけれど、それらの行動を現象として見ると、驚くほど共通的な特徴が見つかる場合も多い。
そういうバラバラな共通的な現象を、的確な概念でその本質を表現できればいいのに、と思っていた。

たとえば、認知心理学の概念として、認知的不協和、グループシンク(集団浅慮)、リスキーシフト(リスク志向の集団極性化)、コーシャス・シフト(安全志向の集団極性化)、有能性の罠(competency trap)、訓練された無能、などがある。
それらを実際にソフトウェア開発に適用してみれば、当てはまる事例は多いのではないか?

具体的には、要件定義で数多くの利害関係者の意向を取り入れると、本来は業務を刷新する革新的なシステムを導入するはずだったのに、現状の業務の焼き直しに過ぎないリプレース案件になってしまった、という事例は、コーシャス・シフトの一例ではないか、とか。

僕は、認知心理学の概念の適用も面白いと思うが、行動経済学の概念を適用する方が面白いと思っている。
経済学の基本理念「限られた資源を有効活用する」ことは、ソフトウェア開発でもまさに同じだ。
優れた開発者、優れた開発チームという唯一無二の資源をいかに有効活用して、ビジネス価値を作り出すか、という目的と一致するからだ。

たとえば、技術的負債やリファクタリングは、時間割引や割引価値の観点で説明できるだろう。
犠牲的アーキテクチャは、埋没価値(サンクコスト)や機会原価の観点で説明できるだろう。
意固地な言動は、バイアスで説明できるかもしれない。

アドレナリンジャンキー」にあるプロジェクト管理のアンチパターンも、認知心理学や行動経済学の知見で整理して説明し直すと面白いかもしれない。

プロジェクト管理のアンチパターン集~アドレナリンジャンキー: プログラマの思索

| | コメント (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)

より以前の記事一覧