暗黙知を作るな、すべてを形式知に変えよ

前回は、Sqwiggleを活用したリモートワークやGitHubを活用した開発について述べました。

開発プロセスは、まあアジャイル開発っぽいですね。アジャイル開発というか、スクラムで求められている他のプラクティスについて、KAIZENのリモートワークではどのようにやっているかをもう少し説明すると、まずデイリースタンドアップ、いわゆる朝会です。リモートでやってるので、スタンドアップといいつつ立ってはいないんですけど (笑)。

朝会は、チームメンバーそれぞれが持つタスクの進捗状況に関して、互いにコミュニケーションを交わすスタイルでやっています。それをビデオ会議で、リモート越しにやる。

毎日時間を決めて固定のGoogle Hangout URLに集まるようにしています。チャットBotが朝会の時間になるとURLを知らせるなど、みんなが忘れないような工夫もしています。

朝会で話した内容は、Markdownでその場でテキストにしていって、その議事メモを、すぐにプログラマのための技術情報共有サービス「Qiita Team」に上げるようにしています。

朝会以外だと、振り返りのため会であるKPT。これは日時を決めて割としっかりやっていますね。アジャイル開発においては、定期的に開発プロジェクトを見直し自分たちのやり方が間違っていないか、おかしなところがあったらそこをどう直していくかということが何よりも大切で、KPTはそのための良い機会になっています。これも議事録をとって、すぐにQiita Teamで展開する。

ところで、議事メモを取ってQiita Teamで共有みたいな話が多いですが、重要なのは、組織の中では暗黙知をできるだけ作らない、すべてを形式知に変えていくという態度だと思ってるんです。ここでいう暗黙知は、言葉の定義通りの暗黙知というより「誰か特定の人しか知らない知識」とかそれぐらいの意味ですが。

普通の開発チームでは、仕様書みたいな絶対残さなきゃいけないドキュメントは、まあ誰でも残しますよね。ところが、普段の開発の相談ごとは口頭での会話や、よくてもチャットを通して進められることが多くて、そういうことは全くどこにも残ってなかったりする。

口頭で決めたことは、そのままでは他の人に伝わらない。決めた本人たちはそれは大した問題ではないと思うのでしょうが、そうした積み重ねが、やがて「あの仕様の背景がわからない」とか「そんな話一度も聞いてない」とか、そういうことに繋がっていくんです。

この点でいうと、僕はテキストにできるものは全部残したほうがいいという考え方なんです。

特に、仕様書のようなストック的な性格の文書と、チャットでの会話のようなフロー的な性格なものの間にあるもの──例えば、会社としての開発の方向性がこのように変わっていったとか、このプロダクトの仕様はなんでこうなっているのかとか、そういう議論や思考の痕跡ですよね。

これも含めて残していくことはとても大切なのに、そこがすっぽりと抜けていることが意外と多いんです。

日報や作業ログも全部、情報共有ツールに入れておく

全部残すんだよといわれても、そういう習慣がない人にはピンと来ない。こういうことは個人だけじゃなくて、組織として意識していないと、習慣化されないものだと思います。

KAIZENも最初はそうでした。しょうがないから、Qiita Teamを入れて、そこに自分が日報とか作業ログとかを一人で書いていました。「Webサービス作ってる会社なんだから、Webサービスを駆使して仕事したいよね」ということなんですが、「使おうよ」と口で言うだけでは、誰も使わないんですね。

それはきっと、こういうツールを使った成功体験をみんな知らないから。僕の場合は「はてな」でこういうものを使ってうまくいった経験があった。

「はてな」で僕は7人目の社員だったんだけれど、会社に入った初日、社長の近藤淳也さんに「思ったこと、気づいたことは、メールを使わず、全部“はてなグループ”に書いて」と言われました。そういう文化が僕が入る前からあった会社なんです。

はてな出身のエンジニアがクックパッドやペパボ（GMOペパボ）に転職してから似たようなツールを開発して情報共有をしているとか、「はてな流儀」の伝播じゃないけど、そういう広がりもあるみたいです。

各社のエンジニアがどういうツールを使って情報共有を進めているかという話は、6月にGitHubユーザーグループ主催でやったイベント「GitHub Kaigi」でも盛んに話題になっていましたね。

最近は、KAIZENの社長（須藤憲司氏）も、週末に家にいて気づいたことを、Qiitaに書き込むようになりました。社長さんは家にいながらも会社のことを常に考えているわけです。

ただ、そのままにしていると、月曜日になると忘れちゃうとか、せいぜい役員会に伝えるだけで終わってしまう。それをQitia Teamに書くようになった。こういう小さな企業では、社長が何を考えているかというのはみんな知りたいものなんですよ。本人が当たり前のように思っていることも、周囲の人間にとっては全然当たり前じゃないんです。

こうして、創業者のビジョンとか、経営の意志決定のプロセスもきちんとテキストに残しょうということ。こういう文化はとても大切だと思います。

「許可を求めず、謝罪せよ」という行動哲学

その中からKAIZEN流の行動哲学が生まれてくるようになりました。その一つに、「許可を求めず、謝罪せよ」というものがあります。これはオープンソース (OSS) プロジェクトの重要な哲学でもあります。

OSSプロジェクトでは自分が欲しいコードは自分で書きなさい。必要以上に議論をするより、コードを書いて見せなさいという考え方がありますが、「許可を求めず、謝罪せよ」もその延長ですね。

企画の段階で会議を開いて、ああでもない、こうでもないなどと延々と議論していると、結論がすごく凡庸で、ちっちゃなものになってしまうことって、よくあるじゃないですか。

最初に思いついた段階ではめちゃめちゃ個性的な味のラーメンが、万人受けするためにとか考えていくと、どこにでもあるつまらない味になってしまうような。

個性的な味のまま、まずはいっぺんお客さんに出してみればいいんですよ。それが大評判になるかもしれないじゃないですか。まあ、誰にも受け入れられなかったら、そこで謝って作り直せばいいわけでね(笑)。

僕は、大組織でよくある承認フローっていうのが苦手なんです。今から自分とやろうとしてることは、まあ話しただけでは反対されるだろうな、でも結果が出たらみんなわかってくれるはず、そんな風に思うことが多いから。だいたい、マネージャーやってるとマネジャーの僕のところに「承認お願いします」というリクエストがいっぱいくる。あれがめんどくさい (笑)。

個々のプロジェクトの細かいことなんて実際にはわからないんだから、困っちゃうんですよ。承認を求めるぐらいだったら、プロトタイプでも作ってみて判断したらいいんじゃないって。

僕らが使うツールについても、これは言えます。人間って間違っている道具でも、それに慣れているとそのまま使い続けるということがありますよね。僕らのように新しい技術に取り組む会社でも、気づいたらとても古くさいことをやっていたりすることがよくある。

そういう「間違ってるとわかっていても使い続ける習性」というのは時々壊してあげる必要がある。そうでないとなかなか進化しないのです。

ただ、いざ変えるとなると、それに抵抗する人も多い。人間は本能的に、変化することに抵抗してしまう生き物なんです。だから、みんなで話し合うとかならず反対意見が出る。全員が賛成するまで変化を起こすことができないと言ってると、なにも変えられない。だから許可を得ずにまずは壊すこと、壊し続けていいんだよ、ということを組織の文化にしようと思って、そういう行動哲学を掲げています。

OSSプロジェクトもそうですよね。「このソフトウェアにこういう変更を加えて良いですか?」と問い合わせるのではなくて手元で実装を作ってみて、Pull Requestにして送る。それが良ければ採用されるし、そうでなければリジェクトされる。それでいいんです。

この話はまあ、OSSプロジェクトっぽい考え方ということのひとつの例ではあるんですが、たとえばソースコードを変更するときにどんなワークフローでやるとか、考え方だけでなく、実践的なプロセスもいろいろと OSS のそれに寄り添う形で参考にしています。

伊藤直也が語る「仕事の流儀」　記事一覧

第1回「KAIZENでの開発体制をKAIZENする」 第2回「スタートアップ企業にリモートワークツールを推奨する理由」

伊藤 直也氏
ニフティ、はてな取締役CTO、グリー統括部長を経てフリーランスとして活動。ブログやソーシャルブックマークなど10年間、ソーシャルメディアの開発と運営に携わる。
著書に『入門Chef Solo』(達人出版会)『サーバ/インフラを支える技術』『大規模サービス技術入門』　(技術評論社) など多数。2013年9月よりKAIZEN platfrom Inc. 技術顧問。
GitHub：@naoya Twitter:@naoya_ito

CodeIQコード銀行にあなたのコードを預けてみませんか？

• CodeIQコード銀行ではあなたのコードを財産と考えます。
• お預かりいただいたコードは、CodeIQコード銀行がしっかり評価し、フィードバックいたします。
• 当コード銀行にお預けいただいたコードは、企業がみてスカウトをかける可能性があります。
• 転職したい方や将来転職することを考えている方で、今の自分のスキルレベルを知りたい方はぜひ挑戦してみてください。
• 企業からスカウトがきたら困る人は挑戦しないでください。

興味を持った方はこちらからチャレンジを！