プロジェクトの進め方

私はソフトウェアやシステム開発のさまざまなプロジェクトに関わってきた。今かかわっているのは比較的規模が大きく1年くらい続いている。何人もの退職者が出た。死者や病人はまだ出ていないがそれに近い人は数人発生した。

どの業界でも忙しいことはあるだろうが、ソフトウェアがからむとどうにも手の付けられない状況にハマることがある。それをデスマーチと言って、終らないので人を増やすが効果がないどころかさらに悪化し悪循環に陥る。

実力がない、技術がない、知識がない、管理能力がないのが基本にあるのだが、
ことソフトウェア開発においては、人を増やすことは危険である。

大規模プロジェクトになると、「ドキュメント」の作成に追われる。
仕様書、設計書、手順書、検証報告書など。

少人数であれば意思疎通は簡単なのだが大規模になり離脱者や途中参加者が発生すると情報共有のために
ドキュメントが必要になる（とされる）。

しかし、ドキュメントも人の作ったものなのでミスや漏れが当然あり、
あやまった情報が共有され、
その訂正や確認に追われ、
せっかく作ったドキュメント内容を再確認するようなハメになる。

最近思っていることは、excelをなるべく使わないようにすることである。

wordは論外。

私がプロジェクトを管理する立場になったらwordの使用を禁止する。

できればwikiのようなブラウザベースのものを使いたい。

あと、コミュニケーション手段としてメールの使用を制限する。

可能なら禁止したい。


メールは本当に不便。
誰が入っているのかもわからない、何十人も登録されたメーリングリストにあてたメールは、
送るのも読むのも嫌だ。

多くの人が大量のメールを未読のままにしているか、読まずに既読にしたりしているだろう。

何千という数である。


私は未読のまま放置することに耐えられないので、開封して0秒で既読になるようにして、マウスで一通ずつカチカチと既読にしていく。

送信者と件名と1行目を見れば不要なメールはだいたいわかる。

さて、プロジェクトの話であるが、大きく分けて二つのタイプがある。

一つは管理型。もう一つは非管理型。

前者はウォーターフォール方式である。

つまり、最初に要件を確認し、お客と合意をとり、
最初にすべてを固めて決められた期限までに完成させる。

後者はスパイラル型とかアジャイルとか言われる方式で、
プロトタイプあるいは機能を絞ったものを作って
それを徐々にふくらましていく、あるいは精度をあげていくような方式である。
「非管理」といってももちろん管理はする。

管理型は、客やプロジェクト管理者は楽だが、設計実装構築等をおこなう者はつらい。

仕様や設計を最初に固めるとはいっても
まず間違いなく途中で仕様変更設計変更は発生する。

そうなると最初に合意した仕様を変更するか、
もう合意しているから変更できないともめるかする。

だいたいの場合、もめた末に変更になる。

非管理型は、仕様変更設計変更を最初から見込んでいる。

というか、仕様も設計もプロジェクトを進めながら作っていく。

これは古い考えの人、頭の固い人、マジメなひと、中途半端に優秀な人、高学歴な人、
大企業や官公庁で成功してきた人には受け入れられないことがある。

「仕様も決まっていないのにどうして作れるのか」
というものである。

が、

逆に、「作ってもいないのにどうして仕様が決められるのか」

という言い分もある。


私は今、完全に後者の考えである。

いまだに管理型の工程の後戻りがないことを前提しているプロジェクトがある。

大量のドキュメントと意識合わせのための会議やメール送受信が発生している。

メンバーの交代も激しい。

そして管理型プロジェクトの場合、管理者が技術に関わろうとしないという特徴がある。

管理者は報告だけを受けて自分は何もしない。

管理型が有効なのは、すでに一度実施したことがあり、
決められた手順にしたがってたんたんとこなせばよいような場合だけである。

ソフトウェアや通信技術などは変化が非常に激しいため、
そういう例はほとんどない。

だいたいのプロジェクトで培った技術、経験、知識はせいぜい2,3年しか有効でなく、

ほとんどはそのプロジェクトでしか役に立たない。


「経験や知識は後で活きない」という知識だけが、私の人に誇れる財産である。

今はどんなソフトウェアもネットワークでアップデートをおこなう。

作って、出して、売ったら後はしらない、ということは許されない。


昔の考えでは、買ってから修正するなんて未完成品を売っているのかと
怒られるやり方だが、

今は当たり前になっている。

そうなってくると、バージョン管理とか、変更履歴管理というものが必要となってくる。

CVSとか、gitとか、subversionとか、そのためのシステムがある。


私はそういうものがあることを知っている程度で、
ちゃんと使ってはいない。

だが、「ドキュメント」の差分比較は
特に最近非常に多くなっている。

差分比較は有効なツールではあるが、私はあまり好きではない。

なぜなら、差分のない部分が見えなくなるからだ。


たとえば、顕在化していないバグがあっても差分だけ見ていたらわからない。

ソフトウェアやシステムには階層や継承や参照などがあるから、

単純に部分を変更して機能が維持されるとは限らない。

結局、やってみないとわからない。

これだ。

この世界は、やってみないと何が起こるかわからないのだ。

しかし、私が関わってきたプロジェクトは基本的にすべて管理型である。

プロトタイプを作って徐々にしあげるといったやり方はまだまだ許容されづらい。


そこで、私は自分に与えられたタスク内で限定的に
反復型、スパイラル型の仕事の進め方をしている。

簡単に言うと、求められていると思われるものよりやや品質を落としたものを作って出す。

そうすると、怒られるか、直せと言わるので直す。

そうすると、余計なことをしなくて済む。

仕事というのは契約であり依頼であるので、

言った言わないやったやらない、やったなら証拠を見せろ、
ということが発生する。

会議とかレビューとか報告とかいうものは、
よりよいモノを作ろうとか、ミスを防ごうとかいうよりも、
後で文句を言われないようにするのがほとんどである。

文句を言われないためには、
何をやればいいか、何はやらなくていいかをはっきりさせておけばよい。

しかし、そんなになんでもかんでもどうすればいいかは
客もめんどくさいしわからないこともあるから、
おまかせになることもたくさん出てくる。

おまかせになったとき、
どこまでやるかは自分の匙加減次第になるが、
文句を言われないことを主眼にすると
やらなくてもいいかもしれないことまでやってしまうことになる。

つまり、過剰品質になる。

そして納期が遅れる。

完成してから、こんなことしなくてよかったのに、と言われる。

よかれと思ってしたことが全部不要で、
お客が求めていた肝心なものが抜け落ちていたりする。


それはコミュニケーション不足であるとか
確認不足であるとか言われるのだが、

実際には無理からぬことだ。

それをなくそうと思ったら大量の会議や会話が必要になる。

時間の無駄。
だから残業がなくならないのだ。

たぶん、こういうことを言うと、そんなことじゃカネをとれない、という人が出てくるだろう。

私はあまりカネのことにはかかわらない。

見積もりとかほとんどやったことがない。


そもそも、ソフトウェアそのものに金銭的価値を求めるのはどうかとさえ思っている。

今はフリーで使えるソフトウェアがたくさんある。


野菜や魚と同じように、
あるいは車やテレビと同じように、カレーライスや寿司のように、

客が求めるものを与えて対価を得ること自体が、ソフトウェアの本質に反しているように思うのだ。

この業界で生きていくのにいい方法を見つけた。

それはフリーランスになることである。

フリーランスというとカッコいいし難しそうに聞こえるが、

要は非正規雇用である。

これについてはあらためて書きたいが、

非正規雇用者は正社員が背負うしがらみからだいぶ自由になれる。

カネはそんなに稼げないが、少なくとも過労死したりウツになることはないだろう。