COCOA開発プロセスの現実と改善点(2021-04)
オープンな開発プロセスの理想についての記事はこちらに。
しかし現実は理想とはだいぶ遠いところにありまして。
・開発状況・テスト状況などなにひとつ開示されない
・リリース予定なども質問しても回答不可
・3月前半には改修のめどがたっていたのに、その後1ヶ月リリースもされずテストしているのかも不明
・GitHub と開発会社の Internal Repository が別管理されている
・もはやソースコードが別管理であることが公言され、「Internal 側に取り込んだので PR をクローズする」といった運用になっている
・GitHub では技術的な不具合などについてのみ扱うのでその他の件は厚労省へ問い合わせしろという返答がなされる
せめて建前くらいはオープンであると言い張ることはできるはずなのに、現状は開発プロセス上でオープンになっている情報を探すほうが難しい状況になってしまっています。
問題点1 - 情報開示
まず情報開示するのがオープンプロセスの第1歩ですが、そもそもそこからしくじっているわけです。受注業者側には契約上開示できないみたいな言い分が仮にあったとしてもそれは3月までの話。4月以降についてはただしく公開できるような契約・受注業者に入れ替えるのが絶対必要です。もちろんすべての項目を企業秘密まであらいざらい出せという話ではないですが、信用を完全に失っているのに何も情報を出しませんは許される状況ではないと考えています。
問題点2 - 一刻も早い修正を
まず受注業者側としては 2/18 には不具合の存在がわかっており、厚労省あてにはその理由についての報告も上がっているようなので、本来はそこから開発してテストして審査を待ったとしても3月上旬には緊急リリースできるようなスケジュール感で話が進むべきだったと考えています。
GitHub 上では @keiji さんの努力によって PR #30 が作られ、おおむね3/4 ごろには改修のめどが立っています。その後 @keiji さんが厚労省参与になったことが公表されたのが 3/16 なのですが、3/16, 3/20 のコメントなどを見ると開発チームがこのPRを評価して動作確認なども進んでいるように思われます。その後テストのフェーズなどあるとしても 3月末にリリースできるよう全速力で作業しているものかとも思われたのですが残念ながらリリースできていません。
問題点3 - 迷走にしか見えない状況
2月までは、master ブランチしか存在せず、マージコミットも行われずに、リリース時の変更点がまとめて単一コミットとして push されているだけ、という最低レベルのオープンソースの基準を満たすだけの運用でした。
オープンプロセス化として Issue / PR が歓迎されるように記載されたのですが、実際に PR がマージされたのは #24, #47, #48, #76, #87, #88 についてはプログラムコードとは関係ない GitHub 上の設定とドキュメント類のみです。
実際のところ2/26以前に開発会社での改修が進んでいる可能性は当然あるので、プログラムコードに対するPRは受け付ける準備ができなかった可能性はあるとは思われる状況でした。
ですが、3/30 に #83 がなぜかマージされました。この PR はほぼすべてのソースコードに対する変更です。ここで疑問となるのが、一刻も早く修正してリリースすることが最優先であるはずなのに、3/30 にもなってから master ブランチに修正とは関係のないコードが push されていていいのかということです。
ここからは想像ですが、もしかするといまからソースコードを整理してテストを始めるのかもしれませんし、テストは終わったので審査に出す準備をしているのかもしれませんが、このペースだといったいいつになったら改修版リリースができるのでしょう？？私個人としては #83 も重要ではあるものの形式的なものであって絶対に急がなければならない対応ではないと思いますので、緊急度の管理が正しくできていないのではという疑念があります。これもいったい何をやろうとしているのかすらも開示されていないので「オープンプロセス」が形骸化していることのひとつだと考えます。
問題点4 - 別管理リポジトリの存在
また、開発工程において一般論としても Internal Repository なんかやめてしまえーとは思います。開発会社がそれに対応できないなら別の業者と契約するのがよさそうですがなぜか4月以降も契約が継続することが公開されたようです。。
前の記事にも書いた通り、COCOA ではアプリ内部の動作が不正なものでないことを示すためにソースコードを公開しています。ですが内部リポジトリの存在を公式に認めてしまったら、そのリポジトリにはどんなコードが書かれているか全く不明なわけですから、オープンプロセス化以前に、もともとのオープンソースの意義すらも失っているわけです。
開発会社を信頼できたとして、その都合を(やむなく)受け入れるとしても、GitHub の master ブランチを正本とする、という建前は例えば以下のようにすれば実現できます
・GitHub master ブランチは原則リリース時にマージコミットする先とする
・GitHub 側の PR は別の(たとえば develop)ブランチに対して行う
・リリース前には、develop ブランチを適宜 Internal にマージする
・リリース時に、Internal から master へマージコミットする
・リリース時のタグもmasterブランチへのマージコミットに対してつける
しかし現状はこういったオープンな開発プロセスに "見せかける" ような努力さえも放棄されて、オープンソースの意義もオープンプロセスというお題目すらも完全に忘れ去られているようです。
COCOA のリポジトリでも「コードフリーズ」といった言葉が一時宙に浮いていた(実態があるのかないのかは不明なまま消えた)のですが、スマートフォンアプリ、とくに iOS 向けでは Apple の審査があるため、開発作業(ソースコードの変更作業)は必ずリリース予定日よりは数日～1週間程度前に完了しておかなければなりません。なのでこの時点でのソースコードは基本的には公開しても問題ないものとなります(厳密には審査でNGとなった場合再改修しての公開となるので、その場合は再ビルド・再公開という手順にはなりえます)。通常審査NGになることはそう多くもありませんので、これだけでソースコードは先に公開してアプリリリース待ちであることをアピールすることもできます。
また、実際にはテスト期間をたとえば1週間とか改修された機能によっては2週間とか取る場合がありますが、テスト対象アプリのソースコードを公開すれば、レビューして問題が見つかる可能性も増えるのです(あくまでも可能性であって、必ず問題が見つかる保証があるわけではないですが)。
このように考えてみると、開発会社側としても、テスト後に不具合が見つかって改修を繰り返してスケジュール上遅延するといったリスクが軽減されるため、コードレビューのために公開することはメリットもあるわけなのですが、残念ながら現時点では協力的とは言えなさそうに見えます。
問題点5 - IT室の体制不足(またはやる気不足？理解不足？)
ここまで 2月26日以降に Open された issue だけで 54件あり、22件は close されています。
3/15以前については、issue や PR は作られたとしても多くのものは @heykuro さんによってラベルだけがつけられてその意図が説明されないまま、のような状況でした。
3/16 以降は @keiji さんが管理側に加わったのでそれまでよりは説明がなされるようにはなり多少改善されました。問題点3, 4 とも重複しますがプログラムコードに関連するほとんどの PR はマージできない状況ですし、緊急リリース優先なのである程度 Issue が増えてしまうのもやむを得ないと思うのですが、
いくつかの Issue は適切ではないと思われる説明がついて close されたり、close されないまでも、いったん close の方針が示された後に外部からの指摘で撤回することが続いたりなど若干不安定な運営状態になっているようにも思えます。また、Issue 内の議論では対応しないよりはしたほうがいいけどたいした問題は引き起こさない、と結論が出たはずの PR がいつのまにか説明もなくマージされたりもしています。
このコメントでは手が空かないということもおっしゃっているのですが、外部からみるとリリースをずっと待っているのに何もしてないのかという不安を呼んでいるところで、ライセンスのコメントの追加という急ぐ必要のなさそうなことについても手が空かないというのは、対応優先度がおかしくなっていないのかなという疑問を呼んでいるように感じます。
また、GitHub での提案から運用についてはすべて厚生労働省への問い合わせに誘導するのも、(明らかに的外れなものは手間がかかりすぎるというのも理解できないわけではないものの) 機能開発と運用は表裏一体ですし、主体性をもってIT室と厚労省が連携できていないのではという疑念を持たざるを得ないように見えます。
改善案1 - 情報開示
ここまで「オープンプロセス」が正常に機能していないことを説明してきたのですが、どこから改善するべきなのか。
ひとつの(あまりうれしくない)方針案としては、オープンプロセスは一旦あきらめたことを宣言して、実現できることをベースにして GitHub のポリシーや運用を再編することも選択肢には上げたほうがいいのではとも思います。
とはいえそれは全面白旗宣言であって、開発会社によほど首根っこをつかまれているとかでなければ別の会社はいくらでもあるわけで、このような白旗宣言をする理由があるわけでもなさそうです(予算や発注基準などの問題があるとは思いますけどね。。)
となると結局は地道に公開できるものから開示するしかないというしごく当たり前の改善を積み重ねるしかないように思います。特におおまかなスケジュール案について非開示であると突っぱね続けていても、なにか急ぎ対応するべきものがあるのかどうか、いつまでに完成するべきなのかもわかりませんから、コントリビューションがきわめて行いづらい状況にあるように思えます。表向きには歓迎と書いてはみたけど実際には歓迎なんかするつもりはなくて邪魔にしか思えていないのではという邪推さえよぎりますが。
改善案2 - GitHub の位置づけの再整理
IT室などで GitHub がどういう役割を持っているのか理解されているのか不安なのですが、前の記事でも書いた通り、COCOA がオープンソースであることにはまず第一に監査的な機能があると考えています。また、オープンプロセスによって担保されるものもプロセスの正当性を監査できるようになる機能であると考えています。
ですが、現状の補佐官や参与のコメントなどには、コントリビューションを求めるといったことが前面に出ているものがあり、開発機能を持たせようにしているようにも見えます。また、コミュニティの定義などを掲げるのも、一般のOSS開発者・メンテナとしては当然のことであっても、監査機能という側面から考えるとかなり違和感があります。
・GitHub 側の取捨選択のポリシーや決定事項の開示
・個人の意見と組織としての決定の分離
といった改善も必要ですし、いったんはコミュニティによる開発機能に期待しなくてもすむ体制づくりに専念したほうが全体的な混乱が整理されるのではと考えています。
改善案3 - GitHub メンテナンスの体制強化
上記の問題点5 への対応ということにはなりますが、有識者を増やすことによって作業量自体もですし責任や知識不足によるリスクを分散・低減するようなことは必要なのではないかと感じます。現時点では
・コードを修正したりするリポジトリ上の作業
・GitHub 上の議論の整理
・GitHub 以外の場所での EN API の検証作業
・その他 GitHub 以外での作業など
など、@keiji さんひとりに負荷をかけすぎているため完全に手が回っていないように思えます。直接的にはたとえば @heykuro さんなり @hal_sk さんなりがもっと積極的にコメントしたり関与したりできればいいのかなとは思うのですが、お忙しくて難しいようであれば増員するなども検討されたほうがよさそうです。
またひとつ気になるのは、結論を急ぎすぎてはいないかということです。もちろん緊急度の違いはあるとは思いますが、実際のところは 6月の初回リリースからすでに10ヶ月ほど経過していて全くうまく軌道に乗っていない状況なのですから、結論を急ぐことは必要だとは思っていません。とはいえ「結論は先送りでいつ考えるのか考えないのかも不明です」では何も進みそうにありませんから、たとえば「今月は難しいので来月改めて検討します」、でもいいから、徐々に情報公開しながら進めていくことが必要だと思います。
また、調査などで人手が足りないといったことがあれば、「こういう調査・情報を必要としています」といったことを告知することでコード以外でも有償/無償のボランティアでの参加者を募ることも可能ではないかと思います。
改善案4 - プロダクトオーナー制
一般的な小規模のオープンソースプロジェクトのコミュニティであれば、「ノウアスフィアの開墾」の16節にもあるような
・優しい独裁者
・議決委員会
・巡回式組織
などによって紛争解決するようなことも行われていると思います。「ぼくと応対することで疲弊するというのであれば、コミュニティを離れるという選択をされるのがよい」という発言も、独裁者モデルではよくあることだとは思いますが、COCOA の場合は最終的に fork して別プロジェクトに行く、といったことが不可能なのですから、これらを単純に適用するのは間違っているとも思います。
とはいえ無限に要望を受け入れることもできませんしその必要もありませんから、方向性を決定する組織としてプロダクトオーナーを立てるのがひとつの解決策ではないかと思います。現実の最終決定権者は大臣などの政治的組織になるかとは思いますがそこまでおおげさにすることもできないので、ここで考えているのは、現状を理解していて、議論をとりまとめ、判断権限を持つようなひとを仮想のプロダクトオーナーとして、オーナーが判断できる情報を提示したり議論したり取りまとめたりといった作業を GitHub Issue など(新機能の GitHub Discussions などを活用する方法もあるかもしれません)を使って行うようなことを想定しています。それであっても判断や決定に賛成できないひとがいなくなることはないとは思いますが、現状の結局誰が判断するのかすらも不透明で誰を説得すれば話が進むのかもわからないような体制よりは議論が整理されやすいと思います。
オーナーと書いていますがひとりで責務を負う必要はなくて数人での合議制でもいいと思いますし、輪番でもいいと思います。理想的にはオープンプロセスを主導できる程度にはその目的を理解していて周囲からも信頼されているひとが望ましいので、@hal_sk さんを含めた方々にオーナー役を担っていただくのが簡単かとは思っていますが特に特定の誰かが責任を負うべきという意図ではありませんのでさらに別の有識者の方が入るのもよいのではないかと考えます。
「Be Open」
みなさん手探りだろうとは思うものの、GitHub への参加者側を信用していないのではと思うのです(足を引っ張ろうとしているのでは、工程を公開すると遅延が起きるのでは、etc..)
信頼の再構築だというフェーズなのに他人を信用できません、などという資格もないのではという議論もできますが、まずは信用するところからスタートしないと相互の信頼も生まれようがありません。GitHub にこれまで Issue などで議論に参加している方も、むしろリリース作業のペースを落とさなくて済むように遠慮したりしていると想像しているのですが、実際にはリリースが期待通りには進んでいなさそうで、不安や不明点だけ増えている状況のように思えますのでこのような記事となりました。
オープンプロセスで改善したいという理念が掛け声倒れになってしまわないよう、応援していきたいと思っております。
この記事が気に入ったらサポートをしてみませんか？