製造管理の日程・WF・文書を
Atlassian Cloud で一元化

技術のメンバーは全員ですね。開発に関わるようなドキュメントの管理や日程管理のメール配信をしているので、主にはその技術メンバーということになります。日本のメンバーという意味だと600名程で、あとは蘇州（中国）のメンバーも何名か見ているので、600〜700名程になると思います。

（技術メンバーが）メインではありますが、開発の中で特定のイベントを経て製品をリリースしますというような日程情報も含まれるので、その関係者（営業など）も参照することがありますね。

大きく2つあります。一つ目が日程の見える化です。QMS的に品質管理の方で定義をしている「イベント」、開発のステップのようなものがありますが、どのタイミングで会議やイベントがあるのかといった日程の見える化をするということです。

そして二つ目が、それに関連した文書の管理をするドキュメント管理です。その中で、ドキュメントの承認やイベントの承認がありますので、そこではJiraを活用して、ワークフロー機能を実現して運用しております。

今時点では、PLMの製品情報管理というのは別にシステムがあります。そのシステムでは工場に引き継ぐ内容や、BOMの情報などを管理しています。一方で、Atlassian製品を使っているシステムでは、開発をしていく中で発生する開発ドキュメントを管理しています。

部品表と関連付けが必要なドキュメント（例：製造規格書・部品の仕様書）は別の仕組み（PDMシステム）を使って工場に内容を引き継ぎ、各イベントに対して作成したその他のドキュメントは、このアトラシアン製品を利用したシステムで管理をする、そういった棲み分けになっています。

平均すると、だいたい20テーマ（プロジェクト）前後ぐらいが常に動いてると思います。各テーマの下に平均10品番、最近だと30品番程あるので、20×30＝600品番程の文書を管理しているという感じになるかと思います。

大体一つの工程で、5〜20の文書を扱うことになりますね。プロジェクトの大小によって何工程分の文書情報をこのシステムに入れるかは様々ですが、5〜10の工程を1プロジェクトあたりでやりますので、その掛け算といった感じでしょうか。

またこのシステムはある意味「品質記録文書」という形で扱っておりますので、公的な機関での監査などでも使わせていただいています。100、500もの重要な文書を1プロジェクトで管理していると考えてよいかと思います。技術法規などの法規関連の非常に重要な文書をここで管理しています。

そうですね。神様ファイルといいますか、「承認されたものはここに入っています」というように説明できるので、ISO9001^*の監査対応などでそこを使っています。

*ISO9001：国際標準化機構が発行した品質マネジメントシステム（QMS）の規格。品質の高い製品やサービスを提供するための仕組みを構築・運用し、適切に管理していることを証明する認証。参考：日本品質保証機構（JQA）

年に1回 ISO9001の定期監査があり、必要に応じて随時見せています。エビデンスの提示を求められた際に、必ずこのシステムを経由して文書を取り出して見ていただくという運用になっているので、監査対応においても重要な役割があります。

個人的には、クラウドになったことで、日本で構築したシステムであっても例えばアメリカの現地の方々がそのシステム上でワークフローを回付して合議をするといった、従来できなかったグローバル利用が実現したことは非常に大きいと思います。今後EMEAやAPACなどの現地の方々も責任者として商品の出荷認定に合議していく形になれば、さらにクラウドの力を発揮するのではないかと思います。

クラウドになったということは大きいと思いますね。前のシステムは完全にオンプレミスでの仕組みだったので。

はい。

さらにいうと、フルスクラッチ^*で自分たちでシステムを作っていたので、新しいOSや新しい仕組みについていくのが困難であったり、定期的にバージョンアップがあったりしました。日々、世の中と同じペースでシステムがアップデートしていくという点においても、この差はすごく大きいと感じています。

*フルスクラッチ：ソフトウェアやシステムを、既存のコードやアプリケーションなどを利用せずにゼロからつくりあげること

世の中がIEからChromium系にガラッと変わった時は、前のシステムでは大打撃だったと思うんですよ。そういう点で安心して使っていけるのは、クラウドはかなり違うと感じています。

最近でてきたConfluence Cloudの「データベース機能」とかも、普通のスクラッチだとなかなかアップデートってないと思うんですよね。活用できるかどうか検証がいるとは思いますが、どんどん新しい機能が入ってきて使いやすくなっているので、是非サポートをお願いしたいと思っています。

やはり、機能向上や改善のハードルが低くなったという点が、このシステムにリプレイスしたことで起きた変化だと思います。自前でサーバーを用意して構築すると、一つの新しい機能を作るのに何百万とかかる場合があるので、ほんの少しの改善でもかなりハードルが高かったのですが、今の仕組みではローコード／ノーコードで対応できたり、ユーザー側で設定できる部分も以前より増えているので、そういったところでの改善も期待できます。

開発する機能にもよりますが、3ヶ月〜半年で数百万円くらいはかかると思いますね。まずヒアリングを受けて、見積もりを出して、だいたい齟齬があったりするのでまたその繰り返しです。（よくあるスクラッチ開発だと）あまりトライ＆エラーができないので、テストが上がってきて初めて実機を見て「なんか違うぞ」ということもあり、費用面だけでなく時間もかなりかかると思います。

スタートは2021年7月で、リリースは2022年5月頃ですね。最初は、前のシステムはこんな感じですというのを少しお伝えしました。

従来のスクラッチシステムでは見え方なども含めてかなり作り込んでいたので、今回構築したシステム（Jira／Confluence）のほうでは、スクラッチと比べて制約があります。ある程度標準機能の中で頑張って要望を実現しているということもわかるので、これからもお互いに話をしながら、より良い形を見つけていってほしいと思います。

Jiraの標準機能で実現いただいているので、カスタマイズ要望に対してフルスクラッチに比べると圧倒的にハードルが低いというメリットを享受させていただいていると思います。フルスクラッチだと「それは実現が難しい」「費用が掛かる」といったやり取りをSEの人とすることがあるのですが、それが少なくなり、小西さんからもいろいろと提案をいただいているので、達成できることが増えた点が前のシステムとの違いだと感じています。標準的に備わっているもので作り上げていくというところが、フルスクラッチとの大きな差ですね。

JiraやConfluenceを使っているので、そこにできるだけ関連する情報を載せていこうという意識の変化は、まだまだこれからですが感じています。TeamsやSharePointなど他のツールもありますが、Confluenceという情報を簡単に共有できるツールがあることで、内部のノウハウなどを関係者に見てもらうハードルが下がっているように思います。

Confluenceでは関連するドキュメント上でスレッド形式でサクッとやりとりしたり、Jiraだとタスクやワークフローのチケット上でやり取りができるので楽ですね。SharePointだとその上でやり取りできないので、どのツールで会話するか迷いますし、別で「ここに置いている文書についてですが」とメールを打つことをよくしていました。

あとは、カンバンという見せ方ですね。全プロジェクトが今どうなっているのか一目で把握できるのが大きなポイントです。弊社はソフトウェアだけでなくハードウェアも作るので、開発メンバーだけでなくSCMや製造など、様々な部署が製品の立ち上げに関して情報共有しなくてはいけない。どの商品が今どの段階にあって、日程的に遅れているのか、どれぐらい遅れているのかがカンバンで可視化され、非常に分かりやすくなったと思っています。

他のシステムの運用ノウハウや、技術者によく聞かれる内容をFAQのような形でまとめたり、運営管理メンバーで共有すべき内容・ノウハウをConfluence上でまとめて可視化しています。これまで属人的なノウハウがかなりあったのですが、それらを個人から引き出してチーム内で可視化・共有していくためにConfluenceを活用しようとしています。

以前はWikipediaのエンジンをそのまま乗せて使っていたので、Wikiの構文が取っ付きにくかったんです。ConfluenceはWordと同じような感覚で文章が書けたり、表が載せられたり、ドキュメントが添付できたりと、発信する側の技術的なハードルが非常に下がりました。今はみんなで技術者にとって役立つ情報を発信し、推進チーム内でも「お互い何をやっている人なのかわからない」状態を解消していこうとしています。

ページ毎にユニークアクセスがどれくらいあるかわかるビューがありますよね。

「ビュー数が上がっていないから、このページは少し変えた方がいいのかな」「子ページへの動線はどうかな」といったことを考えられるようになってきました。

ページアナリティクスを見ていると、コンテンツは技術の人だけが見ているわけじゃないことがわかり、違う視点からも情報を提供しなきゃいけないという気づきが出てくるんです。どういう人がコンテンツを見ているのかを気にするようになったのは、Confluenceのこういった機能ゆえだと思っています。

Confluenceのウォッチ機能ですね。ウォッチしているページが更新されたら、メールが飛んでくる機能です。これまで開発支援として、日程会議やデザイン会議の開催案内、結果報告などを個別にメールで送信していましたが、情報を求めている人に届かなかったり、特定のメンバーだけが受け取っていたりすることもあり、「必要な情報だけを取得したい」という要望がありました。

そこでウォッチ機能を活用し、技術関連およびDR関連のイベント情報や結果報告などをリアルタイムで知りたいユーザーは、自身で対象ページをウォッチすることで必要な情報をすぐに入手できるようにしました。現在、この効果を確かめているところです。

ITの観点で言うと、かなりの短期間で構築したこともあり、テンプレートのバリエーションがまだあまり多くない点ですかね。追加の開発イベントが出た際の対応や、不要なステップも自動生成されてしまうなどの課題があります。現在まさに改善を進めていて、ようやくもう少し改善できるところまで来ていると思っています。

運用の課題なのですが、JiraとConfluenceという2つのツールがある中で、Jiraをまだ活用しきれていない点ですね。技術部門のユーザーはConfluenceの文書管理やファイルのアップロードを主に利用していますが、Jira側のチケットも使って関係者とコラボレーションしたり情報共有するなどの活用がもっとできると思っています。ユーザーの方々と会話をしながら活用方法を周知し、標準機能をどんどん使ってパフォーマンスを上げてもらいたいと思っています。

Confluenceに新しく「データベース」機能が出てきたので、コンテンツの視認性を向上させたり、同じ情報からビューを変えて閲覧できるようにするなど、うまく活用していければと考えています。

QMS的な観点では、より実態に合わせた形で品質を担保できるような改善を継続的に進めていかなくてはいけません。例えば、どのドキュメントがどの部門の人にどれぐらい見られているのかを見える化できるようになると、「このドキュメントは実際には活用されていないので作っても意味がない」といった判断ができるようになります。QA（品質保証）と協力しながら、そういう分析にも手をつけていけたらと思っています。