やりたかったけどやれなかったこととか

ぼちぼち今の組織を離れるので、個人的にはこういうことをやりたかったけど、力及ばず出来なかったこととかをまとめてみる。異論は認める。
ただの個人的な反省で決して特定の誰かに向けたあれこれではないので悪しからず。

■プロデューサー、ディレクター編
・GAを最低限触れるようにする
　・メモ機能によってリリースと数字の変化を一覧できるようにする
　　・現状だとエクセルと、一覧性の低いプロジェクト管理ツールを比較しないといけない
　・セグメントや検索を最低限理解して自身で分析出来るようにする
　　・現状だと別チームにいちいち数字を出してもらう必要がある
　　・施策を考える際にも、ちょっとした数字の変動を追うときにも大変有用なので持っていて損はないスキルだと思っている
・自身のサービス、もしくは競合サービスでもいいので日常的に使ってもらう
　・非ユーザーがユーザー視点で物事を考えられるほど豊かで的確な想像力を持ってる人はそうそういない（僕にはできない）と思うので、やっぱり純粋にいちユーザーでもあったほうが、何がユーザーメリットで何がユーザーストレスになるのかの判断が適切に出来るはず（もちろん偏ったユーザーになる可能性はあるのでその考慮は必要だとは思う）
・数字を疑う
　・提示された数字を容易に信じず、ソースを明らかにする
　・集計が間違っていたり、そもそも定義が想定と異なるようなことは往々にある
　　・疑わしき数字は集計方法を明らかにし、初めて抽出した数字はどんな条件で加算されるものかを明確にする
・効果が計測可能なものか事前に確認する
　・やったけどそもそも効果追えません、みたいなのを無くす
　　・開発者の納得にも繋がる
・案件を実行する前提において、想像を減らす努力をする
　・ふんわりこういう理由でこうなってる気がするからこうしたい、ではなく、根拠となる数字を出来るだけ出して、想像との合致を確かめ、最終的にその数字が向上したかどうかを追っていく
　・こんな感じのことしたらいいデータが作れそうだから作ってリリースして、ではなく、実際にそのロジックで結果を出してみて、想像通りか、有用か判断し、その上で実装するか否かを決める
　　・めっちゃ頑張って作ったけど効果なかった、みたいな悲しみを生まない

■組織全体編
・現場にもうちょっと裁量権を与える
　・開発効率の向上は開発に携わってる人間の方が理解があるので、進め方は基本的に一任する
　　・問題がある場合は決めるというよりは改善方法を決めさせる
・施策や競合の動きに関して議論する場をつくる
　・プロデューサーやディレクターはもちろん、チーム全体でこういう議論ができたらよりよいアウトプットが期待できそうだけど、様々な問題からこういった場が殆どつくれていなかった
・目標設定の適正化

他にも多分色々あるけど。
次にサービスに関わることがあったらもっと頑張らないとなーという自戒も込めて。