アーツテックの新人教育担当です。
当社では毎年新人の開発研修を社内で行っています。入社時にはまったくの経験ない学生でも、2-3か月の開発研修が終わるころには、なんとなく開発っぽくなるのを毎年ほほえましく見ています。

ただ、近年開発するシステムの規模が大きくなり、新人がOJTに入ってもなかなかすべての開発工程を経験することができないという問題を抱えるようになってきたのが、悩みの種でした。その悩みを打開すべく、今年は研修期間を半年に延長し、実際に社内で使用するシステムを構築することにしました。

開発するシステムは社内で公募し、圧倒的多数の支持を得た「週報システム」に決定しました。出退勤時刻はFelicaを使用して記録するというおまけ付です。研修の規模が大きくなるので、新しい教育担当も補強し、お互い日々勉強の毎日です。

せっかく新しい試みを行っているので、このコラムの欄を5ヶ月間ジャックして、彼女たち自身に奮闘記を書いてもらうことにしました。
要件定義～設計～実装～テストの4つのプロセスと最後にリリースとまとめという構成の予定です。
前置きが長くなりましたが、このあたりで新人にバトンを渡そうと思います。
どんな展開・結末になるか担当の私もワクワク・ドキドキしています。

自己紹介

2008年4月1日私達４人の新人が入社しました。
4月1日から入社して、毎日慣れない通勤ラッシュにぶつかりました。朝、満員電車に乗ってる人はツンツンしてる人か、疲れてる人のどちらかであるかのようにさえ思えていました。私はそのどちらにもなりたくはないなと思っていました。
そんな事を考えながら4月は過ぎ、その間に私達はビジネスマナー等社会の基礎を学びました。その頃は覚える事も少なく、苦しさはありませんでしたが、社会に慣れるのは大変な事でした。

5月には、ネットワークやデータベース、プログラミングといった専門的な事を学び、開発の基礎的な事は一通り教えてもらいました。
私たちのほとんどは、これまで本格的にコンピュータに触れて生きてきた訳ではありません。日常生活からは想像し難い電気のしくみや、プログラミングの考え方など、最初は話を聞くだけでめまいがしました。一ケ月間必死になって頭に知識を詰め込んでいました。

実務研修スタート！

そして6月に実務研修に入りました。
実務研修では、実際に週報システムを作ります。学んできた事を実践できる機会でした。しかし、今迄の話を聞くだけの研修ですら目眩がした私達です。知識だって100%吸収しきれていません。こんな状態で実務研修がこなせるのか、とても不安でした。

はじめは要件定義から

要件定義とは、簡単に言えばお客さんからシステムに関する要望を聞き出し、実現可能か不可能かを定義することです。
研修では社員の方をお客さんに見立て、どんなシステムにしたいのかヒアリングをして要求を聞きます。しかし、私達はお客さんに要求を聞くだけで四苦八苦していました。

どんな風に聞けば良いのだろう？
こんな事きいておかしく思われたりしないかしら。
そんな事ばかりを考えて発言する勇気がわかず、気分すら悪くなってきました。聞いた事をメモするだけで精一杯で、先輩にももっと積極的に発言するよう注意されてしまう始末です。

しかし、要求をまとめてみると、聞くべき内容が浮かび上がってきました。二回目のヒアリングでは発言しやすくなり、勇気がわかない事も、気分が悪くなる事もありませんでした。

この時点でもうすでに、慣れない事ばかりでヘトヘトになっていましたが、ここからもう一つのヤマである要件定義書作成に入ります。

要件定義書ってなに？

要件定義書には大きく分けて以下の４つの目的があります。

• お客さんの要求をまとめる事
• 要求を実現するための手段を考える事
• 実現する範囲を定める事
• スケジュールを見積もる事

これら４つの事項を明確にするために要件定義書は存在しているのです。
他にもお客さんとの意識合わせや、チームでの情報共有にも用いられます。これらの知識は５月の基礎研修で教えてもらった事でした。

どうやって書いていけばいいの？

前述したように要件定義書がどんなものかは分かっていましたし、テンプレートは先輩方が作っていてくれました。私たちは中身を埋めていくだけでよかったのです。
しかし、どうやって書けば良いのか全く分かりませんでした。
想像もつかない世界の想像もつかない書類の書き方を悩んでいてもはじまらません。まずは先輩達から情報を引き出すことにしました。

とはいえ、先輩方も忙しい時間を割いて教えて下さるので、最初は細かいことを聞くのは抵抗を感じていました。
さらに時間も限られていたため、私達は作業を分担し、できるところから埋めていく事にしました。
しかしこの作戦は失敗でした。作業を分担してしまったため、言葉遣いやインデントが人によってバラバラで、なんとも読みにくい文章が出来上がり、書いては注意され、書き直し、また注意される。それの繰り返しでした。

マインドマップをやってみよう

徐々に体裁が整ってくると、浮き上がってくるのが想像もつかない範囲の文章の稚拙さでした。分らない中、無理やり文章を書いていた私たちは、大きな間違いをしていたのです。
どんなシステムが出来上がるのか完成予想図もバラバラ、というよりも予想もしていない！というような状況でした。そんな中、要件定義書が書けるはずもありません。
ましてやチームでの情報共有、意識合わせなどもってのほかなのでした。

そこで私たちは、システムに対するイメージをみんなで共有できるよう、マインドマップを作りました。試行錯誤しながら、思い思いの意見を出し合い、システムに対するイメージを固めていきました。しっかりとイメージが固まったわけではないけれど、マインドマップを作ってからはなんとなくみんなの意識も合い、要件定義書も書きやすくなりました。

新たな壁

なんとなく意識があって来たのもつかの間、私たちは再びコミュニケーションの壁にぶつかります。私たちが「機能一覧」と呼んでいた一覧表は「機能要件一覧」として作っていたものでした。

要件定義書には、機能の一覧も要件の一覧も必要だったのですが、きちんと理解や説明をしていなかったために、作っていた書類を先輩方は純粋に「機能一覧」だと思っており、私たちは要件一覧として作業を進めていました。

レビュー直前の月曜日にその誤解が発覚しました。結果的に「機能要件一覧」は「要件一覧」と名前を変えて残ることになり、別に機能一覧を作成しました。このハプニングに収拾をつけるのは、書類の名前を変えるだけではすみませんでした。遅くまで残り、ほとんどを書きなおすことになってしまったのです。

そこから先も言葉の使い方に苦心したり、機能をうまく図で表現できなかったりと容易に作業は進みませんでした。
「～しない予定」と書くべきところを「～しない意向」と書いた結果、非難轟々でした。「意向」という言葉を使うと「～しない」のは私達ではなく、お客様の要望のように聞こえる。とのことでした。私たちはそこまで頭が回っておらず、深く考えないまま使ってしまった単語でした。

試行錯誤しながら、要件定義書は着実に出来上がってきました。それにともなって新システムに対する愛着も増してきました。

要件定義を終えて

最初にシステムを一つ作り上げると聞いた時は、夢の中のような話で、とても現実的には思えませんでした。先輩方に手伝ってもらいながら、なんとか要件定義書をまとめあげた時には、本当に自分達でシステムを作っていくんだという実感がもてるようになりました。
書き始めたころは、「こんなもの書けるはずがない！」と先輩たちを恨んだものですが、今では頑張って良かったと思えます。毎日頭をかかえながら、がむしゃらに頑張っていた自分が可愛らしくさえ思われます。

今回の要件定義書をもとに次回から設計が始まります。設計ではまた違った壁にぶつかり、戸惑う事もあるでしょうが、一歩ずつ確実に成長して行きたいと思います。