納期と予算はプロジェクト外で決定される。仕様はプロジェクト内で決定できる。

ソフトウェア開発プロジェクトの初期段階は、情報量が圧倒的に少ない中で仕事を進めていかなければならない。これから作り始めるものについての情報は、プロジェクト参加者のそれぞれの頭の中にあるが、全員の共通認識が出来ていることはまずありえない。

最悪なのは、誰の頭の中にも完成イメージがなく、「誰かが考えているだろう」と全員が思っているという場合だ。こういう場合は、あの人が大丈夫だと言っているからなんとかなるだろう、という甘い考えの元、わかりやすいところから作り始めて後で泣くという、典型的なアンチパターンである。

顧客側が持っているイメージを、開発側に過不足なく伝えるのは難しい。多く伝えすぎると見積もり段階でコストがあがりすぎ、少なく伝えると本当にやりたかったことが出来ない状態で納品される。なので、イメージを紙に最初に落としこめないのであれば、予算ありきでプロジェクトを開始するしかないのである。

顧客は予算をどこからともなく捻り出す際に、納期も設定してしまう。投資した予算をいつぐらいまでに回収できるかという目標を立てて、それに伴いプロジェクトスケジュールを決めるからである。納期は予算に紐づいていて、その時点でプロジェクトのライフタイムが決定する。

そのような事情から、プロジェクト開始時点では、予算と納期は顧客側により決定されてしまっている。どちらもそれより短く、安くする方向にしか力は働かない。プロジェクトにアサインされた人がコントロールできるのは仕様だけである。プロジェクトの目的は提示されているが、それをどう解釈するかはプロジェクト内部でコントロールできなければおかしい。要求仕様はあくまでも仮のもので、その裏にある真の目的を見定める必要がある。

表に出てきている要求仕様をそのまま形にするのではなくて、最終的にどうしたいのかから逆提案して、そっちの方がより目的に適っている、と顧客に納得してもらえれば、すぐに仕様は変わるのである。開発側の特徴というかノウハウというのはその部分である。

インターネットに公開されている技術要素を知っているだけでは、顧客になんの影響も与えない。開発コスト削減だけでは顧客は反応しない。顧客の中に入っていって、技術と目的を結びつけて始めて顧客が反応するのである。

予算や納期がコントロールできないと嘆くのではなくて、仕様をコントロールすることで予算内、納期内になんとかするのが、プロジェクトマネージメントであると思う。

プログラマはどうやって修行するべきか？

以前ならいざしらず、今の企業は新卒採用も中途採用もどんどん採用基準がいっしょになってきている。採用基準がいっしょということは、その後の待遇も同じということを意味する。極端に言うと、新人教育しなくなるということだ。大手の一部は新人をみっちり研修して囲い込もうとするが、それ以外の企業は即戦力だけを求めるようになっている。

新人教育しないのであれば、プログラムやシステムについての一般的な教養を学ぶ機会は、専門学校や大学に託すということになる。だが大学もコンピュータのエクセルやワードの使い方以上の、システム寄りのことを教える学科は少ないし、専門学校でビジネス系ソフトウェアの作り方のカリキュラムというのはあまり聞いたことがない。

そもそも、大学も専門学校も、教える先生自身がどこまでソフトウェア開発に関わったことがあるのかというと、それほど経験がない場合が多い。だいたい一人でプログラムを組ませて終わりである。あまり仕事向きの教育とはいえない。

さて、企業はもう教育してくれない、という前提にたつと、プログラマになりたい人はどうすればいいのか。OJTという言葉が今でも流行っているらしいが、意味は「職場で仕事しながら自己研鑽してください。でもそんな暇あったら上司の命令を聞いて手を動かしてね」ということなので、職場で違うことするのは無理である。

プログラマがどうやって自分を鍛えるのかというと、やはり会社以外の場所で修行をするしかない。Javaの仕事につきたければ、Javaのプログラムを自分で書いて修行するしかないのである。転職する時、次の派遣先に行く時に、自分のスキルシートにどう書いてあれば相手の企業に受け入れてもらえるか、を逆算して修行に励むのだ。

修行の基本は時間の確保である。時間がないと何もできないので、どうやって時間を確保するかをまず考えないといけない。そう考えると残業でずっと張り付きという状況はなによりもまずいのである。時間さえ確保してしまえば、修行自体はどういうやり方でも構わない。自分で全部やるもよし、他人を巻き込むもよし、オープンソースコミュニティに参加するもよし、別の仕事を自分で受けるもよしである。

修行の目的は、ソフトウェアを完成させること、ではない。あくまでもそれは副次的な要素である。一番重要なのは、新しいことに挑戦して、できるだけ多くの失敗をすることである。新しいことをやって失敗せずにソフトウェアが完成したとしたら、何も新しい発見がないということである。発見は失敗からしか生まれない。失敗するというのは、思ったことをやってみたらうまくいかなかったということだ。これを繰り返すことで、その技術についての限界や特徴が掴めるのである。

会社が教えてくれないから、いつまでたってもスキルがあがらないと嘆いていても始まらない。自分で修行した分だけ将来的に返ってくると考えて、修行に励むのがこれからのプログラマとしての生き方のように思う。人材不足→時間不足→負担増→人が辞める→人材不足・・の悪循環は、企業が解消するしかないのだが・・。

顧客との信頼関係を得るには顧客の不安を解消しなければならない

ソフトウェア開発プロジェクトが失敗した、お金を払わずに裁判になった、という悲しい話をたまに耳にするが、その際に決まって言われるのは「顧客との信頼関係が損なわれていなかったら、裁判にはならなかっただろう」というような内容である。

受託のソフトウェア開発プロジェクトにおいて、どうやったら信頼関係が損なわれないか、ということが問題である。顧客も開発側も、わざわざ信頼関係が損なわれるようなことはしないだろう。

わざとやったのではなくて、なんとなく不信感が募り、いつのまにか敵対関係になり、最終的に喧嘩別れして、かかった分の作業コストを払え払わないという話になるのである。

プログラマは、とかく技術的な側面に目が行きがちだが、技術的に難しいかどうかは、顧客側から見るとあんまり関係ない。逆にプログラマから見るとどうでもいいことにこだわったりする。

顧客側には、業務的にその機能は必須だとか、以前作ってもらったシステムではその機能がなくて大変な騒ぎになったとかいう理由で、まずその機能が実装されるのかどうかで頭がいっぱいになってしまう人もいる。

その時に、まず全体を決めてからその後でその機能について議論しましょうと言っても、全体よりその機能の方がその人にとっては大事なので、全体の議論をしていても上の空で集中力が散漫になっているかもしれない。

開発方法論に沿ってないことはできないとか、後で不要になるかもしれないからまず全体を決めないからでないと判断できない、という理由は当然のようにあるが、不要になれば捨てればいいだけの話で、まずは顧客の気になっている部分についてちゃんと議論して、顧客側の不安感を解消しなければ、実質次へ進めないのである。

開発側から見ると、全体から細部を構築して、理路整然とした感じで、顧客と仕様を詰めたいという希望があると思うが、顧客の誰もが似たような脳みその構造を持っているわけではないので、ほとんどの場合、開発側の土俵でいっしょに話をするのは難しいのである。

開発側が顧客は何にもわかってないと思うのであれば、顧客側も開発屋は何もわかってないと思っていることだろう。早い話が、顧客に合わせて話をしないと意味がなくて、顧客がわからないことにOKを求めても、後でもめるだけなので、顧客がわかる評価基準を決める必要があるのである。

ソフトウェアが作れるからソフトウェア開発の仕事をするのでなくて、顧客が満足できるような仕事が出来るからこそソフトウェア開発の仕事をする、というスタイルで望めば、たぶんもめることはないだろうし、納期が遅れてもただで働けとは言われないだろうと思いますよ。たぶん。

プログラミングとおいしい料理

経験則になるが、機械でもソフトウェアでも、「短時間で作り上げたものは壊れにくく、長時間かけて作ったものはすぐ壊れる」という感覚がある。長時間かけて作るというのは、作る過程で試行錯誤が入っているため、無駄が増え、複雑になるため、ちょっとしたことで動かなくなるというような意味である。

料理も、いつまでも材料をいじくっているとおいしくならない。じっくり煮込む必要があるものもあるが、プログラムは放置しておいても何も変わらないのでここでは触れない。段取りと手際のよさがおいしい料理の秘訣である。

プログラミングも料理も試行錯誤しながら作っているうちは、いいものになりそうにない。当然新しいものに対しては、試行錯誤が必要であるが、それはそれで別に作るとして、実際のソフトウェアを作る際には、悩んでいてはいけない。

実際に納品するべきプログラムというのは、悩まずに作り上げると言うのが理想である。といっても規模の問題があるので、まずは部品レベルをそれぞれ悩まずに仕上げる。料理で言うところの下ごしらえである。そして、下ごしらえしたものを悩まずに手早く組み合わせることで、ソフトウェアを完成させる。

その後、実際に動かしてみたり、仕様変更があった場合には、完成したものを修正するのではなくて、下ごしらえからやりなおしである。ソフトウェアは一期一会、仕様が変われば別のものだ。味付けが違うという場合に、上からソースをかければいいというものではない。

幸い、一度作った部品は、もう一度使いまわすことが可能だ。下ごしらえ部品で足りない部分だけを作って、もう一度組み合わせ作業をするのである。下ごしらえにも階層ができるかもしれないが、それはそれでよい。

ただ、下ごしらえ部品の延長にソフトウェアがあるのではなくて、下ごしらえしたものは、それぞれが依存関係のないばらばらの状態で、最終的なソフトウェアにする時にそれらを一瞬で組み上げれば、たぶん品質の高いソフトウェアができるんだと思う。

つまり、ソフトウェア開発プロジェクトのスケジュールに、下ごしらえ部品作成フェーズと、組み合わせフェーズを用意して、まずは下ごしらえをすべきだということだ。仮組みは何回やってもいいが、正式なソフトウェアとして組む時は、日取りを決めて１日で仕上がるぐらいの粒度になっていればいいと思う。

ソフトウェアはブラックボックスだとよく言われるが、ここまでやれば、何を組み合わせたかがその日のうちに全部わかるわけで、チーム全員が状況を把握できるのではないだろうか。ドキュメントもレシピと呼ぶ事にしよう（嘘

昔流行ったプログラム部品を蓄積しようという考え方に似ているような気もするけど、次で使うために作るのではなくて、今回のプロジェクトに必要な部品を下ごしらえするという点がだいぶ違うのではないだろうか。

仕様変更は開発プロジェクトを困難にする最大の要因

昨今のソフトウェア開発業界は、「仕様変更に強いシステムを作る」、「いかにして仕様変更に応じられるようにするか」というような考え方が主流だが、本当にそれでいいのだろうか。

仕様変更に耐えられるシステムというのは、ある意味予測と臨機応変な対応が求められるわけだが、誰もが素早く頭を切り替えられるわけではない。コンピュータに対するいろいろな技術も求められるのに、そこに臨機応変な対応が出来る人となると、極端に少なくなってしまう。

人が足りない、技術者が足りない、プロジェクトマネージャーが足りないというような状況を生み出しているのは、何かプロセスが間違っているのではないか。IT業界は成熟産業ではないというが、大人数で動いているプロジェクトに対して、途中で勝手にゴールを変えてしまうような業界は他にあるのか。

なぜ仕様変更をするのかと考えた時に、技術的に無理なこと、時間的に無理なことを出来ますと言ってしまってあとで仕様を削る、ということがあるために、顧客の無茶な別の要求を飲まざるを得ないケースというのが往々にしてある。見積対象の機能を削除するのだから、別の機能を入れる、いわゆるバーター（交換）取引である。

他には、紙やHTMLで見た時には、なんとなくいいかなと思っていたけど、実際に触ってみると全然駄目ということに気付いたので、画面インターフェースをがっさり作り直しというケースである。クライアント系、WEB系のアプリケーションだと実際によくある。

また、同業他社を意識する顧客の場合は、同業他社が始めたサービスと似たような機能を入れてくれ、と開発途中にねじ込んでくるケースもある。

どのケースも、納期と金額を変えずに、機能だけどうにか追加してくれというのが前提なわけだが、それはお互いの経営陣がリスクを負わずに、開発チームにだけ負担を強いているように思う。予測できないのは開発チームだけが悪いのではなくて、双方の会社全体で対応すべきであるのではないだろうか。

最初のケースでは、削除した分を他の機能で代替するのではなくて、金額の削減も視野に入れるべきである。もっともこのケースについては開発側で対応可能な部分なので、出来るだけ早いうちに未知の機能に対するリスクを潰しておかなければならない。

２番目のケースはGUIを持つアプリケーション開発におけるリスクの１つと初めから認識した上で、重点的に操作感についての対応を取る必要がある。最後の最後で違うと言われないようにしなければならない。

最後のケースは、明らかに横槍である。その機能を入れないと商売にならないと言われても、中途半端なタイミングでの機能追加はプロジェクト全体の破綻に繋がる。プロジェクトを一旦中止して、それまでの作業分の違約金を払って、新たにプロジェクトを組み直すのが理想であるが、契約書にはたぶんそんなことは書いてないので、だらだら今のプロジェクトが続くのが現状である。

商売はタイミングが重要であり、タイミングを外すと利益が出なくなるのは、ビジネスの世界では良くある話だが、だからといってソフトウェア開発について、同業他社の動きに合わせて、仕様を途中で変えたり、納期を繰り上げたりするのは、顧客側のリスクを開発側に転化していることに他ならない。

開発側も出来ることと出来ないことを見定めた上で、無理なものは無理と言わないと、開発チームがえらい人の手の平で右往左往するばかりである。

そういう事態に対して金で解決するために、本来は契約書があるはずなんだけれども、想定外の事態に対しては、「本契約に定めない事項および疑義の生じた事項については、甲・乙双方が誠意をもって協議の上決定するものとする。」としか書いてないのだ。

予測できる仕様変更の可能性については、ある程度契約書に記載できるのではないかなと思うので、理不尽な要求については事前に防衛策を講じて契約書に記載しておくのがいいと思う。もちろん開発側の責務はきちんと果たした上での話だが。

顧客は、自分の言った事がそのままソフトウェアとなって動いているのを見ると、夢が膨らむのである。いろいろ言いたくなるのだ。双方がプロとして自分の責任を果たすようにしようと思えば、最初に契約書レベルで取り決めする以外になさそうである。ビジネスの世界は性善説だけでは成り立たない。

「設計が甘かった」という言い訳は本質を表現していない

ソフトウェアはどれだけお金と時間をかけても、やっぱりバグが残る。止まると人が死ぬぐらい大事なシステムでも、バグが出る時は出る。

バグが出た時の言い訳が、「設計が甘かった」とか「テストが足りなかった」というのはお約束で、「今後は体制を見直す」というのも反省時のお約束である。

まじめな話、それ以上何も言えないのである。「人員を刷新して～」とかどこから集めてくるのかわからないような言い訳もあるが、とりあえず止まったものはしょうがないので、早急に修正するというのが基本的な対応となる。

ソフトウェアというものは、基本的に間違いがなければ動きつづけるのである。なので止まったらどこか間違っていたのである。やっかいなのは、エラーの原因が納得できるようなものはほとんどなく、解ってしまえば簡単に修正できるという類のものばかりであるということだ。

なんでそんな簡単なことをちゃんとテストしなかったのか、とその部分に注目すると誰もが思う。顧客の目から見てもミスだとわかるようなバグもよくある。なので、一方的に開発側が攻められることになる。

しかし、事の本質はそう単純ではない。なぜそんな簡単なことも見つからないのかということだ。決してケアレスミスで済ませてはいけない。トラブルが発生するまで見つからないのだから、同じ方法論では同じ失敗を繰り返すだけである。

例えばコンシューマ向けのゲームソフトは、徹底的に大人数で長時間叩いてバグを全部潰すという、もぐら叩き的なデバッグを行っているらしい。それでも、一度出荷されると一切拡張しないので、その方法でもいいのかもしれない。

それに引き換え業務システムは、納品後も、やれ追加開発だ、仕様変更だ、スケールアップだと、当初の想定をはるかに越えた拡張を行うことが多い。そういう意味で生き物みたいに成長していく。餌はプログラマの知恵なのだろうか。

生き物だとすると、たまに休止とかありそうなものなのだが、ソフトウェアはそれを許さない。結局のところ、先にプログラマの方が力尽きてしまう。どんな人にも限界があるので、どれほど工夫しても一定以上の規模は把握できないのだ。

で、サブシステムを他の人に任せて、どんどん関わる人数を増やしていって、誰か１人でもミスをすると、システムが止まってしまうということになる。

結局のところ、システムの規模をどうコントロールするか、という問題に帰結するのかもしれない。

チェックできない規模のシステムを納品して、バグが出てから「設計が甘かった」という言い訳を言うのはやめにしたい・・と心に刻みつつ、今日もバグを修正しているのであった。

矢を放った後に的を動かしてど真ん中にあてるスキル

どれほど技術力があるプログラマでも、目的がはっきりしないものは作れない。どれほど変更に強いプログラムを作ろうと思ったところで、顧客が思いがけないことを突然言うかもしれない。

顧客に全く干渉せずに言われたものをきっちり仕上げればいいのである、という考え方には賛成できないし、疲れるだけだろう。そうではなくて、顧客といい関係を築きつつ、できるだけ、楽に、早く、安く作れる方法を提案して、最終的な成果物をシステム側にある程度よせていくことが大事なのだと思う。

動いている的の真ん中にどうやって矢をあてるのか、というのはスポーツの世界の話であり、ビジネスの世界の話では無い。技術を競っているわけではなく、利益を継続して出していく必要があるのである。

顧客は、的のど真ん中に矢を当てる方法が知りたいのではなくて、矢が真ん中に当たった的がほしいのである。それを勘違いして、「的は動かしてはいけない」とか「的から遠く離れたところから矢を打たないといけない」、と勝手に思っているから苦労するのである。

オンサイト顧客がやりたくても顧客が自分の会社に常駐してくれないのであれば、自分のチームが相手の会社に常駐すればいいのである。派遣は毎月支払いがあるからリスクがなくて受託開発は終わるまでお金がもらえないからリスクが高いというのであれば、毎月リリースして毎月支払ってもらえばいいのである。

行動を制限しているものは、ほとんど今までの習慣でしかないのである。公務員でもあるまいし、今までの習慣を打破することでより楽しく儲かる仕事ができるのであれば、新しいことを試みるべきだろう。

プログラマだからお金に関することはタッチしたくないとか、経営に口出しするつもりはないとか、そういうことを言っていると、いつまでたっても不幸なままである。ソフトウェアはプログラマが作るのであり、プログラマが的を動かせないような環境で、いいソフトウェアが出来るとは到底思えないのである。

もう少し広い視点を持てとか、そういうレベルの話ではない。ソフトウェアはビジネスと密接に繋がっていて、ビジネスを知るものがソフトウェアを制するのである。ビジネスに関する知識はプログラマにとって必須である。

どんな矢でも当ててみせるという自信のある人は、技術というよりも、人との対話で納得させてみせるということが根拠になっていることが多い。ただ技術だけしかない人には、最終的にどうしたいのかがわからない間は自信もくそもないだろう。

しかし、顧客が信頼するのは前者のタイプであることが多い。最初に契約だけして、後で適当に決めたことについてプログラマが泣くのがいつものパターンだが、信頼感で契約して技術力を生かして的のど真ん中に当てることが出来れば・・と考えると、いつまでも泣いてはいられないだろう。

要は矢を放った後（契約した後）に、的を動かすというのは仕様をある程度コントロールするスキルということだ。コントロールというと顧客を騙してみたいな意味にとられるかもしれないが、騙さずにプロジェクトが失敗するぐらいなら、騙してでも成功させろ、と思う。

まぁ上記は極端だが、せっかくプロジェクトに関わるのであればいろんな手を尽くしてプロジェクトを成功に導くべきであり、それはプログラマがプログラムをあの手この手で作るだけでは難しい。

デスマーチになってから唸るよりは、ならないように的を動かしてみよう。最初の的と違うところにあるからといって、そんなにかっこ悪いことではないし、顧客も的の場所はそれほど重要だと思ってないことも結構あるのだ。

でも、的を勝手に動かしたら、顧客は不満に思うかもしれない。そこはやはりコミュニケーションが大事ということで。

プログラマにも何を知っているかではなく誰を知っているかが求められる

プログラマは、コンピュータとだけ付き合っていればよいわけではなくて、会社の中の仲間とだけ付き合っていればよいわけでもなくて、やはり社外の人達とどのようにして繋がっていくかが求められるのでは無いだろうか。

プログラマという職種は、一歩間違うと、会社で長時間働いて、脳みそが疲れに疲れて、家に帰っては寝るだけ、という状態に陥りかねない。会社にいいように使われているのに気づかないのだ。

プログラマにとって、技術も当然重要だが、人的ネットワークの形成も同じくらい重要である。１つの会社しか知らないと、他の会社に転職するのもままならないわけだが、人的ネットワークがあると、そのネットワーク内にいる人が別の会社を紹介してくれることだってあるかもしれない。

わざわざ人材派遣会社に登録して仕事を探してもらうのは、その会社が持っている人的ネットワークに対して利用料を払っているようなものである。中途半端な人材派遣会社に登録してつまらない仕事をするくらいなら、自分のネットワークを使って、仕事を探したほうが何倍か安全であろう。

結局のところ、仕事を探すのも、会社を探すのも、誰かの人的ネットワークに頼るのである。人的ネットワークが大きくなれば独立しても仕事や人材が集まるのでやっていける。人的ネットワークもないのに、技術があるから独立できるかといったら、失敗するのが落ちである。

営業が下手とか営業が上手いとかそういうレベルでは無い。ネットワークビジネスとも違う。人生において、友達の輪を増やしていきましょうという話である。

タイトルの「何を知っているかではなく誰を知っているか」とは、英語のことわざらしいが、困った時に頼れるのは技術ではなくて人だということを心にとめておいた方がいいかもしれない。自分１人で出来ることには限りがある。

プログラマがもっといろんな人と知り合いになったら、世の中のコンピュータに対する考え方も、教育そのものも、プログラマ自身の幸せ度合いも変わるかもしれない。それだけでも社会貢献なんじゃないかなと思うわけだが。

過去の自分と比べて、今の自分は成長していると感じられるか？

ソフトウェア開発業界は、日々進歩している。言葉だけが先行したり、表面上形が変わったが中身は同じ、という技術もあるが、少なくとも一部の技術は確実に根付くし、皆が知識を得ることで求められる技術そのものが高度になっていく。

世の中の進歩について行けなくなった時、技術者としての使命を終えてしまうのである。ついて行けるかどうかの指標として、過去の自分と比べて今の自分が成長したかどうかで判断できるのではないだろうか。

半年前、1年前では出来なかったことが出来るようになっている。また、以前は知らなかったことを知っている、すでに使っている知識を身に付けることができただろうか？

過去に失敗していたら、きっと今は成長しているだろう。失敗は成長の糧である。１年間失敗せずに無難に過ごしていたら、今はもしかすると全く成長していないかもしれない。

３Ｘ歳定年説とよく言われるが、１つに３０過ぎるとだいたい既存の技術について失敗しなくなるため、無難に過ごしてしまい、成長しないために気づくと最新の技術についていけなくなる、というのがあるような気がする。

コツを掴んで、似たようなプロジェクトばかり請け負っていると、失敗しなくなり、失敗しないから皆その人に頼むようになり、だんだん技術的に先細りになっても、仕事のあるうちはそればっかり請け負って・・という悪循環で技術的についていけなくなってしまうのかもしれない。

そうはいっても、年齢を重ねるとおいそれとプロジェクトを失敗させるわけにもいかない。責任あるポジションになると、リスク回避能力が身につくせいで、既存のこなれた技術ばかり適用してしまいがちである。

ポストイットでお馴染みの3Mには、執務時間の15％を自分の好きな研究に使ってもよいとする「15%ルール」という不文律があるらしいが、ある程度以上経験を積んだ人は、それなりの時間と予算を確保して、自前プロジェクトを組んででも、新しい技術に挑戦し、失敗を重ねる必要がある。

去年と今を比べて、新しいことを何にもやっていないとすると、そろそろプログラマとしては駄目かな、と危機意識をもたないといけない。一生プログラマであり続けたいなら、工夫しながら新しいことに挑戦していく気構えがいるだろう。

ソフトウェア開発プロジェクトを戦時と見るか平時と見るか

---
平時：平常のとき。ふだん
戦時：戦争の行われている時期。戦争中。平時←→戦時
（広辞苑　第四版より）
---

プログラマは、ソフトウェア開発プロジェクトが終われば、また別のソフトウェア開発プロジェクトに移る。年中何かのプロジェクトに関わっているので、ある意味いつでも同じような状態といえる。

ただ、顧客側から見ると、ソフトウェア開発プロジェクトというのは、ルーチンワークではない、通常とは異なる仕事である。決められたマニュアルに則って作業するわけではなく、新しいことを考えなければならない。少なくとも平時とは言えないだろう。

プロジェクトが始まった際に、顧客側がアサインする担当者が、平時という意識でいるのか、戦時という意識でいるのかで状況が大きく異なる。平時という意識でいる場合、あくまでもプロジェクトは開発側にお任せ的な扱いになってしまう。戦時という意識であれば、プロジェクトを成功するために必要な行動を取るだろう。

開発側が最初にしないといけないのは、顧客との意識をあわせることである。開発側はある意味日常なので平時と言えなくもないが、顧客側にとって戦時であると意識つけることが大事である。

また、顧客があまり知識がない場合、開発側の何気ない発言にも敏感になる。「これはお客様に作業して頂かなくてはいけません」とか、「お客様にどちらか決めて頂かないとこちらは動けません」とか、顧客に負担を強いるのを前提とした発言は要注意だ。

そもそも、受託開発の場合は、顧客あっての仕事なので、顧客のソフトウェアに対する考え方や知識に応じて開発側の作業量も変わるため、見積もりも納期も異なるのが常である。これを画一的に画面数でとか、サービス単位で、とやってしまうから後でトラブルが発生するのではないだろうか。

顧客との間に信頼を築きあげるのに、言われた事をしっかりやる、というだけでは足りなくて、顧客の担当者をはじめ、関わるいろいろな人が、どのような立場でどのようにソフトウェア開発プロジェクトを意識しているか、ということをいつも考えていると、少々のトラブルは吸収できるだろう。

人があってのソフトウェア、人があってのソフトウェア開発プロジェクトということだ。技術面も心理面も両方意識していれば、それほど失敗はしないだろう。逆にどちらかが欠落していると、どこかでトラブルが発生するだろう。

と考えると、ソフトウェア開発プロジェクトって考える事が多いよね、みんなよくやってるなぁ、と思ってしまうのであった。