アジャイル開発版契約書の手引について再考

IPAがアジャイル開発版契約書の手引きを公開されていたのでメモ。
以下、結論のないメモ。

【参考】
アジャイル開発版「情報システム・モデル取引・契約書」～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～：IPA 独立行政法人 情報処理推進機構

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

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

このタイミングでIPAがアジャイル開発の契約書の手引を公開したことには大きな意義があると思う。
その背景には、DXというバズワードがIT業界以外にも広がっていることだけでなく、製造業やサービス業でもアジャイル開発の考え方や手法を適用していかなければならない、という強い意志が働いているのではないか、と想像した。

特に、自動車業界では、テスラが電気自動車を販売するだけでなく、「自動車という空間移動を持ったコンピュータ」を実現したために、ガソリンをベースにしたエンジンの自動車を生産する既存メーカーは脅威を持っているだろう。
自動車が単に電気で駆動するだけでなく、ソフトウェアで自動車の制御やユーザ環境を常時アップデートし、自動運転も視野に入れた仕組みを実現しているからだ。
そして、Uberやカーシェアリングのように、自動車というハードを所有しなくても便利な生活ができるビジネスモデルも生まれている。
それは丁度、iPhoneが携帯電話を駆逐するだけでなく、世界中の人達の生活を大きく変えてしまった歴史をなぞっているように思える。

特に日本では、自動車業界というメーカーに経済が大きく依存しているため、影響は計り知れないほど大きく、メーカーであってもソフトウェア開発へ重点を置く方向へビジネスモデルも変化しているように思う。
だからこそ、メーカーが苦手とするアジャイル開発も必要だという認識が広がっているのだろう、と思う。

中身はサラッと読んだだけだが、発注者であるユーザ企業と受託者であるベンダーがスクラムをベースとしたアジャイル開発をどのように契約し、ソフトウェア開発を推進していくべきか、という点が書かれている。
準委任契約をベースとした契約の内容は具体的に書かれていて参考になる反面、何となく、もう少しビックリするような、刺激を受けるような内容がなくて、もう少し読み直してみたくなった。
たぶん、具体的な経験談に相当するような内容は、公式資料として書きにくい部分もあったのだろう、と推測する。

僕は、従来のSIがやっていたWF型開発とは価値観そのものが違うから、従来のリーダーや開発メンバーは総入れ替えして、新たなチームを作るべき、みたいな過激な発言を期待していたのかもしれない。

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

個人的には、倉貫さんが言う「「全部つくらない」を前提をした契約は保証されるのか」という観点があるのか、もう一度読み直してみたいと思う。
従来の一括請負契約が好まれていた理由は、全部作ることを想定した契約を結ぶことで、それが実現できない開発リスクをベンダーに一方的に押し付けることが、発注者が好んでいたからだ。

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

DXのように、そもそもゴールが不明確なソフトウェア開発は一括請負契約にはなじまない。
PoCのように、仮説検証しながらあるべきソフトウェアを策定していく開発にも一括請負契約はなじまない。
他方、従来の準委任契約でDXやPoCを進めても、いつまで経っても完成しないソフトウェアが延々と作られるだけだ。

おそらくストーリー的には、発注側がプロダクトオーナーとしてソフトウェア開発に大きくコミットすべきであり、受託側のベンダーへのリスクを減らし、お互いにWin-Winとなる関係を築くような契約にすべき、ということだろうと推測する。
しかし、発注側のユーザ企業と受託側のベンダー企業という全く組織文化の異なる企業同士で、大規模なソフトウェア開発を円滑に進めるのは、アジャイル開発でも至難の業と思う。

その時に、そういう水と油の組織文化を持つ混成チームが持つ問題点と、アジャイル開発特有の本質的な問題点を区別して、それぞれの解決方法が書かれているのかな、と期待して読み直してみたいと思う。
個人的には、スクラムマスターの振る舞い方に鍵があると直感している。

【追記】
@papandaさんの意見では、プロダクトオーナーの振る舞い方に鍵があるという指摘。
参考にする。

ichitani ／ チーム・ジャーニーさんはTwitterを使っています 「仕方がないことなのだけど安易な準委任が増えないように、発信していかなければならない。空論ではなくて書籍「正しいものを正しくつくる」に、その道筋を示しているつもりです。」 / Twitter

ichitani ／ チーム・ジャーニーさんはTwitterを使っています 「私は契約によってPOとSMや開発チームのコミットメントラインを分ける方向性ではなくて、第3者(PO代行)が介在するモデルが現実的ではないかと思っています (かつ、その存在さえも消していくことが)。そのあたりのケーススタディを示していかないといけないと理解しました」 / Twitter

ichitani ／ チーム・ジャーニーさんはTwitterを使っています 「アジャイル契約のワーキンググループみると、事業会社側、DXを当事者として進めなければならない側がいないように思います。当事者側の意見や知見、現実にはどのくらい適応できているのかな？ https://t.co/SEqWSEPBsP」 / Twitter

オンラインのリーダーシップとは何だろうか

リモートワークの推進によって、リーダーシップの振る舞い方も変わってきているように思う。
オンラインのリーダーシップの概念が必要になっているように思う。
ラフなメモ書き。

【１】リモートワークのノウハウについては、倉貫さんの会社が日本で一番持っているのではないだろうか。

［議論］新型コロナでリモートワーク急拡大、でも少し変じゃない？：日経ビジネス電子版

相手に「伝わる」ビデオ会議、14の鉄則。全社員リモートワークのソニックガーデンに聞く ｜ iXキャリアコンパス

リモートワークで生産性を上げる仕組みやノウハウが非常に細かく書かれていて参考になる。
そんな記事を読んでいると、いくつか疑問が出てくる。

今までは会社、学校というオフラインの場所で、仕事や教育を行ってきたし、その仕組みに特化するように、洗練されていた。
しかし、昨今のコロナウイルス流行の影響でオフラインの場所を確保できない状況になり、一時的であっても、オンラインで仕事や教育を実施する必要性が出てきた。
すると、感染症が終わって正常の世界に戻った場合、既にリモートワークで生産性が上がっているならば、以前のオフラインの世界に戻る必要はない。
その意味では、現在の感染症は、オフラインの仕組みに依存してきたビジネスモデルそのものも劇的に変更されるだろう。
もはや会社や学校という物理的な場所はなくてもビジネスも教育が回るからだ。
感染症が終わった後の世界では、会社も学校も大きな環境変化が生じているだろう、と推測する。

【２】では、オンラインとオフラインの環境の本質的な違いとは一体何だろうか？

オンラインの作業についての問題点もいくつか出ている。
その問題点は、技術的課題と適応的課題の２つに分けられるだろう。

技術的課題は、オンラインのツールに慣れない、普及しない、環境が揃っていない、など、技術を克服すれば解決できるもの。
たとえば、「強い者や賢い者よりも変化に速い者が生き残る」という言葉は、まさに、オンラインの環境にいち早く適用した人ほどその利益を得やすい事実を示唆していると思う。

一方、適応的課題は、そういうツールや環境が揃ってきた上で、コミュニケーションや意思疎通をより深く太くしていく為には何が必要なのか、それぞれの現場や人、組織に依存したもの。
これらは、コンテキストに依存している場合が多いだろうから、出てきた課題を一つずつ皆で解決しながら、課題のレベルを上げていくしかない。

上記の記事を読んだ後、いかに一人ぼっちにさせないか、という仕組みが非常に重要になっているような気がした。
オンラインのリモートワークの環境になると、身近に物理的に人がいないので、困った時に声掛けできない。
そのために、Twitterのタイムラインのようなデータを流したり、顔を常時写したり、いろんな工夫がされている。

【３】僕が一番興味を持つのは、オンライン環境ではリーダーはどのようなリーダーシップを振る舞う動作が必要なのか、という問いだ。
あるいは、オンライン上のチームビルディングでは何が必要なのか、という問いだ。

倉貫さんの下記の意見に非常に興味を引いた。

(引用開始)
倉貫氏：改めて考えてみると、これまではなんて牧歌的な時代だったんだろうと驚きますね。チームビルディングを「同じ場所に集まる」という偶発的なものだけに頼って、ほとんど何もやらずにさぼってきたのかと、自分の反省も含めて思います。
(引用終了)

従来のチームビルディングの手法は、オフラインの環境に依存しすぎていないだろうか？
従来の手法をそのままオンライン環境に持っていっても、チームビルディングが上手く行かないのは明らかだろう。

【４】会社、役所、NPO法人、コミュニティなどの集団は、必ず何らかのトップとなる人がいて、彼らがその組織文化を生み出す責任を持っている。

組織文化はトップが作り出すものであり、その逆ではない、と僕は習った。
実際、どんな集団も共通目的があり、その目的に賛同した人たちが結集して、集団の目標を実現しようとする。
そういう集団を最初に作る創始者が組織文化を生み出し、メンバーとの化学反応を起こして集団をより進化させていく。

以前ならば、オフラインの空間では、実際に人が集まってトップの話をうやうやしく聞いたり、あるいは、実際にトップが自ら動いて汗をかく場面を見て、メンバーの貢献意欲が刺激されて、一致団結していく、などの事例があった。
しかし、オンラインでは、トップの行動も話も声もPCの画面を見なければ伝わらない。
TV演説に近い部分もあるかもしれない。
以前のオフラインのリーダーシップの発揮方法とは本質的に異なっている気がする。

特に、昔ながらのリーダーシップの発揮方法である「制度的リーダーシップ」は、オンライン環境では非常に難しくなっていると思う。
つまり、役職を前提としたリーダーシップは、オンライン環境ではその権力を影響させにくい。
オンライン環境では、社員が真面目に働いているのか、を管理職が逐一監視するのは難しいからだ。

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

最近では、トランプ大統領がツイッターでどんどん発言することで影響力を増しているように、オンラインのリーダーシップの発揮方法はいくつかのやり方があるように思う。
一方、オープンソースの開発のように、最終的に意思決定するリーダーがいたとしても、世界中に散らばった開発者の技術力を結集して、優れた成果物を作っていくやり方もある。

いずれにしても、まだ僕の中ではスッキリした答えは持っていない。
でも、世界を見渡せば、オンライン環境でもリーダーシップを発揮して、メンバーをあるべきゴールへ導くようにメンバーの意欲を向上させることができているリーダーもいる。
彼らはどんなやり方を使っているのか、そのやり方の本質的な特性は何なのか、考えてみる。

Redmineのステータスに説明機能が欲しい要望の背景

Redmineのステータスに説明機能が欲しい要望のやり取りがあったのでメモ。

【参考】
Feature #2568: Description for issue statuses - Redmine

akipiiさんはTwitterを使っています 「なるほど。トラッカーの説明機能はあるが、ステータスも説明欄が必要な利用シーンが聞きたい。RT @minazou67: Redmineの運用が上手くいくかどうかはトラッカーとステータスとワークフローの設定次第と言っても過言ではない。そしてステータスにはコメント欄が欲しい…」 / Twitter

齋藤さんはTwitterを使っています 「@akipii @minazou67 私もステータスのコメント欄に一票。独自に作ることが多く、人によって定義が違ってブレますから。もちろん、wikiに書けば良いという話もありますが、初心者に解りやすいのは、コメントかなと。 #redmine」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii プロジェクト毎に独自のトラッカーを作成するシーンが多くて、進捗率の値の関係で同じ様なステータスが複数あったりするので。トラッカー単位でグルーピングされたステータスを作成できれば良いのですが、そうすると管理画面とDBが複雑になってしまうので。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii 1人の管理者が上手くコントロールすれば良いのですが、専任の管理者を置くのは無理なので複数のPMがトラッカーやステータスを管理している状態だとどうしても乱雑になってしまいます。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii なのでステータスが20個とかできてしまい、一覧には進捗率で並ぶので何がなにやら分からない状況に。。説明欄があれば、このトラッカーで使っていてこの状態の場合はこのステータスと分かるのでありがたいです。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii Redmineを分ければええやんと言われればそれまでなのですが、プロジェクト単位で立てるのは管理コストが厳しいのです。。saasを使えば楽ですが、使えないプロジェクトも多いのと、数が増えすぎると横断的に把握し難いというデメリットもあるので悩ましいです。」 / Twitter

u6k_yu1さんはTwitterを使っています 「@akipii @minazou67 わかる。作業がどういう状態になったらそのステータスに変更するのか、というのが認識統一しづらかったりする。「作業中」が、事前調査段階なのか、課題で詰まってるのか、手を動かすだけなのか、みたいな。」 / Twitter

akipiiさんはTwitterを使っています 「@u6k_yu1 @minazou67 なるほど、Redmine のステータスは、トラッカーごとに意味が異なると。同音異義語みたいですね。すると、トラッカーごとにステータスの説明機能が必要？」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@akipii @u6k_yu1 そこは難しいですね。そこまでするならトラッカー毎にステータスを管理するのが素直だと思うのですが、そこまですると既存からの変更が大き過ぎるのでNGかと。なので単純にステータスに説明欄があれば個人的には満足です。」 / Twitter

akipiiさんはTwitterを使っています 「@minazou67 @u6k_yu1 さっそく @g_maeda さんが本家チケットを掘り返してくれてます。 Feature #2568: Description for issue statuses - Redmine https://t.co/B6aglS4ZMY」 / Twitter

【1】Redmineのステータスに説明機能が欲しい要望の背景としては、各部門ごとにRedmineのトラッカーやステータスに独自の意味を付与して運用しているので、メンバーに説明するために欲しいらしい。
トラッカーやステータスは単一のインスタンスであっても、各部門ごとに独自の意味を持って運用している。
すなわち、トラッカーやステータスは同音異義語のような振る舞いを持っているらしい。

こういう背景が発生した要因も何となく理解できる。
日本企業では、現場の権限が強いので、自分たち独自の共通言語を発展させてきた場合が多い。
すると、各現場では、単一のワークフローであっても、自分たち流に読み替えて運用することで、自分たちの現場の文化に合わせようとする。

特に大企業の場合、事業部門はプロフィットセンターなので声も権限も大きい。
したがって、事業部門ごとに組織文化も育まれてくるので、業務フローの同音異義語も発生しやすくなるのだろう。

ただし、ワークフローごとにステータスの説明機能を付ける事までは不要で、単にステータスの説明だけで十分とのことだった。

【2】他方、トラッカーの説明機能は、Ver4.1で実装された。

Redmine 4.1 新機能紹介 (2/3) | Redmine.JP Blog

Feature #442: Add a description for trackers - Redmine

つまり、独自のトラッカー名称で運用している場合、この説明機能があれば、新規加入したメンバーや派遣社員も理解しやすくなるだろう。

同様に、ステータス機能も本家チケットに10年以上前からあがっているので、実現できるといいだろうと思う。

Feature #2568: Description for issue statuses - Redmine

【3】こういう話を聞くと、Redmineは会社で単一の標準Redmineで運用するのがベストではなく、Redmineインスタンスを各部門にVMで配布して自由に使ってもらうという運用もベターではないか、という気持ちになってくる。
特に、大企業ほど各事業部門ごとに組織文化も業務フローも大きく異るので、単一Redmineで開発プロセスや業務フローを標準化するのは所詮無理があるからだ。

一方、デメリットは、RedmineインスタンスのVMを沢山ばらまいた場合、複数のRedmineインスタンスのVerUp作業が非常に煩雑になる点だ。
しかし、このデメリットも、AWSのコンテナサービスやマネージドサービスを上手に使いこなせれば、解決できるだろうと考えている。
実際、ファーエンドテクノロジーでは、RedmineホスティングサービスをAWS上でRedmineの複数インスタンスを提供している訳だが、そういう問題点は既に解決されている。
つまり、似たような発想で、複数個のRedmineインスタンスのVerUp作業をコンテナ化＆自動化することで解決できるだろう、と思っている。

AWS上でクラウドネイティブで再構築した「My Redmine Gen.2」リリース！ - ファーエンドテクノロジー株式会社

Redmineのホスティングサービスをクラウドネイティブで再構築 | RubyWorld Conference 2019

つまり、複数個のRedmineのインフラ構築そのものも、Infrastructure as Codeを実現してしまえばいい訳だ。
この辺りも色々考えてみる。

Ruby初心者が間違いそうなこと

Ruby初心者が間違いそうなことの記事に共感したのでメモ。
適当なラフなメモ書き。

【参考】
Ruby初心者が失敗しがち/間違えがちなこと5選 | Workship MAGAZINE(ワークシップマガジン)

1. 範囲演算子の範囲を読み違えがち
=> 範囲演算子「..」「...」は異なる。点一つで意味は全く違う。

2. 引数にProcをそのまま渡しがち
=> Procをブロック引数として渡すために、&演算子を使う。
　　さらに、シンボルで渡す方が簡略化できる。
　　injectが良い例。
　　＆演算子を使う部分はPerlに似ている。

3. Array#mapのブロック引数で、途中結果を返却するためにreturnを書きがち
=> mapやselectなど、ブロック引数を受けとるタイプのメソッドを使用する際、「ブロックの途中で得られた値」を「そのブロックで得られた最終結果」として返却したい場合では、「return」ではなく「next」を使う。
結構間違える。

4. 正規表現のマッチ結果を思うように取得できない
=> （）でグループ化した正規表現に対し、組込変数$1,$2...に、マッチング結果が格納される。
　Perlと同じ。Javaとは異なる。Javaの方が面倒。

5. privateなクラスメソッドを定義しようとしてpublicにしがち
=>
　privateの考え方はJavaやC#と全く異なるので、最初は混同してた。

JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try

[Ruby] privateメソッドの本質とそれを理解するメリット - Qiita

Javaならば、親クラスのprivateメソッドは子クラスでは呼び出せない。
しかし、Rubyでは「privateメソッドはサブクラスからも呼び出せる」考え方が最初は分かってなかった。
「privateメソッドは呼び出す際にレシーバを指定できない」「子クラスでは、親クラスのメソッドをレシーバ無しで呼び出せる」ことを組み合わせれば良い、という記事を読んでようやく理解できた。

6. スコープゲートが厳しい
=> Rubyのスコープゲートは厳しい。
　Rubyは、class、module、defのスコープゲートは乗り越えられない。

ローカル変数をスコープ内側へ - 【旧】PerlerのRuby日記->はてなブログに移行しました

　Perlは、myを付けなければ、ローカル変数はメソッド内でも使える。
　Javaならば、クラス内ではprivateな変数はどのメソッドでも使える。
　この点をよく間違えていた。

　一方、Rubyでは、ブロックならスコープゲートを越えられる。
　たとえば、define_method do～end、Class.new do～endのような書き方でスコープゲートを回避する。
　つまり、フラットスコープ。

AWSクラウドデザインパターンの感想～RDP（Redmine Design Pattarn）の構想

「AWSクラウドデザインパターン」を読み直した。
以下、AWS初心者によるラフなメモ書き。

【参考】
AWS-CloudDesignPattern

【１】「AWSクラウドデザインパターン」本を買ったのは、2013年のデブサミの時だった。
玉川さんにサインを書いてもらった。
「Work hard, Have fun, Make history!」と。

あの頃はまだCDP（クラウドデザインパターン）理解しきれてなかった。
AWSに触れて、ようやくCDPの威力を理解することはできた。
ただし、CDPに記載されたAWSサービスは2012年頃の内容なので、Lambdaなどが含まれていないから、そういう最新のサービスで置き換えられる部分はいくつかある。

振り返ると、2010年代前半にCDP本が出たからこそ、AWSが日本に普及し始めたのだと思う。
CDPは、システムのアーキテクチャ設計、インフラ設計において、AWSのサービスや機能をどの場面で適用するとどんな効果が得られるのか、を明確に示唆してくれる。
クラウドによる設計や実装を試行錯誤していた頃に、CDPを用いることで、より良いクラウドによるアーキテクチャ設計が実現可能になったためだ。
また、アーキテクト同士で、クラウドによるアーキテクチャ設計について、共通の言葉を使って議論できるようになった。
そういうメリットがCDPにはあった。

CDPの形式はGOFのデザインパターンに似ている。
CDPの形式はもっとシンプルだ。
解決したい課題、クラウドでの解決、AWSによる実装、利点、注意点、その他の関連パターン、という項目で必要最低限に絞り込まれている。
CDPというカタログを読んでいくと、どのユースケースでは、どんなパターンを用いるとどんな利点があるのか、クラウドでの解決方針に沿ってAWSはどんなサービスや機能を提供してくれているのか、が理解しやすくなる。
実際に、オンプレのインフラ構築や運用で苦しんできた経験のある人ほど、AWSによる実装方法で、なるほど、と気づく場面が多いはずだ。

イントロの部分もすごく惹かれた。
AWS普及に心血を注ぐ3人が、ある居酒屋にて、クラウドを語る上で共通言語となるデザインパンターンのようなものが必要である、という議論が白熱し、その場で40種類以上のクラウドデザインパターン（CDP）の種をノートに書き出した、とある。
この文に触れて、クラウドの導入でつまずいているプロジェクトがあって苦労したり、オンプレの設計思想に囚われすぎてAWSの良さを活用しきれていない場面で歯ぎしりしたりしたのではないか、と勝手に想像した。
そういう経験を元に、CDPが生み出されたのだろう。

【２】そんなことを考えているうちに、Redmineデザインパターン（RDP）みたいなものが作れないだろうか、と想像したりした。
Redmineの導入・運用も既に10年以上の蓄積があり、必要な運用ノウハウはネット上にたくさん語られているし、運用で必要なロール（組織上の役割）もいくつか語られている。
しかし、そういうノウハウはバラバラに散らばっているに過ぎない。
それらを一つの体系として、暗黙知となっているものを形式知化することには意義があるはず。
なぜなら、まだ困っている人も多いだろうし、経験者が議論する時の共通言語はまだ暗黙知になっている部分が多いからだ。

僕も以前、チケット駆動開発のパターン集みたいなものを編み出そうと考えていた。
そのパターンの根底は、アジャイル開発にチケット駆動開発を適用するにはどんな考え方が必要なのか、があった。
でも、それから5年以上たち、今は情報システム部門の人達が一般ユーザに使ってもらう運用基盤に変化したので、異なるパターン集が必要になっていると思う。

今僕のアイデアとしては、パターンに4つほどのレイヤで階層化して詳細化できないか、と考えている。
イメージは、ユースケース層＞マネジメント・ロール層＞アプリ・機能層＞ソース・実装層。
たとえば、ユースケース層では、課題管理・ソフトウェア開発・サポートデスクなどの実際の利用シーンでカテゴライズする。
マネジメント・ロール層では、Redmine職人・Redmineエバンジェリスト・Redmine警察のようなロール、PMxTMマトリクスのような組織への導入方法。
アプリ・機能層では、Redmineの各機能のベストプラクティス。たとえば、チケットのワークフロー、JAXAが生み出したカスタムフィールドやプロジェクトのOR・AND条件など。
ソース・実装層では、ViewCustomizeプラグインによる課題解決、プラグインやカスタマイズによる課題解決など。

このようにパターンをレイヤ化して区別することで、パターンの粒度を区別できること、初心者や経験者が会話できる共通言語を提供できること、というメリットがあると思う。
僕が以前考えていたパターンはアジャイル開発への適用に特化しすぎていたので、2020年現在の実情に合わせたデザインパターンを作れたらいいなあ、と考えた。