Friends of astah*になりました

このたび、Friends of astah*になりました。
とても嬉しいです。

【参考】
Friends of astah*

振り返ると、自分は10年以上前からastahを使っていたんですね。

【再考】GanttProjectとFreeMindとJude: プログラマの思索

astah*Professionalファーストインプレッション: プログラマの思索

本格的にastahを使い始めたのは、Redmineによるチケット駆動開発の開発プロセスをUMLで分析してみよう、と思い立って色々描いていた時。
その頃は、アクティビティ図とステートマシン図、配置図がメインだった。

我流のプロセス分析をしながら、色んな気づきがあった。
たとえば、プロセスの例外処理はJavaやVBスクリプトの例外処理に似ているなあ、と思った。
また、プロセスが複雑な理由は組織の構造や権限をそのまま反映しているからだ、と気づいた。
つまり、コンウェイの法則そのままじゃないか、とか。

また、要件定義でシステム構成図、機能構成図、業務フロー、データモデルを書きながら、それぞれのダイアグラムにトレーサビリティという関連があること、粒度を保ちながらレイヤ化という思想で詳細化していく、という発想も身を持って体験できた。

こういう体験は、モデリングツールがあったからこそ、できたのだろうと思う。
なぜなら、Excelやパワポで絵を描くと、ちょっとしたレイアウト変更だけで労力を費やして、本来明示したい設計思想を忘れてしまいがちだから。
また、ダイアグラムを試行錯誤して描くことで、複数の観点でモデルを分析することが自然に身に付くし、各ダイヤグラムのトレーサビリティや粒度を気にするようになるから。

一般に、日本企業では、設計書は日本語という自然語で記述するのが普通。
しかし、日本語では主語が明示されていない、構造が明確化されていない、などの弱点があるので、いくら詳しく書いても必ず漏れる。
巻物みたいなExcel設計書をたくさん書いても、その後のマイグレーション案件では役立たない。

むしろ、A3の1枚用紙に描いたシステム全体概要の方が役立つ時もあったりする。
そんな経験もあって、自分の理解も深めるために、astahを重宝している。

しかし、astahも10年以上使っていると、こういう機能も欲しい、という思いも強くなってくる。
そんな思いも書いてみた。

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

また、XPJUG関西メンバーの後押しもあり、astah関西というコミュニティも立ち上げてみた。
来年度も、Redmineコミュニティと合わせて、色々活動してみたいと思う。

astah関西 第1回勉強会 - connpass

個人的には、ソフトウェア工学の実験ツールであるRedmineと同様に、astahも、ツールがモデリング技術の可能性を高める部分が沢山あると思っている。

ツールがプロセスを改善していく。
ツールが開発プロセスに新たな利用シーン、想定していなかった副次効果をもたらす。
ツールがモデリング技術の新たな可能性を開拓していく。

そんなアイデアを色々考えてみたいと思っている。