Agile

2023/10/21

概念モデリングや設計原則は進化しているのか

最近、概念モデリングや設計原則の勉強会に参加して色々気づきがあった。
ラフなメモ書き。

【1】「実践UML第3版」を勉強会で読み始めた。
僕は「実践UML第1版」を購入して読んでいた。
思い出せば20年前になるのか。
そこから第2版も買ったし、最近第3版も買ってみた。
中身は変わってきているが、版を重ねるごとにオブジェクト指向設計の内容が洗練されて、RUPという開発プロセスに準じるように設計から実装、移行まで一気通貫する。

2020年代の現在、「実践UML」を再度読んで気づきがいくつかある。

【2】1つ目は、RUPはもう不要と思う。
スパイラル開発プロセスはWF型開発からの脱却という観点で重要だったが、Scrumを中心としたアジャイル開発が全盛の時代だから、わざわざテーラリングが必要な重厚長大なRUPを利用するメリットはないと思う。

【3】2つ目は、モデリングに必要なUMLのダイアグラムの力点が変わっていること。
「実践UML第1版」では、以前は協調図(コラボレーション図)、今のコミュニケーション図がオブジェクト指向設計で重要です、と主張していた。
理由は、コラボレーション図を描くことで、機能をどのクラスに割り当てるべきか、凝集度や結合度、生成などの観点で検討する時に有用だから。
オブジェクトからたくさんの指示が出ていれば責務が多すぎるね、と気づきやすいから、と。
当時の自分はすごく納得した。

実践UML第2版実践UML第3版では、クラス図やシーケンス図で説明する場面が多い。
コラボレーション図の話はなくなっていた。
たぶん、UMLの中でも重要度が下がったためだろう。

しかし、機能の割り当ての考え方は普遍的と思う。

【4】3つ目は、GRASPパターンは「情報エキスパート」パターンが一番大事ということ。
このパターンが「実践UML」の重要ポイント。

機能や責務はどのクラスに割り当てるべきか?
責務の遂行に必要な情報を持っているクラス、すなわち情報エキスパートに責務を割り当てるべきだ。

つまり、責務の遂行に必要な情報を自身のクラスの属性、関連先のクラスから取得した情報を自身のクラスで持ってること。
そして、処理を実行する時に、他クラスへメッセージを投げ出せること。

コミュニケーション図なら、情報エキスパートとなるクラスからメッセージという矢印が出ているだろう。
シーケンス図なら、情報エキスパートとなるクラスからメッセージが出て、他のクラスに処理が委譲されて、階段状の図になっているだろう。

その他のパターンも8つくらいあげられているが、そこまで重要ではないように思う。
生成、疎結合、高凝集度、多相性、コントローラは読めば分かる。
バリエーション防護壁はFacadeやAdapterみたいなもの。
純粋加工物、あるいは人工品は、機能の関連だけで構成するのではなく、ソフトウェアのプログラムの都合上、論理的なオブジェクトをワンクッション挟むようなもの。

【5】4つ目は、概念モデリングとデータモデリングは似ているようでやはり異なることだ。

「実践UML」では、概念モデリングでの注意点がいくつかある。

【6】属性とクラスは区別する。
一般に、ある概念をクラスの属性にするか、クラスで独立させるか、識別は間違いやすい。
「実践UML」の指針では、ある概念Xが現実世界では数値でもテキストでもなければ、Xは概念クラスであり、クラスの属性ではない、と言い切っている。

これは重要と思う。
初心者だった頃、どれをクラスにすべきか迷ってしまう時が多かった。
迷って、概念をクラスの属性にしてしまいがちな時が多い。

例えば、Destination、AirportはFlightに含めるべきか。
それぞれクラスとして独立させて、関連で結ぶべき。

実際は、1つの概念はクラスのロール名としていろんな別名として現れる。
例えば、企業クラスは顧客だったり仕入先だったり、取引先だったり、もしかしたらグループ内企業だったりする。
つまり、企業クラスはいろんなロール名として呼ばれる時がある。

【7】属性にはプリミティブ型を使わず、データ型を使う。
たとえば、属性にはDate型、Number型、String型を使う。
あるいは、Address、Color、PhoneNumber、UPC、SKU、ZIP、列挙型を使う。
区分値は列挙型を使う場合が多いかな。

例えば、会員クラスの会員名、会員IDみたいなものだろう。
でも、同じ会員名であっても、実際の人物は異なるケースもある。
だから、ValueObjectを別で用意して利用する場合もあるだろう。
ドメイン駆動設計なら、ValueObjectをかなり頻繁に使うだろうと思う。

【8】概念クラスの関連付けに外部キーや複合キーを書かない。
概念クラスの関連付けは、属性ではなくクラス間の関連で書く。

この部分がデータモデリングと異なるし、引っかかるところと思う。
一般にオブジェクトには唯一の主キーとなるサロゲートキーが割り当てられる場合が多いだろう。
すると、データモデリングで考えた時、外部キーや複合キーがなく、全てサロゲートキーなので、クラス間の制約条件が分かりにくくなる。
RailsのActiveRecordがそういう例になるだろう。
データモデリングなら、サロゲートキーを使っている場合、外部キーのペアが複合キーの役割を持つので強属性になるような制約をもたせるだろう。

では、概念モデルから実装モデルへ詳細化されていくうちに、関連はどう変わっていくのか?
概念モデルの関連から相手先のロール名が割り当てられて、最終的には関連はどこかのメソッドとして実装されて、そのメソッド内でロール名は変数名と同一視されて利用されるだろうと思う。

【9】概念クラス図でも、関連クラスのように、複合キーを使った事例はある。
しかし、関連クラスを多用すると、クラス図から読み取りにくくなる。
一方、データモデリングの観点では、関連クラスを複合キーを持つクラスと置き換えれば、明確な意味を読み取りやすくなる。

【10】概念モデリングでは、クラス間の関連と多重度でクラス間の制約条件を読み取る場合が多いように思う。
慣れるまで大変だけど。

【11】そんなことを考えてみると、概念モデリングや設計原則は以前よりも変化していないように思う。
UMLが流行していた2000年代からモデリング技法は進化しているのだろうか?

オブジェクト指向設計とデータモデリングの違いは他にも整理してみる。

| | コメント (0)

2023/09/30

パッケージ設計の原則の意義は変化しているのか

パッケージ設計の原則についてちょっと議論する場があり、色々考えるものがあった。
考えたことをラフなメモ書き。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

パッケージ設計6つの原則~ポイントは関連性/依存性/抽象度 | プレイン・プログラム

コンポーネントに関する6つの原則 - Qiita

【1】パッケージ原則6個の復習。

1. パッケージ再利用等価原則 Release Reuse Equivalency Principle
* 再利用の粒度はリリースの粒度と同じ
2. 共通閉鎖原則 Common Closure Principle
* クラスは共に変化し、共に存在する
3. 共通再利用原則 Coomon Reuse Principle
* 共に再利用されないクラスを同じグループに入れるべきではない
4. 非循環依存関係原則 Acyclic Depenedencies Principle
* パッケージ間の依存関係は循環してはいけない
5. 安定依存関係原則 Stable Dependencies Principle
* 安定している方向に依存する
6. 安定抽象原則 Stable Abstracttions Principle
* 安定したパッケージは抽象的であるべきだ

【2】パッケージ再利用等価原則が最も基本の原則と考える。

ちょっと昔のJavaシステム開発であれば、リリースモジュールwar/earがリリースの単位であり再利用の単位になる。
サブシステムごとにwar/earをビルドして検証環境でテストした後、オンプレの複数台のサーバー環境ごとに、複数のAPサーバーへwarを手動でデプロイしていた。
ロードバランサーからデプロイするサーバーを切り離して、1つずつwarファイルをデプロイして起動確認し、確認OKならば外部通信できるように設定していた。
つまり、そういう面倒な手動のリリース作業があった。

オンプレのサーバ環境にwar/earファイルをデプロイする単位は普通はサブシステム単位なので、そういう粒度で再利用しやすくする。
その場合、war/earファイルはできるだけサイズは小さい方がAPサーバ再起動時間も短くなるし、リリース作業も短くなるので、リリース作業ミスの確率も減らせる。

特に最近はAWSのようなクラウド環境では、サーバ環境そのものを使い捨てみたいにコンテナから自動生成するので、コンテナ(リリースする単位)のサイズが小さいほどサービスの再起動時間が短くなり、サービス停止時間も短縮化でき、顧客満足度も高くなる。
JavaGoldを取得した時に、モジュールの話で、モジュールサイズをできるだけ小さくしたい要望がある理由がそこにあると聞いて納得したことがあった。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

【2】ただし、リリースモジュールの保守性や分割についてトレードオフがある点は理解できる。

実際、サブシステム単位にリリースモジュールwar/earをビルドする場合が多いので、普通はリリースモジュールのファイルサイズは非常に大きくなりがちだ。
なぜなら、リリースモジュールには、Apacheの共通ライブラリ、会社特有の共通ライブラリなどのJarという共通コンポーネントを多数含んでいるからだ。
同様に、RailsのようなWebアプリでも、bundlerの中には共通ライブラリGemを多数含んでいる場合が多い。

すると、リリースモジュールのファイルサイズを小さくしたくなる。
簡単に思いつくのは、リリースモジュールから他のサブシステムと共通で使う共通ライブラリは別出しして、デプロイする時は共通ライブラリは再リリースしなくて良いようにしたい。
APサーバ上に共通ライブラリを別で配置して事前ロードしておいたり、別APサーバ上に共通ライブラリを配置するケースも考えられるだろう。

メリットは、リリースモジュールのうち共通ライブラリは既にAPサーバにデプロイされているので再リリースは不要であり、リリースモジュールのサイズを小さくできる。
その分、ビルド作業時間、リリース作業時間を短縮でき、リリース作業ミスのリスクも減らせるだろう。

一方、デメリットは、共通ライブラリに手を加えた場合、既にデプロイ済みのサブシステムのwar/earファイルに影響が発生してしまう。
デグレがないか事前確認が必要だし、共通ライブラリがサブシステムのAPサーバとは別APサーバにデプロイされていて、共通ライブラリが複数のサブシステムから呼び出されているならば、複数のサブシステムに影響が発生してしまう。
共通ライブラリのリリース作業中にAPサーバを停止する事態が発生すれば、呼び出し側の複数のサブシステムで業務停止してしまうリスクが発生する。

また、共通ライブラリにサブシステムA向けのAPIを追加したり改修して、他のサブシステムB向けのAPIは触らない場合であっても、共通ライブラリをリリースする時にサブシステムAもBにも影響が発生してしまう。

だから、一般には、サブシステムごとに共通ライブラリを含んでリリースモジュールをビルドする場合が多いと思う。
すると、たとえば、サブシステムAの共通ライブラリXのバージョンは1.1、サブシステムBの共通ライブラリXのバージョンは1.2、みたいにコンポーネントのバージョンがサブシステムごとに違ってくる場合も発生するだろう。

つまり、サブシステムで利用する共通ライブラリのバージョン管理、構成管理が重要になってくる。
この仕組みがMavenであり、Railsならbundlerなのだろうと思う。
ライブラリやコンポーネントの構成管理というソフトウェアの複雑性をビルド管理の仕組みで補っているわけだ。

【3】では、昨今のアジャイル開発、DevOps、クラウドなどにより、パッケージ設計の原則の意義は変化しているのか?

メタな観点ではパッケージ設計の原則の意義は変わらない。
リリースモジュールは再利用できる単位であることは変わらないし、モジュールの分割方針やデプロイ方針も基本は変わらない。
しかし、具体的なリリース手順や開発プロセスは影響を受けていると思う。

例えば、SaaSビジネスでは、リリース作業時間は極力短くしたい。
リリース作業時間は広義の意味では、顧客に機能を提供するリードタイムと同じ。
BtoCのSaaSビジネスならば、機能改善の要件定義からリリースまでのリードタイムを短縮化する事は売上に直結する。
ちょっとした機能改善を即座にリリースできれば、顧客満足度も上がり、ユーザ数増加が売上につながるから。

また、特に昨今はクラウドでサーバーごとの仮想化するなどして丸ごとコンテナ化し、コンテナを使い捨てみたいにいくらでもデプロイできるから、リリース作業時間はできるだけ短くしたい。

これは、DevOpsの考え方と非常に相性が良いと思う。
DevOpsで開発チームがシステム運用と一体化したプロセスになるし自然にアジャイル開発になるはず。
つまり、アプリ開発者はアプリも開発するし、クラウド上でインフラ基盤もサーバー基盤もコンテナをプログラム化して自動配置できるようにすれば、開発も運用も一体化できるはず。

そして、リリース作業時間と言うKPIを開発チームが毎回計測し監視すれば、改善すべきか評価できるはず。
リリース作業時間、ビルド時間、デプロイ時間などはアジャイル開発の主要なメトリクスの一部と捉えられるだろう。
システム停止やデータ移行の時間も含めてリリース作業時間に3日間かかっていたのを、1時間で終わらせたり、わずか5分で終わらせれば、その分システム停止時間も短くでき、顧客の業務や顧客の操作時間への影響を減らせる。

そんなことを考えると、アジャイル開発やDevOpsという考え方は、サーバの仮想化やクラウドの技術のおかげで進化している部分も大きいのだろうと思う。
こんなことは既に当たり前の考え方と思うけれど、アプリ層の設計技法もインフラ基盤の仮想化技術に相当影響を受けているのではないか、と思う。

| | コメント (0)

2023/07/15

日本のアジャイル開発の先人による話が良かった

日本のアジャイル開発の先人による話が良かった。
ラフな感想をメモ。

【参考】
根回し、本音と建前……透明性が大事なアジャイルは、日本の慣習とどう折り合いをつけるべき?【平鍋健児×市谷聡啓×岩瀬義昌】 - エンジニアtype | 転職type

2000年頃からアジャイル開発がIT業界の技術もプロセスも先取りしていると気づいた人たちが、アジャイル開発を日本で導入し運用し始めてもう20年以上経つ。
ようやくアジャイル開発も日本で知名度が上がってきたが、まだメインストリームでない所が大半だろうと思う。
そんな中で平鍋さん、市谷さんの経験談や気づきに共感する所が数多くあった。
たくさんの経験を踏まえて、日本の風土に合うアジャイル開発のあり方が見えてきたのかな、と思う。

平鍋さんの発言録を読むと、日本人の風土をすごく理解されていて、琴線に触れるような言葉があるなと思う。

たとえば、アジャイル開発は「仲間作りの旅」ですよ、とのこと。
岩瀬さんが言われる通り、スクラムをやっていても、スクラムマスターやプロダクトオーナーはチームに1人しかいないので孤立しやすい。
だから、チーム外のステークホルダーだけでなく、チーム内のメンバーからも突き上げを食らったりする時もある。
そんな時は精神的にも辛い。
日本人の組織やチームはウェットなので、モチベーションアップのためにも、仲間という雰囲気作りが大切と思う。

たとえば、日本の大企業に根回し、建前があって透明性を求めるアジャイル開発と相性が悪い所がある。
しかし、平鍋さんは根回しは好きです、と言われる。
この人が反対するとプロジェクトが進まない、という状況であれば、悪い状況を最小限にするために、その人に早めに話をする(根回しする)のはありでしょ、と。
そういう人には割と感情的な部分もあるだろう。
そういう部分は日本の風土に合った現実的な解決策だなと思う。

アジャイル開発を堅苦しく考えないところがいいなと思っている。

| | コメント (0)

2023/05/26

JSTQBのテストプロセスの概念モデルを描いてみた

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

【参考】
テストアイテムとは何か?概要や定義、現場での使われ方について解説

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか?
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか?

この辺りは色々考えてみたいと思っている。

| | コメント (0)

2023/01/22

PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか

@sugimoto_keiさんのツイートを読んで、PM理論ではP志向の方がM志向よりも生産性が高いことを主張していることに気づいたのでメモ。

【参考】
杉本啓さんはTwitterを使っています: 「多くのひとは職場での人間関係を気にし過ぎる。その人が自分を支配しようとして色々束縛するなら、それは人間関係の問題だが、そうでないなら、人間関係は気にしないで自分がやるべき仕事をすれば、ほとんどの場合、解決する。人間関係が気になるのは仕事がうまくいってないから。その逆ではない。」 / Twitter

杉本啓さんはTwitterを使っています: 「昔の経営学で、課業志向と人間関係志向という概念があったが、これは課業志向の考え方。基本的には、課業志向でできることをまずやるのが先決だと思う。人間関係というものは答えがないし、根本的に解決することもできない。」 / Twitter

杉本啓さんはTwitterを使っています: 「多くのひとはたぶん、集団の中で自分の居場所を作ることが重要だと考えているのだろう。それが人間関係志向ということ。それはわかるのだが、そうではなく、何を達成するのか、そのためにどうするか考える。これが課業志向。そうすると人間関係は大して気にならなくなるし、却って良くなるものだ。」 / Twitter

【PM理論とは】歴史や特徴を事例からわかりやすく解説|リベラルアーツガイド

PM理論とは?理論とリーダー育成における活用場面をわかりやすく解説|人材育成・社員研修|ラーニングエージェンシー

PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

心理的安全性はPM理論のメンテナンスの発展形ではないか: プログラマの思索

組織論で紹介される学者はほとんどが欧米人だが唯一の日本人として、三隅二不二のPM理論がよく紹介されている。
昭和の時代にカイ二乗検定を使って統計的に有意な仮説としてPM理論を打ち立てたらしい。
PM理論の考え方は考えてみれば当たり前のように感じて、あまり気に留めていなかったが、@sugimoto_keiさんのツイートを読んで、PM理論が主張したかった本来の内容は違うのではと思った。

組織におけるリーダーの能力は、課業志向と関係志向の2つがあり、両方とも高いレベルを目指すべきとPM理論は言う。
しかし、実は課業志向の方が関係志向よりも生産性が高いことを言いたかったのではないか。
つまり、リーダーシップは結局成果を出して初めて認められるものであり、成果を重視せず関係ばかりに注力しても問題解決にならない、と。
特に、日本人のリーダーや集団は課業志向よりも関係志向を重視しすぎていて、生産性が高くないのではないか、と。

たとえば、リーダーシップとは成果主義が前提であるという考えは、「採用基準」にも記載されていたのを思い出した。
採用基準」では、成果を求められないリーダーシップに囚われすぎる日本人を批判している。

たとえば、野中先生の「失敗の本質」でも、日本軍という官僚的組織が実は成果主義よりも関係志向を重視していて、リーダー間で忖度し合うことで戦争に負けた経緯が詳しく分析されている。

たとえば、PM理論でリーダーを育成する企業は伸びる『事例紹介』 | 識学総研では、典型的な日本企業である日立でも、管理職のリーダークラスは優秀であっても課業志向ではなく、関係思考が強い傾向があるらしい。

こういう話を踏まえた上で考えると、日本人は集団でリーダーシップを発揮するという考え方や行動に何らかの問題があり、それがずっと弱点になっているのではと思う。

今の日本のアジャイル界隈では心理的安全性という概念がとても好まれているが、実は日本人のリーダーシップには関係志向が強すぎて課業志向が欠落しているのではないか、という考え方も心に留めておく。
たぶんコンテキストや環境によってはこの観点も必要だろうと思う。

| | コメント (0)

2022/12/23

現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ

採用基準」「生産性」を読み返したらいろんな気付きがあった。
ロジカルでないラフなメモ書き。

【参考】
「採用基準」の感想~日本の根本問題はリーダーシップの総量が不足していること: プログラマの思索

DXとは組織論である: プログラマの思索

Slack導入がDXに繋がる話: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

失敗の本質―日本軍の組織論的研究の感想: プログラマの思索

プログラマとスクラムが社会実装を変えていく #Findy_GovTech: プログラマの思索

デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?: プログラマの思索

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

【1】最近の日本のIT業界を見ていると、主に2つの現象が目につく。
一つは、DXに向いた組織を作ろう、という組織論の話。
もう一つは、DXを実現するためにアジャイル開発をもっと積極的に導入して運用しよう、という話。

この2つの話の背景には、2つの問題意識が真因として隠れていると思う。
具体的には、組織論の話題、アジャイル開発の話題の背後には、日本人はリーダーシップが不足していること、日本人は生産性の意識も言動も非常に低いことだ。

【2】今のビジネス界隈では、DXがバズワードだ。
DXを実現するには、既存の業務であれ、新規の事業であれ、ソフトウェアでコスト削減、さらには売上の創出が求められている。
DXを実現するには、ソフトウェア開発者、そしてそれを取り囲む組織という基盤が必要だ。

しかし、DXに関する組織論のテーマはすごくフワフワとしていると思う。
命令指揮系統ではなくフラットに風通しを良くしよう、心理的安全性が担保されるような組織風土を作りましょう、という組織文化の話題が多い。
だがそういう甘い言葉の背後には、今までの組織文化や事業スタイルを捨てて、新しい事業や新しい組織の関係を作ろうとする原動力が必要なのに、たくさんの壁にぶち当たる怖さが説明されていないように思える。
だから、何となく、現状を批判するだけで何も変わらない、という現象が出ているように思える。

実際は、既存の組織風土を変えるのは、今までの人間関係や組織との関係を変えることであり、自らリーダーシップを発揮して動いていかなければ何も変わらない。
ものすごく自頭の良い人やできる人に従ってやれば問題解決するわけではない。
自らチェンジ・エージェントになり、たくさんの困難な壁にぶち当たるごとに、一つずつ壁を壊したり乗り越えていくパワーが必要になる。

採用基準」では、問題解決には、問題解決スキルだけでなく、問題解決リーダーシップ(Problem Solving Leadership)が必要と主張している。
たとえば、目の前に起こったいじめの問題に対し、MECEやロジックツリーだと言っても何も変わらないし、実際に解決するように行動して初めて、問題解決の方向に動き出す。
それが本来のリーダーシップ。

すると、このリーダーシップの背後には、「自らリスクを取る」という概念が隠れていることが分かる。
自分の思いどおりに変わらない状況に対し、自分と異なる価値観を持つ人を説得して調整したり、自分が持っていない知識やスキルはそいうう専門スキルを持った人たちに働きかけてチームとして問題解決を図ることが必要になってくる。
そういう行動は、思い通りの結果にならないかもしれないリスクに自らチャレンジすることを求める。

しかし、日本人はリスクを取りたがらないと一般的に言われている。
すべてのリスクを回避してリスクをゼロにすることばかりに専念している。
だから、リスクを取ってリーダーシップを発揮するという行為、選択肢が取りにくい人が日本には多いのだろう。

実際、「採用基準」に記載されている通り、日本人はチームプレーでチームに貢献した成果を問われる経験が極端に少ない。
たとえば、小中高校生なら、受験という行動はその人だけの能力測定試験であり、個人プレーにすぎない。
社会人になっても、プロジェクトリーダーや管理職にならない限り、自分だけの仕事の成果しか問われない。
すると、一般職の日本人は一生、チームでの成果を求められる、というリーダーシップ経験を積まずに終わる人が多い。

そんなリーダーシップ経験のない人は、わがままな振る舞いが多い。
チームで成果を出すためにそれぞれの役割を認識せず、自分が一番成果を出しやすい行動に走ってしまいがちだから。
自分が成果を出しやすい個人プレーに走るのは、自分が苦手な場面に行動するリスクを取らないことにも通じる。

そんなことを考えると、リーダーシップ不足という弱点をごまかして隠すことで、組織論というふわふわしたテーマに流れてしまうのだろう。
そしてリーダーシップ不足という日本人論の問題点は、日本人はリスク許容度が低いことに真因があると思う。

【3】アジャイル開発は20年以上前から提唱されているのに日本ではなかなか導入すらされなかったが、ここ最近になって積極的に取り入れようとする流れが出てきた。

アジャイル開発の本質は一体何なのか?
僕は、アジャイル開発とは時間価値を最優先にしたソフトウェア開発だ、と一言で言えると考える。
WF型開発のように、時間も労力もかけて品質を作り込んで、高品質なソフトウェアをリリースするのではなく、小刻みにいち早くソフトウェアをリリースすることで売上もキャッシュも獲得していく戦略を取る。
1年間で1回のリリースではなく、5回リリースできるなら、5回分のフィードバックが得られて、その分、市場ニーズに合ったソフトウェアへいち早く開発できるようになる。
つまり、リリース頻度が5倍多いなら、ソフトウェアの価値も5倍高まるメリットが生まれる。

では、なぜアジャイル開発は日本で受け入れられなかったのか?
アジャイル開発の源流はトヨタ生産方式と言われていて、日本人にも馴染みがあるのに、なぜアジャイル開発は日本人にフィットしなかったのか?
たぶんその最大の理由は、ソフトウェア開発の生産性が低いことが問題だ、という意識が非常に薄いことだと思う。

官公庁みたいな縦割り組織の日本人は生真面目なタイプが多いので、決められたルールに従う方が重要であり、コストや期間を度外視したり生産性を重視する行動に行きやすい。
また、ソフトウェア開発者派遣のような人月ビジネスでは、たくさんの工数がかかるほど儲かるので、生産性を上げるモチベーションがビジネスモデル上生まれにくい。
今の日本の製造業では生産工程の改善により原価低減による付加価値向上を目指すが、3%の生産性向上よりも30%以上、2倍以上の生産性向上を目指すような、イノベーションを取るような行動が生まれていない。

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想: プログラマの思索

生産性が低い現象が問題だ、と考えて、その問題解決を図ることにより、生産性をさらに大幅に向上させるという正のループを作り出せていない。
特に、3%の生産性向上のようなちょっとした改善ではなく、30%や2倍以上の生産性向上を図ろうとすれば、今までのやり方を捨てて、新たなアイデアを試す、といったリスクを取らなければ実現できないだろう。
しかし、今までリスクを取ったことがない人が、いきなりハイリスクハイリターンの選択肢を取るのは非常に難しいだろう。
なぜならば、仕事でもプライベートでも、そういうハイリスクハイリターンの練習を経験していなければ、実践で試すことは難しいだろうから。

日本人の生産性が著しく低い、という点にも、日本人はリスクを取りたがらない、という現象がその問題の背後に隠れている。

つまり、「ソフトウェア開発のように、時間価値が重要な意味を持つビジネスでは、生産性に比重をおいて時間戦略を取るべきだ」という考え方が日本人も日本企業も受け入れられていないからだ。
その真因には、日本人のリスク許容度が低いこと、土建業界やIT業界に限らず自動車業界においても日本のあちこちの業界で多重請負ビジネスがはびこっていることにあるのだろうと思う。

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想: プログラマの思索

【4】リーダーシップ不足や生産性が著しく低いという現象には、リスクを取らないという日本人の気性が出ているのではないか。
あえてリスクを取ることで、大きなリターンを得る、というハイリスクハイリターンの選択肢を最初から捨てている場合が多いのではないか。

リーダーシップがあり、生産性が高い人は、いろんな問題解決に対してリスク許容度が広いので、かなり大きなリスクを自ら選択することができる。
つまり、リスク対応力とその人の問題解決能力は比例しているのだろうと思う。

【5】組織論やアジャイル開発をテーマにしている人たちは、日本人の弱点である「リーダーシップ不足」「生産性が著しく低い」「リスク許容度が著しく低い」という真因におそらく気づいている。
その真因をいろんな角度から、いろんな言葉で、いろんな手段で解決を試みようとしているのだろうと思う。
そういう観点を持って、今のDXにかかわるテーマを取捨選択して聞いてみたいと思う。

| | コメント (0)

2022/12/13

DDPは品質管理に役立つのか

DDP(Defect Detection Percentage)は品質管理に役立つのか、について考えたことをメモ。
ラフなメモなので、間違っていたら後で直す。

【参考】
資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)|Tech Village (テックビレッジ) / CQ出版株式会社

バグ密度・テスト密度に依存しない品質保証への挑戦 | DATA INSIGHT | NTTデータ

コード行数を用いない品質分析技術と開発速度を落とさない品質管理手法の提案~NTTデータ ソフトウェア品質シンポジウム2021

テスト / 品質関連メトリクスまとめ | Test-Hack | 3分で理解するIT/テスト技術

DDP(欠陥検出率)とは何か。 - ソフトウェアの品質を学びまくる2.0

【1】
ソフトウェアテスト標準用語集 (日本語版)によれば、欠陥検出率(Defect Detection Percentage (DDP))の定義が書かれている。

欠陥検出率(Defect Detection Percentage (DDP)): あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。escaped defects も参照のこと。

テスト / 品質関連メトリクスまとめ | Test-Hack | 3分で理解するIT/テスト技術では、
欠陥検出率(DDP) =検出バグ数÷当初保有バグ数×100
で紹介されている。

DDPの事例としては、コード行数を用いない品質分析技術と開発速度を落とさない品質管理手法の提案~NTTデータ ソフトウェア品質シンポジウム2021が有名なのだろう。

ただし、DDPをよくよく考えてみると疑問がいくつか出てきた。
上記のPDFでは、単体テストで潜在バグをすべて検出できず、後工程である結合テストで流出した単体テストのバグ数を数えて、結合テストフェーズでDDPを算出している。
その内容を見ると、DDP=9/10=90%なのでそれほど流出しておらず問題ないように見える。

しかし、結合テストフェーズでは、3件のバグのうち1件が単体テストから流出したバグなので、前工程から流出したバグの割合は1/3=33%になる。
よって、結合テストでは本来結合テストで見つけるべきバグよりも、前工程から流出したバグが多く見つかっているのではないか、という疑念が生じる。

また、資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)|Tech Village (テックビレッジ) / CQ出版株式会社でもそうだ。
ここでは、アジャイル開発でスプリントごとにDDPを算出している。

スプリント1のDDP=40/(40+10)=80%なので、後のスプリントにあまり流出しておらず、スプリント1は品質が良さそうに見える。
しかし、スプリント2では、バグ45件に対し、10件がスプリント1という前のスプリントのバグが見つかっている。
つまり、スプリント2のうちスプリント1が占めるバグの割合は、10/45=22%にものぼる。
前のスプリントで潰しておくべきバグが後のスプリントでたくさん見つかるということは、今実施中のスプリントで本来見つけるべきバグ検出にリソースを集中することができていない疑念がある。

また、スプリント2のDDP=35/(35+25)=58%なので、かなり品質は悪い。
スプリント3でスプリント2のバグが占める割合は、25/80=31%なので、スプリント2の時よりももっと品質が悪くなっている事実を示している。

【2】DDPが高い数値で品質が高そうに見えるが、実は品質が悪かったという状況はどんな時なのか?

それは、前工程や前のスプリントで多数のバグが見つかったケースに相当するだろう。
つまり、たとえば、前工程や前のスプリントで20件、50件、100件のように多数のバグが見つかった場合、後工程で10件流出したとしても、DDPの値は高めに出るので、一見品質は良さそうに見える。
しかし、元々DDPの分母や分子の数値が大きいので、そう見えるだけ。
後工程で、前工程から流出したバグの割合を見れば、多数のバグが流出しているだろうから、前工程ですべてのバグをすべて潰しきれていないことを示しているだろう。

つまり、DDPは前工程のバグの流出を許さないような前提条件で品質を考えている場合、DDPは品質管理に有効とはいえないだろう。
WF型開発やアジャイル開発でも、後工程がお客様という立場であれば、DDPの指標がたとえ高くても、その妥当性は色々分析してみる必要がある。

【3】そんなことを考えると、品質管理に出てくるメトリクスは1つの観点のKPIに過ぎず、品質という抽象的な成果を評価するには多数のKPIをつなげて1つのストーリーを作る必要が出てくる。
したがって、品質に問題がないという説明で納得させるには、いろんなKPIをつなぎ合わせて試行錯誤して、なんとか妥当性の根拠を示すという手間がかかるわけだ。

プロマネはそういう部分で数多くの苦労をしているので、品質管理や不具合分析は胡散臭いと思っているのかもしれない。

【補足】
@sakaba37さんのコメントを追記しておく。
メトリクスには罠が多い。
さかばさんはTwitterを使っています: 「@akipii 開発中は「いつもと同程度なら、いつもと同じようなテストが実施されたと推定できる」以上のことはわからないように思います。」 / Twitter

| | コメント (0)

2022/11/29

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体|山本 正喜 / Chatwork CEO|note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか?

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5~7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか?

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか?
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム(SoR)が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。


| | コメント (0)

2022/11/16

XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)
テスト駆動開発なら、テスト駆動開発実践テスト駆動開発
継続的インテグレーションなら、継続的インテグレーション入門継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
ふりかえりなら、アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。


| | コメント (0)

2022/11/06

第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

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

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か?
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査 事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね? #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか?
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ!という話。
チケット駆動が楽しい!
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。

| | コメント (0)

より以前の記事一覧