[Programs] / 最終更新時間:2004年07月13日 23時18分46秒

概要

ソフトウェア開発はビジネス上の理由により、いつも厳しい状況にあります。しかし、ビジネス上の厳しい要求は、遅れや仕様の削減、品質の低下、販売の低下といった事態を招き、それがさらなる厳しい要求を招くという悪循環を起こしています。

現状に無駄や問題を感じる人は「もっといい方法があるはずだ」と考えています。

厳しい現実の中、会社、従業員、顧客、クライアント……皆が幸せになる方法は存在するのでしょうか?

参考文献をまとめた内容と、個人的な経験をもとにその方法を探してみましょう。

目次

問題

問題はたくさん思いつきます。

  • 期間、資金などきびしい条件でよいものをつくらなければならない
  • 突発的な変更要求がある
  • 変更に時間がかかる
  • スケジュールが遅れる
  • 仕様がはっきりしない
  • プログラムのデバッグに加えて仕様のデバッグが必要になる
  • 無理のあるスケジュールと分かっていても突き進む
  • 提出前にドタバタがある
  • どこまでやればOKという明確な基準や製品の形が誰にも分からない
  • 厳しい状況になるほど会議、掛け持ち作業など効率の悪いものが増えていく
  • 自分の仕事に誇りをもてない
  • 期待だけは大きい
  • 出来上がる製品がぱっとしない
  • ……etc.

解決方法はないのか?

人は多くのことに注意を向けるのは苦手です。解決のために膨大な作業をするのも困難です。しかし、ある問題は別の問題が原因で起こっていることがよくあります。ということは、なにか問題を解決するなら、たくさんの問題の原因になっているコアの問題を解決するのが一番効果的だといえます。

風呂から水があふれているとき、風呂場への入り口を密封したり、あふれる前に洗濯機で水を再利用するのは、たしかに問題を一時的に解決しているかもしれませんが、蛇口を閉めるのが一番簡単です。

会社の目的

問題の解決方法を考える前に、なんのために解決するのかを考えてみましょう。会社の目的は何でしょうか。

・利益(金)

ほかにも社会貢献とか、夢をもたらすとかありますが、基本として「利益がなければ会社は死んでしまう」ものです。しかし、利益を手に入れるにはなにをしてもいいのかというとそうでもないです。

・顧客(ユーザー/クライアント)を満足させる
・従業員を満足させる

どれが欠けても失敗への道に突き進みます。金を稼ぐのが必須条件で、そのうえで客や従業員が満足させるのがベター……なのではなく、どの条件も犯してはいけないことです。なぜでしょうか。

顧客を満足させられなければ、製品は売れず、あるいはクレームが増え、保守の手間がかかり、評判が悪くなり、仕事が減ったり、契約条件が悪くなったりします。忙しく働いているのに利益が出ない状態です。

顧客が満足していて、利益がたくさんあっても、従業員がぼろぼろだったなら、その人はもっと条件のいいところへ去っていきます。残っていてもだんだんゾンビのようになっていき、やる気はなくなり、新たな雇用のコストが増え、ノウハウは損失、生産性は落ちる一方という状態です。

顧客を十分満足させるよい製品を無理なく開発し、従業員が充実した気持ちでいたとしても、費用が利益を上回れば会社は給与を十分に払うことができません。リストラやコストカット、従業員へのプレッシャーの増大といった恐怖の文化が会社を染めていき、リスクのある事業は一切行えなくなり、ただ現状を生きながらえることだけを目指す状態です。

だから、これら3つの目的を侵害するような案はなにかが狂っている、といえます。

コアの問題

以上をふまえて、コアの問題はなんでしょう?

売れるものを作るためのソフトウェア開発には変更がつきもの。しかし変更には時間がかかり、厳しい現実により期間や予算を増やせない。

誰が悪いわけでもない、このジレンマこそがコアの問題だと考えます。

解決手段

問題がひとつでも解決方法はひとつとは限りません。論理的に考えると、解決方法は以下のいずれかの方法になるでしょう。

ムダを減らす
変更を減らせるようにする
変更に時間がかからないようにする
必須のコアを小さくしておき、変更にかけられる時間を多くとる
生産能力を上げる
セールストーク/特別なサービスでよい条件を

このA〜Fに対応するレシピを示します[1]

  • [1]実際には、多かれ少なかれA〜Fすべてに影響する方法論が多いのですが、簡単のためあえてひとつの項目に分類したりもしています。

レシピA

「ムダを減らす」

クリティカルチェーン(TOC)
個々のタスクを細かく分けて、ひとつひとつが確実に終わるようサーフティを組み込んで見積もるのではなく、個々のタスクからプロジェクト全体に対してセーフティを移動することでムダを省く、といった考えがあります。ただ企業の文化を変えなければ、単に仕事がきつくなる結果にしかなりません。
コミュニケーション
仕様の形はこういうのがよいとか、企画としてはこんなやり方だと助かるとか、こんなことがしたいからこの機能がいるんだという真意だとか、お互いが知らない相手のこと知るために話すことで、無駄な作業を避けることができます。
会議を減らす
進捗報告のためなどで存在する、定例の長い会議を減らすなど、手間のかかる手続きを減らすということです。
プライオリティ
なくてもいいものを優先しないこと、すべてに優先度「高」としないことです。
ライブラリを使う
車輪の再発明を避けます。

組織図を変えたりするのはコミュニケーションや手続きに関連しますが、どこを円滑にしようとしているのか、という視点が必要です。

次のレシピに行く前に

どのレシピもそうですが、ほかにも方法はあります。例をあげることで現状のやり方とは違う方法があることを示して、それ考える足がかりにしてもらえれば……なんて思っています。

もちろん、現状のやり方も、会社や個人の歴史の中で「嬉しかった経験」「ひどい目にあった経験」「学んだり感心した事柄」があって、育まれた方法です。レシピの中にはそんな方法に真っ向から対立する、悪しきやり方をすすめるものもあります。

どれがよいのかはプロジェクトやメンバー、クライアントの特性によりますが、やり方にそれほどの違いがあるのに、うまくいくプロジェクトがあるのは不思議だと思いませんか。

問題は、これから未来も含めて、いろんなやり方のなかから「その方法を確固たる理由をもって選択する」のか、「選択を避けて変化しないまま」でいるのか、です。

レシピB

「変更を減らせるようにする」

紙と頭でシミュレーション
ペーパープロトタイピングでもいいし、一人の頭の中でユーザーの立場から出来上がったソフトウェアを使う手順を想像して追っていくことでもできます。ただし、これですべての変更がなくなることはありません。
コミュニケーション
前もって意見を聞いたり検討したり、で「ムダを減らす」の項目と同じです。

レシピC

「変更に時間がかからないようにする」

先を見込んだ実装
最初にある程度の柔軟な設計をするという方法です。最初に時間がかかるのと、ここで予想した以上の変更には対処できず、余計たいへんになることもあります。
XP
エクストリームプログラミングでは、短期間に小さくつくることで時間を節約し、ムダなコードを再設計し、テストを常に施すことで、変更が必要になったときにも――というより日々が変更で――それほど難しい事態にはならないという思想があります。
スクリプト/ツール
プログラムを変更するのに比べて低コストである、簡単なスクリプトデータやツールによるデータ修正で調整や変更できるようにしておく方法です。懲りすぎると逆に高コストになります。
Lisp/Python/Smalltalk/ML/Curl/C#…
言語的に変更に柔軟なものや、ある環境でよくある変更を行いやすいものなどを選択するという方法です。環境を限定するのと、再利用、教育と保守の問題があります。

レシピD

「必須のコアを小さくしておき、変更にかけられる時間を多くとる」

プライオリティ
つまり、コアを優先、ほかをベターとするということですが、営業時に必須部分を小さくする利点を説明/あるいは水増しで説得などの交渉が必要になります。変化のためにコアを小さくするわけです。シンプルな状態で機能するものこそが好まれているというデータをMozilla Firefoxなどを例に説明するとよいかもしれません。
XP
XPをはじめとするアジャイルな開発方法論では、重要な機能から順に実装して提供していきます。もしなにかの機能が間に合わなくても、先に実装したものよりは重要度が低いものになります。

レシピE

「生産能力を上げる」

ゆとり/やる気
頭を働かせるのに必要なことをする。「管理者の仕事は従業員を働く気にさせることだ」という言葉がありますが、特にソフトウェア開発では重要度を増します。詳しくはピープルウェアやゆとりの法則を参照してみてください。成長する余裕をもたせ、その能力アップによっても生産性を上げられるでしょう。
テスト駆動開発
精神的によいことと、バグが減ること、シンプルなコードによって生産性があがります。ただこのやり方が向かない人もいます。
XP
テスト駆動開発はXPのプラクティスのひとつですが、それに加えて、ペアプログラミングでのテクニックの伝達や、客の望むものの提供による質の向上、チームの検束などの効果があります。しかし、完全なXPを適用できるような環境が少ないという問題もあります。
評価
ボーナスによる物理的な励みや、仲間やユーザーからのレスポンスによる精神的な満足感などを得られる仕組みがあるかどうかを確認してみてください。
便利ツール/ライブラリ/言語/テクニック
場合によっては効率的になることがあります。新しいことは何でもそうですが、最初は学習の手間などで逆に効率が落ちるので注意が必要です。

レシピF

「セールストーク/特別なサービスでよい条件を」

TOC(思考プロセス)
TOCには対立する問題を見たとき、妥協することで解決するのではなく、その問題のどれかの仮定が間違っていると考えることで新たな解決策(両者によい方法)を考え出すという思想があります。これによって、契約時にこれまでと違ったサービスを提供することで、予算や期間をより理想的なものへと変えることができます。
実績/信頼
過去の実績や信頼は大きな力になります。
ユーザーの声などのデータ
プロジェクトの途中でも交渉時には客観的なデータが役に立ちます。
営業の練習
どんな職種でも常にぶっつけ本番でなければ力をつけられない、というわけではありません。

まとめ

これまでいろいろな方法を見てきましたが、以下のことを忘れると安易な解決手段に走り、結果、解決への道が遠のくことになります。

「銀の弾丸はない」[2]

  • [2]ブルックスによる「ソフトウェアの生産性をひとりでにもたらすようなプログラミング技法は今後10年間は登場しない」という意味の言葉。

たがいに矛盾するものがあるこれらのレシピ/方針のなかから、効果的だと思うものを順に導入したり、余計なものを取り除いて身軽になること、その選択をする助けになればと思います。

中途半端な導入や下手なカスタマイズは危険ですが、無批判にすべてを導入するのも危険です。そのため、次の項ではより詳細が分かる参考文献をいくつかあげています。

大企業の戦略と中小企業の戦略は違うし、同じことをしても勝てません(逆もしかり)。たとえばGoogleはどんな戦略をとって今の姿になったのでしょう。業界の常識に惑わされず、自分たちにあったやり方を見つけ、実行すること。それを見習いたいものです。

参考文献

  • XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法
  • XPエクストリームプログラミング懐疑編―XPはソフトウェア開発の救世主たりえるのか
  • テスト駆動開発入門
  • ANSI Common Lisp

関連リンク

蛇足

個人的には会社が大きくなろうがなるまいが、それほど興味はないし、プロジェクトマネジメントなんて気持ち悪い。けれど、楽しくいいものを作ることには興味があるし、それが結果的に皆が幸せになることじゃないかと。

楽しく作る。っていうと遊んでばっかりとか、苦労をしないとかそういう意味にとれますが、そうじゃなくて苦労の中にも楽しいことがあるってこと。楽しくという言葉を聞いて、「仕事は遊びじゃない」と思ったなら寂しいです。

「プロとして仕事を苦行のようにこなす」チームと「プロとして仕事を楽しんでこなす」チーム、どちらがよいものを作れるかといえば後者なのは当然です。モチベーションが違います。

もちろんこれは楽しむということの程度の問題、なのかもしれません。しかし、もし今なにかのプロジェクトにかかわっているとしたら、その中で「楽しい」と思ったことがどの程度あったのか考えたほうがいいと思う。そのバランスはどの程度ですか。

楽しめるように、なにができるでしょう。個人が楽しむことでプロジェクトが駄目になるとしたら、それを禁止すればいいのでしょうか。

プロジェクトはどのように個人に満足感を与えることができるでしょう。たとえば、あなたは給与があればどんな仕事でも満足し、辞めずに続けるでしょうか。

人には精神的満足感が必要で、満足感があれば苦労もできるんです。だから楽しく作るっていうのは本当に重要なことだと思います。

ちいさなことから:実例

楽しいプロジェクト運営の実際

いま会社でメインプログラマーとしてゲーム制作をやっているのですが、うちの会社にとっては新しいやり方を実践中です(一部、プログラマーのみの項目もあり)。たとえばこんな感じ。

スケジュール

  • スケジュールは、おおよその作業内容、量は提出予定の内容をもとに、数ヶ月まとめて、前もって話し合っておく。これはあくまで目安。
  • 2週間を1区切り(1イテレーション)として、入れたい要素(2行以内で具体的)を優先度順に並べたチェックリストを用意して、実際の全体スケジュールに。
  • そのチェックリストを印刷して各自がもつ(紙ペラ1、2枚。自分がかかわる項目もあるし、かかわらない項目もある)。
  • 優先度はクライアントの要望、企画、ディレクターの要望、デザイナー、プログラマーの都合などをバランスよく考慮して決める。優先度は必ずつけ、優先度同士で同じ優先度はない(万一遅れが出ても優先度が低いものが外れるだけですむ)。
  • もう一度。クライアントの要望をちゃんと確認する。
  • プログラマーの作業分担などは、各自のやりたいこと、得意分野などをできるだけ聞き(立候補歓迎)、そのうえでイテレーションごとに皆で分担
  • ひとつのイテレーションが終わった後、次のイテレーションの内容を決める。
  • イテレーションでガントチャートは使わない(細かい個々のタスクの正確な期間を予測するのは無理な上、そのとおりに日数を使うのは無駄だし、遅れを別の簡単なタスクを進めることで緩和すると優先度が不明瞭になる)。

実装

  • 将来のためのおおげさなコードでなく、いま現在必要なシンプルなコードにする(できるだけ)。
  • ざっと書いたコードを関数化したり、クラス分けしたり、統合したり、コードの手入れを随時行う方針で行く(だからこそ、最初に思い切ってざっと書ける)。
  • 新機能や要望、見た目の改善などやりたいことがあっても、ほかより優先度が低ければ「やりたい要素リスト」に入れるだけにする
  • なんでもかんでも新たなツールを制作して解決するのではなく、ほかからシンプルにデータをもってこれないか考える(すでにあるエクスポーター、ツール、csv、画像データ、etc.)。
  • デバッグインターフェイス、プロファイラなどはちゃんと用意(テキストベースのシンプルなものでいい)。
  • Subversionでバージョン管理。更新内容は毎回更新コメントに短く。
  • 未実装な部分は未実装らしい見た目にする(見た目がそれっぽいと、もうできているものと思われるし、できたときのインパクトが薄い)。

コミュニケーション

  • 無駄に長い会議をしない(意味のある会議、短時間のミーティングはする)。
  • Web(XOOPS+B-Wiki)で情報を共有。簡易的なデータ仕様や、ノウハウ、ニュース、リンク、遊び、アイデア、バグトラッキングシステムとして。また、チームとして誇りを持てるように。
  • 仕様書などの書類は大量に書く前に読み手に相談する。
  • これまでと違う新しいやり方はできるだけやわらかく導入する。優しいところから様子を見つつ。
  • クライアント、上司、部下、チームメンバーを敵にしない。仲間として信頼関係を築く努力をする(態度、言葉使い、お礼、要望を言ったり聞いたり、成果物、etc.)。
  • よい意見やよい結果がでたら、「いい」とか「素晴らしい」とか「おお」とか素直に言葉に出す。苦労をしていたり、うまくいかなかったら、一緒に悩んだり手伝うし、手伝ってもらう。

全体

  • あまり残業しない。

結果としては予定していた内容より多くのことが入ったROMを予定した時期より一週間早く焼けました。しかも、予定していないトラブルが多い、慣れない環境の中で。なかなか頑張ったと思います。

個人的には、自分のタスクをハイペースでこなしたり、打ち合わせしたり、一緒にデバッグしたり、CEDECやゲームショーに行ってレポート書いたり、結婚祝いの会に出たり、日帰りキャンプに行ったり、残業はそんなにしてないけど(手が離せなくて昼食はたまに抜いてしまったものの)、二倍くらい働いた感が。(え? 後半は違うって? ごもっとも)

実際のところ、見た目はまだパッとしないし、遊びもまだまだぜんぜんで、これを提出した後の反応もどうなるか分かりませんが、今回の提出はこれまでの開発と違って「見た目がパッとしない」のを意識的に選択していたりします(予定よりは良い見た目だけど)。

というのも「今回、重要視するものは何なのか?」をクライアントと打ち合わせ、「ゲームのルールや遊びを試せる」ことを重要視することになったからです。その意味で、この時期にゲームに必要な要素がほとんど入り、「遊び」の部分を検証/改良していけるようになったのは、自分的に嬉しいです。

いままでは見た目優先でスタートするものが多かったので、いったん遊べるゲームができ、これから遊びにかけられる期間を考えるとちょっとわくわくします。ほかにもやることたくさんですが。



後日談

無事チェックも通り、「こんなふうになったんだ」「ここまで出来ていると思わなかった」といった声をいただけました。最初の提出としては好印象だったようです。これからまだまだ仕様の変更/洗練なども必要ですが、ひとまず成功ですね。