低予算プロジェクトの醍醐味

昨今の多くのプロジェクトは工数が十分ではない。そのためプロジェクトが失敗するとそのせいにされがちである。
だが少ない工数で成功した例はいくつもある。成功のカギは如何に工夫するかであり知識をどれ程持っているかである。工数は成功の必要条件にすぎない。

例えば、ユーザーが100人以下、商品が5種類に満たない買い物サイトシステムに高価なDBMSやFrameworkは不要である。そのようなことは低予算プロジェクトの開発手法を知っていればわかることだ。しかしそれを知らないSIerは大規模プロジェクト開発手法を適用する。CSVで済むのにORACLEを使い、PHPで済むのにstrutsを使う。
工数がかかって当然である。

以前に私がいたプロジェクトも同じだった。
そのプロジェクトのSIerは多くのライブラリを持っていた。だがプロジェクトメンバーの誰もライブラリの使い方をよく知らなかった。ガイドが難しく教育制度も無かったからだ。

しかしプロジェクトリーダーはそれを理解していなかった。ガイドがあれば開発者はそれを学ぶと思っていた。

このままではメンバーがライブラリを習得出来ないまま開発に入らざるを得なかった。ガイドは不十分だった。講習会が必要だった。しかし講習には予算がいる。プロジェクトリーダーは承知しなかった。

そこで私はライブラリからの訣別を提案した。必要のないライブラリは捨てましょう、そうしないとプロジェクトは遅延しますよ、言ったのだ。

これは脅しと捉えられたかもしれない。クレームと捉えられたかもしれない。だが、結果としてプロジェクトは成功した。リリース日の1ヶ月前にはシステムテストを全て終了していたのだ。

これが不要なライブラリからの訣別という工夫の結果である。

勿論、工夫は簡単ではない。アイデアだけでなく、調整も必要だ。時として覚悟もいるだろう。しかし、それこそが低予算プロジェクトの醍醐味と言える。工夫をすればなんでも上手くいくなんて面白味に欠けるではないか。失敗の可能性があるからこそプロジェクトは面白いのだ。

iPhoneからの投稿

プロジェクト管理者の素養（その３）

段階的リリースでは機能を1人で開発すべきではない。少なくとも2人以上で協業すべきだ。プロジェクトを牽引する管理者はこのノウハウを知る必要がある。

では、なぜ2人以上で開発すべきなのか。理由はいくつかある。

早くできる。
早くできるというのは自明だろう。2人でやれば早いのは当たり前だ。開発効率は上がってはいない。だが、それでいい。求められるのは開発効率ではない。スループットなのだ。

専門知識を生かせる。
適材適所。これも自明だろう。開発者にも得意不得意がある。得意なことをやらせれば効率はあがる。不得意なことをやらせればどころかなんの成果も得られないかもしれない。

ミスが減る。
これはペアプロに通じる。互いの作業を監視する機会が増えるためミスがなくなるわけだ。誤魔化しが効かない。

トランスに陥らない。
これもペアプロに通じる。2人で協業している間は常に適度な緊張感とコミュニケーションが発生する。これではトランスに入ることはできない。トランスとは軽い瞑想状態である。始末が悪いのはトランスに陥った人は皆、自分が集中し作業効率が上がっていると思い込んでしまう事だ。しかし実際は感覚が鈍っているだけでスピードはむしろ落ちているのだ。

このように協業により1+1は3にも4にもなる。だが1、場合によっては0や-1になることもある。協業には相性が必要だからだ。相性が悪ければコミュニケーションを円滑に行えなくなる。また1人の技術者が極端にレベルが低くてもダメだ。もう1人の技術者がパフォーマンスを発揮出来なくなる。

プロジェクト管理者はこうしたプロジェクトの特性、メンバーのスキルや相性、クライアントの要望（要件ではなく）、見積りの不確定性等を管理し、最善の運営を執行する責任がある。だからこそ、専門知識を持ち、訓練を受けた者でなければ務まらない。システムエンジニアの経験を積んだからそろそろプロジェクト管理者になってもいいだろうというのが浅はかなのだ。

プロジェクト管理者の素養（その２）

元サッカー日本代表監督のイビチャオシムが、監督に最も必要なのはカリスマではなく知識だといった。これは炯眼な言葉だ。そして全く同じことがプロジェクトマネージャーにも言える。

前に段階的にリリースすることで開発期間は短くなると書いたが、実は短くしない方が良い場合もある。
段階的リリースではリリース直後に次のリリースが待っている。つまりリリース間隔が殆どない。だがそうなるとフィードバックも小さくなる。
だがリリースしてからしばらく使ってもらい次のリリース直前に再度ヒアリングすればより大きなフィードバックが得られる。より優しいシステムを納品できる。
従来の段階的開発をW型というならリリース間隔をとるこの手法はV_V型である。両者にはメリットデメリットがある。W型はスピードがあり開発コストもかからない。対してV_V型はクライアントの要求を最大限に引き出す。

プロジェクトマネージャーに必要なのはこうした開発手法の知識である。どんな開発手法が相応しいかを判断するには知識が必要だ。開発手法の知識がないプロジェクトマネージャーなんて、プログラム言語を知らないプログラマと同じだ。
だが、この様なプロジェクトマネージャー失格とも言えるプロジェクトマネージャーは少なくない。これは本当に困ったことだ。

プロ失格の技術者

仕事が遅い技術者をできないとは思わないし、何度も同じことを聞く技術者をできないとも思わない。できないと思うのは依頼主を無視する技術者である。

以前、ある人（仮にＡさんとしよう）に簡単な仕事を頼んだ時の話である。

簡単な仕事というのは構成管理用の表の作成であった。具体的には「１列目にフォルダ名、２列目にファイル名、３列目以降にそのファイルのサイズや拡張子を書いてくれ」と指示をした。

皆さんがこの様な指示をされたらどんな表を作るだろうか。

Ａさんは想定した時間を遥かにオーバーして作った表を持って来た。まぁ、それだけならたいしたことはない。だがその１頁目をみて驚いた。
明らかに名前の違うファイル名がいくつもあったのだ。１頁目からこんな間違いがいくつも見つかる様では他の頁も知れているが、更に驚いたのはフォルダ名がない行もあったことだ。ファイル名の間違いはともかくフォルダ名の未記載は明らかに指示を守っていない。私はこれをＡさんに指摘した。すると、フォルダ名はあえて書かなかったという。何故と聞くと、次の行も同じフォルダなのだから書く必要ないと言う。
確かに繰り返しフォルダ名を書くのは冗長だが、依頼者である私としてはソートや検索をしたかったので冗長でなければ困るから指示通りに作成してくれと言った。ところがそんな書き方では見にくくなるから必要ないとガンとして聞かない。あげく、そもそもこんな単純作業はツールにやらせるべきだ、私がやる作業ではないと言う始末。
結局その後、細かい作業指示とその作業をする理由の説明、単純作業で申し訳ないが必要なのでやってくれという説得を１時間近くかけてする羽目になった。だが、それでも完了せず、結局引き取る羽目になった。
この教訓は、仕事を依頼する時に説明だけでなく説得も必要な人間もいるということだ。この種の人は依頼主の立場で考えず、依頼主が何を望むのかを優先しない。論外だ。
しかし、残念ながらこのような技術者は少なくない。

プロジェクト管理者の素養

システム開発の現場において工数の見積もりは必須だ。しかし、従来型の開発では精度の高い見積もりは極めて困難である。見積りのための情報が揃っていることは稀であり、たとえ揃っていたとしてもそれを収集する時間はないからである。
だが多くの現場ではその状況でも見積もらなければならない。不足情報は過去の経験と勘で補うしかない。

あるプロジェクトにＳＥとして参画したＡ君の最初のタスクはＸ機能の設計だった。マネージャーにどれくらいの日数がかかるかを問われたＡ君はそれぞれ１週間かかると答えた。マネージャーはそれにあわせてスケジュールを組んだ。
ところがＡ君は見積りを間違えてしまっていた。つまり本来２週間かかる作業を1週間と言ってしまっていた。だが、気付いたのは作業に入って２日目であった。
すぐにマネージャーに報告したが「１週間と見積もったのはあなたなのだから責任をもって間に合わせてくれ」と押し切られてしまった。徹夜で作業をしても期日には間に合わないのは明らかであった。それでも何とかするしかない。結局徹夜と土日出勤の覚悟を決めた。

見積りミスの責任がSEに押し付けられるケースは少なくない。だが技術者の多くは駆け引きを知らない。こうした交渉スキルは管理者が上である。見積もりミスという負い目もあり管理者に「責任を取れ」と言われれば大抵のSEは渋々ながら従う羽目になるだろう。SEはもっとマネージャーとの交渉スキルを磨くべきだ。
Ａ君も、納得していない部分もありながらも「自分のミスだから」と残業を承諾した。しかし寝不足で作られた設計書の品質は低い。品質が低ければ後工程で手戻りが発生する。悪循環となる。

だが、こうした悪循環はSEの交渉スキルの低さだけが原因でおきるわけではない。プロジェクトマネージスキルの低さもあるのだ。

作業Ａを行う条件が作業Ｂの完了である場合、それを考慮してスケジュールを組まなければならない。それができなければログイン画面やメニューができていないのに社員照会画面を開発するような状態になってしまう。
これはパート図を知っていれば簡単な作業だが、驚くべきことに多くのマネージャーはパート図を知らない。パート図はプロジェクトマネージメントの基本である。つまり基本を知らない。

この様なプロジェクトマネージャーの下で働く技術者に心から同情する。