事業の5年目にあたる前期は、皆様のご支援により独立以来最高の売上を記録することができました。 その分、今期の市県民税や各種保険料が跳ね上がり、今月は通帳からゴソッと大金が消えてやや気分が落ち込んだりもしておりますが、これは「嬉しい悲鳴」の範疇でしょうか。 それだけに今年以降もこの業績を伸ばしていく手段を考えていかなければ、ジリ貧に陥り、当面の目標である法人化も遠のいてしまうため、現状に満足してしまうことなく一層精進していく所存です。

ところで、事業を「法人化」するということは「雇用」を行うということでもあり、それは即ち「給与」の支払いという義務を負うこと。 給与を含め、人件費は事業にかかる費用の中でも特に大きな割合を占めるもののひとつであり、世の経営者たちはこれを削減する方法の模索に余念がありません。 そのための道具を作り・売ることで成り立っているIT業界に身を置く私自身、あちらこちらのオフィスで日々営まれている各種の業務を効率化 (あるいは自動化) する方法はないものかということに常に頭をめぐらせているわけですが、そんな立ち位置から眺めていると、自動化・合理化による削減以前のレベルで、本質的にまったく不要な人件費を垂れ流しているプロジェクトを頻繁に目にすることに。

前期より業務内容に「開発コンサルティング」を加えたこともあるので、今回のエントリではそうしたプロジェクトにおける無駄について、思うところを述べてみたいと思います。

以前に受けたある案件にて、システムの機能改修を依頼されたことがありました。 しかし、システムの現行の設計・実装から考えるに、依頼された修正内容は使い勝手を良くするどころか、かえって使いづらくなるようにしか思われません。 そこで、差し出がましいかとは思いつつも、修正指示を出したマネージャに「本当にこれで良いのですか?」と確認してみました。

マネージャ曰く、「顧客からこの機能が使いづらいと言われたので、とりあえずこちらで考えて修正を行い、それを見てもらうことにした」とのこと。 「先方には具体的にどの部分に不満があるのかは確認したのですか?」とも訊ねてみたのですが、「それは今やるべきことではない」という答が返ってきました。 つまるところ彼女は、

1. 発注者の意向を伺うことなく憶測で計画を立て、
2. その計画の内容についての確認も取らずに製造を開始

しようとしていたわけです。

多少とも社会人経験のある方にとって、これが相当に駄目な仕事の進め方の部類に入ることは論を待たないのではないでしょうか。 しかしながら、ソフトウェアシステムの開発現場においては

• とにかく手を動かすこと
• とにかく長時間オフィスにいること

といった、ひたすらに間断なく作業を続けることに対して、その効率や成果を問うことなく高い評価を与るというマネジメントが出現することがしばしば。 この傾向は納期や予算が不足しがちな現場において顕著であり、そうした非効率的なマネジメントはさらなる状況の泥沼化へと続いているのがお定まりのパターンです。

欧米の歴史的生活背景にある狩猟･採集文化では、どんな場合でも目標がはっきりしていなくては獲物を手にできません。 どこに、どのような目標を選ぶかで、成果はゼロにもなるし、予想を上回ることもあります。 また、目標に向かって最善のルートで近づくことが要求されるので、目標に到達するための手段や方法の理論が欠かせません。

そのため欧米の人たちは、どんな場合でも目標がはっきりしていないと気がすまないようです。

これに対して私たち日本人は、農耕文化の影響を強く受けて育ってきました。 農耕の場合は、単位面積当たりに投入する労力と収穫の間にほぼ比例関係が成立するので、目的や目標をそれほど意識する必要がありません。 私たち日本人が「とりあえず、できることから始めよう」ということになりやすいのはそのためではないかと思われます。

ところがこういった物事の考え方や進め方は、重要なことを成し遂げようとする場合には順序が逆です。 目的がはっきりしなければ、優れた計画を作ることはできません。

『「計画力」を強くする - あなたの計画はなぜ挫折するか』 / 加藤 昭吉

この件についても、マネージャの「とにかくやってください」という指示により修正作業が強行されたのですが、案の定、顧客の反応は「コレジャナイ」。 スタート時点において「何をするべきか」の確認を怠ったがために一度目の修正作業に掛かった費用は虚空 (=私の懐) に消え、会社としては必要に対して倍の支払い、つまりは無駄遣いをしなければならなくなったわけです。

このような事態は、それを受け取る立場ある私からしても、あまり愉快なことではありません。 労働に対する正当な対価として、それを受け取るに何ら疚しいことはないにしても、自分が手間を掛けて作ったプログラムが人の役に立つことなく消えていくというのは陰鬱な気分になるもの。 貴重なお金を使い、人間の労力を費やす仕事というものは、それはやはり誰かの・何かの役に立つものであるべきでしょう。 「そもそもこの作業はやる価値のあるものなのだろうか?」をいう疑問を抱き続けることは、決して「仕事に対して消極的である」ことを意味するものではないのです。

若干古い話になりますが、とある自治体が「発足xx年事業」と銘打って大掛かりなプロモーションを行い、その一環として特設ウェブサイトが制作されたことがありました。 このプロジェクトの発注先は複数の業者によるコンペティションで決定されることになったのものの、そこで提示された要件には主催者である自治体の主体性がまったく見られず、

• テーマと見せ方
• ページ更新等の運用方法

といった、事業の根幹に関わる要件までもを「提案事項」としてコンペティションの参加者にゆだねるという丸投げぶり。 その結果、応募企業からは、それぞれに目標設定が異なる企画書が提出されることに:

• A社「地域独自の伝統芸能・工芸を活かした産業振興を目指します。」
• B社「豊かな自然環境と美しい景観を活かした観光客誘致を目指します。」
• C社「充実した子育て支援と高齢者福祉をアピールしての移住者増加を目指します。」

それぞれの企画の目指すところがバラバラで、 結局、何が決め手となったのかよく分からないままにA社の受注が決定されてしまいました。

「伝統芸能・工芸を活かした産業振興」という方針はこの時点において前触れなく決定されたものであるため、当然のことながら、地元の伝統芸能・工芸を手掛ける団体や企業との連携については、まったく何の段取りも付けられてはいません。 取材・資料提供の申し込みやそのスケジュールの調整、報酬の支払いに関する交渉などもなされていない状態での制作・運用は難航。 既刊の書籍やパンフレットの内容を引き写したような独自性・目新しさの欠片もないウェブサイトが公開され、更新も殆ど行われないままにプロモーション期間が終了し、誰の記憶にも残らないまま閉鎖を迎える、という結果となりました。

プロジェクトを開始するに当たっては、複数の計画、代替案 (オルタナティヴ) を検討することが必須である、というのはよく言われることですが、そもそも、目的が不明確な状況下では、幾通りの計画を用意したところで、その中から最適なものを選ぶことはできません。 何故なら、それらの優劣を評価・比較するための尺度が存在しないから。 計画の出来が「良い」とか「悪い」と言うときには必ず、「何を達成するために」という括弧書きが前提として付与されければならず、それなしで下された評価に対しては強い猜疑が投げかけられるべきです。

プロジェクトの主体となる人物あるいは団体に、責任を持って目標を設定しこれを遂行しようという意識が見られないというケースも散見されるところです。

前述のマネージャの例では、顧客の要求 (要件) を確認する立場にありながらこれを怠り、自分の勝手な想像でそれを代替しようとしたことに問題がありました。 類例として、上流工程に従事する者が、その職務である「要件定義」を遂行せず、下流工程 (一般に部下や業者がこれに相当する) に押し付けるという構図があります。 そうした光景は日常的に観察される事態ではありますが、歪んだ業務形態であることは間違いありません。

要件定義とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などのを明確にしていく作業のこと。 いわゆる上流工程の一部で、実際の開発・実装作業を始める前に行う作業の一つである。

要件定義では、利用者がそのシステムなどで何がしたいのかを元に、それを実現するために実装しなければならない機能や、達成しなければならない性能などを開発者が検討して明確にしていく。 まとめられた成果は「要件定義書」として文書化されることが多い。一般的にこの段階では「何が」必要なのかを定義するに留め、それを「どのように」設計・実装すべきかは後の工程で検討される。

要件定義とは - IT用語辞典

上流・下流工程が分離されている開発現場においては、下流肯定 (プログラムの設計・実装) の担当者は、システムの利用者である顧客と直接コンタクトを取る権限を与えられていない場合が殆ど。 従って、要件定義は顧客と直接交渉を行う立場にある上流工程の担当者が負うべき作業となるわけですが、怠惰な者はこれを口頭やわずか数行のメールといった簡素な指示で伝え、要件定義を含む設計を下流工程の担当者にやらせてしまいます。

プロジェクト全体を見れば、顧客との折衝を行わない下流担当者に要件定義を行わせるのは大変に非効率なやり方に見えますが、上流担当者からすれば、自分の頭と手を使って下流の作業に必要にして十分な要件定義書を書き上げるよりも、他人が作った計画書を見て「これで良い」「これは駄目」ジャッジする役に回り、その繰り返しで満足のいく出来になったものを顧客に提出するというプロセスの方が楽ができるという寸法。 これはつまるところ、本来開発チーム側にいるはずの人間が

という「お客様」的ポジションに座り込み、職務を放棄している状態です。 こうした態度を取る上流担当者というのは、

• 顧客の要望が開発内容に正しく伝わり・反映されることを妨げる
• 曖昧な指示で設計作業を命じ、作業効率と品質を下げる
• 工期を無為に延ばし、人月費用を増大させる

という、まさに「居るだけ邪魔」な存在。 プロジェクトを管理する立場からは、こうした不適切な人員配置を如何に避けるかということが開発コスト節減の要点となるでしょう。

この手の問題は開発チームだけでなく、顧客側に存在することもあります。 前節の自治体の例では、目的・指針を考案し練り上げるという事業の土台を築く作業の主体性をコンペティションという形で受注業者側に放り出してしまったことに最大の敗因がありました。

一般的に、システムを発注する顧客はITのプロフェッショナルではありません。 そのため、彼らが自分たちの「やりたいこと」を明確な要求事項として書き出すことができない、という状況は往々にしてあるもの。 開発を請け負う業者は、そうした要求・要件の洗い出し作業への協力を惜しむべきではありませんが、一方で要求・要件が不明確なままで設計・開発作業を請け負ってしまうことは厳に慎むべきです。 「やるべきこと」が決まっていない段階で根拠に欠ける工数見積を出して受注することは、顧客に対しても、また、自らが所属する企業に対しても、不誠実で無責任な行為。 実際には出来もしないことを出来るといって受けたがために、発注側あるいは受注側の企業の経営が傾くほどの損害を出してしまった、という例は枚挙に暇がありません。

私はソフトウェア開発以外の仕事に実務と呼べるレベルで従事した経験がないため、他の業界においても同じことが言えるとは断言できませんが、経験的に、プロジェクト運営には以下のようなトリレンマが存在すると考えています。

プロジェクト運営の健全さを保ったまま、

• 金銭 (人件費・外注費)
• 時間 (工期・納期)
• 思考 (調査・評価等、意思決定にかかるコスト)

のうち2つ以上の項目を削減することはできない。

厳密な定義や証明があるわけではありませんが、例えば

• 予算という「金銭」だけを投じ、その使途を吟味・精査する「思考」を省けば、詐欺的な企画屋の餌食となる
• 実作業のための「時間」を省けば、既製品を仕入れて収めるだけの、開発プロジェクトとは呼べない事業となる

といった具合。 もちろん、三方をそれぞれ少しだけ削る、といったような手法も有効なことはあるでしょうが、それは単なるジリ貧に陥るだけの戦略、という場合が多いようです。

この原則に従って本エントリの主題を捉えな直すならば、

という事実、そして、

という指針に行き着くでしょう。

開発コンサルタントとして目覚しい実績があるわけではありませんが、年齢に比してやや多めの場数を踏んできてはおりますので、興味のある方はぜひお声掛けください。