元請SIerがTracのような環境を提供できない３つの理由
セキュアに公開されたソース管理システムと課題管理システム、つまりhttps接続のcvs/subversionとtrac/redmineを用意してほしい。
（略）
全てのプロジェクトメンバは計画と設計情報に対するアクセス手段を確保すべきだ。
激しく同意。
ツールの種類はともあれ、この手の情報は、
- 1箇所に集中
- 版の管理
- セキュアなアクセス
- 誰でも参照できる
を実現することよって、関係するすべての人にとって、作業負荷の軽減に寄与するものですから、さっさとやりましょうよ。
導入、周知、初期学習コストだけじゃん。
導入コストなんて、環境構築手順を確立して、場合によっては自動構築スクリプト化すればさくっと終わる話。
導入ノウハウなんて、みなさんいろんなところで公開してくれているわけだし。
初期学習コストなんて、初めて触る人だけの問題。
それよりも、その後のあらゆるコストの低減のほうが、よほどインパクトが大きい。
ファイルサーバーに原本があるのにメールに添付して、
原本と添付と別々に更新してあとでマージがたいへんだー、
とか、
最新情報が伝わってこないまま開発進めて、後から「あれ見てないの？仕様変更になったよ？」
とか
いつまでやってんの。ばかなの？死ぬの？（って初めて使ったー。使ってみたかったー。）
が、少なくとも私が関与してきた限りでは、
出来ないことが多いのも現実なので、そのへんの事情について書いてみる。
できない3つの理由
- 自分の会社のネットワークに好き勝手にサーバーを立てて外部に公開する権限を持っていない。
- 若手はこれらのツールの有効性について理解していても、「上の人」が理解していない為、「Excelで何が悪いの」より先に進まない。
- そもそも無関心。「やることやってくれていれば、それでいい」
権限がない
元請SIer基本的に大企業であることが多い。大企業であれば、IT系企業であれ非IT系企業であれ、情シス部門は別に存在し、
社内のシステムの統括は情シスにて行う。
情シスオフに参加している自分が言っちゃあなんだが、
大企業の情シス部門というものは、基本的に保守的である。
いかに「トラブルのない環境を提供するか」が彼らのミッションだから、当然である。
「内部にサーバーを立てる」どころか「クライアントにソフトを入れる」ことすら監視、指導するわけだから、
「サーバーを外部に公開する」なんてのは、もってのほか、ということになる。
寝技立技駆使して、公開可能な状態まで交渉を持っていける頃には、そのプロジェクトは終わっていることでしょう。
というわけで、
元請SIerとうのは、
クライアントから発注を受けたシステムについて「あーだこーだ」といったり、
実際にシステムにアクセスしたりすることについてはハードルが低いが、
自社のシステム環境について手を出すのは、非常にハードルが高いのです。
この辺、小さい規模で、自社のシステムの自分たちでメンテしているような会社だと、
自由度が高く、良いと思ったものがすぐ取り入れられるのがイイヨネ。
上の理解が得られない
人は変化を嫌うもの。新しいものがいかに作業効率に寄与するか、よりも、それを使う為の学習コストや、
それを運用していくコストのほうにウェイトを置いてしまう。
今までそれで済んできて、それなりに成功を収めたゆえに上のポジションに収まっている人なら、
なおさらのことである。
「所詮手段。何でやってもいいじゃん（否定的な意味で）」
「いまのやり方で十分なこと（と、発言者は勝手に思っていること）を、新しい手段を覚えることに力使うのって違うんじゃない？」
こんな言葉が、業務改善とかに関わっているコンサルからでも、自分のことになると出てきてしまうくらいですから、
「人は変化を嫌う」という問題は、そう簡単には解決しない、永遠のテーマなのかもしれません。
にしても、若手がいくら危機感抱いていろんな勉強していても、
上がこんな態度じゃ、モチベーション下がるよねえ。
そもそも無関心
上の例は、「若手は勉強しているが、上がそれを理解できない」ケース。こっちの場合は、上から下まで無理解／無関心のケース。
もう、どーにもなりません。
業界設立以来disられ続けている典型的な元請カルチャーですね。
さっさと淘汰されてください。と思ってもなかなかそうはならないんだけど。
対策
何ならユーザに公開してもいいってか、突き詰めればユーザこそ、これで管理すりゃいい。そうなるとSIerの仕事は完全にコンサルに特化しちゃうだろうけどね。
はい。これが１つの解です。
実際なんどかやったことあります。私が仕向けたわけじゃないけど。
１つは、CVS止まりでTracまではやりませんでした。
１つは、CVSでもSVNでもTracでもredmineでもない、別の有償ツールでやりました。
ただし、どっちもクライアントがIT系の会社だったときの事例。
それくらい、「モノ」に理解がないと、受け入れてもらえない、というのが現実なのでしょうか。
とくに後者は、こちらから提案するまでもなく、社内標準として推進している最中でした。
やはり、ソースコード管理だけじゃなく、設計情報、管理情報まで共有すると、
コミュニケーションロスやマネジメント負荷がかなり減って、それ以外の問題に取り組む時間に回せます。
全体生産性を向上させ、産み出された時間を、別の課題に振り向けることによって、
プロジェクト全体、システム全体の質の向上に寄与すること。
特に元請SIerは、その主要業務となっている「管理業務」*1に割く時間を最小化し、
プロジェクトが抱える課題、顧客が抱える課題を１つでも多く解決していくことに振り向けること。
それを、コンサル業務と呼ぶのかどうかは別としても、
元請SIerの競争力は、そっちの方向にシフトしていくのではないかと。
もうひとつの解。
「関係者全員、客先に開発スペースを確保して、仕切りなしのタコ部屋開発をやる。」
タコ部屋に全プロセスに関係するメンバーを全員集めて、
重要な課題に関する情報などは紙（フリップチャートなど）に書いて貼り付けておく。
みんなが見えるようにする。
近距離にいること、見えるところに必要な情報が張り出されていること、
これだけでも、コミュニケーションロスがかなり減る。
残念ながら、下請法等の関係でムダに仕切りつくったりフロア分けたり。
開発を請け負う会社は「持ち帰り開発」を望むし。
持ち帰りって社内独自のノウハウを使って生産性高めている羽生さんのところのケース
株式会社マジカジャパンの羽生章洋が書いてるブログ:契約のこと - livedoor Blog（ブログ）
などもあるので、一概には否定できないけど*2、
平均的なところを見ると、どんどん非効率な方向に走っているんだよなあ。
そろそろ私のこの考え方自体を改め、新しいスキームを考え出さないといけないのか。
追記：情報公開制限について
まったく触れていなかった。というわけで、「情報公開に関して厳しい」というのは、実はウェイトとしては低かったりする。
「提案を断る為の口実」程度。
確かに、情報流出に対して敏感になっているのは事実だけどさ。
どっかのセキュアなサーバーに置いといて不正アクセスされるリスクと、
メールベースでばら撒いて誰かのPCから流出するリスクと、
どっちが可能性が高いかっていうと、どっこいどっこいなんじゃないか？
