ソフトウェア工学

2017/02/27

Redmineの親子チケットの功罪

RedmineのFAQとアンチパターンを整理していると、最近は、親子チケットに絡む内容が多いような気がした。
Redmineは先進的なプロジェクト管理を行う実験場であり、まだまだ改善の余地はたくさんあると思う。
考えたことをラフなメモ書き。

【1】最近、ソフトウェア開発者以外の人達から、Redmineを業務に使えないか、質問を受ける場合が多い。
彼らの目的は、タスク管理や、昔のNotesの代わりの事務処理ワークフローに使いたいみたいだ。
Excel帳票やExcel管理台帳が溢れていて、それを何とかしたい、という動機みたい。

そういう場面に、Redmineは導入しやすいし、運用して効果も期待できる。
OSSで無料だし、小さく運用を始めて様子見した後、大人数へ横展開することもできる。

特に、大規模に使っていく場合、Redmineのメリットがとても良く出てくる。
つまり、Redmineのメリットである「親子プロジェクトの階層は無限」「親子チケットの階層は無限」を上手く適用できれば、多数の組織も管理できるし、多数の作業もまとめて管理できる。

換言すれば、Redmineの「プロジェクトやチケットの階層が無限に作れる」特徴は、とても柔軟な機能なので、いろんな業務に適用しやすい。
だから、色んな人達が色んな業務にRedmineを適用しようと試している。

しかし、話を聞くと、業務がRedmineに完全にフィットしない場面もあるらしい。
どうやら、特に親子チケットの作り方に問題があるような気がしている。

【2】では、Redmineを実際に運用した場面で、親子チケットを使った時にどんな問題が噴出しているのか?
色々集めてみた。

【2-1】親子チケットにし過ぎる

個人のToDoを子チケットで登録して、親チケットにぶら下げる人がいる。
他の人には不要なチケットだ。
チケットが乱発されて、登録した本人ですら、チケットの棚卸しができなくなる。

根本問題は、チケットの粒度があまりにも細かすぎる点だと思う。
解決策としては、他人と共有すべき作業内容に限定する運用ルールを作る。

僕が最も推奨するのは、TODOレベルは、チケットにチェックリストを追記する運用に変更することだ。
なぜなら、個人のToDOレベルのタスクが全て終わったことが、その人のチケットの完了条件とみなせば、他人と進捗状況を共有しやすくなるからだ。
つまり、個人のToDOはチェックリストにすべきだ。

たとえば、Checklistsプラグインを入れてもいいかもしれない。

Checklists - Plugins - Redmine

但し、チェックリストを作ったとしても、チケットに未チェックが残っても、チケットが完了できてしまうリスクもある。
その場合は、下記のように、完了できなくなるパッチを当てればいい。

Redmine Checklists pluginで未チェックの検証を雑に行う - Qiita

あるいは、プライベートチケットを使う方法もあるだろう。
プライベート機能を使えば、他人には見えないから、ToDOチケットは邪魔にならない。
しかし、共有すべきチケットが存在すれば、埋もれてしまうリスクもある。

【2-2】親子チケットで、開始日・期日・予定工数のロールアップを止めたい

よくある例は、WF型開発の案件で、親チケットにSEが開始予定日・終了予定日・予定工数を入力した後、子チケットにPGが実績の開始日・終了日・自分で見積もった予定工数を入力すると、親チケットの開始日・期日・予定工数が消えてしまう問題だ。

Redmineの本来の仕様は、「WBS 100%ルール」であり、WBSに漏れがあってはいけないから、親チケットは子チケットの情報をロールアップする。
しかし、WBS 100%ルールは、実運用に合わないケースが多い。
結局、WF型開発も綺麗に運用できるわけではない。

SQIP2015の講演後の質問でも、この質問が最も多かった。

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

実は、対処としては、RedmineのVer3から、Redmineの設定画面で「子チケットから独立」を選択することで解決できる。
また、親チケットの予定工数と、子チケットの予定工数の合計は別カラムとして表示されるので、問題なくなった。

しかし、この運用が本当に良いかどうかは分からない。
WBS 100%ルールを止めるということは、WBS作成の基本ルールを破棄していることだから。

【2-3】未完了のチケットが残っているのに、親チケットが完了できてしまう

これは、WBS 100%ルールではありえない問題だが、Redmineの機能には実装されていない。
実は、RedmineのVer3.4で対応済みだ。

2016年11月のRedmine開発状況 | Redmine.JP Blog(Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止)

Redmineの次期バージョン3.4の見所: プログラマの思索

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

「Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止」のパッチによって、WBS 100%ルールが実現できるおかげで、親チケットのステータスを明確に判別できる。

【2-4】親子チケットでどこまで深く階層化するか?

Redmineの実運用では、ExcelのWBSのように5~10階層までブレイクダウンしたい目的が多い。
つまり、ExcelやMSProjectみたいに、WBSの深い階層をRedmineチケットで表現したい。

しかし、WBS 100%ルールを厳格に運用するとデメリットが大きくなると感じている。

普通、タスクは階層化しやすい。
しかし、障害やQAは階層化に合わない。

そして、深い階層のチケットは、チケット一覧画面では見通しが悪い。
むしろ、ガントチャートが向く。
ガントチャートならば、階層構造が綺麗に表現されるからだ。
だが、Redmineのガントチャートで編集できない弱点がある。

また、深い階層のチケットのデメリットはいくつかある。
一つは、 性能が悪くなること。
浅い階層では問題ないが、かなり深い階層とか、数千件の子チケットを持つチケットの操作のパフォーマンスが悪くなるらしい。
そのパフォーマンス改善のパッチがRedmine本家に提供されたが、Ver3.4ではリジェクトされている。

2016年12月のRedmine開発状況 | Redmine.JP Blog (Defect #23318: 大量の子チケットを持つチケットで #lock_nested_set メソッドが遅い問題の改善)

実際、Redmineの実ソースでは、子チケットを表示する時に、select ~ for updateを使っているみたいだ。
つまり、ロックを故意にかけているので、性能が悪くなる可能性はある。

もう一つは、親子チケットを一括登録しようとすると一手間かかることだ。
実際、親チケットを採番しないと子チケットを一括インポートできない。
なぜなら、親チケットNoを採番しなければ、子チケットの親チケットNoを指定できないからだ。
すると、階層の数だけ、一括登録のインポート処理を繰り返し、その都度、親チケットNoを取得してはセットする手間が必要。
手作業で親子チケットは簡単に作れるが、MSProjectで作った5階層のWBSを一括インポートしたい需要はあるだろう。
どこかのツールで手軽に実行できないかな?

さらに、深い階層の親子チケットは、チケット保守が大変になる。
親子構造を変えにくかったりする。

また、バージョンが古いRedmineでは、WBS 100%ルールが実運用に合わないことは前に触れた。

そして、深い階層の親子チケットでは、WBS漏れを検知できるか?
要件チケットから成果物までのトレーサビリティをRedmineは実現できるのが、もう一つのRedmineのメリットだが、階層の深いチケットを作ると、WBSがどこかで漏れていたとしても、Redmine上ではすぐには分からない。
結局、CSV出力して、Excel上でWBS漏れを探した方が早いだろう。

あるいは、Lychee LACという有償プラグインを使って、Redmineの階層構造とトレーサビリティをツリー構造で図で表示する方法があるかもしれない。

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

【2-5】チケットの棚卸しがやりにくい

親子チケットにすると、チケットの棚卸しがやりにくそうに感じる。
最下層の子チケットを棚卸ししなければ意味がないが、どうしてもチケットが多すぎるからだ。
駄目なプロマネはRedmineのチケット一覧で頑張ろうとして、溢れたチケットに溺れてしまう。

チケット一覧で棚卸ししようとして詰まるみたい。
すると「放置されたチケット」「停滞したチケット」「乱発されたチケット」のようなアンチパターンが生まれてしまう。

個人的には、親子チケットを使わすぎず、ロードマップを使う方が良いと思う。
つまり、バージョン=納品日、締切日として運用して、ロードマップ画面でチケットを取捨選択する運用に切り替えるわけだ。
僕がRedmineを運用して、これがアジャイル開発の本来のマネジメントなのだ、と気づいた機能の一つ。

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

Redmineのロードマップ画面では、右クリックでチケット編集コンテキストメニューを出せるので、ロードマップ画面上で優先度を考えながら、チケットの属性を編集できる。

しかし、Redmineのロードマップ画面も機能不足と感じる。
ロードマップ画面で、チケットの優先順位を付ける機能がないからだ。

現状では、下記の3つしかやり方がない。
しかし、チケット枚数が増えるとロードマップ画面でも厳しくなる。

1・チケットの優先度を設定する
→なる早が増える

2・先行・後続の関連を付ける
→チケット操作が複雑。ガントチャート画面で編集できない。

3・バージョンを設定する
→チケット枚数が増えるとチケットが溢れる。本来は、チケットの並び順で優先度を付けたい。

本来は、ロードマップ画面で、チケットをD&Dして並び替えて、チケットの並び順で優先度を付けたいのだ。
このパッチは、実はRedmine本家で既に提供されている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

2016年9月のRedmine開発状況 | Redmine.JP Blog(Feature #22802: バージョン内のチケットをドラッグ&ドロップで並べ替え)

ここで、Scrumのプロダクトバックログでは、タスクカードの並び順が作業順序である。
つまり、開発者は、バックログの一番上からタスクカードを取り出して、作業をこなしていけばいい。
開発者は優先順位について考える必要はない。

一方、プロジェクトオーナーやプロダクトオーナーは、プロダクトバックログを常に精査して、どのフィーチャの実現を優先すべきか、取捨選択して、並び順を優先順位として考えればいい。

つまり、Redmineのロードマップ画面はもっと改良できる余地がある。
Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineでは、ロードマップ画面の並び順だけでなく、チケット一覧画面の並び順も考慮すべきでは?という議論があるが、それはナンセンスだ。

チケット一覧画面は、クエリによってある特定の検索条件でチケットのリストを抽出だけの機能だ。
しかも、ソート順も検索条件の一つになっている。
そもそも、D&Dでチケットの並び順を変更する必要もない。

一方、ロードマップ画面はリリース計画で使うべき機能だ。
この画面こそが、チケットの取捨選択を行うべきRedmineの中核機能だ。
だからこそ、Redmineにもっとアジャイル開発の特徴を取り込みたいのだ。

個人的には、Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineに数多くの人が「+1」のコメントを付けて、Redmineの機能の一つとして実現して欲しいと思う。

【3】こう考えてみると、Redmineは先進的なプロジェクト管理を行う実験場であり、機能面でも運用面でもまだまだ改善の余地はたくさんあると思う。
チケット管理には、プロジェクト管理を効率化させる可能性がまだまだ秘められていると思う。

【追記】
皆さんのツイートがとても興味深いので、メモしておく。
もっと、皆さんの経験に基づいた奥深い議論がしたい。

門屋 浩文さんのツイート: "@akipii WBS関連で親子関係についてはいつも議論になりますがプロジェクトのベースを合わせることを意識した説明、意識づけをしてます ロードマップは合わないかなと思い説明はしてません"

akipiiさんのツイート: "@MadoWindahead 個人的には、ロードマップ画面こそがRedmineの中核機能と思います。でも機能が足りない。チケット一覧画面で皆頑張ろうとしすぎ。親子チケット、親子PJの運用方法はまだまだ改善の余地がある。"

ニートン 岩崎さんのツイート: "親子チケットは罪しかないので、親子チケット作らないようにして、それに該当するのはカテゴリやマイルストーンで代用してる https://t.co/vx7eXRiBPZ"

akipiiさんのツイート: "@neeton_iwasaki Redmineの親子チケットや親子PJは、メーカーのような機能別組織にとてもマッチしてます。親チケットは設計部門が作り、製造部門が子チケットにタスクをぶら下げて、進捗管理するとか。多分、日本のSIやメーカーは親子チケットが好きなのでしょう笑"

| | コメント (0)

2016/12/28

チケット駆動の罠~複雑さはチケットの粒度に関連している

チケット駆動の罠の記事をメモ。

【参考】
JIRAに死を | TechCrunch Japan

(引用開始)
ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。
ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。
JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。
ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。
(引用終了)

tadashi-aikawaさんのツイート: "本文にも書いてあるけど JIRAをディスっているのではなく JIRAの使い方をディスっているだけ。 Confluence使えばおけ JIRAに死を | TechCrunch Japan https://t.co/pNEqwe12Ex via @jptechcrunch"

akipiiさんのツイート: "チケット駆動の罠か。なるほど。RT @arichika: 派手なタイトルの割にちゃんと読めば、チケット駆動が陥りやすいミスが書かれていると思う。プロダクト・サービスの全体像が見えにくくなる、という事。... https://t.co/TB8O1uTEA6"

宮乃ぺこ@木曜東ア34bさんのツイート: "JIRAに関してというより、システム全体をみようねって話 JIRAに死を | TechCrunch Japan https://t.co/Nk3mms8Ryg @jptechcrunchから"

Takeo Hashimotoさんのツイート: "煽りタイトル良くない。そのようにデザインされていない道具をそのようにデザインされていない目的に無理やり当てはめようとしてもうまくいかないのは、ある意味当たり前。原文見たら本当に death って書いてあって呆れた。/ JIRAに死を https://t.co/iEXy4qUFUm"

Mass Kanekoさんのツイート: "「ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。」 少なくともAtlassianはそれを推奨していないのでは。 JIRAに死を | TechCrunch Japan https://t.co/YfCfN4F9GW"

akipiiさんのツイート: "Redmineのチケットも同じ。「デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

akipiiさんのツイート: "「ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元するという考え方」「ソフトウェアプロジェクトをチケットの集合で表すという考え方」JIRAに死を | TechCrunch Japan https://t.co/M54P4FBt3f"

Takafumi Ikedaさんのツイート: "分かるよ。優れた要求仕様はエッセイのようになってるべきだと思う。ジョエルスポルスキーが言うみたいに。でもそうするといつ出来上がるのか予想できないプロジェクトになりやすいけど。経験上。 / “JIRAに死を | TechCrunc…” https://t.co/vzLYSENUZB"

Yamamoto hiroyukiさんのツイート: "ストーリーやタスクは完成しているかしていないかのいずれかと考えるのはアジャイルマネジメントのベストプラクティスだ。著者はそれに異論があるようだ。 | TechCrunch Japan https://t.co/9LjDHX09fI"

【感想】
Redmineのチケット機能はとても優秀だと思う。
理由は、チケット構造をツリー上に展開できるおかげで、WBSやタスクカードなどのような構造をチケットの関連として実現できるからだ。
WBSをチケットに一度登録できれば、ガントチャートであれ、ロードマップであれ、サマリであれ、好きなようにチケット集計のビューで色んな角度で分析できる。

しかし、チケット管理をやりすぎると、思ったほどの効果が出ない場合がある。
@arclampさんが以前、下記の記事を記載されていたのを思い出す。

チケット駆動開発で作業管理はしないほうがいい - arclamp

また、第11回東京Redmine勉強会のアンケート結果でも、「全てチケット化するのは非経済となるシーンもある点です」という声もあった。
たぶん、数多くの人たちが試行錯誤しながら、Redmineのチケット管理の可能性を試している。

個人的には、上記の記事のような指摘から発生する問題の根本には、チケットの粒度があると直感する。
WBSであれ、ソフトウェアやマスタの構造であれ、さほど複雑でなければ、少ないチケットの枚数で表現できる。
チケットの枚数が少ないならば、外部環境からの影響でチケットの構造に変化が発生したとしても、その修正コストはさほど大きくないし、受け入れられる。

しかし、WBSやソフトウェアの構造が複雑になり、チケットの枚数が非常に多くなれば、その構造を実現して、最新の現状と連動させるように同期し続けるのは非常にコストが大きくなる。
チケット保守のコストが大きくなってくるからだ。

ソフトウェア設計では、ソフトウェアの複雑さを複数のレイヤーで分割し、粒度や抽象度を上げることで、その複雑さを軽減しようとする。
チケット管理でも、チケットの親子関係や親子プロジェクト、バージョンなどの機能によって、大量のチケットをレイヤーで分割して、枚数を制限することで、チケット管理の保守コストを受け入れ可能なレベルまで落とす。

つまり、チケット管理が駄目なのではなく、複雑さをどのように手なづけるか、ということが本来の問題なのだと思う。
それは、ソフトウェア工学の古くからの問題であり、あちこちの場面で出てくる。

但し、Redmineのチケット管理では、複雑さを軽減するためのレイヤーとなる機能が限られている。
たとえば、親子チケット、関連チケット、親子プロジェクト、バージョン、カテゴリなどしかない。
それらの機能を増やした方が良いのか、それとも、それらの機能の使い方をもっと工夫すべきなのか。

今の僕の考えは、Redmineの既存の機能を使って、チケット管理の可能性をもっと研究してみたい。
まだまだ色んな可能性を秘めているはずだ、と思う。

| | コメント (0)

2016/12/06

品質保証部はソフトウェア組織のボトルネックなのか、ソフトウェアチームに同化すべきなのか

平鍋さんの記事を読んで、品質保証部はアジャイル開発のボトルネックなのか、必要な組織なのか、いろいろ考えてしまった。
主張のないラフなメモ書き。殴り書き。

【参考】
QA to AQ: Quality Assurance から Agile Quality へ - Qiita

HARADA Kiroさんのツイート: "明後日開催です。英語で開催ですが、ゆっくり質問の時間はありますので、ぜひ。/ "品質保証からアジャイル品質へ入門コースー品質もアジャイルになるための価値、プラクティス、パターンー" https://t.co/m9eXSwIExq @Eventbriteさんから"

(引用開始)
よくアジャイル開発についての質問で、「品質保証はどうするのですか?」と聞かれることがあります。
日本の大企業の中には「品質保証部」という組織があり、そこが出荷判定をしたり、最終的な製品のQA(Quality Assurance)についての責任を持つことがあります。
その部署が、現場のアジャイル開発にどのように関わるのがよいのか、という質問です。
ひいては、メトリクスの取り方(既存の品質のメトリクスや、バグ収束曲線が当てはまらない)にはじまり、「どのタイミングで」、「どういった体制で」関わるのか、という質問です。
日本でアジャイル開発の導入が進まない、もしくは懐疑的に考える人が多いのは、この部分にあると思います。
(引用終了)

上記の指摘は、現場でよく感じる。
メーカーのソフトウェア子会社、メーカーの情報システム部門からスピンアウトしたSIであれば、品質保証部という組織が普通はある。

製造業では、品質保証部という部門はとても存在意義があるし、ものづくり日本の品質管理技法を発展させてきた輝かしい歴史があった。
しかし、ソフトウェア開発で品質保証部が絡むと、あまり良い話を聞かない。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

製造業では、3S活動によって、生産プロセスを単純化→標準化→専門化して、製品や生産工程の品質のばらつきを無くす。
そして、その活動をQCストーリーに落とし込んで、PDCAサイクルに組み込んでいく。

製造業の生産プロセスでは、品質が安定した製品を大量生産するために、プロセスを標準化する。
標準プロセスを作るために、各工程の作業へ細分化して、各工程の仕掛品の品質をチェックして、品質のばらつきを原因特定して解決していく。

しかし、ソフトウェア開発では「プロセスの標準化」という活動が有効に活用できない。
正直、効果が出ているとは思えない。
システムのインフラ、開発環境、プログラミング技術が日進月歩で変わるために、その変化に標準化活動が追いつかないのだ。
むしろ、古くなった開発プロセスを現場に押し付けるような立場になっていると思う。

では、ソフトウェア開発では品質保証という部門は不要なのか、と言われるとそうでもない。
SIにいると、形骸化した品質保証部の代わりに、開発案件の受注時の見積りレビューやリリース判定を行う役割をPMOのような組織が肩代わりしている場合が多い。
たとえば、見積りやプロジェクト計画が甘くないか、リリースしてクレーム対応に追われるリスクがないか、などを精査する。
つまり、製品の出荷判定を品質保証部がチェックするように、PMOがリリース判定を行っている。

そのPMOは、製造業のISOシリーズのように、CMMIなどの標準プロセスを策定して、ソフトウェア品質を確保しようとするが、実際はなかなか上手くいかない。

では何が違うのか?
ぼんやりしていて、その理由ははっきり分からない。

但し、上記の記事を読むと、「品質保証部」対「開発チーム」という牽制の関係ではなく、2つの組織をばらして、品質保証部メンバーが開発チームに混じって作業する方が上手くいく、という指摘をしているように思える。

つまり、運用チームと開発チームが組織的に分割され、チームが牽制し合うことで不正な作業をチェックする仕組みではなく、昨今のDevOpsのように、チームをシャッフルして、ペアプロのように共同作業していく方向性が良いと示唆しているように思える。

日本人も日本の組織も、QCサークルのような文化があったのだから、本来はペアプロのような共同作業は、日本人にフィットしているはずだと思う。
日本人は本来、トップダウンによる変革よりも、ボトムアップによる改善の方が向いているのだろうと思う。

しかしながら、そのやり方は、IT全般統制のような法律があるがゆえに、日本ではなかなか浸透できない現実もある。

ITに係る全般統制とDevOpsの緊張関係: プログラマの思索

昨今は、組織的不正を行わないように、組織が互いに牽制し合うように組織構造を作ることを勧められているために、日本の現場にそのような風潮を取り込むと、各組織の意思決定が部分最適化しすぎてしまい、全くうまくいってない。
なんだかな~と思ったりもする。

少なくとも、IT業界における世界の潮流は、サイロ型の組織構造をばらして、小さなチームに編成し直し、アジャイルに行動する方向へ進化している。

組織構成の考え方を変えれば、その潮流に乗れば、日本のソフトウェア組織も適応できるのではないか?
品質保証部はソフトウェア組織のボトルネックではなく、ソフトウェアチームの一部分に同化できるのではないか?
すると、ソフトウェア開発では、品質保証部は解体されて、ソフトウェアチームに同化されるべきではないか。
たぶん、DevOpsもその流れ。

この妄想をいろいろ考えてみる。

| | コメント (2)

2016/11/12

日本の品質管理がISO9001やシックスシグマに変わっていった歴史

最近、日本の製造業の品質管理に興味を持って、色々あさっている。
TQM品質管理入門」を読んだら、日本の品質管理がISO9001やシックスシグマに変わっていった経緯が書かれていて分かりやすかった。
以下、自分の理解でラフなメモ書き。
メモなのでロジカルでない。

【参考1】
今、あらためて、日本自動車産業の「ものづくり」について考えよう | 住商アビーム自動車総合研究所 自動車業界コンサルティング

(引用開始)
日本型ものづくりの基礎に貢献したのはW・エドワード・デミング博士だろう。
彼は統計学者として戦後初の1951年国勢調査計画立案に携わる傍ら、品質管理技術の専門家として日本科学技術連盟の招待を受け、日本の製造業経営者に対し統合的品質経営(TQM)を説いて歩いた。こうして日本のものづくりは体系化され、力を付けた。

1980年代、日本の製造業、特に自動車産業が勢いを増す中、米国マサチューセッツ工科大学(MIT)が中心となり、日本の自動車産業における生産方式を研究し、その成果を再体系化・一般化し、「リーン(=痩せぎす)生産方式」(LPS)と命名した。その後、LPSの概念は欧米製造業に浸透し、ゆくゆくは日本本国に逆輸入された。

1990年代末、日本にてバブル経済、金融不況と苦境が続いた後、再度、自動車産業を中心に日本の製造業が徐々に復活を見せた。この時、日本は、単なる製造を超えた日本古来に由来する日本の強みと伝統の象徴とすべく「ものづくり」と命名し、「ジャパンブランド」の一つの軸に位置付けた。

斯様な歴史を経て、「ものづくり」の概念は今日に至ったが、特にリーマンショック以降、それを取り巻く環境諸般が著しく変化する中、またもや、大きな転機に差し掛かっているものと考える。

リーマンショック前後より電機関連領域における日本の製造業の地盤沈下が起こった。
続いて2010年以降、自動車産業においても大規模なリコールが発生し元来の「品質神話」に疑問符が付いた。
更に昨今では、消費者の「モノ離れ」とか、「モノからコトへ」とまで言われる。「モノ=所有文化=時代遅れ」という感じすらある。
一方で、欧米では、IoTとか、インダストリー4.0とか新しい概念が生まれ、GEをはじめ「製造業の復活」と言われている。

こうした一連を見るに、「『ものづくり』とは一体何だろう」と改めて問題提起をし、皆様と一緒に考える契機を作りたい。(後略)
(引用終了)

【1】引用元のURLを忘れたが、下記のような解説があった。

(引用開始)
 品質管理のさまざまな新しい方法の開発によって、統計学は大量生産時代の必須の技術として定着していきます。第二次大戦後の日本の品質向上は、米国ではミラクルと考えられた時期がありますが、1980年代のMITのレポートでは、日本の産業界が統計的方法を活用していることを一つの原因としています。
 これについては、デミングが1950年に日本で行った講義以来、石川馨(特性要因図)、田口玄一(ロバストパラメータ設計)、赤尾洋二(品質機能展開)、狩野紀昭(狩野モデル)といった新たな管理技術を開発した日本の先生方の貢献が大ということができるでしょう。
(引用終了)

(引用開始)
品質管理は管理図に始まり、管理図に終わる
(引用終了)

つまり、製造業の品質管理は、大量生産する時に製品の品質のバラつきをなくすために、管理図や特性要因図などのQC7つ道具を編み出し、それら技法を洗練させてきたのだ。
品質管理の技法の背後には、統計学、特に検定や回帰分析の理論がある。
だから、品質管理の技法は、統計学の理論がバックにあるので、廃れないし、理論的に強固なのだと思う。

そして、日本の「品質管理の総本山」は「日科技連」。
高校生の頃に日科技連の数学の本を読んだら、普通の数学と違うなあ、と思っていたが、その理由は、僕が統計学を知らなかったので、違和感が合ったのだろうと思う。

しかし、今ではこういう製造業の品質管理の技法が普及しているとはあまり思えないのは何故だろうか?

【2】「TQM品質管理入門」を読んだら、日本の品質管理がISO9001やシックスシグマに変わっていった経緯が書かれていた。
どうやら1980年代のアメリカで、日本の製造業の品質管理を徹底的に研究し、アメリカ独自の理論に発展させていったみたい。
それが、シックスシグマらしい。

TQM品質管理入門」を読むと、アメリカのシックスシグマと日本のTQMの違いは、アメリカはトップダウンによる標準化であり、日本はボトムアップによる教育。
たとえば、品質管理の技術者をグリーンベルト~ブラックベルトのようにレベル分けする点は、CMMIに似ている。
「特性要因図の目的の一つは教育」と言われるように、日本企業ではOJTによる社員教育を重視してきたが、昨今の成果主義制度のために、OJTが機能しなくなっているように思える。

最近、職場で「OJT」が機能しないのはなぜなのか?(中原淳) - 個人 - Yahoo!ニュース

もう一つの流れはISO9000シリーズ。
品質管理をきちんとやっています、という国際的な免許が公開され、グローバルスタンダードになってしまったために、日本の製造業も取得せざるを得なくなった。
ISO9001の中身はTQMと同じだが、日本企業では、ISO9001の維持のために膨大な管理人員が割かれているデメリットが大きいのではないか。

【3】一方、欧米では、日本の製造業の品質管理を徹底的に研究し、シックスシグマやISO9000シリーズを生み出しただけでなく、ソフトウェア開発においても「アジャイル開発」という概念を編み出した。

アジャイル開発の源流には、日本の製造業の品質管理があると聞くが、その理由が知りたくて、今も品質管理の文献をあさっている。
個人的には、製造業の発想とソフトウェア開発の発想は全く違うと思っているので、どうしてもそれが密接に関連しているという理由が腑に落ちないからだ。
欧米人がどのように文脈を変えてきたのか、という観点で今も読んでいる。


| | コメント (3)

2016/11/03

日本のアジャイルは導入部分ばかりで終わっている

はてぶがすごく多い牛尾さんの記事を改めて読んでみた。
「日本のアジャイルは導入部分ばかりで終わっている」という主張に共感した。
以下は自分の理解のラフなメモ書き。
特に主張はなし。

【参考】
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

日本でアジャイル / DevOps 導入が進まないのは「文化」を変えないから - メソッド屋のブログ

僕もアジャイルコミュニティでずっと活動していて、コミュニティイベントでアジャイル開発の事例紹介のために講師をお願いしたり、自分達の事例紹介をやったり色々してきた。
そんな経験をもう10年近くやっているけれど、何となく腑に落ちない部分もあった。

アジャイル開発の事例の講演は、ほとんどが、アジャイル開発の導入で終わっていて、それから先の発展系があまりにも少ない。
チームのメンバー、上司をどう巻き込んで、アジャイルなチームを作ったのか、それをどう定着させたのか、どのようにアジャイル開発を標準化プロセスに組み込んだのか、という話ばかりを、10年も同じようなレイヤーでずっと話し続けている場合が多い。

そんなモヤモヤ感を持っていた時に、牛尾さんの記事を読んで、ああこれが原因なのかな、と思ったりした。

日本では、ソフトウェア開発案件はビル建築や製品製造のような一括請負契約が基本であり、契約時のスコープ固定、検収による支払いという制約のために、スコープ変更の開発がとてもやりにくい。
また、日本のソフトウェア文化として、製造業の成功経験が大きすぎるために、標準化・専門化によるプロセス改善に偏りがち。

そんな組織風土、組織構成の中でアジャイル開発を実践しようとすると、牛尾さんの言う通り、アジャイルの知識うんぬんよりも、「日本の商習慣の中で如何にアジャイルの能力を最大限に発揮できるよう「調整」したり足りないところを「埋めたり」する能力」の方が重要になってくる。
つまり、アジャイルの深い知識よりも、組織内の根回しの方が、日本のアジャイルな現場で重要なキーポイントの一つだ。

つまり、「アジャイルの本質を掴んだまま、日本の請負発注形式や、品質監査などに対応できる」かという問題に対し、日本の商環境の制約条件の中で、色々苦労した経験事例も多い。
だが、牛尾さんの言う通り、「しかし、請負発注や、正直、アジャイルにおいては意味のないような品質監査に適応することで、本来のアジャイルの実力を引き出せたとは言えなかった」と思う。

さらに、「第二世代のアジャイルブーム」であるScrumによって、「自分のところでリスクをかぶって、アジャイルが生む本当のビジネス価値を取ろう」とする開発手法を試す現場も現れた。
このScrumに関する事例はとても有意義なものが多いと感じる。
今までのアジャイル開発で暗黙知とされてきたノウハウが、言葉やプラクティス、プロセスフレームワークとして定義されたように思えるからだ。

一方、アジャイル開発を組織に導入するための根回しに関するお話の事例がとても多くて、そのような傾向の講演は僕はあまり好きではなかった。
つまり、平鍋さんの言う「アジャイルのレフトウイング、ライトウイング」の絵で言えば、レフトウイングの「チームマネジメント」や「組織マネジメント」に関わる話はあまり好きではなかった。

アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:オルタナティブ・ブログ

むしろ、アジャイル開発が好きであり、アジャイル開発を実践したいと思うならば、もっと技術にこだわって、技術重視で活動すべきではないか、と思っていた。
たぶん僕の興味は、開発プロセスを支援するツール群、本来のシステムを作るためのモデリング技法にあるからだろうと思う。

そして世界の潮流では、アジャイル開発の導入が一段落した後、DevOps、マイクロサービスアーキテクチャなどの技術が注目されている。
いつまでもアジャイル導入で停滞しているわけではない。

マイクロサービスアーキテクチャ」や鈴木雄介さんの本「Cloud First Architecture 設計ガイド」を読むと、従来のシステム設計技法が大きく変わりつつある印象を受ける。

| | コメント (0)

ソフトウェア工学は未成熟なプラクティスによって重大な阻害を受けている

平鍋さんの資料にある「ソフトウェア工学は未成熟なプラクティスによって、重大な阻害を受けている」の文言にビビッときた。
以下は思いつきのメモ。
特に主張はなし。

【参考】

SPI Japan 2016 | イベント | 日本SPIコンソーシアム

現場から始めるアジャイルの技術プラクティス

ソフトウェア工学の方法論と理論 1. 目的とスコープ(Purpose and scope)

SEMAT “Call for Action” の日本語訳 - とあるソフトの開発記録

アジャイルは”再び"死んだ

(引用開始)
ソフトウェア工学についての後悔
Tom Demarco ソフトウェア工学、そのときは去った。
Ed Yourdon ソフトウェア工学に大切なことは?
Barry Boehm あの指数曲線は間違いだった。
Ivar Jacobson ソフトウェア業界は、ファッション業界のようだ。
Tom Gilb ソフトウェア工学は定義を間違った。
(引用終了)

(引用開始)
Ivar Jacobson
ソフトウェア工学は未成熟なプラクティス(immature practices)によって、重大な阻害(gravely hampered) を今日受けている。
例えば、具体的には以下のように:
言葉の流行が、工学の一分野というよりファッション業界のようだ。
しっかりした広く受け入れられた、理論的基礎の欠如。
非常に多くの方法論(methods)とその派生。
またそれらの違いがほとんど理解されずに作為的に強調されている。
信頼できる実験的評価(experimental evaluation) と妥当性確認(validation)の欠如。
産業界の実践(industry practice)と学界の研究 (academic research)の乖離。

私たちは、ソフトウェア工学を堅固な理論および検証された原則とベストプラクティスを基礎として、再建するプロセスを支援する。そのプロセスは、以下の特徴を備えている。
広く合意された要素からなる、特定用途に拡張可能なカーネルを含み、技術の問題と人の問題の両方を扱い、産業界、学界、研究者そして、ユーザに支援され、要求とテクノロジの変化に応じて追随できるような拡張性を備えている。
(引用終了)

「ソフトウェア工学」という言葉は、たぶん、IT技術者ならば、愛憎の両面を持つ言葉だろうと思う。
いつも現場で混乱していて、その解決の手がかりになるような、厚い雲から差し込む光のように感じるけれど、実際に使おうとしたら、そう簡単に結果は出ないし、使いにくい。

個人的には、ソフトウェア工学は、製造業の品質管理やPMBOKのように、汎用化された知識体系として提示したいけれど、問題解決の適用領域が時代と技術に依存するために、その範囲がとても狭い。
そして、技術の陳腐化が激しいために、使える期間がとても短いがゆえに、工学と言いづらいのだろうと思う。
工学として使える手法は、夏日のアイスクリームのように、一瞬だけ使えて、溶けて無くなる、みたいな。

それから「プロセス」という言葉がいつも引っかかる。
普通の感覚では、「プロセス」は業務フローや業務のワークフローのような、ある定型的な手順を指す。
しかし、ソフトウェア開発をプロセスとして定義しようとすると、各案件の開発手順は、環境・組織・技術・要件などによって異なり、それらを統一ないし標準化することがとても難しい。
むしろ、標準化しても、すぐに陳腐化してしまい、使えなくなる。
誰でもいつでも使える「プロセス」という発想自体がおかしいのかもしれない。

つまり、物理の法則や数学の公理系、製造業の品質管理、製造業のIEとは違い、ソフトウェア工学は、汎用的な工学として成立できていないように思う。
その根本問題には、問題解決の領域が狭すぎる、問題解決の鍵となるアイデアの生存期間が極端に短すぎる、ということがあるのではないか。

でも、矛盾しているが、ソフトウェア工学やプロセス改善について、自分なりに考えて試行錯誤することには意味があると思う。
そして、その問題の解決の糸口に、オープンソースやアジャイル開発があるように直感的に思う。

| | コメント (0)

2016/10/19

JDMF2016講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になる

JISA Digital Masters Forum2016 「~Digital Business in Action~いまこそ、ソフトウェアで「!(革命)」を~」というフォーラムが10/21金に東京で開かれるらしい。
その中の講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になるのでメモ。

【参考】
JISA Digital Masters Forum2016 「~Digital Business in Action~いまこそ、ソフトウェアで「!(革命)」を~」

JISA Digital Masters Forum 「JDMF2016」タイムスケジュール

JDMF2016プログラム詳細~ 『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』

JDMF2016プログラム詳細PDF

(引用開始)
22 経験報告
『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』
宮本 陽一(三菱スペース・ソフトウエア株式会社 鎌倉事業部 宇宙第一技術部)

当社既製品の派生開発では、非効率な再利用(場当たり的な再利用)という課題に直面している。
再利用性の効率を上げるアプローチとしてプロダクトライン型開発への早期移行を試みる中、当社の開発を支える開発手法や環境(チケット駆動開発基盤)にプロダクトライン型開発を融合させる方法(Feature on TiDD)を見出した。
本報告は、その融合方法と評価実験を行った結果に関する事例報告である。
(引用終了)

下記に簡単な説明を付したシステム設計一覧のPDFが公開されている。

「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

【1】チケット駆動開発基盤で使われるツールがRedmineであると仮定した時、プロダクトライン型開発とは、仕様が微妙に違うが似通っている多数の組込ソフトウェア製品の開発であろうと推測する。
チケット駆動開発とプロダクトライン型開発の相性が良いだろう、という考えは以前たくさん書いた。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか: プログラマの思索

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

【2】チケット駆動開発とプロダクトライン型開発の相性が良い理由はいくつかある。
一つは、開発チームの組織構成とRedmineのプロジェクト構造が密接に関連すること。
むしろ、Redmineを導入することで、プロダクトライン型開発に向いた組織構造が目に見えるようになり、チーム形成が促進されるメリットがあると思う。

「Conwayの法則」「逆Conway戦略」なる言葉があるように、ソフトウェア工学的にはとても面白い部分。

【3】もう一つは、プロダクトライン型開発を支える開発基盤に構成管理が重要な要素を占めていること。
たとえば、プロダクトライン型開発の一番わかりやすい例は、iPod/iPhone/iPadのようなAppleの製品ファミリー群だろう。

製品は違うが、コアとなるOSや部品のほとんどは共有化されており、再利用が促進されるメリットがある。
しかし、製品仕様はほとんど同じだが微妙に異なるプログラムをそれぞれできちんと構成管理していくのは、実は非常に難しい、という経験はソフトウェア開発者ならば誰でも知っているはずだ。

メインラインモデル、Git-flowモデルのようなブランチモデルで製品系列ごとのプログラムを構成管理し、マージ作業していく必要があるだろう。

ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係: プログラマの思索

アジャイル開発とソフトウェアプロダクトラインの関係: プログラマの思索

ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索

ソフトウェア再利用の概念: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

【4】一方、部品や共通ライブラリが共有化されているために、一つのバグが他製品にも影響し、マージするのも大変だし、それぞれの製品のリリース日にも影響してくる。

つまり、マージ作業だけでなく、リリース計画の整合性を取るのが管理作業として大変なのだ。
その部分は、Redmineのチケット管理のコピー機能を上手く使えば、一つのチケットから派生したタスクに対し、製品ごとにリリース日が異なっても、作業チケットは漏れ無く管理することはできるだろう。
しかし、それ以外の運用ノウハウも色いろあるはず。

つまり、メインラインモデルのような構成管理だけでなく、複数の製品系列のリリース計画の管理という部分も考慮に入れる必要があるだろう。
この辺りは組織や製品や案件ごとに制約条件が違うので、細かなノウハウを聞いてみたい。

| | コメント (0)

2016/10/17

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい~技術は人やチームに残る

SPIJapan2016の資料「現場から始めるアジャイルの技術プラクティス」資料が素晴らしいのでメモ。
個人的なラフな感想。

【参考】
SPI Japan 2016 | イベント | 日本SPIコンソーシアム

akipiiさんのツイート: "良い資料。「技術は超大事」「技術は人/チームに宿る」たぶん僕は技術指向、ボトムアップ指向の方が好きなんだな。組織変革、トップダウンは好きじゃない。現場から始めるアジャイルの技術プラクティス https://t.co/dzCclCA0CA"

akipiiさんのツイート: "聞きたかった!RT @Taka_bow: 今年のアジャイル関連の発表は基調講演の影響が大きくて「先ほど平鍋さんが言っていましたが…」「昨日平鍋さんも仰っていましたが…」という接頭辞が付きまくり。みんな、気にするな!笑 #spijapan2016"

akipiiさんのツイート: "ソフトウェア工学は未熟なプラクティスによって重大な阻害を受けてる、か。RT @hiranabe: 本日の講演資料こちらです。 #spijapan2016 https://t.co/PvOFlDC2cV"

アジャイル開発を日本の現場に導入する時、どこから手を付ければいいのか?
上記の資料では、「テスト駆動から始めよう」。
テスト自動化に反対する上司はいない。

テスト駆動の技術プラクティスは、他の技術プラクティス(CI、より良い設計)や品質改善、コスト改善にも良い影響がある。
なるほど、確かにそうだ。
他の技術プラクティスやマネジメントに目が向いてしまいがちだが、改めて初心に戻るような主張だった。

「アジャイルとかWFとか関係ない」
「技術プラクティスはプロセスに依らない」
「WFでもやれば良い (やるべき) 」
「技術は人/チームに宿る」
「チームを作り上げるには手間と時間が必要」
という主張はすごく同感。

プロセス改善、プロセス標準にどうしても目が向いてしまいがちだが、IT技術者である限り、技術にこだわって進んでもいいのではないか。
技術やプロセス改善のノウハウは、大きな組織やドキュメントに残るのではない。
人やチームに残るのだ。

だから、人やチームを大切にすること、人やチームを成長させる意識を持つことが大事。

個人的には、こういうボトムアップ的な改善方法が好きだ。
トップダウンの指導、標準化は、僕の経験上、上手く言った試しがない。
「選択と集中」という標語は良いが、日本人には向いていないのではないか。

たぶん、日本人は製造業のQC活動のように、ボトムアップのプロセス改善の方が当てはまりが良い気がする。
上から言われるのではない、自分たちの手元にある道具を使って改善できないか、という、ちょっとした動機から、最終的な良い製品を作り出す。
たぶん、そんな方法の方が上手くいく気がする。

| | コメント (0)

2016/10/10

組込みソフトウェア開発のプロセス改善の違和感

先日、組込みソフトウェア開発現場のプロセス改善の講演を聞いてきて、何となく違和感を感じた。
以下は感想とラフなメモ書き。
箇条書きなのでラフなメモ。

【1】こんな講演ストーリー。

【1-1】組込みソフトウェア開発組織での課題。
経営層がソフトウェア開発を分かっていない。
工場のモノづくりと同じような感覚でマネジメントしようとして、思い通りにならないことに苛立っている。

なぜ、そんなにコストがかかるのか? コストやロスを見える化できないのか?
これだけの開発規模で、もっと安く作れないのか? 開発効率を向上できないのか?
人材を計画的に育成して、もっと良い人材を揃えたい。IOTやビッグデータ、AIなどが分かる技術者を揃えたい。

(感想)
メーカーの経営者から見れば、ソフトウェア開発はブラックボックスなのだろう。
モノづくりのように、なぜもっと作業を標準化して、資本(資金)と労働者を大量導入して、大量生産できないのか?と思っているのだろう。
ソフトウェア開発は労働集約的な産業であり、規模の生産性が効かないのを知らないだけ。

【1-2】では、開発者にとってのプロセス改善はどうか?

プロジェクトリーダーにとって、憂鬱な仕事。
現場は、プロジェクトを回すのに手一杯で、これ以上、管理作業を増やしたくない。
SQA審査は無駄、時間の浪費としか思えない。

ソフトウェア開発を失敗しないやり方、うまいやり方はないのか?
しかし、銀の弾丸はないのだから、最終的には、自分達にあったやり方を見出すしか無い。

【1-3】開発標準の目的は、ソフトウェア開発を手順化して、管理できるようにして、効率的なやり方を定着させたい。
製造業の生産工程の標準化、3Sと同じ発想。

SQA審査では、開発標準に定めたルール、それに沿ったチェックリスト、テンプレート資料で、ドキュメントを精査する。
しかし、この開発標準は実質的に機能していない。形骸化している。

現場にとって負担が大きいだけで、効果が薄い。
CMMIのようなプロセスモデルの要求事項を満たすだけのために導入された資料作り、という感触が強い。
では、手間がかかるデータの収集にツールを導入して解決できないか?

(感想)
本当にその通り。
CMMIやISO9001のようなプロセス改善のための資料作りは、審査を通すだけのための作業と化しており、本来の品質維持にあまり役立っていない。
実際、リリース後に、設計書を整備したり、テスト結果を整理する作業をまとめて行う場合が多い。

【1-4】開発の計測として、工数、開発規模、欠陥抽出数というメトリクスがある。
たとえば、下記がある。

欠陥検出密度=欠陥検出数(件)/開発量(kStep)
開発効率=開発量(kStep)/工数(人時)

【1-5】「欠陥検出密度=欠陥検出数(件)/開発量(kStep)」は、どの工程で測定するか、で意味合いが異なる。
たとえば、「設計レビュー」「結合テストのテストNG数」「総合テストの障害数」なら、バグ率。
バグ率を使って、品質を良くするためのプロセスを取り入れることで、開発期間中のプロセス制御に使える。

しかし、レビュー指摘数が多いほど欠陥検出密度は大きくなり、品質が悪く見えるので、レビュー指摘を躊躇する人が出てしまい、悪循環になる場合がある。

一方、製品出荷後なら「流出不具合率」になる。
ハードの製品なら、出荷後の不具合は、PL法(製造物責任法)の制約でメーカーの無過失責任になる可能性があるから、一方的にコスト負担になりがち。
だから、流出不具合率はできるだけ低く、ゼロにしたい。

しかし、流出不具合率は、開発完了後、一定期間を経過しなければ測定できないデメリットがある。
また、開発期間内に欠陥があると分かっていて、その欠陥は品質に問題なしという評価で、出荷する場合もあるが、それは流出不具合率に含めるのか?

(感想)
欠陥検出密度は、テスト前に、他の類似案件を元に計画値を定めて、実績はそれとほぼ同じか、少し低いぐらいの数値になるように収める、みたいなやり方が多い。
でも、欠陥検出密度の測定方法はいくらでも改ざんできるので、あまり意味が無いと思う。
「これは障害ではなく、顧客要望の仕様変更です」と言って省くこともできるから。

【1-6】「開発効率=開発量(kStep)/工数(人時)」は、開発する対象や領域によって傾向が大きく異る。
プロジェクトや製品ごとに違うために、比較しにくい。

また、流用開発や派生開発では、新規開発よりも開発効率の値が低くなりがち。
たとえば、流用率が高いほど、新規作成のソース行数は少ないが、工数は新規開発とそんなに変わらない。

話を聞くと、普通は、5step/時間、800step/人月くらいらしい。
1時間で5ステップ、または5行とは、かなり少なすぎるが、デバッグやテスト、障害修正を考えると、そうなるのだろう。

だから、経営者から見れば、ソフトウェア開発は効率が悪すぎる、と見てしまいがち。
つまり、開発効率は数字がひとり歩きしがちだが、比較は意味が無い。

(感想)
開発効率を使いたい場面は、子会社のオフショア開発者の生産性評価に使いたい場面が多い。
もちろん、開発効率が良い開発者が評価が高い。

しかし、実際は技術の習熟度、プロジェクトの習熟度に依存するので、ほんとうに正しいかどうか分からない。
メーカーのモノづくりならば、生産工程における単純な組立作業、ライン上の作業の開発効率として評価しやすいし、あまりブレない。
むしろ、生産工程の「標準時間」として抽出し、「生産標準」として「この生産工程ではこれくらいの作業時間が標準だ」と定めて、未熟練労働者を指導することもできる。
しかし、ソフトウェア開発でそんなやり方が通用するのか?

【1-7】そんな状況で、プロセス改善活動をやっているが、現場で蓄積するノウハウを展開していきたい。
組織のルールが自分達のプロジェクトに合わなくても、柔軟に解釈して運用する方が良い。
無理に合わせるため必要以上に時間を使わない。

(感想)
現実的にはそうなるだろう。
しかし、そうであれば、プロセス改善活動を進める立場の人の意義は、結局何だろうか?
プロセス改善部署がなくても、現場は回るのではないか?

【2】組込みソフトウェア開発のプロセス改善の話に違和感を感じたのは、製造業の品質管理の技法をそのまま当てはめようとしても、実際はうまくいかない、と思うからだ。
その違和感については、過去に書いた。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

ソフトウェア開発でバグ管理はなぜ必要なのか: プログラマの思索

上記の講演では出て来なかったが、僕が一番違和感を持つ言葉は「標準時間」「開発原単位」だ。
製造業では、開発効率の単位となる「標準時間」、開発コストの単位となる「開発原単位」をメトリクスとして抽出するのが一番重要であり、そこから計画を立てて、正確な見積を行おうとする。

なぜなら、数億~数千億円のような製造装置、製造ライン、工場を建てる場合、正確な見積がなければ、設備投資できないからだ。
しかも設備投資の意思決定は、実際のプロジェクト開始の1年前に決まっている。
だから、早めに開発効率やコストの原単位を計算する必要性がある。

しかし、ソフトウェア開発では、「標準時間」「開発原単位」は計算できるのか?
ソフトウェア技術者の能力によって、生産性や10倍以上違うのだから、標準時間も10倍以上違ってしまう。
開発原単位も、技術者の人月単価は30万円から200万円まで幅がありすぎるし、標準時間も10倍以上も差があれば、見積りのブレは大きくなりすぎ。
つまり、ソフトウェア開発では、「標準時間」「開発原単位」を計算しても、その正当性を説明しづらいのだ。

そもそも、アジャイル開発では、そんなものは計算しないし、計算しようとする動機も持っていない。

一方、日本の製造業では、実際の生産は外注に出している場合が多いので、外注によるアウトソーシングでどれだけコストメリットが出るか、品質が良いか、という評価が必要になる。
その時に、「標準時間」「開発原単位」という指標が外注ベンダー単位に必要なのだ。
そうすれば、今後の発注にも、見積りとして使えるし、納入された製品の品質評価にも使える。

そのやり方をソフトウェア開発にそのまま取り入れてもうまくいくとは到底思えない。

| | コメント (0)

2016/09/25

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事をメモ。
特に主張はなし。

【参考1】
『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

M・アンドリーセン氏が考える2012年--「ソフトウェアが世界を飲み込む」 - CNET Japan

次の5年でソフトウェアが世界を食べつくす。 | リーディング&カンパニー株式会社

(引用開始)
コンピュータ革命から60年、マイクロプロセッサーの発明から40年、そして近代インターネットが興隆してから20年、ソフトウェアによって産業を変革するのに必要な技術の全てが、ようやく実用化され、世界規模で広く提供されるようになった。
(中略)

私の意見では、医療と教育が、次にソフトウェアをベースとした根本的な変革が起きる分野である。
私のベンチャー・キャピタル会社は、これら両方の巨大で重要な産業において、積極的なスタートアップ企業を支援している。
私たちは、これら両産業は、歴史的に見て起業家精神に基づいた変化に対しては非常に抵抗を示してきたが、現在、新しい、ソフトウェアを中心に据えた偉大な起業家達によって、臨界点に達する時期にきていると信じている。

(中略)
あらゆる産業において各社は、ソフトウェア革命がやってきていることを想定する必要がある。
これには、今現在ソフトウェア・ベースである産業も含まれる。Oracle社やMicrosoft社など、既存のソフトウェア大企業ですら、Salesforce.comやAndroid(特にGoogle社が大規模ハンドセット製造会社を保有している世界では)といった新しいソフトウェアの出現によって、自社製品が陳腐化してしまうという危機にますます脅かされている。
(引用終了)

池田信夫 blog : ソフトウェアが世界を食う

(引用開始)
第二は、労働や教育が大きく変わることだ。
これから先進国では、コーディングができるかできないかで収入は桁違いに変わる。
ソフトウェアの使えない労働者は、新興国の単純労働者と競争するしかない。
教育も、つまらない教養科目を教えるより、早い時期からプログラミングを教えたほうがいい。

最後に、ソフトウェアの価値を実現する必要がある。
すでにグーグルやフェイスブックは収益を実現したが、他のソフトウェア企業が資本主義の世界で既存の企業をしのぐ存在になるかどうかは今後の問題だ。
そういうビジネスモデルを開発した者が次の時代の勝者になるだろう。
(引用終了)

【参考2】
ソフトウエア、それが問題だ Software Matters - 日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (2/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (3/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

ソフトウエア、それが問題だ Software Matters - (4/4)日本のリーダーはソフトウエアの本質を理解していない:ITpro

(引用開始)
ソフトウエアは物事を変換しうる本質を持つ。
日本のビジネスリーダーはこのことへの理解が遅れていた。
日本の製造業は過去、ソフトウエアの役割を最小化する“ものづくりイデオロギー”によって成功したが、そのことによってソフトウエアをハードウエアのためのものとみなしてしまい、ソフトウエアが新機能、付加価値そして差異化の牽引役であることになかなか気付かない。
(引用終了)

| | コメント (0)

より以前の記事一覧