« 2022年8月 | トップページ | 2022年10月 »

2022年9月

2022/09/24

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルが公開されていたので自分用にメモ。

【参考】
CATとは? :: CATマニュアル

TestRail ドキュメント

QualityForward マニュアル

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか: プログラマの思索

TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索

2022年現在、日本で有償のテスト管理ツール導入を考えた場合、上記の3つに絞られるのではないだろうか。
理由は、3社ともに日本の開発元、販売元であるので、サポートを受けやすいためだ。

僕としては本来はOSSのTestLinkを使いたいが、やはり使いにくい場面も多い。
上記3つの有償のテスト管理ツールはUIもよく考えられていて、マニュアル無しでもソフトウェア開発チームならばすぐに導入できるだろうと思う。

個人的印象では、CATとQualityForwardはExcelテスト仕様書のUIイメージに近い。
だから、Exccelのテスト仕様書をWebに置き換えただけ、という感覚で使える。

一方、TestRailは、テストケースを全てWeb上で一括管理するためのツールだ、という特徴を強く押し出している。
Web上でテストケースを追加したり更新したり、Redmine障害チケットと連動したりするUIがすごく使いやすい。
Redmineがチケット管理をWebに置き換えたように、TestRailはテストケース管理をExcelからWebへ完全に置き換えたイメージに近い。

よって、僕の感覚ではTestRailが好きなのだが、やはりテストケースは数千~数万も登録する必要があるので、そのままでは現場で使えないと思う。
そこで、事前にCSVやXMLで大量のテストケースを作り込んで一括インポートし、実行フェーズではTestRailで運用する、というやり方が一般的ではないか、と推測している。
つまり、TestLinkを運用する時と同じように、事前にExcelテストケースは準備し、一括インポートした後、テスト実施管理はTestLinkでやる、みたいな感じだ。

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルをより詳しく読んで理解したいと思う。

| | コメント (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/12

「物理学の野望」の本が分かりやすかった

物理学の野望 「万物の理論」を探し求めて」の本が分かりやすかった。
物理学は、世界のすべての現象を1つだけの考え方で統一して説明しようと頑張っている。

【参考】
物理学は一つの認識論: プログラマの思索

物理学を攻略するためのマップ: プログラマの思索

「小水力発電が地域を救う」の感想: プログラマの思索

その発想の原点は、オッカムの剃刀にある。

ウィリアム=オブ=オッカム

(引用開始)
ウィリアム=オブ=オッカムが云った言葉に「存在は必要以上に増やされるべきではない」というのがある。これは、真理は単純明快なものであり、それを説明するのに余計なことはできるだけ省くべきであるという意味で、「オッカムの剃刀(カミソリ)」と云われている。
この言葉は、一般にある問題についていくつかの解答があった場合、「より少ない原理でより多くの現象を説明できる理論の方がよりよい」ということで、例えば天動説と地動説では、天動説では天体の運動と地上の物体の運動とで別々の法則を立てなければならないが、地動説は両者を一つの運動法則で説明できるから、こちらの方が正しい、と言うように使われる。
(引用終了)

数多くの現象を集めても無意味で、それら現象をより少ない原理で説明されるべき。

物理学の野望 「万物の理論」を探し求めて」ではこんなストーリーになる。

まず、ニュートン力学により、地球の外にある天上の世界を1つの原理で説明した。
次に、物理学者たちは、地上の現象を説明しようと頑張った。
彼らが取り組んだのは、熱、光、電磁気。
熱はエネルギーの一つの要素と分かり、光は電磁波と分かり、電気と磁気は相対する関係と分かった。
そして、マクスウェルの方程式でそれらの現象は統一して説明できるようになった。

そして、電磁気力、弱い力、強い力は最終的に法則で統一された。
最後に残るのは、重力。

物理学の野望 「万物の理論」を探し求めて」には書かれていないが、おそらく超弦理論が4つの全ての力を統一する法則を提供するのだろう。

物理学の野望 「万物の理論」を探し求めて」で興味深かったのは、発電所は、磁気モーターで電気を作り出す仕組みが根本にあり、そのモーターを回す仕組みを○○力発電と呼んでいるだけ、ということ。
たとえば、水力発電、風力発電、火力発電、地熱発電、原子力発電は、磁気モーターをどの力で動かしているか、という違いを表しているに過ぎない、と。
なるほど、たしかにそう考えると当たり前なのだろうが、詳しくないので新鮮だった。


| | コメント (0)

2022/09/10

アトキンソン氏の中小企業再編成論、生産性向上は処方箋を提示していると思う

新・日本構造改革論 デービッド・アトキンソン自伝 | デービット・アトキンソンを読んだ。
アトキンソン氏の中小企業再編成論は、生産性向上は、解決策となる処方箋を提示していると思う。
アトキンソン氏のロジックを理解した内容で書く。
気づきをラフなメモ。

【参考】
「中小企業の生産性向上」が日本を救う根本理由 | 国内経済 | 東洋経済オンライン | 社会をよくする経済ニュース

【1】日本経済が30年以上低成長である問題とその原因について、色んな有識者が数多くの意見を述べてきた。
アトキンソン氏の主張は簡単だ。

日本は少子高齢化社会で人口が増えないどころか減少する時代に入ったのに、従来と同じ仕事のやり方で生産性を上げてこなかったから、GDPが伸びない。
今後の日本は、GDPを増やすよりも、少なくなった人口で生産性を高めて賃金や収入を増やす方向へ変換すべきだ、と。

ロールモデルとなる国は、先進国で唯一人口が増えている米国ではなく、1億人に満たない中堅国である欧州諸国だ。
なぜならば、欧州諸国は人口規模が小さいので、GDPという規模では米国や中国に負けるが、1人あたり生産性、1人あたりGDPではトップクラスにあるから、と。

一方、アトキンソン氏の中小企業再編成論を批判する - 同友館では、中小企業診断士または商工会議所の立場から、アトキンソン氏が主張する中小企業政策を批判しているが、重箱の隅をつついている感じを受けた。

また、アトキンソン氏の「中小企業は再編すべき」という説を徹底検証 | 識学総研でもアトキンソン氏の主張を批判しているが、重箱の隅をつついている感じは同じだった。

【2】アトキンソン氏の主張の一つは、労働参加率は頭打ちなので、労働生産性を高めるべきだ、という内容。
1人当たり生産性は下記の公式で因数分解できる。

1人当たり生産性=GDP/総人口=GDP/生産人口 x 生産人口/総人口=労働生産性 x 労働参加率

労働参加率は失業していない人の生産量に貢献する。
なぜならば、生産人口=総人口-高齢者-子供-失業者(専業主婦や女性なども含む)だから、総人口が減っても、生産人口を増やせば、GDPに貢献する。

たとえば、安倍政権のもとで女性活躍推進政策、70歳までの高齢者の雇用努力政策などを進めることで、女性や高齢者を勤労者として流入させてきた。
しかし、日本の労働参加率は世界的に見てもトップクラスであり、これ以上増やすことは難しい。

一方、労働生産性は働いた人の生産量に貢献する。
つまり、労働生産性は労働者1人当りの年収、時給に相当する。
日本の時給、年収は、先進国の中でも低いレベルなので、伸びしろがあり、ここにテコ入れする価値がある。

アトキンソン氏によれば、2050年頃の日本の経済を今のレベルで維持するには、最低時給は2500円まで上げる必要があるだろう、と書かれていてビックリした。
今のサラリーマンの残業代の時給は正直3千円程度だろうから、それくらいまで増やすべきなのだ。

安倍政権の頃から続く最低賃金引き上げの政策は、会社経営の問題ではなく、経済政策の問題である、という認識を持つことが重要だ。
経済政策であるという認識が、今の日本の経営者にはない。
なぜならば、労働者の収入を増やすことで、労働生産性を高めて、最終的には生産性を高めるべきだからだ。

【3】アトキンソン氏のもう一つの主張は、日本経済が低成長である真因は中小企業が多すぎる点だ。
これが日本病の正体だ、と言う。

実際、中小企業白書を見れば分かるが、企業数の99%、労働者の70%は中小企業に属する。
だから、今までの日本政府は、中小企業を弱者とみなし、数多くの補助金、税制上の優遇政策などを実施してきた。
しかし、その効果があまり出ていないどころから、足を引っ張っている。

【4】中小企業が多いと、経済にどんな悪影響があるのか?

たとえば、会社規模が小さく、財務基盤が弱いので、設備投資しにくい。
工場の新たな機械に投資しないから、生産性は上がらない。
社員教育に投資しないから、社員の能力は伸びないし、社員の給料も上がらない。
ITシステム投資をしないから、消費税の納税、インボイス制度、電子帳簿制度に反対する。
特に、中小企業がIT投資しにくい点は、今後大きな問題になるだろう。

中小企業は会社規模が小さいので、輸出しにくい。
なぜならば、輸出するには一定の資金、ある程度の設備、ある程度大人数の能力ある社員が必要なのに、会社規模が小さく、社員数が少ないので対応できないからだ。
輸出できなければ、外貨が稼げないので、GDPに貢献できない。
特に、2022年度現在、記録的な円安なのだから、もっと輸出していくべきなのに、輸出できる基盤を持つ中小企業が少ないので、その機会を活かせていないのだろう。

【5】中小企業が多くなる原因は何なのか?

たとえば、中小企業は税制上の優遇が多い。
交際費は800万円まで経費とみなされるし、接待飲食費の50%は損金として認められる。
また、補助金の種類も多い。
コロナ禍では持続化給付金がよくあがった。

これらの税制の優遇、補助金の支援は、中小企業が規模を拡大していくインセンティブを失わせる。
本来は、最初は中小企業であっても、事業を拡大していけば、規模の経済を活用するように社員を増やし、設備投資して、どんどん会社を大きく成長していくべきなのだ。
しかし、中小企業という小さい規模の方が、今の日本ではあまりにもメリットが大きすぎるために、あえて中小企業になっているケースが多い。

最近よく聞かれるマイクロ法人は、税制上の優遇を使って経費削減するためのノウハウとして活用されている。
本来はそういう仕組ではないはずだ。

【マイクロ法人設立で節税】個人事業主と二刀流のメリット・違法性を解説

すると、企業数が多くなるので過当競争になりやすい。
つまり、低価格競争になりやすいく、労働者の賃金が抑えられて、労働者の年収も増えない。
むしろ、労働者を低賃金で長時間労働させるようなブラック企業をのさばらせることにつながる。

本来は、そういうブラック企業は市場から退出させるべきだ。
しかし、中小企業を破綻させないように延命させる制度を数多く用意しているために、労働者にとっても都合の悪いブラック企業が残り続けることになる。
だから、最低賃金を上げることで、その最低賃金も払えないような企業は市場から退出させるべきなのだ、というロジック。

今後の日本は少子高齢化で、人口も減っていくので、国内市場はどんどん小さくなっていく。
中小企業の数を減らさない政策を続けると、過当競争に陥りやすく、労働生産性を上げることもできない。
だから、中小企業をM&Aなどで統合していく政策が必要になるだろう。

実際、最近の中小企業が自主廃業するケースが増えているために、中小企業庁も、事業承継やM&Aを積極的に推進する政策を取っている。
また、事業承継士のような資格も出てきていて人気があるらしい。

事業承継センター|資格取得講座・無料ガイダンス

たぶん、今後20年くらいは、事業承継やM&Aの仕事が多くなるだろうと思う。

【6】アトキンソン氏のもう一つの政策は、観光政策を充実させることだった。
安倍政権のもとで観光政策を推進して、2019年には3千万人以上のインバウンド客を取り込んできた。
このおかげで、特に地方は外貨を稼げるようになったように思う。

観光政策を提唱したのはとても良い案だと思う。
よく知られているように、日本は四季の季節ごとに観光地がたくさんあり、神社仏閣も多く、食事も多彩で美味しいし、観光資源が充実しているからだ。
交通の便利さ、Wifiやトイレの設置、英語などの案内などの設備投資を行えば、観光客がSNSで勝手にマーケティングしてくれるので、相乗効果を得やすい。

コロナ禍で観光政策は下火になったが、2022年に記録的な円安になったから、海外から観光客を呼び込めば外貨を稼げるはず。
しかし、昭和の時代に重工業製品やハイテク製品の輸出で外貨を稼いできたのに、平成や令和の時代は観光政策でしか外貨を稼げないのは情けない気もするが。

【7】アトキンソン氏の意見で興味深いのは、日本人は真面目で頑固なのに突然変化するのはなぜなのか?という問題の原因分析。
たとえば、江戸末期の尊皇攘夷と開国の論争では、明治維新になると突然、文明開化に変わり、近代化を推し進めた。
たとえば、太平洋戦争で鬼畜米英と言っていたのに、戦争に負けたら、突然欧米と仲良くなり、高度経済成長を推し進めた。
なぜ、日本人はそれまで頑固に態度を変えないのに、急に態度を変えてしまうのか?

アトキンソン氏によれば、日本人は面倒くさいと思ったからでは、と言う。
つまり、今までのルールや価値観を変えるのは面倒なので、いくら正論を言われても、なかなか変えられない。
ちょうど、総論賛成各論反対の状況と同じ。

しかし、問題が大きくなって手に負えなくなる事態になると、いくら面倒くさいと思っても、状況を変えないと、どんどん状況が悪化して損をする。
つまり、実際に問題が手に負えない時点になると、急に方針転換して、まるで問題がなかったかのように、急激に物事が変わっていくように、どんどん政策が実行される。

戦前の日本人の気質はまだ成熟していない青年期と同じだった: プログラマの思索

一方、欧米人は原理原則、価値観を重視するので、主義主張がマキャベリストみたいに変わることはない。
だから、欧米人は対立が激化したら、戦争が起きやすいタイプなのだろう。

【8】アトキンソン氏の書籍を読むと、経済政策や財務にとても詳しく、統計データを元にロジカルに説明してくれるのでとても分かりやすいと思った。

| | コメント (0)

Javaのモジュールシステムは複雑性をより増している

Java9以降のモジュールシステムについて、探した記事のリンクをメモ。

【参考】
モジュールシステムを学ぶ - Qiita

モジュールグラフが作られる様子を学ぼう - Qiita

Java 9のモジュール機能「Project Jigsaw」の基本を紹介 (1/2):CodeZine(コードジン)

Java 9のモジュール機能「サービス(SPI)」と既存ライブラリの共存 (1/2):CodeZine(コードジン)

Java 9のリリースとこれまでのトレンドを振り返る (1/3):CodeZine(コードジン)

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

(引用開始)
立ちはだかるモジュールシステム
ビルド設定の不備に起因するエラーが増えた

Java 8 以前
「パッケージ...は存在しません」
「シンボルを見つけられません」
java.lang.ClassNotFoundException
java.lang.NoClassDefFoundError
java.lang.NoSuchMethodError

Java 9 以降(上記に加え。。。)
「モジュールが見つかりません: ...」
「パッケージ...は表示不可です」
「パッケージ...はモジュール...で宣言されていますが、エクスポートされていません」
「パッケージ...はモジュール...で宣言されていますが、モジュールfooに読み込まれていません」
「パッケージ...はモジュール...で宣言されていますが、モジュール・グラフにありません」
java.lang.module.FindException
java.lang.IllegalAccessException

(中略)
Java 8 以前のビルドエラーの原因
クラスパスに必要な jar がない
クラスパスに入れている jar のバージョンが間違っている
だいたい、クラスパスの設定を調べれば解決した(要出典)。

Java 9 以降のビルドエラーの原因
設定漏れなどにより、モジュールの解決が正常に完了できなかった
解決されたモジュールグラフが必要な形を満たしていない

モジュールグラフの作られ方を理解していないと、
エラーの原因が特定しづらい(気がする)
(引用終了)

Javaはもはやシンプルなオブジェクト指向言語ではない。
他言語に比較して不足していた機能を次々に取り込んできたために、とても複雑になっていると思う。
モジュールシステムもそうだろう。

以前なら、Mavenで必要なライブラリを管理していたが、それだけでなく、モジュールシステムを使って、どのライブラリを公開するか、必要とするか、という細かい設定ができるようになった。
便利になったように思えるが、これが曲者だ。

以前なら、ビルドパスに必要なライブラリがあるかどうかだけ気にすればよかった。
しかし、モジュールシステムの設定が正しいかどうか、確認する作業まで増えてしまった。

人月の神話」に偶有的な複雑性と本質的な複雑性の話があったが、モジュールシステムは偶有的な複雑性の範疇と思う。
昔のEJB、そしてPOJO、依存性注入などの考え方も、偶有的な複雑性の範囲と思う。

つまり、Javaは本来、コンピュータの内部構造、システムの内部構造を本来は隠蔽して、プログラマがそんな部分を気にせずに業務ロジックの実装に注力できるように整備すればいいのに、そういう部分までプログラマの能力を浪費してしまう部分がある。
とても繊細な積み木をブロックで組み立てている気持ちになる。

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索

モジュールシステムについては色々調べているのでまたメモしておく。

| | コメント (0)

2022/09/04

「Googleのソフトウェア・エンジニアリング」の感想

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセスを読んだのでラフなメモ。


「Google社内でときに言われるのは、「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」ということだ。」という文章がとても印象的。
ソフトウェアの複雑性は、積分された面積で表現されるとすれば、保守性や移植性などのソフトウェア品質特性を維持するために、それをいかに増大させないようにするか、という問題につながる。

そのために、コーディングルール、開発環境、テスト自動化、継続的インテグレーション、継続的デプロイ、テスト環境のコンテナ化、など色んな技術とそのノウハウが出てくるわけだ。

スケールとトレードオフ:「Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス」を読んだ - mamo.memo

Book Talk:『Googleのソフトウェアエンジニアリング』をぼくたちはこう読んだ!(前編)|グロービス・デジタル・プラットフォーム|note


| | コメント (0)

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/09/02

Javaはなぜ関数型言語になろうとしているのか

今のJavaはオブジェクト指向言語である、というよりも、関数型言語になろうとしているように思えた。
ラフなメモ。

【参考】
JavaプログラマのためのIOモナド - kmizuの日記

yasuabe blog: Java8 の Optionalを Haskellの Maybeモナドっぽく使ってみる

Java の語彙で Maybe を説明してみる - ぐるぐる~

JavaでMonadをはじめからていねいに :: Igreque -> Info

モナドについてSwiftで説明してみた - Qiita

モナドとは「メソッド内の副作用の存在を戻り値の型で表現する」ためのデザインパターンです - Qiita

関数型プログラミングなんもわからん。を考えようと言うイベントを開きました。

ラムダ式や関数型インターフェイスは、まあ書けば理解できるが、OptionalクラスやStreamクラスがなぜ必要なのか、正直分かってない。
ネットで漁って、OptionalクラスはMaybeモナド、StreamクラスはListモナドである、という文章を見つけて、そんな難しい構造を持っていたのか、と今頃気づいてる。
StreamのAPIはMapReduceと同じだな、とか。

モナドを支える圏論は大学院のときに代数幾何学の一つの理論として読んだことがあるが、写像を集合とみなして公理系を打ち立てる、ぐらいのイメージしかなくて、プログラミングの観点でモナドがどのように扱われるのか、まだ理解できていない。
今は、モナドとは、メソッドを副作用を持たない関数にした時、戻り値に状態の型のように副作用の型を持たせるとみなして理解している。

普段の業務系Webシステムで、DBにデータを出し入れするぐらいであれば、関数型言語をわざわざ使って並列処理を効率化するようなシチュエーションなんてない。
ロードバランサ、Webキャッシュみたいに、大量のトランザクションを捌くような処理は、正直フレームワークの中に隠れてしまっていて、普通のプログラマであればそんな低レイヤーは気にしないし、気にしないようなオブジェクト指向なフレームワークを作るべきだと思う。

今のJavaはオブジェクト指向言語だけでなく、関数型言語のAPIも追加されているため、非常に膨大で複雑化してしまっているように思える。

なぜJavaは、わざわざ関数型言語のAPIを取りれたのか?
オブジェクト指向言語のAPIで十分なはずなのに。
Scalaの出現とも絡んでいるのか?

たとえば、Scalaの本を読むと、ScalaのAPIはJavaのAPIと非常によく似ている。
ScalaのOptionはJavaのOptionalと挙動が同じ。
ScalaのFutureはJavaのFutureと挙動が同じ。
Scalaのトレイトは、Javaのインターフェイスがdefaultやstaticで実装メソッドを持つようになったのと同じ。
もちろん、map, flatMapなどはScalaもJavaも挙動が同じ。

つまり、ScalaはJavaとかなり互換性があるように思える。
単にScalaがJVMに乗っていて、JavaAPIを呼び出せる事実以上に、言語の思想としてもJavaがScalaに影響を受けているように思える。

気になるのは、Scalaの書籍は2010年頃に大量に出版されたのに、今はあまり出版されていないこと。
人気も下火になったのかな?

「Javaはなぜ関数型言語になろうとしているのか」については調べてみる。

| | コメント (0)

« 2022年8月 | トップページ | 2022年10月 »