0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術的なことも大事だけど。。。

今回は 「メインは外勤という名の派遣だけど、社内でも受託開発してますよ」 的な会社に勤めている人と 「会社をIT化(DX化w)したいけど、大手に頼むほどの予算はないからと中小のIT企業を選定している企業様」 に少しでも刺さるようなものを書いてみようかと。
※同僚の又聞き的なキーワードをネタにしてみただけですが。。。

どうも、そんな形態な会社に勤めてる、え~すけさんですよ。

発注者の皆様、IT屋に仕事を依頼するときって、、、

システム開発を外部に依頼するとき、だいたい以下を基準に選ぶ企業は多いと思います。

  • 価格
  • 人数
  • 実績
  • 知名度

有名なところに安くやってもらえればそりゃありがたいに越したことないですが、
有名なところは人月単価が高い高い(ホントにその新人みたいな人がその金額分の仕事すんのかよ!?と疑いたくなるみたいな)金額だったり。。。
逆に名前が知られてないのに価格が極端に安いところは、とりあえずの実績欲しさに赤字覚悟の見積もりで出してんのか?と逆にプロジェクトが無事に終わるのか怖くなるようなケースもある。

もちろん、ちゃんとした人材・マニュアルなどを用意してる優良な企業もあるのかもしれないけれど、何の知識もコネもない発注者はそんなのわからないので残念なマッチングにより、使いもしない・使いこなせもしない多機能なシステムを納品されたり、技術・工数不足により欲しい機能が入ってないシステムを納品されたりと、DX失敗みたいなこともあるかもしれません。

せっかくお金かけるんなら失敗したくない!!

「CMMIって知ってます?貴社のCMMIのレベルってどれぐらいですか?」

一昔前にあった「マ〇モ湯」のCMみたいなアレだな。
何年も替えていないと言われているお湯に浸かるくらいなら、2日に1回の入れ替えスパンでいいから「マトモ湯」に浸かりたいね。

「CMMI」ってな~に~(・・?

まぁ正直自分もついさっき聞いたぐらいなので、
打ち合わせでこんなん言われても(゚Д゚)ハァ?ってなるかもしれません。

ざっくりいうと 「個人技じゃなく、組織として安定して開発できる仕組みを持ってるか」 を5段階のレベルでみる考え方らしいです。

レベル 状態 現場の雰囲気
Lv1 初期 個人技頼り 「○○さん休み!? 今日もう終わりじゃん…」
Lv2 管理 最低限ルール化 Redmineだけはちゃんと動いてる。でも運用は空気。
Lv3 定義 標準化され始める 「新人でも最低限は動ける」が実現し始める。神。
Lv4 定量管理 数値で管理 「感覚ではなくデータで語れ」が始まる。急にIQ高そうになる。
Lv5 最適化 継続改善 障害原因を分析して改善まで回る。もはや人類強化パッチ。

レベル別の個人的なイメージ

偏見まみれなので、折りたたんでおくね

Lv1 初期

とりあえず強い人(ベテラン)が全部なんとかする世界。

  • ドキュメントは存在しない
  • 仕様は脳内・コードを見ろ
  • 引き継ぎは口頭
  • 「前任者もう辞めました」

みたいな、
割とIT業界でよく見る光景。

ただし強い人がいると普通に回るので、外から見ると問題が見えにくい。

Lv2 管理

「ヤバい、これ管理しないと死ぬ」

に気づき始めた状態。

  • チケット管理
  • 手順書
  • レビュー

などが生え始める。

ただしまだ、

「運用が人による」

ので、割と事故る。

Lv3 定義

「誰がやっても最低限回る」

を組織として持ち始める。

  • 共通ルール
  • 標準手順
  • テンプレ化
  • 教育

などが整備され始める。

新人からするとかなり助かる。

逆に、この環境にいた人が外勤先として、
何も整備されてない現場(レベル1~2)に放り込まれると、

「見て覚えて」

とかいう、
昭和の寿司職人システムが始まり、辞めたくなる。

Lv4 定量管理

ここまで来ると急に“できる会社感”が出る。

  • 障害件数
  • 品質分析
  • 工数分析
  • ボトルネック分析

などを数値で見始める。
感覚ではなくちゃんとデータで改善し始める。

正直、管理者がここにこだわり出して管理しだしたら、作業者的には超めんどくさい。
分析結果だけを連携してくれればいいから、細かく色々と聞いてくんなよと言いたくなる。

Lv5 最適化

改善が文化として回っている状態。

  • 障害を分析する
  • 原因を潰す
  • 改善を回す
  • ナレッジ化する

を継続できる。

そんなわけで発注者様へ

打ち合わせで、

たくさんシステムを作ってますので大丈夫です(キリッ

って謳ってる企業でレベル3以上を豪語するようなら候補に入れてあげてください。
その際に 「どういったもので、どのような管理・分析をされてるか?」 も追加で確認してください(粗探しw

レベル5で真面目にプロジェクト回してるって言ってくるところ、
過去の実績などを元におそらくものすごく慎重に慎重を重ねて問題が出ないように作業をしてくれると思いますが、
発注者側にも色々と細かな問い合わせやドキュメント作成・記述などを強いられる可能性があるかと思いますので、余裕がないと逆に厳しいんじゃないかという懸念がありますので、どういったフローでどんな作業が降りかかってくるかも確認するようにしていただけると助かります。

開発会社側の言い分的な

発注者側に有意な情報を与えてからこんなことをいうのもアレですが、
まぁぶっちゃけ、大手でもレベル1の企業って結構多いような気がするわけで。

そもそもSESや受託、客先常駐メインの会社で働いていると、たまにこういう人を見かける。

「この人、めちゃくちゃ強いな…」

  • どんな現場でも適応する
  • 仕様理解が速い
  • トラブル対応もできる
  • 顧客とも話せる
  • コードも書ける

いわゆる“強いエンジニア”。

ただ、こういう会社って不思議なことに、

個は強いのに、組織になると急に弱くなる

ことがある。

なぜそうなるのか

理由は割とシンプルで、

ノウハウが会社に蓄積されない

から、要は会社としての強みがない。

要するに普通
要件さえ言ってくれれば(人を集めて)、どんなシステムでも作れるよ。

一見、なんでもできそうな感じで強い感じはするけど、
何が出来るのかがフワッとしてるね。

お客がグッとくるやつ
○○と××の業務の知識あるよ。
それに特化したシステム提案できるよ。
Reactに強いからWebもスマホアプリもイケるよ。
○○システムとの連携とかも実績あるよ。

会社として業務知識があるとか、それにそった提案できるのって強いよね。

個だけで見れば、業務知識も実績も十分あるんだろうけど、
組で見たとき、個に依存しないと何もできなくね?ってならんかね。

特に「個」への依存が高いと「組(会社)」として何を強みに出来るのかが分からないんじゃないかなと。

外勤メイン企業あるある

現場ごとに全部違う

  • 言語違う
  • FW違う
  • 開発手法違う
  • 管理方法違う
  • 文化違う

これは若い時はマジで毎回思ってたけど、
人付き合いも変わるので転職してるみたいな状態になる。
当然、新人がそんな状態になったら所属会社への帰属意識なんかかけらも生まれないことでしょう。

結果どうなるか

各メンバーが、

「現場に最適化された戦士」

になっていく。

これはこれで会社としては強みとなる。
人を派遣するにあたり、出来ることが多い人材は提案しやすいので、営業的にはおそらくありがたいはず。

ただ問題は その経験が所属会社に戻ってこない・還元されない こと。

「属人化」が強くなる

例えば、

Aさん → AWS詳しい
Bさん → Oracle詳しい
Cさん → Angular詳しい

みたいになる。が、、、

「それを会社として再利用できる形にできているか?」

となると怪しくなる。

強い人が辞めると終わる

これ、外勤系企業でかなり起きやすい。

  • 手順がない
  • 標準化されてない
  • ドキュメントない
  • ナレッジ共有されてない

結果、

「あの件、○○さんしか分からないです」

が爆誕する。

そして○○さんが転職する。

終わる。

CMMIの本質

CMMIのレベルを上げるためには、色々と準備だったり意識高い高いが必要なんでしょ?
なんて思ってた時期が自分にもありましたが、結局これの本質って。。。

「誰が担当しても、ある程度品質を維持できるか」

要は、以下が出来てるかが大事って話なのかなと。

  • 属人化してないか
  • 手順があるか
  • 再現性があるか
  • ナレッジ共有されてるか

全部は無理(限界

プロジェクトによってシステムのタイプ(Web・オンプレ・バッチ)変わる・言語変わる・FW変わる・コード管理変わるなどは当然なので、それらをいちいち標準化しようとしてたらキリがないので、まずは出来そうなところから始めてみてはというご提案。

共通化できるものの洗い出し

  • 命名ルール
    →ラクダだ・ヘビだのではなく、論理名・物理名のルール(単語の略し方とか)
  • レビュー観点
    →言語的にこういう書き方は許さん的なアレ
  • 障害対応フロー
    →どのツールで管理して、誰がどう対処するかのフロー
  • ドキュメントテンプレ
    →テンプレ持ってないとか、お客様指定とかが多かったりするけど、自前のテンプレぐらいはIT屋なら持ってろよと思っちゃう。。。
  • 設計の考え方
    →何を考慮して設計するかの考え方など
  • ナレッジ共有方法
    →GitHubにExcelで管理w・Teamsに専用チャンネル作るなど社内の人間が自由に見れる・編集が出来るようなものがいいよね

といった、

「あまり技術依存しない部分」

をまずは揃える。

レッツ、ドキュメント化

「いっぱい色を使って、文字サイズもいっぱい変えて、斜体とかも使っちゃお💕」な 「立派な資料を作ること」 なんかどうでもいいんですよ、そんなの暇なときに自己満でやっておいてください。

大事なのは以下の3つがちゃんと記載されているかだけです。

  • 引き継げる
  • 再利用できる
  • 他人が理解できる

これでレベルが2~3ぐらいにはなれるかもね!!

結局

  • 属人化
  • 技術のブラックボックス化
  • 「○○さんしか分からない」

みたいな状況を減らしていかないと、
組織として継続的に戦うのって結構難しいのかなと。

ただまぁ現実問題、

「そこまで整備する余裕がない」
「まずは今の案件回さないと…」

ってなる気持ちもめちゃくちゃ分かる。

なので結果として、

また今日もどこかで

「すみません、この障害対応できる人いますか?」
「すみません、来月からこのプロジェクト手伝ってください。」

が発生し、

便利屋みたいに色んなプロジェクトへ召喚される、
スーパーエンジニアである私の出番は増える一方であるw

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?