問題意識の共有について

f:id:razokulover:20131102002030j:plain

「新しい仕組みを導入したい！」と思っていてもただ導入したいというだけなら要望は通らない。 例えば「フレームワークをRailsに変えたい」とか「Gitを導入したい」とかだ。 巷で利用されているイケてる開発手法やツールはとても便利だし、使いこなせば開発効率が劇的にあがる。

しかし、どのチームにもチームごとのカルチャーがあり、少し古い企業ならばレガシーなコードも多いはずなので簡単に導入とはいかない。

その現状を無視して、最新の技術を導入したいと述べるだけでは誰もついてこないのは目に見えている。

以下では、こうした現状のシステムに新しいシステムを導入したり、またはリプレースする際に 考えなければならない点をまとめてみた。

考えるべき点は3つになった......






という書き出しで、偉そうに語ろうと思ったけれどもやめた。





理由は、そんな仰々しくまとめるほど難しい話ではなかったからだ。

うん、重要なのは１つ。

『問題意識の共有』

ただこれだけ。

そこにいる人すべてが同様に問題を感じていなければ新しいシステムなんて導入できっこない。

選挙だってそう。選挙にいかないのは選挙に行かないことに問題を感じていないから。

誰だって普通は問題を感じなければ動けない。

だから問題提起をして人をまきこんでいける人は尊敬する。

どんだけ精力あるんだ。

僕は精力の乏しい若者なのでまきこむ力がない。

ただ、それなりに考えてみた。それが以下のような駄文メモ。

冒頭で３つあると書いたのは当初、そのようなエントリを書こうとしたから。

でも、結局やめた。

書きかけだけど晒す。







①現状の課題

  • 現状抱えている課題をあげる
  • 自分が抱えている問題でも誰かが感じている問題でもよい
  • 課題なしに提案はありえない、というかそれ、ただのわがままだ。

②【重要】問題意識の共有

  • 洗い出した問題がチームの誰もが感じているなら解決への道は近い=実現できるかも
    • 協力が得られる
    • 目的がはっきりしているのでモチベーションが落ちにくい
  • ただし、自分しか感じていない問題なら自分ひとりで解決まですべてやらないといけない。通常業務と並行でやるのはつらい。
  • なので、問題を誰にでも共感してもらえるレベルまで抽象したり逆に各人の身近な事例を例にしながら提案する。
  • これができないのであればそれは問題として影響力の小さい問題なのでチームレベルでやるのは難しい

③問題の解決法

  • ここのフェーズまでくればあとはやるだけ。
  • 最も(チームにとって)効率の良い方法をとる
  • プログラミングで言えばコードを書くだけの段階

具体例

※これはフィクションですよ！たとえ話です。

PHPのバージョンアップ+Laravel4を導入したい

会社でLaravel4を導入したい。最近盛り上がってきてるし。でもいきなりフレームワークリプレースとかむりぽ...。 そもそもPHPのバージョン的に非対応...。移行コストとか今やる必要ある？とか正論だよ...

現状の課題

  • PHPのバージョンがサポート切れなので便利ツールが使えない
  • 膨大なcontroller,model,viewがテストなしで運用されている
    • ソースを追いにくい
    • 属人的なアプリが生まれる
    • 今後さらにコードが増えていくと限界がくるのでは...
  • テストを考慮してコードが書かれていないのでテストコードが書きにくい+導入しにくい
    • テストがなく、変更した機能の影響を調査するのに時間がとられる。自分が追加した機能で振る舞いがどう変わるのか、tail -f logファイル + f5でしか確認できない。
  • CI？ほぅ...

問題意識の共有

  • 現状問題なく運用できてる（人が多い）ので問題だと思っている人が少ない
  • テストがなくてもなんとかなってるし、むしろ書くことが増えるので負担増
    • =>問題意識が低い
    • =>問題意識を共有する術を考える必要あり

【施策】

秘伝のたれを続けた末、すでにメンテナンス困難になっている社内ツールを例にする

  • そのツールのバグの多さやメンテナンスしづらさは誰もが知っている
  • 「今はメンテナンスできてる」がずっとつづくと思うな的アピール
  • リプレースするとしたらいくらかかるか?高いよね？

問題の解決法

  • メンテナンス性をあげましょう！膨大になったコードを一度整理しましょう！
    • =>PHPのバージョンアップ
      • 今までバージョンアップすらできなかったライブラリ郡をcomposerで依存管理できるようになる。
      • メンテしやすい！
    • =>Laravel4
      • テストが導入しやすい
      • 今まで利用していたフレームワークの後継なので学習コスト低い
      • フレームワークごとcomposerで管理できるのでバージョンアップも基本的には難しくない
      • 便利機能たんまりあるで...
      • どうせコードの整理するならより便利なフレームワークでもいいのでは？

補足

この具体例では、強引な感はあるけど伝えたいことはわかってもらえるはず。

少なくともアクションとしては十分だ。

最後に

ここまでやっても聞き入れてもらえない場合は自分に問題がある。 だから、まずは最低限やるべきことはやるようにする。ある程度信頼は必要だし。

ただ、どう振り返ってみても自分に非が無いなと感じるなら会社がくそな可能性あるので辞めよう。







くそなメモだ。これ単体でエントリにしてたら集中砲火受けてた気がする。

「くそまとめ乙」と。

何が言いたかったかよくわからない散文になったけどやっぱり言いたいのは一つで

『問題意識の共有』は大切だ、ということ。それだけ。

そう言えば、先日ロリポに転職した人のブログだったかな？

ここにはレガシーなコードがたくさんあるけど、同僚みんながそれを改善しようという意思がある。だからやっていけそう。と。

それこそが問題意識の共有。

ふぅ。メモっぽい文章終わり。