コミュニティ

2022/08/05

組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない

組織を芯からアジャイルにする対談で、平鍋さんが話されていた。
感想をラフなメモ。

【参考】
平鍋健児 ? 市谷聡啓 ?組織を芯からアジャイルにする対談? - シン・アジャイル | Doorkeeper

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

平鍋さんの穏やかな口調のお話を聞いていると、そうだよねとうなずくし、勇気づけられた点もあった。

1990年代、2000年代は、プロセスの時代。
仕様に対して、いかに仕様どおりに正しく作るか、品質を担保するか、が問題だった。
そのために、ソフトウェア工場、オブジェクト指向設計、要求工学、ソフトウェア工学などがたくさん出てきた。
そして、アジャイルが出てきて、今までのアプローチは違うのでは、と。
開発者の中でこねくり回すのではなく、顧客と対話したり、市場と対話してシステムを作り上げる。
2010年頃から、リーンスタートアップが出てきたのもその流れではないか、と。

今となっては、アジャイルも日本では普通に認識されるようになってきた。
今の日本では、アジャイルは先カンブリア時代みたいに、たくさんの人達がこれがアジャイルだ、とたくさん実践して公開してきている。
そんな中で、これが本当のアジャイルだ、と言う必要はないと思う。
アジャイル警察はいらない。
もちろん、自分のポジションや意見として、アジャイルはこうだというものはあるけれど、それで対立を煽るような議論はしない。
最近は議論をやめてます、と。

平鍋さんの話を聞いて、何となく救われたような気もした。
僕だけが感じているだけに過ぎないかもしれないが、最近のアジャイルの風潮として、自分はアジャイルをやってますと名乗るには、アジャイル開発の経験だけでなく、スクラムの認定資格を取っているか、認定スクラム資格を持つアジャイルコーチの指導があるのが条件なような気がしていたから。
カジュアルに、アジャイルをやってます、みたいなことが言えない気がしていたから。
顧客とオンサイトで超高速開発ツールを使ってすぐにデモして見せてアジャイルにやってます、みたいな場面があったりして、それは違うのでは、という違和感を感じていたから。

一方、スクラムの研修を受けると、内容は確かによく考えられているし、参考になる概念もすごく多い。
このフレームワークでプロセスの諸問題が解決されるのでは、と思えたりする。
1990年代から2000年代にかけて、たくさんのアジャイルの流派が生まれてきたけれど、2020年代の現在では、それらアジャイルの考え方、プロセスはスクラムへ収斂されていく過程ではないかと思ったりもした。

しかし、平鍋さんの話を聞けば、今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない。
そう思えば、そこまで神経質にならなくてもいいし、自分で経験して理解できたことがあれば、それを普通に表現して、自分なりに解釈してもいい。

他にも気になる話があった。

平鍋さんいわく、市谷さんの書籍は、熱い気持ちや勢いで書いている所があっていいね、と。
自分が思いついたアイデアには旬があり、今ここで書かなければいつ書くのか、みたいなタイミングがある。
特にIT業界の本はそういう傾向がある。
こういうことに気づいて考えたから、今書きたい、という熱いモチベーションがあるうちに一気に書くべき。
平鍋さんが共著で書いた本「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」も、今書かなくてどうするんだ、という熱い気持ちで書いた、と。
自分も、年末には書きたい本の目次は壁に貼っておいて、そこから書きはじめる時がある、と。

平鍋さんいわく、市谷さんが提唱した言葉「越境」「向き直り」もいいね、と。
市谷さんはネーミングが上手い。
気づいたアイデアに名前付けしてネーミングすることは重要だ。

平鍋さんがプロジェクトファシリテーションでレトロスペクティブを「ふりかえり」という言葉で概念化したが、過去を振り返るだけでなく未来にも目を向けていることを強調できなかった。
だから天野さんと議論した後で、小野小町の見返り美人もそうでしょ、後ろに顔は向いているけれど、足の方向は前向きだから、とフォローしたんだよ、と。

確かに、何かすごいことを思いついた時、そのアイデアを別の言葉でネーミングすることにより、新しい価値や意味をもたらすことができる。
そういう体験を僕も感じた。
その体験はやると病みつきになる感じ。

| | コメント (0)

2022/05/29

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

第22回東京Redmine勉強会の感想をラフなメモ。

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

2022/5/28 第22回勉強会 - redmine.tokyo - Togetter

【1】三浦さんの講演は興味深かった。
プロジェクトで発生する情報源として、3種類を抽出している。
エクセルファイルのような静的ファイル、Slackのような動的なチャットログ、日々のタスクやWikiなどの静的でもあり動的でもあるデータ。
資料では、一昔前の管理方法、昨今のリモートワークの管理方法、redmine.tokyoの管理方法などが紹介されていて、この発想が面白い。
具体例を見ると、Googleドライブ、SlackやTeams、RedmineやGitlabのように、数多くのサーバーが乱立して連携する形が多いみたい。
むしろ、情報源は1つのサーバーにまとめるのは逆に管理が面倒かもしれない。

三浦さんの考え方では、3種類の情報源はそれぞれの管理方法が違う。
エクセルファイルは共有ファイルサーバーだったり、Googleドライブで管理する。
チャットログは、メールよりもSlackやTeamsの方がいい。
チケット、Wiki、GitHubは別サーバーにある。

これらの情報は参照関係が双方向ではなく、単方向であるという制約がつく。
たとえば、チケットから共有ファイルサーバーの資料リンクはあるが、エクセルの設計書にはチケットのリンクを貼ることはあまりない。
そういう作業履歴の情報は不要だから。

また、チケットのコメント、GitHubのコメントはSlackのチャットログに流れた方が管理しやすい。
更新メールがたくさん流れても困る。

つまり、これら3種類の情報に分けた時、双方向の参照関係が実はあまりない。
この気付きが面白かった。

【2】かるねさん、門屋さん、ワテさんのRedmineの使い方はみんな異なる。

ワテさんは、ソフトウェア開発の受託案件が複数個走っているので、案件テンプレートを準備して、チケット管理のワークフローや初期設定、Git連携などは事前にテンプレート化しておく。
チケットの進捗管理、ステータス管理は細かく設定されている。

門屋さんはチケット一覧を重視する。
チケットの親子関係をうまく使って階層化してチケットをグルーピングしたり、ソート順を決めて、管理しやすくする。

一方、かるねさんは事務処理をRedmineで管理しているので、ロードマップ画面で、毎月のルーチンワークをバージョンで設定し、毎月ごとに事務処理チケットのボリューム感をコントロールしている。

それぞれの目的に応じて、Redmineの機能をピックアップして使っているのが面白い。

【3】ボウコバさんの講演では、Redmineを導入するときに、ボトムアップとトップダウンの手法をうまく組み合わせる点を話されていた。
たぶん、大企業では標準プロセスが揃っていて、それに従う必要がある。
そこで、標準プロセスをRedmineで実現しておき、スモールスタートで運用を開始して、成功しているよ、という雰囲気を社内に作り出す。
そこから少しずつ広げて、トップダウンで最後に広げていく、みたいなイメージ。

以前アカベコさんが、Redmineの運用では活況を演出するのが重要だ。
なぜならば、活発に更新されてすごく便利そう、という雰囲気を醸し出さないと、根付かないから、と言われていたが、そのやり方に似ているな、と思った。

僕は、ボウコバさんのように、チケットに情報を集約する方が好き。
そのチケットは、日々のタスク管理のようなフローの情報、課題管理や障害管理のようなストックの情報の二重性を持つ。
チケットに2つの情報が集約されることで、検索機能やハイパーリンクが使えて、Redmineがナレッジデータベースになるというイメージ。

【4】内藤さんの発表では、直近4回位のRedmine勉強会の参加者が常連さんに偏っている点がグラフで示されて、正直びっくりした。

その原因は色々あるだろう。
オンライン勉強会になったので、地方の人も参加しやすいが、対面で知り合う機会がないので、初対面同士で盛り上がりにくい。
自然に、すでに知り合いの仲間同士で盛り上がってしまい、その輪に入るのはなかなか難しい。

一方、Redmineの機能改善も、チケット管理ツールのライバル製品の機能を取り込む方が多くなっているので、独自性をアピールする点が不足していることもあるだろう。

他方、チケット管理ツールの概念はある程度知られてきていて、イノベーターやアーリーアダプターにとっては新鮮味があまりない点もあるかもしれない。

このあたりの原因は色々聞いてみたい。

とはいえ、今日の勉強会の中身も濃かったと思う。
講演もLTもちゃんと聞いていると、こんな使い方もあるのね、とか気づきが多かった。

【5】西崎さんがRedmine開発者コミュニティを作ろうと提唱されていた点も興味深かった。

やはりRedmineの開発は情報源が少ないので、もっと多くの人を巻き込まないといけない。
Redmine開発者コミュニティがハブになって、他のRedmine勉強会の人たちをつないで、開発に興味を持ってもらったり、ユーザに使ってもらってフィードバックをもらうことを考えられていた。

一方、山崎さんはRedmine Marketplaceを作り、Redmineのプラグインを集めて、有償販売できたりするWebサイトを準備されていた。

つまり、Redmineをさらに使いやすくしたり、手に届くような環境を作ろうと活動されている。
こういう活動を見ていると、やっぱり日本人にはRedmineが向いているのかな、と改めて思う。

| | コメント (0)

2022/04/10

『ものづくりの数学』の感想 #もの数

今朝、講演会『ものづくりの数学』に参加してきた。
感想をラフなメモ。
全くロジカルでないメモ。

【参考】
講演会『ものづくりの数学』 - connpass

講演会のテーマは、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の著者の先生に、企業の技術者と理論物理・純粋数学の科学者という2つの立場から、ものづくりの現場に現代数学をどのように導入して効果を上げるべきか、という内容だった。
内容は相当難しいと思う。

改めて『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読み切ってみると、読者の対象は、大学で純粋数学や理論物理、理論化学を学んだ後、社会人では一般企業の技術者や管理者、IT業界の技術者になった人だろうと思う。
大学の理論研究の経験と一般企業でのビジネス経験の両方がなければ、この本の意義は理解しにくいだろうと思う。

なぜなら、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の内容はすごく抽象的だからだ。
実際、数式は出てこないけれど、現代数学がメーカーの製品開発の背景にあるという経験がなければ腑に落ちないだろう。
また、ポパーの反証主義、トーマス・クーンのパラダイム論やフッサール現象学、ソシュールの記号論などの概念がふんだんに引用されるので、なぜこの知識が必要なのか、という意図がつかめないだろう。
専門の科学者集団はパラダイムに囚われすぎているという先生の指摘は斬新ですごく面白かった。

僕が感じた感想は3つある。

【1】今の日本の弱点は、ハードウェアに付加価値をつける点では新興国の韓国・台湾・中国に追い越され、ソフトウェアやシステムで付加価値をつける点では、米国に負けてしまっていること。
その問題を解決する時に、現代数学が役立つよ、という主張だった。
その製品開発のフェーズに現代数学を使ってモデル化を図って、理論の裏付けを持った技術に育て上げるような方向性だろうか。

だが、ハードウェアの付加価値に差別化を図ろうとする場合、より尖った製品を開発するのは困難だろうと思う。
そのマーケットがそもそも売上や利益が出るような規模なのか、そこにマーケティングを実施して掘り起こせるのか。
その市場で売上を確保できる期間が十分にあるのか。
今の時代は、世界の工場である中国にほとんど製造拠点を持って行かれているので、日本も米国のように、おそらくAppleのように安いハードウェアにソフトウェアやブランドという付加価値を付けて高値で売るようなビジネスに行かざるを得ないのではないか、と思った。

すると、ソフトウェアやシステムで付加価値をつけるフェーズで、現代数学とコンピュータサイエンスを組み合わせて、技術の差別化やビジネスモデルの構築を図る、みたいな方向性が王道になるのではと思う。
しかし、日本から世界に通用するプラットフォームビジネスを生み出せるのか。
日本で現代数学も使えるようなIT技術者を育成できるのか。

先生のお話を聞くと、日本の大学という制度はもう時代に即していないんだなと改めて思う。
明治から昭和までのやり方を未だに大学で続けようとしているが、令和の時代では違うでしょ、みたいな感じ。

akipiiさんはTwitterを使っています: 「今聞いているけど面白い。今の日本の大学という制度は時代に即していないと先生が言い切るのがすごいね。大学もお金を集めないとやっていけない現状、理論の専門家が企業に必要なのに大学が人材供給できていない現状とか色々あるだろうな。#もの数 講演会『ものづくりの数学』 https://t.co/8ijd5ko08g」 / Twitter

【2】先生のお話で面白かったのは、純粋数学や理論物理などの科学者の専門集団はパラダイムに囚われすぎていて、彼らだけに通じる基準と運用で維持し続けられているが、常にその存在意義の正当性を問われているという指摘だった。
自分も大学で数学の研究に従事していた時があったので、その雰囲気がそういう観点で見られているのが斬新だった。

ものづくりの数学のすすめ 技術革新をリードする現代数学活用法』にかかれているトーマス・クーンのパラダイム論の解釈を読むと、科学者という専門集団は真理を追いかけているように見えるが、すごく閉鎖的な集団なんだよ、という意見に聞こえてしまうのが不思議だった。

akipiiさんはTwitterを使っています: 「問題解決者よりも問題定義者が重要。学会はパラダイムに囚われすぎている。ビジネスの現場で抱えている問題は既存の学会や理論で解決できるとは限らず、むしろ無い場合が多い。現場の問題に忠実に認識してその問題を数学で分解して定義し、その一つを大学へアウトソースして解決してもらうとか #もの数」 / Twitter

一方、ビジネスマンは企業の現場で解決したい問題がすでにある。
その問題は理論や学術面で意義は小さいかもしれないが、その現場ではすごく価値がある。
そういう問題を解くのに現代数学という理論を使うとより効果的だよ、と。
そして、大学での理論研究と企業の現場の違いを認識して上手く利用したほうがいいよ、と。

akipiiさんはTwitterを使っています: 「ビジネスと理論のような大学の場の双方を知るような人材をどうやれば育てられるか?先生曰く。ビジネスマンは大学の弱点や問題点を知るのが大事。そんな話を聞くと、日本の大学は時代に即していない感じがするね。 #もの数」 / Twitter

特に、理論と技術の間にはタイムラグがある。
このタイムラグはいわゆる、死の谷、魔の川、ダーウィンの海に相当する。
すると、理論を研究したり使う時も、その技術がビジネスに使えて実際に威力を発揮できるには、いくつかのハードルを越える必要がある。

akipiiさんはTwitterを使っています: 「#もの数 フィリップスを作ったカシミールの考え方。科学と技術は違う。資本主義企業が科学を引っ張るというモデルを経営者は持つがそうではない。量子力学が生まれた時、ビジネスとも関係なく、半導体やコンピュータのビジネスに繋がることは誰も知らなかった。」 / Twitter

【3】なぜ現代数学の理論が企業の技術者やIT技術者に求められるのか?
その理由は、現場の問題を解決しようとする時、既に知られている技術や小手先の知識だけでは対処できず、20世紀以後の現代数学の理論を最終的に使わないといけない場面が出てきているからだろう。

例えば、線形代数の利用シーンが連立方程式や固有値計算だけではなく、代数・幾何・解析・確率論などの色んな場面で使われている。
特に、線形代数の理論は、ニューラルネットワークや機械学習のモデルの計算ではよく使われている。

akipiiさんはTwitterを使っています: 「先生曰く。現代数学は線形代数化している。現代数学は幾何学化している。代数幾何学も線形代数にすぎない。色んな所で線形代数が出てくるのにどの書籍にも解説していない。だから出版した、と。 #もの数」 / Twitter

akipiiさんはTwitterを使っています: 「平鍋さん曰く。行列はAIや機械学習で解きたいデータを表現していて、それを線形代数の理論で解くものと思っていた。なるほど、そういう見方で考えれば画像認識技術にAIが使われる意味が分かる気がする。 #もの数」 / Twitter

先生の話では「位相」という言葉がよく出てきて、どういう意味で使っているのか、当初は理解しにくかった。
ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読んでみると、いろんな事象を分類する基準、その構造の近さを同値関係で表していると思った。

akipiiさんはTwitterを使っています: 「位相とは何ですか?という質問に先生曰く。数学者は点ではなく部分集合で考える。だから、関数単体で考えるのではなく、関数の集合で考えて、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するわけか。工業化学をやった人はこの考え方が分かってないと言われた。 #もの数」 / Twitter

代数幾何学が楕円曲線をドーナツの形で分類するように、いろんな事象を数学で捉える時、点ではなく部分集合でカテゴリ化して、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するという発想と思えた。
たぶん、現代数学を知らない人向けにそういう意味で使っているのかな、と想像した。

【4】『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』はとても良い本と思うけれど、現代数学の知識を適用する場所は、メーカーの現場の問題よりも、経済学に関する問題の方がよりインパクトがあるのではないかと僕は思っている。
なぜなら、数学者や物理などの科学者は1990年代頃から経済学や金融にシフトしていること、数学の理論を使えばIT技術と経済学や金融がすごく相性が良いことが分かってきたからだろうと思う。

講演会の参加者には、データサイエンスに詳しい方が割と多い気がしたけど、その人達のバックグラウンドはむしろ、経済事象やマーケティング事象などの社会科学の方が近い気がする。

IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索

計量経済学における統計上の根本問題: プログラマの思索

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

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

機械学習で反実仮想や自然実験が作れる: プログラマの思索

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

僕の問題意識はちょっと別の方向にあるかもしれない。

| | コメント (0)

2022/02/25

RedmineJapan vol.2が開催されました #RedmineJapan

本日、RedmineJapan vol.2が開催されました。

RedmineJapan vol.2 2022/2/25 - Togetter

REDMINE JAPAN vol.2 オンライン開催 - connpass

Redmine Japan - Redmine Japan Vol.2 ?明日の仕事を変えるために必要なモノ?

参加して良かったです。
とても参考になった講演は、市谷さんの仮説検証アジャイル開発の講演、和田さんの開発プロセスの話。
Redmineに関係ないです、と二人とも語っていたように、Redmineとは無関係の話でしたが、アジャイル界隈、テスト駆動開発の界隈では超有名人なので、話は面白いです。

また、RedmineAwardを私も受賞させていただきました。嬉しかったです。
今後もRedmineコミュニティを緩く長く続けたいと思います。

| | コメント (0)

2021/11/28

第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある

第21回東京Redmine勉強会の感想をラフなメモ書き。

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

2021/11/27 第21回勉強会 - redmine.tokyo #redmineT - Togetter

【1】最初は、@g_maedaさんのRedMica、そしてRedmineの最新機能の紹介。

【1-1】複数キーワードによるAND検索の実装は嬉しい。
チケット一覧から、Google検索みたいに細かい条件で検索できる。
チケット検索機能の強化につながるので、Redmineをナレッジ資産として使う現場としては貴重な機能と思う。

【1-2】チケット一覧でカスタムクエリをデフォルトで表示できるようになった。
PJごとに、みんなが見たいビューはたいてい決まっている。
最初にカスタムクエリで絞り込んでおけば、今日はどの作業に注力すればいいのか、考える必要もないはず。

【1-3】CommonMarkdownの試験的なサポートも興味深い。
斎藤さんのLTでは、Confluenceがすごく便利と話されていた。
実際、Confluenceでは、Wordのような直感的なUIで表も挿入できるし、履歴管理もすごく楽。
Confluenceがあれば、Excelの設計書を廃止して、すべてConfluenceで設計書を書くことができる。

一方、RedmineのWikiでは、Markdownの原稿を逐一プレビュータブで開いては確認する手間がかかる。
また、表のセルの結合、細かな文字の装飾も直感的ではない。

本来は、WikiはWordやExcelの代替機能になるべきだ。
そうすれば、Redmine上で、日々のタスク管理や課題管理はチケット、技術情報や設計書はWikiに全て集約できる。
それ以外の足りない機能は、REST APIやGit連携などの機能によって、他の外部ツールと連携すればいい。
最終的には、Redmine一つでPJの情報をすべて一括管理できるし、Redmineはナレッジ基盤そのものになるはずだ。

【1-4】Mermaid.jsによる作図機能は面白い。
PlantUMLみたいに、UMLのクラス図、シーケンス図、フローチャートをテキストで表現できる。
ただし、redmica_ui_extensionプラグインの機能なので注意。

個人的にはPlantUMLは好き。
モデルそのものもテキストで管理できれば、Gitで履歴管理できるので、設計書をソースコードと同じように管理できるのはいい。

My Redmine インストール済みプラグイン | My Redmine

GitHub - redmica/redmica_ui_extension: This plugin adds useful UI improvements to RedMica.

plantuml - Plugins - Redmine

Redmineには2つのPlantUMLプラグインがある - taikii blog

【2】第21回 パネルディスカッション <Redmineとわたしたち>では、モデレータ、パネラーの女性5人によるフリーディスカッション。

【2-1】面白いのは、5人の女性のキャリアが全員違うことだ。
もちろん、5人全員がRedmine経験歴は10年なのでベテランばかり。

akipiiさんはTwitterを使っています 「Redmineを使う女性だけのパネルディスカッション。サーバ管理者、プロジェクトマネジャー、SEPG、PMO等の色々なキャリアを持つ。組込ソフトウェア会社、外資系、サービス系、メーカー系など色々な属性。面白そう。 #redmineT」 / Twitter

【2-2】僕の琴線に触れたのは、ともこさんとりょうこさんの発言だった。
りょうこさんは外資系SIのPMでPlanioを使っているので、プロマネ観点が多い。
だから、Redmineパトロールみたいにチケット保守や、多数の社外関係者のユーザの権限管理の観点が多くなる。

akipiiさんはTwitterを使っています 「PMの方の意見では、Redmineのパトロールが大事。Redmineの運用がずれてしまうので、定期的にチケットの運用をパトロールする。ゾンビチケットを駆除したりとか。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineの良さ。半年前のチケットを元にコピーして今回の作業チケットを作れるので、差分だけ見ればよく作業漏れがなくなる。関連チケットでチケットを相互関係付けられる。色んな会社の人が使うので権限管理が細かく決められるのがいい。 #redmineT」 / Twitter

一方、ともこさんは全社のソフトウェアの障害管理、全社PJのゲートレビューの管理、Redmineサーバーの管理をされているので、PMOの観点が多い。

akipiiさんはTwitterを使っています 「Redmineが使いにくい所では、UIが初心者のハードルが高い意見が多いが、UIよりもワークフロー設計の方に課題がある意見の方に興味を持った。トラッカーとステータスで障害管理、定常業務の作業管理のワークフローをどう設計するか?の方が重要だし腕の見せ所と思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineに限らずチケット駆動の弱点の一つは、チケットの説明欄が自由すぎること。起票者の能力によってバラついて作業連携やコミュニケーションにロスが出る。そこでテンプレートを用意したり、事前にテンプレートチケットのリンクをWikiに用意して誘導する。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを通じて対面だけでなく非同期のコミュニケーションもやっている。1年前の障害チケット、既に去った人が書いたチケットを読んで意図を理解する。チケットの説明欄に、障害内容や関連するチケットがこれです、と書けば伝えられる。書いて伝える能力が要求される。 #redmineT」 / Twitter

【2-3】女性ならではの観点では、お母さんみたいな役割もあるらしい。
この辺りは中年男性の僕には分からない笑。

akipiiさんはTwitterを使っています 「管理者がオレオレ運用ルールを押し付けると、メンバーは何でやねん!と反発してしまう。そこで相談しやすい雰囲気を作って、お母さんみたいな役割を持って、悩みを聞きまくる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineをパトロール中に、この表現はダメだよね、と気づいたら、チケットもコメントもコッソリ直したり指導する。IT技術者の説明はぶっきらぼうで、これが仕様です、と書いてもノンITの人には伝わらない。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「心理的安全性を高めて雰囲気を良くして、チケットに書いたら、お互いに時間を有効に使えるよ、と伝えたい。 #redmineT」 / Twitter

【2-4】5人のディスカッションでは、「柔軟性」というキーワードが多かった。
「Redmineはユーザとツールの観点で柔軟である」と。

ツールの観点では、Redmineはプラグインやパッチのおかげ機能追加がすごく柔軟な特徴を持つ。
一方、ユーザの観点では、Redmineは現場の人たちのニーズに応じて、運用ルールを柔軟に変更してFitさせることができる。

僕は、「柔軟性を英語でいうと、Elasticと思う。AWS用語でよく出ると思う。 #redmineT」と思っていたが、どうやらFlexibilityの方がイメージが合っていると思う。

akipiiさんはTwitterを使っています 「柔軟性には、ツールの柔軟性と人としての柔軟性の2つの観点がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「100人上のユーザの中で女性PMが一番Redmineが詳しいが、若い人の意見に時々はっと気づく時がある。自分が決めた運用ルールが絶対ではないのでこう変えてもいいかもと思う時もある。人の柔軟性を実現してくれる柔軟なツールがRedmine。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineは、各人が貯めている経験や知識を吐き出すのに向いている。他人の言葉にハッとする時はむしろTwitterや対面の方が多いのではないか。 #redmineT」 / Twitter

【3】田畑さんの森林管理でRedmineを利用している事例はとても面白かった。
岡山の山奥の村に、林業でDXをやっているらしい。

【3-1】Redmineを使う場面は、補助金の申請業務や日々の作業管理。

akipiiさんはTwitterを使っています 「林業だけでは収入が少ないので、補助金の書類が大事。書類が多い。そこでRedmine。人によって情報格差が大きい。知っている人は作業できるが、知らない人は作業できない。ストレスが溜まる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ステータスは、下請けさんの作業街が多いので追加。監督者対応中も追加して65歳の監督者を想定。補助金の申請業務は他者対応待ちを追加。実際の業務で必要だから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「プロジェクト=現場。バージョン=作業監督。チケット=作業で数時間。トラッカー=設計、実施、監査など。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「トラッカー=設計、監督、実施後で作ったが、WFが同じなので分ける必要はなかったかもしれない。 #redmineT」 / Twitter

【3-2】Redmineで工夫している点は、ワークフロー設計と、GTTプラグインを入れて、チケットに地図情報を記載している点だ。
実は、第20回勉強会 - redmine.tokyoで「 第20回 LT: Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介」で知って、取り入れたらしい。

Redmineと地図情報を組み合わせるアイデアは面白いと思う。
営業活動や配送管理などにRedmineを適用できるのではないか。

akipiiさんはTwitterを使っています 「森林管理は口承伝承。作業手順を文字化して標準化したい。作業手順記録はWiki、作業状況確認はRedmine+GTTプラグイン。前回勉強会LTのGeoTaskTrackerプラグインを使う。 #redmineT」 / Twitter

GitHub - gtt-project/redmine_gtt: Plugin that adds spatial capabilities to Redmine

akipiiさんはTwitterを使っています 「チケットにGTTプラグインの地図情報が表示される。チケット説明は簡単に書く。詳細はWikiに書く。チケットの説明に詳しく書くと流用しにくい。 #redmineT」 / Twitter

【4】僕も久しぶりに「Redmine屋から見たMS Planner #redmineT」を講演した。
Teamsに付属しているPlannerを使っているのだが、とにかく使いづらくて仕方ない。
Plannerは所詮ToDo管理に過ぎず、もっと細かなタスク管理や課題管理をやるのには向いていない。
当たり前なんだけどね。

MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから: プログラマの思索

懇親会で聞いてみたら、ブレークアウトルームの大半の人はTeamsを使っている。
Slackを使う人はごく少数。
Office365を使う企業は多いので、Teams利用者が圧倒的に多い。
すると、フリーのPlannerも付属してくるので皆知っている。

しかし、Plannerは使えませんという声が圧倒的だった。
興味深い意見は、Plannerのタスクには更新履歴が残らないので、ナレッジにならない。
使い捨てのカードみたい。
PostItの感覚でしか使えない。
本来は、Redmineのように、完了したチケットでも後から参照したいのに、と。

【5】今回の勉強会は参加者が100人にも到達しなかった。
同日開催の裏番組のOL勉強会が多かったせいだろう、という意見が多かった。

また、@naitohさんのRedmine.tokyo21 questionnaireの通り、初めての参加者が少なく、4回以上の参加者が圧倒的に多くなっている。
この傾向に危険を感じる人も多い。

でも僕はあまり気にしていない。
我々の勉強会が楽しくて盛り上がっていれば自然に人は集まる。
誰でも参加できるような雰囲気さえあればいい。
他人の都合に合わせる必要はないし、こちらの雰囲気が良くて気になるなら、こちらの都合を合わせてくれればいい。

コミュニティはボランティアなので、過大なコミット感まで持たなくていい。
むしろ、緩く長く続けることのほうが大事と思う。
年2回開催という絶妙のバランスのおかげで、スタッフの作業負荷も大きくない。
5月、11月に定期的に開催できるリズムがあるから、参加者もスタッフも講演者も予定を入れやすい。

この勉強会ももう10年以上も続いているのは一つの奇跡だと思う。
他のアジャイルコミュニティも浮き沈みがあって、スタッフの入れ替え時期には開催できなかったりしていた。

三浦かずひとさんの通り、純粋に楽しめればいいと思う。

みうら かずひとさんはTwitterを使っています 「#redmineT 最近RedMineに対する思いもないし、特段興味を持って参加ではなかったのだけど…「利用者視点かつファンでない視点で見つめる」と、「お、工場?」「お、林業?」とか、凄く純粋に楽しめました。」 / Twitter

【6】2021年もAdventCalendarをやっているので、興味のある方はぜひ応募してみてください。
書いてみると、1年後には記念になるのがいいです。

Redmine Advent Calendar 2021 - Adventar

| | コメント (0)

2021/11/09

なぜソフトウエア後進国の日本でRubyは成功したのか?~ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある

なぜソフトウエア後進国の日本で、Rubyは成功したのか? 生みの親・まつもとゆきひろが語った五つのポイントの記事がとても心に残った。
ラフなメモ。

【参考】
なぜソフトウエア後進国の日本で、Rubyは成功したのか? 生みの親・まつもとゆきひろが語った五つのポイント - エンジニアtype | 転職type

この記事で僕の心に響いたのは下記の文章だった。

(引用開始)
ソフトウエアの成功にとっては、コミュニティーやポリシーなど、意外とテクノロジーではない部分が重要だというのが、私の経験から言えることです。
(引用終了)

ソフトウェアは、プログラマが書いて生まれる。
しかし、永続的に存続していくには、ソフトウェアを囲むエコロジーが必要だ。
それは、開発者コミュニティやユーザコミュニティだ。

熱心なユーザや開発者がいるからこそ、ソフトウェアのバグがあってもユーザが見つけてくれて、開発者がパッチを即座に当ててくれる。
高品質なソフトウェア、永続するソフトウェアは、熱心なユーザや開発者がバグ修正したり、新たなアイデアに基づく機能改善によって成長していく。

オープンソースのコミュニティの存在意義と知的財産権: プログラマの思索

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

次の文章もすごく心に残った。

(引用開始)
最初に申し上げた通り、日本の大企業的なやり方はソフトウエアづくりの面ではうまくいきません。21世紀のソフトウエアビジネスをしようと思ったら、コミュニティーの存在が不可欠なのではないかと思います。
(引用終了)

日本の大企業的なやり方とは、製造業に基づく大量生産かつ高品質な生産プロセスとのことだ。
製造業の高品質な生産方式は、規模の経済を活かしやすい特徴がある。
しかし、ソフトウェアは規模の経済が効きにくいのが最大の特徴だ。
大人数で開発するほどソフトウェアの品質は悪くなるのはよく知られている。

ソフトウェアもムーアの法則で巨大化する: プログラマの思索

少人数のチームの方がソフトウェアの品質は高いという経験則: プログラマの思索

ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある: プログラマの思索

その理由は、人月の法則、リーマンの法則によるものだ。
コミュニケーションロスが、ソフトウェア開発の生産性を大きく落とす。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

その背後には、Conwayの法則がある。
1つのコンパイラを4チームが作ったら、4つのインターフェイスに分割されて、無駄に複雑なアーキテクチャになってしまった、という逸話を思い出す。
つまり、「アーキテクチャは組織構造に従う」。
だからこそ、逆に、組織をアーキテクチャに合わせるように、組織をフラットに少人数なチームへ編成し直す戦略が必要になる。
これが、逆コンウェイ戦略。

今、「DXとは組織論である」という風潮が流れているが、その背景には、ソフトウェアに基づくビジネスモデルを構築したいならば、従来の重厚長大な階層型組織ではなく、ソフトウェア開発に向いたフラットで少人数のチームへ編成し直すべき、というメッセージが込められているのだろうと思う。

Conwayの法則~アーキテクチャは組織にしたがう: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説: プログラマの思索

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

| | コメント (0)

2021/08/08

redmine.tokyo10周年を祝う会でふりかえりしました #redmineT

redmine.tokyo10周年を祝う会が開催されたのでメモ。

【参考】
Redminetokyo 10周年を祝う会 - redmine.tokyo

shinagawa.redmine キックオフミーティング が開催されました - secretbase.log

akipiiさんはTwitterを使っています 「https://t.co/i2sJFMVOU3 の初回の打合せの参加者は、割といましたね。@tkusukawa @tech_machii まるやまさんもおられましたね。#redmineT」 / Twitter

はるかさんはTwitterを使っています 「あきぴーさんの記事はこれですね。https://t.co/DjjTZPJ3S2 #redmineT」 / Twitter

redmine.tokyo10周年を祝う会で歴史を堪能する #redmineT | マドびっ! Madosan's View

【1】redmine.tokyoのコミュニティですごいと思うのは3つある。
1つ目は、コミュニティが10年続いたこと。
自分がスタッフとして関わったコミュニティで、熱量が維持されて10年も続いたコミュニティは、redmine.tokyoとSEA関西ぐらいだろうか。
アジャイルのコミュニティも他のコミュニティも、10年も長続きしなかった。
どのコミュニティも浮き沈みがある。
ブームに乗って盛り上がった時もあるが、スタッフが高齢化したり、熱量を持つスタッフが減ってしまったりする。

あるいは、熱量を持つスタッフが複数人いて最初は良かったが、視線のベクトルが異なってしまって、コミュニティとして分離してしまったり、とか。
いくら仲が良くても、思想や性格も違うので、それがきっかけで別れてしまう時もある。

そんな経験を経て、「コミュニティは細く長く続けること」が大事かなと思っている。

【2】2つ目は、redmine.tokyoは初期立ち上げのスタッフが多数残っていること。
@tkusukawaさん、@naitohさん、@ohwadaさん、@haru_iidaさんが残ってくれている。
もちろん離れたスタッフもいるが、10年も続いた縁は本当に長いと思う。
人間関係は長いほど、その人の性格や価値観も分かってくるし、そういう安心感もある。
熱量が減ったとしても、同窓会みたいな感じで戻れる場があるのは心強い。

【3】3つ目は、KPTを10年続けていること。
会社でも、コミュニティでも、KPTのふりかえりを実施している所は少ないのではないか?

第1回勉強会でKPTをWikiに残しているが、当初は僕がちょっとやりたかったという気持ちもあって気軽な感じだった。
それが10年もKPTを続けると、今回の勉強会で試して分かったことや良くなかった点を、次回に活かしたいね、という内容が出てくて、次回の勉強会に活かせるようになる。

年2回の勉強会なので、半年ごとのPDCAサイクルを自然に回していることに、後から気づいた。
KPTの活かし方はこんなものなのかな、と後から気づきが多かった。

【4】僕はコミュニティという場は好きだ。
理由は、コミュニティでは、同じ価値観や問題意識を持っている前提が暗黙的にあるおかげで、誰とでも気軽に人間関係を作れるから。
相手がたとえ社長のような社会的地位が高くて年収が高くても、コミュニティでは全く関係ない。
その人自身に能力があり、人格が優れていて、リーダーシップがあれば、自然に輝くし、自然に人間関係が作れる。
つまり、本音で話せる雰囲気が出やすい。

一方、会社では、組織上の地位や権限、権力関係が人間関係にも現れてくる。
どうしても、腹を割って話すのは難しい。
上司であれば、丁寧語を使ったり、相手におもねったり、忖度してしまう。
営利企業であり、仕事であるから、人間関係に請負契約みたいな雰囲気も出てしまう。

コミュニティではそういう責任がない点もあるだろうが、より純粋な人間関係が現れやすい気がした。

【5】redmine.tokyoも今振り返ると、浮き沈みはあったのではないか、と思う。
立ち上げ当初は、藤原さん、小久保さん、岡本さん、@haru_iidaさんのように、ツールの自動化の連携、アジャイル開発への適用に興味を持つ人が多かった。
あるいは、SIerのプロジェクトリーダーとして、ソフトウェア開発のPJ管理を自動化して、チーム運営する基盤を求めていた。
しかし、Scrumが普及し、ツール自動化が当たり前になって、その流れはある程度廃れた。

一方、2015年頃からRedmineユーザの兆候が変わってきた。
情シスやメーカーのような他業界の人達が入ってきて、いろんなRedmine利用事例を発表するようになってきた。
あるいは、PMOやSEPGのように、複数プロジェクトのQCDをモニタリングしたい第三者レビューの観点の人も入ってきた。
そんな話を聞くと、いわゆるプロジェクトリーダー層だけでなく、他業界で現場を回している係長クラスの人達にRedmineが当てはまっているんだな、と感じる。
つまり、Redmineユーザ層の変化が暗黙的にスムーズに行われたのではないか、と結果的に思う。

【6】参加者が現場に持つRedmineは、どれも唯一で、独自にカスタマイズされたRedmineばかりだと思う。
つまり、参加者が運用しているRedmineは、他のユーザの現場に持っていくと使えないだろう。
なぜなら、参加者が持っている問題意識や課題を解決するためのRedmineに特化しているので、他の現場ではコンテキストが違うからだ。

特に最近のredmine.tokyoのLTで聞かれるRedmine利用事例は、どれも個性的で、その現場でしか通用しないRedmineだ。
他に持って行っても通用しない。

だからこそ、そういうRedmine利用事例を聞くのは面白い。
そういう問題意識や課題から、なぜ、そんなカスタマイズしまくりのRedmineになってしまったのか、そういう経緯を知れるのが面白い。

【7】僕自身も最近はRedmineとチケット駆動開発の思索よりも、他のテーマのほうが多くなってきた。
今となっては、会計システムと同じように、チケット管理システムも普通の開発基盤になったように思える。
チケットでタスク管理することで、一元管理する発想は、もはや当たり前で、そこに新規性はない。

では、Redmineはどういう方向に進化すべきか?
どんな課題を解決していくべきなのか?
Redmineが提示すべき価値観とは何なのか?

その辺りは今後も考えていく。

| | コメント (0)

2021/06/26

アジャイル開発で日本の品質技術をどこで活用すべきか #jasstkansai

JaSSTソフトウェアテストシンポジウム-JaSST'21 KansaiをOLで聞いている。
誉田さんの品質重視のアジャイル開発の講演がとても良かったので、ラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'21 Kansai

akipiiさんはTwitterを使っています 「誉田さんの品質重視のアジャイル開発の講演は良かった。アジャイル開発の中で、日本の良さを活かせる箇所はあるしそこに特定して注力すべき、というメッセージを受け取った。日本はアジャイル開発が遅れているので、励まされる。 #jasstkansai」 / Twitter

【1】アジャイル開発が日本に浸透しない理由は、「多重下請け構造に慣れたおじさん技術者が多いのでそう簡単に変化しない」ことに尽きるのではないか。

akipiiさんはTwitterを使っています 「アジャイル開発は自己組織化を重視しすぎ、という意見は同感。日本の現場では「多重下請け構造に慣れたおじさん技術者」が多いのでそう簡単に変化しない。簡単なのは、人を入れ替えるしかないんじゃないかな。 #jasstkansai」 / Twitter

アジャイル開発のチームは、リーダーがおらず、全員が自律的に動く。
しかし、日本のSIは多重下請け構造が一般的なので、発注者、プロマネ、下請け開発者という階層構造が当たり前。
ソフトウェアの請負契約がそういう縦割りの組織文化をさらに助長させて、ソフトウェア開発に悪影響を与えている。

DXは組織論である」からには、組織文化を変えるだけでなく、その組織文化を生み出す組織構造を壊さなければたぶん治らない。
実際は、年を取るほど新分野を勉強して成長するのが難しいので、人が育つのを1年も2年も待つのは難しい。
今の時代で、ビジネスはそこまで待てるのだろうか??
人を入れ替えるしかないのかもしれない。

cobaltさんはTwitterを使っています 「新人だけで構成されたアジャイルチームが失敗するのは自明では? 成熟したチームに育成目的で新人を入れる方が将来的に良いと思う。 #jasstkansai」 / Twitter

【2】アジャイル開発に日本の品質技術をどこで活用すべきか、について、本当によく考えられていると思った。

akipiiさんはTwitterを使っています 「品質重視のアジャイル開発の肝は、Doneの定義=出荷判定とみなす点と思う。そうすれば、日本の品質技術を適用しやすいし、メトリクスによる定量化も可能になる。 #jasstkansai」 / Twitter

欧米発のアジャイル開発をそのまま取り入れても、たぶん日本ではうまく行かない。
アジャイル開発の肝は、マネジメント系プラクティスよりも技術系プラクティスをどこまで徹底させるか、にあると思う。
マネジメント系プラクティスはたぶん、日本人も理解しやすい。
しかし、実際にアジャイル開発の開発基盤がなければ、ソフトウェア開発で結果を出していくのは難しい。

誉田さんの講演では、Doneの定義=出荷判定とみなすことで、従来の日本が誇る品質管理技術を活かせるようにした点に意義があると思う。
そうすれば、バグの原因分析、なぜなぜ分析、レビューの徹底、XDDPなどいろんな技術をアジャイル開発に適用しやすくなる。
品質をプロダクト品質、プロセス品質に分解し、日本の品質技術がどこに当てはめられるか、どのような効果が得られるか、を明示したのもわかりやすかった。

XPが生み出したTDD、CI、CD等の技術プラクティスに、日本の品質管理技術を組み合わせれば、日本の独自性も生み出せるだろう。

アジャイル開発で日本の品質技術を適用できれば、データによる定量化と統計的予測、統計的品質管理の技法を活用できる。
アジャイル開発に統計的品質管理を当てはめられたら、色んな知見が得られそう。

【3】しかし、アジャイル開発に統計的品質管理を安易に適用しても上手くは行かない。
理由は、アジャイル開発のメトリクスは相対値が多いので、定量的に比較しようがない。
また、アジャイル開発の文化として、メトリクスを自分たちチームの会話に使うので、メトリクスを第三者への説明に使う発想がないし、メトリクスが独り歩きして自分たちの行動を縛るのは嫌う。

akipiiさんはTwitterを使っています 「ストーリーポイントは自分たちのチームの会話に使うものです、と言う回答は思わず膝を叩いた。そう、自分たちのためであり、第三者への品質保証のためではない。 #jasstkansai」 / Twitter

この辺りは、昨今のSaaSみたいに、開発者がソフトウェア開発を行っている行動を自動的にログとして透過的に採取する仕組みを使えばいいと思う。
現代では、ビジネスや人の行動のログは、自動的に採取して、その大量データをAIで分析して活用する仕組みが当たり前だから。

akipiiさんはTwitterを使っています 「メトリクス収集はアジャイル開発で嫌われる問題点はあるが、Webログ採取みたいに、開発者が普通に会社で働いていれば自然に取れるようにすればいい。労働時間、工数は必ず取るし。 #jasstkansai」 / Twitter

【4】アジャイル開発を日本のチームが取り入れたとき、もっと技術系プラクティスを重視すべき、というメッセージは非常に重要と思う。
なぜなら、従来の開発者はテスト駆動開発とか継続的インテグレーションとか、割と使っていないからだ。
特にテスト自動化の技術が疎いように思う。

そして僕自身もこの辺の知識が古くなっていると痛感している。
テスト自動化の技術はここ10年でかなり深化して広がっていると思う。

テスト自動化だけでなく、テスト管理ツールや品質管理ツールも急激に進化して変わっている。
この辺りはもっと調査していく。

TestRailの感想: プログラマの思索


| | コメント (0)

2021/05/22

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

本日の第20回東京Redmine勉強会の感想をメモ。
Redmineを思いもつかない利用シーンで使われる事例ばかりで、久しぶりに刺激を受けた。

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

【オンライン開催】第20回redmine.tokyo勉強会 - connpass

2021/5/22 第20回勉強会 - redmine.tokyo #redmineT - Togetter

【1】@g_maedaさんの講演で、Redmineは細かな機能改善だけでなく、セキュリティ強化にも注力している印象を持った。
たとえば、2要素認証、通知メールのドメインの制限など。
OSSとはいえ、セキュリティホールがあると企業の基幹業務では使えないが、Redmineは世のトレンドの追随して、セキュリティのパッチもいち早く当てて対応しているのは信頼が持てる。

akipiiさんはTwitterを使っています 「二要素認証がVer4.2で機能追加された。Redmineを外部インターネットに公開する時は、このコロナ時代でDX時代では、もう必須の機能ですね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット更新メール通知機能の制限強化。セキュリティ面の強化は、Redmineをエンタープライズ面で利用するために必須。ISMSの観点でも必須。 #redmineT」 / Twitter

また、メール送受信のEndToEndでデータを暗号化通信するMIMEプラグインを使った事例もあった。
つまり、SMTPやPOP3という、今となっては相当古いプロトコルであっても、暗号化通信で機能強化することで、Redmineの通知メールを安全に取り扱うこともできる。

akipiiさんはTwitterを使っています 「Redmineの最新バージョンの2要素認証、メールドメインの制限、に加えて、MIMEプラグインでメールの暗号化でセキュリティ強化に貢献できた、と。 #redmineT」 / Twitter

UIの使いやすさも重要だが、セキュリティ機能の強化でユーザが安全に使える安心感をもたらすことも重要だから。

【2】Backlog x Redmine対談では、プロジェクトマネージャに必要とされる能力や役割が、コロナ時代やリモートワークによって急激に変化した印象を持った。

akipiiさんはTwitterを使っています 「プロジェクトマネジメントという言葉が嫌なのは、元請けSIのマネージャと下請けプログラマの開発者、みたいな役割が固定されてしまう響きがあるから。どうしても契約上の力関係がより強固になり、自発性を生み出さない、心理的安全性を生み出さない雰囲気がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「チケット駆動の開発スタイルでは、マネージャの指示によるマイクロマネジメントは正直やりにくい。細かい作業が膨大になってチケット保守はマネージャ1人では回らないから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「結局、担当者にチケット保守を権限移譲して回す方針でないと、チケットは腐りやすい。マネージャ、開発者の役割は関係なく、チーム一体でチケットを消していくゲームにする。それがチケット駆動開発と思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「MoreEffectiveAgileに出てくる「開発チームをブラックボックスとして扱う」「マネージャはチームのInputとOutputだけを管理して作業の中身はマイクロマネジメントしない」やり方はチケット駆動開発に活かせると思います。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT マネージャも担当者もリーダー経験があると、マネージャはチーム管理が本当にやりやすくなると思います。リーダーの苦労が分かるので、先取りして準備段取りしてくれる。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、データを整備して意思決定しようとする環境を整備しようとしています。エビデンスベースドな意思決定は企業も政府も求められますね。チケット管理ツールはそのデータ基盤を与えてくれると思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「そうそう、門屋さんが言うように「自分がやったことがない技術を使ったシステム開発をマネジメントをする必要がある」。だからPJ管理力に要求される能力は非常に難しくなってきたと思う。特に複数ベンダーに開発委託する案件のマネージャは本当に大変。 #redmineT」 / Twitter

【3】もう一つは、チケット管理に至った結果までの道のりが、各発表者ごとに全く違っていたことも興味深かった。

たとえば、Googleスプレッドシートの情報をRedmineに集約する。
たとえば、チャットや描画ツールでラフな議論をした内容をタスクや課題としてBacklogに落とし込む。
たとえば、工場の現場でExcelのタスク管理をExcelライクなUIにお化粧してRedmineに載せる。
たとえば、全社のワークフローシステムは既にあるが、一つの事業部内の事務処理フローはRedmineに一元化して、全ての申請承認フローを載せた。

たとえば、コロナ感染サイトをRedmineで作った。
たとえば、人や店の地理情報をGoogleMapのAPIを使ってチケット情報に載せた、とか。
たとえば、RPAを使って、テストケースをRedmineに書いて、テストを実行し、テスト結果をExcelに吐き出して、それをチケットに添付して、チケットを更新する一連の作業を自動化する、とか。

とにかくいろんな発想、モチベーションを元に、チケット管理ツールを使いこなそうとしている。

akipiiさんはTwitterを使っています 「#redmineT 今日の勉強会で面白かったのは、Redmineがテーマなのに、Redmineという言葉の同音異義語が多かったこと。工場もあれば、事務の人も使うし、コロナ情報サイトでも使うし、チケット管理に至るまでの道のりも違うのに、参加者同士で話が通じ合うのもすごい。」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、チャットのTypeTalkや描画ツールCaCooなどを使っている。何となくこんなのはどうなの?という話や雑談に近い話はBacklogだけでは吸い上げられない。そこでこんなイメージを絵にしたり、オンライン会議したり、色んなツールを駆使してる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ヌーラボでは、モヤモヤしたテーマや話を見える化した後でBacklogのチケットに書いて、管理しやすくする。門屋さんの場ではGoogleスプレッドで何でも書いてしまうのでRedmineに情報を集約しようとする。チケット管理ツールに行き着く道が違うのが面白いね。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「情報の乱雑度合い、散在度合いを下げるために、チケットに集約してエントロピーを下げようとする。その道程は、アイデア発散→課題に収束のパターンもあれば、あちこちのデータを集約、のパターンもある。#redmineT」 / Twitter

akipiiさんはTwitterを使っています 「全社WFの社内システムはあるが、組織内のWFシステムはないのでExcel管理になってしまう。そこでRedmineで組織内WFを構築して上手くいった。あるある。これいいですね! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「都道府県=PJ、感染者=チケットに割当。Redmineの機能にフィットギャップ分析してる。ViewCustominze、MessageCustomize、Tagsなどのプラグインでチケット一覧の見た目をかなりカスタマイズしている。 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「データを可視化するときに、頭の中でDBが動いてた次元構造化をされたんだろうな・・・めちゃくちゃセンスのよさと頭の良さを感じる・・・DBの知識かなり深い方なんじゃないだろうか・・・ #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「RPAでテストして、テスト結果をExcelに書いて、チケットに添付して、チケットを更新する一連の動作を、RPAで実現した事例。RPAはWindows10でも簡単に使えるので色々試せそう。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Shelperのイメージは、チケットにテストケースを書いたら、チケットの更新時に、RPAがキックされて、シナリオ通りにテストされてテスト結果をExcelに残し、それをチケットに添付する一連の動作が自動化された、わけか。Redmine+RPAでテスト自動化ツールになるイメージかな。 #redmineT」 / Twitter


【4】だから、「なぜ、Redmineを使おうと思ったのか?」という理由を講演者に聞きたくなる。

昌。さんはTwitterを使っています 「#redmineT だからなぜこれをRedmineでやろうと思うのw」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineは、改革者を、何にでも解決できそうなツールに惑わせるのです。理由はないのですw」 / Twitter

y503Unavailable@Redmine Kindle本出版unofficialcookingさんはTwitterを使っています 「@aj15_aj15 そこにRedmineがあるから #redmineT +そこにRedmineTokyo勉強会があるから」 / Twitter


【5】Redmineがもたらす組織面の効果は、はっきりとあると思う。
たとえば、Redmine利用者がシステムの機能やUIに目が肥えてしまい、社内のシステム保守担当者に厳しく要求する場合も増えた、という話もあった。

akipiiさんはTwitterを使っています 「Redmineを利用する事務の社員がシステムを見る目が厳しくなって、他システムへの八つ当たりが大きくなった笑 これは良い副作用?効果?ですね。 #redmineT」 / Twitter

たとえば、工場の現場ではベテランが経験を元にノウハウを伝承するが、若手はツールにすぐに慣れるので、逆に若手からベテランにRedmineの使い方を教え合う、という相互作用が生まれた、とか。

たとえば、Redmineの予実管理の機能を使って、見積もり能力を鍛えることができるよ、というメッセージ、とか。

yukiaさんはTwitterを使っています 「工数の予定と実績の管理をチームがしてる時点で、 そのチームは本当にすげぇと思う。 それがボトムアップ発なら、もう奇跡なんじゃないかとすら思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT 工場などの製造業では、工数管理は非常にシビアなので、予定工数と実績工数の管理は、作業管理と同じくらい重要でした。デメリットは、工数管理の間接作業の工数が割と多すぎて非効率な場面もあることですね。」 / Twitter

【6】グループディスカッションで話をしながら、プロジェクトマネージャに必要な能力は何だろうか?と考えていた。
僕は、一つは見積もり能力、もう一つはリスク対応力、と考えている。

akipiiさんはTwitterを使っています 「見積もりスキルのギプスとしてのRedmine。マネージャの能力の大半は「見積もり」能力と思っている。 #redmineT」 / Twitter

僕の数少ない経験上、プロジェクトマネージャの仕事の大半は計画づくりだ。
実際、PMBOKでもプロジェクト計画フェーズだけで、PMBOK本の半分を占めている。
スクラムやアジャイル開発でも、緻密で精細な計画で確定した計画ではないが、チームの開発の羅針盤としての計画は必ず作る。

その計画づくりに必要な能力は、見積もり力とリスク対応力。
これくらいの作業工数がかかる、これくらいの開発規模になる、という予測がなければ計画は作れない。
もちろん、要件定義前の企画フェーズでは、見積もりの精度は低いが、見積もりに必要な要素を探し出そうとすることで、システムのあるべき姿を描いていく。
最初は見当外れに近い仮説かもしれないが、イテレーションを経るごとに、段々と骨格が定まっていき、あるべき姿は明確化されていくので、見積もり精度も後になるほど高くなる。
アジャイル開発では、検査と適応により、フィードバックを重視するので、ソフトウェア開発にも学習による経験曲線効果を活かすことがきると思う。

また、プロジェクトのリスクがどこにあるのか、をいち早く検知することも大事。
マネージャは船の船頭みたいなもので、プロジェクトは一度動き出すと統制を取るのは難しいが、何とか、前進方向を保とうとする。
岩場にぶつかったり、天候異変で思わぬ方向に行きそうになったり、予測しきれない場面もがあるが、そういう場面をあらかじめリスクとしてイメージできるようにしたい。
リスクを全て洗い出すことは難しいが、リスクを拾っていき、そのリスクを自身で保持するのか、別の人に転嫁するのか、リスクの事後対応策や予防策を準備するのか、をイメージしながら、進めていく。

とはいえ、実際は難しいとは思う。
特に、内製開発チームのように、全てのリソースがマネージャの手の内にあればコントロールしやすいが、ステークホルダーが多く、複数ベンダーに開発を委託している案件であれば、複雑なパズルを解くような感覚になる。

【7】Redmineの面白さは、Redmineというツールがたくさんの可能性を秘めているだけでなく、Redmineを使って問題解決する人たちがこういうコミュニティに集まって議論できること。
コロナ感染サイトのように、Redmineをこんな所に使う発想、なんて誰が予想できただろうか?

実際にサイト運営者の方にお話を聞いたら、すごい悲壮感を持っているわけでもなく、なにか作ってみたかった、という気持ちから実現された、とのこと。
仕事はソフトウェア開発に直接関係しないのです、と謙遜されていたが、PythonのPandasでデータをパースしたり、Python-Remdine APIでRedmineにデータを取り込んだり、5種類以上のプラグインを駆使してUIをカスタマイズしたり、本当にいろんな技術を試されているのは、すごい。

自分が持っているアイデアやモチベーションを元に、即座にアイデアを実現できるツールの一つとして、Redmineがある。
僕自身も改めて、モチベーションをもらった感じ。


| | コメント (0)

2021/04/29

デジタル庁で応募中のアイデンティティアーキテクトは昔のDAと同じ役割か?

デジタル庁でアイデンティティアーキテクト、データアーキテクトを応募しているツイートを見つけたのでメモ。
ラフなメモ書き。

【参考】
yoshi sanさんはTwitterを使っています 「アイデンティティアーキテクトなる独立したポジションがあるんだ。」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクトってなんだよと思ったけどめちゃまともな内容だった」 / Twitter

Yoshikazu NojimaさんはTwitterを使っています 「デジタル庁のアイデンティティアーキテクト、超重要かつ超高難易度な仕事にしか見えないのだけど、どんなキャリアパスを積んで、どれほどの研鑽を積めば担えるのか想像もつかない。 https://t.co/2iU02v4WLr」 / Twitter

akipiiさんはTwitterを使っています 「アイデンティティアーキテクトとは、昔のDAと同じ役割か?」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト https://t.co/raIDjeGhb9 めちゃくちゃ楽しそう(発狂しそうなほど大変だと思うけど)」 / Twitter

ミジンコOLさんはTwitterを使っています 「アイデンティティアーキテクト、あの先輩しか思い浮かばない。 ・行政証明書コンビニ交付サービスの開発経験有 ・某メディア企業の大型サービス利用ID統合経験 ・プラポリにも詳しい ・認証・認可詳しい ・IPA上級資格9割持ってる ・泥臭いPJTの中でも爽やか #デ https://t.co/Ue6JVxsyLh」 / Twitter

【参考】
中途採用|デジタル庁創設に向けた準備サイト

『アイデンティティ管理技術解説』システムアーキテクトを志す方のために IPA

【参考1】
アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
デジタル庁(仮称)においては、行政サービスのデジタル化・ワンストップ化を推進するにあたって、利便性が高く安全な識別・認証の仕組みを構築することにより、多種多様なシステムにまたがった円滑なデータ連携を実現していくことが求められます。

アイデンティティアーキテクトは、各省庁の担当者や専門家と連携して、デジタルガバメントのサービス高度化に必要な、アイデンティティ管理、データ連携の枠組みを構想し、その整備を推進する役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

政府情報システムに関わるアイデンティティ管理の計画策定全般

住民制度、公的個人認証、マイナンバー制度に関わる個人のアイデンティティ管理もしくはGビズID、商業登記電子証明書等に関わる法人等のアイデンティティ管理

行政事務と住民・事業者向けシステム、住民・事業者向けシステム間をつなぐ国のシステムを理解した上での、業務プロセスの見直し、移行計画の立案、変革の推進

国民・事業者向けサービスや各省庁のシステムにおける利便性の高い安全な識別・認証の仕組みづくり

各省庁や地方公共団体の専門家と連携した横断的なプロジェクトの推進
(引用終了)

【参考2】
データアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
データアーキテクトは、デジタル庁(仮称)において、社会全体のデータの現状と将来像を俯瞰し、データ戦略の策定を主導するとともに、標準やルールに加え基礎データ、プラットフォームなどを整備し、その活用を推進していくことが求められます。また、多数のステークホルダーとの調整を進めながら、デジタル時代の新たなスタンダードを構築していくための強いリーダーシップが求められます。

政府は、多量のデータを保有するデータホルダーとして、またデータプラットフォーマーとして、先導的な振る舞いを期待される立場です。本ポジションは、あらゆる社会・経済活動に不可欠なデータを、国の競争力の源泉とするために、また、豊かな生活を実現する上で不可欠な基盤とするために、中心的な役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

体系的なデータ整備に係る中長期戦略・計画の策定

データ標準・データ連携プラットフォームの整備

政府内におけるデータサイエンスやAIの活用の推進

デジタル庁(仮称)内外のデータに関する人材育成

データに基づいたEBPM(Evidence-Based Policy Making、証拠に基づく政策立案)の推進

国際機関や関係各国との交渉
(引用終了)

【感想1】
デジタル庁でアイデンティティアーキテクト、データアーキテクトの募集背景・業務内容を読むと、本当にガチの内容だ。
個人的には、一昔前のデータアーキテクトの業務を連想する。

その頃は、テーブルを新規追加したり、カラム1個を追加するのに、わざわざデータアーキテクトに申請して、内容の詳細や対応期限を説明して、開発環境にやっと反映される、みたいな牧歌的な時代だった。
データアーキテクトは、ER図やデータディクショナリの保守担当者みたいなイメージを持っていたので、あまりカッコイイ職種には感じなかった。

しかし、実際の業務システムの要件定義では、データモデリングの技量の違いがその後の設計、開発の室に直結する。
業務フローのようなプロセスばかり書いても、フワフワしていて、テストでデスマーチになりがち。
データ基盤がしっかりしていれば、そこから業務の制約条件をプログラマも読み取れるし、テストデータを作ったり、保守していくのもかなり楽になる。

さらに、データアーキテクトの職種だけでなく、アイデンティティアーキテクトという職種まで応募しているのはとても興味深い。
単に、公共サービスのデータ基盤、データディクショナリを揃えるだけでなく、その根本となる一意な主キーを見出し、それを維持管理していく重要性を認識しているのだろう。
もちろん、マイナンバー制度という国民をユニークに識別する仕組みにも直結する。
国民を一意に識別してデータを管理できる基盤があれば、今のコロナワクチン予防接種の履歴管理に使えるし、今後のワクチンパスポートの発行にも発展できる。
他にも、収入や資産の追跡、税の徴収だけでなく、本当に困っている人たちを特定して補助金を直接届ける、という仕組みも作れるはず。

また、アイデンティファイアの整備は、認証基盤にも直結する。
政府の膨大な公共システムを利用する場合に、利用者の国民が安全に利用できるだけでなく、バックエンドの事務に携わる公務員や保健所の人たちが安全にログインできて、その操作履歴をきちんと管理できる仕組みも必要。
さらには多種多様な利用権限の制御まで考える必要もあるだろう。

つまり、価値ある公共サービスを提供するためにデータ基盤のアイデンティファイアは必須要件だが、人権やプライバシーの保護の観点からアイデンティファイアの認証・認可・アカウンティングの機能要件も必須という、高度なハードルがある。
想像するだけでも、アイデンティティアーキテクトという職種は非常にタフで難儀な内容であるのは間違いない。

だからこそ、こういう職種が必要ときちんと公開して打ち出しているのは信頼が持てる。

【感想2】
最近はITコミュニティ以外にも、官公庁の関係者がオンライン勉強会で登壇して色々話してくれる場が多くなった。

直近で、農林水産省とウーオが語る!林業・水産業をITで変えるチャレンジ - connpassを聞いた時、今の官公庁で最もデジタル化が進んでいるのは、実は農林水産省なんです、という発言を聞いて驚いた時がある。
その時の事例では、ベンチャー企業が、漁港で取った魚と都市部の魚市場のマッチング処理のシステムを開発して、お互いの利益を向上させる、という話だった。
他にも林業で、日本産の木材が、今はコロナなので実は高く売れている、そういう市場をITの力で支援している、という話もあった。

おそらく、楽天、メルカリのビジネスモデルのように、生産者と消費者のマッチング処理を農業や水産業の市場に適用して、両者がWin-Winになるような方向を目指しているのだろうと思う。
そんな話を聞くと、単に業務システムを開発したり、ITビジネスでお金を儲けるだけでなく、IT技術を社会の問題解決に適用し、多くの人達のために社会貢献する方向に進化しているように感じた。

| | コメント (0)

より以前の記事一覧