テクノロジー本部の鈴木(@szk3)です。ソリューションアーキテクト・クラウドアーキテクトとして業務にあたっており、最近はWebRTC周りに興味関心があります。
自分が所属するチームでは「アーキテクト相談」 という技術相談の取り組みを行っています。
今回は、その技術相談で取り入れている 「ナレッジマネメント」および、知識経営の提唱者である野中郁次郎先生が提唱した「SECIモデル」について紹介します。
背景
LIFULLでは、多種多様なプロダクト開発を行っておりますが、それらの設計や開発工程においてグループ内だけでは判断しづらい内容がでてくることがあります。
そういった悩みは、個人・組織において以下のような問題を引き起こしかねません。
個人レベル
- 悩みの解決の糸口が見つからず、開発工程を圧迫する
- ルールや規約があることを知らず、手戻りにつながった
- そもそも、誰に聞いていいかわからない
組織レベル
- 別のグループも同じ悩みを抱えているが、その悩みが共有できてない
- 相談内容と回答の中から、汎用的なものはストックしておきたい
そういった課題に対し、汎用的な技術相談窓口として機能しつつ、それらのやりとりを一過性のものにしない相談の仕組みが「アーキテクト相談」です。
「アーキテクト相談」の目的は "システム・アーキテクチャの初期設計・手戻り工数削減" です。
この目的を達成するために "解決策を一緒に整理し、使えるナレッジとして再利用できるようにする" という一連の流れをサポートしています。
相談手法
「ナレッジマネメント」を説明する前に、相談手法について整理します。
他の方法(例えば対面での口頭、電話)もありますが、ここではテレワークを前提とした現時点で実際に使っている相談手法を列挙しています。
手法 | メリット | デメリット |
---|---|---|
チャット (Slack / Chatwork ) |
・個別相談でも気兼ねなく聞ける ・ほぼリアルタイムで相談にのってくれる |
・ やりとりの流れを追うのに時間がかかるケースがある ・大人数の部屋だと相談しにくい人が、少なからずいる |
オンライン会議 (Zoom / Meet ) |
・話したほうが早いケースがある ・熱量が伝わりやすい |
・相談内容を他の人にシェアしづらい(議事録残らない可能性) ・時間的な制約がある |
チケット駆動 (JIRA) |
・議論が混ざりにくい ・シェアしやすい ・テンプレ化しやすい ・情報をリンクさせやすい |
・チケットを書くのが大変(文章の整合性、伝える情報の粒度) ・解決までに速度がワンテンポ送れる |
ドキュメントを読む (公式Web, Confluence、Github(README)、Google Drive等の資料) |
・自己解決できる ・シェアしやすい |
・目的の情報を探すのが、困難な場合がある ・情報鮮度が信用出来ないケースがある |
※ドキュメントを読むは、正確には"相談"ではありませんが、解決したい課題があるという意味では同じレイヤーに存在する手法だと考えます。
お察しの通り、どれか一つで解決するのはなく全ての手法を使っていますし、運用ルールしだいでデメリットを解消するようなことも可能です。 また、相談者のコンテキストに合わせて、複数組み合わせることもあります。
どれが良いというのはなくて、相談相手が「選択できる」状態を作っておき、特性にあわせた手法を選べるのが重要と考えています。
また、上記には含めていませんが、Google グループ の「会話」はスレッド的に使えます。オープンにディスカッションできて検索もできるので、お手軽に情報管理するのにおすすめです。
ナレッジマネジメントとは?
「アーキテクト相談」では、相談と回答から再利用可能な情報を抽出しドキュメンテーションしています。
その一連の流れを、ナレッジマネジメントのフレームワーク「SECIモデル」を用いて運用しています。
「ナレッジマネジメント」とは、企業が保持している情報・知識と、個人が持っているノウハウや経験などの知的資産を共有して、創造的な仕事につなげることを目指す経営管理手法*1です。
この管理手法を、技術相談の過程で生み出される情報資産の管理に適用しています。
「ナレッジマネジメント」に関しては、北陸先端科学技術大学院大学 知識科学研究科 梅本研究室の資料が大変参考になります。
SECIモデルとは?
「SECIモデル」とは、ナレッジマネジメントのフレームワークであり個人の暗黙知を組織的な形式知に変換し、その形式知を個人が体験することで暗黙知に変えていくプロセスになります。
そのプロセスにおける、知識変換の流れを4つのステージで表現しています。
それぞれのステージを簡単に説明すると、
- 共同化では、個別の暗黙知を共有し組織の暗黙知として扱えるようにします。
- 表出化では、組織の暗黙知を明示的な言語や図を通じて形式化します。
- 連結化では、形式化された情報を組合わせて新しい形式を生み出したり体系化します。
- 内面化では、整理された情報を使って個人が行動・体験して新しい暗黙知にしていきます。
このプロセスを継続的に回し続けることで、組織的に使える情報資産を作り、個人と組織に貢献していくことが可能になります。
アーキテクト相談の対応範囲
「SECIモデル」はやや難しそうにも見えますが、チームとして具体的にやっていることがイメージできると、意外とシンプルであることがわかります。
- 宛先のない技術相談の窓口として機能し、課題の顕在化を推進する(共同化)
- 課題を整理し、ソリューションを一緒に考え、ナレッジ化する(表出化)
- ナレッジを体系化する(連結化)
- 新しいナレッジの認知を促し、個人が利用できる状態を創出する(内面化の環境整備)
ここから分かる通り、「アーキテクト相談」の責務は単純に相談内容に回答するだけに留まりません。
「SECIモデル」の共同化から内面化までの全てのプロセスに関与します。
では、具体的に何をしているか説明します。
プロセスをスムーズに回せるような環境・運用整備
「SECIモデル」の実践において、相談者や回答者側のルールを整備や、相談窓口の多様化(チャット / オンライン会議 / チケット駆動)など、日々改善サイクルを回しています。
たとえば、
- ナレッジの一覧をどのようにすれば見つけやすくなるのか?
- ナレッジのフォーマットはわかりづらくないか?
- ナレッジ担当の負荷は分散されているか?
- 相談者は質問しづらくないか?
- 効果測定をどのように行うか?
など、考慮ポイントは多岐に渡ります。
そのため、週次の定例MTGにて相談内容と運用改善についてディスカッションし、TRYし続けています。
表面化・連結化における、形式化(ナレッジ化)
技術相談への回答後、そのやりとりからナレッジを抽出しますが、ひとつの相談から複数のナレッジが得られることもあります。
それらのナレッジ候補について、チーム内でナレッジ化の必要是非についてレビューを行います。無駄に全てをストックすることはしませんし、再利用しにくい知識はここでフィルタされます。
ナレッジ化が合意された知識はドキュメンテーションされますが、その成果物であるナレッジもチームによるレビューが行われます。これによりナレッジの質を高めています。
また、ナレッジを検索しやすいように整えたり、そのナレッジ同士の関連を更新していく作業も対応範囲のひとつです。
運用への向き合い方
技術相談および「ナレッジマネジメント」の運用過程において、課題や懸念点も生まれてきます。
ここでは、運用における課題や懸念点について、チームがどのように考え、向き合っているかを紹介します。
回答に時間がかかりませんか?
技術相談(特にチケット駆動)でのやりとりは、全てにおいて決して早いレスポンスが返せているとは思っていません。
提供された資料の読み込みと、回答期待値のすり合わせに時間がかかるケースなどは一定数存在します。
ただし、これらは回答精度をあげるために必要な時間であったりもするので、ある程度は許容しています。
許容はしつつも、それらを可能な限り短くしようとする改善活動は行い続けています。
たとえば、あまりにも回答に時間がかかりそうなチケットは、チケットを分割することで回答者側のアサインを増やす工夫をしています。
仕組みに縛られすぎず、目的を見据えたうえで柔軟に対応しています。
他の技術相談窓口と競合しませんか?
LIFULLではスペシャリティのあるチームが多数ありますので、そういったチームでは相談窓口を開いています。
しかし、それらと競合するとは考えていません。
相談者の質問ドメインが明確であれば、それぞれのスペシャリストなチームが対応するのが、最も適切で自然だと考えているからです。
たとえば、社内のアプリケーション実行基盤チームはSlackで問いかければ数分で答えが返ってきます。その体験は代替できないものであり、専門的な相談に対しては直接聞いてもらったほうが明らかに全員の幸福度は高いと考えています。
逆に、ドメインを定義しにくい相談や、クラウド活用、アプリケーションの設計に関する相談については、「アーキテクト相談」が窓口になるケースが多いです。
ナレッジの効果測定はどうやっていますか?
これはまだ試行錯誤中ですが、その中でもいくつか取り組んできた例を紹介します。
まず前提として、アーキテクト相談ではナレッジをConfluenceに保存しています。
Confluenceとはチーム開発におけるドキュメントのコラボレーションツールです。 非常に多機能で、JIRA(課題管理ツール)と連携するとドキュメントを統合的に管理することができます。
効果測定として、当初はナレッジへの「いいね」の数などが指標の候補になりました。
しかし、もっとわかりやすく直感的なフィードバックをいただけるように、以下のようなアンケートページをConfluence上に作成しました。
ConfluenceではHTML(+css+javascript)を記述することができるので、HTMLマクロでアンケートを作成しています。
ボタンを押すと、そのページのコメントに評価内容を投稿する仕組みになっており、各ナレッジからこのマクロを含むページをインクルードすることで、アンケートを一元管理しつつ、より詳細なフィードバックが得られる仕組みを実現しています。
また、直近では、Google Analyticsを使い、効果測定のための指標を作れないか検証を始めたりもします。
ここらへんは、まだまだ発展途上です。
情報鮮度への対応はどうしてますか?
Confluenceのラベル機能を利用して、見直す可能性があるナレッジを可視化しています。
具体的には、ナレッジに「要ナレッジメンテ」のラベルを付与し、コンテンツレポートテーブルマクロで一覧化しています。
これらを定期的に見直す仕掛けをつくることで、鮮度を保っていきたいと考えています。
まとめ
以上、「アーキテクト相談」という技術相談を通じたナレッジマネジメントの実践について紹介しました。
技術相談については、100社あれば100社のスタイルがあると思います。
それぞれのベストプラクティスを探す旅に正解や終わりはありません。
「アーキテクト相談」への相談件数は前期比で2.8倍になり相談していただけるUUも増加傾向にありますが、まだまだやれることがたくさんあると感じており、今後も改善しつづけ発信していきたいと思います。
我々は、「SECIモデル」を用い "知識の管理"、"知識の経営" を実践していくことで「経営をリードするエンジニア」を体現していきたいと考えています。
新しい季節は人の流れが変化し、技術的な相談事が増える時期でもあります。 そういった機会をチャンスと捉え、「SECIモデル」で社内で使える知識に変えていきたいですね。
弊社の取り組みが、これから技術相談のフローを整備しようとしている方の参考になれば幸いです。
*1:Wikiより抜粋