ソフトウェア開発時の管理コストを少なくする

本業の開発時間を増やすために

ソフトウェア開発では、なるべく本業の開発に専念している時間を増やしたい。
そう思っている人、チームは多いでしょう。
ソフトウェア開発の管理コストは、管理の手を抜けばいいわけではない。放ったらかしにしたら、そのつけは開発を失敗に導く。
だから、課題・作業の管理のしかたを組織として上手にしていく必要がある。
異なる考え方の組織での開発経験をしてきたので、その中でソフトウェア開発時の管理コストに関わる２つのスタイルを述べる。
(管理コスト以外の要因についてはとりあえず、あまり述べない。）

ソースコードの管理コストを減らす

開発中のソースコードの管理方法の改善自体が、まずは本業の開発に専念する時間を増やすことにつながった。
git 解説記事 にたどり着くまでには、SVN, CVS, RCS(新しい順から記載)といくつものコードのバージョン管理ツールを経てきた。
今の便利なツールがなければ、どれだけ生産性が低下するかはよくわかるだろう。

開発成果物のドキュメントの作成コストを減らす。

開発成果物のドキュメントの作成コストを減らすことがされてきた。
ソースコードのドキュメンテーションコメントから、ドキュメントを自動生成することなどはその１例だろう。
Doxygenを使って実装のドキュメントにする流儀は増えた。（と同時に、不完全なドキュメンテーションコメントで生成したhtmlを納品物とされてしまうこともあるが。）

Github がソフトウェアの配布の標準の１つとなってきた効果も大きい。
ソースコードリリース時のドキュメントをREADME.md とマークダウン言語で書いて、何のライブラリなのか、前提条件、インストール方法、使い方などを含めるのが標準になっている。
また、Jupyter notebook 解説記事を使って実行結果のドキュメントを作るのも、ドキュメンテーションコストを下げる部分の一つだ。
そういったドキュメンテーションコストを下げる方向に移行している組織が増えていることはとてもいいことだ。

開発成果物のインストールコストを削減する

• 標準的なインストールのしかたを採用しよう。
• データファイルの取得を自動化しよう
• パッケージ管理などを採用しよう
• コンテナ型の仮想化環境を利用して、ライブラリのバージョンなどの違いに基づく問題を回避しよう。

開発の管理コスト

そして今、開発組織によって差が大きい部分は、ソフトウェアの開発計画の全体像にかかわる管理コストだろう。
そのことを以下の述べたいと思う。

トップダウン型の組織構造の1例：

• 組織のトップから上から順に階層を経て、現場のメンバーに対して作業が割り振られる。

• 作業の進捗状況は、下から上に集められる。
  　進捗資料作成　＞　チーム長へ

• 組織の上層部は、自分の判断について自信を持ち、決断する。

• 組織の上層部（もしくはその指示に従う人）の労力の何割かは、各担当者に書かせたExcelで書かせた進捗を集めて
  　PowerPointで資料を作成する。
  チーム長　＞ 上位の組織単位　への報告用資料

• 組織の上層部は、そのPowerPointを元に判断をする。

• 会議の際は、発言権が上層部に偏っていて、現場のメンバーの発言は簡単に打ち切りを命じられることがある。

• 会議の際には、作業はシーケンシャルに進み、コンカレントには進まない。

上記の例の場合の特徴：
- 情報の流れが一方的であって、瞬時に双方向でのやりとりをすることがない。
- 時として起こること資料を作成させたがる組織の上層部は、重大な判断を行った時のその時の議事録を残さない場合がある。
（事前に作らせておいたPowerPointの資料は残されているのだが）

• 組織の中のチームＡとチームＢがあるときには、必ずチーム長を通してから現場のメンバーで話をしなさいという場合がある。

• 完全に綺麗にわかりやすくレイアウトされたPowerPointのスライドでないと話を聞くことを拒絶する人もいる。
  　　「もう少しわかりやすく、データをきちんと揃えてから持って来い。」

• メールは、相手の言質をとるための手段になっていることもあり、双方のアイディアを高めるための手段とはなっていないことがある。

• １件のメールは他のメールを見せなくするレイアウトが多い。

フラットな組織構造の１例：

• PowerPoint,Excelよりも付箋紙が活躍する。
  • 個々の担当者は、付箋紙に、自分の分のタスクを書く。
  • 付箋でチームのタスク＆プロジェクト管理をやってみたら色々捗った
• 表示範囲に限りがあるモニタよりも実際のボード上の付箋紙・手書き
  • タスクが付箋紙としてボード上にあるので、一覧性がよい。
    • Ｅｘｃｅｌの場合だと、「EXcelの別シートに書いてあった」。「Ｅｘｃｅｌシートのとてつもなく下に書いてあった」などという状況が発生します。
    • 全員から集めて、誰かが集約するという作業が発生します。
• 書類を綺麗に書くことに時間をかけない。
• チャットに類似したツールで、短く簡潔なやりとりを繰り返す。表示が短く一覧性を損なわない。
  • 短い投稿に刺激されて、その内容に義務のない人から、別のアイディアがだされることがある。
  • 見てもよく、見なくてもよいという領域がある。
  • 大流行中・Slack（スラック）の使い方を隅々まで徹底解説！（保存版・1/全10回）【設定について】

技術的な内容に対する判断は、誰が言ったよりも、中身自体が重視される。

両者の比較

・トップダウン型の組織の場合

同じ作業の繰り返しの場合、前にやったことのある内容がそのままヒントになる状況の場合、誰が判断したという責任重視の場合、トップダウン型の管理の方法が効果的な場合も多いだろう。

　　ビルの建設現場で付箋紙を張りながら、次どうするか考えられても困ってしまう。

ソフトウェアの管理コストをどう少なくするのかという問題は、その組織で開発しようとする対象が、どれだけ未知な要素を含んでいるかによって変わってくるのではなかろうか。
　銀行のシステムの場合、しなければならないこと、してはならないことはあるだろうが、しても良いこと、しなくても良いことという自由度があるようには見えない。
困難さは、現実世界の制度の厄介によって引き起こされている分が大きいのではないかと、門外漢は推測する。
たとえば間違ったデータがあったときにそれを訂正する手段は、同時にシステムに対するセキュリティホールになりやすい。
　いずれにせよ、未知の不確定の要素があるのではなく、現実の組織の中にある組織運営の厄介さや、ソフトウェア担当者は知らない部分を、どうしているのか、どうしてほしいのかを明確にする部分が残っているにすぎない。
　だから、開発する対象の違いによって、開発管理の手法も違ってくる部分があり、一方が他方に対して優劣をもつものではないらしい。

付記：
　やり方は別に２つだけあるわけではない。
　トップダウンの組織運営でも、付箋紙を使って、課題をリストアップして、それをボードに並べて、それを用いて会議に使ってもいいわけです。