概要

この度、自分だけで使う小規模な書籍自炊システムを作った。
振り返ってみると業務でのシステム開発に通じる要素がちらほらあった。
初心者や未経験者、大学生など、システム開発に関してまだそれほど明るくない方に向けて勘どころをまとめる。
また、顧客向けサービスや社内システム、受託開発、自社開発などを区別せず広い意味でシステム開発を取り上げる。
IT関連の仕事に興味があるががなんとなく実態が掴めない、具体的な業務内容がピンとこない、という方が解像度を上げる助けになれば幸いである。

目次

導入
 要件定義(この記事)
設計
 実装

要件定義の始まり

まずは大枠からまとめてみる。
要件とは必要とされる条件や機能のこと、よりくだけた言い方をするとユーザーがやりたいこと。

今回は私がユーザーであり開発者であるため、自分がやりたいことを自分で実装する。
もし今回のプロジェクトがお客さんからの依頼で始まったとして、最初に上がってくる要件は以下のような内容が想像できる。

紙の書籍を電子化したい。
- 書籍を裁断せずにスキャンしたい。
- 最終出力はPDFとする。
- PDFをクラウドに保管して複数の端末から閲覧したい。
  - 閲覧を想定する端末はwindows, mac, iPhone, iPad等

図にすると以下のようなイメージになる。

実際の業務では最初の打ち合わせは簡単な挨拶と、システムの概要として上記のようなことを確認して終わるだろう。
開発チームはこの内容をもとに要件定義を進めていくことになる。

最初の要件を掘り下げる

上記の図だけでもシステムの大枠は掴めるが、もう少し細かく掘り下げるべきところもある。
要件定義では、最初に大枠を把握したらより細かい内容を検討していく。
実際の業務ではこのあたりからエクセルやパワーポイントを使うようになる。
先ほどの図にあるそれぞれの要素についてどんな属性を持っているか考えてみよう。

書籍
- サイズ(A4, A5, 文庫本など)
- 縦書き(右綴じ)、横書き(左綴じ)
- 言語(日本語、英語など)
- カラー、モノクロ
PDF
- カラー、モノクロ
- 許容できるファイルサイズ
- ロックや署名は必要か
- 注釈や書き込みの可能性
- OCRは必要か
- 表紙、裏表紙を含めるか
スキャン
- 1冊のスキャンに関わる人数
- 裁断は必要か
- 使用端末
  - スマートフォン、スキャナ、カメラ
- 端末の組み合わせ
  - 例えばスキャナやカメラを使う場合はコンピュータも同時に必要になる。
  - 複数の端末を組み合わせて使う場合の接続方法(有線、無線)
- 作業環境の広さ
  - 例えば広い机が使えるのであれば使える端末の候補も増える。
  - 逆に机がなかったり狭い場所での作業なら使える端末が限られる。
クラウド
- アクセスできる人(自分、他人など)
- アクセスできる端末
- ファイルの履歴管理は必要か

この段階はまだ仕様を作る段階ではないため、その要素がどんな属性を持っているかを考えるのが重要。
このようにまとめた資料をもってユーザーが必要としている要件を明確にしていく。

属性
システム開発やプログラミングをやっていると結構耳にする言葉のひとつ。
性質やプロパティとも言い換えられる。
意味合いとしてはそのモノに対して設定可能な項目と言える。
例えば今回話題にしている書籍であればサイズであったりページ数、綴じ方向などが挙げられる。
また、もう少しプログラミング的にcsvファイルで例えてみよう。
csvファイルであればファイル名、項目名、項目数、行数、文字コードなどが挙げられる。
この属性というものは細かく考えればいくらでも細かくできるため、検討の匙加減には慣れが必要。

属性を考える具体的な方法

上記の属性はこの記事を書くにあたってまとめた "結果的なもの" である。
最初からこれらの属性をすべて挙げられたわけではない、ではどのようにしたか。
一番手っ取り早いのは実際のモノやコトを見ることだ。

例えば書籍は手元にある実際にスキャンしたい書籍を見比べて本による違いを属性としてまとめた。
例えばPDFは電子書籍として使うことを想定している。そこで、kindle書籍を見比べて必要そうな機能を属性としてまとめた。
例えばスキャンには機材が必要になる。自宅で確保できる作業環境や機材をもとに無理なくできることを属性としてまとめた。

このように実際のモノ、コト、想定した使い方をもとに考えていくと非常に検討を進めやすい。
実際の業務であればユーザーからいくつかサンプルの提供を受けることをおすすめする。
.csvや.txtを入出力とするシステムであれば実際のファイルを貰うのが良い。
webサイトを作るプロジェクトであればwebサイトの見た目を示したラフ画や、そこに表示するコンテンツの原稿を貰うのが良い。
今回のように何らかのオペレーションが発生するシステムであれば、その作業動画を貰ったり実際の作業を見学させてもらうのが良い。

オペレーション
そのシステムを運用するうえで、人間が行う作業や操作のことをオペレーションという。
これは今回の書籍自炊システムや、企業の商品発送だったり帳票出力など現実のモノと関わりが強いシステムでよく使われる言葉。
単純なアプリケーション開発ではあまり耳にしない印象がある。
例えば今回であれば書籍のスキャンは人間の作業なので、スキャンオペレーションということになる。
また、商品発送であれば商品のピッキングオペレーションや梱包オペレーションなど様々な作業がある。
現場や状況によって比較的広い意味を持つ言葉だが、なんらかの作業や操作を指すものと覚えておけばよい。

実際に見ることの重要性
「普通に考えれば当たり前だろう」と思っても実際に見ることにはとても重要な意義がある。
ここでは書籍の縦書き、横書きについて取り上げてみよう。
パッと考えてみれば1つの書籍というのは縦書きか横書きかどちらかに統一されていると考えるのが妥当だろう。
ところが実際には、次のように本文は縦書きで注釈が横書きというパターンがある。

今回は結果的に既存のOCRアプリケーションを採用したのでお手軽だったが、自分でOCRプログラムを開発するとなると話は別だ。
この縦書きと横書きが混在しているという前提に早い段階で気づかないとプログラムの構成が複雑になるかもしれない。
私は画像処理系のプログラムを書いたことがないため実際の難易度は分からないが、考慮しておくに越したことはない。
このような想定と違った例は実際の開発現場でも山ほどある、どれだけ気をつけていてもだ。
自分の先入観が邪魔をしたり、機密等の理由でサンプルの提供を受けられないこともあるだろう。
また、スケジュールの都合で確認できないことも考えられるし、単純に面倒くさくて見ないこともある。
しかし、念のため見られるものは全部見ておこうという心構えは非常に重要である。

まとめられた属性を受けて……

先ほどの属性のいくつかは今回の開発中に初めて気がついた。
実はこれは珍しいことではなく、非常によくあることだ。
以前の記事でも書いた通り、ユーザーから依頼が来たとしてもほとんどの場合ユーザーは自分が必要としているものがよく分かっていない。
要件定義とはユーザーがやりたいことを聞き出すための工程である。
先ほどまとめた属性をもとに要件を更に絞り込んでいく、実際にはこのあたりから要件≒仕様となってくる場合もある。
打ち合わせの内容としては開発側が資料を提示してユーザー側が確認する、という流れが多い。
今回で言えば先ほどの属性をまとめた資料を提示してユーザーが必要なものを確認していくということになるだろう。
場合によっては開発側で事前に要件定義書などの資料を作成してユーザーからレビューや承認を貰うこともある。

最終的に今回の書籍自炊システムの要件を以下の通りとした。

書籍
- A4(見開きA3)以下
- 縦書き(右綴じ)、横書き(左綴じ)の両方に対応する。
- 縦書きと横書きの混在に対応する。
- 日本語と英語
- カラー、モノクロ
PDF
- 基本的に書籍の属性をそのままPDFに適用する。
- PDFの大きさは書籍の大きさと一致しなくてもOK
  - 例えばA5の書籍でもA4のPDFを出力可能とする。
- 1ファイルにつき200MB以下を目標とする。
- カラーはカラー、モノクロはモノクロのPDFを出力する。
- ロックや署名は不要
- 注釈や書き込みは必要
- OCRは必要
- 表紙、裏表紙を含める
スキャン
- 1人で作業できるものとする。
- 基本的にカメラとiPadを有線接続してスキャンする。
- 例外としてスマートフォン単体でもスキャン可能とする。
- 作業環境は100cm*60cm程度の机を使う。
クラウド(保存と閲覧)
- 自分だけアクセスできればOK、逆に他人はアクセス不可とする。
- windows, mac, iPhone, iPad等でアクセス可能とする。
  - 実際にはwebブラウザやスマートフォンのアプリケーションでアクセスする。
  - どの端末からでもPDFを編集(注釈や書き込み)可能とする。
- ファイルの履歴管理は不要。

簡略化のため箇条書きとしているが、実際の業務ではエクセルやパワーポイントでそれっぽい資料を作ることが多い。
そのほうが資料を成果物として扱えるのでビジネス上の都合が良いのである。

それっぽい資料の重要性
なぜ資料の見映えが重要なのか、内容が読み手に伝わればそれで十分ではないか？
確かにその通りである、設計書やその他資料はシステムを作るためにあるのだ。
しかし、ビジネスとしてはこれらの資料にはもう1つの役割がある、ユーザーの承認を得るためにこれらの資料を使うのだ。
ではその承認は誰が行うのか？　そのプロジェクトに参加している役職者だったり、もっと上位の人だったりする。

そうなると伝えたい内容は相手に伝わるだろうか、ユーザー側の役職者は恐らく技術的な事柄にはあまり詳しくない割合が高いだろう。
それだけでなく、技術的な内容というのはどうしても複雑で一見すると読みたくない資料になりがちである。
ひどいときには最初に何を見れば良いのか分からない資料さえある。
そんな状況を避けるために見映えをある程度整えて「あぁなんとなくしっかり作ってあるな、あのときの打ち合わせの内容も含まれてるし。」という資料を作るのは一定の価値があると言える。

まとめ

今回の記事では要件定義の工程を詳細に記載した。
最初の要件から最終的な要件まで検討内容がどのように変化していくか、また、この工程で重要な点が伝われば幸いである。
次の記事では設計工程として、要件を受けての技術選定やプロトタイピングの内容を取り扱う。