朝の挨拶を交わすことなく自分の席に座ってPCの電源を入れ，メンバーと互いに助け合うムードがないまま黙々と仕事をし続けている。うまく行っているように見えて，実はメンバーのモチベーションが徐々に下がってきている――最近，自分たちのチームや現場の雰囲気が悪いと感じたことはないだろうか。

　実際のところ，ITエンジニアは自分が働く現場の雰囲気をどのように感じているのか。2009年6月30日～2009年7月13日にかけて，日経SYSTMES読者100人に対して，現場の雰囲気を聞くアンケートを実施した。その結果，ほぼ3分の1が現場の雰囲気は明確に「悪い」と回答した。加えて，3年前と比べて現場の雰囲気がどう変わったか質問したところ，「悪くなった」「非常に悪くなった」の合計も全体の3分の1に達し，「良くなった」（21％）を大きく上回った（「非常に良くなった」の回答はゼロ）。このまま何もしないでいると，今は良い雰囲気の現場でも，やがて悪化する可能性が高いということだ。

　現場の雰囲気がこのまま悪くなる一方，というのは由々しい問題だ。モチベーションを向上させたり，コミュニケーションを促進したりして，現場の雰囲気を変えるにはどうすればよいのか。この疑問を解き明かすべく，雰囲気の悪いチームを良い雰囲気に変えるアプローチ法を多数の事例を交えて紹介する特集「イキイキ現場の作り方――チームにも感情がある！」を日経SYSTEMSの9月号に掲載した。

小さなゴールをたくさん設定する

　さて，その特集の企画段階でタイトルに「イキイキ」の文字を含めることを決めたとき，記事自体が「イキイキ」するよう，作成作業も「イキイキ」と進めることを決意した。ちょうど，関東が梅雨に入ったころの話である。ただ，ちょっと問題だったのが，小中学生が夏休みに入って，一昔前なら海へ，山へと出かけて真っ黒に日焼けしているはずの，暑い盛りに作業がピークを迎えること。猛暑の中をアスファルトの反射熱にあぶられながら取材で歩き回って夏バテしたり，作業の追い込みが続く中でもうこれ以上頑張れないと燃え尽きたりしていては，目標を達成できなくなってしまう。

　記事をイキイキと作るにはどうすればよいのかについて具体的なイメージがわかぬまま，取材を始めた。そしてCTCテクノロジーに取材に伺った際，燃え尽き防止策として，小さなゴールをたくさん設定するのが有効だったという話を，「絶対に失敗の許されない通信系システムの開発プロジェクト」でプロマネを務めた方から聞いた。そのプロジェクトには，社内でもトップ・クラスの8人の精鋭ITエンジニアが集められたそうだ。「ドリーム・チームといえば聞こえはいいが，皆プライドが高くて競争意識も強かったので，無理が過ぎてチームが空中分解してしまう危険性があった」という。

　燃え尽き感の発生リスクを緩和するにはチームの一致団結が有効と考え，いくつかの工夫を施したとのことだった。その一つが，小さなゴールをたくさん設定し，それを通過するたびにチーム全体で盛り上がれるイベントを用意したこと。具体的には，一つのシステムができ上がるたびに盛大に祝賀会を催し，めったに話をする機会のない役員からチームにねぎらいの言葉をかけてもらうようにした。経営陣から褒められて，チームの結束力は予想をはるかに超えて強くなったとのことだ。さらに，そのプロマネは，一人分の作業予定を一人だけでは実現不可能なボリュームに設定し，その一方で遊軍となるメンバーが常に生じるようにアサインしたという。こうすることで，予定をこなすには必ず遊軍メンバーの協力が必要となり，「自然とメンバー同士が助け合うようになった」そうだ。

要求が収束しづらく反復作業が終わらない

　話を記事作りに戻そう。小さなゴールをたくさん設定するとよいとの話を聞いたとき，イキイキと記事を作るポイントはコレだと思った。くだんの特集は，1/3ページから4ページの短い記事を寄せ集めた構成なので，各記事の執筆および編集作業を独立したタスクととらえ，アジャイル風に短期間のイテレーション（反復作業）で各タスクを処理していけば作業が平準化されるはずだと。優先度の高い記事から作成していくことで，でき上がった特集が企画内容に沿ったものになることを編集長やデスクが早期に確認できそうなことにも魅力を感じた。なにより，デスクの原稿チェックや制作会社のデザインおよびDTP作業を流れ作業で効率よく実施できそうなので，従来以上にイキイキとした現場になるはず，との思いが頭を駆け巡った。

　このアイデアを実践してみて，二つのことに驚いた。一つは，想像していた以上に毎日の作業量が平準化され，スムーズに進行したこと。正直，いつの間にか作業が終わっていたという印象を受けた。バタバタと作業したのでは品質が上がりにくいので，この点は大いに評価できると考えている。そしてもう一つは，アジャイルで指摘されることの多い，要求が収束しづらく反復作業が終わらないという課題が，特に終盤について回ったこと。今回の記事作成の場合，要求に当たるのは記事の全体最適を図ること。あいまいさや重複感の排除，主張のブレの抑制，寄稿原稿との整合性確保などのため，多様な修正を加えた。修正が必要な個所が必ずしも局所化されていないので，スケジュールに遅れが生じるほどではないにしろ，ひどく手間取った。

　構築するシステムの規模や特性などによって最適な開発手法が変わるのと同様，記事の内容や構成等によって記事の最適な作成スタイルも変化するのは確かだ。とはいえ，もし「次も同じ進め方で記事を作るか」と問われたら，長くて特別に強い一貫性が求められる記事でない限り，「はい」と答えると思う。終盤でつまずきかけた今回の経験を生かして，PDCAを回すよいチャンスとなるはずだから。