ソフトウェア工学

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)

2022/04/21

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

プロジェクト管理の基本はテーラリングだと思う。
そして、Redmineはプロセスをテーラリングするツールだと思う。
ラフなメモ。

【1】プロジェクト管理の基本的な考え方は何だろうか?

QCDのコントロール、課題管理、スケジュール管理とか、色々あるだろうが、僕は、標準プロセスを各案件、それぞれの現場にテーラリングする能力が問われている、カスタマイズする能力が問われていると思う。
なぜならば、現場にあるプロジェクトはどれもバラバラであり、過去の経験と全く同じプロジェクトはありえない。
そこで、標準プロセスを元に、過去の経験やベストプラクティスのいずれかを、それぞれの現場の案件に適用して、プロジェクトの成功を目指すことになる。

つまり、案件の特徴を見抜いて、標準プロセスから、案件に合ったベストプラクティスを適用して効果を引き出すわけだ。
プロジェクトマネージャは、案件を自分のコントロールの配下におくために、自分の手持ちの武器のうち、有効な武器だけを抽出して、プロジェクトごとにカスタマイズして適用しているわけだ。

すると、2つの疑問が湧いてくる。

【2】1つは、標準プロセスがなければ、そもそもテーラリングができないので、テーラリングという考え方が合っているのか、という点。

PMBOKのようなプロジェクト管理の基本知識では、予実管理が基本だ。
つまり、標準が前提としてあって、実際の実績が標準からどれくらい離れるのか、を測定して制御するイメージ。

しかし、標準プロセスが事前に定まっている環境は、大企業や歴史の長いSIなど、それなりに自分たちの開発の歴史を持って、そこから標準プロセスを作り出した人たちだろう。
そうでない場合は、標準プロセスがあいまいか、そもそも存在しないかもしれない。

そういう状況は、カオスと言えるだろう。
案件を受注するたびに、いつも初めてのプロセスを自分たちで作って運用していかないといけない。
それはあまりにも大変すぎるし、失敗しやすい。

アジャイル開発がそんな場面で利用されやすいだろうが、スクラムのようなきちんと決まっている最低限のフレームワークを用いることで、そういうカオスを制御しようとしている。
スクラムから離れて自分たちのアジャイル開発を見出すのは、スクラムの守破離のうち、守りをきちんとマスターした後でいい。

だから、何らかの標準プロセスが前提にあるのが基本ではないかと思う。

【3】もう一つは、プロマネが標準プロセスからテーラリングできる自由度の範囲はどれくらいあるのか、という点。

PMOの立場では、標準プロセスを策定して、各案件のプロマネに提示して使ってもらう。
しかし、案件ごとに特徴がバラバラだから、標準プロセスをそのまま100%当てはめるて運用は難しい。
だから、プロマネには、基本は守ってもらうけど、ある程度カスタマイズして、プロジェクトをスムーズに運用してください、とある程度のカスタマイズお自由は手渡す。

では、どれくらいの自由度がプロマネにはあるのだろうか?
この自由度は、その会社のプロマネの能力レベルに依存する、という身も蓋もない話。

プロマネの能力が高ければ、標準プロセスを元に、担当案件ではこの部分をカスタマイズして、プロジェクトを運用しやすくします、と宣言して進める。
プロジェクトをコントロールするには、この部分のカスタマイズが必要だと彼らは分かっている。
彼らは、カスタマイズする根拠を説明して、ステークホルダーに納得させるだけの能力を持っている。

一方、プロマネの能力が低い場合、彼らは、プロジェクトの実績の妥当性を標準プロセスに求めたがる。
こういう運用をしているのは標準プロセスに即しているからです、開発を委託したベンダの成果物の品質が悪いのは標準プロセスに従ったからです、などと平気に言う。
つまり、プロマネは、案件の遂行の妥当性を第三者に説明する根拠として、標準プロセスを使おうとする。

すると、PMOは、標準プロセスが現場にフィットしていないからそういう意見が出てくるのだ、と判断して、標準プロセスをどんどん詳細化し、ガチガチに決めていく。
そうすることで、テーラリングの自由度が下がり、プロマネが自由に運用できる裁量が狭くなる悪循環に陥る。
自分で自分の首を絞めている感じ。

そういう現象も多いので、標準プロセスの策定では、プロマネにどんなインセンティブを与えれば、彼らが良い方向にカスタマイズしてくれるか、を考える時が多い。

その気持ちは、まるで法律家みたいだ。
政府が定める法規制によって、市場や社会を良い方向へ誘導しようと計画するが、実際は、生身の人間は小賢しいので、その意図をすぐに行動に反映して自分の利害に合うように変な方向にカスタマイズする、みたいな感じ。
マクロ経済学で言えば、ルーカス批判。
量子力学で言えば、不確定性原理みたいなものか。

【4】他方、Redmineを使うと、標準プロセスとテーラリングのバランスをある程度保証して、プロマネに運用してもらうことができると考える。

Redmineはとても自由度が高いプロジェクト管理ツールだ。
とはいえ、Redmineも汎用ツールなので、Redmineに埋め込まれた機能によって、プロセスの自由度はある程度限られる。
つまり、Redmineで提供する「プロジェクト」ごとに、スクラッチのシステム開発やパッケージ製品導入、サポートデスクなどのドメインで、ワークフローやチケット管理などをテンプレート化しておく。
そのドメインのテンプレートをプロマネに手渡し、そこから先はプロマネに自由に運用してもらう。

つまり、ドメインごとのテンプレートで標準プロセスは固めておき、それから先の運用はプロマネの自由裁量にある程度任せる。
もちろん、チケット起票やチケットの完了条件については、Redmineの機能で制限することは難しいから、運用ルールで縛ることになる。
ただし、各案件ごとに、開発者のスキルが違っていたり、開発やリリースの手順が違う時もあるだろうから、チケット管理にテーラリングを当てはめて、ある程度の自由裁量で運用ルールを変更する余地は残す。

そうすれば、Redmineで標準プロセスを元に、プロマネがテーラリングして、案件ごとに合った運用ルールを策定できて、プロジェクトを成功させる確率を高めることができるはず。

ただし、この運用の前提条件は、プロマネがRedmineの機能やカスタマイズできる範囲を理解し尽くしておくことだ。
つまり、Redmineをプロセスのテーラリングに使うツールとして用いることができる能力を前提としている。

そうでなければ、プロジェクトのテーラリングをRedmine上で実現できないからだ。
個人的には、Excel手順書で運用ルールを逐一テーラリングするよりも、ある程度ツールで標準プロセスを遵守して、ツールの基板上でテーラリングする方が、コントロールしやすいのではないかと考えている。

| | コメント (0)

2022/04/17

初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ

初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。
理解できた内容をラフなメモ。

【参考】
初中級プロマネのための 現場で活かせ!統計情報1

初中級プロマネのための 現場で活かせ!統計情報2

「ソフトウェア開発分析データ集2020」の発行:IPA 独立行政法人 情報処理推進機構

「ソフトウェア開発データ白書」のダウンロード:IPA 独立行政法人 情報処理推進機構

初中級プロマネのための現場で活かせ!統計情報  2019年4月19日| CITP Community

CITPアニュアルレポート2018を公開しました | CITP Community

【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。

【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。

1つ目は、プロマネとしてシステムの企画書や提案書を書いている時に、見積もりの妥当性を説明するために、日本の他社事例の数値を元に遜色ないことを理由として、見積もり工数や金額は妥当です、とロジカルに説明したいこと。
もう一つは、プロマネとしてリリース判定会議で、システムの開発やテストの結果が、日本の他社の成功した事例と遜色ないことを理由として、品質は妥当です、とロジカルに説明したいこと。

プロマネは、経営層が考えた戦略を受けてその内容をシステムとして実現する時に、自分が考えた企画内容の妥当性を説明したい。
その時に、経営層から聞かれるのは、投資効果が見込める妥当性はあるのか、初期投資の金額の妥当性はあるのか、という点だ。
この根拠を作るために、実際に業務システムの無駄な問題点を工数や金額で事前調査したり、削減できるコストがこれだけあるとか、売上や利益がこれだけ伸びるとか、色々話を膨らませる。

特に難しいのは、初期投資としての見積金額が本当にこれで妥当なのか、という点だ。
まだ実際に作ってもないし、あいまいな調査を元に機能一覧を洗い出して、その積み上げで工数を算出し、人月単価を元に見積金額を弾くわけだが、それを各工程に分けて積み上げて、本当に正しいのか、と言われると、正直難しい。
実際は、色んな前提条件をたくさん置いて、こうなります、という説明しかできない。

そんな時に、日本のSIで成功した事例では、こういうデータがあるので、工数や金額に妥当性があると言えれば、自分たちの会社も日本のSIで普通のレベルだと仮定できれば、こんな数値になるのは妥当でしょう、と言える。
そういうロジックに持ち込みたい。

つまり、プロマネの勘や度胸のような直感に頼らず、利害関係者にロジカルに説明するための根拠づくりに、IPAデータ白書を使いたいのだ。

【2】IPAデータ白書には、日本のトップレベルのSIが収集したソフトウェア開発における数多くの統計データが掲載されている。
その統計データが膨大であるために、どのように使えばよいか分かりにくい。
僕も正直悩んでいた。

しかし、初中級プロマネのための 現場で活かせ!統計情報1を読むと、初級者・中級者のプロマネはIPAデータ白書をこういう風に使うと役立つよ、という指針を書いてくれているのでとても役立つ。

IPAデータ白書の主な使い道は、見積り、生産性、品質の3つの観点で使うと良いだろう。

【3】企画提案の段階では、要件定義工程比率や工程別の工数比率、工程別の工期の比率が役立つ。

たとえば、要件定義工程は準委任、設計・開発・テストは請負契約でやる場合、トータルの工数や工期を提案段階である程度見積る。
その時に、要件定義フェーズはこれくらいの工数や工期が必要である根拠として、IPAデータ白書の数値を用いて算出するとよい。
なぜならば、経験上、要件定義フェーズをケチって実施してしまい、実際の開発フェーズに入ると要件がどんどん覆されて遅滞してしまい、最終的にプロジェクトが赤字になるか、失敗プロジェクトで終わってしまうという失敗事例がすごく多いからだ。
やはり、要件定義工程にある程度の工数や工期を割り当てて、メンバーも労力も割いた方が次の開発フェーズはスムーズに進みやすい。

あるいは、設計・開発・テストの各工程の工数別割合をIPAデータ白書の数値を用いて算出し、プロジェクトが成功するならこれくらいの比率の工数が必要だ、という根拠に使う。
なぜならば、開発工程の見積は実際にプログラマが見積もればある程度明確になりやすいので、その工数を元に設計やテスト工程の工数を算出できるからだ。
失敗プロジェクトでは、設計工程は十分に工数を取るが、テスト工程の工数をケチって、実際のプロジェクトで破綻する時も多いからだ。

【4】また、設計や開発工程の見積もりには、生産性の指標が役立つ。

たとえば、SLOC規模あたり設計書ページ数を使えば、プログラム規模を元に設計書ページ数を見積もれるので、設計書の規模感や設計書作成の工数の根拠を算出できる。
あるいは、SLOC 規模別 SLOC 生産性 や SLOC 規模と工数の関係を使えば、プログラム規模を元に各工程の工数をある程度見積もることができる。

つまり、設計、開発、テスト工程の工数の見積の精度を向上させることもできる。

【5】設計・開発工程がほぼ終わり、テスト工程に入る時には、レビュー指摘件数、SLOC 規模 テストケース数、SLOC 規模 検出バグ数を使えば、品質の妥当性をチェックすることに使える。

たとえば、設計工程のレビューの指摘件数を収集できれば、SLOC 規模/工数あたり/ページあたりの数値がIPAデータ白書にあるので、その基準値を元にレビュー指摘件数が妥当であるか、管理図を使って検査できる。
外れ値が出るならば、レビュープロセスに原因があるのか、設計書という成果物が悪いのか、さらに原因分析していく。

あるいは、開発が終わればプログラム行数は簡単に測定できるので、開発規模に応じたテスト工程ごとのテストケース数や検出バグ数を予測することができる。
IPAデータ白書の数値を元に、開発規模から妥当なテストケース数はこれくらいと分かれば、そのケース数から外れ値が出ていないかチェックすればいい。

そして、実際にテストしてみて、バグ数がIPAデータ白書の基準値よりも多く出るならば、品質が悪い可能性があるのでさらに原因分析していく。

つまり、設計・テスト工程の品質の妥当性にIPAデータ白書の数値は使えるはず。

ソフトウェア開発データ白書と定量データの活用方法を参考にすれば、ゾーン分析やトレンド分析、信頼度成長曲線など数多くの品質管理技法を適用することもできるだろう。

「ソフトウェア開発データ白書2018-2019」のご紹介~プロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果~も参考になる。

【6】IPAデータ白書の統計情報はたしかに、見積り、生産性、品質の観点で使えるし、それなりに役立つ。
しかし、いくつかの留意点はある。

1つ目は、WF型開発を前提としたメトリクスであること。
実際に収集した事例の数値では、ほとんどがWF型開発であり、アジャイル開発を前提としたメトリクスではない。

2つ目は、開発言語やシステムの種類、開発フレームワークをすべて混ぜ込んで、グロスで集計した数値であること。
以前は、JavaやCobolなど数多くの言語で分類されていたが、最近は言語の区別もなく、せいぜい、新規開発・改良開発・再構築の開発種別の違いだけしかない。
つまり、色んなシステムのデータを一つの数値でまとめているので、本当に精緻なデータなのか、という疑問はある。

3つ目は、IPAデータ白書に提出した日本の各SIの統計データは、工程の定義や開発規模、テストケース数、バグ数などの定義が各社でバラバラである可能性が大きいことだ。
この点はIPAのFAQサイトにも記載されていて、その点を考慮して色々精査されているみたい。

「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答:IPA 独立行政法人 情報処理推進機構

4つ目は、この数値を鵜呑みにして使わないように、IPA自身も注意喚起を記載している点だ。
あくまでも参考データであり、自分のソフトウェア企業がこの数値に当てはまるとは限らない。

とは言え、IPAデータ白書は10年以上の歴史があり、その統計データの推移を見ると、そんなに大きく変わっているわけではないようだ。
日本でDXが叫ばれていても、日本のSIではやはりWF型開発が主流であり、それなりの品質データや見積データを収集して蓄積しているみたいだ。

個人的には、日本で少しずつ浸透しつつあるアジャイル開発の統計データが収集されて、実際の統計データとして採用されると参考にしたいと思う。

| | コメント (0)

2022/03/24

CFD法のコツは同値分割にある #GIHOZ

ベリサーブ社のテスト勉強会で、CFD法のコツは同値分割にあると分かったのでメモ。
後半は適当な妄想なので後で消すかもしれない。

【参考】
【明日から使えるテスト技法勉強会】 #4 ~CFD法って、なに?~ - connpass

CEGTest - 原因結果グラフからテスト条件を作成するツール

CEGTestによる原因結果グラフの書き方: プログラマの思索

ソフトウェアテスト技法ドリルの感想: プログラマの思索

CFD法は原因結果グラフの別の表記法。
秋山さんの本「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際 | 秋山 浩一」にも紹介されていた。
実際はなかなか使いにくい。

テストケースやロジックそのものをANDやOR条件でつなげて原因結果グラフで書くこと自体が難しい。
そして、原因結果グラフで書いたとしても、何が嬉しいのか、分からない感覚があった。

今日の勉強会で良かった点は、テスト仕様を提示して、そこからCFD法で実際に図を描いて、そこからデシジョンテーブル、最後にテストケースを作る、という一連の流れが分かったこと。
実際は、ベリサーブ社が提供するクラウドサービス上でやっていただけ。
でも、GUIが揃っているのは便利。

CFD法のコツは、テスト仕様を同値分割の集合体と考えて、同値分割の集合でグルーピングして、同値分割のグループを原因→結果の流れで矢印を結んで、ロジックを状態遷移図のように一連の流れで示すこと。
同値分割はテスト技法の初歩で出てくる考え方だが、まさに同値関係でテスト仕様をグルーピングするのがCFD法の起点になる。

盲点になる点は、仕様を同値分割でグルーピングした時、補集合を忘れがちなことだ。
ベリサーブ社のツールでは補集合は「その他」として必ず表示されるので、漏れがなくなる。
大体のケースは、システムエラーや例外処理、異常処理のケースが多いだろう。
そういうケースを忘れないように図で示せるのは良い。

すると、CFD法は状態遷移図で表せないか?と思った。
CFD法で描いた図を見ると、同値分割の各グループを状態遷移図の「状態」と捉えることができる。
状態遷移図では、状態の入れ子構造も表現できるから、補集合も内部状態の一つとして表現できる。

そうすれば、状態遷移図を描ければ状態遷移表を自動生成するツールはastahやEnterpriseArchitectなどたくさんあるから、そこからデシジョンテーブルやテストケースを生成することができる。
つまり、状態遷移図に落とし込めれば、状態遷移表を通じてテストケースを自動生成するやり方はツールで既に実現されているし、状態遷移図は組込みソフトウェア開発者であれば見慣れた図なので、理解しやすいからだ。

ただし、このアイデアも、Q&Aで聞いた所、状態遷移図はトリガーやイベントも含む技法なので、CFD法のように原因と結果を結ぶ図とはそもそも観点が異なります、という回答があった。
確かに、全く違うのはその通り。

実際、下記の例題を考えてみよう。

(引用開始)
例題

ベリサーブショッピングモールでは、買い物金額やシネマ鑑賞に応じて、駐車場の料金を割引きするサービスを提供しています

■<駐車場割引サービスの仕様>

パターン 結果
お買い物金額2,000円以上 1時間無料
お買い物金額5,000円以上 2時間無料
お買い物金額10,000円以上 3時間無料※平日限定
シネマ鑑賞 3時間無料※鑑賞本数・上映時間に関わらず上限3時間
割引サービスの判定システムの実装を確認したところ、条件判定はシネマ鑑賞、お買い物金額、曜日の順に実施していました。
このシステムの判定結果が正しいことを確認するためのテストケースを作成してください。
(引用終了)

シネマ鑑賞、お買い物金額、曜日の3項目は、それぞれ同値分割でグルーピングできる。
具体的には、シネマ鑑賞の有無、お買い物金額は金額ごとに4パターン、曜日は平日と平日以外の2パターンに同値分割される。
そして、シネマ鑑賞、お買い物金額、曜日の3項目に対し、同値分割のグループの組み合わせを考えて、それらを原因→結果でつなげると、状態遷移図のような図でCFD法を示すことができる。

同値分割の各グループを状態と捉えて、状態遷移図で表現することは可能だろうと思った。

astahであれば、状態遷移図を描ければ状態遷移表は一発で自動生成できるから、そこからデシジョンテーブルやテストケースを作成すればいい。

状態遷移表プラグイン | astah* Plugins

状態遷移パスプラグイン | astah* プラグイン

CFD法の特徴の一つに、ループ構造がない点だ。
理由は簡単で、原因→結果の1方向しかないからだ。
この特徴を活かせば、状態遷移図や状態遷移表は非常にシンプルに描くことができるはず。

しかし、状態遷移表では前状態x後状態の表をイベントで表すから、CFD法には使えない。
状態遷移パス表なら、状態xイベントの組み合わせでパスをすべて生成するので、テスト仕様が3項目なら、入力3個と出力1個で合計4個のパターンを見なして、状態xイベントを4パターン組み合わせたもので表すことができるはず。

改めて理解できた点は、テスト仕様は同値分割で最小限のテストデータに整理できること。
そして、同値分割の組み合わせを原因と結果の組み合わせで表現する時に、原因と結果を状態に割り当てれば、状態遷移図らしきもので表現できると思う。

ちょっとこのアイデアを試してみようと思う。

| | コメント (0)

2022/03/23

テスト自動化の計画づくりにはコツがある #mabljapan

藤原さんが主催されたOL勉強会に参加した。
ラフなメモ。

【参考】
テスト自動化スタートダッシュ! テスト自動化のオンボーディングや戦略、計画づくりを考える編 - connpass

イベントレポート: テスト自動化スタートダッシュ! テスト自動化の戦略を考える編 | mabl

【1】テスト自動化をやりたい動機は色々あるが、効果を出すには、ゴール設定やスコープ設定が必要になる。
なぜなら、mablがいくら優れたテスト自動化ツールであっても、その現場の問題解決にピッタリ当てはまるとは限らないからだ。
たとえば、マニュアルテストをすべて自動化したいと思っても、実際はなかなかうまくいかない。
あるいは、テスト自動化で回帰テストを強化したり、受け入れテストを自動化したい、と思っても、効果を出すには割とギャップがある。

どうやらテスト自動化と従来のマニュアルテストの間には大きなギャップがあるらしい。
テスト自動化に合ったテストケース作成、テストシナリオ作成、テスト自動化のスコープや自動テストの粒度があるようだ。

テスト自動化の計画の話を聞くと、4つの注意点があるように思う。

【2】1つ目は、テスト自動化のゴール設定、テスト自動化で実現する品質の基準を明確に定めること。
テスト自動化で何を求めたいのか?
一口に品質向上と言っても、コストをいくら掛けてもいいわけではない。
藤原さんの言葉で腑に落ちた点は、テスト自動化をやっていると品質保証という言葉が合わない。
むしろ、どんな品質をテスト自動化で担保したいのか、を明確にすべきだ、と。

たとえば、受入テストのような手動テストを自動化したいのか、本番運用する前に品質検査するスモークテストを自動化したいのか、機能追加や機能改善してもデグレしないように回帰テストを重視したいのか、自動テストのカバレッジを上げたいのか、どれなのか、と。
あるいは、クレジット決済に関わるようなクリティカルな機能のテストは十分に自動化したいのか、本番システムの障害テストを自動化したいのか、と。

また、品質に関する基準も、マネージャや開発者、ユーザでも異なってくる。
この辺りは狩野モデルかな。
当たり前品質なのか、魅力的な品質を求めるのか。

マネージャならシナリオテストや受入テストを自動化したいだろうが、開発者なら単体テストのカバレッジを上げたり、回帰テストを強化したいだろう。
役割によって、求めたい品質は異なってくるから、そのゴールをまずは現場で合わせる必要があるわけだ。

【3】2つ目は、テスト自動化は、単体テストから受入テストまでのプラミッド型のスコープではなく、回帰テストからテストカバレッジまでの逆ピラミッドにすべきであること。
つまり、テスト自動化を導入する場合、松竹梅のレベルに合わせて、まずはテスト自動化に手を付けやすく、投資効果が大きい部分から始めて、徐々にテスト自動化の範囲を広げていくのがおすすめ。

資料のスライドでは、回帰テストの松レベルから始めて、受入テストのうち重要機能の正常ケースを網羅するスモークテストに手を付け、徐々にシナリオテストや単体テストの網羅率を広げていくような例があった。
この方法ならば、開発者も実装しやすいし、ユーザもテスト自動化の投資効果を得られやすいだろう。

【4】3つ目は、テスト自動化の実現手段は、WF型開発の各工程、アジャイル開発ならDevOpsの各プロセスによって異なること。
たとえば、単体テストならC0、C1のテストカバレッジ、結合テストなら回帰テストやCI、総合テストならシナリオテストやCD、受入テストならUIテストやスモークテストやCDなどが相当する。
つまり、テスト自動化の技術は、WF型開発の各工程、DevOpsの各プロセスによって異なる。
だから、投資効果を得たいならば、どのフェーズにテスト自動化を注力するのがよいのか、をゴール設定から見極める必要がある。

【5】4つ目は、テスト自動化を担当するロールは、現場の組織のリソースや組織構成に応じて、柔軟に対応すること。
たとえば、大規模なSaaSや大規模な基幹システムであれば、複数のチームが機能やサービス単位に分かれていて、それぞれで開発して、品質に責任を負っている。
すると、回帰テストやスモークテストを実行したい時、複数のチームをまたがってテストシナリオを作ってテスト自動化を図る必要が出てくるが、それを担当する人やチームが曖昧になりがちだ。
なぜならば、複数チームにまたがるので、その作業工数や品質について誰がその責任を負うのか、が不明確になりがちだからだ。
そこで、たとえば、複数の機能やチームを横断するテスト自動化のチームを作り、回帰テストを担当するケースもあり得ると言われた。
確かに、チーム横断、機能横断でそういうチームを作るときもあるだろう。

一方、各チームにテスト自動化の専任担当者を作った方がいい場合もあるだろうし、他方では、チーム内の各メンバーがテスト自動化のスキルを持つように能力を育成して全員が担当する、という場合もあるだろう。

やはりアジャイル開発であれば、少人数のメンバーでチームを組んで開発していきたいので、各メンバーがテスト自動化のスキルを持って実装できるのが理想だろうと思う。

【6】こういう話を聞くと、テスト自動化とは単にJUnitやSeleniumなどで実装するだけではなく、細かいの実践ノウハウが必要だと分かる。

僕は、ソフトウェア開発において、テスト自動化のスキルはシステムの品質を担保する上で重要な要素の一つであると思うので、この辺りの技術は今後もウォッチしていく。

| | コメント (0)

より以前の記事一覧