ドッグフードを食べるのはマネージャから
あまりマネージャの仕事は見えないことが多い。職位上の仕事が主になるから、そうなるのは当然なのかもしれないが、全てがロールの仕事という訳でもない。事業会社なら、担当の業務テーマを持つし、SIerでもプレイングマネージャもあるだろうし、プロジェクトを組織化したチームのマネージャならプロジェクトも兼任することもあるだろう（実際ある）。
プロジェクトのプレイングマネージャを兼任する場合はメンバにマネージャの仕事ぶりを見せることができる。これは、マネージャの情報の整理やロジックの組み立て方、ファシリテーション、意思決定などのマネージャ自身の価値観をチームに見せられるので、良いと思っている。良いお手本か、反面教師なのかはメンバが勝手に判断すればいい。
メンバはエンジニアだから、いやマネージャもエンジニアなのだが、新しい手法やツールをマネージャが率先して使うと、メンバがマネージャの仕事に興味を持ってくれる。いや、興味の先は、手法やツールなのだが、業務の課題解決で使っているので間接的にそうだと思うことにする。
特に技術に詳しいエンジニアは何をやっているかを覗きにくる。officeのwordをやめて今風のマークダウンに書き換えることをやっていると話すと『それはgithubに置けますね』なんて言ってくれる。ターミナルを開いてあれこれやり始めて、クライアントを入れろと言われて気づくとpipelineまで設定して、ドキュメントがpdfやepubに出力される環境を作ってしまう。
もともとPCでやれていたが、そうすることで、ドキュメントの一元管理はもちろん、構成管理も版管理もできるし、ファイルサーバからも抜け出せるし、officeからも一連のドキュメントは抜け出せる。wordだとスタイルをいくら設定して使っていると、誰かが更新した折に亜種のスタイルを作ってしまい全くスタイルが意味をなさないことがある。cssがあるのでどう頑張っても同じ体裁になるメリットもある。
これを非エンジニアにどう使わせるかという新たな課題が生まれた瞬間であるのだが、得られる物の方が大きいそうだ。
マネージャや経営者がバズワード（手法の名前）をやろうと言ってくるほどやばい案件はないのは誰もが先刻承知のことである。現場をモルモットにするのは本人たちから言ったのでなければ効果を測定できないからやめた方がいい。新しい手法やツールを入れたいなら、マネージャ自身がドッグフードとして自分で食べなければいけない。
実際、食べてみると実際やりたいドキュメントの移植からマークダウンの記述を調べたり、LaTexの先っちょを調べることになったり、思うように行かない（仕様だと気づいたり）することがあって大変学びが大きい。
そう言ったこともマネージャ自身が実験台となって見せられる。これ以上に良い教材はないと思うのであるが、やはり反面教師的かもしれない。
