« 2020年9月 | トップページ | 2020年11月 »

2020年10月

2020/10/31

アジャイル動画「私もアジャイルに飛びこんだの! -- 『品質重視のアジャイル開発』の誉田さんインタビュー」がいいね

アジャイル動画「私もアジャイルに飛びこんだの! -- 『品質重視のアジャイル開発』の誉田さんインタビュー」がいいと思ったのでリンクしておく。

私もアジャイルに飛びこんだの! -- 『品質重視のアジャイル開発』の誉田さんインタビュー ? アジャイル動画

「私もアジャイルに飛びこんだの!」というフレーズがとても可愛いのだが、誉田さんはNECでCMMIレベル5の導入運用に携わった人と聞いているので、そのギャップの違いに惹かれた。

『品質重視のアジャイル開発』を書いた動機は、色んな人から、アジャイル開発では品質保証はどうやっているのか?と聞かれて、その解答を自分から答えようとしたこと、と聞いて、すごく納得した。

実際、『品質重視のアジャイル開発』では、P.32で「顧客が納得するアジャイル開発の品質保証方法は確立されていない。本書は、その課題の解決に挑戦している」という言葉がある。
この言葉にすごくしびれた。

上記の動画では、誉田さんは、私は2010年頃からアジャイル開発に携わったので、平鍋さん他皆さんとはそこまでアジャイル開発の経験を持っていないと謙遜されていたが、『品質重視のアジャイル開発』の内容はとても充実していると思う。

上記の動画の最後でも紹介されているが、アジャイル開発はミニWF型開発ではない。
アジャイル開発はミニWF型開発とみなしてしまうと、必ず大火傷を負う。
それはなぜか?

アジャイル開発の特徴はとにかく期間が短いことだ、と著者は言う。
WF型開発では半年かけて、各工程にゲートを設けて品質チェックし、品質を担保していく。
そのやり方をアジャイル開発にそのまま適用しても、短期間の制約があるから、必ず現場が混乱する。

一方で、WF型開発の品質保証で得られた知見である「プロセス品質」「プロダクト品質」の考え方はアジャイル開発にも通用する。
アジャイル開発でもその考え方を適用する。
プロセス品質では、技術プラクティスを習慣にし、開発チームの構成に配慮すること。
プロダクト品質では、Done判定を出荷判定基準とみなし、バックログの順番に頻繁に品質保証していくこと。

個人的には、「Done判定を出荷判定基準」とみなす観点は有効な知見だと思う。
ソフトウェア品質保証は、WF型開発でもアジャイル開発でも、同じような概念や観点は共通で存在するし、その背景には、品質はどんな開発プロセスであれ必要なのだ、という思想があるのだと思う。

また、『品質重視のアジャイル開発』では、アジャイル開発にもWF型開発のメトリクス分析を適用しようとして、色々苦労されている内容がある。
結論は、定量データを用いてアジャイル開発のプロセスを分析するのは難しい、ということだ。
理由は、アジャイル開発では、短期でリリースするので、スプリント単位の開発規模は小さいために、メトリクスのばらつきが大きくなるからだ。
すなわち、開発規模やチームの生産性のばらつきが大きいために、Velocityで複数チームの生産性を比較するのは有意味なりにくいし、各チームの開発状況を分析するのが難しいのだ。

考えてみれば、規模が小さいのでばらつきが大きくなる、というのは当たり前なのだが、結局、短期間リリースと定量データ分析はトレードオフなのかな、と感じる。

また、『品質重視のアジャイル開発』本は、品質保証の観点で噛み砕いて解説してくれているので、WF型開発バリバリのプロジェクトリーダーがアジャイル開発に取り組む時に役立つと思う。

| | コメント (0)

2020/10/30

「オブジェクト指向でなぜつくるのか」は良い本だ



オブジェクト指向でなぜつくるのか」を読んで、良い本だと感じた。
ラフなメモ書き。

10年前に書かれた第2版の本なのに、オブジェクト指向をキーワードにして、これだけ幅広く記載しているのはすごいな、と思った。
本にある図を参照して、イメージ図を自分で書いてみた。

Photo_20201030220601

「オブジェクト指向」を開発者が混乱するのはなぜか?
犬や猫の鳴き声をポリモルフィズムで表すとか、その例自体が混乱させる。
現実世界を全てオブジェクトに置き換えられるわけではないのに。

理由は、元々はオブジェクト指向プログラミングから発生したのに、オブジェクト指向設計や再利用部品群やデザインパターン、UMLなどの派生した概念と混同しているから。
特に、オブジェクト指向設計は汎用の整理術なので、オブジェクト指向プログラミングとは全く異なる。

オブジェクト指向プログラミングで、メモリ領域の話と絡めて説明しているのは分かりやすい。
メモリにクラスやインスタンスがロードされる感覚がなければ、良いプログラムは書けないだろう。

一方、オブジェクト指向設計では、クラスは集合、インスタンスは要素として集合論に持ち込んだり、メッセージパッシングからクラスの責務・役割分担へ発展させたりして、本来のオブジェクト指向プログラミングから離れた方向に向いている。

面白かった点は、ビジネスソフトウェアと組込みソフトウェアでは、設計・分析の考え方が違う点だ。
ビジネスソフトウェア設計では、システム化される業務と人間の手作業の業務を明確に分ける。
システム化された領域のうち、データモデルのみが現実の出来事の世界を反映しているに過ぎない。
だから、業務分析でシステムの境界を明確にし、システム化する業務を詳細化することが非常に重要になってくる。

一方、組み込みソフトウェア設計では、機械装置が最初にありき、で、機械装置の機能を全自動化するためにソフトウェアで実現する。
もちろんオブジェクト指向設計もできるが、機能の状態遷移図の方が設計でも重要になってくる。
つまり、どういう状況で、どういう動作を行うのか、という要求分析の方が重要になってくる。

この違いが面白い。
組み込みソフトウェア開発は経験がなかったので、この辺りのフィーリングの違いは興味深く読んだ。

オブジェクト指向の影響は、オブジェクト指向のプログラムは再利用しやすい点より、フレームワークやコンポーネントなどの再利用ライブラリを作り出した。
そして、再利用する設計思想を抽出するコンセプトから、デザインパターンが生まれた。
デザインパターンも数多くの流派を生み出した。
再利用できるイディオムやノウハウ、プロセスという観点で、アナリシスパターン、アーキテクチャパターン、そして、組織パターンなどがある。
XPもプロセスパターンの一種である、と考えれば、オブジェクト指向の影響が見受けられる。

Scrumも、「More Effective Agile」で一番気に入った言葉「スクラムチームはソフトウェアのコンポーネントのように振る舞うので、ブラックボックスとして扱うべきだ」から考えると、オブジェクト指向の影響を受けているように思える。
スクラムチームは自律的なチームなので、プロジェクトマネージャはチームのインプットとアウトプットだけ評価すればよく、マイクロマネジメントする必要はなく、チームをブラックボックスとして扱うべき。
スクラムチームはコンポーネントのように疎結合で独立してるならば、複数のスクラムチームを疎結合で組み合わせることで、内部の無駄な影響なしで大規模なチームを構成しやすくなる。
つまり、コンウェイの法則「アーキテクチャは組織構造に従う」を、複数のスクラムチームで構成された大規模な組織は、は良い意味で実現している。

そんなことまで連想させてくれて面白い。
そして、改めて、アジャイル開発はオブジェクト指向の影響を色濃く受け継いでいることを再認識した。

| | コメント (0)

2020/10/28

チケット管理ツールの用途が変わってきている

チケット管理ツールのクラウドサービスAsanaの記事を読んで、チケット管理ツールの用途が変わってきていると感じたのでメモ。

【参考】
チームの仕事、プロジェクト、タスクをオンラインで管理 ・ Asana

Asanaが好きなもので。|なかやけんいち|note

Asana - Wikipedia

asanaの活用方法を徹底解剖!基本的な使い方から応用編までご紹介 |マケフリ

タスク管理ツールAsana(アサナ)とは?特徴や使い方を徹底解説

(引用開始)
人によって「使いやすい」の基点が違う
そして困ったことに「使いやすさ」「快適さ」は職種や人でそうとう異なるんですね。そもそもプロジェクト管理ツールに対する期待値や使う人の環境が違うという問題があります。

エンジニア系の人々は「プロジェクト」という生物を飼育するための運営連絡帳的な視野で利用しているようです。
飼育してる生き物(プロジェクト)が突然病気になったり死んでしまわないよう、チームみんなで協力して連絡帳つけましょう、やるべきことしっかりまとめましょう、とかなり几帳面に運用します。そして当然のように仕事の間ずっと目の前にPC画面があるので頻繁に丁寧にアクセスして記入してくれます。

非エンジニア系=管理・営業・マーケティング系の人々は「パーティ開催の準備リスト」的な視野で利用しているようです。
すべきことのリスト作りは直感的にスピーディにできるのが理想的。そして突発的なタスクの発生・変更にも対応し易く、メンバーが相互に確認できる手軽さが大事です。そして、打ち合わせなどの移動中などにスマホなどからさっと確認・処理できるのがうれしかったりします。
こうした違う種類の人たちが混在するプロジェクトのニーズを同時に満たすのは簡単ではありません。まさに今この瞬間にもうまくいかないと困ってるチームはあると思います。

あえて「エンジニア系」と「非エンジニア系」と書いてみましたが、細かいことを言い出すと、同じ職種でも人によって「快適」のツボは異なったりして、全員が満足するツールを見つけるのはなかなか大変です。
(引用終了)

自分はエンジニア系なので、ソフトウェア開発のプロジェクトを管理したい。
だから、プロジェクトが変な方向に行かないように、成果物とチケットの更新履歴を見ながら、頻繁にチケットを更新して、メンバー間のコミュニケーションを取るようにする。
朝顔に水をやり、変な虫を取り、こまめに手入れするみたいな感じ。
社内の定型業務や一般業務の管理も同じイメージだろう。
Scrumのバックログでチケットを登録して、それらを逐一細かく追跡したい。

一方、営業・マーケティング系の人たちは「パーティ開催の準備リスト的な視野で利用している」指摘が面白い。
確かに、エンジニア系の人でも、コミュニティでのイベント管理や日々の運用管理では、成果物とそれに紐づけた作業の2つを管理するよりも、今どれだけの課題やタスクがあって、抜け漏れはないよね、という点を確認したい。
もっと気軽にチケットを管理したい。
ToDo管理やGTDに近い感じで、サクサク閉じていきたい。

Redmineは良いツールと思うが、他のSaaSを見ていると、気軽に使えるな、と思う時がある。
そのあたりを色々考えてみる。


| | コメント (0)

2020/10/22

RedmineでGitのbareリポジトリにアクセスする方法

久しぶりにローカル環境のRedmineを構築してみた。
ローカル環境にあるGitリポジトリをRedmineに連携する設定をメモ。

【参考】
共有フォルダに Git 中央ベアリポジトリを置く - Qiita

既にGitリポジトリがローカル環境にある前提とする。

git-bashを開く。
bareリポジトリを作成する。

cd /c/home/ruby
mkdir bare

cd /c/home/ruby/bare
git init --bare --shared=true

初回のPush。
cd /c/home/project/repo
git remote add origin /c/home/ruby/bare
git push --set-upstream origin master

2回目のプッシュ
cd /c/home/project/repo
git push origin master

TortoiseHgやSourceTreeならば、2回目からコミットしてPushすればOK。

Redmineの設定画面でGitのBareリポジトリをセットすれば、リポジトリ画面に表示される。

Ver4.1のRedmineをローカル環境にセットアップして、Gitリポジトリも連携できたので、すごく快適。
課題管理も進捗管理も構成管理も、全てRedmineに集約すれば、作業が捗るのは嬉しい。

| | コメント (0)

2020/10/21

astahでオブジェクト背景にグラデーションを設定する方法

いつの頃からか、astahでオブジェクト背景にグラデーションがつかなくなった。
astahでオブジェクト背景にグラデーションを設定する方法が下記にあるのでメモ。

既存の図にグラデーションを設定する方法 | astah in 5 min

システムプロパティ>ダイアグラムエディタ>グラデーション図要素>横
に設定し、[プロジェクトに関する設定を現在のプロジェクトに反映する]にチェックを入れる。

| | コメント (0)

2020/10/20

複雑なUMLの代わりにC4モデルが提案されている

知人から、複雑なUMLの代わりにC4モデルが提案されていると聞いたのでメモ。

【参考】
ソフトウェアアーキテクチャのためのC4モデル

The C4 model for visualising software architecture

C4モデルを見ると、Webサービス用のアーキテクチャを描くためのモデリング技法みたい。
コンテナという要素もあるので、インフラ基盤も意識しているように思える。

下記のデモGifが分かりやすい。

C4-PlantUML/vscode_c4plantuml_snippets.gif at master ・ RicardoNiepel/C4-PlantUML ・ GitHub

UMLモデリングは僕は好きだが、確かに記法が複雑になってきているので、初心者には分かりにくいかもしれない。

僕が最近UMLに物足りないと感じるのは、クラウドに特化したモデリング記法やモデリングツールがないことだ。
単にアプリ層だけでなく、インフラ基盤のアーキテクチャも描きたい。
今はWebシステムはAWSのようなクラウド上に構築するのが当たり前で、AWSのサービスを駆使して開発するのが当たり前なので、どういうアーキテクチャに設計すればいいのか、をモデルとして描きたいのだ。

こういう簡単なモデリング技法を使うことで、アプリ開発者がインフラ基盤担当者と会話できるようになるといいなと思う。

| | コメント (0)

2020/10/18

Scrapboxが使いやすい

別のコミュニティ活動でScrapboxを使っているのだが、割と使いやすい。
Scrapboxのリンクをメモしておく。

【参考】
Scrapboxの使い方!アウトプットの効率化におすすめ | Workship MAGAZINE(ワークシップマガジン)

Scrapboxを使い始める前に知ってもらいたい7つのこと|倉下忠憲|note

【お役立ち情報】Scrapboxのメリットから使い方まで一気に解説! | Pikawaka - ピカ1わかりやすいプログラミング用語サイト

議事録をマークダウンで書いているのだが、高速で自動保存されるので気にしなくていい。
普通の箇条書きでサクサク書けて、簡単な強調文字や色文字も使えるし、画像も貼れる。
基本は、ページ内でリンクを貼るだけ。
たくさんのページができても、Index用のページを1個作っておけば、いつでも辿れる。
ブラウザの印刷機能を使えば、そのままPDF出力できる。

また、ブラウザでどこでも表示できるので、PCで書いた後、外出中や通勤電車内でスマホで閲覧もできる。
隙間時間に、自分のアイデアやメモ、記録した内容を見れるのはありがたい。

Googleスプレッドシートを使っている時もあるが、やはりExcelライクなので、後で読みにくい。
やっぱり、Excelはよく使うけれど、あまり使いたくない。
テキストでサクサク書ける方がいい。
たぶん僕はWikiみたいな使い方が好きなんだろうと思う。

Scrapboxであえて弱点があるならば、表を書くことだろうが、「|」ではなく下記のような記法があるらしい。
今度試してみたい。

テーブルの書き方 - oystersjp

| | コメント (0)

2020/10/16

仕事が上手じゃない人は取り掛かりが遅い

Redmineヘッドラインを読んでいたら、「仕事が上手じゃない人は取り掛かりが遅い」という記事があったのでメモ。

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

「部下を育てる」ことを「部下の能力を上げる」ことだと勘違いしていた、という話 | Books&Apps

結騎 了さんはTwitterを使っています 「転職を数回経験して、直近の数年は上司を体験させてもらってるけど、「仕事が上手じゃない人」の多くに共通点があると感じている。それは、「取り掛かりが遅い」。とにかくこれに尽きる。シンプルな怠惰、考えすぎ、極端な慎重派、仕事を断れなくて量を抱える人......。何より着手までが遅い。」 / Twitter

結騎 了さんはTwitterを使っています 「「取り掛かれば10分で終わる仕事」をとにかく後回しにして、30個くらいコレクションして常に「忙しい?忙しい?」と言っている人がいる。仕事コレクターの多くは、何度アドバイスをしても中々改善されない。残念ながら。貴方が持っている間に仕事が腐って次にそれに触れる人が迷惑しているのに。」 / Twitter

(引用開始)
皆さんも経験ありません?
やること自体は明確なんだけど、複数タスクが並んでいると、「まずどれから着手するか」ということから考えてしまって、なかなか着手出来ないこと。
これ、上司からちゃんと優先順指示されてても、「次のタスク」が気になって心理的ハードルが上がっちゃうことってあるんですよ。

まして、タスクの優先順とそのゴール地点自体が不明瞭だったりすると、着手のハードルは天井知らずに跳ね上がります。
「あー」とか「うー」とか言いながらモニターの前で思わずネットサーフィンを始めちゃうこと、ありますよね。

しかもこれ、割と人間の根源的な問題なんで、改善ってすごーく難しいんですよ。
上司や周囲がいくら叱っても、直らないもんは直らないんです。
「他者による能動的な改善」が非常に難しい部分なんです。

で、私の部下にもそういう人いまして、とにかく「まずタスクを開始出来るまでがやたら遅い」という問題があったんで、普通にある時こう言ったんですよ。
「ブラウザのスタート画面をredmineのカスタムクエリにしましょう」って。
(引用終了)

こういう人はいるなあ、と思う。

| | コメント (0)

2020/10/14

Redmine運用の基本を再確認する

Redmine運用の基本を再確認するために、@g_maedaさんの資料をもう一度読み込んだ。
ラフなメモ書き。

スポーツでも勉強でも仕事でも守破離がある。
慣れてくると、破離の段階に入っていくけれど、成長が頭打ちになる時がある。
そんな時に、もう一度原点に立ち戻り、守の部分からやり直すことには意味がある。
凡ミスが多くなる時は、基本を忘れて、基本を徹底していない時が多いものだ。

それはRedmineの運用でも同じように思う。
チケット管理の運用に慣れてきても、ちょっと運用から離れていたりして勘が鈍ると、割と忘れている。

上記の資料で、守の部分の箇所は下記だと思う。

(引用開始)
表計算ソフトで一覧表を作りたくなるような仕事をうまく使える。

難易度・低
課題管理、QA管理、インシデント管理
随時発生する課題を都度登録してどんどん処理していく形態の業務は適用が簡単。

難易度・高
プロジェクト管理
将来のタスクの洗い出しや、すぐには処理できない大量の課題の扱いには習熟が必要。

チケットは管理表の明細1行分に相当。
付箋と捉えてもよい

トラッカーは単なる分類ではない。項目やステータスを制御するもの。

トラッカーの設計=入力フォームの設計

1チケット=1課題

題名だけでも内容が伝わるように

説明欄では終了条件を明確に

担当者は、そのチケットに書かれた課題・仕事を任された人ではない
担当者は、現時点でそのチケットを対処すべき人

チケットの担当者は次々に変える方が良い

Redmineで仕事を進める考え方
仕事は原則チケット化
みんなでチケットを終了させて仕事を終わらせる
(引用終了)

つい最近、自分がミスしたな、と思った部分は、担当者を責任者に固定化してしまったこと。
本来は、担当者はボールを持っている人であり、キャッチボールでやり取りすべき。
責任者をチケットに持たせたいならば、カスタムフィールドで別で保持すればいい。

PJ計画でWBSを策定することばかりやっていると、そういうアンチパターンにはまってしまいやすい。

また、Redmineを運用する時に、チーム全員が積極的に利用する雰囲気を醸し出すことも大事だ。
プロジェクトリーダーは自分自身の管理を楽にするために使いたがるが、利用者の観点でもメリットが感じられるように、配慮すべき点はたくさんある。
もちろん、各メンバーがコミットする責任を持つ意識は必要だが、チーム全体でアウトプットを出すからには、メンバー全員で残チケットに積極的に対応して終わらせる、という意識も必要だ。

そういうメンバーの貢献意欲を引き出すための工夫もRedmine運用では必要だ。
いわゆるチームビルディングやファシリテーションのようなスキルも必要になってくるだろう。

| | コメント (1)

Redmineの二要素認証の利用イメージ資料のリンク

Redmineの二要素認証の利用イメージ資料をリンクしておく。
@g_maedaさんの説明なのでとても分かりやすい。

Redmineに2要素認証のパッチが提供されている: プログラマの思索

Redmine4.2に2要素認証機能が導入された: プログラマの思索

Redmineでワンタイムパスワードが使えるようになるので、スマホのAuthenticaterアプリを使う場合が多いだろう。
その時の手順が画面キャプチャ入りで説明されているので非常に役立つ。

注意点は、Redmineで二要素認証機能をONにしたときに、必ずバックアップコードを生成しておくことだろう。
あるいは初期登録直後の画面キャプチャを採取しておく。
そうしないと、もしもの場合にログインできなくなるなどが考えられる。

Redmineの二要素認証機能が使えることで、インターネット上で公開して運用する場合に、よりセキュアに利用できるメリットがある。
昨今のセキュリティ不備のニュースを見ているから、オープンソースのRedmineにも二要素認証機能が含まれたことはすごいと思うし、今後の発展に役立つだろうと思う。
今後のRedmineの機能改善に着目していく。

| | コメント (0)

2020/10/07

経済学は信頼性革命や構造推定により大きく変貌している

最近、図書館から借りている「経済セミナー」という雑誌が非常に面白い。
経済学は信頼性革命や構造推定により大きく変貌している。
10月号では、「変貌する経済学:実証革命が導く未来」の特集号が非常に面白くてためになった。
気づきをラフにメモ。

実証革命?経済学が会計学に影響を与えるもの|上野 雄史|note

「予想よりも早かった」ノーベル経済学賞(會田 剛史) - アジア経済研究所

伊藤先生は、「データ分析の力 因果関係に迫る思考法」の本でも知っていた。
伊藤先生いわく、日本の高校生が踏み絵を踏まされる「文理選択」は廃止すべきだ、と言う。
高校生の頃、数学が好きだったが、化学や生物は興味が持てず、むしろ社会科学に興味があった。
だから、文理のどちらに行くか悩んだ、という言葉は共感する。
僕も、数学は好きだったし、日本史や世界史や地理はとても好きだったが、物理や化学は正直好きになれなかった。
結局理系に進んだけれど、今でも、歴史の本は好きだからよく借りている。
数学と社会科学の興味の両方を活かせるのが経済学。

経済学は信頼性革命や構造推定により大きく変貌している。
特集記事で曰く。
現代の経済学は、ルーカス批判、信頼性革命、構造推定の3つによって、実証革命が起こり、経済学が公共政策やビジネスに非常に役立つようになった。

僕の理解では、ルーカス批判は、モデルは説明変数とその変数の変化率の2つで考えるべきだ、というもの。
「経済数学の直観的方法 マクロ経済学編 」にも書いてあった。
信頼性革命は、ランダム比較実験で意思決定の結果の良否を説明付けられる、ということかな。
構造推定は、モデルにおける2つの変数の因果関係を明確に説明付ける、ということかな。

相関関係と因果関係は全く違う。
相関関係は、2つの変数に何らかの関係がある事実しかない。
因果関係は、要因→結果という一方向のロジックまで特定する。
このレベルまで経済学が理論付けられるとしたら、すごいことだ。

伊藤先生は学生指導で、既存研究の仮定を疑って検証する発想を持て、とよく言うらしい。
そう、この発想は、自然科学でも文系の学問でも同じだな、と思う。

伊藤先生の博士論文では、消費者が実際に見ているのは限界価格なのか、平均価格なのかを電力市場のデータで検証したらしい。
これはまさに、電力会社のように固定費が高く寡占市場になりやすい市場において、社会厚生を最大にするには、平均費用価格なのか、限界費用価格なのか、という政策論争につながる。

伊藤先生の研究スタイルは、まずは社会にとって自分にとっても大きな問いを立てて、その問題が経済理論でどのように整理できて、どんなデータ分析手法で検証できるか、を考えていく。
この話を読んで、研究者として王道のスタイルだなあ、と思った。
偉大な学者は、とてもシンプルかつ根源的な問題を持っていて、その問題を解くために、色んな方向性から考えたり、レベルを落としたり、寄り道したりして、その過程で数多くの研究成果を残すが、常に根本的な問題を持ち続けている。

経済学の面白い点は、IT革命でコンピューティングパワーが強化されて、大量データの収集と膨大な計算が簡単になったことだろう。
つまり、経済現象を分析するツールが揃ってきた点が、最近面白い点になるのだろう。
そういう背景を踏まえて、信頼性革命や構造推定などの考え方が組み合わさって、経済現象を理論化できたり、政府の政策やビジネスの意思決定に役立てる応用もできているのだろう。

実際、補助金や公共投資はどんな政策であれば効果的なのか、とか、どのようなインセンティブを市場に与えると社会全体として経済効果が波及されるのか、など色んな事例に対して、経済学を適用することができる。

個人的には、経済学の発想をソフトウェア工学に適用したら、どんなことができるのだろうか、と妄想している。


| | コメント (0)

2020/10/06

インフラ構成図やシステム構成図で使えるアイコン集のリンク

インフラ構成図やシステム構成図で使えるアイコン集のページをリンクしておく。

ネットワーク図・システム構成図作成に使えるアイコン集 - Qiita

IT・Networkインフラでのプレゼンで使えそうなアイコン集 | ITnews on the Web

社内ネットワーク図に使えるパワーポイント無料アイコン集 | ビズルート

使える!!構成図に使うアイコン集|インフラタイムズ | ITの実践的な学習ができるサイト

以前、インフラ構成図やシステム構成図はVisioで作っていた時があった。
他には、ジョブ構成フロー図などもVisioだった。
VisioはExcelよりも図が書きやすいのがメリットだった。
しかし、Visioは有償製品であり割と高いのがデメリットだった。

最近、astahでインフラ構成図やシステム構成図を描く方法を教えてもらった。

astahでAWSインフラ構成図が描ける方法がある: プログラマの思索

astahのクラス図で、クラスのステレオタイプにアイコンファイルを取り込むだけなのだが、割と便利。
きれいに描けるのがいいし、astahで全てのモデリング作業を統一できるのもいい。

plantUMLでも同様に、アイコンファイルを取り込めば作図できるが、やっぱりastahが好きなので、astahで試してみる。

PlantUMLでAWSのインフラ構成図を描くやり方: プログラマの思索

| | コメント (0)

2020/10/03

astahでモデルを整理するにはクラスやユースケースの配下にモデルを置く

知人と議論しながら、astahでモデルを整理する方法について、考えたことをメモ。

astahのようなモデリングツールでモデルを書いていると、1個のファイルに何十個ものダイアグラムをたくさん書いて残したくなる。
たとえば、案件で分析フェーズのモデルと、詳細フェーズのモデルは観点や粒度が違うので、それぞれのモデルを区別して管理したい。
さらに、分析モデルと実装モデルをリンクするなどして、関連付けもしたい。

あるいは、複数個の案件を並行で担当していたら、それぞれの案件のモデルを区別して管理し、場面ごとに書き分けたい。
あるいは、過去の案件のモデルを参考にして、別のモデルを描くこともやりたい時もある。

今までの僕は、astahのパッケージを使って、Windowsのエクスプローラみたいに、フォルダ構造でツリー化してモデルを分けていた。
だから、詳細フェーズのモデルはツリー構造が深くなり、探しにくくなったり、分析モデルとの関連付けがやりにくいデメリットを感じていた。

モデリングツールで、たくさんのモデルをどのように管理していくべきなのか、色々考えていた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

知人から教わったことは、astahのクラスの配下に、クラス図やシーケンス図、ステートマシン図を置けること。
同様に、アクター、ユースケース、インターフェイスの配下にも、各種ダイアグラムを置くことができる。
最も驚いたのは、クラスのメソッドの配下にシーケンス図やアクティビティ図を配置できたことだ。

この機能の意味は直感的に分かる。
たとえば、ステートマシン図は、1つのオブジェクトがどのような状態に移るのか、を表しているので、1つのクラスに関連付けられる。
よって、ステートマシン図は、クラスの配下に置くべきだし、その方が直感的に理解しやすい。

たとえば、1個のユースケースに対し、ユースケース記述で業務フローを書くだけでなく、アクティビティ図で描いた場合、ユースケースの配下にアクティビティ図を配置すべきだし、その方が直感的に理解しやすい。

同様に、シーケンス図はクラスの1メソッドの流れを書いたものだから、クラス>操作の配下に置くべきだ。

そういう考え方を徹底すると、下記のようなモデル操作ルールが出来上がるだろう。

(1)分析フェーズでは、ユースケース図を描いて、登場人物とその利用シーンを洗い出す。
 ユースケース1個に対し、業務フローをアクティビティ図で描いて、そのアクティビティ図はユースケースの配下に置く。

(2)分析フェーズでは、概念モデルのクラス図を描いて、必要なクラスを洗い出す。
 クラス1個に対し、オブジェクトの状態遷移はステートマシン図で描いて、そのステートマシン図はクラスの配下に置く。
 クラスのメソッド1個に対し、メソッドの詳細はシーケンス図で描いて、そのシーケンス図はクラスのメソッドの配下に置く。

これにより、ユースケース図>アクティビティ図、クラス図>ステートマシン図・シーケンス図、というモデルの構造が全て階層化できることになる。
この階層化は、各ダイアグラムがどのオブジェクト(ユースケース)の詳細を示しているのか、を明示しているので、一貫した意味でモデルを整理できていることになる。

できれば、astah上で、こういう階層構造とともに、クラス(ユースケース)とダイアグラムの間で相互リンクできれば、要件からモデルまでのトレーサビリティが実現されるので、モデルの意味がより理解しやすくなるはずだ。

モデリングツールの新機能が、モデラーの設計技術を支援するだけでなく、モデラーの思考を刺激して新たな発想を生み出す。
そういう刺激を求めて、モデリングツールのあるべき姿を色々考えてみる。

Astah_arrange_under_class

| | コメント (0)

astahでAWSインフラ構成図が描ける方法がある

astahでAWSインフラ構成図が描ける方法がある、と知人から教えてもらったのでメモ。

【参考】
astah* 上でAWSアーキテクチャダイアグラムを書いてみよう | astah in 5 min

PlantUMLでAWSのインフラ構成図を描くやり方: プログラマの思索

PlantUMLによってコードベースでAWSのアーキテクチャー図を作る方法 - Qiita

astahでAWSインフラ構成図を描く方法は、AWSアイコンをクラスのステレオタイプに設定して、クラス図をインフラ構成図でみなすこと。

astahでAWSインフラ構成図を描けるメリットは、astah上で、アプリ層のアーキテクチャだけでなく、インフラ基盤のアーキテクチャも描けるので、システムのハード・ソフト全てをastahのモデルで一括管理できること。
最近は、クラウド上の開発が多いので、AWSサービスと組み合わせたアプリ開発が多いから、AWSインフラ構成図が描けると、設計モデルが理解しやすくなる。
特に、マイクロサービスが流行している昨今、AWSインフラ構成図をモデルで綺麗な絵として描けるメリットは大きい。

ただし、astahのAWSアイコンを1個ずつ読み込んで設定する作業は手作業しかないので、複数個のAWSアイコンを逐一設定するのが煩わしい。
astahのモデルでAWSテンプレートが提供できると便利なのだが。

暫定方法としては、複数個のAWSアイコンを設定したastahファイルを1個作っておき、それをテンプレートとして別ファイルで保持しておく。
既存のastahファイルでモデリングしている時、astahのマージ機能を使って、AWSアイコンのテンプレートであるastahファイルをマージして取り込むことで、手作業を防ぐことはできる。
最初に、AWSアイコンのテンプレートであるastahファイルを作る作業の1回分だけは我慢すれば、後はマージするだけで使えるようになるので、便利。

plantUMLでAWSインフラ構成図が描けるようになったことと同じように、モデリングツール一つで、アプリもインフラもモデリングできるようにしておきたい。
やっぱり、僕はastahが好きなので、astahでアプリもインフラも描けるようにしておきたい。

僕も今後試してみたいと思う。


| | コメント (0)

plantumlでタイミング図が描けるらしい

plantumlでタイミング図が描けるらしい、と知人から教えてもらったのでメモ。

【参考】
plantumlのタイミング図の構文

僕は業務系なのでタイミング図に疎いけれど、ハードウェア屋さんや組込みソフトウェア屋さんには、タイミング図が欲しくなる機会が多いらしい。
しかし、タイミング図の書き方は、ハードウェア屋さんの中でも、エレキ屋さんや本当のハード屋さん、さらにソフトウェア屋さんでは、微妙に違うらしいので、実際に書くのは難しい時があるらしい。

UML2の仕様では、タイミング図は2つの書き方があると言うのは知っていた。
たぶんその理由は、上記のような理由があるのだろう。

タイミング図を書きたい機会はまだ分かっていないので、色々調べてみたいと思う。


| | コメント (0)

Excelで業務フローを作成するアドオンがあった

オージス総研のHPに、Excelで業務フローを作成するアドオンを無償提供していたのでリンクしておく。
知人から教えてもらった。

業務フロー作成ツール(Activity Diagram Drawing Tool) ダウンロード | オージス総研

操作手順書を読むと、Excelのアドオンとして提供されて、アクティビティ図が描けるみたい。
パレットには、客・外・主・他のようなアイコンもあるので、日本企業向けに適している感じ。

Excelで業務フローが書ける利点は、設計書はたいていExcel仕様書なので、そのままアクティビティ図を埋め込むことができるからだ。
たぶん、外部設計書や要件定義書をExcelで書いている場合、このアドオンは重宝するのではないか。

Excelで業務フローだけでなく、クラス図やシーケンス図、ステートマシン図も簡単に描けるアドオンがあったら、日本のSIの現場では割と重宝されるかもしれない。

ただし、業務フロー図などの保守は面倒になるだろうな。
最初から書き直した方が速いかもしれない。


| | コメント (0)

« 2020年9月 | トップページ | 2020年11月 »