私は，2007年2月2日付の記者の眼「『使えない人間』などいない」で「Java初心者で構成されるチームがいかにプロジェクトを完遂したか，という事例」があり，その事例を取材したうえで，日経ソフトウエア2007年5月号のJava特集でレポートすると書いた。その号がいよいよ明日（3月24日），発売される。特集のルポ「Java初心者のチームが挑む基幹系刷新プロジェクト」という記事である。

　具体的には，群馬県内の各JAやJA関連組織のIT共同利用施設であるJA群馬電算センターが提供しているシステムの事例だ。Javaをほとんど知らなかった4人のメンバー，JA群馬電算センター 経済情報部の片野富久氏，前原貴美子氏，大久保浩治氏，渋谷知央氏が，基幹系システムの刷新プロジェクトに先立つパイロット・プロジェクトを成功させた，というものである。

　もっとも，取材を終えた今では，この事例を「『使えない人間』などいない」という例として取り上げるのは少し失礼だったかもしれない，と感じている。彼らにはJavaのスキルはなかったかもしれないが，仕事に対して誇りを持ち，チーム内のコミュニケーションも良好だった。いわば，欠けていたのはJavaのスキルだけ，という状態だったからだ。むろん，スキルの低いメンバーを“信じて”牽引したサポート役の和田卓人氏（タワーズクエスト）は賞賛されるべきだが，このチームだったからこそプロジェクトを完遂できた，という側面も否定できないと思う。

　日経ソフトウエア本誌のルポは，Java特集の一部ということもあり，Javaプログラミングの側面を中心にこの事例を取り上げている。このため，要件定義から設計にかけての流れは大幅に省略せざるを得なかった。ただ，この部分にもチームの“志の高さ”を感じさせる話題がいくつもあった。公開せずに捨ててしまうのは忍びないので，この記者のつぶやきで補足したいと思う。

「問い合わせの電話がかかってこない画面」を作る

　このパイロット・プロジェクトで開発したのは，比較的規模が小さい二つのシステム，「賦課金システム」と「利用高配当システム」である。JAには営農指導のような利益を直接生まない事業があり，そのコストを耕作面積や家畜の頭数などに応じて組合員が負担する。これを賦課金と呼ぶ。賦課金システムは，賦課金を自動計算して組合員の口座から引き落とし，領収書を発行するシステムである。利用高配当システムは，利用高，すなわち組合員がJAのサービスをどれだけ利用したか（＝手数料をどれだけ払ったか）に応じて，剰余金を配当として分配するシステムだ。いずれも基本的には年に1回しか使わないシステムである

写真1●カード型業務分析ツールのマジカを使って，まず現行の業務を洗い出した
[画像のクリックで拡大表示]

　プロジェクトが始まったのは2005年11月。開発メンバーの4人に加え，全農ビジネスサポートのトータル・サポートとして，前述の和田氏とスターロジックの羽生章洋氏が参加した。まず行ったのは，JAの現場で行われている業務の洗い出しである。システムを構築するメンバーも業務に詳しいわけではなかったからだ。このために使ったのが，カード型の業務分析ツール，マジカ（写真1）である（参考記事）。賦課金業務の洗い出しにかかったのは2週間弱。利用高配当業務の洗い出しは，前原氏が1人で8～10時間で終えてしまった。

　ただ，業務の洗い出し後のブレーン・ストーミングには時間をかけた。洗い出した現行の業務フローを，あるべき新業務フローに作り変えたのである。「それまでのシステムの設計は，業務の流れを追いかけているだけだった」（片野氏）。これに対し，このプロジェクトでは，「業務の本質は何か」を徹底的に突き詰めていった。ただ，現行のシステムにどうしてもとらわれてしまうため，考え方を切り替えるのは大変だったという。

　実際の作業では，会議室の壁に業務の流れを貼り出し，おかしなところや流れがよどんでいるところを直していった。和田氏は，この作業を立ちっぱなしで行うよう提案した。立ちっぱなしだと，作業が長時間に及ぶにつれて開発メンバーには疲れがたまってくる。だが，実はそれが和田氏の狙いだった。疲れてくると，物事をシンプルにとらえるようになり，本質的な処理を実現することだけを考えられるようになる。「疲れてからが本番」（和田氏）だったのだ。大久保氏は「システムはいろんな複雑な処理を行っていると思っていたが，『ここはただの振り込み処理』といったように簡単に考えればいいんだ，ということがわかった」と振り返る。

　新しい業務フローが固まったら，構築するシステムの画面を紙に書き出していった。「手書き」というのが重要なポイントである。「ワープロだと見映えが気になるため，できあがること自体に重点を置いてしまう。このため，本来は何をしたいのか，というところを見失いがちになる」（前原氏）。ただ，ここでも従来のシステムの呪縛は強かった。大型コンピュータによる現行システムで使ってきた画面は，行数や文字に大きな制約があった。にもかかわらず，4人には従来のシステムのイメージが強すぎて，最初はそのような画面しか思い浮かばなかったという。そこで羽生氏は「日頃，ネット・ショッピングをするときのような画面を参考にしてみたら」とアドバイスした。これにより，従来のシステムの画面にとらわれない使いやすい画面をイメージできるようになった。

　“使いやすい画面”とは何かを端的に表しているのが，前原氏がプロジェクトの最中に熱く語ったという「ユーザーから問い合わせの電話がかかってこない画面」という言葉である。システムを利用する現場のユーザーは，たいていマニュアルなどは読まず，わからないことがあればJA群馬電算センターに直接電話をかけてくる。その問い合わせ対応に時間を取られて思うように仕事が進まない，という経験がこの切実な考え方を生んだのだ。

写真2●当初，使っていた「組合員コード検索」という表記は，「照会する組合員の組合員コードを入力してください」とわかりやすく書き換えた
[画像のクリックで拡大表示]
　
写真3●画面の表記をわかりやすく書き換えた別の例
[画像のクリックで拡大表示]

　例えば，使いやすさを考慮していなかったときは、画面に「組合員コード検索」といった表記を使っていた。しかし，これでは組合員コード「を」検索するのか，組合員コード「で」検索するのかがよくわからない。そこで，「照会する組合員の組合員コードを入力してください」といったように誰にでもわかる表記に変えていった（写真2，写真3）。また，意味がわかりにくい画面には，長くて丁寧な説明の文章を付けるようにした。このようにして，たとえ業務を知らない新人でもマニュアルなしで使えるような画面にしていった。手書きの画面ができあがったら，それらをすべて壁に貼って「ウォークスルー」を行った。文字通り，歩きながら流れを確認したのである。

　次に，手書きの画面をすべてHTMLにしていった。画面の数は二つのシステムで130程度あったが，賦課金システムの画面は約1週間，利用高配当システムの画面は4日間程度ですべてHTML化したという。さらに，リンクやボタンを押すことで実際に次の画面に遷移するようにそれぞれをつないでいった。この段階でもう一度，システムの流れを確認。実際の動きが付くことで初めてわかる違和感を拾っていった。ここまでが外部設計である。さらに内部設計として，画面から必要な項目を洗い出してデータベースの設計を行った。

　渋谷氏はここまでの作業を「みんなで集まっておしゃべりする感覚で『あれがいいこれがいい』と言い合えたのがよかった」と振り返る。従来のシステム開発だと，パソコンに向かってひたすら書類を作る作業がほとんどで，他の開発メンバーとはあまりコミュニケーションが取れなかった。このプロジェクトではコミュニケーションができたため，より仲間意識が強まり，「みんなががんばるんだったら私もがんばる」（渋谷氏）という気持ちになれたという。

　以上，紹介してきたプロジェクト前半の作業で「何を作るか」ははっきりした。あとはその通りに作るだけだ。ただ現実には，実装フェーズでの作業，すなわちプログラミングも決して楽ではなかった。実装フェーズで何があったかは，ぜひ日経ソフトウエア2007年5月号の記事で確かめていただきたい。