Agile

2022/09/04

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

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


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

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

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

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


| | コメント (0)

2022/08/05

組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない

組織を芯からアジャイルにする対談で、平鍋さんが話されていた。
感想をラフなメモ。

【参考】
平鍋健児 ? 市谷聡啓 ?組織を芯からアジャイルにする対談? - シン・アジャイル | Doorkeeper

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

平鍋さんの穏やかな口調のお話を聞いていると、そうだよねとうなずくし、勇気づけられた点もあった。

1990年代、2000年代は、プロセスの時代。
仕様に対して、いかに仕様どおりに正しく作るか、品質を担保するか、が問題だった。
そのために、ソフトウェア工場、オブジェクト指向設計、要求工学、ソフトウェア工学などがたくさん出てきた。
そして、アジャイルが出てきて、今までのアプローチは違うのでは、と。
開発者の中でこねくり回すのではなく、顧客と対話したり、市場と対話してシステムを作り上げる。
2010年頃から、リーンスタートアップが出てきたのもその流れではないか、と。

今となっては、アジャイルも日本では普通に認識されるようになってきた。
今の日本では、アジャイルは先カンブリア時代みたいに、たくさんの人達がこれがアジャイルだ、とたくさん実践して公開してきている。
そんな中で、これが本当のアジャイルだ、と言う必要はないと思う。
アジャイル警察はいらない。
もちろん、自分のポジションや意見として、アジャイルはこうだというものはあるけれど、それで対立を煽るような議論はしない。
最近は議論をやめてます、と。

平鍋さんの話を聞いて、何となく救われたような気もした。
僕だけが感じているだけに過ぎないかもしれないが、最近のアジャイルの風潮として、自分はアジャイルをやってますと名乗るには、アジャイル開発の経験だけでなく、スクラムの認定資格を取っているか、認定スクラム資格を持つアジャイルコーチの指導があるのが条件なような気がしていたから。
カジュアルに、アジャイルをやってます、みたいなことが言えない気がしていたから。
顧客とオンサイトで超高速開発ツールを使ってすぐにデモして見せてアジャイルにやってます、みたいな場面があったりして、それは違うのでは、という違和感を感じていたから。

一方、スクラムの研修を受けると、内容は確かによく考えられているし、参考になる概念もすごく多い。
このフレームワークでプロセスの諸問題が解決されるのでは、と思えたりする。
1990年代から2000年代にかけて、たくさんのアジャイルの流派が生まれてきたけれど、2020年代の現在では、それらアジャイルの考え方、プロセスはスクラムへ収斂されていく過程ではないかと思ったりもした。

しかし、平鍋さんの話を聞けば、今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない。
そう思えば、そこまで神経質にならなくてもいいし、自分で経験して理解できたことがあれば、それを普通に表現して、自分なりに解釈してもいい。

他にも気になる話があった。

平鍋さんいわく、市谷さんの書籍は、熱い気持ちや勢いで書いている所があっていいね、と。
自分が思いついたアイデアには旬があり、今ここで書かなければいつ書くのか、みたいなタイミングがある。
特にIT業界の本はそういう傾向がある。
こういうことに気づいて考えたから、今書きたい、という熱いモチベーションがあるうちに一気に書くべき。
平鍋さんが共著で書いた本「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」も、今書かなくてどうするんだ、という熱い気持ちで書いた、と。
自分も、年末には書きたい本の目次は壁に貼っておいて、そこから書きはじめる時がある、と。

平鍋さんいわく、市谷さんが提唱した言葉「越境」「向き直り」もいいね、と。
市谷さんはネーミングが上手い。
気づいたアイデアに名前付けしてネーミングすることは重要だ。

平鍋さんがプロジェクトファシリテーションでレトロスペクティブを「ふりかえり」という言葉で概念化したが、過去を振り返るだけでなく未来にも目を向けていることを強調できなかった。
だから天野さんと議論した後で、小野小町の見返り美人もそうでしょ、後ろに顔は向いているけれど、足の方向は前向きだから、とフォローしたんだよ、と。

確かに、何かすごいことを思いついた時、そのアイデアを別の言葉でネーミングすることにより、新しい価値や意味をもたらすことができる。
そういう体験を僕も感じた。
その体験はやると病みつきになる感じ。

| | コメント (0)

2022/07/31

製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?

先日、認定スクラムプロダクトオーナー研修を受けてきた。
その中で最も興味を持ち、そして今も半信半疑で理解できていない話は、「テスラの生産は全てスクラムでやっています」というお話。
ジョー先生から、下記のYoutubeを教えてもらったので見た。
以下、理解できていない初心者のラフなメモ。

【参考】
[日本語と英語] Keynote アジャイルコーチが学んだ「Tesla 真の凄さ」?あなたが学んできたアジャイルとTeslaは何が違うのか? ジョー・ジャスティス - YouTube

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

【日本語訳】A day of Mob Programming Subtitles by Joe Justice [No Audio] - YouTube

なぜ米国企業は90年代に蘇ったのか~日本の手の内は完全に読み取られた~V字回復の経営の感想: プログラマの思索

【1】ジョー先生の認定スクラムプロダクトオーナー研修に出た時に一番興味があり、そして今も完全に理解できていない点は、ジョー先生が話されていたのは、テスラはスクラムで電気自動車を製造しています、という話。

先生曰く、テスラでは調達・計画・製造・品質部門は全てスクラムチームで活動し、すべて生産している。
たとえば、材料や部品を購買するチーム、車体を作るチーム、ブレーキを作るチーム、電池を作るチーム、自動運転ソフトウェアを作るチーム、販売するチームなどがある。
それらスクラムチームをサポートするために、カスタマーサポートのチーム、経理チームなどがあり、他にも、各チームにコーヒーを提供するコーヒーサポートチームもあるらしい。

ジョー先生に、生産計画はどうなっているのか?と聞いたら、そんなものはない。
スクラムチームは生物の細胞(セル)のように自己組織化されているから、と。
各チームはそれぞれの部品を作る責務があり、各チームは他チームに必要な部品や素材を要求するために、各チームのプロダクトオーナーが集まってメタスクラムの中で調整する。
下流工程のスクラムチームから上流工程のスクラムチームへ部品や素材を要求して製造されるので、プル生産になっているので問題ない、と。

他にも色々聞きたかったが、僕が疑問点を言語化できていなかったので、それ以上は質問できなかった。

【2】電気自動車がモジュール化できるだろうと推測できても、本当かなと思うが、たぶん僕が分かっていないだけかなとも思う。
でも、この仕組みで本当に高品質に大量生産できるのか、は別問題と思う。

高品質な規格品を大量生産できる仕組みをどうやってアジャイルに構築して、大量生産できるのか?
単純に考えると、普通の大規模製造業では、相当大規模な資金を使って、工場に設備投資して、生産ラインを作って、部溜まりが安定するくらいに生産ラインの設備機械の稼働率も製造メンバーによる生産プロセスも安定させる必要があるが、それをスクラムで実装できるのか?

一方、ソフトウェア開発は結局、人依存であり、メンバーのスキルや能力に品質が比例するし、技術の習熟度合いも比例する。
ソフトウェア開発には設備は殆どいらない。
ソフトウェア企業での規模の経済は所詮、開発者という人員と拠点となる作業場くらいなので、簡単にスケールできる。
しかし、ハードウェア製品の規格品を作る場合、人だけでなく、膨大かつ大量資金の設備が必要であり、それをすり合わせるのが難しいはず。
テスラが自動運転などのソフトウェア技術が優れているのは理解するが、ハードとして本当に実現できているのか?

【3】製造業の業務にスクラムを本当に適用できるのか?
僕の疑問はこれに尽きる。
この疑問を自分なりに分解してみる。

1つ目は、ジョー先生の話を聞くと、製造業のバリューチェーンにある各機能、つまり機能別組織をそのままスクラムチームに単純にマッピングしただけに思える。
一般に普通のメーカーであれば、仕入→計画→製造→販売という主活動のバリューチェーンがあり、購買部、生産計画部、製造部、販売部のような機能別組織で構成されている。
また、総務・経理・人事・企画などの支援活動のバリューチェーンもあり、総務部、経理部、人事部、企画部という機能別組織が構成されている。
ジョー先生の話を聞くと、機能別組織をスクラムチームに編成するだけで、各チームは自己組織化されるように聞こえるが、それら組織は会社として全体最適化されるのか?

たぶん、普通の会社の機能別組織をそのままスクラムチームにマッピングしても、有機的な触媒が簡単に起きるとは思えず、おそらく何らかの前提条件が数多くあるのではないか、と思う。

2つ目は、製造業の生産ラインで重要な点は、生産プロセスを標準化生産に当てはめて安定化させることだが、スクラムを適用してもそれを実現できるのか?
一般に、トヨタ生産方式でもっとも重要なポイントは、需要の変動をなくして、在庫があまり増減せず一定の範囲に落ち着くように、また、設備の稼働率が大きく変動することなく、設備機械が高い稼働率で安定して動かすために、生産量を標準化するように生産計画を立てる。
そういう生産計画なしで、単に、機能別組織を置き換えたスクラムチームだけで、安定的に生産できるのか?

普通に考えると、各機能の組織は個別最適化するように動いてしまって、ボトルネック工程に数多くの在庫を作り出してしまう罠が発生しがちだ。
なぜなら、生産部門の中で、部品加工を行う部署は、高額な設備機械を持ち、部品加工を効率良く行うための手順を持つので、自分たちの生産性を最大限に上げるように動きがちだから。
スクラムチームは生産プロセスを全体最適化するように自然にバランスを取ってくれる保証はあるのか?
もしそれが実現するならば、どんな原理によって実現されるのか?

おそらく、製造業の業務というビジネスモデルの中でも最も複雑な問題をスクラムで解決できるならば、それなりに何らかのノウハウがあるのではないか、と思う。

【4】とは言え、テスラは自動車業界で最も注目されていて、2022年現在の時価総額がNo.1である。
ジョー先生は、テスラの時価総額は、トヨタなどの日本メーカー、アメリカのビッグスリー、ドイツやフランスや韓国のメーカーの時価総額の合計に等しいくらい大きいです、と言っていた。

注目されている理由は、いくつかあるだろう。
以下は自分の推測。

1つ目は、電気自動車という「移動能力を持ったスマホ」という製品がビジネスとして大きなインパクトと可能性があることだ。
電気自動車というハードウェアを一度所有すれば、自動運転ソフトウェアやユーザインターフェイスがスマホみたいに定期的にバージョンアップされるので、いつでも最新の機能を維持できる。
つまり、従来のメーカーによる製品売り切りではなく、バージョンアップされるソフトウェアのサブスクリプションで売上を確保するようになる。
どこかの話では、アップルやテスラの粗利益率が30%以上もあると聞いていて、その理由は、こういうソフトウェアのバージョンアップというオプション、つまり付加価値がとても大きいからだ、という話を聞いた。
つまり、ビジネスモデルとしては従来の自動車メーカーよりもはるかに財務体質は良いことになる。

テスラが従来の自動車メーカーと異なるところ - Togetter

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること: プログラマの思索

2つ目は、他の自動車メーカーにも大きな影響を与えているように見えることだ。
たとえば、ドイツのフォルクスワーゲンは、自動車のソフトウェア化では、テスラよりも劣っているが、日本のメーカーよりも遥かに先に進んでいると聞いたことがある。
その理由は推測だが、フォルクスワーゲンなどのドイツ自動車メーカーはディーゼルエンジンの不正により大打撃を受けたので、従来のガソリンエンジンは捨てるしかなく、電気自動車に賭けるしかなかった、ということではないか。

また、テスラがベルリンに製造工場を作った事件もドイツ自動車メーカーに影響を与えているのではないか。
なぜなら、ドイツ自動車メーカーの工場の生産性よりもテスラの製造工場の生産性の方が圧倒的に大きかった、と聞いている。
すると、テスラを見習って、単に電気自動車を製造するだけではなく、電気自動車の付加価値を高めるソフトウェア基盤の開発が重要なはずだ、と考えて、その方向に一気にカジを切ったのではないか?

【5】そんなことを考えると、他業界のビジネスモデルにもスクラムを適用できるのではないか?と思える。

製造業という数多のビジネスモデルの中でも最も複雑な業務にスクラムを適用できるならば、小売、卸、サービス業、官公庁の業務にも適用できるはずだ。
単純に連想すると、経営コンサルタント業務のように、高度な専門知識を持った人が集まって、少人数のチームを形成してアウトプットを出す業務には、スクラムはすぐに適用できるはずだ。
なぜなら、ソフトウェア開発チームの特徴にコンサル業務がとてもよく似ているからだ。
設備はほとんど不要で、必要なものは、各メンバーに高度な専門性を持つ技術があるかにかかっているからだ。
つまり、コンサル業務のチームにスクラムをそのまま適用すれば、今の大規模スクラムのノウハウをそのまま適用するだけで、コンサルビジネスもスケールできるはずだろう。

製造業でスクラムを適用できるならば、小売スーパーや飲食店、理髪店やネイル店、旅館などの中小企業が多いサービス業の業務にも簡単にスクラムを適用できるはずだ。
特に労働集約的な業務には、スクラムチームで編成し直して、メンバーの生産性を高めるように持っていけるのではないか。
スクラムチームはプロダクトオーナー、スクラムマスター、チームメンバーの3つの役割だけから構成されていて、少人数なチームで構成されるので、それらのサービス業のメンバーにも適用できるのではないか。

この辺りも単純なアイデアに過ぎないけれど、たぶん既に他の人達がやっているに違いないと思う。
色々事例を探してみたいと思う。

| | コメント (0)

2022/07/28

認定スクラムプロダクトオーナー研修の感想

認定スクラムプロダクトオーナー研修に参加してきたので感想をメモ。
ラフなメモ。

【1】実は最近は、アジャイルという言葉にずっと違和感を感じていた。
理由は2つある。

1つ目は、アジャイルなソフトウェア開発で実践して経験してます、とアピールしたいならば、実践経験はもちろん、スクラムの認定研修を受けて認定資格を持っておく必要性がある風潮に何となく違和感があったから。

以前なら、XP本を読んで自分なりに解釈していろいろ試してました、FDDやScrumの本や勉強会で刺激を受けて自分なりにいろいろ試しました、みたいな話が多かったように思う。
周囲に実践者が少ないし成功談も少ないので、自分たちで試行錯誤するしかなく、自分自身や自分たちのチームを実験して、自分たちの個別の経験を積めばよかった。
その頃はアジャイルの牧歌的な時代だった。

しかし、アジャイルコーチというプロのアジャイル開発のコンサルタントの職業が一般的になり、彼らがチームを指導してチームが運用に軌道に乗せて、どんどんアジャイルなチームを増やしている。
それは良いことなのだが、プロのアジャイルコーチがいない所で、自分たちでアジャイル開発を試行錯誤して上手くいきました、と言われても、それは本当にアジャイルなの?と言われる。
アジャイルもどきであって、真正のアジャイルではないでしょ、みたいな感じに思われる。
ウォータースクラムフォールではないのか?、それはスクラムのルールを改変しすぎているね、君の思い込みではないかね、とか。

実際に見た案件では、顧客に超高速開発ツールを使ってすぐにデモして見せてます、アジャイルにやってます、と言っていた場面を見たが、単に顧客と机を並べてオンサイトでWF型開発しているだけじゃないの、アジャイルでもなんでも無いでしょと。

超高速開発でアジャイル開発を実現する話に違和感がある: プログラマの思索

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

ちょうど、キリスト教が生まれた後、いろんな宗教家が自分たちこそがキリストの真の後継者なのだ、と200年も論争して、三位一体説のキリスト教に収れんされた歴史を連想する。
現代は、アジャイル開発の数多くの流派が生まれて論争された後、スクラムに収れんされていく時代なのかな、と思っている。

捏造された聖書の感想: プログラマの思索

2つ目は、最近のアジャイル開発のニュースが、ソフトウェアのプロセスやソフトウェア工学の観点よりも、DXに向いた組織を作りましょう、組織文化をもっとアジャイルに変えましょう、という組織論の論点に偏っているように感じたから。
もちろん、アジャイルな組織文化は重要だ。
一番流行しているバズワード「心理的安全性」が浸透したチームや組織であれば、アジャイルなソフトウェア開発も事業もやりやすいだろう。

しかし、経営層や組織構造を変えないまま、組織文化をボトムアップで変えようとするのは至難の業だ。
既存事業や既存組織が残ったままになりがちなので、結局、社内に出島を作り、そこでアジャイル開発を成功させて、少しずつ社内に展開していこう、みたいなやり方に落ち着く。

チャンドラーの言葉「組織は戦略に従う」、コンウェイの法則「ソフトウェアは組織に従う」の経験則に従えば、組織文化を規定する組織構造、さらには経営戦略から抜本的に変える必要があると思う。
つまり、ソフトウェア開発を事業の根本に据えて、ソフトウェア開発の事業の向いた組織構造を作るのが一番手っ取り早いと思う。
大規模スクラム Large-Scale Scrum(LeSS)」でも、「組織構造が組織文化を規定する」と書かれていて、そうだよねと納得した。

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

だから、組織論の話、特に組織文化の話に持ち込んでも、真の解決にはならないと思っている。
「組織文化は社長が作り出すものだ。社長がもっと汗をかけ!」と以前、中小企業診断士の先生が言われていたのを思い出す。

文化は組織構造に従う: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

【2】とはいえ、実際に認定スクラムプロダクトオーナー研修に参加してみたら、すごく楽しかった。
スクラムマスター研修は以前受けているので内容は大体分かっているけれど、新たな知見もあったし、ゲーム感覚で経験できるのは楽しかった。
アジャイル開発は、こういうゲーム感覚で進められるように整備されている点が上手いな、といつも思う。

プロダクトオーナーが関わるプロセスでは、
Release Goal→Contract→Vision→Personas→User Story→Release Planning→Product Backlog
のループになる。

【3】興味深かったことはいくつかある。

1つ目は、ReleasePlanningでのユーザーストーリーの優先順位付けだ。
ユーザストーリーには、サイズという見積もり情報をフィボナッチ数で見積もる。
S、M、L、XLのカテゴリに3つの数値が分類されるので、フィボナッチ数は1~12番目まで使われる。

さらに、ユーザーストーリーにVlaueという顧客から見た価値、定量化された数値を設定する。
ここでも、S、M、L、XLのカテゴリでフィボナッチ数が使われる。

ここから、ユーザストーリーの優先度=Value/Sizeを計算して定める。
優先度の大小で、ユーザストーリーはプロダクトバックログに一列に並ぶことになる。

興味深い点は、実際に自分たちで優先度を定めてみると、実は1以上の優先度が少なくて、殆どが1未満の小数点の端数になったことだ。
つまり、優先度の高いストーリーはすぐに決まるが、大半のユーザーストーリーは1未満の優先度なので、あまり大きな差が出ない。
すなわち、価値の高いユーザーストーリーを作ることは非常に難しいことを意味している。

この事象は僕らのチームのユーザーストーリーの作り方が悪かったのかもしれない。
価値あるユーザーストーリーをたくさん作れなかったのだから。

【4】2つ目は、狩野モデルでユーザーストーリーを分類したとき、プロダクトオーナーの観点では意味合いが異なる点だった。
狩野モデルでは、4象限のマトリクスに分類されて、当たり前品質、一元的品質、魅力的品質で分類される。

狩野モデル | UX TIMES

狩野モデルから探る品質のあり方とは | SHIFT ASIA -ソフトウェア品質保証のプロフェッショナル-

プロダクトオーナーの観点では、当たり前品質は最低限の品質を担保する機能を指し、魅力的品質では顧客を驚かせたりワクワクさせるような機能、つまりValueを指すらしい。
そして、一元的品質のある第1象限はできるだけ避けるらしい。

僕にはこういう発想はなかった。
なぜなら、QC検定試験のようないわゆる品質保証の話で出てくる狩野モデルでは、品質と顧客満足度の関係を製品のプロダクトライフサイクルの観点で移り変わるものである、品質は時代によって変化することの方が重要視されていて、こういう発想の説明は聞かなかったから。

【5】3つ目は、ジョー先生から、テスラの事例がやたらと多く話されていたこと。

電気自動車メーカーのテスラの凄さは、中島聡さんのメルマガなどで聞いているが、やはり生の声はとても参考になる。
ジョー先生はテスラにもコンサルで関わっていて、生産ラインというものはなく、メーカーの全てのプロセスは、スクラムチームで形成されている、とのこと。
イメージとしては、車体を作るチーム、タイヤを作るチーム、自動運転のソフトウェアを作るチームなど、部品や機能ごとにチームがあるし、コーヒーチーム、カスタマーサポートチームのような全てのチームを支援するような部署もスクラムチームになっているらしい。

僕は、製造業がソフトウェア企業と異なる点は、規格品を大量生産できるプロセスを整備することであり、そのために生産ラインのような標準的なプロセスや組織が必要と思っていたが、ジョー先生に質問したら、テスラではそんなものはありません、みたいなことを言われた。
テスラの中にあるチームは、細胞組織(セル)のようなもので、それらが必要なものをやり取りして、最終的な製品を作るのです、と。
そういう説明を受けたが、僕はどうしてもその内容を理解できなかった。
メーカーのプロセスを全てスクラムで実現してしまうとしても、どんな点に注意して、スクラムチームを構成すべきなのか、どんなハードルがあるのか、まだイメージできなかった。
たぶん、日本の製造業のイメージが強すぎて、最先端のアジャイル製造業の話を目の前の事実として理解できなかったからだろうと思う。
品質が安定した規格品を大量生産するには、安定した標準ラインよりもアジャイルなチームの方が本当に向いているのか?と。
ジョー先生からは、アジャイル製造業のコミュニティがあるから、ぜひ聞いてみてね、みたいなことも言われたので、聞いてみたいと思う。

【6】4つ目は、プロダクトオーナーは必ずスクラムチームに1人は存在するように、大規模スクラムを実践すべきである、という話があった。
スクラムチームはたくさんあっても、プロダクトオーナーが1人だけに限定される話は、過去の話です。
チーフプロダクトオーナーは作らないのが今のやり方です。
チーフプロダクトオーナーが仕切るのは古いやり方です。
今の大規模スクラムでは、スクラムチームに必ずプロダクトオーナーは1人いる、と。
そして、プロダクトオーナーが定期的に集まって、そこでプロダクトバックログにあるユーザーストーリーを調整します、みたいな話をされていた。
そのミーティングがスクラムオブスクラムですね、昔とは違います、と。
たぶん、大規模スクラムのLess、SAFeの話と比較されているのだろうと思った。

【7】他にも色々興味深い経験ができた。
認定スクラムプロダクトオーナー研修を受けて感じたことは、自分が当初感じていた2つの違和感はまだ残るが、スクラムは本当に上手く作られているな、と改めて感じる。

スクラムの認定資格を持っていないとアジャイルなソフトウェア開発をやっているとは言いにくい風潮も、実際に研修を受けていて、なるほどそういう意味があるのか、と気づくと、その価値に納得する。
また、アジャイルな開発をやるには組織論が重要だ、という話も、スクラムに触れてみると、実際にチームメンバーにはかなりの自由度が任されていて、その専門性を活かせる環境にあるので、自然にそういう文化を受け継ぐし、今の日本のIT業界における多重下請け構造とは違った世界だから、やっぱりスクラムの組織の方がいいよ、みたいな感想を持ってしまう。

まだ経験できた内容は全て言語化できていないので、書き出してみたいと思う。

| | コメント (0)

2022/06/19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/05/08

小説活動にプルリクエスト駆動が必要になってきた

小説活動にプルリクエスト駆動が必要になってきた記事を見つけたのでメモ。

【参考】
Pull Request駆動で小説を開発する

GitHub上に構築した小説執筆環境について

akipiiさんはTwitterを使っています: 「コミット履歴を整理するためにプルリクエストを使う発想。面白い。Pull Request駆動で小説を開発する https://t.co/EJ5fHkyr1O」 / Twitter

【1】まず、なぜ、小説家にGitHubが必要なのか。
理由は以前書いた。

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること

【2】次に、なぜ、小説家にプルリクエスト駆動が必要なのか。

小説家がGitHubのプルリクエストを使うメリットは2つある。
1つ目は、GitHubのコミット履歴が意味ある情報のみに集約できること。
2つ目は、ブランチが小説の各シーンのToDo管理に適用できること。

【2-1】1つ目は、小説というテキストをどんどんコミットしていくと、途中のToDoや作業中の成果物も全てmasterに反映されてしまう。
すると、小説が完成版に至るまでの作業履歴に、途中の作業履歴や思いついたアイデアの破棄などの雑多な情報が不純物として混じってしまって、最終成果物の品質を維持しにくくなる問題点がある。

本来は、1日では完成しきれなかった原稿、思いついたアイデアを試したがやっぱり捨てた原稿は、本流のmasterから分離して一時的に退避しておきたい。
つまり、未完成の原稿、思いついたアイデアの原稿は、トピックブランチで管理すべきなのだ。

そうすれば、本流のmasterには完成されたシーンの原稿だけが取り込まれることになるので、常に最新版の原稿の品質を維持することができる。
コミット履歴という情報を整理したい、という意見は、こういう意図があるのだろう。

【2-2】2つ目は、トピックブランチで、作業中の原稿や思いついたアイデアの実験を管理したいことにつながる。
トピックブランチは、作業中の原稿であり、実験で途中経過の原稿である。
つまり、トピックブランチは、小説のワンシーンに当たる各シーンのタスク管理を行っているわけだ。

トピックブランチのコミット履歴に作業中の状況を記載すれば、チケット管理ツールのチケットの作業履歴に相当する運用になっている。
GitHubならば、トピックブランチを派生する時にIssueを発行できるから、Issueで作業のステータスや重要度、作業履歴をリポジトリとは別に管理できる利点がある。

プルリクエストを行うことの意義は、トピックブランチで作業途中の成果物を管理すること以外に、チケット管理で作業状況のステータスや重要度を管理することもあるわけだ。

【3】Pull Request駆動で小説を開発する記事に知的刺激を受けた理由は、過去の偉大な哲学者や思想家は、GitHubのような優れた開発環境を知らなかったが故に、本来の創作活動の潜在力に一定の限界があったのだろうな、と思ったからだ。

akipiiさんはTwitterを使っています: 「@MadoWindahead 過去の偉大な哲学者ですら、プログラミングを知らなかった、というフレーズが強烈でした」 / Twitter

門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii エンジニアの知的生産という本を書いた人のセッションでした」 / Twitter

門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii まだ、なさそう https://t.co/PO5I82pmft 参照してください」 / Twitter

デブサミ2019【15-B-1】エンジニアの知的生産術 ビフォー・アフター #devsumiB - Togetter

過去の偉大な哲学者や思想家に比べて、現代の知的生産者は、ワープロやPCという単純にオンラインで物書きできるツールがあるメリットだけでなく、GitHubのような優れた構成管理ツールを使いこなすことで、ちょっとしたアイデアの実験をトピックブランチで自由に試して、その中で高品質で完成したものだけをプルリクエストでマージして、高品質な成果物を生み出す仕組みを習得できる。
つまり、知的生産活動の難易度はたった50年前の人達よりも、はるかに楽になってきている。

GitHubが生まれるつい20年前までは、Wordで原稿を書けたとしても、途中の原稿はコピー新規で履歴管理したり、複雑なフォルダ管理でやるしかなく、相当面倒だった。
しかし、今の時代はそんなアホな成果物の管理をする必要もない。


そして、今後の成果物はGitHubで管理しやすいように、できるだけテキストで書いていくべきだ。
そうすれば、GitHubで成果物の履歴管理ができるだけでなく、思いついたアイデアの実験をトピックブランチで別で管理して、その作業状況も一括管理できるメリットがある。

そういう仕組みを上手く使いこなした方が絶対に良いに決まっている。

| | コメント (0)

2022/05/06

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

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

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

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

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/04/21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/03/04

タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine

RedmineJapanの懇親会で友人たちと議論しているとき、「タスク分割は親子チケットにすべきか、それともチェックリストにすべきか」というテーマで盛り上がった。
考えたことをメモ。
結論のないラフなメモ。

【参考】
ActivityとTaskはどう違うか ? ガントチャートと課題管理表から考える : タイム・コンサルタントの日誌から

akipiiさんはTwitterを使っています 「懇親会は人数が少ないのに、Redmineの濃い話で盛り上がる。Redmineでは、親子チケットを切る基準と1チケット内でチェックリストを作る基準の違いは何か?進捗率はどう決めるべきか?面白すぎw #RedmineJapan」 / Twitter

【1】Redmineでチケット駆動開発を実践すると、チケットの粒度に悩む。

タスクの粒度が大きすぎるチケットは、完了までの期間が長くなるので、進捗を管理しにくい。
肥満児チケットも言う。
こういう肥満児チケットは、完了条件が曖昧なので、作業していくと次から次へと問題が噴出して、進捗率が90%のまま停滞しがち。
たとえば、1本のプログラム開発のチケットでも、エラー処理のメッセージが決まっていなかったと後で判明して保留になったり、実際に作り込んでみるとSQLチューニングしないと使えない代物だった、とか。

一方、タスクの粒度が小さすぎるチケットは、作業しやすいが、大量のチケット保守に苦労する。
経験的には、1チームで管理できるチケット枚数には上限があると思う。
それ以上のチケット枚数になると、チケットが放置されて、今日は何をやればいいのか、今後どの順番でチケットをやっていけばいいのか、混乱しがちになる。

管理者も担当者も、細かくチケットを切って、チケットを1個ずつこなしていくようにしたい。
では、どのように細かいタスクをチケット管理すべきなのか?

【2】タスクの粒度の解決方法としては、親子チケットにすべきか、それともチェックリストにすべきか、という問題に落ち着くのではないか。

1個のタスクを親子チケットで階層化し、細かく切った子チケットを親チケットでグルーピングして、親チケットでステータスや進捗率を把握する。
一方、1枚のチケットの中にチェックリストを設けて、チェックリストの1項目ずつ消し込んでいくことで、どこまでやり切ったのか、後は何が残っているのか、を把握する。

どちらが良いのだろうか?

【3】チェックリストを使いたい場面は、担当者が1人で決まっていて、自分のタスクを作業の順序や作業の詳細ごとにチェックリストに落とし込んで、作業をこなしてはチェックリストを消し込んでいきたい時だろう。
つまり、自分だけのToDo管理に近い作業になる。

たとえば、こういうToDo管理は、研究者が道の問題解決の時に使う手法でもあるし、すでに手順化された作業をチェックリストにして使う時もあるだろう。
たぶん、担当者1人だけの作業に閉じている時、1枚のチケットにチェックリストを書く方がいい。
お手軽だし、チェックリストを考えること自体が、作業分割に繋がり、作業のクリティカルパスを考えることにも役立つ。

しかし、チェックリストのデメリットもある。
チェックリストの進捗を把握するには、1枚のチケットを開きっぱなしにしておく必要がある。
タスクボードやチケット一覧では、チェックリストの中身は見えないし、残項目数がどれだけあるか分からない。
つまり、チェックリストはチケット集計機能に向かない。

【4】親子チケットを使いたい場面は、1つの作業を複数人で分担して並行作業したり、課題の解決方針から複数のアクションタスクが派生してそれらを管理したい時に使いたいだろう。

一般に、WF型開発であれば、1つの工程の中で複数人が作業分担して、作業を逐次実行したり、並行作業で行う。
たとえば、コーディングして、コードレビューを受けて、ビルドを通すという一連の作業では、プログラマとレビューア、ビルド職人で担当者が切り替わる。
あるいは、1つの機能を複数人が分担してプログラム開発を並行作業し、最後に統合してビルドする時もあろうだろう。

そんな時は、各人のタスクを子チケットにして、親チケットでグルーピングして、親チケットでロールアップする方が進捗管理しやすい。
親チケットで進捗やステータスが分かるからだ。
また、チケット一覧やタスクボードで、子チケットを集計すれば、ガントチャートやEVMなど色んな集計機能でPJ全体の情報を把握できる。

しかし、親子チケットのデメリットはある。
何でもかんでも親子チケットにすると、チケット枚数が増えて、一瞥して管理しにくい。
大量のチケットであふれると、チケットは乱発され放置されて、誰も保守しなくなる。
だから、普通は毎日棚卸しタイムを設けるなどしなければ、PJの現状がチケットに反映されないだろう。
それだけの手間を惜しまない気力が必要と思う。

【5】親子チケットが特に重要と思う場面は、課題管理だろうと思う。

プロジェクト運営では、ゴールに向けた作業が全て洗い出されて、タスクがチケットに落とし込まれれば、その時点でほぼコントロールできる可能性が高まる。
作業に落とし込めるということは、ある程度標準化された作業、想定される作業に落とし込めることなので、ほとんど未知のリスクはない。
定常作業がそういう部類だろう。

しかし、一般には初めてのプロジェクトでは、どんな作業があるか分からない時もある。
むしろ、作業を進めていくうちに、今まで経験しなかった課題が噴出して、それらをもぐら叩きのように丁寧に潰し込んでいかざるを得ない。

すると、それら課題を発生の都度チケットにして、課題チケットを一つずつステータス管理していく必要がある。
僕は、プロジェクトマネジメントのほとんどは課題管理、もっと言えば、リスク管理に尽きると思っている。
なぜならば、未知のリスクに遭遇した時、それらの問題を課題に置き換えて、それら課題を潰し込んでいきながらゴールへ近づいていくというイメージが強いからだ。

【6】では、課題管理では何が重要なのか?
一つは、課題のステータス管理。
もう一つは、課題の解決方針から導出されるタスク群のステータス管理だ。
つまり、課題は親チケットにして、それに子チケットのタスクがぶら下がるイメージだ。

課題を調査して、試行錯誤して解決方針を決定し、タスクに落とし込んで、それらタスクが完遂されて初めて、課題は完了する。
すると、課題は今はどのステータスで滞留しているのか、を知りたくなってくる。
大抵の場合、課題の解決方針を決定するまで持ち込むのが割と大変ではないか。

そもそも、課題の解決方針がすぐに分かるようならば、それは課題ではなく、タスクであるべきだ。
なぜならば、タスクとはやるべき作業の具体的内容と完了条件が分かっているものであるが、課題はその解決方針すらも分かっていないのでどんな作業内容すらも分からないからだ。

課題を解決するには、技術情報を調査したり、集めた情報を分析したり、経験者からアドバイスをもらう、などいろんな手段があるだろう。

課題を解決する時に重要なのは、何を持って課題を解決できたとするのか、課題の完了条件を決めることだろう。
課題の方針が決まれば完了とするなら、課題チケットだけで、子チケットにタスクチケットは必要ではない。

一方、課題の方針を決めてそれらをタスクに落とし込んで、それらタスクを実践して結果をさらに分析してみて評価する、という方法もあるだろう。
つまり、課題は親チケットにして、解決方針の内容を子チケットのタスクで詳細化していくイメージだ。

能力のあるプロジェクトマネージャは、課題管理やリスク管理に敏感で、落とし穴にはまらないように未然防止策を立てていたり、落とし穴にはまり込んだ時のコストやスケジュールをバッファとして保持するなど、リスク対策をよく考えている人が多い。

【7】「親子チケットにすべきか、それともチェックリストにすべきか」という問いは、タスク管理よりも課題管理のほうが重要ではないか、と思う。
最初は、いきなり課題チケットからタスクチケットに分割できる訳ではない。
試行錯誤しながら課題を解決する必要があるから、チェックリストでまずはラフでもいいので書き込んで、それらを一つずつ潰していきながら、解決方針を探り当てる。

チケット管理の面白さは、こういうプロジェクト管理の技法を実際にチケットの中で色々試せることだ。
どういう場面でチケット管理のどの技法を使うと有効なのか?

それを手順に落とし込むことができたら、チケット管理という意思決定は、単純な条件分岐だけの意思決定まで落とせるるはずだ。
なぜならば、場面ごとのIF文ごとにチケット管理の技法を実行する、というSwitch文に置き換えられるからだ。

プロジェクトマネジメントとは、最終的には、単純な条件分岐だけの意思決定まで落とし込んで、プロジェクト運営の問題を具体化して分割することに過ぎないのではないか、と思っている。

| | コメント (0)

より以前の記事一覧