システム開発の現場には幸福感・満足感が少ない
筆者は新卒でサイボウズに入社し、大企業向けグループウェア「ガルーン」のパートナーセールス、ダイレクトセールスを担当した後、2009年からの2年間、事業拡大を目指した戦略的子会社のサイボウズ総合研究所（サイボウズ総研）の立ち上げに携わりました。サイボウズ総研では、クラウドサービス「cybozu.com」の前身となるSaaS事業と、サイボウズ製品に関するSI事業の立ち上げに従事。メーカーの立場でパッケージ製品を提案する側から一転し、お客様ごとに最適解を作り上げる毎日になりました。そこで筆者は、お客様に合わせたシステム開発の良し悪しというものを体感することになります。
パッケージ製品では叶えきれない、お客様の希望にそったシステムの構築は、独自の仕様を詰められる反面、一度作ったシステムのメンテナンスコストがどうしても高くなってしまいます。システムを改修する度にお金も時間もかかってしまうため、業務の変化へ対応する柔軟性を失ってしまうリスクがあります。
お客様を上記のような結果に陥らせないためにも、当時筆者は、最初の要件定義をとにかく綿密に実施し、仕様書に落とし込むことに注力していました。
お客様が業務で抱えている問題を念入りにヒアリングし、時には実際にシステムを使う立場の人に打ち合わせへの同席をお願いするなど、できることは片っ端から取り組みました。しかし……。綿密に仕様書を作成しようとすればするほど、お客様側もこちらに任せる動きになってしまうのでした。「伊佐さんのほうがシステム開発に詳しそうだし、このまま伊佐さんが良いと思うように進めてくれればいいよ」
自分のことを信頼し、任せてくれる。非常に嬉しいことではありましたが、実際にリリースした時、必ずお客様の理想との乖離がありました。
特にシステムの利用者からは「ここはこうしてほしかったんだけど、まあ業務システムってこんなもんだよね」といった諦めの声が聞こえ、導入担当者からは「やっぱり使いづらいから改修してほしい」と改修の依頼が入り、そのたびに本当にこれでいいのだろうかという気持ちが頭をよぎりました。
システム開発の現場には幸福感・満足感が少ない――。そのような感情を、SIの経験をしてからというもの強く意識するようになりました。
仕様書を用意しない「対面開発」という形
その後、筆者はサイボウズに戻り、kintoneプロダクトマネージャーとして活動しています。前述のように、kintoneが開発基盤として特徴的なのは契約窓口の８割が業務部門ということで、これまで与えられたシステムを使うのみだった業務部門のメンバーが、SIと直接対話し、満足のいくシステムを自らの手で生み出しています。
業務部門がシステム開発に抵抗を感じない理由は、旧来と異なるその開発プロセスの中にありました。
まず、システムを利用者する立場の人の目の前で開発する（筆者はこれを「対面開発」と呼んでいます）ことから始まります。画面設計をすれば自動的にデーターベースが構築されるため、見ているだけでも、どのようにシステムが開発されていくのか体感できます。こうしてできあがったシステムは、即時にお客様が操作し、そこで挙がった要望についてSIerや社内開発者が再び目の前で改修します。システムの組み方が理解できているので、ユーザーも改善要望を思いつきやすく、結果としてすばやいPDCAを回しながらの開発プロセスが進みます。この工程を何度か繰り返し、システムはお客様が本当に欲しかったものへと近づいていきます。
システム開発の経験豊富なメンバーにしか解読できない仕様書は用意せず、利用ユーザーを巻き込んだ開発手法で理想のシステムに近づけていく。過去に自分が囚われていたものとは真逆の事実が、そこにはありました。
「仕様書を用意しない対面開発」、それはいったいどこまで通用するのでしょうか？この連載では、その開発現場を直接見ていきたいと思っています。
