ソフトウェア工学

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

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

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


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

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

2018/12/03

ソフトウェア開発に心理学や行動経済学の概念を適用した記事のリンク

ソフトウェア開発に心理学や行動経済学の概念を適用した記事がとても素晴らしいので、リンクしておく。
このアイデアを育ててみたくなった。

【参考】
ソフトウェア開発に役立つ 心理学的現象、行動経済学の概念など 15題 - Qiita

ソフトウェア開発に、製造業や生産管理のベストプラクティスを適用しても、あまり有効でない。
むしろ、認知心理学や行動経済学の知見を適用して、開発者の心理や開発チームの行動に着目した方が、うまくコントロールできるのではないか。
そんな感触をずっと持ち続けてきた。

上記の記事はまさにピッタリ。
そう、こういう記事が読みたかった。

現場の開発者や開発チームは、独自の存在であり、全ての存在が同じではないけれど、それらの行動を現象として見ると、驚くほど共通的な特徴が見つかる場合も多い。
そういうバラバラな共通的な現象を、的確な概念でその本質を表現できればいいのに、と思っていた。

たとえば、認知心理学の概念として、認知的不協和、グループシンク(集団浅慮)、リスキーシフト(リスク志向の集団極性化)、コーシャス・シフト(安全志向の集団極性化)、有能性の罠(competency trap)、訓練された無能、などがある。
それらを実際にソフトウェア開発に適用してみれば、当てはまる事例は多いのではないか?

具体的には、要件定義で数多くの利害関係者の意向を取り入れると、本来は業務を刷新する革新的なシステムを導入するはずだったのに、現状の業務の焼き直しに過ぎないリプレース案件になってしまった、という事例は、コーシャス・シフトの一例ではないか、とか。

僕は、認知心理学の概念の適用も面白いと思うが、行動経済学の概念を適用する方が面白いと思っている。
経済学の基本理念「限られた資源を有効活用する」ことは、ソフトウェア開発でもまさに同じだ。
優れた開発者、優れた開発チームという唯一無二の資源をいかに有効活用して、ビジネス価値を作り出すか、という目的と一致するからだ。

たとえば、技術的負債やリファクタリングは、時間割引や割引価値の観点で説明できるだろう。
犠牲的アーキテクチャは、埋没価値(サンクコスト)や機会原価の観点で説明できるだろう。
意固地な言動は、バイアスで説明できるかもしれない。

アドレナリンジャンキー」にあるプロジェクト管理のアンチパターンも、認知心理学や行動経済学の知見で整理して説明し直すと面白いかもしれない。

プロジェクト管理のアンチパターン集~アドレナリンジャンキー: プログラマの思索

| | コメント (0)

2018/09/25

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

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。
以下、ラフなメモ書き。

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

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【1】以前、下記のツイートがあった。
最初はRedmineでチケット管理して上手く回っていたのに、ガントチャートで厳しく管理し始めたら、内容が空っぽのチケットが大量発生して、チケット駆動でなくなった、というアンチパターン。

【1-1】
akipiiさんのツイート: "ガントチャートはもう時代遅れなのかな?RT @kabukawa: Redmineはチケットからガントチャートが自動で作られて便利なんだけど、ガントチャートを目的に導入すると、Excelより入力が面倒で使わなくなるか、設計とか実装ってタイトルの中身が空のチケットか沢山できて、時々脱力する。"

門屋浩文@redmineeva☀️さんのツイート: "個人的には品質状態(中身)が見えないガントチャートは時代遅れだと思いますよ ごまかせるもの… "

あさこ@センチちうさんのツイート: "ガントはあくまでも、参照かなー。 誰がなんのために見るか、使うかを区別しないと手段が目的になってしまう。 時代遅れとかではなく、手段の違いだと思います。 ガントで見ることができるものをちゃんと区別していないと、ごまかしとかが生まれてくる。見るべきものを適切なもので。… https://t.co/aw4zR2QAQw"

門屋浩文@redmineeva☀️さんのツイート: "目的を理解して使ってる人 ほとんど見たことないよ(疲れていてネガティブです) うーん、見たことあるかなあ? 俺はWBS辞書 つまりチケット一覧をソートして見る派なので 期間にかかる工数も成果物の精度も見ないで何がわかるのかわからないから パッとみで安心したって意味ないもの… https://t.co/AAWOZvyaXo"

昌。さんのツイート: "まどさんがネガティブ!いかんですな。確かにぱっと見安心する使い方してる人たちいますけども。 私は最アジャイルさんのLycheeのおかげでRedmaineにおけるスケジュール見える化はプロセスわからない派にも使えるかもと思うことができましたさ。… https://t.co/4uE4LNBrDL"

門屋浩文@redmineeva☀️さんのツイート: "ネガティブ続きですが、、、ガントチャートが問題の早期発見や解決につながってないんじゃないかなと感じてるから時代遅れと言った 把握してる人に責任押し付けたって誰も幸せにならんから ガントチャートのみ見て改善につなげられる凄腕なら別だが 時系列で5つ並べてみたら気が付けるかなあ俺… https://t.co/fPxjDRBRLu"

あさこ@センチちうさんのツイート: "ガントだけだと、早期発見なんてほぼできないよね。その目的で使うならば間違いなく、「それじゃないっすよ」と答えるかなー。 ガントの強みってなんだろうねー。 タスク同士の流れとか、いつまでに何が終わるのか、どのくらい終わってるのかを見るだけのツールとして今は使っているかも。… https://t.co/xSecapQWwY"

昌。さんのツイート: "ガントに限ったことではありませんが、ツールに対してこれダメ!ってなる人は弊社の場合は大体が目的見失ってるかツールに夢見てるひとですかね。あなたが使ったようにしか使えませんよー、ってなる。… "

やっさん🍶さんのツイート: "管理者より担当者視点だと (関連あれば)チケットを前後で関連付けちゃうので、前後の関係とか、並列度とかを見るくらいですね。ガントチャートの利用って。… "

akipiiさんのツイート: "ガントチャートはメーカーの製造工程や発注作業の管理に向いていて、ソフトウェア開発のように、作業が不明確で、担当者がコロコロ変わり、管理単位が1日未満で粒度が小さい場合は向いてない。所詮、ガントチャートはマネージャがプロジェクト管理で使うビューの一つに過ぎないと思う。… https://t.co/wc6TLz0MKc"

【1-2】akipiiさんのツイート: "知りたい。RT @g_maeda: Redmineのガントチャート、実は社内では全く使ってない。ガントチャート機能を使ってる組織ってどのくらいの割合なんだろう。"

あさこ@センチちうさんのツイート: "うちは、お偉いさんたちが、プロジェクトのMilestoneとガントチャート、リスク管理表と合わせて見るということをしてくれています。 Milestoneに対してどうか、間に合うか、作業的にリスクがあるかという観点で使ってますね。 ガントチャート一本で何かを見るということは難しい…… https://t.co/uuNqP8gYWb"

あさこ@センチちうさんのツイート: "多分、そのリソースやスケジュール確認するのも、目的が合って、そこにたどり着くまでの一つのプロセスになってますよね、ガントチャート。 なので、みたい観点もある、って感じですかね?… "

昌。さんのツイート: "です。>みたい観点 個人的にしっかりプロセスてか目的に沿ってチケット運用してる限りタブ切り替えるだけで自分やメンバーのタスクが見える化されてるから便利〜なので、とりあえず朝イチとか進捗確認時に眺めたり確認したりな感じです。… https://t.co/pcMefEEx29"

【1-3】akipiiさんのツイート: "第3回 Lychee Redmineユーザ会 - connpass https://t.co/5O2rOzCMxx 「Redmine + Lychee導入のアンチパターン」の講演は、チケット管理が回っていたのに、Lycheeガントチャートを使いだしたら、空っぽのチケットが増えてチケット駆動でなくなった、というアンチパターンだろうか?笑"

【1-4】akipiiさんのツイート: "読み返したら、当初の目的が忘れられて、手段が目的化してしまった、という症状に思えてきました。チケット管理がうまく回っていたのに、ガントチャートの監視を厳しくしたら、チケットの中身よりチケットの進捗率が重要になって、チケットが忘れ去られた、みたいなイメージ。… https://t.co/u1P1tcsDZB"

りょうまさんのツイート: "そうですね。私はガントチャートは進捗の俯瞰とインデックスだと捉えてるので、その奥に詳細があるのが当たり前だと思い込んでいました。… "

昌。さんのツイート: "ひとは簡単に目的と手段が逆転しがちなので気をつけねばいけませんね。いつも、目的はなんだ?と自分にも問いかけるようにしてます。… "

【1-5】その真因は、本来のチケットは、プロジェクトで発生する変更要求、課題、作業、障害など、プロジェクトで管理すべき対象全てが起票されるはずなのに、進捗管理だけの側面だけ重視されてしまい、チケットの2重性がなくなって、スカスカの空っぽのチケットになってしまった、ということだと思う。

つまり、本来のチケットは、課題の検討履歴、変更要求の作業履歴というストックの側面を持ち、かつ、チケットの納期や作業進捗も合わせて管理できると言うフローの側面も持ち、2重性があったのに、担当者の作業進捗だけ気にするようになってしまい、フローの側面だけ残り、ストックの側面がなくなってしまった、というアンチパターンが発生したわけだ。

【2】以前、ISO9001のQMSの運用の現場を見た時、変更要求や変更管理に関するExcelの作業依頼書と、設計書やリリース手順書などのExcelドキュメントの2種類のExcel帳票が管理されていた。
その運用は非常に煩雑で、最新版のドキュメントが連携されなかったり、リリース漏れが発生したり、非常に手間がかかっていた。
今どき、Excel帳票で管理する現場はありえないと思うが、古い製造業ほど、Excel帳票がはびこっている。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

その原因も上記と同じ。
つまり、ISO9001で実現する時、Redmineでチケット管理せず、Excel帳票で管理する場合、作業依頼書という変更管理に関するフローの側面と、設計書やリリース手順書などの構成管理対象になるストックの側面は、2つのExcel帳票に必ず分かれる。
そして、その2種類のExcel帳票を常に最新化しながら、申請承認フローに沿って厳密に管理せねばならない。

【3】では、なぜ、Excel帳票の運用は必ず失敗するのか?

【3-1】なぜなら、昨今のように経営環境がすぐに大きく変化する場合、Excel帳票で逐一管理する運用は、その変化についていけないからだ。
変更管理の運用と構成管理の運用はシステム開発ではとても重要だが、2種類のExcel帳票で管理するのは煩雑すぎて、現実として運用できないだろう。

結局、Redmineのようなチケット管理ツールで、フローの側面であるワークフロー管理と、構成管理の側面であるソース管理連携機能の双方を実現しなければ、経営環境の変化のスピードにシステム開発そのものが付いていけいないだろう。

例えば、最初は課題チケットで起票したが、課題に対して複数の代替案を出して検討し、一つの解決案を決定した履歴を残す。
さらに、その対策の作業状況も履歴として残し、課題が解決されるまで、チケットに全ての情報が残す。
すると、そのチケットのステータスが変わるたびに、裏では、その時々の意思決定の状況が管理され、マネージャによる承認プロセスを経て、システムに反映されてリリースされていく。

例えば、最初は顧客からの変更要求の仕様変更チケットで起票したが、その変更要求の発端を記録しておく。
また、チームでそのアーキテクチャや実現方法を検討した経緯を記録しておく。
すると、そのチケットのステータスが変わるたびに、裏では、担当者の作業状態が管理され、マネージャや利害関係者の承認プロセスを経て、システムに反映されてリリースされていく。

つまり、当初は課題チケットや変更要求チケットだったのに、チケットが更新されるたびに、作業チケットの意味合いに変わり、チケットが進捗管理対象になる。
さらに、チケットが更新されるたびに、変更管理の承認プロセスの意味も込められて、チケットが変更管理対象にもなる。

すなわち、チケットはストックとフローという2重性の性質が一つの実体として実現されている。
チケット管理では、ストックとフローという2重性の性質を、マネージャやメンバーが深く意識しなくても運用できるような仕組みを提供しているわけだ。

【3-2】本来あるべき姿のチケット管理では、チケットに変更管理や進捗管理というフローの側面と、成果物の構成管理や課題や作業の履歴管理というストックの側面を故意に持たせることで、スムーズに運用させる。

一方、Excel帳票でそれらを管理しようとすると、フローの側面のExcel帳票と、ストックの側面のExcel帳票の2種類に必ず分かれてしまう。
なぜなら、ステータスだけ管理したいExcel帳票と、リリース対象の成果物として厳格に構成管理したいExcel帳票は、管理方法が大きく異なるので、具体的な実体として分けざるを得ないからだ。

すなわち、Redmineのチケット駆動開発は、2種類のExcel帳票の具体的な実体が1つのチケットに合体されている。
そういう背景を、チケット駆動で運用している人は、意識しているだろうか?

【3-3】Redmineでのチケット駆動開発では、メンバーはストックの側面のチケット管理を意識しているが、その背後では、変更に関する申請承認という変更管理、そして、進捗の作業状況の把握という進捗管理、というフローの側面も裏で持たせている。

2種類のExcel帳票で分けて二重管理している運用が、チケット管理では、チケットという1つの実体で管理できるので、非常に運用しやすくなる。

よって、Redmineのチケット駆動開発ではチケットに複数の意味を持たせて運用した方が上手く回る、と僕は思う。

【4】僕の経験上、メンバーはストックの面だけ意識してもらえばよく、フローの側面はそんなに気にしない方が、チケット管理は上手く回ると思う。
もちろん、変更管理や進捗管理は重要だが、その意識が強すぎると、チケットのライフサイクルが長くなり、チケット駆動のメリットが薄れるから。

チケットに対するフローの側面を意識し始めると、ストックの側面を忘れてしまう。
チケットのストックの側面こそが重要なのに、その部分が軽視された運用になってしまうのだ。
ガントチャート重視のチケット駆動開発が、空っぽのチケットを大量発生させるアンチパターンはまさにそれだ。

一方、ストックの側面ばかり強調すると、チケット入力の運用のコストが上がってしまう。
チケットは手軽に起票して、記録して欲しいのに。
誰も更新しなくなるRedmineは、ゴミ箱と同じ。

だから、チケット管理の運用では、フローの側面を強調しすぎると空っぽのチケットが増えて破綻するし、ストックの側面を強調しすぎると、誰もチケットに起票しなくなって破綻する。

チケットの2重性という奇妙な性質を活かすには、そのバランスが重要だ。
フローの側面だけ、ストックの側面だけ、という運用では、チケット駆動のあるべき姿を実現できないし、チケット駆動の効果が得られない。

そのバランスを維持するための運用ノウハウは、実は数多くの現場で暗黙知となっていると思うので、収集してみたいと思っている。

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

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

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。


| | コメント (0)

TRIZ(発明的問題解決理論)のリンク

マーケティング企画業の古典的本「アイデアの作り方」、メーカー技術者が創造的発明する時に使う手法「TRIZ(発明的問題解決理論)」に関する情報のリンク。
結論もなく、自分のアイデアのためのラフなメモ書き。

【参考1】
アイデアのつくり方(ジェームズ・ウェブ・ヤング) - Wikipedia

「アイデアの作り方」 ジェームス・W・ヤング 感想 - 人といる時にスマホを触るな

わずか100ページの薄い本。
率直な感想は、「アイデアとは、古いアイデアを新しい机においたものと同じ」みたいに連想した。

【参考2】
TRIZ(アルトシューラ) - Wikipedia

アルトシュラー『発明的創造の心理学について』(邦訳) | 産業能率大学 総合研究所

アルトシュラー『発明的創造の心理学について』(邦訳)

TRIZが普及していないわけ(歴史的背景) ? アイデアを出すためのコトバとイメージの使い方

TRIZの概要

【1】研修で、プロジェクトマネジメント技法の一つとしてTRIZが挙げられていた。
こんな説明だった。

「(TRIZ)とは、直訳すると発明的問題解決理論。ロシアの特許審議官が膨大な特許情報を分析して「相反する問題を同時に解決すれば発明になる」「現実の問題を一般的な問題に抽象化すれば解決策がいくらでも出る」といった発明の法則をまとめた問題解決の方法論。」

つまり、品質とコストの両立という、互いの解決策が矛盾するような課題であっても、TRIZを使えば、いくらでもアイデアが出てくるよ、という売り文句だった。
それが本当かどうかはよく知らない。

【2】でも、産業能率大学 総合研究所にあるアルトシュラーの原論文「アルトシュラー『発明的創造の心理学について』(邦訳)」を読むと、深い思索があることが何となく感じた。

【2-1】原論文PDFにある自転車の事例が面白い。

最初に発明された自転車には「伝動装置がなく、走行する時は両足で地面を蹴らなければならなかった」。
そして「前輪の軸にペダルを取り付けるという技術進化」が起きた。

次に、「ペダルによって走行速度の増加」による事故障害の課題に対し、ブレーキが発明された。
「その結果、駆動輪の直径を大きくし、これによりペダル 1 回転による自転車の進行距離を増大させるという形で、作業装置をさらに発達」したが、「駆動輪の直径をそれ以上増加させると、自転車走行の危険性が急激に高まる」課題が出てきた。

そこで、「伝動装置の変更(チェーン伝動の採用)」が発明されて、「チェーン伝動により、車輪の直径の大きさではなくて、足踏み回転数を増加させる方法で高速を得ることができるようになった」。

そして「空気入りタイヤが導入」されて、「伝動装置の新たな変更(フリーホイール機構の採用)」が行われ、現在の自転車が完成した。

【2-2】つまり、ある機能の改良は、各要素のバランスを崩すまで劇的に改良できるが、その矛盾が噴出すると、システムの全体的発展のブレーキになり、成長速度が止まる。
なぜなら、ある機能に関する課題があるが、その課題を解決すると、他の技術的課題が現れ、その矛盾は現状のやり方では解決できなくなる段階に到達するから。

しかし、その矛盾の除去が本来の意味での「発見」であり、その発見は、システムの機能の一部を根本的に変更することにつながり、その影響範囲が広いほど、他の部分にも抜本的な変更を施すことになる。

そういうストーリーであると理解した。

【2-3】TRIZの原論文を読んで、「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の一節を思い出した。

「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の感想: プログラマの思索

科学者とエンジニアの間には、宿命的な対立関係がある。

科学者の立場は、真実の探求、自然界の仕組みの探求、制約なしの研究の結果を重視する。
科学者は理想主義者。

一方、エンジニアの立場は、技術的課題の単なる解決ではなく、最も優れた方法で問題解決する。
限られた予算、開発スケジュール、納期の制約の下、「まずまずのところ」で折り合って解決する。
エンジニアはがんこな現実主義者。

つまり、エンジニアは、品質・コスト・納期のバランスという制約条件の中で、「ほどほどの品質」「ほどほどのコスト」「ほどほどの開発期間」で、最大の良い製品を生み出す。

その宿命的対立を乗り越えたら、すごく良い製品が生まれる、という話。
TRIZにも似たような雰囲気を感じる。

【2-4】但し、TRIZはソ連における膨大な特許から、そのアイデア発想方法を理論として生み出した背景があるので、そういう膨大な知識データベースがないと、本来のメリットを活かせない気もした。
課題を解決したい時、その課題に関連する技術情報が即座に収集できなければ、無い知恵をいくら絞っても、解決策は出てこないのでは、と思った。

つまり、「アイデアの作り方」と同じく、既存のアイデアを組み合わせるやり方に近い気もした。

TRIZ――10分以内に「それ、どうやって実現するか」を思いつく方法 (3/3) - ITmedia エンタープライズ

(引用開始)
筆者はTRIZの専門家から詳しいことを教えてもらう機会が幾度かあった。
TRIZを作った人々が分析した特許は非常に膨大であったが、その99%が40のパターンで表現できたと言われている。

逆に考えると「世の中にはパターンでは表現できないものが1%存在する」とも言え、人の知性のロマンチックな可能性をTRIZ創設者らが示唆しているように思えてならない。
真偽は定かではないが、筆者は少なくともこう考えている。目の前の100の課題に対して、この40個のパターンを使えばほとんど(99%)、何かしらの解決コンセプトが発案できる。
解ける問題は効率的にどんどん発案し、人間の知恵を絞るしかないこと(1%)にぜいたくに時間を使いたいものだ。
(引用終了)

【2-5】解決策をそういう組合せの問題に持ち込めるならば、その分野はソフトウェアが強い。
そういうアルゴリズムをプログラムで実装して、ひたすら組合せの結果を評価すればいい。

それは、機械学習、人工知能にも似たような匂いを感じる。
しかし、AIが全ての問題を解決できるわけではない。
たとえば、AIでも人間と同じく、過学習という罠にはまれば、そこから脱出できなくなる。

でも、量子コンピュータなら、トンネル効果を使えば、過学習から脱出できるかもしれない。


| | コメント (0)

2018/07/05

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアというものがあるという前提で、従来から研究されている信頼度成長曲線の理論を適用した論文が非常に面白い。
もし、この論文の指摘内容が実際のソフトウェア開発の現場に適用できるならば、そんなソフトウェアはアジャイル開発こそ向いている、と言えるし、アジャイル開発の有効性の範囲が特に最近は広がっている、という事実を補強できるのではないか、と思う。
ちなみに、この論文は@sakaba37さんから教えてもらった。

以下は、浅はかな理解の元でのラフなメモ書き。

【参考】
ソフトウェア・シンポジウム 2018 表彰論文

ソフトウェア・シンポジウム 2018 最優秀論文賞 [研究論文]バグ修正時間を考慮したソフトウェア最適リリース問題についての一考察

【1】研究論文の内容は、正直難しいです。
僕も細かな内容は分かってない。
しかし、言わんとする内容は、とても刺激的。

【2】従来のWF型ソフトウェア開発では、「バグ発見時間が遅いほど、バグ修正時間も長くなる」という前提で、いかにバグを早く発見して修正するか、さらに、バグを作り込まないように予防対策を行うか、という考え方が主流だった。

この発想は、製造業の源流管理ともマッチするので、日本のWF型開発では、上流工程や超上流工程でいかにバグを作り込まないように、漏れなく高品質なものを作って後工程に流すことばかり、考えるように仕向けられていた。

つまり、「バグ発見時間が遅いほど、バグ修正時間も長くなる」は正の相関関係を意味している。

【2-1】しかし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが存在するとしたら、どうなるのか?

もし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが世の中の大半を占めていたとしたら、今までの品質予防の対策ノウハウは無意味になるのではないか?
むしろ、バグなんか気にせずにいち早く作ってリリースして、ユーザの反応を見ながら修正していく方が効率的ではないのか?

つまり、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアとは、アジャイル開発が適用できるソフトウェアと同一視できるならば、ソフトウェア開発はアジャイル開発に特化してしまえばいいのではないか?

すなわち、「バグ発見時間が遅いほど、バグ修正時間が短くなる」は負の相関関係を意味している。

【3】この論文では、信頼度成長曲線という古典的理論を使って、「修正時間を考慮した最適リリース問題」として置き直して、モデル上で理論的な計算を行っている。
確率分布を使った計算なので、細かい内容はきちんと追わないと理解したとは言えないので、僕はすぐには分かってないが、下記の結果は理解できた。

【3-1】「バグ発見時間とバグ修正時間の相関関係」について、いくつかの前提をおいた上で、モデル上で計算を行った結果は、4ページの「表 1. 最適リリース時刻と最小総期待費用」で説明されている。

ここで、α:相関関数なので、
α=+1:完全な正の相関
α=-1:完全な負の相関
になる。

また、総期待費用 C(T) 、最小総期待費用 C(T*)である。

その結果、αが+1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が増えていくので、「バグを放置していたら、修正コストは増えていくよ」というメッセージなのだと常識的に理解できる。

一方、αが0から-1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が小さくなっている。
つまり、このモデルでは、「バグを故意に放置した方が、修正コストは最小になるよ」というメッセージを伝えている。
これは、従来のWF型開発における品質の源流管理という常識とは異なる結果だ。

【3-3】この結果は、反常識的で面白いが、「バグ発見時間とバグ修正時間の相関関係」の観点で読み直せば、ストーリーはよく分かる。
つまり、従来の源流管理重視の品質管理では、「バグ発見時間とバグ修正時間は正の相関関係」の前提で語っていたけれど、それはWF型開発しか頭にない人がそういう前提で語っているだけ、とみなせる。
「負の相関関係」の前提となるソフトウェアもあるのではないか?

常識で考えると「バグ発見時間とバグ修正時間は負の相関関係にある」ソフトウェアはすごく変だ。
なぜなら、バグを放置した方がバグを速く直せる、と言っているのだから。

しかし、MTBFを高めることに注力するよりも、MTTRを短くする方に注力するソフトウェア開発プロセスがあるように、「負の相関関係」の前提となるソフトウェアもあるはずだ。
たぶん、そのようなソフトウェアはアジャイル開発に向いているソフトウェアなのだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

実際、昨今のWebサービス開発では、いち早くリリースして、頻繁にリリースしながら品質向上していく開発プロセスが主流だ。
何年もかけて品質を作り込んで、ドカンと一発リリースするソフトウェアとは全く違う。

もちろん、そういうコストを掛けて品質を高く保つソフトウェアもあるし、従来はそういうソフトウェアばかりだったように思う。
今でも、航空宇宙や組込みソフトウェア、業務システムはそういう部類に属するだろう。

しかし、従来は周辺的な位置付けに過ぎなかったWebサービスのマーケットが広がり、皆が24時間スマホを触っているのが普通な現代では、アジャイル開発に向いているソフトウェアが多くなった。

とすれば、アジャイル開発に向いているソフトウェアでは、「バグ発見時間とバグ修正時間は負の相関関係にある」という事実と表裏一体なのではないか。

【4】但し、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張は、僕個人の意見に過ぎない。
上記の研究論文でも、そこまで触れられてはいない。
しかし、上記の研究論文では、理論上そういうソフトウェアが存在する前提で、モデルから何が言えるのか、を示唆している。

自分のラフなイメージとしては、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張が、上記の研究論文の発展形で保証できれば、アジャイル開発の有用性を証明できた、ということになる、と思う。

そのためには、実際のアジャイル開発の現場で、そのようなソフトウェアメトリクスを採取して、上記の研究論文の理論的検証が正しかった、という体験論文ないし実験論文が続編になればいいだろうな、と思う。

【5】信頼度成長曲線の理論は1970年代からずっと研究し尽くされていて、かなり枯れた理論と聞いているが、この研究論文では、アジャイル開発の要素を取り入れたモデルで考え直すと、古典的な理論から新たな知見が生まれる、という可能性を示唆している、と思う。
そういう意味では、久しぶりに自分の中ですごくホットになって、面白かった。

個人的には、「アジャイル開発はソフトウェア開発ですごく有効である」と証明できるソフトウェア工学の学術論文をもっと読んでみたいし、そういう論文集があると面白いだろうな、とも思う。


| | コメント (0)

2018/05/08

論文のお作法は、さかばさんから真似る

さかばさんのブログにある論文のお作法の記事がとても良くて、いつも参考にするのでリンクしておく。
以下、ラフなメモ書き。

【参考】
社会人のためのシンポジウム発表入門 リーン論文作法: ソフトウェアさかば

論文の善し悪しをサンプルで見る: ソフトウェアさかば

できる人を観察して勝負する: ソフトウェアさかば

さかば流・論文作法 その1 - 論文の構成 -: ソフトウェアさかば

さかば流・論文作法 その2 - 論文を書く上での注意点 -: ソフトウェアさかば

さかば流・論文作法 その3 - 良い技術 -: ソフトウェアさかば

【1】僕も論文を書くのは嫌いだったかな。
学生の頃、先生からいつもたくさんの指摘を受けて直すのに、OKの返事がもらえなくて苦労した。

今思い出すと、その理由は、論文特有の書き方を知らなかったから、だけでなく、経験した現実とあるべき理想の対立を自分の心の中で強く持っていなかったから、とも思う。
僕は世間にこういうことを主張したい、という熱い気持ちで書き出して、その内容を数多くの人に叩かれたり議論したりして、アイデアを鍛えて、内容をブラッシュアップしていく、という過程を、その頃は経験できていなかったから、とも思う。
ずいぶん自分のレベルが低かったと思う。

まず言いたい主張が先にある。
そこから、その主張がどんな問題を解決するのか、何が課題として今後の研究テーマになるのか、などの骨組みが決まっていく。

【2】さかばさんの下記のツイートが好き。

【2-1】
さかばさんのツイート: できる人は、頭の中で知識の構造を常にリファクタリングしている。凡人は、整理しないままで置いておくから活用できない。大学院で学んだ事の一つです。

僕はSEA関西の知的サロンのような雰囲気が好きなのだが、そこでは、アジャイル開発とか新しい技術とか議論していると、必ず定義を聞かれることがあった。
互いの議論によって、自分が持っている知識体系、理解している知識ツリーに入れば理解できたことになる。
その作業が、知識構造のリファクタリングにつながる。
世話人の方は、たぶんそういう作業を常にされているのだろう。

僕自身の経験でも、いつもポンチ絵を描いている。
モヤモヤしたアイデアを明確にするために絵を描く。
新しい知識を色んな観点で比較評価するために絵を描く。
絵を何度もリファクタリングして描き直すうちに、あるべきイメージが固まっていく。

【2-2】
さかばさんのツイート: @tunemage まずは論文で主張したい点を3つにまとめて、それを裏返して問題設定すると論文の概要ができます。それを端的に表現すればタイトル。用語を説明すれば背景になります。各段落を一行で表した箇条書きを作ってから書き出すと綺麗な構造になりますよ。

普通は、自分が言いたい主張が必ず先に存在する。
その主張から問題点を明確にして、主張を正当化する必要がある。
その作業は、「Justify」と呼ばれている。
数学ならwell-definedに相当するだろうか。

論文作成の技法part2~論文作成の観点 : プログラマの思索

Well-defined - Wikipedia

このJustifyの作業を「主張の裏返し」という言葉でさかばさんが表現されているのは凄いなあ、と思う。
自分の経験を振り返れば、主張と問題点に線を引いて因果になっているか、トレースできているか、自分でチェックしていたけれど、その作業と同じだったわけか。

問題を明確にするというJustifyの作業が重要な理由は、問題となる前提条件、スコープが明確にされなければ、主張したいアイデアが何を解決するのか、一方、現在の主張では解決できないので何が課題として残るのか、というストーリーを説明できなくなるからだ。

自分の主張で、全ての問題が解決するわけではない。
普通は解決できた部分はごく一部だけ。

でも、その主張のアイデアが優れていれば、未開拓の分野にどんどん適用されて、関連研究が広がる。
たとえば、科学者の論文でも、すごく偉い科学者が理論を打ち立てたら、その後続の凡庸な科学者は、その理論を使って細かい問題をしらみ潰しに論文を量産していく、というパターンが多い。
そういう凡庸な論文が多いので、それを関連研究として整理するのもまた一苦労、みたいな感じかな。

【3】論文作成のお作法であるロジックの組み立て方は過去にまとめていた。

論文作成の技法part1~論文の構造: プログラマの思索

【4】さかばさんの「リーン論文作法」の発表資料には、そういうノウハウが濃縮されている。
なので、さかばさんの「リーン論文作法」の発表資料はお勧めです。
ダウンロードできるので、印刷したり、スマホに常に持っておき、いつでも参照すると便利です。

| | コメント (0)

2018/05/06

Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスのリンク

最近、Markdownで資料を書いて、WordやPDF、epubに変換したり、RedmineやConpass等に書く場合が多い。
しかし、いつも表形式が書きにくい。
そこで、Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスをリンクしておく。

【参考1】
選択したExcelのセルをMarkdown形式でコピーするExcelアドインをリリースしました。 - nuits.jp blog

nuitsjp/CopyToMarkdownAddIn: Add-In for copying from Excel to Markdown

Excelのアドオン。
Excel上で右クリックした後、テキストに貼り付けるだけ。
こちらを愛用してる。

【参考2】
Excelの表をMarkdown形式に変換 - Qiita

Markdown Tables generator - TablesGenerator.com

Excel上でコピーして貼り付けるだけ。

【参考3】
Markdown で書いた試験仕様書を Excel に変換するツールを作った

Markdownのテスト仕様書からExcelに変換するツールを作られたらしい。

似たような例として、FreeMindのマインドマップからテストケースを自動生成するツールもあったな。
因子の組合せによるテストケース生成は、ツールを使った方が簡単。

FreeMindからテストケースを自動生成するテストツールFMPictをリリース - 千里霧中

fmpict/manual.md at master ・ hiro-iseri/fmpict

こんな本もあった。

『マインドマップから始めるソフトウェアテスト』を読んでマインドマップを書こう! - そこに仁義はあるのか(仮)

| | コメント (0)

2018/04/28

技術革新とエンジニアのキャリア形成にオープンソースコミュニティの存在が重要性を増している

Publickey主宰者のインタビュー記事を読んで、気付いたことをメモ。
ラフなメモ書き。

【参考】
Publickey主宰者・新野淳一氏に聞く、エンジニアのキャリア・スキルの磨き方、「稼ぐ力」の付け方 - GeekOut

【1】Publickey主宰者のインタビュー記事を読んで、印象に残った点は2つある。
一つは、クラウドとオープンソースにより技術革新の場がベンダからオープンソースのコミュニティへ移ったこと。
もう一つは、エンジニアのキャリア形成に、オープンソース活動やコミュニティ活動による貢献が重要性を増していること。

【2】現在では、技術革新の場はベンダーから発信されるよりも、オープンソースのコミュニティを中心に発信させる場合の方が多い。
たぶん、その事実もかなり知られている。

(引用開始)
取材するスタイルも昔とはずいぶん変わりました。かつてはベンダが一番情報を持っていたので、発表会に出席して、新製品や技術のことを取材していましたが、いまのメインストリームは明らかにコミュニティです。僕もオープンソースのコミュニティの情報や、フォローしているオープンソースエンジニアのTwitterを見て、業界動向をウォッチしています。
(引用終了)

上記の記事のように、一昔前は、IBMやMSなどの大企業の技術動向をウォッチするために、大企業のイベントに出向いて、情報収集するのが普通だった。
でも、今では、LinuxやRuby、Python、Wordpress、LibreOfficeなど数多くのオープンソースが市場を支配して影響を与えている。
これらオープンソースコミュニティに出向いて、優れたコミッタやそのリーダーをウォッチしたり、直接話したりする方が、情報収集が速い。

この変化によって、大企業よりも、優れた中小ベンチャーやコミッタの方がIT業界において、政治的影響力を増している、という事実が挙げられるだろう。
たとえば、UberやAirbnbなどのシェアリングサービスも一気に普及し、昨今のAIブームに乗って大きく成長している。

つまり、オープンソースを中心としたコミュニティが技術革新と新しいビジネスの創出を生み出している。
その変化にエンジニアも付いていかないといけない。

【3】すると、エンジニアのキャリア形成に、オープンソース活動が大きな影響を与えてきている。

【3-1】エンジニアがスキルを向上させるために、オープンソース活動に積極的に関わり、貢献することで、周囲に彼のスキルを認めてもらい、彼自身の価値を上げていく、という成長のらせん構造が生まれている。

(引用開始)
 そうすると、エンジニアの働き方やキャリアも変わります。それまでは、最新技術はほとんどベンダに集まっており、ベンダの技術に詳しい人が求められてきました。しかし、オープンソースという新しい価値観が生まれることで、コミュニティへの貢献がキャリアに好影響を及ぼし、スキルアップにつながるようになりました。そういう新たなエンジニアのヒーロー像が生まれたのです。

 あとは、やっぱりクラウドですね。クラウドの最大の特徴は、一言では表現できないジャンルの広さです。その分、クラウドを活用することは非常に難しくなっている。社内で学べる範囲を超えているんですね。あらゆるレイヤーに精通する必要がありますし、オープンソースやベンダの技術も追っていかなければなりません。技術だけではなく、仕事や業務についても勉強する必要があります。そういう包括的な知識は、単に仕事をこなすだけではなかなか学べないのです。会社の枠を超えて物事を学ぶ姿勢を保ち続けないと、クラウドをキャッチアップできないと思います。

 クラウドとオープンソースが出てきたおかげで、会社の中でキャリアを考える時代から、会社を超えて自分のスキルやキャリアを考える時代へと変化しました。そうでないと、エンジニアは自分のキャリア人生を生き抜けなくなってきています。Linuxが出てきた頃からそういう雰囲気はありましたが、クラウドの登場で、その傾向が一段と鮮明になってきた。僕はそう思っています。
(引用終了)

【3-2】似たような話として、下記の記事もあった。

会津大学で「これからのエンジニア像」についてお話してきました - インフラエンジニアway - Powered by HEARTBEATS

(引用開始)
これからのエンジニア像

この先とか言ってるけど、未来人じゃないから先に事はわからないよ
・なので歴史を踏まえて推測するね

ここ20年を振り返ると、ITは10年でスキルの価値がなくなる業界です
・最先端の貴重なスキル =(10年)=> ふつうのスキル =(10年)=> こどもでもできる

世間的なエンジニアの評価軸が技術領域ベースから価値ベースにシフトしてきたよ
・ネットワークエンジニア => Webサービスエンジニア...

みなさんはきっと75歳くらいまでは働く必要があります
・たぶん私もね

ホワイトカラーは一生勉強し続ける必要があります
・宿命ってやつですね

いまのうちにじっくり基礎から勉強の仕方・活かし方を身に着けておくとよいですよ
・基礎知識と、学びの習慣化をしておこう

とにかくまず学校の勉強をきちんと真面目にやるのが最高
(引用終了)

IT業界にいて、つくづく思うのは、身につけた技術は10年経つと陳腐化してしまい、無意味になってしまう可能性が高い事実だろう。
実際、Cobolやメインフレームでバリバリ、プログラミングして経験を積んで、部課長に成り上がった人達を見ると、彼らの話が既に時代に合わなくなっていることをいつも感じる。
そして、彼らの経験やノウハウが陳腐化されるのと同様に、自分もそうならないか、といつも自問している。

アジャイル開発は常識だ: プログラマの思索

ライフ・シフト」のように、人生100年時代の中で、現代を生きる人は皆、死ぬ直前まで働くことを前提に、一生勉強し続けることを準備しなくてはならないのだろう。

たとえば、昨今は、いわゆる文系の士業は人工知能で代替されるニュースが相次いでいるので、士業の受験者数がかなり減少していて、危機感を持つ人が増えている、という話も聞いた。
いわゆる士業のAI受難だ。
よって、士業だけでなく、普通のホワイトカラーも、価値を生み出さないエンジニアもAIで代替されてしまうリスクがあるのだろう。

AIによる代替可能性90%以上の士業は3つの士業 | 株式会社ネクストフェイズ

では、技術や知識を得たとしてもすぐに陳腐化してしまう時代において、どんな方針で働くべきなのか?

現状では、社内研修やOJTだけでは、エンジニアのキャリア形成は不十分だ。
むしろ、エンジニア自身が積極的に、オープンソース活動に加わった方がいい。

現代では、オープンソースコミュティが技術革新の発信源であるからだ。
だからこそ、オープンソース活動に加われば、自身より優れた開発者と交流することで、やる気も出るし、自身の能力向上にも役立つ。

自分にも銘じておく。

| | コメント (0)

2018/03/29

SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア

Swaggerを使うと、WebAPIドキュメントをExcel仕様書から脱却してシステム化することができる。
自分はまだ無知なので、以下は自分用のメモのリンク。

【参考1】
【連載】Swagger入門 - 初めてのAPI仕様管理講座 [1] Swaggerとは|開発ソフトウェア|IT製品の事例・解説記事

(引用開始)
システム開発のトレンドとして、マイクロサービス化が進んできています。モノリス(一枚岩)スタイルの開発に比べて、アプリケーションの単位は小さくなり、多くのサービスが構築されます。

Uberの配車ビジネスやAirbnbの民泊に代表されるデジタルビジネスにおいても、APIエコノミー化が進んできており、Google Map APIやTwitter APIなどさまざまなAPIを組み合わせて素早くシステムを構築します。
Programmable Webでは、2017年1月時点で16,590以上のAPIが検索可能で、2009年9月の10倍以上、2006年5月の90倍近くに達しています。

では、そういったマイクロサービス・APIエコノミーの開発現場では、一体どのようなことが起こっているのでしょうか。

例えば、Androidのアプリから叩いているサーバのAPIが機能追加されたために、3日間かけてテストして終わったと思ったら、いつのまにか更なる仕様変更が入っていた。APIのインタフェースを定義するドキュメントの仕様に従ってアクセスしたら、実は実装との乖離があり、うまく動かなかった。

このようにAPIプロバイダとAPIコンシューマ間の悩みはさまざまです。ただし、いずれもサービスインに影響を及ぼす重大な問題と言えます。インタフェースの向こうの世界は関与できないことが多いだけに、仕様と実装の乖離はあってはならないものなのです。
APIエコノミーを作るにあたり、このようなことを起こさないためにも、APIについて正しく記述した仕様書が必要となってきます。
(引用終了)

【参考2】
Swaggerとは何か? - プログラマでありたい

Swaggerを使ってインタラクティブなWeb APIドキュメントをつくる - Qiita

SwaggerでRESTful APIの管理を楽にする - Qiita

Swaggerの概要をまとめてみた。 - Qiita

【Swaggerの実例】
API リファレンス | SORACOM Developers

【1】Webシステムをモノリック・アーキテクチャからマイクロサービス・アーキテクチャで設計することで、まるで部品を組み立てるかのように、迅速にシステムを構築することが可能になった。
つまり、斬新なアイデアを実現するWebサービスを素早くリリースして、市場のニッチリーダーからシェア独占を狙って、先行者利益という独占利潤を得たいわけだ。

例えば、Uberの配車ビジネスやAirbnbの民泊。
日本なら、例えば、メルカリ、DMMとか。

現代は、これらシリコンバレー発祥のWebサービスが、自動車業界やホテル業界を直撃している、と言える。
よって、マイクロサービス・アーキテクチャで作られたWebサービスは、ありとあらゆる業界のビジネスモデルを一瞬にして破壊してしまう可能性が高い。
だから、こういうAPIエコノミーに対し、古い業界の人達も戦わざるを得ない。

【2】しかし、マイクロサービス・アーキテクチャの根幹となるWebAPIは、VerUpによってコロコロ変わってしまう問題がある。
そこで、I/F仕様をWebで公開して、即時に情報共有できるようにしたい。

つまり、マイクロサービス・アーキテクチャの実装基盤であるREST APIのI/F仕様を公開できるようなWeb基盤が欲しいわけだ。

【3】そこで、その候補として、Swaggerがあがる。
Swaggerの特徴は、「インタラクティブなWeb APIドキュメント」。

つまり、単純にWebへ公開できるドキュメントが作成できるだけでなく、リクエストを入力すればレスポンスを表示できる仕組みまである。
すなわち、APIをWebに公開できるだけでなく、使用しているAPIがVerUpしても使えるかどうか、事前に自動テストすることも可能。
これによって、Webサービスをリリースする時、利用しているAPIが使えなくなった、というリスクを減らすことができる。

たとえば、ソラコムさんのWebサイトが最も良い事例だろう。

API リファレンス | SORACOM Developers

上記の記事にもあるが、Dockerによるビルド環境構築やCIツールをSwaggerと組み合わせれば、マイクロサービスで組み立てたWebサービスの自動テスト、デプロイやリリース作業の自動化にもつながるだろう。
つまり、マイクロサービスで作られたWebサービスの品質向上、開発速度の向上にも役立てられるはず。

但し、Swaggerで全ての問題が解決されるわけではなく、まだ課題もある。
たとえば、Swaggerて゛のapi開発よもやま話の18ページにあるように、たくさんのAPIを一瞥できるような『オブジェクト構造図(仕様書のObjectの参照関係を階層構造で定義)』が欲しくなる。

【4】今の僕は、Excel仕様書からいかに脱却するか、というテーマを持っているが、その中でも、I/F仕様書は色んな意味で重要性が高い。

なぜなら、公開したI/Fというものは、自分のチーム以外の他チームも参照するので、説明責任が発生するし、I/Fの仕様はシステムのVerUpによって変わってしまう時が多いのに、その変更内容をExcelドキュメントへ反映する手間が結構かかるからだ。
しかも、I/FがVerUpで変わった、という事実を他チームにも随時連絡する手間も発生する。

よって、I/Fが変わったら、自チームがプッシュ通知するのではなく、他チームがプル通知で自動検知する仕組みの方が運用が楽になる。
そこで、SwaggerのようなWebAPIドキュメントの基盤を有効に活用できるだろう、と思う。

【4-1】ここで、I/F仕様書がSwaggerで置き換えられる可能性を考えると、現代という時代は、Excelドキュメントを一生懸命に書くよりも、仕様書というモノさえプログラミングする時代なのだ、という気がしてくる。

実際、単体・結合テストなどのテスト工程の作業は、TDDやCIなどの開発支援ツールでプログラミング作業に集約できる。
また、デプロイやリリース作業、そしてビルド環境や本番環境のインフラ構築作業も、DockerやGitHub、CIツール、AWSなどのクラウド環境などの技術によって、プログラミング作業で代替できるようになった。

今後は、要件定義や設計作業ではExcelドキュメントを書く、という作業も、きっとプログラミング作業で代替されるようになるだろう。
つまり、いちいち自然言語で要件や仕様を書くよりも、YAMLやJSONに似たデータ構造あるいはDSLによって、いきなりプログラムを書いた方が速いし、その後の保守更新も楽になる、という方向へ進化していくはずだ。

仕様書をプログラミング作業の本体であるテキストで代替できれば、Gitで管理できるし、そうすれば、TDD・CI・プルリクエスト・継続的デプロイなど昨今の開発支援技術の恩恵を受けられる。
よって、ドキュメントの情報共有が促進され、フィードバックを受けて修正すれば、仕様書の品質そのものも向上できるはず。

では、仕様書のExcel脱却の起点となる課題は何か?
答えは、Gitで管理できるか、そして、テキストからAPI仕様書や図表などを自動生成できるか、という課題に集約されるだろう、と思う。
幸いなことに、MarkdownやPlantUMLなどの記法でテキスト化すれば、HTMLやOfficeドキュメント、PDFへ自動生成するツール(Pandoc、MkDoc、他たくさん)で、今まさにたくさんの技術が実験されている。

この辺りの技術も、技術の進化の歴史の観点で今後整理していきたい。

| | コメント (0)

より以前の記事一覧