ソフトウェア工学

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/04

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

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


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

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

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

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


| | コメント (0)

2022/07/30

テスト管理ツールTestRail、CAT、QualityForwardの感想

テスト管理ツールに触った経験が少しだけあった。
TestRail、CAT、QualityForwardの感想をラフなメモ。

【参考】
テスト管理ツール TestRail | ソフトウェア品質保証 | テクマトリックス株式会社

CAT | テスト管理ツール | 株式会社SHIFT

テスト管理ツールQualityForward|ソフトウェアテスト・第三者検証のベリサーブ

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

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

脱Excel! TestLinkでアジャイルにテストをする:エンジニアがお薦めする 現場で使えるツール10選 - @IT

SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス~日本の品質管理技術を見直そう」

ETWest2009講演資料「TestLinkでアジャイルにテストする」

【1】欧米製のテスト管理ツールと日本製のテスト管理ツールでは、やっぱり発想が全く異なる。

TestRailはドイツ製。
テストケースは全てWeb上で管理する。
Excelのテスト仕様書は完全に廃棄される。

だから、TestRailではWeb上のUIが非常に使いやすい。
テストケースをツリー構造で表したり、Redmineの障害チケットと連携したり、テストケースをフィルタリングするのがやりやすい。
UIはTestLinkよりもはるかに使いやすい。

一方、CATやQualityForwardは日本製。
Excelのテスト仕様書をそのままインポートして、UIもExcel上のテストケースと全く同じ。
たぶん、従来の日本のソフトウェア開発チームならば、普段はExcelでテストケースを管理しているので、運用しやすいだろう。

【2】TestRailとCATやQualityForwardの大きな差は、テスト集計機能の有無にあると思う。

CATでは、SubversionやGitと連携する機能があるのでソースコード行数を保持できる。
だから、テスト密度、バグ密度を表示する機能もある。
また、信頼度成長曲線、PB曲線も表示してくれる。
つまり、日本のSIが品質管理で使いたいと思う機能は、一通り実装されている。

QualityForwardでも、PB曲線は表示される。
またカバレッジパネルという機能もある。
これは、テストケースの項目別集計に対し、テスト結果の割合を表示して、どれくらいテストを消化したのか、バグが多く出ているのか、などを表示する。

一方、TestRailでは、テスト集計機能はほとんどない。
テスト結果の状況を表示するサマリ画面はあるので、テスト状況をさらに細かくドリルダウンすることはできる。
また、バーンダウンチャートもあって、テスト時間を計測すれば、予実で表示されるみたい。
しかし、基本は、REST APIでBIツールに取り込んでもらうか、CSV出力して自分で集計してもらうことが必要。

【3】こういう内容を書くと、日本製のテスト管理ツールの方が良さげに見えるが、僕はTestRailの方が使いやすそうに思えた。

実際に画面に触れてみれば分かるが、TestRailの方がRedmineのようなUIに近い。

TestRailのマイルストーンは、Redmineのバージョンと同じ。
TestRailのテストケースは、Redmineのチケットと同じ。
そうみなせば、Excelのテスト仕様書はいらない。
そもそも、Redmineを使い始めたら、ExcelでWBS管理や課題管理はやらなくなる。
それと同じ。

日本製のテスト管理ツールにはテスト集計機能があるので、色々使えそうと思ったが、罠も多い。

まず、テストケースや障害チケットの粒度を揃えたり、テストケースや障害チケットの分析項目を標準化したり、集計する以前の前処理にすごく手間はかかる。
本来は、テスト作業やテスト成果物は標準化できていればよいが、やはりシステムごと、案件ごとに微妙にカスタマイズされているので、その辺りに規制をかける必要がある。

また、信頼度成長曲線をツール上で表示する時、障害チケットをインポートするタイミング以降でしかグラフを表示してくれない。
つまり、テストを始める前に、テスト管理ツールとRedmineを連携しておく必要がある。
テスト途中でRedmineと連携する設定を行うと、インポートする日以前のバグ発生数のグラフが表示されない事象が発生する。
なぜそんな仕組みなのか分からないが、Redmineチケットのカスタムフィールドをテスト管理ツールに取り込めないケースもあるし、信頼度成長曲線のグラフで表示したい日付情報をチケットのカスタムフィールドで対応できないケースもあるからだろう。

テスト密度やバグ密度も表示されるのは便利だが、結局、そのデータの妥当性を精査する必要があるし、テスト密度やバグ密度が基準範囲から外れていれば、細かく原因分析する必要がある。
よって、ツールで集計されたデータをそのまま鵜呑みにはできない。

そんなことを考えると、テスト管理ツールもRedmineと同じく、テスト管理の予定と実績を蓄積するのに専念し、テスト集計機能はBIツールを使ったり、自分でExcelやRで集計するように、作業を分離した方が良いと考える。
集計して分析する作業はどうしても標準化できないから。

【4】まとめると、TestRailはExcelのテスト仕様書を完全になくしてWeb上で完結する。
Redmineライクな感じ。

一方、CAT、QualityForwardはExcelのテスト仕様書をそのままインポートできるので、ExcelをWeb上で触っている感じ。

たぶん、日本のIT企業のテスト管理や品質管理は機能の網羅性テストを重視していて、欧米のIT企業のテスト管理は機能の充足よりもいちはやくリリースできる品質を担保する観点を重視する、という違いが出ているように思えた。
この辺りに、日本人の品質管理の思想と欧米のアジャイルな品質管理の思想の違いを感じる。

とはいえ、テスト管理ツールは発展途上のツールと思うので今後も見ていく。

| | コメント (0)

2022/06/29

メトリクス分析のコツは良いIssueを見つけること

メトリクス分析のコツは良いIssueを見つけることと思う。
ラフなメモ。

【参考】
DXの本丸は「データ」にあり 「問い」からはじめるデータ分析とその活用法 - ログミーBiz

データ分析から導き出す「強い野球チーム」のつくり方 映画『マネーボール』で学ぶデータサイエンス - ログミーBiz

akipiiさんはTwitterを使っています: 「ソフトウェア工学のメトリクス分析の考え方にも適用できるので参考にする。データ分析から導き出す「強い野球チーム」のつくり方 映画『マネーボール』で学ぶデータサイエンス - ログミーBiz https://t.co/ZmCzuVEIUy」 / Twitter

akipiiさんはTwitterを使っています: 「データ駆動はイシュー駆動。良い問いが解決策を生み出す。メトリクス分析も同じだな。DXの本丸は「データ」にあり 「問い」からはじめるデータ分析とその活用法 - ログミーBiz https://t.co/XRe7ceo6u0」 / Twitter

【1】問題解決を図るときに、定量データを扱うのは有効だ。
最近は、Webログやスマホ履歴のようにビジネスの副産物として簡単にデータを集められる。
すると、溜まったデータをいかに活用するか、が大事になる。

『マネーボール』という映画では、貧乏球団が強いチームを形成するのに必要な問題は、「出塁率の最大化」だった。
そこに問いの価値がある。
選手の人間性、選手の組み合わせ、とかそんな観点の問題ではなかった。
問いを「出塁率の最大化問題だ」と立てられたら、あとは、バッター個人のデータを分析して、確率論に持ち込めばいい。

つまり、良い問い(Issue)を把握するのが大事。
良いIssueは数字で答えたくなる。

良いIssueを探るには何が必要なのか?

顧客行動の理解ならカスタマージャーニーを使う。
お客さんがその商品を購入したいと思うタイミングとか、ファンになるまでのステップごとに定量データを集めて分析する。
そうすれば、どこでユーザが離脱するのか、どこでユーザの満足度が低いのか、が浮き彫りになってくる。
これを業務システム開発に置き換えれば、一連の全体の業務フローを描いて、それぞれのステップごとに分解することになるだろう。

次はこれをどうやって定量化していくか?

KPIツリーによる指標分解を使う。
売上=客数x客単価。
顧客数を=認知人数×購入率、みたいに分解していく。

掛け算か足し算で異なる。
掛け算では、2つの指標を独立だとみなす。
足し算はセグメントに分ける。

基本は、カスタマージャーニーマップのステップごとにKPIツリーで分解していく。
この辺りのプロセスは、ECサイトの分析であるAARRRの手法と全く同じ。

【2】ソフトウェア開発プロセスのメトリクス分析でも、同じような考え方を適用できる。

たとえば、WF型開発のPJであれば、工程ごとにゲートがある。
各ゲートに着目してQCDの観点でメトリクスを作ることはできる。

では良いIssueとは何なのか?
Issueをどうやって解決するのか?

良いIssueを見つけるのが大事。
イシューから始めよ」の通り、質よりも量で頑張ると、生産性が非常に悪い。
大量にアウトプットを出しても、正解にたどり着くルートはせいぜいそのうち5%ぐらいしかない。
そうならば、事前に本来のIssueを絞り込んで、生産性を高めるべき。

メトリクス分析では、良いIssueを立てて、そこからKPIツリーで分解した各要素のどこにインパクトがあるのか、を見るのが大事。

| | コメント (0)

2022/06/19

プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある

とある勉強会で、プロセス設計はどの範囲を指すのか、を議論した。
自分の考えをメモ。
ラフなメモ書き。

【参考】
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想~CTOの役割とは何ですか?: プログラマの思索

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

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

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

プログラマとスクラムが社会実装を変えていく #Findy_GovTech: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

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

ソフトウェア・ファーストの感想: プログラマの思索

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール: プログラマの思索

【1】プロセス設計とは何か?

「SEはプロセス設計する能力が必要」と清水吉男さんは言われていたと思う。
PJ計画時に、担当SEは担当PJでどんなプロセスが必要でどんな成果物が必要なのか、を明確にすべき。
なぜならば、システムの特徴、PJ特性に応じて、プロセスや成果物はどのPJでも微妙に異なるからだ。
それを不明確なまま進めると、じきにプロジェクトの運営がうまくいかなくなる。

イメージとしては、XDDPならばPFDというDFDを描いて、プロセスと成果物のデータフロー図を描くものと思う。

【2】プロセス設計の考え方は標準から各PJへのテーラリングが基本

では、プロセス設計とはどんな構造を持つのか?
きちんとしたSIであれば、社内に標準プロセスがあり、それを担当PJごとにテーラリングしたサブプロセスを定めることになる。
つまり、「プロセス」クラスと「サブプロセス」クラスという型が継承関係にある。

プロジェクト計画が確定すると、「サブプロセス」のインスタンセスが生成される。
PJ実行フェーズで、プロセスのインスタンスをもとに、具体的な成果物(たぶん、設計書などのExcel帳票)が作られていく。

つまり、プロマネは担当PJの特徴、システム特性に応じて、標準プロセスをテーラリングないしカスタマイズする自由度は許されている。
ここにプロセス設計の能力が必要とされる。


【3】プロセス設計の範囲は、PMO事務局とプロマネで異なる

では、プロセス設計の範囲はどこなのか?
(1)プロセス設計とは、プロセスインスタンスから標準プロセスへ抽象化する手法?
(2)プロセス設計とは、標準プロセスをプロセスインスタンスに具体的に実現する手法?
(3)プロセス設計とは、標準プロセスからサブプロセスへテーラリングする手法?

僕の考えでは、プロセス設計の範囲は、PMO事務局とプロマネで異なる。

全社横断的PMO事務局は、社内の案件に対し、標準プロセスを定めたガイドラインを定義し、その推進活動を担当する。
PMOの作業範囲は、「プロセスというクラス」の部分で標準プロセスの型をガイドラインで定義し、各案件のPMには、標準プロセスは守ってもらうことになる。
一方、プロマネには、PJ特性に応じて成果物やプロセスを取捨選択したりカスタマイズしてテーラリングする。

つまり、PMOが担当するプロセス設計の作業範囲は「プロセスというクラス」になる。
なぜならば、標準プロセスを定めたガイドラインの保守改訂はPMOの範疇だから。

一方、案件のプロマネの作業範囲は「サブプロセスというクラス」でPJのテーラリングを行ったプロセスを取捨選択ないしカスタマイズして決めて、PJ計画の活動で具体的なプロセスと成果物(たぶんExcel帳票)を確定すること(プロセスインスタンス)になる。
なぜならば、プロセスをテーラリングして詳細化する作業は、プロマネの担当だから。

【4】テーラリングはどのように評価されるのか

実際の現場では、PMOとプロマネの間で対立はある。

PMOは、ガイドラインがベースラインなので基本はPMに守ってもらうことが最優先であり、実際の案件とのギャップがあれば、それは吸い上げて真因を深掘りする作業を担当する。
テーラリングの自由度は許される範囲内でプロマネにあるから、プロマネの説明の根拠を一つずつ確認して、問いただしていく作業が必要がある。
実際は、そのテーラリングの妥当性で揉めることが多い。

たとえば、プロマネが案件の予算を申請する時、役員を含めた経営陣やPMO事務局が投資計画の内容を精査して、案件の予算確保と実行承認を決定するだろう。
その時に、会社標準のプロセスに即して投資計画を立案しますが、基本はテーラリングが必ず入る。

テーラリングの例としてはこんなものがある。

・標準では許されない工程の重複や統合、省略を許す
・標準化されていない開発方法、技術を適用する
・メトリクスの許容値を調整したり、代替メトリクスを計画する

たとえば、SAPのようなパッケージ製品の導入であれば、すでに開発プロセスがベンダ製品に埋め込まれている。
社内標準とは異なるベンダ製品のプロセスを社内の体制で実行できるか、などをPMが経営陣に説明する必要がある。

あるいは、機械学習の開発基盤を導入する案件であれば、標準化されていない開発手法を適用することになる。
開発リスクを見込んだスケジュールを作っているか、コストを見込んでいるか、をPMが経営陣に説明する必要がある。

あるいは、品質基準を変更してPJ用にテーラリングしたならば、品質基準を変更した妥当性の根拠をPMが経営陣に説明する必要がある。

プロマネが作った投資計画書やPJ計画書をレビューして、細かく精査すると、コストの妥当性、開発リスクの検討、品質基準の設定が甘い時も多い。
そういうレビューを通じて、投資計画の精度を高めるし、プロジェクト実行時の各ゲートレビューでPJの実行状況をPMOがモニタリングしてチェックすることになる。

【5】とは言え、プロセス設計とその評価プロセスの質は、SIであってもユーザ企業であっても、バラつきが多い。

システムの有効性を知りたい経営者、利用ユーザなどの第三者であれば、こういう仕組みがしっかりしていると、安心してシステム開発を任せられる。
たぶん、日本政府のデジタル庁が目指しているあるべき姿も、この辺りの内容に近いのでは、と推測する。
なぜならば、内製部隊を持てない場合、ベンダに委託する必要があるが、こういうプロセスの仕組みをしっかりすることで、ベンダから提供される成果物が標準化できるし、社内でもユーザ要求や仕様をまとめる能力が高まるし、最終的にベンダロックインを防いだり、プロジェクトの進行状況を適宜チェックする仕掛けができるからだ。

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

| | コメント (0)

2022/06/05

「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする

「大人の学びパターン・ランゲージ」はリスキリングの参考になると思った。
IPAの同じWebページにある「学び続けている実践者の方からお話を伺いました。」というインタビュー記事もとても良い。
読んでみて、自分の中で色々考えるものがあった。
ラフなメモ。
間違っていたら後で直す。

【参考】
大人の学びパターン・ランゲージ(略称まなパタ):IPA 独立行政法人 情報処理推進機構

変革への道:IPA 独立行政法人 情報処理推進機構

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

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

【1】社会人になって「学ぶ」とはどんな意義や問題点があるのだろうか?

日本人なら大学へ入る18歳までは受験勉強という公式な体制の元で勉強させられる。
学びとは何なのか?という基本的な問いを考える作業は、この期間は無意味だ。
むしろ、希望大学に入学することが自己目的化している人ほど、受験競争の勝者になる。

一方、社会人になると、急激に能力を伸ばす人と、停滞する人の2種類に差別化される。
案件に揉まれて技術やマネジメントの経験を身に着けて、どんどん昇格して、社会的地位が上る人もいれば、職を転々としながらも何も変わらない人もいるし、同じ企業の中でずっと何も変わらずに仕事している人もいる。
人はそれぞれの目的を持って生きているように仕向けられる。

そういう状況の中で、現代という時代では、20代で身につけた知識や技術がすぐに陳腐化するリスクに常につきまとまれている。
特に、IT技術を身に着けても、それは10年後には当たり前になり、差別化できる要因ではなくなる。

すると、30代、40代、50代と年齢を経るごとに、自分が活躍できるステージをどんどん変えていく必要性が出てくる。
単純な専門的知識で差別化するよりも、チームや組織、企業を回すようなマネジメント、経営への領域へ移す人達も多い。
人との関わりという部分で差別化しようとする。

しかし、20年経てば1世代変わるので、人も社会も価値観が変わり、人間関係をコントロールするマネジメントスタイルも急激に変わる。
昨今では、米国でのマネジメントの最新知識、たとえば、心理的安全性、ファシリテーション、ティール組織、などいろいろな手法を身に着けなければ、今の社会で自分の存在意義を見つけるのは難しいのではないか。

【2】ビジネスで結果を出そうとする時、知識と経験の2つの両輪が必要になる。

自分の数少ない経験では、知識を経験に変わるタイミング、経験が知識に変わるタイミングを自分なりにつかんでおくことが重要と思う。
なぜならば、知識だけ脳みそにたくさんあっても使いこなせなければ現場では無意味だからだ。
経験をいくら積んでも、その経験を自分なりに解釈して抽象化した知識に変換して、他人に説明できなければ、現場では無意味だからだ。

知識を実際の現場で使おうとする時、他人から教わった知識、本から得た知識は、自分の現場の問題が発生する環境とギャップがある。
環境がもたらす制約条件を考慮しながら、問題を解決する方向へ知識を利用する。
その知識が問題をうまく解決するときに使えたタイミングで、その知識の有効性とその知識が使える範囲を自分なりに理解できる。
この時が知識が経験に落とし込めたタイミングだ。
このタイミングはすごく重要で、そのタイミングを意識しなければ、何事もなく通過してしまって、自分の腹に落とし込めたものにならない。
その知識には、自分にとって再現性がなくなるからだ。

一方、色んな経験をして来た後で、本を読んで気づいたり、コミュニティや大学で色んな人と議論して気づいたりするタイミングがある。
たとえば、初めての案件で初めての役職で仕事して試行錯誤したり、デスマーチ案件で日々苦しめられたり、ルーチンワークに追われて何も考えないまま過ごしたりした後で、なぜこんな状況を自分で解決できないのか、という疑問や問題意識を強烈に持つ。
自分の能力の限界を知り、自分で環境を変える要因をつかみたいと思う。
そんなときに、本や動画、ネット、他人との会話という数多くのチャネルを通して、知識やフレーズに触れたときに、ぴーんと来る時がある。
この時の知識が、経験から知識を抽出して、自分なりに理解できたタイミングだ。
このタイミングは重要で、自分でそのタイミングを意識しなければ、経験は単なる時間的浪費にすぎない。
いくら年齢を取ったとしても、同じ時間という量は質が大きく異なる。

知識と経験を行ったり来たりするタイミングを自分なりに意識して習得することが必要であると最近感じている。

【3】知識と経験を行ったり来たりするタイミングやその活動は、たぶんSECIモデルで表現されるだろうと思う。

知識を経験に変えるタイミングは、形式知から暗黙知に変換する活動に一致し、それは「内面化」に相当すると思う。
経験を知識に変えるタイミングは、暗黙知から形式知へ変換する活動に一致し、それは「表出化」に相当すると思う

つまり、内面化や表出化のタイミングを自分なりにいつも意識して、その瞬間を忘れないようにすること。
そうすれば、以前の自分からなにか一つ殻を破れた、という感覚が得られると思う。

そのためには、表面的な知識を色々自分なりに考えて、どういう問題ならうまく適用できるのか、どんな制約条件を考慮すべきか、実はあまり効果がないのでは、と試行錯誤して考える必要がある。
その作業は、形式知同士を組み合わせて新たな形式知を得る「連結化」という作業が必要になるのではないか。

また、案件でたくさんの経験を得たとしても、その経験から何が問題だったのか、何が足りなかったのか、どんな環境要因があったのか、試行錯誤して考える必要がある。
その作業は、暗黙知の内容を整理して暗黙知のレベルを高める「共同化」という作業が必要になるのではないか。

【4】知識と経験を行ったり来たりする作業は意識的にやる必要があると思う。
特にビジネスマンになれば、いろんな場面で初めての問題に遭遇し、常に問題解決や再発防止を迫られる。
そんな状況で何らかの成果を出すには、常に知識と経験を行ったり来たりする技術を持つ必要があると思う。

以前「実践した後に勉強するのがエンジニアの本来の道」というツイートを読んで、ソフトウェア開発はまず実践して経験した後で知識を習得するのが一番の近道、という内容を思い出した。
実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

また、ビジネス経験を積んだ後でMBAを取得する話をよく聞くが、たぶん、一度経験した内容を知識として再構築する必要性を感じているのだろうと思う。
「あるMBAコースの人(元銀行員で支店次長)が僕にこう言っていた。MBAっていうのは、サラリーマンが20年間で覚えることを圧縮して教えるものだと。マネジメントのエッセンスを短期的に学ぶことで管理職、役員レベルの視点を持つことを目的にするということなのかもしれない。」という内容は心に残った。

企業経営アドバイザー - hmiyau ページ!

MBA | 猫好きのブログ

まなパタにはそのヒントが隠れているような気がする。

| | コメント (0)

2022/05/26

「コーディングを支える技術」は良い本だ

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読んで、良い本と思った。
ラフなメモ書き。
プログラミング初心者の適当な感想。

【参考】
コーディングを支える技術――成り立ちから学ぶプログラミング作法:書籍案内|技術評論社

「コーディングを支える技術」著者公式ページ
「コーディングを支える技術」著者公式ページ 補足記事

【1】Javaで開発経験をした後、RubyやPythonを覚えた今、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読むと、ああそういうことか、と気づくことがある。

【2】IF文の裏ではGOTO文が動いている、という内容を読んで、VBのことを思い出した。
VBでは、例外処理などのAPIが貧弱なので、割とGOTO文がよく出てくるので、VBは好きでなかった。
たぶん、APIが貧弱な古いプログラミング言語ほど、GOTO文が幅を利かせている。
その分、何でもできるが、とても読みづらく保守しづらい。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」の一節に、大学でC言語を初めて習った人が、「while文があればfor文はいらないのでは?」と思ったらしいと書かれていた。
僕も似たような感覚を抱いていた時があった。
JavaでもRubyでも、なぜ、while文、do-while文、for文、拡張for文など、似たようなループ処理の文法があるのか?と不思議に思っていた。

理由は単純で、当初はIF文みたいにwhile文を使っていたが、カウンタ変数のスコープがブロック外にあるので使いにくいから。
だから、while文からfor文の記法により、カウンタ変数のスコープはブロック内に収まった。
さらに、拡張for文により、カウンタ変数そのものも不要になった。
さらに、ListのforEachメソッド、Rubyのブロックのように、for文はクロージャとして吸収される。
つまり、プログラミングの文法もどんどん進化しているわけだ。

【3】変数のスコープの説明では、Perlで静的・動的スコープをプログラムで説明してくれている。
Perlを初めて書いていた時、なぜlocalやmyを変数に付ける必要があるのか、分からなかった時を思い出した。

Pythonでは、わざわざglobal/nonlocalで変数のスコープを制御できるようにしてくれている。
この文法を見た時、Perlみたいだな、と思ったことを思い出した。

Rubyなら、def~endのブロックとクロージャのブロックで、変数のスコープが異なるように使い分けている。
この文法は最初は理解しづらかったが、このおかげで、Rubyはメタプログラミングでやり放題ができるわけだ。

【4】オブジェクトとクラスでは、JavaとRubyでは考え方が全く違う。
親子で継承関係にあるクラスがあった時、インスタンス変数、インスタンスメソッド、クラス変数、クラスメソッドの挙動がJavaとRubyで異なる。
Javaでは、インスタンス変数、クラス変数、インスタンスメソッド、クラスメソッドは、親子クラスそれぞれで保持する。
ただし、親クラスの変数に、子クラスのオブジェクトを代入した場合、インスタンスメソッドは、子クラスのメソッドを利用する。
つまり、Javaでは、親クラスの変数の振る舞いは、ポリモーフィズムで動的に処理が変わるように見せかけられる。

一方、Rubyでは、親子間でインスタンス変数が共通として扱われる。
親クラスが定義したインスタンス変数と同じ名前のインスタンス変数を子クラスで使うと、親クラスのインスタンス変数は子クラスで上書きされる。
この書き方に慣れると、「クラス(型)は仕様である」を時々忘れてしまう。

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその1)

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその2)

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその3)

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその4)

Javaでは「クラス(型)は仕様である」が、Rubyではメッセージを渡したオブジェクトに全てを委ねる。
Rubyはまさにダック・タイピングなので、例えばdesktop.printが変数なのか、メソッドなのかも動かしてみないと分からない。

【5】多重継承のデメリットをどう解決するか?も、Java、Ruby、Pythonなどで全く違う。
Javaは多重継承を禁止するが、インターフェイスを導入して解決しようとした。
Javaでは、継承の代わりに委譲を進めるが、さらに委譲の参照をソースにハードコードするのではなく、依存性の注入により、設定ファイルを使って動的に変更できるような手法が多くなった。
JavaのフレームワークではDIが多いから、設定ファイルにXMLを用いることが多く、その分、プログラムを書くよりもXMLを書いている時が多くてあまり楽しくなくなる。

Rubyは、多重継承の問題を「どの順番で継承関係を検索するか」という問題に置き換えた。
Rubyでは継承関係は、Objectを頂点とするツリー構造だから、継承ツリーをメソッド検索することで解決しようとする。
include, prepend, refinementsはそういう使い道だろう。
また、Rubyでは、どうしても多重継承したい時は、モジュールでMix-inを使う。

Pythonでは多重継承できる、と聞いていてまだ理解できていなかったが、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」によれば、C3線形化のアルゴリズムで継承関係の検索を決めることで解決しているわけだ。

[Python入門]多重継承:Python入門(1/2 ページ) - @IT

Pythonのメソッド解決順序(MRO) - 情報系大学院生の勉強メモ

【6】それから、並行処理のプログラミングの章も非常に分かりやすい。
Windows3.1やMacOS9は強調マルチタスクで、プリエンプティブマルチタスクではなかった、という一節を読んだ時、昔のPowerbookがMacOS9だった時を思い出した。

並行処理の問題点は、競合状態が起きること。
競合状態は3つある。
1つ目は、2つの処理が変数を共有している。
2つ目は、少なくとも1つの処理がその変数を上書きする。
3つ目は、一方の処理が一段落付く前に、もう一方の処理が割り込む可能性がある。

1つ目の対策は、結局スレッドを使っているので、変数を共有しない方向で解決していない。
アクターモデルのように、メッセージを送ることで解決しようとしている。
Erlangがその例だろう。

2つ目の対策は、メモリを共有しても書き換えないようにする方針もある。
全ての変数はImmutableにすればいい。
Haskellなどの関数型言語がそうだろう。

3つ目の対策は、協調的なスレッドを使う。
たとえば、Rubyのファイバー、Cのコルーチン、Pythonのジェネレータ。

あるいは、ロック、ミューテックス、セマフォ、モニタのような機構を使う。
Javaなら、synchronizedブロックで囲むだけでいい。

【7】自分は「プログラミングのできない山羊」出身なので、プログラミングを経験してやっとこういう本の内容が分かってきたという気がしている。
ソフトウェア開発は、数学や物理、経済学、財務会計、心理学などと違って、やっぱり独特の考え方がいると思う。
自分の中で言語化できていない部分は気づいたらブログで残しておく。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ: プログラマの思索

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

| | コメント (0)

2022/05/14

ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ を読んで、テストケースの切り方の練習として良い教材と思った。

【参考】
【書評】「ソフトウェアテスト技法練習帳」を読んで、体系的なテスト技法の知識を身につけよう - give IT a try

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~:書籍案内|技術評論社

ソフトウェアテスト技法練習帳 / 梅津 正洋/竹内 亜未/伊藤 由貴/浦山 さつき/佐々木 千絵美/高橋 理/武田 春恵/根本 紀之/藤沢 耕助/真鍋 俊之/山岡 悠/吉田 直史【著】 - 紀伊國屋書店ウェブストア|オンライン書店|本、雑誌の通販、電子書籍ストア

(引用開始)
目次
1 同値分割法と境界値分析(温度によって表示を変えるペット用室温計;キッチンスケールの動作検証 ほか)
2 デシジョンテーブル(1杯目のビールの価格;銀行ATMの引き出し手数料 ほか)
3 状態遷移テスト(ストップウォッチの動作;スマホ決済アプリの決済処理 ほか)
4 組合せテスト(美味しい組合せ;BUG QUEST★冒険のはじまりの旅支度 ほか)
5 総合問題(スマートフォンの料金プランと料金計算;BUG QUEST★隠しアイテム探し ほか)
(引用終了)

ソフトウェア開発でテストの重要性は誰もが知っている。
しかし、実際にテストケースの切り方をきちんと学んだ経験を持つ人は少ないのではないだろうか。
実際、テスト技法の本はプログラミング関係の本に比べて圧倒的に少ないし、現場でも、デシジョンテーブル、状態遷移テストなどをきちんと駆使して、漏れなくテストしている場面が少ない気がするからだ。

その真因は、テストケースを作るのが非常に面倒だからと思う。
業務フローやデータパターン、確認項目の個数が増えれば、その組み合わせを考えると爆発的に増えてしまう。
その時に、同値分割で代表となるパラメータの組み合わせでテストケースを作るわけだが、手動で作成するのが鬱陶しい。
組み合わせには禁則処理もあるから、パスを通過しないパターンを削除したり、含められるパターンをまとめたりするのが手動であり、自動化しにくいからだ。

テストケースをユニットテストのプログラムで実装すれば、後は自動でビルドしてテストできるが、肝心のテストケースをすべて漏れなく洗い出すのが面倒なのだ。

また、真因の一つには、テストケースの作成技法であるデシジョンテーブル、状態遷移テストには割と細かいテクニックが隠れている点もあると思う。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ の良い点は、テストケースの練習帳なので、実際に頭で汗をかいて、書き下してみることができるからだ。
僕も実際にテストケースを書いてみたけれど、解答を読んで、そんな仕様を読み落としたのか、とか、そういう考え方もあるな、とか色々気づきがあった。
テストケースを我流で作っていると、割とこういう基礎的な部分を忘れている気がする。

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

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かったのでメモ。
ラフなメモ。

【参考】
オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - AFFORDD

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - 経験論文

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - スライド資料

オープンソースERPパッケージiDempiereはいつか、仕組みを習得して、ERPはこういうものですよと自分なりに理解したいと思っていた。
ネット上の情報から、普通にインストールできる。
PostgresSQLのDBの中身を見ると、テーブル数は1千個を越えるので、OSSのわりに作り込んでいるERPだと思う。

こういうOSSのERPを自社開発、受託開発したい場合、必ずカスタマイズが入る。
その時に、どんな方針でカスタマイズすべきか、という問題が出てくる。
無造作にカスタマイズしていくと、開発基盤のバージョンアップに追随できなくなるし、今後の運用保守もやりにくくなるからだ。

そこで、ERPのカスタマイズに派生開発手法であるXDDPを用いて解決してみよう、という流れは自然に理解できる。
基本方針は、カスタマイズする場合、標準機能をラッピングまたは継承する形で、独自ロジックを実装する。

上記の資料で興味深いと思った点は、OSSのERPのカスタマイズで発生する問題として、標準機能の知識習得が難しいこと、派生開発により基盤である標準の品質を損ねること、という2点があげられたことだ。
そして、その解決方法として、教育環境の整備、開発規約の整備、開発体制の強化があげられていた。

意外だなと僕が思った理由は、派生開発のプロセスやiDempiereの開発基盤のアーキテクチャに焦点が当たると思っていたからだ。
しかし、よく考えれば、プロセスや技術面よりも、技術の習得や教育の方が長期的な問題なのだ、と理解すればいいのだろう。

得られた情報や検索した情報は、社内のRedmineで一元管理して共有している点も面白い。
Redmineを組織のナレッジ資産として使っているわけだ。

今後の課題として、XDDPのトレーサビリティマトリクスを利用して技術上の課題を解決していく点があげられていた。
iDempiereはOSSとはいえERPなので、相当な機能数があるから、すべてを理解するのが難しいのだろう。
そのために、XDDPのトレーサビリティマトリクスを利用したいのだろうと思う。

| | コメント (0)

より以前の記事一覧