astahによるUMLモデリング

2022/11/14

astahとExcelの間でマインドマップをやり取りする方法はコピペだけ

astahとExcelの間でマインドマップをやり取りする方法はコピペだけと分かったのでメモ。

【参考】
マインドマップのExcel出力 | astah in 5 min

マインドマップは個人的にはよく使う。
1日のタスクの洗い出す。
1日のToDo管理は、マインドマップ上でアイコンを付けて、完了、進行中、作業順番、重要度、優先度などを付ける。
提案資料のアウトラインを書き出して、内容を肉付けしていく。
問題分析するときは、問題の症状からロジックツリーのように分解する。
構想を練っている時は、とにかくアイデアを書き出して、枝葉にアイデアを移動したり、つなげたり、まとめたりして、整理していく。
テスト仕様書を作るときは、テスト観点をざっくり洗い出して、機能ごとにばらして細かく書いていく。

そんな内容がまとまったら、やっぱりSIの現場ではExcel仕様書が幅を利かせているので、Excelと行き来できるのは便利。

astahのマインドマップをコピーしてExcelに貼り付けるだけ。
一方、Excelでインデントを付けたテキストをastahに貼り付けるだけ。

このあたりも色々試せるのはいい。

| | コメント (0)

2022/11/06

Go言語でできることは何なのか

Go言語でできることは何なのか、について考えたことをメモ。
全くのGo初心者がいろいろ考えたことのメモ。
間違えていたら後で直す。

【参考】
とほほのGo言語入門 - とほほのWWW入門

Go言語(golang)とは? 特徴・できること・将来性を徹底解説 | 【テックストックMAGAZINE】エンジニア向けスキル・キャリア情報

Go言語にできることってなに?人気の理由をくわしく解説 | 株式会社パソナ(旧パソナテック)|ITエンジニア・ものづくりエンジニアの求人情報・転職情報

Go言語の強みと得意分野を探る(上) - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(中)1 - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(中)2 - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(下) - Go言語の強みと得意分野を探る:Computerworld

Go言語でできることとは?Go言語で作れるアプリの事例を紹介 | プログラミング大陸

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Go言語の書籍を色々読んでみて色々気づきはあった。

Go言語は、マイクロサービスアーキテクチャを実装するプログラミング言語であるらしい。
色々記事を読んでみて、Go言語は、CLIやAPIを作るのに最適な言語であると感じた。

他システムがWebサーバーからデータを取得したり更新しようとする時、APIという公開IFを設けて疎結合な設計にしたい。
Go言語であれば簡単にHTTPでやり取りできるのでWebサーバを立ち上げる必要もなく、普通のクライアントアプリケーションみたいに作ればいい。
また、Go言語では並行プロセスの実装も割と簡単なので、負荷に応じてプロセスを増やせば良く、クラウド上でAPIを公開するためのアプリとして最適。

Go言語でCLIを作るイメージは、Unixコマンドを作るイメージだろうか。
Unixであれば、/binの中に各種コマンドがexeで配置されている。
別システムがバッチ処理をキックしてシステム連携したい場合、CLIという公開IFを叩けば良い。

そんなことを考えると、Go言語はかなり特殊な状況で使うもののように思う。
業務ロジックを実装するレイヤではなく、OSやアプリの間で処理するためのミドルウェア、ないしフレームワークみたいな役割を持つレイヤで実装すべき。

また、Go言語はクラウドと相性がいい。
Go言語はクロスプラットフォームでバイナリファイルを作れるので、CLIやAPIに向く。
また、Go言語で作ったバイナリファイルのサイズを小さくできれば、クラウドのリソースを少なく押さえられる。
また、メソッド呼び出し時のアプリ起動時間を短くでき、並行プロセスで走るアプリの起動時間(ロード時間)も短くできる

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

つまり、Go言語はクラウド上でCLIやAPIを実装したプログラムに特化した言語なのだろう。
だから、マイクロサービスアーキテクチャと相性が良いと言われているのだろう。
そして、マイクロサービスアーキテクチャはドメインごとの境界で使われるので、ドメイン駆動設計とも相性がよく、それらの設計技法と密接に絡む。

そんなことを考えると、一昔前のオンプレ環境でのWebシステム構築で経験されて蓄積されたアーキテクチャ設計技法は古くなっており、クラウドに特化したアーキテクチャ設計技法をもっと探究していくべきだ、という方向性が出てくるのだろう。
このあたりの考え方もいろいろ調べている。

| | コメント (0)

2022/10/21

astah* Mermaid Pluginが公開された

astah* Mermaid Pluginがあるらしいのでメモ。

【参考】
astah* Mermaid Pluginをリリースしました! | astah in 5 min

Mermaid記法の書き方(Markdownテキストでチャート・グラフが描ける) - NotePM

Markdownでシーケンス図とかが書けるMermaid記法で業務フローを書いたら意外とイケたので自分なりのコツを紹介してみる | DevelopersIO

mermaid - Markdownish syntax for generating flowcharts, sequence diagrams, class diagrams, gantt charts and git graphs.

astahにMermaidプラグインを入れてみたら、既存のクラス図やシーケンス図から簡単にMermaid のソースを抽出できた。
Mermaid のソースはPlantUMLみたいに簡単。
直感的に読める。

Mermaid はUMLだけでなく、ER図やガントチャートも書ける。
つまり、設計書の図はMermaid で代用できるし、ガントチャートもMermaid で書いてしまえばいい。

なぜならば、Excel設計書は重たいし、修正に手間取るし、共有しにくいからだ。
設計書はMarkdownとPlantUMLやMermaidだけで、全てテキスト化すべきだろう。
そうすれば、Githubにソースコードと一緒に放り込んで、いつでもマニュアルとしてビルドして納品することも可能だ。
以前、そのようなアイデアも書いた。

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

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

astahには、PlantUMLプラグインも既にある。
Mermaidも一緒に使うと便利かもしれない。

astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索

| | コメント (0)

2022/10/16

クラウド上の開発がJavaに与えた影響は何なのか

クラウド上の開発がJavaに与えた影響は何なのだろうか。
考えがまとまっていないがラフなメモ。
自分はAWSも知らないし、Go言語も知らないので、間違っていたら後で直す。

【参考】
Javaがサーバレスに至るまでの道のり

元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話 - DMM inside

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Javaがサーバレスに至るまでの道のりの記事を読むと、いかに軽量のWebアプリケーションを実現するか、に注力しているように思える。

従来のWebアプリケーション開発では、PerlのCGIのようなプロセス指向ではなく、JavaのServletのようなマルチスレッドの方が無駄にリソースを食わず、効率が良いと歌われていた。

しかし、サーバーレス環境では、AWS Lambdaのようにアプリをキックするような仕組みなので、アプリの処理時間だけでなく、アプリのロード時間も短いほど優位だからだ。
サーバーレス環境では、アプリを常駐させて、マルチプロセスで動く。
そして、処理が終わり、無駄に多くなったプロセスはすぐに破棄される。

つまり、クラウドでは、DockerやK8sのようなコンテナのおかげで、アプリ環境を使い捨てにできるメリットがある。
アプリも、負荷分散に応じて必要なだけ常駐プロセスを増やして、不要になれば捨てればいい。

すると、アプリのビルド、デプロイの時間も短い方がいい。
さらに、「起動時間がレスポンスタイムに含まれる」ために、アプリの起動時間も短くできれば、サーバーレス環境ではレスポンスタイムをもっと短くできて、使い勝手が良くなる。

そういう発想がJavaにどんな影響を与えているのか?
クラウド上の開発がJavaに与えた影響は何なのか?

たまたま、Javaのモジュールシステムの話の中で、jlinkコマンドがなぜ必要なのか?という話があった。
JDK9以後は、JREが配布されないので、Javaファイルを実行できない。
そこでjlinkで実行ファイルを作る必要があるという話だったが、さらにもう一つ興味深い話があった。

Java Module System 入門 その1 - YouTube

Java Module System 入門 その2 - YouTube

jlinkコマンドを使うとランタイム専用アプリを作れるが、必要なJDKライブラリだけを読み込んで、Jarファイルを作成する。
すると、jlinkで作られたランタイム専用アプリのサイズは、従来のランタイム専用アプリのサイズよりもかなり小さくなる。
不要なライブラリを除いているからだ。
実際、デモ画面では200Mから30Mまで小さくできた例があった。

つまり、jlinkコマンドを使えば、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
その分、クラウドのリソースを抑えられるし、アプリの起動時間(ロード時間)も短くできるメリットが出てくる。

すなわち、jlinkコマンドはクラウド上で配布するアプリに適合するように作られたものなのだろう。
Javaもクラウドに特化したアーキテクチャ設計を取り込んでいるのだろう。

そんな話を聞くと、サーバーレス環境のアプリでは、ランタイム専用アプリはバイナリファイルでサイズが小さいほど優位性が高いことになる。
マイクロサービスの実装言語はGoが主流であると聞くが、その理由は、Goで簡単にバイナリファイルが作れて、さらにそのサイズが小さいので、性能的にも優れている点があるのではないだろうか?
そして、Javaもそういう流れの設計手法を取り入れるために、jlinkコマンドのようなアーキテクチャが必要になってきたのではないだろうか?

ここで、クラウド上のシステム設計では、ドメインごとにアプリを細分化したマイクロサービスアーキテクチャが流行していて一般的になってきている。
マイクロサービスアーキテクチャが必要な理由は、普通のWebシステムでもクライアントからのアクセスがブラウザだけでなく、スマホだったりタブレットだったり、色んな端末に対応する必要があるので、公開APIを通じて制御できるよに、色々分割したほうが楽になる点があるだろう。
また、逆コンウェイ戦略のように、システム開発しやすいチーム組織の観点で設計すると、小さなコンポーネントの集まりになるようにシステムを分割して、マイクロサービスアーキテクチャで連携できるようにした方がよい点もあるだろう。

マイクロサービスアーキテクチャのそんな特徴を活かすには、おそらく、Go言語やjlinkコマンドのような実装言語やビルド方法も必要になってくるのだろう。

そんなことを考えると、クラウド上のシステム開発では、フロントWebシステムをRubyやJava、Pythonで作ったとしても、AWS lambdaやマイクロサービスの部分はGo言語やjlinkを使う、といったように、複数のプログラミング言語を適材適所に当てはめて開発する必要性があるのではないか。
つまり、クラウド上の開発は、単にコンテナ部分のアーキテクチャを使いこなすだけでなく、複数のプログラミング言語を適材適所で使い分けるノウハウも必要になってくるのだろう。

この辺りは妄想に近いかもしれないので間違っているかもしれない。
ただ、クラウドというアーキテクチャは、Webリソースをふんだんに使える富豪プログラミングを可能にしたからこそ、それに特化した設計手法がどんどん現れているのだろうと思う。

この発想が正しいのか、これから検証していく。

| | コメント (0)

2022/09/18

「ソフトウェアアーキテクチャの基礎」本はアーキテクトが読むべき本だった

ソフトウェアアーキテクチャの基礎」は良い本と思う。
アーキテクトが読むべき本だったと思う。
ラフなメモ。

【1】ソフトウェアアーキテクチャの定義とは何か?
以前の定義は、ソフトウェアアーキテクチャとは後から変更することが難しいモノだった。
しかし、今は、マイクロサービスの出現により、変化しやすい設計を指すようになって、ガラリと変わった。

【2】アーキテクチャの重要な要素は、トレードオフの決定だ。
品質、コスト、スケジュール、スコープのバランスから、一番最良のものを選ぶ。
それぞれの要素を最大限にするのではなく、トータルでバランスが取れているものを選ぶ。

【3】アーキテクトに期待されている役割。

アーキテクチャ決定を下す。
アーキテクチャを継続的に分析する。
アーキテクチャの最新のトレンドを把握している。
アーキテクチャ決定の順序を徹底している。
様々な技術に精通している。
事業ドメインに詳しい。
対人スキルや政治力を持つ。

【4】ソフトウェアアーキテクチャを語る上で、XPの偉大さがある。

XPでは、プロセスよりも経験的に知られていたプラクティスを重視した。
たとえば、テストが多いほど品質が良くなる経験から、テスト駆動を生み出した。
継続的インテグレーション、コードの共同所有、継続的デプロイなど。

【5】ソフトウェアアーキテクチャの法則は2つ。

1つは、トレードオフが全て。
トレードオフが見つからないならば、分析が不十分な事実を知るべきだ。

2つ目は、HowよりもWhyが大事。

【6】モジュール性とは何なのか?

モジュール分割するアーキテクチャのテクニックの利点は分かる。
しかし、モジュールの実現方法はあまり知られていない、とメイヤーは言った。
この話は、コンポーネント志向につながる。

Javaならば、当初のJDKはパッケージで分割した。
しかし、それだけでは扱いづらいので、Jarというコンポーネントが導入された。
しかし、Jar同士でパッケージ名が衝突する場合があるから、module systemがJava9から導入された。
つまり、Javaもモジュール性の実装方法に苦労している。

【7】本の途中のコラムがとても参考になる。

【7-1】スウェーデンで軍艦ヴァーサ号を製造したが、初めて処女航海に出ようとした時に、すぐに港で沈没した話。

失敗の原因は、アーキテクチャ特性を全部盛り込みすぎて、軍艦が重すぎてしまい、バランスが取れなくなり沈没した。
数多くの利害関係者の要求を最新鋭の軍艦に盛り込んだために、軍艦として実現できなかった。

今のソフトウェアアーキテクチャの話も同じ。
ユーザのたくさんの要望を盛り込みすぎると、結局使い勝手の悪いシステムになってしまうし、それ以前にスケジュールが伸びすぎて永遠にリリースされないシステムになるリスクすらある。

【7-2】ドメイン駆動設計の意義は、境界づけられたコンテキストという概念により、アーキテクチャ設計手法が大きく変わった点にある。

ドメイン駆動設計の出現以前は、組織内の共通エンティティは再利用を重視していた。
しかし、再利用を重視しすぎて、ビルドが困難になり、チーム間の調整が難しくなり、ソフトウェアの複雑さが増大し、多くの問題を引き起こした。
たぶん、ソフトウェアプロダクトラインの話も同じ。

ドメイン駆動設計の出現後、境界づけられたコンテキストの考え方により、各エンティティは局所化されたコンテキストの中で最もよく機能すればいい。
つまり、組織全体の共通エンティティは不要であって、問題領域ごとにエンティティを自由に作り、その中で最適化されたエンティティを作ればいい。
問題領域のドメインの境界上で調整すればいい。
つまり、この考え方がマイクロサービスにつながるわけだ。
マイクロサービスの実装言語はGo言語が主流である。

各ドメイン内のシステムはRailsだったりPythonだったりPHPでもよく、複数のプログラミング言語で作られたシステムとGo言語によるマイクロサービスがAWSのようなクラウド上で動くアーキテクチャが多いわけだ。

【8】コンポーネント設計では、分割の観点は何か?

コンポーネント設計とは、アーキテクチャの分割であるという考え方。
レイヤーアーキテクチャがよく使われる。
たとえば、Javaの依存性注入(DI)、DLLやJarなどのコンポーネント。

この考え方を進めると、開発スタイルはコンウェイの法則に縛られることになり、複雑な組織構造が反映された複雑なアーキテクチャになってしまう。
だから、逆コンウェイ戦略という考え方が出てきた。

一方、コンポーネント設計とは、ドメインによる分割であるという考え方。
これはドメイン駆動設計であり、マイクロサービスアーキテクチャにつながる。

ドメインごとに開発チームを作ることにより、コンウェイの法則のリスクを避けられる。
逆コンウェイ戦略をそのまま実現しやすい。

【9】アーキテクチャスタイルとは、アーキテクチャのパターン集。

モノリシックアーキテクチャと分散アーキテクチャに分かれる。

モノリシックアーキテクチャ:

レイヤーアーキテクチャ →TCP/IPとか。
パイプラインアーキテクチャ →Unixとか。
マイクロカーネルアーキテクチャ →コアシステム+プラグインの構造。Eclipse、Jira、Jenkinsとか。

分散アーキテクチャ:

サービスベースアーキテクチャ →フロントエンド+バックエンド
イベント駆動アーキテクチャ →デスクトップアプリ。非同期システム。
スペースベースアーキテクチャ →ロードバランサー。インフラの仮想化。クラウド。
オーケストレーション駆動サービス指向アーキテクチャ →よく分からない。使われない。
マイクロサービスアーキテクチャ →ドメイン駆動設計とか。

分散アーキテクチャが今の流行だが、8個の誤信がある。
ネットワークは信頼できる。
レイテンシーがゼロ。
帯域幅は無限。
ネットワークは安全。
トポロジーは決して変化しない。
管理者は1人だけ。
転送コストはゼロ。
ネットワークは均一。

他にも、分散ロギング、分散トランザクションなどもある。

これらの観点をトレードオフとして考えるべき。

| | コメント (0)

2022/09/04

GSNや因果ループ図を本番障害のなぜなぜ分析に使うアイデア

GSNや因果ループ図を本番障害のなぜなぜ分析に使えるのでは、と思った。
アイデアをメモ。

【参考】
SysML要求図をGSNと比較する

astah* GSN - Goal Structuring Notation描画支援ツール

astahGSNのメモ: プログラマの思索

astah*の因果ループプラグインがいいね: プログラマの思索

GitHub - snytng/inga: astah* plugin to analyze a usecase diagram as causual loop.

因果ループ図(いんがるーぷず):情報システム用語事典 - ITmedia エンタープライズ

システムのリリース後に本番障害が出ると、必ず原因分析と再発防止策を作る必要がある。
その時の分析手法として、GSNは因果ループ図を使えないか?

本番障害の原因分析にはなぜなぜ分析を使う時が多い。
5回のなぜで深掘りする。
しかし、実際は使いにくい。
なぜなぜ分析する時の観点、フレームワークが事例ごとに個別なので、どこを切り口として深掘りすればいいかわかりにくい。
原因を洗い出してもそれが因果関係として正しくても論拠として浸かるか、本当に真因なのか、疑問が残る。
たいていは、設計書を残らず書く、テスト漏れをなくす、PJメンバーに経験者を入れる、みたいなありきたりな再発防止策になりやすい。

GSNを使う利点は、障害の原因分析の論点、因果関係を明確にしやすいこと。
論拠とデータがセットになっているのもよい。

因果ループ図を使う利点は、悪循環の構造を明確にしやすいこと。
QCDが悪化した状態は、何らかの悪循環のループがシステムとして埋め込まれて、そう簡単には壊せない。
本番障害が出るということは、原因分析や再発防止策をきちんと行わなければ、必ず二度目も起きる。
その構造を浮き彫りにできる。

一方、これらのツールにも課題はあると思う。
GSN、因果ループ図を扱えるツールが少ないこと。
この課題は、astah GSN、astahの因果ループ図プラグインで解決できる。
あるいは、GSNは所詮、ロジックツリー構造なので、マインドマップでも代用できる。

GSNで描くと、20個以上の要素がたくさん出てきて、複雑化しやすい。
ロジカルシンキングと同じで、因果関係はすごく丁寧に書き出す必要があるから、どうしても要素は細かいレベルになりやすい。
すると、20個、50個と要素が出てきて、整理するだけでもかなり手間取る。

因果ループ図は、悪循環の構造を表現する要素をうまく抽出しないと、肝心の解決策を見出しにくい。
ループになっている要素のどこかを変化させることで、ループを弱めたり、別のループを生み出すように解決させていくので、要素が真因であるように見出すのが大事。
実際はそれが難しい。

この辺りは色々アイデアが浮かぶのでこれから整理してみる。

| | コメント (0)

2022/06/17

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンクがあったのでメモ。

【参考】
組み込みUMLでの、分析モデリングでのクラスの識別アプローチについて文献まとめ - 千里霧中

組込みソフトウェア開発と設計をちょっと調べている。
やっぱり設計手法にはUMLを使っている方が僕は理解しやすい。
それに関する書籍のリンクの記事があったので、メモしておく。

【1】組込みソフトウェア開発のためのオブジェクト指向モデリング (組込みエンジニア教科書) | SESSAME WG2

この本はとても分かりやすかった。
湯沸かしポットを題材として、実際にクラス図、状態遷移図まで落とし込んでくれている。
この本の感想は以前書いた。

組み込みソフトウェアの根本問題~対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい: プログラマの思索

【2】リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection) | ダグラス,ブルース, Douglass,Bruce Powel, 博之, 渡辺, 株式会社オージス総研

【3】リアルタイムUMLワークショップ | ブルース・ダグラス, 鈴木 尚志

持っているけど理解できていない。

【4】組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発 (OOP Foundations) | 博之, 渡辺, 和人, 堀松, 政彦, 渡辺, 和記, 渡守武

古本屋で見たことがある。
今度読んで見る。

【5】UML動的モデルによる組み込み開発―分析・設計・実装・テスト | 政彦, 渡辺, 哲史, 石田, 康二, 浅利, 周作, 飯田, 修二, 山本 | Amazon

今度読んで見る。

【6】オブジェクトデザイン (Object Oriented SELECTION) | レベッカ・ワーフスブラック, アラン・マクキーン, 株式会社オージス総研 藤井 拓, 株式会社オージス総研 藤井 拓, 辻 博靖, 井藤 晶子, 山口 雅之, 林 直樹

オブジェクト指向設計のうち、責任の割当に注力して書かれている。

【7】実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 | クレーグ・ラーマン, 依田 智夫, 今野 睦, 依田 光江

僕は第1版、第2版を読んだ。
第1版では「オブジェクト指向設計の肝はコラボレーション図(協調図)です」という一節がすごく心に響いた。
クラスへ責務を割り当てるときに、UML2.0ならコミュニケーション図を書いて、責務が集中しないように疎結合にしたり、関連する責務は集めて凝集度を高くする、などのアドバイスがあった。

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/01/01

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること

ITの地殻変動はどこで起きているのかを2022年現在で考えてみる。
ラフなメモ書き。
特に後半は、ロジックが飛んでいるが、自分のアイデアを書き残すことに重点を置く。

【過去の記事】
ITの地殻変動はどこで起きているのか?~2006年: プログラマの思索

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか・2009年: プログラマの思索

ITの地殻変動はどこで起きているか?~Agile2.0をサポートするチケット駆動開発: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道: プログラマの思索

ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感: プログラマの思索

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代: プログラマの思索

ITの地殻変動はどこに起きているのか~ソフトウェアの複雑さをどのようにして手なづけるか?: プログラマの思索

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ: プログラマの思索

【1】コロナ時代でのソフトウェア事業の問題点

ソフトウェア開発やソフトウェア事業を中核としたIT事業は、2000年頃から大幅に広がり、コロナ時代に入るまでに、GAFAに代表されるように全てのビジネスの中核となった。
ソフトウェアこそが今は、すべての事業の中核システムにある。
コロナ時代になって、対面での営業、対面での人間関係が厳しく制限されて、全ての人間関係がオンライン上で実行せざるを得ない環境に追い込まれて、ソフトウェアはビジネスだけでなく、人々の生活インフラの中核にまで覆い尽くした。

従来の製造業、小売業などの従来型のビジネスモデルは、ソフトウェアを基盤とした事業モデルに大きく変革を強いられた。
それは、業務を単にIT化するだけではない。
単なる業務のペーパーレス化、情報の一元管理が目的なら、コスト削減が目的であり、それはERPというパッケージ製品の導入と同じだ。

では、どんな変革を強いられたのか?
それは、ソフトウェアで作られたシステムを基盤として、企業が提供する価値とそれを購入して消費する顧客をつなげるバリューチェーン全てをシステムで一元管理することだ。
今風に言えば、それはプラットフォームビジネスであり、DXであり、SoEとも呼ばれるのだろう。

全てのバリューチェーンをシステムで一元管理できるとどんなメリットが出てくるのか?
それは、製造業の生産プロセス、小売業の販売プロセス、在庫プロセスという企業内部の情報を一元管理できるだけでなく、販売した顧客の購買履歴や活動履歴をも一元管理することで、顧客関係性を強化でき、顧客の声を生産プロセスや販売プロセスにフィードバックすることで、自社の業務プロセスを改善できるチャンスが増えることだろう。
しかも、アジャイル開発を適用できれば、1ヶ月間というスプリントよりももっと短いサイクルで業務を改善する仕組みさえ作れる。

このDXというソフトウェア基盤にはクラウドというスケールしやすいインフラがあり、MLやDLのようなAI基盤を使って、顧客が望むものを分析し提示することすらできる。
DXを構成する開発基盤や技術が一通り揃ってきたからこそ、すべての事業をソフトウェアで丸呑みして完全に実現できるようになってきた。

事業を一度ソフトウェアで実装してしまえば、アジャイル開発プロセスに従って、いつでも方針の変更が容易になるし、顧客の情報をより簡単に入手できて分析できるから、ビジネスのKPIに適用して、ビジネスそのものの診断ツールにも使える。

しかし、製造業も小売業もその他の業界の事業も全てソフトウェアで実装してしまえばいいだろうが、実際にはその転換は従来のビジネスモデルを構築した企業ほど難しい。
なぜ、ソフトウェア事業へのビジネスモデルの転換は難しいのか?

【2】DXとは「逆コンウェイ戦略を適用する」組織論である

ソフトウェア事業へのビジネスモデルの転換は難しい理由は、ソフトウェア事業に向いた組織を作るのが難しいからだろう。
チャンドラーは、組織構造は経営戦略に従う、と言った。
つまり、ソフトウェア事業に向いた組織構造を構築する必要がある。

一方、コンウェイは、ソフトウェアは組織構造に従う、と言った。
複雑な多重階層構造を持つ組織は、ソフトウェアをより複雑化させる。
人月の法則の通り、ソフトウェアの本質は複雑性にあり、ソフトウェアの複雑性を飼いならすのは非常に難しい。
つまり、ソフトウェア事業に向いた組織構造を作ろうとするが、従来の組織に単にソフトウェア開発を担当させるだけでは上手く行かない。

特に、ソフトウェア開発は、規模の経済が適用しづらく、少数精鋭の優秀な人材の開発チームで実行する方が成功しやすい。
だから、従来の製造業や小売業のように、大規模な設備、大量の人員を用意していても、ソフトウェア開発には向かない。
人月の法則の通り失敗しやすい。

そこで、コンウェイの法則の逆張りを考えて、逆コンウェイ戦略を取ってみてはどうか、という話になる。
つまり、ソフトウェア開発は少人数の開発チームの方が適しているなら、システムの構造に従って、開発チームを構成し直して、そこから組織を作ればいいのでは、となる。
たぶん、今、ScrumがIT企業だけでなく、製造業や小売業など他の業界にも適用されて浸透しようとしているのは、そういう理由があるのではないか。

たぶん、そういう動きは一部の企業に過ぎないだろうが、ソフトウェア事業が中核になれば、従来型の企業もそういう流れに傾いていくのだろうと思う。

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

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

【3】今後の課題は、ソフトウェア事業におけるエージェンシー問題を解決すること

他方、会社という大きな集合体の中で、ソフトウェア事業を委託する人と、ソフトウェア事業を実行するの間には、利益が相反する緊張関係があると思う。

株主や経営者、生産プロセスや販売プロセスに従事する事業部門の人達は、プリンシパル(=委託者)になる。
彼らはソフトウェアやITに詳しくはないので、専門技術を持つエンジニアに、事業のソフトウェア化を実現するために、事業システムの構築を依頼する。

一方、エンジニアは、プリンシパルのために代理で活動する代理人をエージェント(=受託者)になる。
彼らは、ITの専門家として、プリンシパルの目標や要望を聞き出し、彼らの期待を実現する為に働く。
彼らは、事業のソフトウェア化を実装するために、業務システムだったり、Webシステムだったり、スマホアプリだったり、機械学習基盤だったり、クラウド基盤だったり、いろんなソフトウェア基盤を構築してリリースする。

しかし、経営学で習ったプリンシパル=エージェント理論では、エージェントがプリンシパルにとって望ましい行動を行わないというエージェンシー問題が必ず発生する。
一般に、エージェンシー問題が生じる要因として、「プリンシパルとエージェントの利害の不一致」と「情報の非対称性」の2点がある。

組織運営支援|マーサージャパン

ソフトウェア事業でも、委託する人達はシステムのことが分からないので、結局は、委託者であるSIの言いなりになってベンダロックインされやすい。
製造業や小売業などの発注者も、システムのことは分からない、システム開発をコントロールする難しさは体験済みなので、一括請負契約を結ぶことでシステム開発リスクをSIに全て押し付けようとするが、どうやってもベンダロックインされやすい。
その理由は以前書いた。

一括請負契約はソフトウェア開発にやっぱり向いていない: プログラマの思索

【4】ソフトウェア事業におけるエージェンシー問題を解決するための組織構造とは何か?

従来型の生産プロセスや販売プロセスを持った事業をおなっている会社が、ソフトウェア事業を中核に据えようとする場合、下記のようなイメージで、ホールディングスの持株会社を作り、親会社と事業子会社とシステム子会社がそれぞれ役割分担と制御構造を持つ必要があると考える。

親会社(ホールディングス会社)の役割は、企業グループの全体戦略を策定することだ。
その全体戦略に従って、個別の事業の戦略を策定し、その事業に必要なIT戦略、つまりシステム投資の計画を策定する。

事業子会社は、親会社が策定した事業戦略に従って、その事業に合った業務プロセスを構築し、その業務を実行する。
事業を支える業務には、業務システムが使われるため、自分達の事業に合った業務システムの要求や要件をシステム子会社に提出したり、一緒にIT計画を策定することになる。
事業子会社の成績は、事業のROIで測定されるので、事業のROIを親会社に毎年報告することになる。

システム子会社は、親会社が策定したIT戦略に従って、個別の事業を支援する業務システムを構築し、保守していく。
彼らは、事業子会社の事業戦略に従って、いつまでにリリースする必要があるのか、どれだけの開発予算が必要になるのか、をシステム計画としてまとめて、システム計画を事業子会社と親会社に承認してもらってから、実行に移すことになる。
つまり、システム子会社の主な仕事は、事業を支える業務システム構築とその保守になる。

ここで重要な点は、事業は外部環境や市場の変化によってどんどん変わるので、事業を支える業務システムは一定期間しか使われないという前提で、リプレースする期間と計画を事前に策定する必要がある点だ。
たぶん、減価償却が5年間という制約条件とか、外部環境の変化で事業の寿命は5年とか、そういう単位で、業務システムは定期的に破棄されて、新規に再構築されるように計画しておく。
そうすれば、事業小会社の事業では、たとえば5年おきに新しい業務システムに支えられるので、その時代の最新技術が使えたり、その時代の要件に合ったシステムを使えるようになる。

このように、定期的にシステムはリプレースすべきだ、と親会社も事業子会社もシステム子会社も事前にIT戦略に埋め込んでおけば、時代の変化にあった事業に対応できるはずだ。

さらに、上記のような三者の組織構造があれば、システム子会社は親会社や事業子会社に定期的に報告する義務が生じることで規制をかけられるし、システム構築の目的が親会社や事業子会社の要件に合うように考えさせられるので、システム子会社が暴走するリスクも小さくなるだろうと思う。

【5】事業を支えるシステムの企画は誰が責任を持つのか?

一般の日本企業では、メーカーであれ、ユーザ企業であれ、SI企業であれ、予算駆動だから、システムが必要になったら、その企画フェーズが必要で予算取りの根拠を作らねばならない。
では、その企画フェーズを担当する最終責任者はいったい誰なのか?

ソフトウェアPJの企画フェーズの責任者は誰なのか?: プログラマの思索

本来は、システムの企画フェーズでは、親会社や事業子会社が主導権を持って、事業に必要なシステムの要求や要件を企画すべきである。
なぜなら、彼らが使いたいシステムなのだから。

しかし、僕の経験でもそうだが、ITやシステム開発を経験していない人達がシステム企画を担当すると、割と揉める。
いろんな要求や要件は出てくるが、その時代に合ったIT技術を組み合わせて、品質・コスト・スケジュールのトレードオフに落とし込む作業が難しいのだ。
結局、システム子会社を持たない発注者は、SIやITコンサルに丸投げして、だめなシステムを計画してしまいがちになる。

システム子会社を持っていても、彼らがソフトウェア開発部隊を持っていなかったり、クラウドやAIなどの新技術に関するソフトウェア開発の経験がなければ、SIベンダに丸投げするリスクがある。
結局、企業グループの中核にシステム子会社を持ち、彼らが一通りの技術力を常に研鑽しておかなければならないのだ。

だから、システム子会社の開発者が企画プロセスに入り込んで、彼らが主導権を握る場合が多い。
そして、親会社・事業子会社のユーザと、システム子会社の開発者の間で、対立関係が発生する時もある。
AsIsはユーザが詳しいが、ToBeはユーザでは作りにくい。
開発者がToBeを作ることが多いが、ユーザが果たして納得してくれるのか?

こういう問題にどう対処するか?
たとえば、匠メソッドの匠モデルではこたつモデルを持ち出す。
ユーザ・開発者・営業担当者がいきなりToBeモデルを作る。
事業側も開発側も同じゴールを目指すべきという思想で対応するからだ。

たとえば、Scrumでは、プロダクトオーナー1人が企画プロセスを担当するだろう。
プロダクトオーナーがいるおかげで、開発チームは彼を頼りにしてシステム開発に専念できるはず。

Scrumではどのプロセスを誰が担当するのかが明確ではないかと思う。
企画:ProductOwener
開発:Team
プロセス全体の守護神:ScrumMaster
という仮説も成り立つ。

それから、システムはリリースしておしまいではない。
システム投資の予算を立てて投資するのだから、投資対効果もIT計画に盛り込んで、リリース後に半年後、1年後に実際にROIが予定通りなのか検証したい。
そうしなければ、次のリプレースに活かせないからだ。
また、システム投資のROIを測定する作業をシステム子会社に課すことで、彼らにROIの意識付けもできるようになる。

システムの投資対効果(ROI)を検証するプロセスはどんな構造になるのか?

GoalやToBeでは、システム構築の目的にROI向上(工数削減、経費削減、売上向上)があるはず。
たとえば、システム化することで、手作業から自動化されて工数が削減される。
ペーパーレス化されて、経費が大幅に削減される。
システム化されて、新規顧客に利用してもらって、売上拡大を図る。
そんな内容がROIになるだろう。

稼働後に検証しなければ、一連のPDCAが回らない。
投資対効果=ToBe-AsIs で測定することになる。

企画プロセスでToBeを定めているので、リリース後に実際に、工数や経費、顧客数と売上を測定して、その差分を見ればいい。
もちろん、リリースが遅れると、その分、投資対効果が得られる期間が先延ばしになるので、メリットが薄くなる。
システム構築のコストが増えれば、もちろん投資対効果は薄れるし、使いづらいUIだったり、処理が遅かったり、まともに動かないシステムだったら、投資対効果はゼロかマイナスになってしまうだろう。

【6】こういうホールディングス会社、3社の企業構造をもたせれば、ソフトウェア事業におけるエージェンシー問題をかなり和らげて、エージェントであるシステム子会社が暴走したり、システム構築の目的を忘れてしまうリスクを減らせるのではないだろうか?

逆に言えば、IT計画策定やROI測定などの仕組みを課さないと、事業を支える業務システムを構築できないのではないだろうか。

| | コメント (0)

チケット駆動開発のプロセスと開発基盤を再考する #Redmine

チケット駆動開発のプロセスと開発基盤を書き直してみた。

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine: プログラマの思索の図を改良している。

チケット駆動開発は基本的に、ScrumやXPに似たアジャイル開発のプロセスと同一視される。
なぜなら、ロードマップをScrumのスプリント計画、XPのイテレーション計画とみなして、リリースサイクルに従って定期的にリリースされる仕組みとみなせるからだ。
つまり、チケット駆動開発は小規模リリースを実現するプロセス基盤でもある。

他方、チケット駆動開発というプロセスから発生する情報は、チケット管理ツールに全て集約される。
チケット駆動開発プロセスは、チケット管理システムに支えられて実装される。
チケット管理システムの構造は、Input,Process,Outputという単純なプロセスから成り立つ。
中核となるPMISは、フロー管理とストック管理という2つの機能を持つ。

フロー管理の機能は、チケット管理、チケット集計、ロードマップ、ワークフロー管理などがある。
つまり、チケットは流通媒体であり、ステータスに応じてサクサク流れる。
チケット集計には、ガントチャート、カレンダー、かんばんなどがある。
ロードマップとチケット集計を区別したのは、ロードマップがScrumのプロダクトバックログに似た機能であり、スプリント計画あるいはイテレーション計画で使われる重要な機能だからだ。

ストック管理の機能は、チケット管理、SCM連携、Wiki、トレーサビリティなどがある。
つまり、チケットは記録媒体であり、作業履歴や課題の内容、障害管理票などの帳票として記録される。
ただし、記録される媒体はチケットだけでなく、Wikiもあるし、GitやSVNなどの構成管理ツールにもある。
これらの情報と相互リンクすることで、チケット管理ツールにすべての情報が集約されて、ナレッジ基盤になる。

チケット駆動開発はプロセスであるから、処理が主人公になる。
一方、チケット管理システムは機能から構成されるので、機能を通じて記録されるデータが重要になる。
そのデータの特徴はフローでもありストックでもある。

チケット管理システムは、チケットにフローとストックの両方の意味を故意に持たせることで、幅広い運用が可能になる。
ある側面では、タスクかんばん上でステータス管理できるし、ある側面では、そのタスクや課題のチケットには、数多くの情報が記録されているし、その変更履歴も記録されているので、経緯や意図を把握できる。

このチケットの二重性という特質がチケット管理ツールに豊かな機能や利用シーンを生み出してくれるのだ。

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

| | コメント (0)

より以前の記事一覧