情報共有が大事だと思う理由

前置き

私は今の会社に転職してから約4年半ぐらいになります。
主に自社パッケージの開発・保守をしながら、既存顧客に対して要望対応の改修をしたり、新規顧客に対して作り変えたりしながら導入するような開発をしています。

年齢的には30歳手前で、基本的に開発をしていますが、たまにPM/PLをすることもある立場です。

常々、情報の共有の無さ(技術的情報でも会社にかかわる情報でも)に悩まされることが多く、
どういったところで困っているか、また、どうすれば良くなっていくかを整理して共有しようと思います。

参考

まずは情報共有って大事だよね。。。と感じる素になった記事から紹介

• システム開発でドキュメントが必要な理由と、短時間でわかりやすく書くコツ
• システム開発における業務の属人化とは？解決方法は？
• SlackでDMを使わない方がいい理由をGIFにして説明してみた
• 情報共有しない上司がいる職場のリスクとは

情報共有ができていないとどうなるか

とあるプロジェクトにて…

「Aさんじゃないとその作業はできない」「Bさんに聞かないとわからない」...

…果たして本当にそうでしょうか？

まだ開発期間で確定された前提が曖昧な状況ならまだしも、開発が終わって保守に入った後、もしくは他の人に引き継いで新たな開発が始まった後でもそのようなことがある場合、AさんBさんの情報共有が甘いだけでは…？と思ってしまいます。

なにか不具合が発生して、「誰もわからない…さあ困った」というときに颯爽とBさん登場！
(Bさんしか知らなかった情報で)難なく解決！
「Bさん流石だね！」と褒め称える上司

本当にこれでいいのでしょうか？

情報共有ができていないと...

無駄な作業や無駄な人員確保が必要になる

情報が共有されておらず、誰もやっていないからとやった作業が実は別な人が既にやっていて、無駄な作業が発生したり、誰も作っていないからと作ったものが実は他の人が作っていて同じ処理なのにそれぞれ別な実装で作っていて、保守に時間がかかってしまう原因となってしまうこともあります。

また、Aさんじゃないとわからないから…Bさんじゃないと…と無尽蔵に人の確保も必要になってきます。

障害対応のときに困る

Aさんじゃないとわからないから…という状態を放置し続けているときに、そのAさんが不在の時に不具合が起きたとき、別な人がすごく頑張って原因と対応を探すかお客さんに待ってもらうことになってしまいます。
他の人がなんとか頑張って原因を特定して暫定的な対応をした結果、元の担当者の考えと違う修正を行なってしまい、そこでも無駄な作業が発生してしまうかもしれません。

また、接続先の情報すら共有されておらず、その担当者しかわからない場合、ログを見ることすらできないということも有り得ます。
体調が悪くて休んでいたり、気分転換で休みを取っているときに電話がかかってきて共有しないといけない・・・となると聞かれる側も嫌なのはもちろんですが、聞く側も気を遣ったりとお互いに嫌ですよね。。。

品質が悪くなる

整理された情報が残されていなくてソースコードを読み漁ったり、もしかしたら残っているかもしれないメッセージやメールの履歴を読み漁ったりという無駄な作業や、情報を得るための行動に時間の多くを使ってしまうことになるかもしれません。

その結果、本来やるはずだった作業にかける時間がなくなり、動作確認の時間が減ってしまったり、もっときれいに書き直そうと思った箇所がそのままになったりして品質が良くならない原因となってしまうかもしれません。

スキルが上がらない原因になる

無駄な作業時間が増え続けてしまうと、納期までに間に合わせようと残業時間が増えてしまう原因になります。
少し時間に余裕があるときに深く調べようと思っていたことが、全然余裕ができず調べることができず、放置してしまうかもしれません。

また残業時間が増え、プライベートの時間が確保できなくなっていくと、自分の時間を使って勉強を…と思ってもその時間さえ奪われてしまうことすらあるかもしれません。

情報共有がうまくできることで生まれるメリット

上に書いたことの対極にはなりますが、

• 無駄な作業が減る
• 無駄な人員確保が必要なくなる
• 障害対応のときの取っ付きが良くなる
  • お互いに信頼関係が生まれる

また、直接的に「品質が上がる！」「スキルアップにつながる！」とまでは言うことはできませんが、無駄な作業が減ることでそれらに繋がったり、新しいことができる時間の確保につながるかと思います。

なぜ情報を共有しなくなってしまうか/どうすれば情報共有するか

「なぜ情報を共有しなくなってしまうか」を
ここからは実際に自分が実際に経験して、こうだから情報共有が生まれないんだろうな・・・を挙げていきます。

情報共有の仕組みが整っていない

情報共有のためのツール等をただ単に導入して、「はい、じゃあこのツール使って情報共有していってください～」で情報共有不足が解決するものとは思いません。

ある程度のルール策定をしておいて、どのような情報共有の仕方をしていくかの認識合わせをして運用していくのが良いと思います。

例としてざっくり下記のようなルールを決めておいて、運用しながら改善していくのが良いと思います。

• 長期的な情報はWikiのようなツールに記載する
  • 古くなってしまった情報が放置されないように一度書いた内容も適宜見直しを行う
• やったことを記録するのは課題管理ツールに記載する
  • 作業ごとに課題を立てて、作業中に発生した備考等も追記やコメントで書いていく
  • なにかの障害が発生したときの作業履歴/調査内容等も書いていき、後から見直せるようにしておく
    • コマンド等やログの場所等何度も参照しそうであればWikiにも書く
• 短期的な情報はチャットツールで連絡する
  • 打ち合わせの日時連絡等はチャットツールで済ませるが、議事録的な内容は参加できなかった人への共有の意味も含めて残すようにする
    • (課題管理ツールに「議事録」のようなカテゴリ + 課題名を開催日でどんどん溜め込んでいくような使い方でもOKだと思います。)

評価制度の仕組みが悪い

例えば評価制度が

• 新しいものを作ることにたくさん関わっていたら評価が上がる
• 多くのプロジェクトに関わっていたら評価が上がる

というような状態にある場合、

• 後のことを考えて情報を残すよりも新しいプロジェクトに関わることに力を入れよう
• 今が良ければそれでいいや

という風になっているのかもしれません。
(もちろんそれが100%悪いこととは言いませんが、そのような人が増え続けると技術的負債がたまり続け、新しいことに手を出そうにも出せない状況になってしまうことになるかもしれません。)

また、上の方にも書きましたが、意図的に(?)情報を共有せず切り札として取っておいて(?)困ったときに出すことで評価を得ようとしている人が居てそれを会社が許す、困ったときに役に立つ人だと評価するような状態にあれば、それは今すぐにでも辞めるべきだと思います。

得をするのはその人ひとりでそれ以外の大多数は大迷惑だと思っていることもあるかもしれません。

また、赤字のプロジェクトは利益をしっかりと出せているプロジェクトに比べて評価が下がってしまいます。
すると赤字が出ないようにと省けるところ(≒情報を残す作業、他)が省かれて更に情報が残らなくなってしまうという負のループに陥ってしまいます。
そういった「単純に利益がどれだけ出たか？」が評価に直結するような評価制度になってしまっているのも原因の一つだと思います。

情報共有をすることにメリットが無い

例えば実装時に間違いやすいところを先に共有しておいて、しばらくして「聞いてないよー」「見てないよ－」と言われたら、共有した側の人はどう思うでしょうか？

自分なら「見ないなら共有したところで意味ないか・・・」と今後、情報共有を辞めてしまうかもしれません。

逆に自分が共有した情報以上に「もっとこうした方がいいよ！」とフィードバックがある場合にはもっと積極的に共有していこうとなると思います。

情報を共有しない人が居る

これはどっちが先かになってしまうんですが、
組織内に情報共有をしない人が現れる→じゃあ私も共有しなくていいや→じゃあ私もしなくていいや・・・
というように連鎖的に情報の共有をしなくなるケースもあるのかなと思います。

情報が共有されている状態がどのような状態かわかっていない

これもまさに今所属している会社のことではありますが、上層部だけで話が回っていて、下に情報が行き渡っていないことがあります。
上層部は情報のハブ的な状態で「情報共有できてるじゃん！」みたいな状態で、情報が下の方に流れておらず、上層部と下の方で情報に非対称性が発生していることが大きいのかと思います。
それを上層部も受け入れて、どうすれば良くなっていくのかを一緒に考えることができる組織であれば良くなっていくものだと思います。(下からの考えではありますが)

自分なりの理想論を言えば・・・

DMは基本的に禁止

SlackでDMを使わない方がいい理由をGIFにして説明してみたの記事にも書いてある通りで、
個人情報やどうしても発生するシークレットな情報以外はDM禁止として、会社に所属している人なら誰でも平等に会社のことが分かる状態にするのが良いのかと思います。

また、Slackならチャンネル、Teamsならチーム/プロジェクトも可能な限りプライベート設定にせず、オープンにしておくのが良いのかと思います。
通知が邪魔とかそういうこともあると思いますが、情報を受ける側が基本的に見ないようなものはミュート設定にしておく＋メンションがあるものだけ通知が入るようにする(そのためのルール設定)をしてメッセージツールの運用を行うことが重要だと思います。

特定の立場でないと情報を得られないような状態を作らない

私の今の所属の会社では取締役会・役職者会議・商品企画会議...etcのような特定の立場にならないと参加をすることができない会議がいくつも存在し、その情報が議事録等で公開されていることもないので、気軽に情報を得られない状態にあります。

この状態は正直に言うと「今後うちの会社はどういう方針で進んでいくんだろう」「うちの部署の今後のプロジェクトは・・・」というように不安の原因になったり、同じ会社の人なのに情報をすぐに知ることができなくてすごく気持ちの悪い状態です。

心理的安全性も低く、情報が分断された状態からわざわざ情報を引き出しに行くことのハードルもあるので、引き出しにいかないと情報が得られないという状態ではなく、オープンな状態にしておいて必要に応じて閲覧できる状態にしておくことも大切だと思います。
必要以上に情報の得られる範囲を区分けすることで情報の格差が起きやすい状態を防ぐことも重要だと考えています。

やったこと/情報を得たときに情報を残せる余裕を作る

プロジェクトの流れとして大きく以下のようにあると思いますが、

• 要件定義
• 設計
• 開発
• 単体/結合 テスト
• リリース作業

一つの機能開発に2人日かかりそうだから予定として2人日入れるではなく、ちょっと余裕を持たせて2.2人日ぐらいにする、全体の開発で20人日かかりそうなら2人日程度の時間をそのような時間として見積もっておく。

実際に、今所属している会社では合計の作業見積もりの1割程度はバッファとして見ておきましょう、みたいなことをしてはいますが、過去の負債分(情報が残っていないことに加えて潜在バグ等)もあり、1割程度では回らなくなっているのが現状です。

1割程度のバッファを積んだ状態でお客さんに対して見積もり提示したところで納得して発注いただくことはできますが、これが2割、3割・・・と増えて行くと納得されないと思います。
それに自社の責任で発生してしまった技術的負債をお客さんに請求するのもおかしな話です。

今所属している会社では、作業時間の見積もりN人日、1人日いくら(M 円／人日)という金額 N × M 円 の見積もりをお客さんに提出して発注が受けられればその作業期間内で作業を行うような形を取っています。
このため、バッファを1割程度取っていても溢れた分は利益が下がってしまい、なってしまうようなプロジェクトも出ているのが現状です。

負債(情報の不足、ソースコード上のバグ等含め)が溜まっていくと、その先もずっとそれを考慮に入れた見積もりをしなければならず、お客さんに納得の行くような見積もりをするには見積もり工数を少なくするが、実際の作業はそれ以上にかけなければならず、利益はどんどん減っていってしまいます。

そうならないためにも負債を作らない、返済することができるだけの余裕を作る、実際にはスケジュールを立てていくことが重要だと思います。

終わりに

私が今の会社に転職して入ったときにはすでに情報共有ができている組織とはいえない状態にありました。
自分起因の負債ではないのに負債が原因でやりたいようにできなかったり、不当な評価をされて本当に辛い思いをしてきています。

正直なところ、私が今の会社で情報共有の行き届いた組織に変えていくのはかなり難しいと思います。

ですが、会社という大きめの単位で考えるのでは無く、一つのプロジェクト・一つのチーム内であれば良くしていったり、新しく作るチームでははじめのうちからしっかりと共有ができている状態で進めることはできるので情報共有のできるチームづくりをしていこうと思います。

個人の都合で意図的に情報を分断して評価を得て個人が得をするのではなく、会社の利益、社会全体の利益につながるような行動をしていきたい、また、多くの人がそうであってほしいと思います。