モジュール化によるホワイトカラー労働の生産性向上のための基盤ソフトウェア「MIP」の提案
金澤圭吾 	  佐藤哲也
†1

†2

キーワード：生産性，ホワイトカラー，バージョン管理，Git

The Proposal of Productivity Improvement Software “MIP”
for White Collar working
KEIGO KANAZAWA 	  TETSUYA SATO 	  	 
†1

†2Keywords: Productivity, White-Collar, Version Control, Git

1.   解決する課題とその背景作業者の詳細な作業履歴を記録することで，将来的な不具合の発生原因の追求を行う．これらの課題を解決するため	  ホワイトカラーの低生産性は我が国の大きな課題である．に，バージョン管理システム（VCS）と呼ばれるソフトウ

一般にホワイトカラー労働は非定型性や属人性を有するたェアを導入することが一般的である．

め，製造業現場で有効とされる生産管理手法が有効ではな

様々な VCS が存在するが，近年 Git が事実上の標準にないとされる．また，労働人口の減少局面にあって，リモーっている．Git の特徴としては分散型リポジトリを採用しトワークや外部の知的生産リソースの活用が求められていているために，開発者が原本リポジトリの汚染を気にするるが，管理の困難さや従前の勤務管理の方法とのミスマッことなく作業を記録できることがある．また，最終的に優チから存分に普及しているとはいえない．また，我が国固れた改善パッチが完成した場合は，そのパッチを大元のリ有の勤労文化や商習慣などが影響して生産性を押し下げてポジトリに反映するよう依頼することも可能である．このいるという指摘もある．

特徴は多くのオープンソースソフトウェアの開発において	  本論ではその課題解決のためのソフトウェアを設計・提有効に活用されており，際立った効率性を実現している．

案することを目的とする．

しかし，VCS はホワイトカラー労働一般でみるとまだまだ2.   提案の理論的背景普及しているとはいえない．これらの普及により大幅な生	  本提案の動機としては，インターネット関連産業におけるソフトウェア開発方法論で採用されている方法論を一般的なホワイトカラー労働に導入することにある．それにより，成果物の品質保持や進捗の可視化の大幅な改善が期待できる．具体的には，バージョン管理ソフトウェアの導入による生産プロセスの可視化と継続的な生産物の品質維持等の要素を主に考えている．以下に幾つかの論点について整理する．
2.1   ソフトウェア開発におけるバージョン管理の重要性
一般にソフトウェアの開発では，顧客のニーズ対応やセキュリティ対策などのためにバージョンアップが頻繁に行われる．つまり，生産物として僅かな複数の違いをもつ派生品が同時並行的に多数存在している．また，開発のプロセスにおいても過去のコードの状態に戻す必要がある．また産性の向上が見込める．
2.2   修正プロセスのモジュールとしての commit
Git では修正履歴は commit と呼ばれる．システム理論的にいえば，この commit は修正プロセスのモジュラリティを高めて可搬性を実現したものである．commit 情報はその内部で修正前の状態と修正後の状態を保持している．そのため，修正前の状態が同一なファイルであるリポジトリであれば，当該 commit を異なるリポジトリに適用できることになる．また，修正によっては原理的に別ファイルの複数箇所の修正を統一的に扱う必要があるが，コミットとしてまとめることで問題を回避することができると言った特徴がある．
この修正プロセスをモジュール化した commit は情報の変更作業に可搬性をを提供し，オープンソースの高い生産性†1 （株）デザインルール	  	  Designrule Inc.
†2 （株）デザインルール	  	  Designrule Inc.

1

を実現する鍵となる技術である．この commit を用いた情的で安全とされる利用方法をパッケージ化して提供するこ報生産プロセスのモジュール化が非ソフトウェアの生産にとをめざす．これらのローカルでの履歴保存と履歴の共有も適用できれば，高い生産性が実現できる可能性がある．

操作を自動化することにより，複数人での制作物のリアルそこで，MIP では Git の活用を考えたい．

タイム共有を実現することが可能である．

2.3   ホワイトカラー労働の整理

3.2   標準的な利用方法としての Github-flow	  MIP の検討に入る前に，本論における幾つかの前提概念	  今日の開発現場では単一のソースコード群に対する複数を整理しよう． 本論におけるホワイトカラー労働の定義とメンバー（チーム）による同時並行的開発が中心であるが，して，抽象的な情報学的シンボルの取得と作成及びそのたチームで一つの制作物を制作する以上特定箇所の重複修正めの操作をあげたい．別の言い方をすれば物理的な行為をは避けられない．VCS ではこのような現象をコンフリクト除く，何らかのコミュニケーションやデザインなどの行為が発生したと表現する．コンフリクトが発生すると，人手の総称がホワイトカラー労働である．この定義はやや曖昧でファイルの修正を行うコストが必要になり歓迎されない．

であるが，一般的なホワイトカラー労働の持たれるイメー

そこで，Git を基盤としてコンフリクトの発生を最低限にジと大きく変わることはないと考えている．

抑えつつ，同時並行的に複数人数で編集を進めていく方法	  ところで，情報をストックとフローに分けて考えること論が開発されている．代表的な方法論として Github-flow がもしばしば行われる．それをホワイトカラー労働に適用す挙げられる[2]．

れば，労働者内部に蓄えられた知識がストックであり，目l  管理者がマスタ（原本）ブランチ(※)を準備する．

先の必要な業務処理のために流通する情報がフローである．

l  変更する作業者はマスタのコピーを作成し，作業者さらにフローもインプットとアウトプットに分けることが独自のブランチ（名）を設定する．

できるだろう．一般にインプットはコミュニケーションをl  変更は作業者独自のブランチ上で行う．

通じて得られた情報や，知識情報を書籍や Web サイトなどl  変更作業が終了したら，当該作業をあらわすコミッから収集する行為に相当するであろう．一方，アウトプッ

ト集合をマスタブランチに取り込むよう要求を行

トは業務の遂行のために作成された文書類の作成が相当すう．

るといえる．

l  要求がある場合，管理者ないしは確認を委託された	  ホワイトカラー労働の生産性を検討する上では，本来こ者は当該変更作業が正当な内容であり，取り込みにれらの 3 要素であるストック，インプット・フローおよび問題がないことを確認する．

アウトプットフローのそれぞれが適切に計量できることがl  確認の上，問題がない場合はマスタ上に取り込む．

望ましい．しかし，人間のもつストック情報量を適切に計※）ブランチとは，VCS における幾つかの派生バージョン

測することは現実的ではない．いくつかの有効性の乏しいの存在を示す．

資格制度が代替的に存在しているに過ぎない．インプット・フローの計測はパソコンを視聴デバイスとしている活動に	  その際に，変更者はサイクル内での変更の修正サイズがついてはおそらく可能であろう．だが，それ以外のデバイなるべく小さくなるように配慮する．つまりマスタからコスによる認知を計量することは現時点では難しい．

ピーを作成して，取り込み要求を作成するまでのサイクル	  一方，比較的容易と思われるのはアウトプット・フロー時間をなるべく短くする．その時間が短ければマスタ側でである．特に情報の有効寿命の長い重要な情報であればし別の変更要求が受け入れられて重複修正の発生するリスクっかりとした記録を行うことは必定である．実際にソフトを減らすことができる．もちろんそのためには変更者に対ウェア開発における VCS のログはソフトウェア開発におする作業依頼のレベルで十分に小さいタスクとなっている

ける生産性の計量メトリックスとして活用されている．[1]ことが必要である．

3.   MIP の提案の概要	  もっとも，修正のサイクル時間を短くしたとしても，変更作業中に変更作業を行っている箇所が他作業者によって3.1   Git 操作の自動化変更されるリスクは常に存在している．その場合は作業者	  Git が優れた VCS であり，多くの開発者に支持されていの固有ブランチ上でマスタに生じた変更を吸収し，最新のることは既に述べた．しかし，一方で大きな問題としてはマスタに対する変更要求として作成する義務がある．

操作が難解であることがあげられる．もとより開発者にと	  これらの Github-flow とよばれる方法論は筆者らの研究っても使いにくいと言われることもしばしばである．また，開発により部分的に自動化することが可能である．これら

Git を一般的に利用しているチームでは，やってはいけなの処理により難解とされる Git の利用を自動化するソフトい操作などが存在している．これらの操作を初心者が実施ウェアが実現することになる．

してしまうことに対する恐れも大きな問題点である．

3.3   自動化に伴う commit 粒度の問題	  そこで，MIP では，これらの Git の利用方法のうち標準

MIP では，commit 作業を機械的に記録することになる．実2

際にはファイルの保存が行われるたびに commit を記録すの類似した文書にする変更を一つの作業で済ませることなることになる．しかし，本来の Github-flow を始めとしたどが可能となる．このような効果は VCS を導入した場合にGit の流儀では，commit は意味のあるまとまり毎に作成さ得られる重要な変化である． しかし，分散型 VCS であり，れることが望ましいとされる．それと比較すると明らかに継続的改善の基盤として用いられることの多い Git 技術を細かい粒度で保存することになる．その点は今後の課題と導入することのメリットはそれだけにととどまらず，様々してあげられる．しかし，Git における commit は複数のな波及効果を生み出す．本章ではこれらの効果と応用可能commits を合成して一つの commit にすることが可能であ性について整理する．

る．将来的には commit の内容を知能的に判断して意味の4.2   作業ログとしての commit と可視化

あるまとまりを実現できることが望ましい．

リポジトリに記録されている commit を確認することで，3.4   継続的改善作業の適用作業者の作業ログを取得することができる．これにより，今日的なアジャイル開発とよばれる，ソフトウェア開発方作業の進捗のリアルタイム可視化が可能になる．つまり作法論の大きな特徴として，継続的なインスペクション（ソ業者がいつの時点でどの程度の作業をしているのかを客観

フトウェア・テスト）とビルド（デプロイ）をあげること的に計測できることにつながり，作業者の生産性を把握すができる[3]．これは，共通リポジトリで管理されるソースることが可能である．

コードが変更されるたびに，当該ソースコードの品質を機4.3   文書作成・データ作成プロセスの証跡記録としての活械的・ソフトウェア的に確認することである．これにより用バグの混入を早期発見することができ，コードの品質を担ログを逐次記録できる性質を利用することで，文書の真正保することが可能になる．

性や作業プロセスの正当性を担保することが可能である．

ところで，ソースコードの品質については，実行結果が正

例えば，不正な論文作成プロセスが研究コミュニティにおしくまた安定して動作をするというソフトウェアに本来求ける問題化していく中で，これらの記録を保持していくこめられる性質に加えて，他の開発者にとっても読みやすくとで自身の正当性を保護することが可能になる．

メンテナンスや修正が行いやすいという性質も重要である．

4.4   自動校正等の自動化処理

その 2 つの性質のうち，前者の性質は一般的なホワイトカ

また，commit が行われた動作をトリガーとして，様々な自ラーの成果物については定義が困難であるが，後者の性質動化処理が可能になる．先に述べた継続的な校正作業などは極めて重要である．

はその性質を利用している．その他にも，変更があったこ

読みやすいコードは適切なインデントの有無や一行の長さとを関係者に通知することなどは一般的に考えられる．

が一定範囲内で収まっているといった，幾つかのルールに

4.5   知的生産の自動化に向けた履歴データとしての活用従っているかどうかで判定されることが一般的である．そ文書の加筆や修正などの作業を細かい粒度で把握できるたして，そのルールチェックは一般的に lint と呼ばれて，コめ，作業者の作業を変更差分として定義することが可能でードの執筆ルールに準じているかを判定する仕組みを使うある．これらのデータが十分に集まることで，校正ルールことが多い．の機械的学習が可能になることは十分に有り得る．これに近年に入り，この lint のメカニズムを校正作業のように一より，ヒューリスティックに与えられない暗黙的修正ルー般的な文章構成に用いようとする技術が登場している．

ルが生成され，いずれ機械的な校正案が自動生成される可[4][5]まだ現段階では明らかな文法の誤りなど，比較的シン能性は十分にある．

プルな校正にとどまっているが，自然ご処理技術や人工知能技術の進展とともにいずれ高度な校正処理がソフトウェ

5.   おわりにア的に実現する可能性は高い． そこで，本ソフトウェアで本論では，ホワイトカラー労働の生産性向上のためのソフは，これらの lint 技術を一般的なホワイトカラー労働の成トウェアとして，MIP を提案する．MIP は現代的なソフト果物に対して適用する事を検討する．

ウェア開発方法論の中で生み出されてきた知的労働を効率

4.   MIP 導入による効果と応用可能性化する幾つかの枠組みを，非ソフトウェア開発以外の分野にも適用することで，ワークフローの革新的改善を目指す

4.1   モジュール化による効果ソフトウェアである． 発表では作成中のアプリケーション

commit が修正作業を意味するモジュールであることは既のデモを含めてディスカッションできればと考えている．に述べた．このモジュール化によって従来の直線的な作業	  なお，この論文は mip アプリケーションを使って作成さ経路に限らないホワイトカラー労働，知的生産が実現できれた．

る．例えば，校正を要する文書に対して校正を複数案用意し，最も優れた構成案を事後的に採用することなどが極めて容易に可能となる．また，提出先と形式が異なるが内容

参考文献
[1]

門田暁人, 伊原彰紀, 松本健一. ソフトウェアリポジトリマ
イニング. コンピュータソフトウェア. May 2013, vol. 30, no.

3

2, p.52-65.
Scott Chacon. “Github Flow”. https://gist.Github.com/Gabkm/3705015, (参照 2017-02-07)
この手の議論はブランチ戦略と呼ばれる．有名なものとして
Git Flow,Github Flow, Gitlab Flow が挙げられる．
[3] Martin Fowler, Matthew Foemmel. “継続的インテグレーション”. http://objectclub.jp/community/XP-jp/xp_relate/cont-j, (参照2017-02-07)[4] “Textlint”. https://github.com/textlint/textlint, (参照 2017-02-07)[5] “Redpen”. http://redpen.cc/, (参照 2017-02-07)[2]4