コミュニティ

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)

2020/05/23

第18回東京Redmine勉強会~オンライン勉強会の可能性 #redmineT

第18回東京Redmine勉強会を始めてオンラインで実施できました。
参加者、講演者、スタッフの皆様、ありがとうございました。

【参考】

第18回勉強会 - redmine.tokyo

第18回東京Redmine勉強会『Redmineによるテレワーク運用』(2020/5/23) - Togetter

第18回redmine.tokyoでテレワークの工夫と真髄を知る【リモート開催】 #redmineT | マドびっ! Madosan's View

redmine.tokyo 参戦|makoto0119|note

第18回redmine.tokyo勉強会 - ryouma-nagareのブログ

デッドナイト東京、ではなくredmine.tokyo onlineに参加|みけねこ|note

【1】約3時間の長丁場のオンライン勉強会にも関わらず、最大風速でZoom75人、YoutubeLive100人超えで大盛況でした。
まだ事後アンケートを見ていないが、それだけテレワーク中にRedmineを利用していたり、興味を持つ人が多かったのかな?
ツイートも多くて、読み返すのが楽しい。

【2】講演で気になった感想をメモしておく。

【2-1】前田さんの講演では、RedmineのVer4.2の新機能が紹介されていた。

ユーザグループでウォッチャーに登録できる機能。
ユーザグループを大量に作っている時は欲しくなる。
Feature #4511: Allow adding user groups as watchers for issues - Redmine

ユーザーアカウントのメールアドレスのドメインの制限。
Redmineにある守秘義務のあるデータを個人スマホに転送できなくする為に必要。
ISMSでも必要。
Feature #3369: Allowed/Disallowed email domains settings to restrict users' email addresses - Redmine

優先度が高いチケットの更新を通知するオプション。
Patch #32628: Notify users about high issues (only) - Redmine

akipiiさんはTwitterを使っています 「#redmineT 優先度が高いチケットのみ通知メール対象にする設定の機能追加。通知メールの量を抑えながら、重要な情報のみ検知できる運用が可能。」 / Twitter

プロジェクト一覧のデフォルトの表示形式設定。
Feature #32818: Add a system settings for default results display format of project query - Redmine

akipiiさんはTwitterを使っています 「#redmineT プロジェクト一覧を常にリスト形式で表示できるが、初期表示をカスタムクエリで設定した情報で保存できる機能追加。PMOや経営層のようにPJ横断で見たい人には必要ですね。」 / Twitter

チケット表示画面に「完了」「未完了」のバッジを表示。
完了チケットなのに、コメントする人がいるので、それを気づかせてくれる。
Feature #33254: Show open/closed badge on issue page - Redmine

Wikiツールバーのテーブル挿入ボタン。
Feature #1575: Toolbar button to insert a table - Redmine

Wikiツールバーのコードハイライトボタンのカスタマイズ。

akipiiさんはTwitterを使っています 「#redmineT Wikiで表を簡単に挿入できる。Wikiのコードハイライトでよく使う言語を個人で指定して保存できる。この辺りは、Wikiを使って情報共有したい人には、手が届く痒い機能ですね」 / Twitter

チケットがクローズできない場合の理由を表示。
Feature #31589: Show warning and the reason when the issue cannot be closed because of open subtasks or blocking open issue(s) - Redmine

akipiiさんはTwitterを使っています 「#redmineT チケットがCloseできない理由を警告メッセージで表示してくれる。例のように、親子チケットのCloseができない場合が多く、問合せも多くて面倒でした」 / Twitter

【2-2】門屋さんから、Redmine活動家のお話。
PMOならではの苦労が想像できる。

Redmine警察、Redmine職人、Redmine活動家のような役割は、Redmineの運用をスムーズにさせるには必要な機能と思う。
彼らはRedmineの潤滑油。

ししゃもさんはTwitterを使っています 「Redmine ー警察 ルールが守られているか ーマイスター 職人 使い方の理想を追いつつメンバーを教育 ー活動家 あるべき姿に到達させる人 ー神 まえだ?さん #redmineT」 / Twitter

活動タブをよく見てます、という意見。
プロジェクトの活発度合い、チームの雰囲気を知るのに役立つ。

もりのあささんはTwitterを使っています 「チケット管理は”活動”はかなり重要よね。 よく見る。 #redmineT」 / Twitter

Redmine利用レベルはCMMIを参考にしている、と聞いて、上手く考えているな、と思った。

ししゃもさんはTwitterを使っています 「活動家 レベル1-自主調整 レベル2-相互調整 レベル3-是正提案 レベル4-介入 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「redmine利用のレベル1-5は、CMMIレベル1-5を参照してますよ~ #redmineT」 / Twitter

JiraではチケットよりもConfluenceをよく使う、という意見もあった。
情報を蓄積する機能はWikiの方が良い、ということなのだろう。
以前、Jiraでは、設計書などの仕様は全てWikiで実現すべきという発想であると聞いたので、Confluenceを多用する気持ちは分かる。

もりのあささんはTwitterを使っています 「うちの会社(JIRA)だと詳細がチケットに書かれずにコンフルに書かれてることが多いんだよな。 チケットに書いた方がいいんじゃないかなとは思うんだけど。 (JIRAのアクティビティじゃなくてコンフルの週報とか日報の更新メールを監視してる) #redmineT」 / Twitter

タマコナ??Backlog最近の更新家さんはTwitterを使っています 「門屋さんのお話、RedmineのところをBacklogやJIRAに置き換えても全く違和感ない。それだけ普遍的なお話だということ。 #redmineT」 / Twitter

【2-3】yukiaさんのBacklogとRedmineの比較も興味深かった。

タマコナ??Backlog最近の更新家さんはTwitterを使っています 「Backlogはすぐに利用できる。 (=カップ麺) Redmineは食材を料理してから利用する(=スーパーマーケット) #redmineT」 / Twitter

あさこさんはTwitterを使っています 「「なんで使いにくいと思うのか?」の違和感の追求をすると、本来やりたいところにフィットするツールが選択できるのよねぇ。 機能だけ知っていても、無駄無駄無駄無駄無駄無駄無駄...ッ! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineにもユーザが既読したのか表示する機能は欲しいな。スマホのMessenger等では今は当たり前だから。」 / Twitter

@saitoさんの「Redmine+Teams=TeleWork」の話も興味深かった。
チケット管理ツールとチャットツールをどのように使い分けるべきなのか、どの利用シーンで使うべきか、という議論が聞きたかったから。

もりもりさんはTwitterを使っています 「初動 Teams ・チャットの嵐 ・ファイル、メモの嵐 ・Web会議 →キーマンへチケット化指示(Redmine) #redmineT」 / Twitter

ししゃもさんはTwitterを使っています 「Teams…第一報はココ。大体の嵐が去った後に作戦が立つ。収拾がつかなかったらweb会議へゴー。この会議がなかなか優秀 Redmine…キーマンが宣言してチケット起票 #redmineT」 / Twitter

Ryo MiuraさんはTwitterを使っています 「「共存」「使い分け」はもっともだと思う。シンプルなツールほど使いやすい。昔は、いろんな機能が入ったソフトが流行っていたけど、いまは、スマホのように「シンプルな機能を自分の画面で並べて使っていく」。こんな時代。PCでも、同じかと。#redmineT」 / Twitter

カエ太さんはTwitterを使っています 「ほっとくと皆チャットに籠もってしまうので、いかにチーム/チャネルに誘導するかがポイント>Teams #redmineT」 / Twitter

【2-4】@naitoh さんによるアンケート集計結果で興味深い点がいくつかあった。
Ver4.xが半数以上なので、ほとんどの人達は最新機能の恩恵を受けている。
よって、RedmineのVerUPに追随できるだけのインフラや環境構築の知識がある人達が多いのだろうと推測する。

また、チャットツールはSlackとTeamsとZoomが半数以上を占めること。GoogleMeetは少なかった。
懇親会で聞いた話では、TeamsはMicrosoftがすごく力を入れているので、どんどん使いやすくなってますよ、と。
僕はTeamsの経験がないので、どのチャットツールがどんな特徴があるのか、この辺りのツール比較は興味がある。

akipiiさんはTwitterを使っています 「@naitoh さんによるアンケート集計結果。興味深い点は、Ver4.xが半数以上。チャットツールはSlackとTeamsとZoomが半数以上を占めること。GoogleMeetは少なかった。 https://t.co/WbOoFpsXMf 18 questionnaire #redmine https://t.co/5xNYCDW6wQ」 / Twitter

【3】オンライン勉強会の裏方を担当して、こんなやり方もあるのか、という経験ができて良かった。

講演を普通にZoomで配信するのは当たり前。
課題は、オンライン勉強会では参加者の反応が見えず、シーンとなりやすいので、参加者のフィードバックを集めていかに場を盛り上げるか、という点にあると考えていた。
今回は、Twitterで感想や質問を流してもらい、裏で集めてフィードバックする方法を取ってみた。

講演者の立場では、すぐに感想がもらえるのでとてもありがたい。
スタッフとしても、勉強会の評価に直結するので気になる。

今回は流れる量が非常に多く、その内容を質疑応答タイムで使ったら、講演者とスタッフの間で盛り上がってしまって、ちょっと長引いてしまったくらい、良かった。
この辺りの、勉強会の場を盛り上げる方法はいくつかあると思うので集めてみたいと思う。

たぶん、アジャイル開発のコミュニティであれば、全員がリーダーでありファシリテーターでもあるだろうから、こういう段取りをしなくても上手くいくのかも知れない。

| | コメント (0)

2020/05/18

Redmineヘッドラインで今の話題をチェックする

@g_maedaさんが、Redmineヘッドラインを公開されていたのでメモ。

【参考】
Redmineヘッドライン ? プロジェクト管理ツールRedmineの今の話題をまとめて紹介

MAEDA GoさんはTwitterを使っています 「Redmineヘッドライン https://t.co/xRfgvzB3pZ に先週 (2020/05/10-16) は計6件のリンクを追加しました。 - redmine-issue-loader 2.3.0リリース - Issue Templates 1.0.2リリース - Full Text Search plugin と ChupaTextで添付ファイル内全文検索 ほか」 / Twitter

MAEDA GoさんはTwitterを使っています 「@akipii Redmine関係の記事やソフトウェアの情報は、見つけたものはどんどん載せます。Redmineのコミュニティの盛り上がりに少しでもつなげられるといいなと思っています。」 / Twitter

MAEDA GoさんはTwitterを使っています 「@juno_nishizaki ありがとうございます! いろんな方がせっかく公開してくださった記事やプラグインの情報がRedmineに関心がある方に届きやすくして、コミュニティに少しでも貢献できればいいなと思っています。」 / Twitter

Redmine本体だけでなく、Redmineに関するプラグインやTips、ブログなどがリンクされているので、とても参考になる。
最近の流行はすごく速いので、こういうサイトで時々チェックできれば、最新動向も把握できる。

直近の話題は下記ですね。

「こどもれっどまいん」というテーマを作っています。 - Qiita

Docker Compose で作った Redmine だって Full Text Search plugin と ChupaText サーバーを連携させたい - Qiita

doc2vecでredmineのチケット(csv)を学習させてみる - Qiita

redmine-issue-loader のバージョン2.3.0をリリースしました - Enjoy*Study

Redmine draw.io plugin がすごい便利そうなので紹介したい - Qiita

他に、まどさんや僕のブログもリンクされてましたね。

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ! Madosan's View

Redmineとチャットツールはどのように使い分けるべきなのか: プログラマの思索


| | コメント (0)

2020/05/17

オンライン勉強会のノウハウのリンク

最近の勉強会は、オンライン配信する時が多い。
友人からオンライン勉強会のノウハウを聞いたので、リンクをメモ。

【参考】
Zoomを活用してOSC2020 Online/Springを開催しました - 宮原徹の日々雑感

Zoomで開くオンラインイベント入門

アットホームな感じの オンラインイベントの配信を意識してみた

20200326 meetup video shooting meetup vol2 kitazaki いつも持ち歩ける ワンオペ配信機材

なぜ Infra Study Meetup運営は配信トラブルを引き起こしてしまったのか - Forkwell Press

オンライン勉強会に参加したり、自分たちが主催になった立場で経験してみると、いくつか気づきはある。

良かった点は、2つある。
一つは、東京など遠方の勉強会であっても、参加しやすくなったこと。
今まで行きたかったのに東京だから無理だ、という障害がなくなった。
また、参加者は全国が対象になったので、多数の参加者を集めることも可能になった。
さらに、会場費用も不要なので、勉強会のコストはせいぜい、Zoom管理費用をサブスクリプションで払うぐらい。

もう一つは、コロナ感染防止による自粛で外出できなくなっても、毎日どこかでオンライン勉強会が開催されているので、参加すれば、孤独感を感じることはなくなった。
むしろ、以前よりも頻繁に勉強会に参加しやすくなったし、以前と同じ交流ができた。
休日ならば、1日間に3回もオンライン勉強会をハシゴすることも可能だ。
実際経験してみたら、朝から晩までノートPCにしがみついているので疲れた。

他方、課題や留意点はいくつか感じる。

1つ目は、それなりの機材や環境は必要であること。
通信速度は100M以上は欲しい。
回線が細いと、ビデオも音声も途切れがちになり、お互いのコミュニケーションがやりにくくなる。

ノートPCにカメラは付属しているけれど、音声はヘッドセットが別途あった方がいい。
ハウリングしたり、自宅のノイズを拾ってしまうから。
片耳にかけて会話も出きるBluetooth ワイヤレスヘッドセットがあると便利。

2つ目は、Zoomなどのツールを使いこなすこと。
Zoomの管理機能はまだよく分からないが、部屋を作って参加者を分けたり、とか、割と機能が豊富みたい。
他にも、GoogleHangoutやSkype for businessなどある。
それらのツールでどこまで使いこなすのか、まだ理解している途中。

また、ビデオで会話するだけでなく、チャット機能やチャットツールも欲しくなる。
だが、オンライン勉強会を主催する立場になると、Zoomのようなビデオツール、参加者とやり取りするためにslide.ioやTwitterなどのチャットツール、スタッフ同士で裏でやり取りするMessengerやSlackなどが必要になってくる。

すると、Zoom、slide.io、Messengerの3つのチャネルを随時見ないといけないので、ノートPC以外にタブレットやスマホなども総動員して、3つ以上の通信機器を机に広げることになる。
つまり、割と大変なのだ。

3つ目は、オンライン打合せのファシリテーションスキルが必要になっていること。
対面の打合せでもファシリテーションは必要だが、オンラインになると、どうしても一方通行になりがち。
いかに参加者から活発な発言を促して発散させるか、そしてその議論を収束させていくか、オンライン特有のファシリテーション技術が必要な気がしている。

対面のファシリテーションでは、ホワイトボードやPostItが有効だったが、オンラインではそれらツールが使えない。
エディタやGoogleスプレッドシートを画面共有したり、マインドマップをツールで書いたりする。

オンライン・ホワイトボードは下記のツールがいいよ、と、坂根さんから教えてもらった。

便利なオンラインホワイトボードサービスmiro(ミロ)の使い方の基本

ファシリテーションでは、人間的なスキルだけでなく、こういうツールを使いこなす技術も必要なのだ、と気づいた。

たぶん、こういうツールや課題は、今はまさに発展途上な状態。
来年になれば、当たり前になっているかもしれないし、まだ先のノウハウも生まれているだろう。
いろいろ試してみたい。


| | コメント (0)

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/10/24

第3回astah関西勉強会の感想 #astahkansai

昨夜行われた第3回astah関西勉強会の感想をメモ。講演者、スタッフ、参加者の皆さん、ありがとうございました。

【参考】第3回astah関西勉強会「もやもやを分解しよう」 - connpass

「モデリング事例紹介」10月23日に大阪で開催 ? 参加申し込み受付中! | astah in 5 min

PlantUML Example for モデルベース要件定義テクニック - Qiita

【1】ツイッターやastah blogぐらいしか流していないのに、狭い部屋に参加者が30人以上も来てくれました。懇親会でも、以前から勉強会の存在は検知していて、今回初めて参加できた、という人もいた。勉強会のターゲット層、議論するドメインは非常に狭いと思うのに、興味を持つ人が多くて正直嬉しかった。

僕は、astah関西コミュニティでは、プログラミングとモデリングの間をモデリングツールや事例紹介の観点で行ったり来たりする議論ができるといいな、と考えている。そういう思いに共感してくれる人たちが少なくとも存在する、と気づけたのはとても嬉しかった。

【2】以下、講演の内容で感じたことをメモしておく。

【2-1】@ogomorさんの講演PlantUML+RDRAの話は、以前から聞きたいと思っていた。過去に色々書いてきた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

RDRAについては、システム地図という考え方が重要と考えている。要件定義から論理モデルや実装モデルまで、要件をトレースする仕組みがシステム地図として実現されている。つまり、RDRAでは、トレーサビリティを重視した手法であると思っている。僕は、モデリングではトレーサビリティが重要と思っているので、RDRAの考え方は好きだ。

但し、RDRAでは、UMLを拡張した図を多用するので、astahなどのUMLモデリングツールでは、UMLの制約に引っかかって全ての絵を書くことができない弱点があった。そこで、PlantUMLを使うと、自由に描けるので、RDRAの技法を全て実現できる。しかも、テキストベースなので、設計書をMarkdownで書けば、プログラムから設計書まで全てGitで構成管理の配下に置ける。

akipiiさんはTwitterを使っています: 「#astahkansai RDRA はUMLを拡張してるので、astah などの普通のモデリングツールでは制約に引っかかって書きにくい時がある。plantuml なら自由に描けるので、RDRA の記法も問題ない。」 / Twitter

興味深い点は、PlantUMLのソースを見るだけで脳内にUMLモデルの絵がイメージできるし、逆に、UMLモデルの絵からPlantUMLソースをイメージできるようになる、ということ。
右脳と左脳で行ったり来たりしている点はすごいな、と思う。

akipiiさんはTwitterを使っています: 「Astahkansai 慣れてくると、plantuml のソースから、頭の中で絵をイメージできる一方で、UMLの絵からplantuml のソースが頭の中にイメージできる、と。なるほど、まさに右脳と左脳で行ったり来たりしてるわけだ」 / Twitter

講演では図書館モデルの事例紹介で、ユーザの要望をコンテキスト図で表す時に、アクターアイコンの吹き出しに要望を書くことで、あたかもユーザが声に出して要望を話しているように見える、という箇所は非常に興味深かった。また、VSCodeでPlantUMLをライブコーディングしながらUMLを書いていく説明も分かりやすかった。PlantUMLは奥が深そうなので、色々試してみたい、と思う。

【2-2】とくぢろうさんの講演ユースケースリファクタリングでは、ファウラーのリファクタリング本を元に、ユースケースのリファクタリングのカタログを作ってみよう、という話で、面白かった。

ユースケースの削除、抽象化、分割、共通化、などは、ソースのリファクタリングの手法と全く同じように考えられるので、理解しやすい。実際の場面でユースケースを使う利用シーンは少ないけれど、その考え方は要件定義に活かせると思う。

但し、リファクタリングはTDDと表裏一体なのに、ユースケースのリファクタリングはTDDがないので、その部分の弱みはある。他にも課題はあったが、思考は深められそう。

akipiiさんはTwitterを使っています: 「#astahkansai Cソースの依存関係をastah のユースケースで描くと、ユースケースの依存関係の機能を使えるので便利」 / Twitter

【2-3】高井さんの講演では、GSNを使って、組込みシステムのタスク実装の意図を残す事例。僕は、GSNはロジカルな手法なので、厳密に説明するもの、と思っていたが、事例紹介の話を聞くと、説明する人の立場で論理を組み立てるので、意外に緩やかに使える印象を持った。

僕は、GSNやフォルトツリー解析、STAMPなどの手法はどのような違いがあり、どのように使い分けられるのか、が分かっていないので、この辺りも考えてみたいと思う。

【2-4】細合さんの講演では、テストケースの組合せ爆発を、フィーチャーモデルを使って制約条件を表現し、astahを基盤とした開発ツールでテストケース生成を行った話。フィーチャーモデルはソフトウェアプロダクトラインにも出てくるが、実際の記法を見ていたら、原因結果グラフに似ているような印象を受けた。だとすれば、組合せたテストケースの精度は非常に高いだろうと推測する。

【3】2時間の勉強会にたくさんの講演を押し込んでしまったので、質疑応答の時間が取れなかったのは反省点だけど、熱心に聞き取る参加者を見て、開催できてよかった、と思った。とても小さなコミュニティだけど、今後も緩く長く続けられればいいな、と思っている。

| | コメント (0)

2019/09/21

第3回astah関西勉強会の見所「もやもやを分解しよう」 #astahkansai

第3回astah関西を1年ぶりに開催します。
興味のある方は、ふるってご参加ください。

【参考】
第3回astah関西勉強会「もやもやを分解しよう」 - connpass

(引用開始)
要件定義やシステム開発で袋小路に陥った時、何か「もやもや」していることはありませんか?
そこで、そんな「もやもや」をモデルに書き出して、どんどん分解して、もやもやの真因を突き止めていきましょう。

そんな時に役立つモデリング手法の実践事例を講演者から紹介して頂きます。 具体的には、下記になります。

・モデルベースの要件定義手法(RDRA)とPlantUMLを使った実践モデリング
・ユースケースのリファクタリング・テクニック
・設計やプロジェクトのゴールに関するモデリング技術:ゴール指向表現(GSN)
・フィーチャー図によるテストスィートのモデリング技術
(引用終了)

一番の見所は、@ogomrさんの「PlantUML Example for RDRA 2.0」 。
PlantUMLで要件定義や設計の作業をどれだけ書ききれるのか、に興味がある。

@ogomrさんの下記の記事はとても参考になる。
PlantUML Example for モデルベース要件定義テクニック - Qiita

UMLで全ての設計ができるわけではないだろうが、UMLを一部カスタマイズして、業務システムの要件定義やシステム設計に合わせるようなモデリング技法(RDRA)を組み合わせると、ほとんどの内容をモデルとして描くことができる。
さらに、PlantUMLでテキストベースにUMLモデルを書けば、設計モデルもソースも全てGitの構成管理の配下で管理させることができる。
そうすれば、自動デプロイすることで、最新の設計書とビルドモジュールがいつでもリリースできる流れになる。

このあたりのアイデアは以前色々考えていた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

PlantUMLが優秀な点は、UMLだけでなくER図も書けるし、画面インターフェイスの部品を使って画面設計書も書けたり、マインドマップやガントチャートまで対応している点だ。
つまり、設計資料以外にも、PJ管理資料まで全てテキストで管理できる可能性がある。

また、VSCodeを使えばPlantUMLを簡単にプレビューできるので、開発環境も揃っているのも良い。
もしかしたら、astahでモデルを描くよりも、VSCodeの方が馴染む人もいるかもしれない。

設計者が自分の意図を開発者に伝えたい時、シーケンス図を書くときが多いだろうが、その時に、PlantUMLで書いたシーケンス図を渡す利用シーンも考えられる。

特に、シーケンス図の修正はPlantUMLでテキストベースで書いている方が、仕様変更の対応にも強い。

そんなことを考えると、設計というモデリング技法は、モデリングツールの開発という観点も含めて、まだまだ発展途上の技術のような気がしている。
そういう内容も合わせて、色々議論できると楽しいと思っている。

| | コメント (0)

2019/06/16

業務系エンジニアが生き抜くのは難しい時代になった

業務系エンジニアが生き抜くのは難しい時代になったという記事をリンク。
以下、脈絡のないポエム。

【参考】
業務系エンジニアはどうしていくべきか? - 急がば回れ、選ぶなら近道

【1】日本のSIなら、プログラマからマネージャになるにつれて、実装技術から離れてしまい、どんどん技術から離れていく。
すると、一番怖いのは、技術の目利きが落ちることだと思う。
最新技術のメリット、デメリットをいち早く見抜き、どの場面で適用すると上手くいくのか、逆に失敗するのか、という目利きができなくなると、正直怖くなる。

結局、技術の全部を抑えておかないと難しい。

【2】「最終的にはシステムはIOに行き着く」という指摘は秀逸。
アプリ、ミドルウェア、インフラなどの層別アーキテクチャ(N-Tier)はいつの時代も基本。
最近は、インフラが熱い。
インフラを押さえれば、最近の技術の動向はいち早く把握できる。

【3】イノベーションを常に強いられる業界は、そこで働く人にとっては苦痛に思える人も多いだろう、と思ったりもする。

実際、若かった人も年を取ればどうしても、過去の経験値に縛られたり、集中力や瞬発力が落ちるので、新しい文化を取り入れるのが難しくなる。
広岡達朗の著書の中で「人間は常に保守的な存在だ」という文言を以前読んだことがあったが、たぶんその言葉は真実なのだろう。
人間は、従来成功したやり方を明日からいきなり変える、ということに抵抗感があるのだろう。

経験値がゼロで、獲得した資産や家族がなければ何も怖くはない。
しかし、長年蓄積してきた資産、経験、家族が増えてくれば、それを全て捨て去り、一から作り出すのは心理的に難しくなる。
一方、イノベーションのジレンマでは、過去の資産を活用できるプロセス・イノベーションを前提にしていない。
むしろ、イノベーションを阻害するような過去の経験は無い方が、イノベーションを生み出しやすい。

イノベーションを常に強いられるIT業界は、脱落するエンジニアが多く、経験豊富な人よりも若者の方が有利、という特徴が出てくるのだろう、と思う。
そして、「IT業界はイノベーションが激しい」ということと「IT技術は後方優位性が強い」ということは同じ意味なのだろうと思う。


| | コメント (0)

より以前の記事一覧