プログラマの思索

以前のSQIP2016で、チームの開発環境が開発プロセスの品質を向上させる点を指摘していた資料があったのでメモ。
そこから、未だにチームの開発環境が導入されない理由も考えてみた。
途中で書きかけなので、後で書き直す。

【参考】
モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8 - MassKaneko.Out

(引用開始)
チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012～2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2、SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。
（中略）

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。
(引用終了)

【1】僕は、「私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えております」という意見に、完全同意だ。

製造業の品質管理に影響を受けすぎている人達は、Excelドキュメントによる標準プロセスの構築ばかりに意識が行きたがる。
しかし、そのやり方が実際の案件で作業にブレーキを掛けたり、逆にシステムの品質を向上させない症状を生み出している現場を色々見てきた。

むしろ、チームによる開発を支援する共通基盤を準備した方が、開発スピードも早くなるし、品質向上にも役立つ結果になる。

では、なぜ、彼らはチーム開発の開発基盤を構築して運用する方向に目が向かないのか？

【2】いくつかの理由が考えられる。

【2-1】開発環境の構築に投資する発想がない。

開発基盤を作ると、保守コストがかかる。
日本のプロジェクトマネージャには、開発環境に投資する、という発想がない。
管理コストに投資する発想がない。
案件をまたいだ共通の開発基盤に投資する場合、社内の稟議申請が必要になり、経営層を納得させるだけの理由が作りにくく、普通は通りにくい。

但し、OSSの開発基盤ならば、プロジェクトマネージャに技術力さえあれば、自身の人件費以外はほぼ無料で導入できる。

【2-2】従来通りの開発スタイルによる過去の成功体験があるから

以前、新しい開発ツールを導入して失敗した経験がある。
新しい開発ツールの考え方に慣れることを嫌う。

特に、有償のパッケージ製品には、販売元の会社のプロセスが埋め込まれている為、現場のプロセスにはなかなかフィットしない。

Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想: プログラマの思索

標準化作業は、SDCAの考え方。
つまり、誰もがいつ、どこでも同じ作業をやれるような仕組みを標準として定め、その標準に従って、DCAを回すべき、という発想。

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

この標準化の考え方は、工場のブルーカラー、外食チェーンや他店舗展開の小売業の作業者、コールセンターやサポートデスクのオペレータの管理には向く。
しかし、IT技術者のようなクリエイティブな人には向かない。

アジャイル開発は常識だ: プログラマの思索

なぜなら、IT技術者である限り、最新技術のキャッチアップは必須。
よって、過去の経験が全てクリアされて、一から学習し直す覚悟がいる。
しかし、その学習コストを各自で責任を負うのはハードルが高い。

【2-3】既に投資した社内ツールを捨てられないから

社内に既に、内製化したツールがある。
従来の社内ツールを捨てられない。
従来の社内ツールに、数多くのプロセス資産が蓄積されているので、埋没コストになる。

一般に、2000年頃にBTSが必要と認識した、レベルの高い会社で、そういう社内ツールを内製化した場合が多い。
しかし、OSSの発展に比較すると、UIが古かったり、機能改善が追いつかず、OSSよりも機能が劣っている場合が多い。
なのに、社内ツールを廃棄すると、埋没コストになるから捨てられない。

Redmine運用の感想を集めてみた: プログラマの思索

Sean Osawaさんのツイート: そういうのってホントにあるんだなぁ〜 RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

(引用開始)
フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。
(引用終了)

すなわち、組織変革の障害になりうる。
結局、変革に対抗する力となり、組織慣性として惰性のまま現状維持が続く。

埋没コストとは・意味｜MBAのグロービス経営大学院

サンクコスト（埋没費用）とは | カイロスのマーケティングブログ

【2-4】開発環境は衛生要因であり、動機づけにつながらないから

開発環境が導入済みだとしても、動機づけにつながるとは限らない。
環境がなくても、従来通りやり続けてきた。

一方、優秀なチームでは、開発環境が導入されていないと、モチベーションを落とす。
むしろ、開発環境は導入されていて当たり前。
つまり、開発環境の導入は衛生要因であり、動機づけ要因にならない。

ハーズバーグの動機づけ・衛生理論 ｜モチベーション向上の法則

ハーズバーグの二要因理論 ? リーダーシップインサイト

【2-5】チームの成熟度が低く、Redmineを使いこなせないから

開発環境が既に用意されているとしても、上手く使いこなすか否かは、チームの成熟度に依存する。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

チームの成熟度に対するPMOの支援度合いは、リーダーシップの状況適合理論（SL理論）で説明できるのではないか。

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

SL理論 ? リーダーシップインサイト

SL理論（状況対応型リーダーシップ） | マネジメントオンライン

たとえば、チームの成熟度が指示待ち人間のレベルである場合、Redmine導入と運用は、RedmineエバンジェリストやRedmine警察の役割の人達が、逐一メンバーにコマンドコントロールする必要がある。
つまり、PMOは指示型リーダーシップを発揮して、チームに相当介入せざるを得ない。

一方、チームの潜在能力は高く、Redmineのような新規ツールを欲しているならば、RedmineエバンジェリストやRedmine警察の役割の人達は、コーチングや運用支援のようなスタッフ的な立ち位置で支援すればいい。
つまり、PMOは、コーチングのような説得的リーダーシップ、参加的リーダーシップを発揮して、チームを支援すればいい。

最終的には、チームの成熟度が自律的になっていれば、PMOは委任的リーダーシップ、つまり、サーバントリーダーシップに似たリーダーシップを発揮して、チームにRedmine運用そのものを委任すればいい。

そうなると、各チームは自チームに特化したRedmineが欲しくなるので、チームごとに複数のRedmineインスタンスを提供する方式になるのではないか。
つまり、野良Redmineが普通の状況になるかもしれない。

個人的には、現代において、PMOが教示的リーダーシップ、指示的リーダーシップを発揮してチームをコマンドコントロールしなくてはならない状況は相当減っているはず、と思う。
ネット上に情報もたくさん流れているので時代の方向性は理解できるし、若い人ほど潜在能力が高いように感じるから。

【3】他にも色々考えてみる。

【追記】
akipiiさんのツイート: "個人的には、@MadoWindahead さんがPMOでチームに関わる立場はSL理論でどのポジションにいるのか、知りたいかな。指示的リーダーシップはさすがにないと思うし、委任型リーダーシップであれば、そもそもPMOがチームに関わらなくてもいいので、説得的または参加的リーダーシップかなと推測。… https://t.co/lg3gcKgLZ7"

門屋　浩文さんのツイート: "指示型は敢えてやらず 説得と参加、不安の軽減、やってみせて、効果を感じてもらうことかなあ サーバントリーダーシップはどこまでできてるかの評価は分かれるところかも… "