Tbpgr Blog

Ruby プログラマ tbpgr(てぃーびー) のブログ

組織改善キックオフ。静かなスタート

f:id:tbpg:20150602021259j:plain

概要

組織改善キックオフ。静かなスタート

読者ターゲット

組織改善をしたいが、なかなか踏み込めない開発者。
組織改善の最中で、他社の事例が気になる開発者。

経緯

2014 年度下期のチームの振り返り、 2015 年度の目標設定などを行うにあたって、
チームの枠を越え、 組織単位の問題点が浮き上がってきました
そこで、組織レベルにレイヤーを上げ問題分析を始めることになりました。
そういった経緯で, 社長・上長・私をコアメンバーとして 2015 年の 3 月中旬から
今まで 全社的な組織改善の準備 を続けていました。
親会社の社長・役員まで巻き込んだグループ会社レベルの組織改善まで話が膨らんでいます。

こういった チーム単位から始まる問題を組織レベルですぐに検討を開始 できることは、
この組織の優れた点でしょう。
実際は制約が多く、 「分かっているけど何もしない」組織 の方が多いのではないでしょううか。

組織がだんだんと大きくなり、 少しずつ積もってきた問題点 が目立つようになり、
今後の成長に向けてこのタイミングで改善を行っておかないと 成長を阻害する要因 になることが
明らかであったことが、 このタイミングで大きな改善に着手することを決めたきっかけです。

そして本日 2015 年 6 月 1 日、ついに 全社展開し正式に組織改善のキックオフ となりました。

詳細は大分先に行う予定の開発ブログが立ち上がった際に行うと思います。
この記事は あくまで私の個人ブログとしての立ち位置 なので、
業務の詳細には立ち入らず、おおざっぱにどんなことをしたかだけ紹介します。

キックオフ

お題

  • モダナイゼーションについて
  • 現状・未来
  • システム開発の失敗の歴史

モダナイゼーションについて

モダナイゼーション 」をキーワードとしたプレゼンテーションを社長・上長がメインで行いました。

モダナイゼーションについては、下記などが詳しいです。
2015年は「ITモダナイゼーション元年」

ただし、厳密な意味での「モダナイゼーション」に完全に沿うわけではなく、

  • 世間で名の通ったキャッチーな用語で意思統一できると分かりやすい
  • 弊社は、堅めの BtoB が主業務であるため、 堅めの業界で普及しているワードを選択した方が響きやすい

という点でのワード選定です。
これは、親会社向けに説明する際に話が通じやすいという利点も考慮しています。

現状・未来

現状・未来について上長がメインで説明を担当し、

  • 現状分析ツリーで組織全体の問題構造を図で解説
  • システムの部分最適化と全体最適化について
  • 手動作業と自動化について
  • モノリシック と Microservices
  • etc, etc..

などについてパワーポイントのスライドと、
図解やグラフを用いた esa の記事で各種説明を行いました。

現状分析ツリーで組織全体の問題構造を図で解説

現状分析ツリーで、問題を図解しました。

システムの部分最適化と全体最適化について

esa の記事を作成し、 Markdown ベースで作成された文書・図解・グラフで説明しました。

社内の各システムの現状について、

  • 各システムの間には様々な重複機能が存在すること
  • 言語選定に一貫性がないため類似機能を別々の言語で別々に実装してしまっていること
  • 同一言語の別システム間でライブラリレベルの共通化がなされていないこと

などを認識共有します。 その上で、

  • 疎結合で単一機能の Microservices 型のアーキテクチャへの移行
  • 利用言語を絞り、 学習コストの軽減・共通化によるコスト減
  • 開発基盤の用意。全体での最適化

などを行う方針を示しました。

手動作業と自動化について

esa の記事を作成し、 Markdown ベースで作成された文書・図解・グラフで説明しました。

現状、 日々の運用に追われて自動化が滞っている箇所 があります。
そういった箇所をそのままにした場合、自動化した場合について、
短期・長期的にどのような結果をもたらすのか想定コストを元に作成したグラフを用い、
お金と紐付けて 想像できるように説明しました。

モノリシック と Microservices

外部のスライド資料をベースに説明。

システム開発の失敗の歴史

esa のスライド機能を用いて私が主担当で説明しました。

内容的には、

で対比しました。

対比の都合上このような形式になっていますが、 アジャイル至上主義ではありません し、
ウォーターフォールディスる意図もありません
あくまで個別に存在する問題の個別の解決手法がアジャイルの手法で説明すると分かりやすかったためです。
実際には、「個別に適用すべき解決手法を選んだら結果的にほぼアジャイルになっていた」ぐらいの
イメージになると考えています。

所感

で、結局どうだったの?というと反応は薄め。
ただ、一部の開発者の方は「 そうだよね~。分かる分かる。 」という声が聞こえてきそうな
頷きをしてくれていたのが嬉しかった。

内容としては、組織の問題点を洗いだし、それをどうやって解決していくかが主でした。
解決手法も技術者から見て魅力的かつ個々の開発者のキャリアとしても
個人の市場価値を大きく高めてくれる内容です。

どちらにせよ組織の問題点ということは自分たちが動いて改善しないと
組織全体に影響を与えてしまうので、 やらなければならないこと のはずなのですが。
その辺りが今日の時点ではうまく伝わりきらなかったのがとっても残念です。

私はサポート的な立ち位置で協力していましたが、特に社長と上長は組織全体のため、
つまり今日集まっていただいた全ての人のために相当の労力をかけて
必死にやってきた内容への反応が薄く、心中察するに余りあります。 (表面上は反応がないけど、実は「イイ!」って思ってくれてるかもしれないですけど)

その後、社長・上長・私の三人で反省会をして今後について
脳みそ振り絞って考えたりしてました。
めげたけど、めげずに行きたい と思います。