SC（非公式） Advent Calendar 2018 の二日目になります。尚、本記事は比較的若手エンジニア向けです。

はじめに

自己紹介

5年目のエンジニアです。
2018年はほとんど便利屋的なポジションで仕事してました。
通しで見るとPL業務としてWBS引いたり現場のマネジメントしたり、
モック、設計～開発～テストまでやったり、社外の人との窓口となって対応したり等々...。

本稿の主旨

Qiita記事によくある煽りタイトルにしてみましたが、
残念ながら本稿には、尖ったぎじゅちゅ的な話はじぇんじぇん出てきません。ごめんなさい。

社内システムを例にして、5年目のエンジニアが
課題にぶつかった時にどういう視線で/どのように考え/どう解決していくか を解説する記事を目指しています。
新人をはじめとした若手エンジニアの日々の業務の取り組み方で、少しでも参考になれば幸いです。

本題

さて、2018年7月半ば頃、私が所属する部署では下図のような「KnowledgeShareシステム」なる
Web投稿型の知識共有プラットフォームが開設されました。

開設後1,2ヶ月は普及チームの頑張りもあって、社内知識共有プラットフォームという狙い通り
打合せの議事メモや個人のブログ代わりの記事、技術TIPSなどが投稿されました。

何が問題なのか

知識共有(属人化を防ぐための暗黙知から形式知への転換)が狙いですが、
議事メモとか業務上のタスクに計上されない限り、投稿する人は普段の仕事+αとして時間を割いて
このプラットフォームに記事を投稿することになります。

となると相当な物好き or 承認欲求マンであるか、あるいは相応の動機づけがなければ
投稿が集まらずプラットフォーム自体が活性化しないですよね。

で、普及チームの見解としては動機づけとしての一つの答えが
承認欲求をくすぐる↓の人気ページ(以下ランキングと表記)らしいのですが、、

さてみなさん。
これ、何順でランク付けされてるかわかりますか？？
(人気と言うからには、何がしかの評価基準があるはずですよね)

・・・

正解はこれです。

わかります？黄色で囲ったハートのところです。
とりあえずこのハートマークの横にある数値の降順であることは間違いないようです。

すると、じゃあこのハートマークってなんじゃい！ってなりますよね。私はなりました。
(親指マークがFacebookやTwitterなどのSNSでよくあるLike機能であるのは何となくわかります)

そして困ったことに普及チームからの説明も、サイト上の説明リンクもありませんでした。

こんな不透明な評価軸で「ランキング」って言われてどうですかね？やる気出ますか？

実際画像見て頂ければわかると思うのですが、個人で書いた渾身のブログ記事や知識の棚卸と同等のレベルで
会議の議事録とかが「人気」として評価されちゃう訳です。 ~~皆見たくてその記事を見てるわけじゃないのに~~

これは納得いかねぇですよね。
なのでどういう評価軸でこうなっちゃってるのか暴いていきたいと思います。

ということで、今回は
「KnowledgeShareシステムのハートマークがどのように加算されているか調べる」
事を例に、
「前情報も何も知らないシステムの、とある仕様を紐解いていく」というプロセスを追って行きます。

1. 状態の整理 / 今できること

頭の中で考えたこと

まずは前提として、このシステムについてこの時の私の状態(知らないこと)を整理します。

誰が/どうやって/どのくらいの期間で開発したか等の開発情報(噂レベルでも)
全仕様
どこにデプロイされているか
このシステムに関するドキュメントの存在、及びその保管場所

本当に何も知らない状態です。
ってかここまで何も知らないなら知ってる人に聞けば？って感じですよね。 ~~実際その通りです。~~

ですがエンジニアには往々にして
「誰も知らない」「聞くべき人がわからない」というシチュエーションが発生するのです。
(今回のように大っぴらにすると色々面倒なので、内緒でごにょごにょしたい時とか)

ということで今回は敢えて人に頼らず独力で解決していきます。

やったこと

仕様を知りたいとなれば通常設計書やソースを参照しますが、現段階ではそれらがどこにあるかも分かりません。
なのでまずは手元にあるもの(今回は実際のWebアプリ)で情報をできるだけ集めます。

問題のハートマークの数値ですが、表示されているほかのマークの情報から類推すると、残るは閲覧数が怪しいですね。

ということで試しに複数回同じ記事を閲覧してみました。
が、ハートマークの数値はちょろっとしか増えず、、どうやら単純な閲覧数ではないようです。

その後、記事に対してLikeをしてみたりコメントしてみたりしてポイントの増量を監視した結果、

恐らく

閲覧数　　　⇒1ポイント
Like数　　　 ⇒2ポイント
コメント数　⇒1.5ポイント

といったように重みづけがされており、

ハートマークの数＝ (1 x 閲覧数) + (2 × Like数) + (1.5 × コメント数) etc...

といった感じで、複数のポイントの累計値がハートの数値になっている(であろう)ことがわかりました。

2. 調べる方法の検討をつける

頭の中で考えたこと

手元のWebアプリでの検討が済んだので、いよいよ本格的な調査に漕ぎ出します。
とはいえ何も知らない状態なので、「どうやって調査するか」を先に検討しなければなりません。

そこで、先ほど挙げた4つのわからない情報について整理してみると

誰が/どうやって/どのくらいの期間で開発したか等の開発情報(噂レベルでも)

これが引っかかります。

正直言ってて悲しくなりますが、はっきり言って弊社の技術レベルで
噂が出回らない(ほどに短期間 or 少人数)で、これ程のクオリティのWebアプリをフルスクラッチでできるとは思えません。
となるとGitBucketやRedmine、WordPressのようなOSSを、社内用にカスタマイズして作ったと見るのが妥当でしょう。

ということで社内ドキュメントの場所云々は放っておいて、大元のOSSから情報を得る事に的を絞ります。

やったこと

では早速OSSが出てきそうな、それっぽいワードでググってみます。

「Knowledge Share System」だと検索語句に英語圏の知識共有の学術的な色が強く出てしまうので、
敢えて具象度を上げ(←これ重要)、かつ日本語を織り交ぜた「Knowledgeシステム」でググります。

一件目は広告で「基幹業務～」と出ているので無視するとして、二件目で早速出ましたね。
　※基幹業務システム・・・企業がビジネスを遂行するために不可欠な主要業務を処理する為に用いるシステムのこと
　　　参考) 基幹業務システムとは - IT用語辞典 Weblio辞書

ではこちらのリンクを見ていきましょう。

はい、出ましたね。勝ちました。
弊社に展開されたものと同じロゴ/字体のタイトルがバッチリ出ています。十中八九これを使ったんですね。
ということでOSSならドキュメントもソースもあるでしょう。

これで調査する足掛かりは十分すぎるほどに手に入れました。

...とまぁすでに調査方法が定まった段階までで長くなってきたので
ぶつ切りで恐縮ですが、去年の反省を活かして本日はここまでで、、次回解決編です！

【2018/12/03 追記】
後編です↓
Knowledgeのランキングに納得いかねぇので評価軸を暴いてやった話～後編～