前編でご紹介したプロジェクト管理に関わるすべての方のための祭典「Backlog World⁠」⁠。このイベント内にて、2017年の最も素晴らしいプロジェクトを表彰する「Good Project Award」を行い、最優秀賞には、株式会社diffeasy（本社：福岡県福岡市、代表取締役社長CEO：白石 憲正、以下diffeasy）のプロジェクト「田舎の木材工場で起きた奇跡」が選ばれました。

「⁠高い目標に皆で力を合わせて取り組んだ、不可能と思われた難題をアイディアで解決した、大量の課題に粘り強く立ち向かった、など。2017年に完了させたプロジェクトの中から、Backlog World 参加の皆様に共有できるエピソード、知見、感動をコンテストで発表してみませんか？」という応募要項のもとエントリーされたたくさんのプロジェクトの中から、書類審査を通過した6つのプロジェクトによりコンテストがおこなわれ、同日に最優秀賞の表彰式も実施しました。

また、審査員は会場の参加者および、津脇慈子氏（経済産業省中小企業庁⁠）⁠、中村駿介氏（株式会社リクルートホールディングス人事統括室 人事戦略部 部長⁠）⁠、筆者の3名でした。

ここでは、最優秀賞に選ばれたdiffeasyをはじめ、表彰された各プロジェクトについてご紹介します。

田舎の木材工場で起きた奇跡（株式会社diffeasy 西武史）

宮崎県高原町にある木材加工業の（diffeasyの）クライアント企業の社長から「iPadシステムを創りたい。社員に任せているけど、できない」というわりとザックリとした依頼を受けたことから物語はスタートしました。社員に会って話をすると「iPadってなんね？スマホってなんね？」と言われるほど。

そのクライアントの社員数は20名で平均年齢は48歳、使っている携帯電話はほとんどガラケー、そして老眼。ただ、社長の思いは非常に強く「今後絶対にITシステムが必要になる！どうにかしてくれ！⁠」⁠。diffeasyは、「⁠世界中の“⁠むずかしい⁠”を簡単に」を理念にシステム開発などの事業を行っている企業。そこで「この社長の感じている“⁠むずかしい⁠”を簡単にすることができなければ、世界中の“⁠むずかしい⁠”を簡単にすることはできない」ということで、プロジェクトに着手しました。

最初にはじめたことは、開発メンバーも現場に行き、どういうことをやっているか、どういうことで困っているかなどのヒアリングを徹底的に行い、その結果、家1件につき500枚ほどある紙の設計図の管理がとくに大変だということがわかってきたそうです。お目当ての1枚を探し出すのに多くの時間を使ってしまい非常に効率が悪いことに気づき、その解決策として、プロジェクトメンバーは設計図面のペーパーレス化に着手しました。

タブレットに設計図面を読み込んで、タッチペンで手書きの書き込みもできるようにし、さらに、設計図面が着手中なのか完了なのかという状態も管理できるようにしました。

また、メニューは老眼の方が多いのでメニューを色分けして文字を大きくして、わかりやすくしたそうです。これは、現場で見学をしたエンジニアの「おじさんたちは“⁠赤いボタン押して⁠”とか“⁠青いボタン押して⁠”とか言うような運用をする」という意見を取り入れたそう。

実際にできたシステムを導入してどうなったか？紙の設計図は全部なくなり、全部タブレットになりました。いまや「このタブレットがないと仕事できない」と言われるほどです。さらに、後日現場に伺うと工場に大きなディスプレイが設置してあり、何なのか尋ねると、数ヵ月前まで「スマホってなんね？」と言っていた人たちが、今度は逆に「西さん、知らないんですか？iPadとかAppleTVを使えば、ディスプレイにミラーリングできるんですよ」と回答されたほど、現場の皆さんへの浸透度が高まっていることを感じた、と西さんは感慨深そうに振り返りました。

さらに良い効果がありました。若手がシステムの使い方をベテランに教える状況が生まれ、その影響で若手が技術に対してベテランに質問しやすくなり、交流が生まれたのです。また、システムに対しての提案や意見が活発に出るようになり、会社に対しても提案などをするように変わっていき、他の工場からも見学に来るようになり、このソフトウェアをパッケージソフトウェア化することも決まったそうです。

プロジェクト導入が一息ついたところで「クライアントの木材加工業の社長からは“⁠（diffeasyさんは）我々がこの先、いくらでも変化できると思えるキッカケを作ってくれました⁠”という言葉をいただけたこと、それが何よりのご褒美となりました」と締め括りました。

インシデント管理を一本化して大幅なコスト削減（株式会社IDOM 紺野良太）

中古車の買い取り販売の「ガリバー」を展開しているIDOM（イドム⁠）⁠。国内で8つのブランドを展開しており、アメリカ、ニュージーランド、中国、そしてオーストラリアにも展開しています。1998年に上場後、20年が経過しており、その間に生み出された業務アプリが548個。そして、廃棄されたアプリが216個。現在、稼働中のものが332個あり、それを5社のシステムベンダが保守しているそうです。

平均すると1社約66個を、非常に優秀なメンバーが保守しているのですが、チケットの管理が各社バラバラで、実態がわかりづらい問題が会ったそうです。そのため、増員の要請があっても、正確な判断ができない状態でした。

そこでBacklogを導入し、「⁠作業が終わったら実績工数を入力する」という簡単なルールを導入し、入力された工数を夜間バッチで集計して、工数の可視化を図りました。結果、要員が不足しているチーム、超過しているチームがわかるようになったそうです。

保守は、なかなか褒められることなく、モチベーションが下がりがち、結果的に目の前の作業をやるだけになってしまい、改善は先送りされる。チケットの発生は減らず、悪循環で、メンバーが疲弊していく。今回の取組の副作用として、実績工数を可視化したことで、改善ポイントが発見しやすく、保守メンバー側から、改善の提案が出てくるようになったそうです。そのおかげで、改善や恒久対応が進みチケットの発生件数も大幅に削減したそうです。

LT大会を2年運営して気付いた会社を超えたコラボレーションの秘訣（広報LT大会運営委員会 吉田ハルカ、山川空）

IT系の会社に勤める吉田ハルカさんと、農業系の会社に勤める山川空さんは、ベンチャー企業の広報をやっています。ベンチャー企業の広報は、先輩が居らず、いきなり初代広報になるケースが多く、ノウハウやナレッジが社内にない、また、具体的な事例が書籍やネットにも掲載されていなく、属人性が高く孤独であるとのこと。そこで2年前に始めたのが、「⁠広報LT(ライトニングトーク)大会⁠」⁠。エンジニアの「ライトニングトークの文化（ナレッジをシェアする文化⁠）⁠」に感銘を受けての立ち上げでした。

2ヵ月に1回、広報に関する話題を幅広いテーマを扱うライトニングトーク大会を開催。登壇者には「明日すぐに使えるTipsを入れてください」とお願いしているそうです。毎回50名くらいが参加して、8名くらいが登壇しており、「⁠教科書に載っていない泥臭い悩みや葛藤から学びを得られる」「⁠アウトプットも交流もできるいい機会」「⁠発表、参加がしやすい空気づくりが良い」「⁠フォロー体制が整っていて復習・実践しやすい」などのフィードバックももらっているとのことです。

運営にあたり、とくに力をいれているのはLT大会後で、翌日に発表者にお礼と資料共有の促進を行い、参加者アンケートの送信と回答促進をしており、翌週以降にイベントのレポートを公開、そして、運営メンバーで1ヶ月以内に打ち上げと反省会を開催しているとのことで、まさに広報担当者らしい取り組みです。

イベントの空気づくりとしては、とにかく参加者の人が温かくリラックスできる空間づくりを意識しているそうで、まずは最初に全員で乾杯をするところからスタートして緊張を解しているそうです。特徴的なのは、発表している人に向けてリアクションをしてもらうために「よっ！むっ！の徹底」に取り組んでおり、発表している人がいいことを言ったときは皆で「よっ！」と言って褒めてあげ、逆に失敗した話しなどをしたときは「むっ！」とポジティブに突っ込んでいるそうです。

この場で知り合った先輩に教わった軸ずらしPRと呼ばれる手法で、実際にテレビの取材を獲得できた経験から、1人の経験が誰かの学びにつながると感じ、このコラボレーションはずっと続けていきたいと思っているそうです。また、新たに導入したBacklogのタスクに「夢」というカテゴリーを作ったとのこと。ユニークですね。

クライアントとベンダをつなぐプロジェクトマネジメント（株式会社mgn 福嶌隆浩）

クライアントとベンダ3社のうち、Gitのリポジトリがベンダ側1社にあり、その1社に対してクライアントから進捗や課題、ファイルのコントロールが非常にしづらい状態になっていて、現状がどうなっているかわかりにくいということが発生していました。また、Gitリポジトリのない他のベンダ2社は、都度、Gitリポジトリのある1社に作業して貰う必要があり、大変、やりづらい状況になっていました。

課題解決として、クライアント自身でGitを管理するようにし、効率化を図っていこうとしましたが、今までの経緯があり、クライアント主導で進めにくい関係性にもなっていたそうです。そこで、株式会社mgnは、Gitのリポジトリーを移動することを取りまとめ、Backlogの運用のレクチャー、Gitの研修の実施、さらに混乱しにくい環境づくりを開始しました。

クライアント自身がGitを管理でき、Backlogを活用できるようになったことで、クライアントとベンダ側での作業分担が明確化され、タスク管理で進捗状況や様々な事象の原因理由が共有化されたそうです。さらに、その結果、クライアント自身の問題解決できるスピードと能力が向上し、また、不明瞭になっていたコストも見直すことができたそうです。

受注者と発注者という立場で、どちらにも言い分があり、上手く動けていなかったプロジェクトでしたが、その関係をGitとタスク管理システムでつなぎ、本来の大きなプロジェクトに対して、1つのチームとして働くことを目標に置くことができたそうです。

建設業での設計図面の新旧比較をするツールを開発（株式会社TRIART本田康信）

医療の現場で使われる「レントゲン写真⁠」⁠。2枚のレントゲン写真を比較してガンの場所を見つけるツールがあるのですが、その技術を建築現場の図面を比較するのに使ってみるプロジェクトの紹介です。周囲の2人ほどに相談したら「画像を重ねるだけなんて、面白くないんじゃないか？」と口を揃えて言われたそうですが、「⁠これは絶対イケる」と確信があり、クライアントのいない、完全に自社製品としての開発に踏み切ったそうです。

建物の製造過程は頻繁に図面が変更されます。例えば、何かの間違いで図面の意図しない部分が変わってしまっていることに気づかずにそのまま発注して、そのまま施工されてしまうようなケース。場合によっては数億円の発注ミスにつながるそうです。その対策として新入社員や事務員に図面の比較をさせているケースがあり、確認のための人件費や、ミスした施工のやり直しなど、多くのコストがかかります。

はじめは簡単に画像比較だけだと考えていたんですが、それだけでなく、青図、CADデータ、3DCADデータ、そしてFAXで送られてくる図面など、全て重ねるようにしました。また、比較する図面が2枚のときもあれば、5,000枚にもおよぶときもあるそうです。

社内で開発していくのと同時に、九州工業大学の先生に画像解析の技術協力を仰ぎ、現在は、大手建設会社を始め300社に導入されており、角度の違う建物の写真でさえも自動補正でバッチリと重ねることができるまでになったそうです。契約書なども比較するユーザなども現れ、今後は、更に歪んだ画像も解析できるようにしていきたいとのことでした。

エッジな技術を扱うプロジェクト運営の話（ピクシブ株式会社川田寛）

インターネットでは「ライブ配信」が大流行、そこで、「⁠イラストレーターのライブ配信需要にも、なんとかして答えたい！」と作り始め、4ヶ月で完了したプロジェクト。クリエイターのためにエッジな技術を躊躇なく使っていくチャレンジがいくつもあったそうですが、その結果、潜在ユーザをしっかりと掴み、お絵かき配信で、（⁠おそらく）世界シェアトップのプラットフォームになったそうです。

体制は、プロジェクトの統括が1名、運用広報のチームが11名、プロダクトマネージャー1名、プロトタイプ開発チームが3名、そして、リリース向け開発チームが17名。主に、運用広報のチーム、プロトタイプ開発チームとリリース向け開発チームが要になっていました。

エッジな技術を躊躇なく使っていくプロジェクトの課題は、調達の困難性。インフラの内訳がコロコロ変わり、また、頻繁に発生する稟議の承認に時間がかかり機能しないので、稟議を辞めるまでに至ったそうです。新規性の高いことをやろうとした場合、会社のルールが邪魔することが多いので、マネージャーは絶対逃げてはダメ。絶対に会社と向き合って、会社のルールを変えていくことが大事で、プロジェクト中はずっとそれをやってきたとのことです。

また、進捗管理も上手く機能せず、「⁠あとどれくらいで終わりそう？」と尋ねても「3日か、3ヶ月ぐらい」と言われる。そこで、進捗管理も辞め、100%計画されたものを作ることが重要ではなく、「⁠リリースしたら一番盛り上がる時期にあわせてイケてる機能を選ぶ」というタスクの優先度を管理する運用に変えたそうです。

また、定例ミーティングが大嫌いなので、ステークホルダとのミーティングは初期段階でしっかりと議論をし、途中からはリアルタイムなコミュニケーションが重要になるので、定例ミーティングは減らしていき、チャットツールでコミュニケーションをするようにしたそうです。

新技術を扱うプロジェクトにおいては、「⁠ユーザのコンテキストにあわせていくほど、汎用的な道具に頼らない攻めの姿勢が必要」と話す川田さん。また、「⁠会社都合のルールで縛ったことでプロジェクトの質を 下げてしまうのを防ぐ努力は重要」「⁠進捗管理ではなく、優先度管理」「⁠100%を狙うのでなく、どうすれば最高に近づくか」「⁠ステークホルダコミュニケーションは定例報告をやめて、リアルタイム性を上げる」といったことが大事になるとのことでした。

審査員の講評

最後に審査員の講評をお届けします。