桐井製作所にとってのBacklogは「発注のプロ」になるための成長ツール

• 
• シェア
• ツイートする
  一覧
• 

Excelから課題を移行　Backlogで会議が変わる

　とはいえ、非IT企業への初めてのBacklog導入。しかも、クラウドFAXのメンバーは各営業所の受発注担当が兼務でプロジェクトを回しているため、IT専業ではない。当然ながら現場でのとまどいも予想された。

　そのため、澤田氏は「ゼロの方眼紙」を与えるのではなく、単純作業からやってもらった。「まずはExcelの課題表をなにも考えずにBacklogのチケットに転記してもらいました。こうする起票のコツが理解でき、自動的にガントチャートもできあがります。すでに自分たちがやってきたプロジェクト、しかも不便だったツールから移行してもらうと、現場もすっと腹落ちしてくれます」（澤田氏）。

　200近い項目の課題表をBacklogに移行し、現場のユーザーも新しいツールにとまどいながらBacklogを使っていくようになる。こうすると、開発会社とのやりとりがBacklogに集約され、他のツールを見なくてもプロジェクトが回るようになる。「メールで届いた帳票の中から更新点を探すのは大変。でも、Backlogであれば、変化があればダッシュボードに出てくるし、自分に関係すればメンションが飛んできます。専業でないメンバーでもプロジェクトが回せるんです」（澤田氏）。

　また、Backlogを中心に会議を行なうことで、タスクの進捗管理を行なっている。プロジェクトメンバーも、開発会社も、全国各地に散っているので、オンライン会議ではBacklogをベースに課題の棚卸しと未着手タスクの洗い出しを行なってもらう。「未着手でよいタスクなのか、すぐ手を着けるものなのか、あるいは弊社側の確認が必要なタスクか、開発会社側での作業をしているタスクなのかを確認し、ステータスが変わっていたら、ドラッグ＆ドロップで動かせばいい」（澤田氏）。課題を起票するのに加え、会議とカンバンの組み合わせで進捗管理することで、タスク管理を理解できるようになるという。

　裏を返せば、Backlogの導入で会議のやり方も大きく変わった。「会議が定量化できるので、アジェンダを無理矢理作らなくてもいい。弊社も、パートナーも、会議で話すべきことや量がわかっているので、会議がダラダラしない。問題が起こったら課題として起票すればいいし、アジェンダから議事録までBacklogで完結します」（澤田氏）。

他社との連携にはツールを併用　大事なのは外部業者の事情を理解すること

　業務内容やルールが異なる外部の業者とのやりとりに関してはBacklogだけではなく、別のツールを組み合わせるのが効率的だという。桐井製作所では、Backlogに加えて、SlackやLINE WORKSのようなメッセンジャー、そしてメールの3種類のコミュニケーションツールを用途に応じて使い分けるようにしているという。「契約やお金のやり取りなど、対会社に対してエビデンスを残したい場合はメール。タスク管理は基本Backlogに集約し、通知やリアルタイム性の高いものはメッセンジャーを使うようにしています」（澤田氏）

　Backlogはタスクがリンク化できるため、メッセンジャーとの相性もよい。メッセージにBacklogのリンクを貼り、メンションのみに頼らず、「こちら急ぎ対応をお願いします」と開発業者に依頼すれば、スピーディで誤解もない。タスクを起点に能動的にメッセージングツールで進捗管理を行なうようにすれば、外注ディレクションのスキルも磨かれる。「タスクだけだと、投げっぱなしになるので、管理をしなくなる人もいます。でも、メッセンジャーで進捗を追っかけたり、重要なタスクを通知することで、漏れが少なくなります」（澤田氏）。

　こうしたツールの利用で重要なのは外部パートナーの事情を理解すること。桐井製作所では、開発会社が、どんなツールで、どんな工程管理を行なっているのかを理解した上で、適切なツールを利用している。また、Backlogに関しても、課題を開発会社のやりやすい形で作ってもらうケースもあるという。

　澤田氏は、「開発会社も、なにかしら社内で使っているツールがあり、それで工数管理を行なっているので、『すべてをBacklogでやれ』という強制はしない。開発会社の生産性も下がるので、反発もあります。チケットの転記作業などはプログラマーも本当にいやがります。最初にきちんとすりあわせて、Backlogでやれるところを探ります」とのことだ。

　こうした例からもわかるとおり、澤田氏からすれば開発会社も上下関係のない対等なパートナー。「各会社のPMやディレクタークラスの方には、IT人材を育てたいという要望を伝えて、合意をとった上でプロジェクトを始めます。『われわれは不慣れなチームだから、手厚くサポートしてください』とか、『要望は丁寧に説明してください』といった事情は説明しています」とのことで、前提条件や目的もきちんと共有している。外部パートナーにチームワークを拡げ、生産性の高いプロジェクトにするため、さまざまな配慮が行なわれているわけだ。

日本のITプロジェクトは発注者側の責任が甘い　発注スキルとディレクション能力が重要

　現在、桐井製作所社内においてBacklogで管理されている社内のプロジェクトは133におよぶ。「社内ではとにかくフリーで利用してもらっています。日常の雑多なタスク管理で使っているところもあれば、大規模プロジェクトで使っているところもあります。まずはIT業界の仕事のやり方に慣れ親しんでもらうのが重要だと考えているので、あえて利用に制限はかけていません」と澤田氏は語る。

　実は社内のBacklogはすべて画面も構成も異なる。たとえば、クラウドFAXのチームが担当したLINE公式のトークから受発注ができるシステムのPoCは、Backlogのマイルストーンの機能を用いて、2週間のスプリントを設定した。「この2週間という期間が絶妙で、期間を切った段階で、メンバーはこの期間でどれだけのことができるかを考えるようになります。最初から自分たちで回し始めたので、私は3スプリントあたりから放置していました（笑）」とのことで、チームが自走できている。

LINEによる受注開発で使っているBacklogはマイルストーンの機能を使い、2週間のスプリントを切っている

　また、Webサイトのリニューアルの大規模プロジェクトは、画面の中のコンポーネントごとに制作番号を振り、ブレイクポイントを設けて、細かく管理。Salesforceの導入プロジェクトは、設計、構築、テスト、トレーニングなどの工程を踏んだSIらしい管理で進行した。業種や業界で異なるプロジェクトの切り方をテンプレート化として活用しつつ、その成否を検証すれば勝ちパターンが見えてくるという。

Webサイトのリニューアルプロジェクトは、制作番号を割り振り、納期とタスクを細かく管理している

　今回、澤田氏の話で特にこだわりが感じられたのは、発注のスキルアップにBacklogを活用している点だ。昨今、DXを掲げたシステムの内製化は大きな流行となっているが、もともとプロが作ってきたシステムを、ITスキルのない現場部門の担当者が作れるのか？という疑問がある。その点、システム畑・コンサル畑を歩んできた澤田氏は内製化の夢を見ることなく、むしろ外部の業者前提で、発注のプロになることをメンバーに求めてきたという。

　「日本のITプロジェクトは、発注者側の責任が甘い。それが失敗の要因だと思っています。ユーザー企業が上げていかなければならないのは、発注者側のリテラシとスキル、ディレクション能力。あわせてユーザー側で『できること』と『できないこと』をきちんと理解すること。われわれはフル内製化は目指していません。自分たちの業務のプロになれと言っています。ユーザー企業として、ゴールと正解は自分たちが出すべきもの。開発会社に求めるのではなく、自分たちで決め、きちんと発注しましょうと話しています」（澤田氏）。

　自分たち自身で要件をまとめ、相手からのアドバイスや提案があり、折衝を繰り返していくと、自分たちのビジネス理解、指示出し、発注の甘さに気づいてくる。このサイクルがすべて登録されているBacklogは、最高の教育ツールだ。桐井製作所でも、メンバーがBacklog使うことで、プロジェクト管理の練度が上がり、発注スキルとディレクション能力が育っていったという。実際、1年間のアジャイル開発でBacklogを使った結果、テストケースまで書けるようになったメンバーも現れた。

　次に目指すのは、澤田氏の薫陶を受けたプロジェクトマネージャーが次のメンバーを育てるということだ。「この1～2年でプロジェクト管理やアジャイル開発の工程を吸収した人間に、きちんとアウトプットさせる機会を作ってあげたいです」と澤田氏は語る。