個別管理と全体管理を融合し、プロジェクト横断型の問題をまとめて解決

導入の背景と効果

株式会社ワコムはデザインやコンテンツ作成用ペンタブレットのリーディングカンパニーだ。世界１５０以上の国・地域で事業を展開し、年商は1,000億円を超える。OEMを主体としたテクノロジーソリューション事業部では、スマートフォン、タブレット、デジタル文具など、幅広い分野のメーカーに最先端のデジタルインク・ソリューションを提供している。

同事業部は2017年に「Lychee Redmine」を導入。200件以上の製品量産プロジェクトを多国間で一元管理し、業務効率化を果たした。また、開発プロセスの標準化やプロジェクト横断型の問題解決に「Lychee Redmine」を活用し、競争力強化の足がかりを築いたという。実際、どのように運用しているのだろうか？ 同社のプロジェクトマネジメントを主導する大野憲一氏（テクノロジー・プロジェクト・マネジメント Senior Director）に語ってもらった。
（取材日：2023年2月22日）

プロジェクト情報の一元管理を目指してLychee Redmineを導入

属人的な情報管理が混乱を招いていた

組織的なプロジェクト管理の始まりは、8年ほど前にさかのぼります。テクノロジーソリューション事業部にプロジェクトマネジメント専門のグループを立ち上げ、私はそのグループの一員となりました。

当時は40～50件のプロジェクトが動いていたのですが、その運営は各プロジェクトのメンバーや営業担当者まかせ。組織体制もツールも整備されておらず、情報管理に課題を抱えていました。

たとえば、当時のコミュニケーション手段はメールと電話。あとは会議くらいでした。各プロジェクトの情報があちこちに分散しているので、どこに何があるのか、わからなくなるんです。会議の議事録はメールで共有していたので、一人ひとりのメール内に重要事項が埋もれていく。「アレはどうなった？」「ココで何を決めたんだっけ？」といったように、情報の把握自体に時間と労力を費やしていました。

また、一部のプロジェクトでは進捗管理にExcelやPowerPointを使っていました。でも作成者ごとにフォーマットが違うし、複数の類似ファイルに派生しやすい。「この項目はどういう意味？」「どのファイルが最新なの？」といったように、各所で混乱が生じていました。そこで新設された私たちのグループが主導して、プロジェクト管理ツールの導入を検討したのです。

グローバル企業で導入しやすいクラウド環境にひかれ導入を決意

当社が「Lychee Redmine」を選んだ理由は、いくつかあります。ひとつは私自身の経験です。前職で「Redmine」を使っていたので、その拡張機能なら円滑に導入できると考えました。もうひとつはガントチャート機能です。自由自在な日程調整をはじめ、やりたいことがすべてできる点に惹かれました。

そして、クラウドで利用できることが決め手になりました。本質的なプロジェクトマネジメントに集中するために、サーバー管理や運用サポートは任せたい。当グループの海外法人や外部の協力会社など、複数拠点の連携においてもクラウド環境は必須でした。

導入初期の定着には情報集約に徹し、地道に利便性を啓蒙

「Lychee Redmine」を導入したのは2017年です。ただ、立ち上げは苦労しましたね。使い慣れたメールやExcelをメンバーが手ばなさず、なかなか新しいツールに移行してくれなかったからです。

そんな状況で複雑な運用ルールを強制したら、逆効果になりかねません。そこでメッセージをシンプルにして、地道な啓蒙活動を続けました。「Lychee Redmine」を使って仕事をしてください。そうすれば、情報共有や展開ができます――と。

あとは情報の集約に注力して、毎日アクセスする習慣をつけてもらいました。たとえば、大容量のファイルはメールで送りづらいですよね？ でも「Lychee Redmine」を使えば、簡単に共有できます。世界中のFAE（技術営業職）に対して「問題が生じたら、画像や動画を入れて共有してほしい」と依頼しました。

情報が集約・整理・共有され、業務効率がアップ

そうやって各プロジェクトの情報が蓄積されると、回路図のような設計書などの基本情報も集まってきます。「プロジェクトのココに行ったら、この情報が必ずある」という状態になると、メンバーが利便性を実感して、ツールの使用頻度が上がる。次第にそんな好循環が生まれて、定着につながりました。いまだに不十分な点もありますが、2019年頃にはそれなりに浸透しましたね。

その後は各プロジェクトの情報が「Lychee Redmine」に集約・整理・共有され、業務効率が上がりました。情報把握や段取りに費やす時間が大幅に短縮されたからです。仕様の定義からタスク終了までの流れも各チケットに集約されているので、全メンバーが本来の仕事に集中できつつあります。

また、当事業部のプロジェクトでは、日本・中国・台湾の3拠点が密接に連携しています。Lycheeクラウドによって、ローカルサーバーに依存せず、グローバルな運用が容易になりました。

Lychee Redmineを活用し、開発プロセスも含めた全体最適化へ

導入後の効果は、単なる業務効率化に留まりません。当事業部は2020年から開発プロセスの大規模な改革を行い、その推進に「Lychee Redmine」を活用しています。この取り組みはプロジェクトマネジメントの枠組みに収まらないので、順を追って説明しましょう。

【新たな課題】多数のプロジェクトで個別最適を重ねた結果、機能同士のトレードオフが発生していた

まず改革の背景には、私たちの事業構造があります。当事業部が提供するのは、電子ペンおよび、それをタブレット端末やスマートフォンで操作するデジタルインク・ソリューションです。端的にいえば、事業領域がせまく、専門性が高い。したがって、限られたコア製品の性能向上が競争力強化に直結します。

その一方、当社の顧客は日本・中国・アメリカなど、世界中に広がっています。顧客1社に対して多種類のプロジェクトが走っており、その総数は年間200件以上。最終製品は数百種類におよびます。それらのプロジェクトで個別最適化が進んだ結果、全体のレベルアップが遅れていたのです。

当事業部では多くのエンジニアが活躍しています。彼ら彼女らが優秀だからこそ、現場の問題を独自の手法でどんどん解決していました。たとえば、ある問題がハードウェアに起因する可能性があっても、ファームウェア（ハードウェアを制御するソフトウェア）をいじって迅速に対処してしまうんです。

個別の判断としては間違っていません。最適解にこだわって時間を費やすよりも、顧客が求める成果物のQCD達成が優先ですから。でも、それを繰り返していると、プロジェクトごとに製品の進化が複雑に枝分かれしていきます。

その結果、一部で機能同士のトレードオフが起きていました。ある部分を直そうとすると、別の部分に問題が生じるケースがあったのです。また、他グループが開発した新機能を実装する際、円滑に反映できないケースもありました。

【改善策A】ファームウェアの標準化と分業制で複雑性を縮減、管理体制も見直し

このような個別最適化の弊害をなくすためには、プロジェクトマネジメントの枠組みを越えて、グランドデザインから見直さなければなりません。つまり、全体のプロセスを再編して、すべての製品に最適な解ができるようにする。そして、正しいところに正しいフィードバックが必要です。

全体最適化の第一歩として、まずファームウェアを標準化しました。具体的には全プロジェクト共通のファームウェアを設計して、アルゴリズム（計算・処理手順）とパラメーター（ハードウェアに依存する変動要素）を明確に分離。そして、中核をなすアルゴリズムはファームウエア開発エンジニアが担当し、各プロジェクトのハードウェアに依存するパラメータはハードウエアエンジニアがチューニングするように徹底してもらいました。

いわば、事業部全体の開発スタイルと分業体制を見直し、アルゴリズムは常に最適なものを追い求め、パラーメータのチューニング方法はそれとは別に最適化されていく仕組みをつくったのです。この個別管理と全体管理の融合に「Lychee Redmine」は欠かせません。

【改善策B】「共通課題」を軸にした4層構造のプロジェクト管理

仕組みの全体像をイメージしてもらうために「Lychee Redmine」におけるプロジェクトの階層構造を説明しましょう（上図参照）。

すべての頂点に位置するのが「Common Issue」と名づけたメインプロジェクト。複数のプロジェクトに共通する課題・問題を吸い上げて、正しいところにフィードバックする親プロジェクトです。

その下層に、2種類の子プロジェクトが位置します。ひとつは顧客製品の量産プロジェクトを束ねる「Customer Project」。もうひとつは当社主導の先行開発プロジェクトを束ねる「Develop Project」。前者の下には「A社」「B社」「C社」など、後者の下には「新機能X」「新機能Y」「新機能Z」などの孫プロジェクトがツリー構造でぶら下がっています。

顧客単位の孫プロジェクトはそれぞれのプロジェクトの担当PMが統括しています。その下に「SKU1」「SKU2」「SKU3」といった、最終製品のひ孫プロジェクトが並ぶわけです。いわゆるPLは、この各プロジェクトのチューニングを管理。従来はここで小さな問題が発見され、現場判断で改修される場合がありました。

【改善策C】チケットの重複設定で‟一点突破・全面展開”、適切な機能改修に

しかし、いまは違います。もし現場のひ孫プロジェクトでアルゴリズムに起因する問題を発見したら、チケットを作成して情報を共有します。他のプロジェクトからも同じ問題がチケット化されたら、大元のプロジェクト「Common Issue」で一括管理。プロジェクトマネジメント専門のグループが交通整理して、対応を判断します。いわば、PMOのような役割ですね。

そして、アルゴリズムの共通課題を担当の開発者にフィードバックして、最適解を検討してもらいます。解決策が確立したら、チケットの重複設定などを通じて、同じ問題を抱える全プロジェクトに展開します。適切な改修をしないと、その下にぶら下がっているすべてのプロジェクトで問題解決に至らないので、従来プロジェクト毎に応急措置で対応していたところが根本解決を実施するようになり、それがすべてのプロジェクトに反映することになります。

【改善策D】誰がみても次の流れがわかるように標準的なワークフローを各チケットに明記

この流れを円滑に進めるために「Lychee Redmine」の管理者が集う会議体を新設しました。その会議で標準的な開発のプロセス（ワークフロー）集を作成。管理者がチケット作成時にトラッカーを設定して、メンバーが担当チケットを見るだけで業務の順序がわかるようにしたのです。

すると「この問題は誰に回して、誰に確認して、誰にクローズしてもらえばいいんだろう？」と悩まずにすむ。それぞれのメンバーが正しいところにフィードバックして、正しくクローズできます。

また、カスタムフィールドで分類項目を増やして、問題点のフィードバック先を細分化して記録できるようにしています。カスタムクエリで絞り込み検索の条件を設定しておけば、全プロジェクトから見たい問題点の情報をワンクリックで表示できます。

【施策E】バックログ機能で優先度を分け、意思決定の精度と速度を上げる

最近はバックログ機能を重宝しています。これが山積する問題点の整理に便利なんです。本来の用途はアジャイル開発のスプリント運用などでしょうが、私たちは「Common Issue」の管理に応用しています。

この機能の利点は、多くの問題点をズラッと並べて、カテゴライズできるところです。ひとくちに「問題」といっても、目前の顧客対応、今後の性能改善、プロセス見直しなど、その性質や大小にはバラつきがあります。それらを3段階の優先度に大別して、管理者たちと共有。週次会議で一つひとつの問題点を優先度順に検討し、具体的な対応を意思決定しています。

その際、バックログの画面上だと、各チケットの入れ替えや日付変更が簡単です。「これは来週に改めてトラッキングしよう」「これは猶予があるから、もう少し後の日付に変えよう」というふうに、どんどんレビューできる。非常に使い勝手がいいですね。

適切な問題解決が加速し、製品の本格進化へ

バックログも含めた体系的な仕組みは、ようやく昨年に整ったところです。いまは可視化された問題点を片っぱしから潰している最中なので、全体のレベルアップはこれから。数ヵ月後に「この問題はパラメーターでもアルゴリズムでも解決できない」というソフト改修の終着点までたどりついたら、製品の本格進化が見えてきます。

なぜなら、先行開発プロジェクトにチケットを回して、次世代ICなどの開発時に検討するからです。「Common Issue」を頂点にしたツリー構造によって、量産系と開発系プロジェクトの連携も円滑になりましたね。

このようなチケットドリブンの開発スタイルが定着したら、次は工数を測定できるようにして、生産性の向上に取り組みたい。「Lychee Redmine」のリソースマネジメント機能を活用すれば、工数削減や生産性向上を可視化できます。きっと現場のモチベーションが上がり、人材マネジメントにも役立つでしょう。

プロジェクトマネジメントの進路

我々の製品は顧客の製品の中に部品として実装されるものなので、我々の思い描いているようなものを我々の都合だけでプロジェクトを完成させることはできません。顧客側の部品の変更や、スケジュールの変更、要求仕様の変化や、市場環境の変化、同時にやってくるプロジェクトの数や、内部リソースの調整まで含めてリスクを全て想定してしまうと物はできなくなってしまいます。便利なツールを導入しても、優れたノウハウを学んでも、求めているものに到達できるとは限りません。

でも私が正しいと考える方向性はあります。それは、事前に計画を立てることは当然として、顧客と誠実に向き合い日々のプロジェクトに対処しながら、開発プロセスで標準化できるところは標準化して当たり前のことは誰でも普通に出来上がる環境を作り上げることです。そのカギとなる情報管理、標準化、可視化をLychee Redmineを通して作り上げていき、そこで空いたリソースで、より競争力を上げる製品を作り上げていくつもりです。