Agile

2019/11/09

Scrum@Scale入門のリンク

原田さんのScrum@Scale入門のリンクをメモ。

【参考】
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門(前編)。Developers Summit 2019 - Publickey

スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門(後編)。Developers Summit 2019 - Publickey

Scrum@Scale Guide | Scrum at Scale Guide | Guide for Scaling Scrum

Scrum@Scale 入門 | Attractor Inc

大規模Scrumの話は最近良く聞くけれど、どのように拡張しているのか分かっていなかった。
上記の記事を読んで、何となくイメージが浮かんだ。

Scrum@Scaleで優れていると思った点は、課題管理などの意思決定プロセスが階層化されているにも関わらず、意思決定のスピードが速いことだ。
Scrum of Scrumを組織構造に合わせてマッピングさせている点がうまいな、と思った。

(引用開始)
これをSAAB Technologiesという会社、戦闘機のグリペンの開発でやっています。ゲームの「エースコンバット」をやっている人なら、グリペンは良い機体だっていう人、いますよね?

彼らは製造業なので朝が早いです(笑)

7時30分 SCRUMチームのデイリースクラムがあります。
7時45分 SoSのデイリースクラムがあります。
8時00分 SoSoSのデイリースクラムがあって、
8時15分 SoSoSoSのデイリースクラムがあって、
8時30分 EATがあります。

というわけで、スクラムチームが価値を届けることに困るような課題があれば、1時間後にはトップエグゼクティブの知るところとなって、そのEATでさっさと課題に対応できると。圧倒的に早いですよね。
(引用終了)

EATは取締役会に相当するらしい。
最終的な意思決定の責任は、会社の最高意思決定機関に委ねられる。
会社法上の仕組みとScrumの仕組みを上手く調和させるように作っているわけだ。

AgieTourOsakaに行ってきたが、最近の大規模Scrumの事例では、IT企業に限らず、一般企業にも導入されているよ、と聞いた。
話を聞くと、どうやらソフトウェア開発だけでなく、会社の一般業務にもScrumを適用しようとしているらしい。おそらく、Scrum@Scaleのように、課題に対する意思決定プロセスという現場のプロセスと、会社法上の組織としての意思決定の責任を上手く調和させるように、Scrumの仕組みを拡張しているのだろう、と直感している。

そういうことを考えると、Scrumは大したマネジメント・フレームワークなのだな、と改めて思う。
詳細は今後も調べていく。

akipiiさんはTwitterを使っています: 「すごく良い記事。大規模スクラムでも、最小限の官僚主義を入れる辺りが現実的な判断してるなー。RT @hidenorigoto: “スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門(前編)。Developers Summit 2019 - Publickey” https://t.co/1oclrFQoWe」 / Twitter

【追記】
原田さんから、Scrum Patternの本が出版されているのを教えてもらった。
ペーパーバックで高価だが、オンラインでも一部は読めるらしい。

Scrum Patterns

| | コメント (0)

2019/07/03

Redmineのワークフローをバリューストリームマップで描いてみるとどう改善できるか

バリューストリームマップを使う機会があったので、ラフなメモ書き。

【参考】
VSM (Value Stream Mapping) のススメ?開発プロセス可視化? - Qiita

バリュー・ストリーム・マップを作る 22 のステップ ? リーンシックスシグマの現場

バリューストリームマップを描く時のポイント - Togetter

「リーン開発の現場」はアジャイルサムライの再来となるか: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

「リーン開発の現場」の感想part5~かんばんと因果関係図がセットで運用されるのは何故か: プログラマの思索

【1】バリューストリームマップを使ってみて、Redmineのプロセス改善に使える感触を持った。
特に、Redmineのワークフローを見直す時に有効だろうと思う。

一般に、Redmineのワークフローは既存業務のワークフローをそのままマッピングする場合が多い。
すると、ToBeでなくAsIsの業務フローをそのままマッピングしてしまうので、既存の問題点を残したままRedmineに実現してしまう。
その問題点はRedmineで可視化されるので、改善すべきだという意識改革にはつながるが、改善の方向性はすぐには決まらない。
問題点のどこに着目すればよいか、観点が発散してしまいがちだからだ。

そこで、バリューストリームマップでワークフローを見える化し、問題点を明確にしてみるやり方が有効のように感じた。

一般に、日本企業は縦割り組織なので、業務フローも縦割りで分断されてしまう為に、ワークフローが非常に長くなりがちだ。
そういう部分をバリューストリームマップで描くと、タスクは必ず担当する組織・部門で表現され、そのタスクごとにステータスが割り当てられる。
いわゆる官僚制組織になりがち。

バリューストリームマップでは、ステータスが切り替えられるタイミングで、リードタイム(経過時間)とプロセスタイム(作業時間)、作業人数を必ず書く。
この点が非常に重要だ。
なぜなら、リードタイム-プロセスタイムに当たる待ち時間が長い部分こそが、このワークフローのボトルネックだからだ。
そのボトルネックをいかになくすか、という観点がプロセス改善策につながるからだ。

【2】実際にやってみると、ワークフローの最初から最後までのリードタイムに対し、待ち時間は80%を超える場合が意外に多い。
その原因は様々だ。
たとえば、プロマネの承認、レビューアのレビュー承認、顧客の仕様変更の承認など、第三者の承認で待ち時間が長期間発生する。
あるいは、並行タスクで忙しいために、本来着手すべきタスクを放置してしまった、とか。
あるいは、IT全般統制の成約のために、開発部門とインフラ部門の間で無駄にキャッチボールしている、とか。

実際、放置チケットで、新規から完了ステータスまでの日数と、チケットで実際に作業した稼働日数を比べると、チケットの稼働率は10%とかひどい数字になりがちだ。
そういう状況は、バリューストリームマップで一目で表現できるので、どこに問題があるのか、分かりやすいメリットがある。

【3】バリューストリームマップをワークショップで描いてみて面白いと感じる部分は、全体のワークフローを知る人が実はその会社にはいない、という事実が判明した時だ。
各担当者は担当する業務だけに閉じていて、タコツボ状態になっている。
実は、ワークフロー全体を統括するプロマネがいないわけだ。
だからこそ、既存の業務フローに問題が発生しているわけだ。

Redmineで放置チケットが発生しやすい問題も、実は、チケット管理のワークフローの全体に責任を持つ人がいないことが最大の原因だろうと思う。
チケットを完了ステータスへ持っていく、という責任感をチームのメンバー全員が認識していなければ、当然、チケットが放置されても、自分は関知しない態度に落ち着くからだ。

その解決手段として、その責任感を自然に生み出す仕組みとして自己組織化が使われていたり、その責任感の重さを感じさせないような仕組みとして心理的安全性が生み出されたりしたのだろうとも思う。

アジャイル開発からDevOps、自己組織化、心理的安全性へつながる昨今のマネジメント技術の流れは、そういう一連の流れから捉えると理解しやすいと思う。

一方、Redmineによるチケット管理の観点では、チケット管理のプロセスを守る守護神は、Redmineエバンジェリスト、Redmine警察やRedmineマイスターになるのだろう。

【4】バリューストリームマップでは、LT(リードタイム)、PT(プロセスタイム)だけでなく、手戻り率や直行率を求めている点が面白かった。
そこまで計算しているのか、と。

自動車メーカーに勤務しているんですが、合格率と直行率の求め方(計算式)、... - Yahoo!知恵袋

直行率(%)=一発合格数÷製造実績数×100

たとえば、手戻り率が10%ならば、直行率=90%になる。

実際にソフトウェア開発の業務フローで計算してみると、各タスクの手戻り率を合計していくと、直行率は50%を切る場合が多かった。
つまり、完成品の中身の半分は、手戻り作業で作られたことになる。
一般の現場は知らないが、この事実を悪いと見るかどうか?

【5】バリューストリームマップをRedmineの一機能として実現できると面白いと思う。
具体的には、Redmineのワークフローにおけるステータス間の稼働日数(プロセスタイム)と滞留日数(放置日数)がグラフィックに表現されると良い。
例えば、レビュー待ち→レビュー完了のステータス間では、稼働日数は1日以下なのに、滞留日数が5日以上とか普通にありがちだ。

あるいは、1チケットのサイクルタイム(新規~完了までの日数)と稼働日数の割合を各プロジェクト、各バージョン単位で集計する、とか。
つまり、プロセスサイクル効率(=作業日数/経過日数)を表現したいわけだ。

【6】実は、この概念は「プロセスサイクル効率」として、既に「リーン開発の現場」で既に紹介されている。

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

プロセスサイクル効率=作業日数/経過日数

・作業日数=実際に開発(作業)していた日数。
 ⇒WIPステージ(開発中→システムテスト準備OK→システムテスト中)で貼られていた期間。
・経過日数=サイクルタイム。
 ⇒開始日(次の10機能→開発中)から終了日(システムテスト中→受入テスト準備OK)までの期間。

「リーン開発の現場」では、プロセスサイクル効率を効率化する意識がない限り、普通の企業では10~15%程度だろうと言っている。
つまり、一般企業では、1チケットのサイクルタイムのうち、85~90%は待ち時間であり、真の稼働時間(プロセスタイム)はわずか10~15%に過ぎない事実を示している。
すなわち、チケット管理の計画を立てた時点で、チケットの予定期間の9割は無駄な時間を消費しているわけだ。

この事実が自分のRedmineに当てはまるのか、実際に試してみればいい。
Redmineでは予実の全情報が蓄積されているので、プロセスサイクル効率の検証は可能なはずだ。
もしその事実が自分のRedmineに当てはまるならば、改善すべき点が山ほどあることを示している。

Redmineエバンジェリストは、まさにそのボトルネックを改善すべき役割を担っているのだろう。

| | コメント (0)

2019/06/15

「アジャイル時代の開発」スライド資料のリンク

「アジャイル時代の開発」スライド資料が素晴らしいのでメモ。
以下は感想を交えたポエム。

【参考】




下記の文言が心に響いた。

(引用開始・一部修正)
プログラミングはエラーとの戦い。
巨人の肩に乗るために巨人を探す作業。
リアルを知らない人は嘘(の数字)を欲しがる。
(引用終了)

自分の興味の赴くままにソフトウェア開発をするのは楽しい。
でも、請負契約やビジネス上のプレッシャーを強いられるソフトウェア開発では、もっとシビアな環境でプログラミング作業を強いられる。
たった一つのバグが、プロジェクトの評価を左右したり、最終的に会社の株価を下げる要因にもなりうる。

だから、ソフトウェア開発のベストなプロセス、プラクティスを探す作業がずっと行われてきたと思う。
その一つの解がアジャイル開発、と思う。
ソフトウェア開発の特徴を最も活かしたプロセス、それがアジャイル開発ではないか。

そういえば、下記の記事も印象に残った。

本田圭佑が開発者に熱く語った50分「僕がエンジェル投資家をする理由」【de:code2019】 | BUSINESS INSIDER JAPAN

(引用開始)
「プログラミングを学んで、率直に教えてください。面白かったですか?」

西脇が投げかけると、思わず本田は無言になった。

「あれ……これ流れ的には……」と西脇が苦笑に包まれた観客に続けると、本田は少し黙ったあと、こう続けた。

「大変だな、と思いました。……僕はうそをつくのがあまり好きではないので……。面白いか面白くないかというのは、なかなか分かっていない段階なので、そのレベルまでまだ行っていない」(本田)
(引用終了)

このインタビューを読んで、本田さんは非常に正直な人なのだ、と思った。
自分が実現したいモノがあったとしても、それをプログラムで表現するにはそれなりのコード量、テクニックを必要とする。
特に、システムはその整合性を取るのが難しい。
だから、アジャイル開発などのプロセス面、自動テストや仮想環境などの開発環境面のスキルも必要になってくる。
もっともっと色々必要になってくる。

| | コメント (0)

2019/02/11

法律のケース問題をモデル化するアイデア

法律のケース問題を図解する事例を、ネットサーフィンしながら見つけたのでメモ。
アイデアをラフなメモ書き。

【参考】
中小企業診断士試験 一発合格道場 ≫ Blog Archive ≫ 【法務】ケース問題を打破する図解術

UMLの概念モデルで法律を理解するアイデア: プログラマの思索

法務脳の作り方part1: プログラマの思索

【1】上記の記事によると、法務のケース問題を図解するパターンは2つある。

【1-1】一つは、民法のように「誰がどんな権利を主張できるか」のケース。
重要ポイントは、利害関係者とその権利・義務の関係を明確にすること。
つまり、利害関係者の関係を明確にできるようにモデル化すること。

なぜなら、民法では、被害者・加害者、あるいは背信的悪意者のようなステークホルダーのうち、誰が権利を持っているのか、権利を主張できるのか(対抗要件)をケースごとに見抜くのが重要だからだ。

(引用開始)
1. 図解術その1~登場人物を整理してみる
冒頭にトラブルについての長い状況説明があり、「どのような権利を主張できるか」等の設問があるタイプの問題です。
主に民法関連の問題に多い形式です。

例として、H18年度の第9問-設問1を見てみましょう良い
不法行為と債務不履行の問題です。
(中略)
「X社が主張できるもの」を問われているので、X社をとりまく登場人物とその関係を図で整理してみます
(中略)
作図する際に意識した点は、大きく以下3点です。

・登場人物を明確にする (X社/Y/Z社/B社)
・登場人物の属性を示す (X社はライセンス利用者/Yは保持者/等)
・登場人物の関係性を示す (ライセンス契約/等)

このように登場人物が多く事象が複雑な場合には、一目で全体を俯瞰できることが重要なポイントになると思いますキー
(引用終了)

【1-2】もう一つは、知的財産法のように「ある時点で権利の出願を行うが、他社より「権利侵害である」と言われる」ケース。
重要ポイントは、時系列で権利の出願・公開・侵害の申請などのイベントを整理すること。
なぜなら、「多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要である」ためだ。

(引用開始)
2. 図解術その2~時点を意識する
知的財産権関連の問題に多い形式、過去のある時点で権利の出願を行うが、他社より「権利侵害である」と言われるようなタイプの問題です。

例として、H21年度の第9問を見てみましょう
商標権の問題です。

商標権登録を行うためにライバルであるD社への対処を問われているので、C社とD社の現在までの行動を時間の流れと共に整理してみます。
例えば、こんな感じです。

作図する際に意識した点は、大きく以下3点です。

・誰が (C社またはD社)
・いつの時点で
・何を始めたのか

多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要であると思っています
(引用終了)

【2】上記の事例より、下記でまとめられるだろう。

・民法は「利害関係者の図」が有効。
 なぜなら、権利・義務・対抗要件を明確にしたい為。
 →パッケージ図、クラス図、ユースケース図、コラボレーション図が有効か?

・知財は「イベントの時系列」が有効。
 なぜなら、先願主義なので、誰の行動が一番先なのかを明確にしたい為。
 →アクティビティ図、タイミング図?

過去にも、UMLの概念モデルで法律を理解するアイデア: プログラマの思索で、刑法の概念をクラス図でドメインモデルで描いてみる、という事例もあった。

この辺りを整理してみたいと思う。

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

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい

倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。
新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。
以下はラフなメモ書き。

【研修資料】

【参考】
アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!

アジャイル開発とは:「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!

ドキュメントをなくしてもうまくいく? ? 人に依存するリスクへの対処とは | Social Change!

【1】「ソフトウェア開発をチームで行う内容をよく知らない新入社員に、アジャイル開発をどのように説明すればよいか?」という問題に対し、上記の資料はその解決にとても役立つ。

倉貫さんのBlogや資料がとても読みやすく優れているなあ、と思う点は、ITをよく知らない人、アジャイル開発を知らない人に対して、普段着の言葉でその本質を上手く的確に表現している点だろうと思う。

既にアジャイル開発を知っている人ならば、上記の資料はとても当たり前の内容だろう。
しかし、その当たり前に思っている感覚を、新入社員やITに詳しくない経営者に説明して納得させるのは、とても難しい。
自分がこれだけ、今後のソフトウェア開発はアジャイル開発になるべきだ、と確信していても、普通の人には伝わらない。

一番分かりやすい説明方法の一つは、対比させることだろう。
たとえば、上記資料では、「これまでの開発は、ノンビリしていたな」「でも、これからの開発は、Software is eating the World」のように、従来と今後の開発スタイルを的確に表現している。

また、アジャイル開発の特徴である「最初に決めた機能を全部作らない」「最大限の構想よりも最小限の完成品を作る」「何を作るのか、ではなく、何を作らないか」「タスクをバラし、見積もりし、優先順位を決める」などを分かりやすく説明してくれている。

【2】日本人がアジャイル開発を理解しにくい理由は、日本人が製造業の成功体験に縛られていて、品質の考え方をアジャイル開発へ置き換えられない事が、最大の原因ではないか、とずっと思っている。

【2-1】上記資料では、その点について「“Point of Sales”から“Point of Use”へ」で明確に記されている。
製造業では、一度作った製品はその後で変更できないのが普通なので、出荷時に最高品質を保証できるように頑張る。

一方、ソフトウェアは一度リリースしたとしても、それから利用し始めて初めて、ユーザにとって、ありがたみを感じることになる。
つまり、本番リリース後の保守フェーズで品質を上げていく発想が重要だ。
この点は何度強調しても強調しきれない。

すなわち、ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!の記事の通り、「ソフトウェアは完成だけしても意味はない。むしろ負債である」という事を意味している。

【2-2】経営者ならば、損益分岐点分析は必ず知っているが、それをソフトウェアに適用すると、まさに初回リリース時点では、まだ利用していないのだから、初期投資した分だけ赤字だ。
そこからシステムを利用して、実際に回収して、初めて、損益分岐点を上回れば、元を取った、という事になる。
それまでは、システムはずっと負債であり、利益を得るまで回収する責任や義務が発生するわけだ。

僕も、経験上、ソフトウェア投資は資産なのか負債なのか、と暗黙的に疑問に感じてきたが、上記資料では、明確に、「ソフトウェアは負債だ」と明確に説明してくれているので、改めて腑に落ちている。

【2-3】では、この発想を受け入れると、どんな影響が出てくるか?

結論は、ソフトウェア開発の目的が品質重視から、価値重視へと変換されることだろう。
それはどんな意味を持つのか?

従来の製造業の発想では、マーケティング1.0の供給者重視からマーケティング2.0の顧客重視へ変わった。
さらに、上記の発想では、マーケティング2.0の顧客重視だけでなく、顧客に届ける価値を重視する発想、つまり、持続可能な社会を実現するマーケティング3.0へ発展するだろう、と考える。

なぜなら、顧客が利用し続けて、高額な初期投資を回収できて利益が得られるならば、いかに早く回収するか、という方向へ発展して、最終的には、では、顧客が使い続けてくれるにはどこに価値を感じてくれるのか、という方向へ考えるようになるだろうからだ。

すなわち、顧客の企業だけが儲かれば良い、という発想ではなく、持続的に成長して会社を半永久的に維持していくには、顧客の企業を取り巻くステークホルダー、たとえば、従業員や取引先、地域の人々、との関係性を重視して、エコシステムを作っていく、という流れに変わっていかざるを得ないからだ。
そうでなければ、顧客の価値を実現したとは言えないと思う。

つまり、アジャイル開発で「価値重視」と呼ばれる所以は、そういう背景がある、と考える。

【2-4】すると、ソフトウェアの品質にすごく影響してくる。
初回リリース前のテストでいくら頑張ったとしても、本番リリース後にユーザが価値を感じて利用してくれなければ、システムはただのゴミ箱に過ぎない。
また、利用中に機能追加していくうちに、使いづらくなった、と感じて、利用が減ると、ソフトウェアの価値はどんどん減ってしまう。

つまり、保守フェーズでの品質維持、さらには利用頻度向上が大事になるので、機能性や信頼性よりも、保守性や移植性という品質特性が重視されるようになるだろう。
ソフトウェアはそのまま放置しておくと、エントロピーが増大して、その複雑性が手に負えなくなっていくからだ。

そのために、リファクタリング、テスト駆動、継続的デプロイ、DevOpsなどの開発技術が研究され、今も技術革新されているわけだ。
そして「アジャイル開発では全部作らない」という発想へつながっていく。

【3】さらに、プログラマに求められる価値は、製造業のワーカーのように、技術標準や作業標準を起点としてPDCA(つまりSDCA)サイクルを回す方法ではなく、クリエイティブな発想を大切にしながらそれを実現していく方法へ変わっていく。
この辺りの内容は、数多くの手法が提唱されていて、どれかに理論として一つに統一されている感覚は受けない。
つまり、まさに色んな人達が、汎用的な手法を試行錯誤している所だろう、と思う。

おそらく、プログラマのいるソフトウェア開発の会社は、従来の病院や会計事務所、法律事務所などのような「プロフェッショナル官僚制」へと発展していくのかな、と思ったりもする。
なぜなら、倉貫さんが提唱する顧問プログラマは、顧問弁護士、顧問税理士にたとえられるので、プログラマの人数が増えれば、そういう方向へ進化するのではないか、と想像できるから。

H. ミンツバーグ経営論 : 戸崎将宏の行政経営百夜百冊

官僚制と管理システム

「H.ミンツバーグ経営論 第8章「組織設計:流行を追うか、適合性を選ぶか」」のオーディオブック - audiobook.jp

しかし、一方で、「ティール組織」のように、個人のパフォーマンス重視の組織へ進化するアイデアも提唱されている。
実際、倉貫さんが提唱するホラクラシーは、「ティール組織」が提唱する最終型の組織にぴったりだ。

「ティール組織」の本を読んでみて、アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノートの内容がまさに当てはまる、と感じた。

つまり、「ティール組織」が提唱する最終型の組織は、従来の我々が知っている組織文化や価値観と全く違うのだ。
そういう事実を理解しなければ、「ティール組織」は大変読みにくい本だろう、と思う。

「ティール組織」の感想はまた後で書く。

| | コメント (0)

2018/03/22

カイゼンジャーニーの感想~アジャイルサムライの再来かな

「カイゼンジャーニー」を一気に読んだ。
昔読んだ「アジャイルサムライ」の雰囲気に似ている。

興奮しすぎて、理解した内容をまとめきれていないけど、ラフなメモ書き。
付箋を引いた所だけ、思いつくまま書いておく。
ロジカルでないので、後で直す。

【感想】
akipiiさんのツイート: "カイゼン・ジャーニーを一気に読んだ。スクラムからモダンアジャイルまでのプラクティス、著者の経験に裏打ちされたノウハウを文章の背後からすごく感じる。アジャイルサムライの日本版だなあ。 https://t.co/B54C8o2Dw2"

akipiiさんのツイート: "素晴らしい本で凄く惹き込まれました。コラムの知識もウンウンと頷くと共に、中身の濃い本と思いました。ストーリー形式もいいですね。… "

【1】(P.80)「何のために、このチームは、こんな追い立てられるように仕事しているの?」
「ベロシティを上げることを目的とする限り、このチームは目先のタスクに圧倒され続けるやろうね。みんながそれを選択してしまっている。」

ソフトウェア開発の途中では、当初のゴールや目的を忘れて、日々のアウトプットを作るだけになってしまう時がある。
タスクの消化だけに目が向いている。
しかし、実際に作り上げたシステムは、受け入れテストで実は顧客の思いと違っていた、という結果になる事態は経験上よくある。

「カイゼンジャーニー」はここでインセプションデッキを使う。
紹介されているインセプションデッキは、筆者独自にカスタマイズされている。
そのノウハウを読むと、数多くの現場で叩かれて、鍛えあげられたのだろう、とその背景を想像してしまう。

【2】(P.117)狩野モデル

狩野モデルと商品企画:部門別スキル - 品質管理なら日本科学技術連盟

チームが狙うべきシステムの品質を狩野モデルの3つの品質で区別しようとしている。
「カイゼンジャーニー」の文脈では、アーキテクチャや開発基盤を安定させることを重視する当たり前品質から攻めるのか、iPhoneのようにユーザエクスペリエンスを重視した魅力的品質から攻めるのか、作戦を考えるべきだ、という。

僕は、狩野モデルをメーカーのハードウェア製品の観点で理解することしか知らなかったから、ソフトウェア開発における狩野モデルに軽いカルチャーショックを受けた。

製造業の品質管理における狩野モデルでも、機能安全を重視する当たり前品質から攻めるか、iPhoneや一時期のソニー製品のような魅力的品質から攻めるか、という観点が同様にある。

もう一つの別の狩野モデルの観点では、製品ライフサイクルによって、魅力的品質→一元的品質→当たり前品質へと顧客から見た品質の観念が変わっていく、と言う考え方もある。
たとえば、販売当初の熱気がある頃は魅力的品質があれば多少のキズも大目に見てもらえるが、売れ出して一巡すると、ユーザはちょっとした機能不足に不満を感じ、最終的には、そういう機能はあって当然でしょ、みたいな感覚となり、シビアに見られてしまう。
僕はむしろそちらの方がしっくりいく。

【3】(P.162)タックマンモデル

この理論も僕は好きだ。

タックマンモデルとチームビルディング – ゲームを用いて貴社のチームビルディング研修,グループワーク,階層別研修をサポートします | 株式会社HEART QUAKE

似たような話として、「世界で闘うプロダクトマネージャになるための本」の中では、プロダクトマネージャが持つべきスキルの一つとして「転換点を意識する」というものがあった。
プロジェクトの中で、ある時点(転換点)を超えると、急に決断しやすくなったり、状況が大きく変わる時がある。
そういう転換点を意識して乗り越えるようにすべきだ、と。

タックマンモデルでいう「雨降って地固まる」みたいな転換点を意識して作り出し、それを乗り越えるように、プロジェクトリーダーはそういうスキルを準備すべきなのだろう。

【4】(P.175)モダンアジャイル

Agile 2016の基調講演: モダンアジャイル

(引用開始)
モダンアジャイルの4つの指導理念は以下である。

人々を尊重する
安全な状態を前提とする
素早い実験と学習
価値を継続的に届ける
(引用終了)

2001年のアジャイル原則は、確かに時代から少しずつズレている気はする。
もっと今風の言葉で、2018年の現在に合うような言葉で言い換えたくなる。

心理的安全という言葉は、「アジャイル開発は、組織駆動ではなく、個人のパフォーマンス駆動で行うものだ」という観点では、個人の安全欲求が満たされた状態で本来のパフォーマンスを発揮してもらうための環境づくり、とも言い換えられると思う。

【5】(P.219)仮説キャンパス、(P.234)ユーザーストーリーマッピング

リーンキャンパス、ビジネスモデルキャンパスは僕も一時期、使ってみようとして色々試してみたが、まだしっくりきていない。
たぶん、ぼくの理解が未熟だからだろう。

ユーザーストーリーマッピングも実戦で試せてないので、本を読んでみると試したくなってくる。
実際の理論と現実の狭間、衝突が面白いのだ。

【6】(P.251)SL理論

リーダーシップの状況適合理論も、僕は好きだ。

2/4 リーダーシップは部下の成熟度で変化させる [リーダーシップ] All About

プロジェクトリーダーとして、チーム運営する時に、リーダーシップを発揮せざるを得ない状況になった時、チームの成熟度に応じて、自分はどんなリーダーシップの振る舞いをすべきか、をこの理論は教えてくれる。
自分の振る舞いとチームの現実が合わない場合、裸の王様に近い感じになる。

【7】(P.255)ハンガーフライト

僕がハンガーフライトと似たような感覚を持つ場所は、新しいコミュニティを立ち上げる時だ。
自分で何かをやりたい、と思った時、傍に同志がいて、彼らと夢を語り、そのエネルギーを使ってコミュニティを立ち上げる。
初めてやってみるのは多少怖いけれど、やってみれば意外に報われる時が多い。

【8】他のプラクティスにも、僕が知らないものもあったし、今までの経験でモヤモヤしていたものが「カイゼンジャーニー」を読んで改めて気づかされたものもあった。
また感想を書いておく。

| | コメント (0)

2018/03/21

アジャイル開発とウォーターフォール型開発の違いについて再考

カイゼンジャーニー」を一気に読んだ後で、もう一度、アジャイル開発とは何なのか、現時点で考えを整理しておく。
自分の中の暗黙知を整理するのにとても役立ったので、下記の記事をリンクしておく。
特に主張なし。

【1】アジャイル開発では「個人のパフォーマンスで駆動」されるので、チームワークや心理的安全を重視する。
一方、WF型開発では、プロジェクトの成功を「組織の力で担保」する。

となると、先日の冬季オリンピックで、日本女子がパシュートで金メダルを取った事例を振り返ると、日本人は組織の力を重視する方が好きなのか?
ならば、個人のパフォーマンスで駆動する開発プロセスを志向するアジャイル開発は、日本人の文化とは本来合わないものなのか?

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

(引用開始)
このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。
当初は本当に戸惑いました。
自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。
今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙されはしていますが、システムのアーキテクチャーや機能スコープの管理がされているようには思えず、「これで破綻無くゴールできるのか?」と大いに不安を感じました。
(引用終了)

(引用開始)
そして、得られた一定の理解は次のようなものです。
「アジャイル」の本質は、「イテレーティブに進める」などというところには無い。
本質は「メンバー個々が個々としてプロジェクトあるいはプロダクトにコミットし、メンバー個々が如何にすればプロジェクトの成功あるいはプロダクトの完成に貢献できるか、自ら強いオーナーシップをもって考える、その点にいわば賭けている」、という点にある。

対して、ウォーターフォールの本質は、「プロジェクトの成功あるいはプロダクトの完成を、組織として仕組みとして担保しよう」と考えている点にあると言える。
よく"Collaboration and Teamwork" vs. "Command and Control"などのフレーズで対比されます。「個人の力」を信じるか、「組織の力」でこその安心か。。
このような“文化的背景の違い”からみれば、Unified Processもほとんどウォーターフォールの一変種でしかありません。

「イテレーティブ」という点では、アジャイル系方法論もUnified Processも類似に見えます。
しかし、個人のパフォーマンスで駆動しようとするか、組織の仕組みで駆動しようとするか、その価値の置き方は全く異なります。
(引用終了)

【1-2】アジャイルにおける「計画」とは優先順位を見極めること。
一方、WF型開発の「計画」は、QCDの決定事項であり、予実管理すべきもの。

(引用開始)
また、アジャイルとウォーターフォールでは「計画」に対する考え方が全く異なると感じました。
ウォーターフォールでは、スケジュールと機能スコープが示され、それに対して必要リソース(お金や人)を見積もり、Work Breakdown Structureを作成したりします。
投入可能リソースによって、スケジュールやスコープを調整するものの、それで決定された「計画」は、基本的に遵守すべき事項となり、その「計画」を達成することを目的にしてプロジェクトは進みます。
「計画」通りに進捗しない事象が生じた場合は、リソース配分を調整し、WBSを組み替え、新たなクリティカル・パスを構築します。

アジャイル(※ここでは主にスクラムでの考え方に基づきます)では、最初にリソース(主に人)を制約として捉えます。まずメンバーが具体的に決定されます。
その具体的なリソース(メンバー)は一定期間にどれだけの開発パフォーマンスを出せるのか実測します。(スクラム用語で「ベロシティ」と言います。)
それにより、このチームが一定期間に達成できそうな開発量の見通しを立てることができます。そして開発タスクを優先順位をつけて順次消化していきます。
目標への見通しはあるものの、そこには「いつまでに何を」というかたちで管理され遵守されるべきという意味での「計画」はありません。
アジャイルにおける「計画」とは優先順位を見極めることです。
(引用終了)

【2】アジャイル開発では「全部つくらない」を前提とする。
一方、WF型開発では、「全部つくること」を前提とするので、請負契約と相性が良い。
だから、日本のIT業界では、発注側が委託ベンダーにリスクを一方的に背負わせる方向に向くために、請負契約から離れられない。

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

(引用開始)
アジャイルとウォーターフォールの本質的な違いは、プラクティスを実践するかどうかではなく、手順として繰り返し型にするかどうかではなく、「全部つくらない」を前提とするか「全部つくること」を前提とするかの違いだと考えています。昔あったスパイラルとかRUPとかありましたが、それも「全部つくること」を前提にしていたように思います。だからうまくいかなかった。ただ繰り返しても駄目なんです。

私がシステムインテグレーターで働いていた頃に、プロジェクトをアジャイルに進めるために多くの人に協力や説得をしてまわったことがあります。そこで出た意見が以下のようなものでした。

「アジャイルとは、つまり、これまでのプロジェクトでやってきたようなベストプラクティスを取り入れるということかね?」
「ウォーターフォールでも、ふりかえりとかテスト駆動開発とかを取り入れてやってきたんだけど、それとは何が違うんだ?」

一括請負でビジネスをしているシステムインテグレーターにとっては、システムを完成させることがゴールであり、全部つくることでお客さまに検収してもらえて報酬が支払われます。つまり「全部作ること」こそが仕事な訳です。そんな中で「全部作らないこと」をしましょう、と言っても伝わりません。

そこでアジャイルの良さを伝えるために出来ることは「変化に対応する」とか「人を大事にする」とか「顧客満足度を向上」とか「速く・安く」とか、そういったボンヤリした言葉で伝えるしかなくなる訳です。しかし、それらはどれも絶対にアジャイルでなければいけないものではない訳です。これまでのやり方だってやろうと思えば出来るものです。

これまでのウォーターフォールのやり方から、決定的に違うことを言うのであれば「当初に想定した機能は"全部"つくらない」ということになります。しかし、それは一括請負として「決まった機能を"全部"つくること」でビジネスをしている会社では言うことは出来ませんね。
(引用終了)

【3】Agile 2016の基調講演: モダンアジャイル

(引用開始)
モダンアジャイルの4つの指導理念は以下である。

人々を尊重する
安全な状態を前提とする
素早い実験と学習
価値を継続的に届ける

Joshua氏は、改めて古いアジャイル原則を見ると、古い大きなラップトップを誰かが持っているようで良い印象を持たないだろうという意見を持っている。そして彼はスクラムに対して以下のように言及した。

少し年をとり、素晴らしい寿命を迎え、歴史の一部と認識されて立派な引退をするのに相応しい。
(引用終了)

| | コメント (2)

2018/01/01

アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺

最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。
内容がとても奥深い。

僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。
以下、ロジカルでないラフなメモ書き。

【参考】
@yusuke_arclampさんのまとめ記事が公開されました。

アジャイルにおける事前合意について - arclamp

【1】エンタープライズアジャイル勉強会 2017年12月セミナー開催のお知らせ

アジャイルを機能させる外枠について - arclamp

(引用開始)
アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。
チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@papanda)にお願いしました。市谷さんの講演は「アシ?ャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。
ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました(参照:大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp)

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。
(引用終了)

つまり、見積りできないモノ、ステークホルダーとの調整をアジャイルチームに持ち込まない。

isopさんのツイート: "kent beckや平鍋さんが偉大なアーキテクトだから、という文脈は激しく同意したい"

isopさんのツイート: "@hiranabe 先日のエンタープライズアジャイル勉強会での @yusuke_arclamp さんのQAセッションで開発サイクルを回すことでアーキテクチャは自然と生まれてくるのか?という質問に対する回答でした"

鈴木雄介/Yusuke SUZUKIさんのツイート: "どちらかというと「平鍋さんやkent beckがアジャイルを語るとき、アーキテクチャの重要性が本人達にとって自明すぎるがゆえに語られないのは問題だ」というクレームめいた言い方をしまして... https://t.co/P6Ou6WRkpl"

【2】上記に関する感想をツイート。

akipiiさんのツイート: "名言。ストンと落ちた。RT @yusuke_arclamp: エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM https://t.co/qFNXcROiek"

昌。さんのツイート: "@akipii @yusuke_arclamp 先日のアジャイル勉強会でもその辺り激しく主張されてましたね"

akipiiさんのツイート: "@aj15_aj15 @yusuke_arclamp 立場によっては、当たり前だろ、という意見と、開発を最大に効率化する観点では、この方法しかないので、この方法を洗練化すべきだ、という意見があると思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@akipii @aj15_aj15 特にエンタープライズ業界でアジャイルをスタートする方は強めに意識してもらいたいな、と思います。僕の知る現場で苦労しているのは、この2つということが多いので。"

門屋 浩文さんのツイート: "@yusuke_arclamp @akipii @aj15_aj15 なるほど。エンタープライズアジャイルにはまだ踏み込んでいませんが、納得です。ただ、それができるPOやSMはウォーターフォールでもうまくいく気がします。早く成果物を作る・使うって効果を優先ってことで手法を選択、ですかね"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 いえいえ、もっと深い意味があります。DOAモデラーとの議論では、アジャイル開発では要件定義やアーキテクチャ設計は誰が担当するのか?と言う議論がありました。アジャイル開発の文脈では、開発チームは要件定義やアーキテクチャ設計を担当せず、POに委ねることで解決しようとしてます。多分。"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 よって、DOAモデラーの観点では、そうならば 速く開発できるのは当たり前でしょ、と。でも要件定義やデータモデリングを他人の手に委ねて良いのかと。僕は、アジャイル開発のような特化したやり方は有りと思うし、そういう仕組みがあるから中小SIが市場に食い込めるので日本では人気あると理解し… https://t.co/QO72yG0fhm"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@MadoWindahead @akipii @aj15_aj15 アジャイルでは「要件定義レベルでモデルやアーキテクチャを固くすることに意味がない」とも言えます。なぜなら変化するから。つまり、作りはじめるまでに、いつ、どこまで、誰が固く表現するのか?というのが論点かと。"

【3】スクラムとの関わりについて。

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルで「エンジニアにとって面倒なことをチームに持ち込まない」というのを「効率化のために調整は減らすべき」と考えるか「エンジニアの甘え、仕事の醍醐味は調整だ」とするかで分かれそう。もちろん、両面ある。僕としては「両者を混ぜて曖昧にするな」というだけ。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スクラムマスターってエンジニアの世話役とかおもりみたいな面もあり「そんなの甘え」と思う人もいるだろが、そういう人がいないとエンジニアが機能しないのも事実なんだよね。ウォーターフォールでいう「バッファ」を実体化したのがスクラムマスターともいえるのかな?"

鈴木雄介/Yusuke SUZUKIさんのツイート: "ともかく日本でまともな開発現場、エンジニアがやり甲斐があって、つらくならない開発現場を増やしたい。でも、なんでもできるエンジニアは限られているから組織やチームとしてできる体制を作らないといけない。だから、マネジメントが必要になる。アジャイルは良いツール。"

みぞやんさんのツイート: "@yusuke_arclamp WFでいう(人数によりますが)サブシステムごとのチームリーダーがスクラムマスターを担えるといいのかなと思いました"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@mizoyan432 最新のスクラムガイドでも「スクラムマスターはサーバントなリーダーである」と記載があるので、ある意味ではその通りです。ただしコミュニケーションパスを抑えるようなリーダーではないべきですね。"

HARADA Kiroさんのツイート: "@yusuke_arclamp 有効なら「甘え」でなにか悪いことでも?くらいのノリですかねえ。バッファよりは、もうちょい能動的で、バッファ減らす要因に働きかけに行く感じ。"

【4】アジャイル開発とWF型開発における、プロセスの違い、体制の違い、

鈴木雄介/Yusuke SUZUKIさんのツイート: "企画の決める仕様がゆるい、基幹システム連携がもめる、運用部門に提出するドキュメント作成が大変、といったことはWFからアジャイルになっても変わらない。むしろ、課題として明示化される。作業に落とし込めない調整事を開発チームに持ち込ませないのが大事。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンタープライズ開発だと、WFでもアジャイルでもやるべきことはきちんとやる、のです。ただ、作業にならないものはスプリントに持ち込めなくなるからPOやSMが頑張って作業になるように調整を行うことになる。その代わりチームは機能の実現に全力を尽くす。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スプリント計画で「開発チームが見積もれないものはスプリントバックログにいれない」というのが大事です。それがグダグダになるとうまく回らなくなる。そもそもプロダクトバックログに調整中のものは持ち込まないべき。その手前に解決しておかないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルに比べてWFの方がゲートやプロセスが厳密なんて聞きますが、間違いです。アジャイルはスプリントごとのゲートやプロセスは大変に厳密です。ただWFはゲートの数が少ないので一回でやるべきことが多くなるだけで。"

上記のツイートは、本当に同意。
大規模WF型開発でも、優秀なプロジェクトマネージャは故意にフェーズ分けして段階リリースを踏む、という手段を取る場合が多い。
最後の1回だけの本番リリースは危険すぎる。

鈴木雄介/Yusuke SUZUKIさんのツイート: "WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていた頃が僕にもありましたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM"

そういう文脈で、アジャイル開発では、スクラムマスターやプロダクトオーナーが防波堤になる。
組織パターンにおける防火壁、ファイアウォール。

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラで調整が面倒なのは仕様合意、システム連携、インフラ調整、運用引継。インフラ調整はクラウド化で軽減、システム連携や運用引継はプロセス関係なく事前ネゴ。仕様合意はアジャイルの締切駆動や定期調整に変更。つまり、アジャイルで変化を強く求められるのはビジネス側"

鈴木雄介/Yusuke SUZUKIさんのツイート: "みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。"

【5】@yusuke_arclampさんと@sugimoto_keiさんのやり取りを読んだ後で振り返ると、おそらく、アジャイル開発には要件定義工程はあるのか、という問題の本質を突いているのではないか、と直感した。

杉本啓さんのツイート: "鈴木さんのエントリで一番気になったのは「見積もれないことをチームに持ち込まない」という点です。興味深い要求は、ふつう最初見積もれないですからね。これは「なすり合い」「平行線」とは違うと思うのです。私は鈴木さんの心情を批判しているのではなく書かれた主張を批判している点ご理解下さい。 https://t.co/XE9KG0za2U"

吉田 収さんのツイート: "@yusuke_arclamp @sugimoto_kei いわゆる「ビジネスアナリスト」の領域はチーム外とした方がよいということになるでしょうか。"

杉本啓さんのツイート: "@omuysd @yusuke_arclamp お尋ねの点は、どう仕切りたいかという意思の問題に依るところが大きいように思います。私としては、業務側との関係が宜しければ、業務要件の定義・分析もチームで担当する方が好みですが、それは設計/開発だけチームで受けるのとは少し異なるビジネスかと思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@omuysd @sugimoto_kei フェーズによると思います。初期は完全に外でも良くて、作るものが見えて来たらやり取りを開始し、画面への落とし込みはチームに任せていくという雰囲気でしょうかね。杉本さんが言われるようにチームのスキルや関係性で寄り方は変わるでしょうが。"

@yusuke_arclampさんも違和感を感じられているのかな、と感じた。

akipiiさんのツイート: "DOAモデラーとの議論を読んでたら、そんな感じがする。RT @yusuke_arclamp: なんか自分の主張がRUP的にフェーズによってチームスキルの濃淡を付けろという話になっている気がしてきて微妙な気分。うーむ https://t.co/Vweh4rkrnO"

【6】DOAモデラーからの意見。
モデリングするという行為の立場から言えば、まさに正論。

年忘れLT宴会<第60回IT勉強宴会> | IT勉強宴会blog

ソフトウェア開発と業務システム開発(杉本さん)

(引用開始)
アジャイルとウォーターフォール

・「ソフトウェア開発」に関するアプローチの違いだけではない。
・スコープ(視野に収めている範囲)が違うよね。
・ソフトウェア開発 vs. 業務システム開発
・超高速開発は、スコープの点ではWFと同じ。
・ソフトウェア開発を仕事としているエンジニアに超高速開発を訴えるとき、注意しないとスコープを誤解される。
・超高速開発は、業務システム開発の面を強調した方がよい。超高速開発というとソフト開発が早くできるというメッセージだけ。
(引用終了)

個人的には、関西IT勉強会で、DOAとアジャイル開発におけるモデリングや要件定義の違いについて、@yusuke_arclampさんと@sugimoto_keiさんの対談を聞いてみたい、と思う。

【7】個人的な感想を以下、書いておく。
ラフなメモなので、論理がズレているかもしれない。

【7-1】超高速開発ツールが何故プログラマに嫌われるのか

超高速開発ツールを使うと、DB設計や実装モデルを作れば、プログラミングレスで即座に業務システムを作れる。
つまり、超高速開発はモデル駆動開発の方向性に似ている。

しかし、プログラマの観点では、超高速開発ツールは正直面白くない。

プログラマなら、誰もが自分のプログラムが一番と思っている。
でも、自分が書いた優れたプログラムを見てくれ、という場面をアピールできない。
Githubで互いに書いたプログラムをフォークして、プルリクエストを送る、といったソーシャルコーディングが実現されない。

また、モデルという絵や、モデルを表現するための別のプログラムであるDSL(ドメイン特化言語)を別途覚える手間がかかる。
そんなものを覚える暇があるなら、RubyやPythonをガリガリ書きたいし、そちらの方がはるかに意味があるでしょ、と。

すると、超高速開発ツールは製造業のSE向けがマーケットなんだろうな、と思う。
つまり、プログラミングしないけどシステムを開発したい人達、すなわち発注者、特に日本では製造業のSEがターゲットになるだろう。

彼らはプログラミングは下流工程とみなし、外部へ発注するのが普通と考えているからだ。
外部に発注する工程が超高速開発ツールで代替されて、発注費用がなくなるのが理想だろうから。

akipiiさんのツイート: "同感。良い物なのに肝心のターゲット、つまり発注側のSEに届いてない気がする。RT @sugimoto_kei: 翻って超高速開発ツールを見るに、ターゲットがバクっとし過ぎのような気がする。もちょっとターゲットを定めた方がよいのでは?"

また、超高速開発ツールは多分最終的にはDSL基盤を目指しているんだろうな、と思う。
つまり、超高速開発ツールはプログラミングしない代わりに、モデルを描くために特化したスクリプト言語が必要になり、それがDSL(ドメイン特化言語)になるわけだ。

たとえば、UMLでもOCLみたいなDSLが提唱された時もあった。
DSLの優れた事例は、ExcelのVBAという意見もあったな。

そのDSLの最大の特徴は、プログラマでなくても、ユーザが分かるようなプログラミング言語であり、ユーザが簡単に書けることだろう。
システム化したい業務を一番良く知っているユーザ自身が、モデルをDSLで書いてしまえば、後は超高速開発ツールが即座にシステムを作れる、というストーリー。

そういうストーリーでは、プログラマの出番はないし、業務システムの発注者であるユーザ自身が超高速開発ツールを使いこなせるようにならなければならない。
超高速開発ツールはおそらく、そういう方向へビジネスモデルとして進化するのではないか。

【7-2】アジャイル開発における発注者と開発チームでの設計上の役割分担の誤解

上記のように、アジャイルチームには、外部との調整や要件定義に関わる作業は担当させない。
要件定義やそこから定まるプロダクトバックログはプロダクトオーナーが担当するし、スクラムマスターがスクラムチームの守護神として守る。
つまり、アジャイルチームの外側に、要件定義やモデリングの作業が追いやられているように見える。

モデラーの立場から言えば、そういう分業体制なら、速く開発できるのは当たり前だろう、と。
既に、作るべき機能リストがあり、チームはそれを淡々とこなせばいいのだから、と。

おそらくこの部分で、アジャイル開発とDOAモデラーとの間で、認識の相違が生まれるのだろうと思う。

【7-3】アジャイル開発が何故日本では中小SI企業に人気があるのか

では、なぜ、アジャイル開発が日本でも注目されているのか?
アジャイル開発が注目される理由の中に、日本特有の事情があるのか?

理由として、日本の中小SI企業が大手の下請けに依存しない受託ビジネスを行う時、アジャイル開発の手法が最強の道具になるから、という@sakaba37さんの意見があって、すごく納得した。

実際、日本のIT業界では、受託開発は請負契約の多段階の下請構造になっている場合がほとんど。
すると、その構造のままでは、中小SI企業自身がIT案件を主導するビジネスはやりにくい。

しかし、アジャイル開発を採用すると、ユーザ企業とシステム企画や要件を直接ヒヤリングしながら、スピーディにシステム開発して納品するビジネスモデルを実現できる。
つまり、今までは、元請けSIの大企業が担当していたシステム企画や要件定義フェーズを、下請けの立場に甘んじていた中小SI企業が直接担当して、ユーザ企業と直接契約できるようになるメリットがある。

特に、Webシステム開発のように、技術力に特化しているならば、要件定義さえ上手くまとめれば、ユーザ企業と直接やり取りしながら、小刻みにリリースしながらシステムを納品していくことができる。
一方、発注者であるユーザ企業も、早い段階でシステムの受入れで確認できるし、途中で細かな改善要望も織り交ぜられるので、双方にメリットが共有できれば、受け入れやすい契約になる。

また、ドメイン駆動設計のような設計手法、ユーザストーリーマッピング等の要件定義手法、リーンキャンパスやリーンスタートアップなどのシステム企画の手法も色々編み出されているので、従来のアジャイル開発の盲点であったフェーズもカバーできるようになってきている。

すなわち、日本におけるアジャイル開発の文脈では、アジャイル開発は、中小SI企業が多段階の下請構造から脱却するためのビジネスモデルとして捉えられる、のではないか。

【7-4】DDD(ドメイン駆動設計)がアジャイル開発におけるモデリング技術の補完的役割を担っている

では、アジャイル開発では要件定義やモデリングは不要なのか?
開発チームの外側で要件定義やモデリングを行うとしても、プロダクトオーナーはアジャイル開発の文脈でどのような要件定義手法やモデリング手法を持つべきなのか?

2018年初頭の日本では、ドメイン駆動設計がアジャイル開発における唯一のモデリング手法として認知されている、という回答になるのではないか。

現場で役立つシステム設計の原則を読んだ | mizoguche.info

Takuto Wadaさんのツイート: "(トッパン|ピアソン)ショック、単に絶版、様々な要因でOOA/OODの書籍がほぼ死滅し、訳書が出るタイミングが遅かったDDD本だけがオーパーツのような存在になった結果、日本ではDDD ≒ OOA/OODになってしまったという奇妙な状況の背景の話をした #teppeis_sushi"

@t_wadaさんの指摘の通り、2000年代はオブジェクト指向分析の観点で色んなモデリング手法が提唱されていたが、それらの本を出版していた出版元が書籍発行を辞めてしまったため、最も遅く出版されたドメイン駆動設計本だけが生き残り、その本しかアジャイル開発者は参考できない、という現状があるからではないか。

つまり、ドメイン駆動設計が日本で注目されている理由の一つは、そういう日本特有の事情があるのではないか。

【7-5】超高速開発ツールには、DOA基盤のツール以外にも、SalesforceやKintone、Ruby on Railsも含まれる

そういう超高速開発ツールはDOA基盤のツールだけでなく、著名なパッケージ製品では、SalesforceやKintoneも含まれるだろう。
たとえば、DOAの発想でデータモデルさえきちんと設計すれば、Salesforceで簡単に実装できる。
また、要件定義できちんと要件さえ確定していれば、KintoneでAPIを駆使して、簡単な業務システムを作り込める。

杉本啓さんのツイート: "kintone というのは複数テーブルのジョインも出来ないと聞いて、全然だめじゃないのと思っていたのだが、使ってみるとそうでもないようだ。簡単な台帳を作るにはよく練られている。ターゲットとする用途をうまく選択することがいかに重要かを示す例かもしれない。"

杉本啓さんのツイート: "@akipii はい。私も超高速開発ツールと同じと思っていましたが、おっしゃるように、想定している利用シーンが異なる(kintone の方が絞り込まれている)のではないかと今は考えています。@iteman さんの方が詳しいですが。"

Atsuhiro Kuboさんのツイート: "@sugimoto_kei @akipii 汎用の CMS と WordPress 等のブログシステムとの違いに近いと感じています。超高速開発ツールは「設計する」というアクティビティがあると思いますが、kintone にはそれがない感じでしょうか。"

そういう観点では、Ruby on Railsも超高速開発ツールの一種とみなすこともできるだろう。
業務のデータモデルをActiveRecordで対応付けることができれば、画面は簡単に自動生成できるから。

さらに、画面の細かなUIは、JavaScriptで作りこめばいい。
たとえば、XEADでも、画面UIの作りこみの部分はJavaScriptで実装できるように作られている。

特に、Ruby on RailsはJavaScriptと大変相性が良いので、画面UIをデスクトップアプリのような操作感で実現できる。

よって、最近は、DOA基盤のツールだけでなく、SalesforceやKintoneのように手軽に操作できる有償のパッケージ製品、さらにはRuby on Railsのような強力なフレームワークが普及したことで、超高速開発ツールを適用したいニーズに当てはまるのだろう、と思う。

【7-6】超高速開発ツールが普及したからこそ、匠Methodのような要件定義手法に価値がある

アジャイル開発やプログラマの視点では、超高速開発ツールに否定的になってしまう。
しかし、超高速開発ツールのおかげで、発注者自身がお手軽にシステム開発できる基盤が整った、という側面もある。
つまり、要件定義できちんとシステム要件さえ確定できれば、超高速開発ツールを使えば、即座にシステム化できるのだ。
よって、萩本さんが提唱する匠Methodを要件定義のための手法として扱って、超高速開発ツールのインプットに連携すれば、スムーズにアジャイルに開発できるだろう、と思う。

そんな話を連想できたのは、先月に関西匠塾に行ってきて、匠メソッドの概要を初めて聞いたから。
詳細はまだ理解しきれていないけれど、ビジネスモデル設計やシステム企画から業務の要件定義まで一通り、設計できる、とのこと。

価値を描き、活動に落とし込む手法を学ぼう! - connpass

では、その後はどうやってシステム開発するのか?
お話を聞くと、たとえば、Salesforceを使って、システム要件を元に素早くシステム開発していく、というストーリーみたい。
つまり、匠メソッドを要件定義のアウトプットを作るフェーズで使って、業務の要件定義書を作り、それをSalesforceやKintoneのインプットとして用いることで、アジャイルに開発できる。

【7-7】kintoneという超高速開発ツールの開発基盤があるからこそ、業務ハックという職業も生まれる

この考え方は、最近、倉貫さんの会社でも提唱されている業務ハックにつながるのではないか、と推測する。

業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!

業務ハック勉強会@大阪 ? 働き方改革にも効く!事例で学ぶ業務改善のノウハウ - connpass

つまり、超高速開発ツールのような即座にシステム化できる開発基盤があるからこそ、プログラマの観点では、業務モデリングも実装ツールの一つに組み込んでしまって、アジャイルにシステムを作りながら、業務もシステムも改善してく手法を取っていく、という考え方ではないか。
ユーザから画面UIに関する細かな改善要望があっても、JavaScriptさえ操ることができるなら、画面UIの作りこみにさほど苦労することはないだろうから。

この辺りは聞いてみないと分からないけど。

【8】以上は妄想にすぎない部分もあるけれど、今年も色んな勉強会に行ってみて、上記のアイデアの方向性が合っているのか、確認してみたい。

【追記1】
鈴木雄介/Yusuke SUZUKIさんのツイート: "相変わらずウォーターフォールとアジャイルの話は受けがいいなぁ。最近のエンタープライズ界隈はウォーターフォールからアジャイルへの転向が増えている気がするので、もっと、こういう話はされていいんだろうな。 https://t.co/yR1x9ZUku4"

【追記2】
杉本啓さんのツイート: "読みました。興味深い試みですね。業務の仕組みを作るという志向において超高速開発やDOA界隈と似ていると思います。「業務ハッカー」という呼称は、確かに新味があってプログラマに受けそうですが、顧客サイドからするとどうですかね。現場の人には響くでしょうが、上の方には響きにくいかも。 https://t.co/fbXybQn6vL"

akipiiさんのツイート: "@sugimoto_kei 実現したいものは超高速開発ツールも業務ハッカーも同じ方向性に感じます。但し、モデリングに注力してノンプログラミングにする超高速開発ツールと、プログラミング作業の中に業務設計や運用設計を取り込む業務ハッカーは手法が異なると読み取りました。"

杉本啓さんのツイート: "@akipii まあ、嗜好は違うのだとは思いますが、同じ問題領域を対象にするのであれば、収斂してくるような気がしますね。超高速開発がノンプログラミングというのはセールストークであって実際にはDSLなどでプログラミングするわけだし、業務ハックで使うkintoneもある種のDSL環境ですしね。"

杉本啓さんのツイート: "@akipii 業務ハッカーについては、私は、さほど違和感を感じていません。買う側の意思決定者には響きにくいだろうなと思う程度です。調整をチーム外にという鈴木さんの話については、たぶん問題意識についても不一致があると思います。"

杉本啓さんのツイート: "@akipii とはいえ「超高速開発」よりは「業務ハッカー」の方がセンスありますね。ユーザ視点に立つと、前者では開発が速くなるんだろうなあという印象しか湧きません。後者だと、自分たちの業務に踏み込んで考えてくれるのかも、という期待が持てます。"

| | コメント (0)

より以前の記事一覧