コミュニティ

2021/02/25

デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している

今年のデブサミはOLだったので、在宅勤務中でも、ラジオ番組みたいに流していた。
来年度以後もこういうスタイルであって欲しい。
思いつきをラフなメモ書き。

Developers Summit 2021(2021.02.18-19)

(1)動画を見るよりも、講演者の声がハッキリしているか、発言内容にキレがあるか、の方が印象の残り方がまるで違う。
最近、ClobuHouseが流行しているらしいけど、動画よりも音声の方が今後重視される気もする。

(2)沢渡さんのパネルディスカッションは聞いていてとても楽しい。

ファンを3つ作る。
技術のファン、プロダクトのファン、カルチャーのファン。
デベロッパーこそ、ファンを増やし、自己ブランディングしていくべき。

今はデベロッパーのルネサンス。
コロナ感染の現状では、アナログの環境よりもデジタルな対話が当たり前。

そして、先進的なデベロッパーが使っていたツールが当間になった。
Slack+Zoomが一般的。
会社組織ではTeamsになるだろうか。

つまり、対面の対話が今は物理的に難しくなり、OLコミュニケーションが当たり前となった。
OLツールが使えない人は致命的。
誰とも会話できなくなる。

(3)日立の方の講演では、コロナ禍で社内・プライベートのコミュニケーションが全てデジタル化されたことにより、OSS開発者の価値が上がった、とか、コミュニティ活動の経験者がより上手く適応している、みたいな話があった。
社内の根回し、とか、顧客調整が得意であっても、今はTeamsでやり取りするしか無いから、こういうツールに慣れていないと能力を発揮できない。

一方、OSS開発者は以前から世界中の開発者とオンラインでやり取りしてきたので、何も変わらないし、彼らのやり方をSIも既存企業も真似ようとしている。
また、コミュニティ活動の経験者も、こういうツールに慣れている人も多いし、ノウハウを共有する場作りに長けているから、彼らもその能力を発揮しやすい。

今は、コミュニケーションのスタイルが完全に変わってしまった。

(4)コミュニケーションのスタイルがアナログからデジタルに変わった事態により、何が起きるのか?

年を取るほど、大企業の社内の人間関係をベースにした根回しが期待されてくるが、Teamsでしかやり取りできない現状では、全く無意味なスキルになってる。
新人の営業マンが訓練と称されて、100枚の名刺を配って新規顧客をどぶ板で集める手法も、コロナ感染の現状では実現不可能。

オンラインのツールで他人と深く関わるやり方に早く慣れないといけない。
たぶん、多くの人が試行錯誤しながら、OLツール上で初対面の人と会った時、どうやって仲良くなって意思疎通できるようになるか、試しているはず。

(5)緊急事態宣言のもとでは、外食チェーンや居酒屋、個人料理店ですら、大人数で集まって会話することさえ禁止された。
ショッピングモールや百貨店、商店街などに行くことすら、緊急事態宣言のもとでは、ちょっとした罪悪感さえ感じさせられた。

デジタルネイティブ世代がコンシューマになって登場したら、現状のままでいると、おたくの会社の製品は買ってもらえないですよ、と言われているが、まさにそう。

オフラインで、街中でビラ配りしたり、イベントを開いて沢山の人を集める、というプロモーションは今は事実上禁止された。
つまり、今後は、オンラインのプロモーションが重要になるし、O2Oと言われるプロモーション、つまり、オンラインで集客してオフラインの店に来てもらう、というプロモーション手法がより一般的になるだろう。
以前は一部の企業しか試していなかったが、今は大企業だけでなく、中小企業や個人商店ですら、O2Oを実行しなければ生き残れないのだろう。

(6)オフラインからオンラインにコミュニケーションスタイルが激変した事態のもとで、従来の既存ビジネスをいかにIT化で売上を維持、拡大していくべきか、という問題にすり替えた。
この問題こそ、DXというのではないか。

| | コメント (0)

2021/01/14

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない

みんなのPython勉強会#65に初参加してみて、内容がとても良かった。
自分もPythonが理解できるようになったので、その意義がすごく理解できる。
社会変革の鍵はIT技術者にあるのかもしれない、と思った。
結論のないラフなメモ書き。

【参考】
みんなのPython勉強会#65 - connpass

セミナー参加ログ》みんなのPython勉強会#65 2021/1/13(水) 19:00?21:00(オンライン開催) - acokikoy's notes

【1】Pythonのビジネス、データサイエンティストの話、LT、そしてシビテックまで、幅広いテーマでとても興味深かった。
その中で、シビテックの話がとても興味を引いた。

シビテックは、プログラマが市民の立場で、政府や公共機関に出てくる問題をITで解決すること、と理解している。
関さんは、Coder fo japanというOSSコミュニティで活動されている。
東京のコロナ感染のWebサイト構築で一躍有名になった。

都内の最新感染動向 | 東京都 新型コロナウイルス感染症対策サイト

また、台湾のIT大臣のオードリーさんがGithubにプルリクを送ったことでも注目された。

ソフトウェアの政治的影響力とは何だろうか: プログラマの思索

関さんの話によると、日本では、2011年の東日本大震災の時にシビテックに関わるプログラマが増えて注目を浴びたらしい。
さらに、昨今のコロナ感染状況の期間で、関さんのいるSlackメンバーは、約4倍以上の人数に増えた、とのこと。
つまり、社会の危機的状況が、プログラマをシビテックに関与しようというモチベーションを与えているわけだ。

では、なぜそんな状況でプログラマは、シビテックに関わろうとするのか?
理由は色々あるだろう。
たぶん、人間としての生存本能が現れるのではないだろうか。

こういうOSSコミュニティは、IT技術者にとって、とてもメリットがある場だ。
理由は、自分とは違うバックグラウンドを持つ技術者と関係ができて、技術力もアップするし、視野も広がる。
講演では、東京のコロナ感染のWebサイトでは、色盲の人に優しいアクセシビリティを考えるべき、というプルリクもあって、非常に勉強になった、とのこと。

【2】講演後の質疑応答で気になったのは、シビテックが欧米と日本でどのような特徴の違いがあるのか、という話。

関さんによると、欧米人は自分の意見を持って自己主張する。
政府はこういう政策を取るべき、こういう行動を取るべき、とか。
一方、日本人は、自己主張しない代わりに、応援するタイプが多い。
良い政策があれば、それを後押しするように活動する。
言い換えれば、日本人はリーダーシップがなく、受け身の人が多いのだろう。

また、米国では行政府の人はリボルビングドア(回転ドア)なので、OSSコミュニティの人の中に、行政府に所属して働いた経験を持つ人が多い。
すると、行政の事情に詳しいので、行政のニーズをよく知っていたり、行政の人間関係や法律上の壁などの事情をよく知っている。
ゆえに、シビテックではそういう人たちと組むことで、より効果の出せるIT技術による解決策を提示できる。

一方、日本では、OSSコミュニティに行政に関係する人が少ないので、行政と連携しにくい。
プログラマもそういう行政の裏事情を知らないので、連携しづらい面がある。
しかし、東京の副都知事にヤフー経験者の人が入ったおかげで、東京ではシビテックが盛んになってきた、と。

また、行政はITに詳しくないので、ITに詳しい技術者やOSSコミュニティと関わりたいニーズはある。
特に最近は、デジタル庁を設立する話も出たし、農林水産省や経済産業省もIT技術者を募集する広告を見かけるようになってきた。
こういう危機的な状況だからこそ、IT技術者が求められているのだろう。

社会変革の鍵の一つに、IT技術者も含まれている。

【3】そういう講演を聞きながら、今のコロナ感染対策が難しい理由も素人ながら何となく想像できるようになってきた。
その理由は、コロナ感染という問題が影響する範囲が広すぎて、数多くの分野の専門家を集結させて、一貫した方針を打ち出す必要があるのに、どれが正解か分からないので対策を取るのが難しいからだろう。

たとえば、コロナ感染の新規感染者を予測し、政策に合わせてその精度を次々に手早く変更していくには、西浦先生のような疫学の専門家が必要だし、感染などの医療に詳しい医学者が必要。
しかし、彼らだけで問題を解決できるわけではない。

たとえば、ロックダウンにより経済的に困っている人たちへ給付する政策を実行して、人々にどういうインセンティブを持たせれば効果が上がるか、という行動経済学とか、財政出動とその効果を測定するには、マクロ経済学とか、そういう経済学の専門家も必要。
そして、そういう経済政策や医療政策を実行するための正統性を確保するために、新しい法律を整備する法律家も必要。

たとえば、コロナ感染者が増加している状況で、コロナ感染者をスマホで追跡・隔離したり、検査した情報をクラウドの基盤に蓄積したり、刻一刻と変わる情報をWebサイトで収集・公開したり、各人に適切な給付金を配布するための一連の仕組みをWebシステムで構築したりするには、専門のIT技術者が多数必要になる。

つまり、それぞれの分野で一流の人を集めて、彼らを的確にアサインし、振ってくる問題をさばいていくことが求められる。
そういうことを実施する時、トップが全ての分野に精通して理解できるのは難しいだろう。
トップは全ての分野に精通した専門家ではないのだから。

では、そういうチームを編成して、問題を一つずつ解決していくことを成し遂げるには、何が必要なのだろう??
専門家でもないリーダーには、どんなスキルが求められるのだろうか?
どんなリーダーシップを発揮したら、問題となる状況を解決できるのだろうか?

何故ファシリテーションが流行しているのか?: プログラマの思索

| | コメント (0)

2020/12/13

第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する

第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想をラフなメモ書き。
適当なメモ。

あくまでも僕の理解なので、論理が端追っていたり、論理が飛んでいる。

【参考】
モデルベースシステムズエンジニアリングの活用 - connpass

第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 の見所 #seakansai: プログラマの思索

【1】高井さんの2つの講演「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」は共に、SysMLと戦略の観点のマトリクスによるモデルから、形式手法などのツールを駆使して、別のモデルを作り出し、その生成技法をastahのプラグインで実装したというお話。

あまり詳しくなければ、昔流行したMDA(モデル駆動開発)とか、超高速開発のようなツールを連想してしまうが、実際に聞いてみると、こういうものを実装したい時代背景や動機が色濃くあることがよく分かった。

実際、高井さんが、モデリング技法(astahなどのモデリングツール)と各種の技法(形式手法Spinなど)がほどよく洗練されてきたので、使いやすくなった、と言っていた。

たとえば、形式手法のSpinの問題点は2つあるが、問題点を薄めやすいという。
一つは状態爆発しやすいことだが、状態遷移図だけでなく、SysMLでは上流工程の要求モデルや他のモデルの情報をもとに、状態遷移を明確にすることで、状態爆発しない程度までに抑えることができる。
もう一つは、Spinで検査式が難しくて書きにくいことだが、SysMLのダイアグラムに制約条件を書き込んだり、他ツールとのトレーサビリティから情報を集めて、検査式を作りやすい。

つまり、モデルベースエンジニアリングによるモデルには豊富な情報が含まれているので、形式手法のSpinに合うような情報を連携すれば、Spinの弱点を解決でき、Spinのプログラムを自動生成できるようになるわけだ。

【1-1】具体的には、上流工程から下流工程までの各種のモデルを生み出す技法と、形式手法を組み合わせて、モデルそのものの検証が行えること。
つまり、モデルをいくら書いても、そのモデル自体の正しさはそのままでは保証できないが、モデルに描かれた仕様や制約条件を元に、形式手法のプログラムへ自動生成できれば、モデルそのものを検証できる。
さらに、モデルのテストケースもSysMLで書いておけば、テストケースそのものも形式手法プログラムの一つになる。

デモでは、モデルから形式手法プログラムへの自動生成とモデルの検証をastahで行い、モデルの検証結果がOKであれば、astah上のテストケースが緑色、検証結果がNGなら赤色に変わるように反映されていた。

この手法を使えば、astahで描かれたモデルの検証ケースをテストケースで全て書き込んでおいて、継続手インテグレーションで回せば、モデル検証を自動テストできる仕組みが構築できる。
そうすれば、上流工程のモデルを修正したり追加するたびに、自動テストを動かして、モデルの整合性や正しさを保証できるように運用できるはずだ。

本来は、astahのモデルではなく、PlantUMLのように、モデルをソースコードで書くようにできれば、SpinやLTSAのような形式手法プログラムでモデル検証の自動テストがやりやすくなるはずだ。

【1-2】あるいは、具体的には、自動運転の自動車部品のセキュリティ対処の為に、セキュリティの穴をつくような攻撃シナリオや防御シナリオをastahのGSNモデルとして描き、そこから、具体的に設計や実装が可能なシナリオを自動生成すること。
おそらく、astahGSNで、自動車部品のセキュリティのシナリオを論理的に書いておき、そこからパターンごとにシナリオを生成するイメージ、かな、と思った。
すると、シナリオを元に、具体的な仕様モデルや実装モデルを設計できる。

なお、Spinのような形式手法プログラムもコマンドライン・ベースで動くので、astahの画面からキックして、Spinプログラムを実行できたり、ログ出力された実行結果を読み取ることができる。
Spinはもう随分枯れた形式手法だが、プログラムのI/Fはコマンドラインのまま古い点が逆に良い点に作用しているのだろう。

そういう話を聞くと、astahは外部から接続できるAPIが公開できていたり、astahのプラグイン実装が可能な点が有効に活用できているのだろうと思う。

個人的には、PlantUMLのようにUMLやSysMLをソースコードで書いて、SpinやLTSAのような形式手法プログラムを自動生成&自動テストを実行できる仕組みを作っておき、一方で、ソースコードで書かれたモデルはastahのようなビジュアルなモデリングツールにいつでも読み込めるようにする手法が運用しやすいのでは、と思う。
モデルがソースコードに落ちていれば、Gitで構成管理しやすいし、I/Fがコマンドラインで実行できるならば、形式手法以外の技法のツールと連携しやすいからだ。

【2】一番興味深かったのは、とある大学の先生の話。

フォルクスワーゲンは「ソフトウェアファースト」を掲げて製造業からソフトウェア業へ本当に変革しようとしていて、実際、2020年には2000~3000人ものソフトウェア技術者をドイツで募集しており、社員の割合もハード技術者とソフト技術者の割合が半々まで来ているらしい。

一方、トヨタも2020年になって社長自ら「ソフトウェアファースト」を掲げて、ソフトウェア技術者を応募しているが、今までのエンジン技術の成功体験もあって、そこまでソフトウェア重視ではないですね、とのこと。

僕は、DXとは、ITが中核事業でない既存企業がソフトウェアを中核とした事業にシフトすること、と思っているので、日本企業がソフトウェアにまだまだ詳しくないからこそ、DXというバズワードが流行しているんだろうな、とか思った。

つまり、DXとは、従来の事業スタイルのメーカーや小売業が、新興勢力のソフトウェア企業に「代替品の脅威」を感じて、何とか自社でもソフトウェアを前提とした事業を打ち出そうと頑張るためのバズワード、と思っている。

すなわち。「DXとは、ソフトウェアが世界を食う脅威に従来型企業が怯えて対抗しようとしている活動」ではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

ソフトウェアが世界を動かす時代: プログラマの思索

VWがソフトウエア部門を一新、自社開発を大幅に増やす | 日経クロステック(xTECH)

「ソフトウェアファースト」で社会の一部となるクルマづくりへ、トヨタとNTT - MONOist(モノイスト)

【追記】
当日の講演資料が公開されました。



| | コメント (0)

2020/11/19

増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想~日本人はフレームワークが苦手でいつも振り回されている


増刷記念「ここはウォーターフォール市、アジャイル町」-執筆者と編集者と書籍の表側と裏話と- - DevLOVE | DoorkeeperをZoomで聞いていた。
沢渡さんの発言がすごく面白くて、色々連想させられた。
ラフなメモ書き。

【1】日本人はフレームワークがすごく苦手。
ISO9001から、CMMI、DX、SDGsに至るまで、こういうバズワードに振り回されている。
スクラムも良いアジャイル開発のフレームワークだが、日本人はアジャイル開発は理解できるのに、アジャイル開発のフレームワークを使いこなせているとは到底言えない。

その理由は、フレームワークは問題事象を抽象化した枠組みなので、抽象的思考のまま具体的に考えようとして、本来の目的を忘れてしまうのではないだろうか。
本来は、ISO認証が目的ではなく、品質改善が目的のはずなのに、本来の問題意識を忘れてしまい、いつの間にか手段が目的に変わってしまう。

こういうバズワードが会社の提案書に出てきたら、日本では要注意。
書いた本人も、その提案書を受け入れる経営者もたぶん、フレームワークを使いこなせないので、すぐに目的や問題意識を忘れて、道具を磨くことばかりに注力してしまう。

akipiiさんはTwitterを使っています 「#devlove 日本人は、フレームワークと言う道具が使いこなせない弱点がある。ISO認証もSDGsも、フレームワークに使われるだけで、本来の問題解決にならない。フレームワークに呑まれるな!!」 / Twitter

akipiiさんはTwitterを使っています 「#devlove 日本人はフレームワークに使われてしまうのは、手段が目的化する弱点があるせいだほう。ISO認証、CMMU、スクラム、そしてDX、SDGsまで、全て、日本人は振り回されてる。」 / Twitter
「手段を目的化するのは日本人の病」という記事もあったな。

手段を目的化するのは日本人の病: プログラマの思索
スクラムも開発プロセスのフレームワーク。
フレームワークだからこそ、全てのルールを受け入れることで、こんな問題にはこういうルールや道具が使えるのか、という新しい気づきを毎回得ている。それが面白いのだ、という講演者の言葉に惹かれた。

akipiiさんはTwitterを使っています 「#devlove スクラムはやるたびに、すげーと思う。問題解決のたびにスクラムの道具が使える。スクラムのフレームワークを全部入れると、こういう問題で使うのか、と気づきがある」 / Twitter

フレームワークは抽象化した枠組みなので、あらゆる具体的な事象から抽出した本質を確実に捉えている。
一つのアイデアや理論をいろんな観点で徹底的に分析し、そこから、これが本質なのだ、という一つのメッセージを取り出す。
欧米人の自然科学の本、社会科学の本、歴史学の本を読んでいると、こういう分析が上手いなあ、と思う時がある。
膨大な具体例を述べながら、一つのメッセージを一貫して補強するように論理的に組み立てて説明するのが上手い。

論文作成の技法part1~論文の構造: プログラマの思索

【2】アジャイル、という言葉は現場で使わないでいい。
問題解決にアジャイルの技法を駆使して使って解決して、最後に、今までやったのがアジャイルというものなんだよ、といえばいい。
この言葉にはしびれた。
ちょうど、好きな女の子に手取り足取り尽くして支援して、信頼関係を築いて、最後に振り向いてもらって、最後に好きだったんだよ、という感じ。
違うか。

akipiiさんはTwitterを使っています 「#devlove ウォーターフォールの環境ではアジャイルと言う言葉を使わずに問題解決したい。Issue Drivenが基本であり、問題解決の道具が偶然アジャイルであってゴールを達成したとき、今やった事をアジャイルと言うんだよ、と言ってやりたい。よく分かるなあ」 / Twitter

akipiiさんはTwitterを使っています 「#devlove 問題解決で上手くいってテンションが上がってる時に、実はこれがアジャイルなんだよ、と切り出すと効果的。このテクニックは他にも使えそう」 / Twitter

akipiiさんはTwitterを使っています 「執筆では、沢渡さんはスーパープログラマなので、プロセスや方法論も関係ない。アジャイルは、そういう能力のある人を最大限発揮するプロセスと言うオチかな?  #devlove」 / Twitter

【3】問題解決に名前をつけよう。
そうすれば、名前のついた問題に対して、周囲の人達と同じ景色を見ることができる。
その言葉に共感できれば、問題解決のファンを増やしていける。
問題会計角ファンがどんどん増えれば、勇気づけられるし、問題解決できるリソースも選択肢も増えるメリットがある。

akipiiさんはTwitterを使っています 「#devlove 半径五メートル以内の問題課題に名前をつけよう。表現するとイメージできて解決に近づく。そして、問題解決のファンを増やすのが大事。同志になるし、動機付けになるので心強い。うん、コミュニティ誕生やコミュニティ運営も同じだ」 / Twitter

【4】執筆には、まず目次を書こう。
目次が書けるならば、その目次から、ストーリーが思い浮かぶはず。
こんな物語にしたいんだ、という思いが出てくる。
そして、決め台詞を入れたい。

この物語には、このフレーズを使いたい、このメッセージを伝えたい、みたいな。
このフレーズを使いたい、という時は、伝えたい内容にフォーカスしている。
このメッセージを伝えたい、と言う時は、そのメッセージに自分の気持が含まれている。

akipiiさんはTwitterを使っています 「執筆で大事なのは、目次を書く事。目次が書ければ、ストーリーに発展できる。自分の体験や知見をそこに埋め込める。 #devlove」 / Twitter

akipiiさんはTwitterを使っています 「目次は先に書くが、このフレーズは使いたい、このメッセージは伝えたい、と言う言葉は事前にメモして、目次に入れ込んでおく。このやり方は真似よう #devlove」 / Twitter

akipiiさんはTwitterを使っています 「#devlove システム運用で誰も読まなかったマニュアルを、ダイアローグ形式にしたら、すぐに広まった経験がある。そういう形式に変えるやり方は面白いな。FAQ方式みたいにするのか」 / Twitter

【5】チケット駆動のいい所は、一体感が出くること。
チケットをキャッチボールみたいにやり取りするうちに、相手はどんな反応をしてくるのか、待つようになってくる。

akipiiさんはTwitterを使っています 「#devlove チケットでやり取りすると一体感が出てくるよね、と。なるほど。」 / Twitter
一体感が出てくるとは、組織論の言葉では、バーナードの組織成立の3要件である「組織の共通目的」が誕生していることだ。
つまり、そこには、単なる人という物体の集まりではなく、心理的関係を持つ組織集団が暗黙的に生まれたわけだ。


<br

| | コメント (0)

2020/11/14

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

第19回東京Redmine勉強会に久しぶりに出て楽しかった。
ラフなメモ書き。

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

2020/11/14 第19回勉強会 - redmine.tokyo #redmineT - Togetter

フルリモート開催2回めのredmine.tokyo 日々の悩みと笑いと感動あり #redmineT | マドびっ! Madosan's View

【1】@g_maedaさんのRedMicaの講演では、細やかな機能改善の紹介があった。
Wikiにテーブル挿入ボタン、Ctrol+Enterでフォームサブミット、ユーザマスタCSVインポート機能など。

akipiiさんはTwitterを使っています 「#redmineT 2要素認証の機能追加に伴い、ユーザリストCSVの項目追加、メール送信のドメイン制御などセキュリティ面の配慮がなされている。」 / Twitter

セキュリティ面の機能強化に意識されているのはいいね。

【2】2本のパネルディスカッションは面白かった。
各パネラーの体験談を元にした失敗談、成功談をショートストーリーで紹介し、それを他のパネラーが突っ込む。
そういう意見が出るのか、脱線した話もあっていい感じ。

【2-1】話を聞いていると、ツールでプロセスを実装するか、目的のあるプロセスをツールにフィットさせて実装するか、という議論がごちゃ混ぜで面白い。
@saitoさんと話ししていると、やっぱり僕も、やりたいプロセスが既にイメージできていて、そのプロセスをツールに当てはめて、ツールの設計思想に上手く組み込む感じ。
一方、ツールを使いながら、ああ、こういう機能はこういう時に使うのか、こういう時に役立つのか、と気づく時もある。
しかし、最初はスモールスタートで運用し始めていくと上手く行っても、他チームが相乗りしてどんどんRedmineが複雑化してコントロールしにくくなる話もあったな。

(1) akipiiさんはTwitterを使っています 「Redmineの話ではなく、社内のプロセス改善の話になってる。ツールにプロセスを乗せるか、プロセスにツールを合わせるか、どちらも混じって面白い。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT ユーザディスカッションは、@saito0119 さんと2人で盛り上がる。Redmine の思想は分かって欲しい。トラッカーはチケット種別ではなく、ワークフロー管理が基本、は同意見。プロセスありきで設計しないと後で混乱するから。」 / Twitter

齋藤さんはTwitterを使っています 「@akipii プログラマって、アプリに納得できるかどうかは、設計思想で決まると思ってます。redmine の設計思想が理解できると、後は簡単な気がする。 #redmineT」 / Twitter

【2-2】心理的安全性のテーマはよく出る。
チケット駆動では、メンバーが自発的に登録して、タスクを他人に振って、自分でクローズする運用でないと効果的にならない。
しかし、日本の現場では、派遣契約や外部委託などの契約のために、上からの指示になり、変な忖度をしがち。
おそらく、心理的安全性が日本で盛り上がるのは、上意下達の組織に慣れすぎてしまって、自分からリーダーシップを発揮する訓練が不足しているのだろうと思う。

【2-3】TeamsとRedmineの話も個人的にはとてもヒットした。
GSuiteからTeamsに変わって、とても便利。
Teamsでチャットもできて、TV会議もできて、Googleドライブみたいにファイル管理できるし、Plannerでちょっとしたカンバンもあるし、SharepointでWikiみたいに使えるし、何でもできる。
すると、チーム内のコミュニケーションは全てTeamsでカバーできる。
しかし、課題管理やタスク管理はTeamsでは辛いので、Redmineを使いたくなる。

akipiiさんはTwitterを使っています 「#redmineT Teamsを使ってると、簡単なカンバンはPlanner、テレビ会議も2人だけのチャネルもあり。ExcelファイルやOneNoteもTeamsでGoogle ドライブみたいに共有できるし、Sharepointにもアクセスできて、確かに便利。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT ただし、課題や日々のタスクはTeamsでは管理しにくい。当たり前だがRedmine の方が一括管理できて、履歴が残るので、やりやすい。他事例で、TeamsのPlannerとRedmine チケットをリンクさせてストーリーカードとタスクカードで運用してる話もあった」 / Twitter

チャットを使うことで、Redmineのチケットのコメントがきれいになった、というメリットは同意する。
コメントは掲示板みたいな機能かなと思うが、もっとリアルタイムに速くやり取りしたい時に、チケットのコメントは遅い気がする。

akipiiさんはTwitterを使っています 「これをメリットと思うかデメリットと思うか。コメントは掲示板みたいな機能だった。RT @juno_nishizaki: チャットが使えるようになってからチケットの注記に書くにはノイジーだなって思うような会話をチャットに移せるようになったのでチケットがスッキリするようになったかと感じています #redmineT」 / Twitter

Teamsでこれだけコミュニケーションができると、正直、メールは仕方ないから使っているだけ。
メールはFaxと同じレベル。いい意味でも悪い意味でも。

akipiiさんはTwitterを使っています 「“@saito0119 さん曰く、メールは仕方ないから使ってますよね。メールはFAXと同じですね。本当に同感。 #redmineT」 / Twitter

【2-4】@satioさんと話していて面白かったのは、リモートワークになって、新人や若手が苦労しているね、という話。
オフラインでOJTができないので、初めての設計、レビュー、プログラミングのデバッグなどがやりにくいらしい。
すると、困ったことを誰にも話せず、自分一人で困っていて、何も成果を出せない結果になりがち。
だから、頻繁なコミュニケーションを取りながら、逐一フォローできる仕組みや環境が必要みたい。
つまり、経験者だけでなく新人ですら、成果主義が求められている。
僕は会社から教育された経験がないので、自分一人で勉強してスキルを身に着けていくべきでは?と思っている。

akipiiさんはTwitterを使っています 「リモートワークでRedmineでタスク管理を強制導入しでて、リーダーは馴染めなくていつの間にか異動で消えた、なんてリアルすぎる笑。   #redmineT」 / Twitter

【2-5】Redmineでは、通知メールよりも活動タブをもっと使うべきだ、という意見は、ツイートでも賛成意見が多かった。
詳細が知りたいのではなく、PJの活発度合いを見たいのだ。

(1) akipiiさんはTwitterを使っています 「#redmineT 活動タブでなく、活躍!タブか?」 / Twitter

一方、PMOは特定の複数PJを全部見たい時があるが、活動タブでも親PJで全てのPJの活動履歴を見るしかない、みたいな意見もあった。
この辺りは、活動タブのフィルタリング機能だけでなく、プロジェクト階層構造など色々工夫が必要な感じ。

akipiiさんはTwitterを使っています 「活動タブが通知メールよりいいね、と議論が活発。ただし複数プロジェクト全般で見る管理者は、こまる時があった。特定プロジェクトだけ見る時は良かった。 #redmineT」 / Twitter

【2-6】また、ガントチャートのWBSチケットとチケット駆動のチケットは粒度が違うので、いつもミスマッチが発生してトラブルが起きる。

あいちゃん2号の代理人さんはTwitterを使っています 「だけど、 ガントチャートを描くのって、 結構難しいと思う。 いかに仕事の全体像と、 チーム力が試される。 #redmineT #redmine」 / Twitter

akipiiさんはTwitterを使っています 「#redminet ガントチャートのタスクの粒度と、チケット駆動のチケットの粒度はミスマッチな点に問題があると思います。ガントチャートは荒すぎて、毎日見ても、進捗が進んでないように見えてイライラする」 / Twitter

【2-7】RedmineのUIが機能改善されるのを見ていると、メンバーがもっと楽しく使えるような機能が欲しいと思ってくる。
どうしても、Redmineは管理ツールなので、管理者の観点で使ってしまいがち。
しかし、本来は、メンバーが自由に自分たちのために使って欲しい。
そういう時に、感謝の気持ちや同意する気持ちを簡単に表明できる機能が欲しい。

FacebookやTwitterはそういう機能が上手だし、Teamsでも、いいねアイコンが6個ぐらい追加されて、微妙なニュアンスが表現できるようになった。
ちょっとした機能に過ぎないだろうが、メンバーの貢献意欲を引き出し、PJのゴールに向けて一致団結していく雰囲気を醸し出す機能が欲しいのだ。

akipiiさんはTwitterを使っています 「#redmineT Redmine にメンバーの意欲を盛り上げる機能が欲しい。いいねボタン、GoodJobボタン、GitHubの草、とか、もっとあるはず。大した機能でないけど、楽しく運用したい」 / Twitter

【3】LTも個性的な講演ばかり。

Planioはカンバン機能もあるのは知っていたが、サポート用メルアドが既にあり、サポートデスクの機能は便利だな、と思った。

akipiiさんはTwitterを使っています 「#redmineT planioのサポートデスク機能は、メールによるチケット登録機能を使ってるわけか。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT planioでタスク管理、作業時間管理、サポートデスク、リポジトリなどを使って、便利に使ってる。確か、アジャイルのタスクカンバンもありましたね」 / Twitter

しんやさんのLTは、アンチパターンのお話。
2017年にリツイートした人だったのですね。
最後は退職をチケットに書いた、というオチ。
誰が承認するの、完了にするの、却下できるの?みたいな議論があった笑。

akipiiさんはTwitterを使っています 「面白すぎる。RT @NAGAYASU_Shinya: Redmineにて塩漬けチケットがしぬほどある部署にいたとき、ついカッとなってここ1ヶ月更新のないチケットを一気に却下にしたったことある ……すごい怒られた、そして別に業務になんの支障もなかった。」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT アンチパターン。全員チケット全員ウォッチャー。通知メールが数千件?も届く!怖い」 / Twitter

JAXA木元さんのLTでは、親子チケットのアンチパターンの話があった。
確かに、親子チケットが使える場面は、WBSのようにあまり変化しないケースの方が向いている。
ツリー構造よりも、関連チケットで表現したい時が多くなる。

akipiiさんはTwitterを使っています 「JAXA木元さんの話。親子チケットでこうぞを見える化したいブームがあったが合わなかった。WBSのようにキッチリしたケースは良いが、課題管理のように関連チケットや親子チケットが混じるとエラーが出てフラストレーションが溜まる。 #redmineT」 / Twitter

Nishizakiさんが、Redmineの設計情報をまとめたいという心意気は同意する。
Redmineの設計思想は僕はとても優れていると思う。
オープンソースで10年以上も存続できて、RubyやRailsの激しいVerUpに耐えながら品質を保ってきたのはすごいと思う。
しかし、外部接続のAPI一覧やデータベースの知見などがもっと欲しい。
そういう設計思想を手動でWikiで集めるのも良いし、SwagarAPIみたいに、APIの仕様書とテスト環境を一緒に作ってしまう、とか、色々やり方があるので実現できるといいなと思う。

奈良さんの話では、複数のRedmineサーバーを建てる場合、マスターのRedmineサーバーにあるユーザ・グループなどの基本マスタをセカンダリーの他Redmineサーバーに同期させるやり方を紹介していた。
今はPoC段階です、と言っていたが、このやり方であれば、LDAPのユーザ情報だけ管理できれば、PJ等のその他のマスタは各Redmineインスタンスで自由に使ってもらえれば良い。

akipiiさんはTwitterを使っています 「#redmineT Redmine サーバーのマスターのユーザ、グループなどをセカンダリーのRedmine サーバーに同期させる運用のお話し。確かにこれなら、複数インスタンス管理は楽になりそう」 / Twitter

【4】Redmine勉強会のスタッフとして10年関わっているが、Redmineの面白さを改めて痛感した。
Redmineの面白さは、PJ管理や開発プロセスの実装というソフトウェア工学の観点、そして、Redmineの複数インスタンス制御とかRedmineのデータベース設計などのPJ管理ツールの開発基盤の観点の2つが議論できること。

だから、PJ管理などのマネジメントの話ばかりしていると飽きてしまうけど、飽きたら、Railsやデータベース設計、インフラ構築などの技術の話に行ってもいい。

僕のイメージでは、ソフトウェア工学の話をしている時はサイエンティスト、開発基板の話をしている時はエンジニアの気持ちになっている。
サイエンティストはあるべき姿の理想を延々と話すが現実は違うし、その理想を実装すると、性悪説に基づくPJ管理ツールになってしまう。
一方、エンジニアは、あるべき姿の理想を仕様に落とした時、現在の技術の範疇でどこまで実装できるか、技術や品質・コスト・納期のトレードオフを考えて、現実的な解を出す。
自分の中に2つの人格があって、心の中でお互いに議論しあって、衝突した結果、全く別のアイデアが生まれたりするのが楽しい。


| | コメント (0)

2020/11/11

「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた #devlove #静岡ギルド

今夜行われた「製造業アジャイル、静岡での実践!」を聞いてRedmineはコミュニケーション管理ツールなのだと気づいた。
ラフなメモ書き。

【参考】
静岡ギルド(準備中)勉強会「製造業アジャイル、静岡での実践!」 - DevLOVE | Doorkeeper

詳細は上記ページの通り。
1回目は、POもSMも開発チームもScrumの初心者だった。
やる気はあったが、やはり色んなトラブルが出て、POや開発チームのコミュニケーションも悪くなり、進捗遅延で増員されるたびに開発案件がどんどん膨らんでしまう。
最後に、SMの役割を果たせず、案件から抜けてしまう。

再起を期した2回目はいろんな工夫をした。
その話を聞くと、ポイントは2つあると思う。
それは、組織構造と組織文化の2つ。

組織構造の面では、POを2人体制にしたり、開発チームに進捗報告担当のトラッカーを立てたり、SMも時には開発に入ったり課題管理に直接関わったりしたこと。
Scrumの本来の姿ではないかもしれないが、各人の役割と責任に対し、権限と責任が一致できていないならば、補佐を立てて強化したり、あるいは自ら作業に加わったりする。
目的は、Scrumを運用することではなく、開発案件を成功させることなのだから。

組織文化の面では、TeamsでPOと開発者が頻繁にコミュニケーションする。
コメントに、いいねやハートのアイコンをつけることで、ちょっとしたニュアンスを伝えられた。
TeamsのPlannerでPBIを書いて5つのステータス(ToDo、Ready、Doing、Reviewing、Done)でかんばん風に管理したり、TeamsのPlannerで書き足りない内容はRedmineのチケットに詳しい仕様や課題を管理し、Sprint計画はRedmine上でロードマップ画面を使った。
スプリントレビューのデモでは、Teamsのカメラ機能を使って、実際にスマホアプリの動作をステークホルダーに見せて、その場でフィードバックをもらえた。

最初は、TeamsのPlannerでストーリーカードをかんばん風に管理して、詳細化したタスクカードをRedmineのチケット管理で実現したと思っていたが、TeamsのPlannerにはたくさんの情報を書き込みできないなどの不便があったので、Plannerはステータス管理に注力し、Redmineチケットのリンクを書いておいて、課題や状況の管理はRedmineで行っていたらしい。
後で、Redmineのチケットパネルプラグインを入れたら、親チケットはチケットパネル機能でかんばんで管理し、詳細なタスク管理は子チケットで管理するといいのでは、と提案してみた。

そんな話を聞くと、RedmineやTeamsはコミュニケーション管理ツールなのだと感じた。
ガチガチの進捗管理をツールで実現するのはすぐに可能だが、実際はそう簡単には回らない。
一方で、チーム内のコミュニケーションを活性化するには、POやメンバー同士の信頼関係が前提条件だ。
そのために、デイリースクラムではSMはメンバーに進捗遅延を責めることはしないし、POは開発メンバーに見積もりが多すぎるのではとあえて口を挟む権限を付与したりする。
つまり、お互いに本音で言い合える関係をツールで実現することが重要だと感じた。

もちろん、ツールさえあれば開発案件が成功するわけではない。
自分の経験を振り返ってみると、結局は、ソフトウェア開発案件は開発者とリーダーの能力にすごく依存する。
開発者とリーダーの能力を最大限に発揮するには、プロジェクトの体制図という組織構造で権限と責任を明確にし、権限と責任を一致させて、各メンバーの意思決定を迅速させることが重要だし、メンバー全員が最終ゴールを認識していて、その実現のために目標達成意欲を高揚させる雰囲気作りが大事だ。
そして、コミュニケーションを円滑に進める基盤として、RedmineやTeamsのようなツールがあるわけだ。

組織構造を整える部分は、プロジェクトの体制図を決める時に決まるから、おそらくプロジェクトの立ち上げ時に既に決まっている。
組織文化を整備する部分も、RedmineやTeamsを事前に整備しておく必要があるから、プロジェクトの立ち上げ時に既に決まっている。
そんなことを考えていると、Scrum云々というよりも、プロジェクトマネジメントという基盤の考え方が使えるのかな、と思ったりもした。


| | コメント (0)

2020/11/05

第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 の見所 #seakansai

2020/12/12土の夕方に、SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」が開催されます。

私も関わっているastah関西コミュニティの高井さんをお招きして、SEA関西にて「モデルベースシステムズエンジニアリングの活用」の講演2本が実現しました。

特に、自動車業界などで組込みソフトウェア開発を担当している技術者やアーキテクトに対し、上流工程におけるモデリング技法並びにモデリングツールを活用した設計技法のお話は参考になると思います。
興味のある方はぜひご参加ください!

講演の見所を少しだけメモ。

【申し込み】
第73回 SEA関西プロセス分科会 「モデルベースシステムズエンジニアリングの活用」 | Peatix

(引用開始・一部入れ替え)
開催日時: 2020年12月12日(土)16:00~18:00

開催形式: オンライン(ZOOM)

講師: 高井 利憲 氏(株式会社チェンジビジョン)

講演1:モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用
 最近のシステム開発では上流工程での検証の必要性が高まっています。
 本講演では、モデルに基づくシステムズエンジニアリングアプローチと形式手法を組み合わせて活用する方法について、自動車分野のシステム開発を例に、ツールによる支援可能性を中心に議論します。

講演2:モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用
 最近のシステム開発においては、シナリオベースの検証や妥当性確認を求められることが多くなってきています。
 本講演では、自動運転車の安全規格の一つであるISO21448(SOTIF)や同じく自動車分野のセキュリティ規格であるISO21434(車両サイバーセキュリティ)を例に、システムズエンジニアリングにおける効果的な実施方法を紹介します。
 講演1と同じ例題モデルを用いることにより、モデルの再利用可能性についても議論します。

本講演1及び2は名古屋大学倉地亮先生とdSpace藤倉俊幸様との共同研究の結果に基づいています。

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

プログラム:
 15:30 アクセス受付開始
 16:00 講演1「モデルベースシステムズエンジニアリングにおける形式手法の効果的な活用」
 16:30 質疑応答
 16:45 講演2「モデルベースシステムズエンジニアリングにおけるシナリオ生成手法の効果的な活用」
 17:15 質疑応答・フリーディスカッション
 18:00 閉会

 閉会後、オンラインでの懇親会を持ちたいと思います。
 お時間の許す方は、お好きな飲み物をご用意の上、お気軽にご参加ください。

定員:
 100名
 お申し込み順です.定員になり次第受け付けを締め切ります.

(引用終了)

実は、過去に高井さんの講演や資料を見聞きして、刺激を受けた部分がたくさんある。
一つは、モデリングツールを経由して、開発プロセスと成果物のトレーサビリティを保証する仕組みを作り出すお話は面白かった。

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

ソフトウェア開発に置いて、開発プロセスが重要な理由は、単に手順を標準化して、作業の効率化を図るだけではない。
作業と成果物の間でトレーサビリティを保証することで、プロダクト品質とプロセス品質の両方を保証することだ。
例えば、ソースにバグがあれば、過去の変更履歴からどこでバグが埋め込まれたのか、どんな変更理由や要件の変更があったのか、を探れる。
あるいは、たった一つの仕様変更がどれだけの範囲のソースに影響を及ぼすのか、ということも追跡できるはず。
つまり、作業と成果物のトレーサビリティは、ソフトウェア構成管理に直結する。
ソフトウェア開発では、ソフトウェアの構成管理こそが、開発プロセスの本質ではないか、と思う。
そういう仕組みの実現に、実はastahというモデリングツールが一役買っている、という話が興味深かった。

2つ目は、SysMLというモデリング言語が、組込みソフトウェア開発において、メーカーのプロダクトオーナー、ハードウェア技術者、ソフトウェア技術者、自然科学者の間で、共通のコミュニケーション言語になっている、という講演も面白かった。

第2回astah関西の感想 #astahkansai: プログラマの思索

特に、組込みソフトウェア開発では、ハードウェア技術者が設計したハード機器に対して合うようなソフトウェアを開発するために、ソフトウェア技術者はどうしても弱い立場になりやすい。
そして、ハードの仕様変更や要件の理解不足などで、どうしてもソフトウェアの品質を担保するのは難しい。
その真因には、ハード技術者とソフト技術者の間で、コミュニケーションが不足しているから、ということがあるだろう、と思う。
ハード技術者にも理解してもらうために、UMLではなく、ハードの構造も表現できるSysMLを使うことで、ハード技術者とソフト技術者がSySMLという共通言語で会話できるようになった。
さらに、製品を市場にフィットさせる責任を持つプロダクトオーナーや、ハードに電気・流体・機械などの自然科学の制約を与えるドメインまで、すべての話をSysMLで会話できる。

多様なドメインを持つ製品開発では、こういう人工的なモデリング言語があるからこそ、ソフトウェアも含むハードを開発できるという点が面白い。
つまり、モデリング言語が我々の思考そのものを規定し、効率化させる部分があるわけだ。

今回の講演1本目は、モデルに基づくシステムズエンジニアリングと形式手法を組み合わせて検証する時に、astahというモデリングツールを使った事例を紹介してくれる。
モデリングツールによる検証方法の実装がどれだけ実現性があるのか、興味がある。

講演2本目は、自動運転車の安全規格などについて、システムズエンジニアリングにおける効果的な実施方法の事例を紹介してくれる。
自動車業界は今、ガソリンエンジンから電気自動車に大きく変更しつつある時代なので、こういう機能安全規格をいかにモデリング技法で実現するか、は、色んな観点で興味を引くはず。

最近、「モデルに基づくシステムズエンジニアリング」も読んでとても面白かったので、感想はまた今度書く。


| | コメント (1)

2020/09/18

RedmineJapan2020が無事に終わりました #RedmineJapan

本日、RedmineJapan2020が無事に終わりました。
講演者と参加者の皆さん、スタッフの皆さん、ありがとうございました。
今日は本当に疲れたので、まずはメモしておく。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

今日は朝9時から19時半まで、自宅の机とPCに張り付いて、気づいたら外は真っ暗。
基調講演から最後まで、どの講演も素晴らしくて、興味を引いて、気が抜けなかった。

Matzさんの話は、Rubyのリモート開発と、開発をリードする立場の事情話。
自分の意見と自分が書いたソースコードは違う。
エゴレス。

みうら(あに)さんはTwitterを使っています 「(自分思い出し用)1) OSS→コミュニティベース開発→PdM:「よい」とは?⇒同じ方向見れるか?⇒求心力/哲学 2) ツールの支援:円滑な意思決定⇒分散SCMのよさ⇒Issueベース⇒フロー/ストック⇒Wikiの使い方 3) コンフリクト解決:コードより知見大事、エゴレス、ゆるやかにつながる #RedmineJapan」 / Twitter

東芝やNTTコムウェアの開発プロセス標準とRedmineをベースとした開発基盤の紹介。
大企業の内部事情が分かった感じ。

@akiko_pusuさんのLTは、朗読のようなナレーションで聞き入ってしまって、聴衆の皆さんも思わず泣きたくなったのではないか。

平鍋さんの話は、リモート時代でのアジャイル開発のコミュニケーションの取り方。

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんが最初に作ったastahも、平鍋さんが書いたソースコードはもうない。インターフェイスだけ残っている。そういう意味では、設計思想が優れていた、ということなんでしょうね。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんは工学部出身だから、場と言えば、電磁気学や量子力学を連想されたのかな?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 古典力学はコマンドコントロール。場の理論は、チームの空間から力が生まれる。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ティール組織は場がない。スクラムは場がある」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan リモートワークの場作り。リモートワークの基本の最初は、速いインターネット回線」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan デジタルでは表現者が優位。過剰な表現で十分」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ネットワークの7層モデルと、コミュニケーションモデルの比較。物理層は、信頼関係に対応するのでは、という仮説」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan タックマンモデルも、最初の混乱期までは合宿して、それからリモートに移行する。でも、コロナ時代はどうする?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan これからのチームビルディングは、合宿無しの継続的なチームビルディングへ。」 / Twitter

(1) kabukawaさんはTwitterを使っています 「#RedmineJapanA いまここ性 here-now-ness」 / Twitter

リモートワークの時代では、チームビルディングの手法はオフラインとは変わってくる。
五感のうち、見る・聞くしかチャネルがない。
だから、自己表現を派手にするぐらいでないと伝わらない。

すると、チームビルディングでは、タックマンモデルの形成期・混乱期がリモートワークでは難しくなる。
いかにそういう場をオンライン上で実現するか?

パターン言語を用いて、アジャイル開発の秘密基地のパターンを作っていた。
同様に、リモートワークのアジャイル開発のパターンが作れないか?
そのパターン言語を作ることで、リモート時代の特徴や本質が見えてこないか?

同時並行で見れなかったB会場では、RedmineのDBアーキテクチャの説明、RedmineのDockerのお話、ファーエンドさんのAWSでRedmineサービスを作った裏話、なども聞きたかった。
動画を準備しているので、ゆっくり見てみたい。

Redmineというテーマで、オンライン参加者が300人もいるイベントを実現できて本当に良かった。
Redmineは、開発プロセスの構築とそれを支えるPJ管理ツールの話と、実際にPJ管理ツールの開発基盤を構築するためのインフラ環境やRedmine本体の改善の話を同時に議論できて面白い。
そういう話をコミュニティで10年も継続できたことがすごいな、と思う。

| | コメント (0)

2020/09/13

RedmineJapan2020の見所 #RedmineJapan

9/18金に予定するRedmineJapan2020の見所について、スタッフの一人としてメモ。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

RedmineJapan2020の見所は3つある。

一つ目は、Redmineに関する日本最大のイベントになったこと。
発端は、@agilekawabataさんの発起により、Redmineに関するイベントを開催しよう、という話。
そこから、いつの間にか、参加者500名を超える大規模なイベントになった。
大阪や東京のRedmineコミュニティでも、50~100人前後がせいぜいなので、参加者だけでも、オンラインとはいえ、経験したことのない規模になった。
それだけ、Redmineに興味のある日本人が実は一定の層だけいることを示しているのだろう。

2つ目は、多種多様なスピーカーによる講演が目玉であること。
Redmineをテーマにするので、講演の数が集まるか、スタッフとしては不安だった。
しかし、蓋を開けてみれば、あっという間に応募枠は埋まったので、とても嬉しい。
理由を推測すると、大阪と東京のRedmineコミュニティが10年以上も継続的に存続してきたので、熱心なユーザが常に存在していたのだろうと思う。
また、ソフトウェア開発のプロジェクト管理だけでなく、製造業の業務部門や情報システム部門で、当初想定されていなかった使い方をする事例も増えてきたこともあるだろう。

RubyのパパであるMatzさんや、日本のアジャイル開発の第1人者である平鍋さんの基調講演が聞けるのも楽しみ。
そして、そういう日本のIT業界を代表する人たちと、僕も講演者としてタイムテーブルにプロフィール公開されているのも、ちょっぴり嬉しい。

講演内容は、A会場はPJ管理系・事例系、B会場は技術系・ツール系に分けた2トラックになる。
タイムテーブルを見ての通り、正直どちらの講演も聞きたいぐらいだ。
そんな声も踏まえて、後日、参加者には聞けなかった講演を動画で視聴できるようにしたい準備も進めている。

3つ目は、今後のRedmineの発展に貢献したいこと。
コロナ感染騒動でオフラインの開催自体も怪しくなったが、オンライン開催できる運びとなった。

実は、コロナ感染騒動がなければ、フランスのJPLさんもお呼びする予定だった。
しかし、コロナ感染騒動のため沙汰止みとなった。
周知の通り、Redmine本家の開発体制はJPLさん、@g_maedaさん、@matsuorijpさんの3人だけだ。
競合となるJiraやBacklogに比べれば、非常にリソースが薄い開発体制である弱みはある。
だからこそ、ユーザによるこういうイベントやコミュニティの盛り上がりで、オープンソースであるRedmineが今後も永続的になっていけるように支援できれば、とスタッフの1人として思っている。

まだ、当日まで参加可能なので、是非応募してみてください。

最後に、注意点を1つだけ。
RedmineJapan2020のオンライン配信は、Remoというツールを使う。
ほとんどの人が使ったことがないはずなので、下記のガイドは必ず読み込んでおいて下さい。
RemoはZoomとは全く違って、仮想的なイベント会場を用意している。

日本コミュニティでの活用 - Remo.co Virtual Events and Office space

Remo参加者用ガイド

当日までに、Remoにアカウントを作って事前にログインして動作確認することをお勧めします。
ちなみにRemoの環境は、PCのChrome、Firefoxが推奨です。
iPhoneなどのスマホでは、ブラウザ表示がベータ版になっています。


当日はスタッフは公演準備に忙しいのでフォローできない可能性が高い為です。

では、皆さんのお越しをお待ちしてます。

| | コメント (0)

2020/07/07

ソフトウェアの政治的影響力とは何だろうか

今年になって、台湾の天才IT大臣の記事をチラホラ見かける。
ソフトウェアの政治的影響力を上手に使いこなしているな、と感じたのでメモ。
ラフなメモ書き。

【参考1】
「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

(2) akipiiさんはTwitterを使っています 「時代の変化は速いよね。「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に https://t.co/drVTKoZz74」 / Twitter

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (1/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (2/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (3/4) 〈dot.〉|AERA dot. (アエラドット)

(引用開始)
タン氏にインタビューした経験がある前出の近藤さんは、こう話す。
「両親の職業がジャーナリストということもあり、彼女は『情報』が人々にどのような影響を与えるかをとても理解しています。
また、現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている。
入閣した時に『公僕の中の公僕になる』と宣言したとおり、特定団体の利益のために動くのではなく、テクノロジーを駆使して台湾の人々と行政院をつなぐ“パイプ”になっています」
(引用終了)

akipiiさんはTwitterを使っています 「ITによる可視化で政治的対立を消化させる道具にする発想が素晴らしいと思った。Redmineにも通じる。「むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」新型コロナ“神対応”連発で支持率爆上げの台湾IQ180の38歳天才大臣の対策に世界が注目 AERA dot. https://t.co/GORTP5vWb4」 / Twitter

【参考2】
台湾の天才IT担当大臣オードリー・タンに訊く、新型コロナウイルスの先にある未来の国家とは - Engadget 日本版

akipiiさんはTwitterを使っています 「ソフトウェアの政治力を良く知り尽くして活躍されてる事例。参考になる。” 台湾の天才IT担当大臣オードリー・タンに訊く https://t.co/zxSe7tNwVZ」 / Twitter

こーじさんはTwitterを使っています 「>その一方でパニック買いなど、噂による行動は防ぐ必要があります。そこに対しては、インフォデミック(≒情報の氾濫)より面白いユーモアを発信するという対策に取り組みました。 これ凄い面白い取り組みだな」 / Twitter

akipiiさんはTwitterを使っています 「@saba1024 台湾のIT担当大臣は、人々がシステムやSNSを使うと、どんな行動に走るのか、それを遠くまで見通して意思決定している点が凄いです。ソフトウェアの開発力だけでなく、その政治的影響力、行動経済学の知見、社会心理学の知見を知り尽くしてる、そんな気がします」 / Twitter

こーじさんはTwitterを使っています 「@akipii まさに仰るとおりですね! 時代が人を作るのか、人が時代を作るのかというのはよく言われる話題では有りますが、この方は間違いなくこの時代に必要とされる方ですね。」 / Twitter

台湾の天才IT担当大臣の振る舞いをツイッター上で眺める限り、ソフトウェアの調達方法や影響力の行使の仕方をよく理解しているな、と思う。
たとえば、コロナ感染症サイトへのプルリク、マスク在庫サイトの構築方法、記者会見をすべてオンライン化などがすぐに思い浮かぶ。

彼女のやり方で参考になる点はいくつかある。
1つ目は、ソフトウェアの開発はベンダー委託ではなく、オープンソース開発者のコミュニティを使って、アジャイルに開発していること。
公的なソフトウェアの開発は、官公庁の内部調整やベンダーへの委託によるリスク回避など、数多くの組織的な壁がボトルネックになりがちだ。
しかし、本来、公的なソフトウェアは国民全てがその利益を享受できるものだし、その重要性は高いのだから、いち早くリリースして、漸進的にVerUpしながら開発していくべきだ。
しかも、ソフトウェアは請負契約で作ったら終わりではなく、SaaSと同じく、運用しながらどんどん改善していく開発スタイルなので、ベンダーへの一括委託は元々なじまない。
現在のソフトウェア開発の技術革新の場所は、ベンダーではなく、オープンソースコミュニティに移っているのだから、彼らの力を利用して、国民すべての利益にかなうようなソフトウェアを作るべきだろう。
彼女の言動や行動した結果を見ると、ソフトウェア開発の特徴をよく理解しているように思える。

2つ目は、情報を発信すると人々がどのように影響を受けて、どんな行動に移るのか、という事を彼女はよく考えて理解しているように思えることだ。
「現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」という記事の言葉から想像すると、行動経済学の知見をよく知っているのではないか、と思う。

実際、コロナ感染が流行している時期にマスクの情報を何の仕掛けもなく公表するとどうなるのか?
本来マスクが必要な人に情報を知らせるにはどうすればよいのか?

皆が混乱している時に、その情報をIT技術で見える化することで、真実を共有し、そこから各人のあるべき行動を促す。
IT技術は本来、そういう問題解決に使うべきものであるはずだ。

そして、単に、マスク在庫のシステムをアジャイルに作るだけではない。
彼女や他の大臣が率先して、その規範を示していることも大事だ。

「例えば、支給マスクの色がランダムで、ピンクが当たった男子生徒が登校拒否になっているという声が届きましたが、その翌日には閣僚の男性陣によるピンクマスク着用のキャンペーンが始まりました。」という記事の通り、大臣自らが率先して見せれば、他の人も自然にその行動変容を受け入れてくれる。

「組織文化は組織のトップが作り出すもの。組織のトップはもっと汗をかくべき」と、とある先生から組織論の授業で習った。
僕が理解するには、人がたくさん集まっても、単なる集団であり、何かの目的を成し遂げるための組織にはなりえない。
トップがリーダーシップを発揮して、共通目的を語り、メンバーの貢献意欲を引き出し、コミュニケーションを活性化して初めて、集団は組織に変わり、人々の行動を変容させる。
また、社会や組織の中にいる人達は、社会的地位が低かったり、経済力がなかったり、政治力がないために、他の力の強い人達の影響を受けやすい面がある。
だからこそ、規範となるべき人があるべき姿や目的を語ることで、人々の意欲を引き出し、人々の行動を変容させる。
つまり、社会に流通する価値観や規範は、そのトップのリーダーシップから生まれるものだ。

そして、昨今の環境では、SNSを使えば、簡単に周知させやすい。
人の気持ちを盛り上げて、意欲を引き出すような言動をリツイートさせることで、人々に行動を変えさせる事が以前よりも格段に簡単に、かつ、その影響力が大きくなった。
その分、この使い方も難しい。
行動経済学が考えているように、人は合理的な存在ではなく、時代や環境に依存したバイアスを持って価値判断を下し、経済効果を生み出す。
そういう考え方を利用する方法もあるだろう。

| | コメント (0)

より以前の記事一覧