記事の内容
IT業界では、DevOpsという言葉がしばし使われています。
DevOpsはデブオプスと読み、DevelopmentとOperationsを組み合わせた言葉です。
この記事では、DevOpsの概要とDevOpsが日本に馴染まない理由を説明します。
DevOpsとは?
DevOpsの概要
DevOpsは、ソフトウェア開発手法の一つです。
開発 (Development) と運用 (Operations) を組み合わせた言葉で、開発担当者と運用担当者が連携して協力することを意味しています。
でも、これだけでは、抽象的でよくわからないはずです。
もう少し具体的に考えてみます。
上がDevOpsが上手くいっている例で、下はDevOpsではない例です。
どちらがいいかは明白です。
DevOpsが上手くいってる
- ユーザー数が急激に増えたので、サーバーを明日には10台追加する
- チャットアプリに翻訳機能をつけたいから、すぐに実装する!
- ECアプリに商品のレビュー機能をつけたいから、すぐに実装する!
DevOpsではない
- ユーザー数が急激に増えたけど、すぐには対応できないので、一ヶ月後にサーバーを10台追加する
- チャットアプリに翻訳機能をつけたいから、まずはアプリの調査から始める
- ECアプリに商品のレビュー機能をつけたいから、まずはアプリの調査から始める
DevOpsの理想
DevOpsを理解するために、DevOpsの理想論についても説明します。
DevOpsの理想とは、運用者がやりたいと思えば、スピーディに開発者が実装できる体制にあることです。
そうすることで、施策を次々に打ち出して、ユーザー数を増やしていくことができます。
DevOpsの理想に必要なこと
では、このような体制を築くためには、どうすればいいのでしょうか?
実は、方法論とツールは既に確立されています。
DevOpsに必要な技術的な話
- サーバーをすぐに増やせる体制にする
(AWS、GCP、Azureを使う) - 開発者同士でコードレビューをして、全員がコードを理解する
(GitHub) - テストコードを書くことで、新しい機能を追加しても既存のコードを壊さないようにする
(PHPUnit、Minitest) - テストコードを必ず回すようにする
(Circle CIとPHPUnitのようなテストツール) - 人気のプログラミング言語を使って、開発者を集めやすい体制を整える
(PHP、Ruby、Goなど)
DevOpsに必要なチームの話
- 運用者と開発者がコミュニケーションをシッカリと取る
- 運用者と開発者が一つのゴールを目指す
- メンバーが何でも言える体制を整える
(心理的安全性の確立) - サービスが成功すれば、運用者も開発者も利益を享受できる体制にする
(ストックオプション)
DevOpsの現実(悪い例)
ただし、日本で行われている多くのDevOpsの現実は、理想のようにはなっていません。
多くのケースでは、何かしらが欠けていることがほとんどだからです。
そのため、いくら開発をしても、なかなかユーザー数は増えません。
そうして、下記の図のようになって、「運用者」と「開発者」の両方に不満が募ってしまいます。
DevOpsが日本に馴染まない理由
どうして、日本ではDevOps進まないんでしょうか?
簡単に言ってしまえば、IT音痴の人が上にいるせいでで、DevOpsが進まないからです。
その状況をもう少し噛み砕いて説明します。
年功序列
日本は年功序列の社会だと言われています。
それは一部のWeb系の企業を除けば、ITの世界も例外ではありません。
つまり、能力の高い人が上に立つわけではなく、年上の人が上に立つということです。
今までの日本社会では、それでもやってこれました。
なぜならば、シンプルな社会においては、人間の能力の差はたかが知れてるからです。
一日に部品を10個作れる人もいれば、15個も作れる人もいます。
確かに差はあるのですが、その差はたかだか1.5倍です。
でも、それがITの世界になると話は変わってきます。
「1の能力」の人もいれば、「100の能力」の人もいます。
そのような能力差があるにも関わらず、「1の能力」の人が組織の上に立つと、「100の能力」も宝の持ち腐れになってしまいます。
「そんな馬鹿な?」と感じる人もいるかもしれませんが、それが起きているのが今の日本です。
台湾のIT大臣がプログラミングの天才であることは業界では有名ですが、日本のIT大臣はプログラミングのことは何も知りません。。。
従業員のリストラができない
大手の会社では、緊急の時以外には、リストラをしてはいけないと法律で決められています。
そのため、会社は、どれだけIT音痴で生産性が低い人でも、従業員を雇い続けなければいけません。
それは、ITが高度になってきた現代では、非常に辛いことです。
少し前に、富士通が5,000人規模の配置転換を発表しました。
経理や総務のような間接部門で働いてきた人達を、IT部門に異動させてプログラマを育てるという話です。
プログラミングは、そんなに簡単なものではないので、多くのIT音痴が「なんちゃってプログラマ」になっているのではないでしょうか?
富士通で起こったこの出来事こそが、今の日本社会を象徴しています。
諸悪の根源となる受発注構造
「従業員のリストラ」ができないことは、経営者の間では、随分前から問題になっていました。
その対策をするために、日本の会社では分社化が行われます。
例えば、東芝システムという会社がありますが、あれは東芝グループの子会社です。
子会社化することで、いつでも会社ごと倒産させて従業員のリストラをできるような仕組みになっています。
このような仕組みは、多くの会社で見られるものですが、これはシステム構築にも悪い影響を与えてしまいました。
いわゆる、「受発注構造」と呼ばれている悪習です。
受発注構造の何が問題なのでしょうか?
これは、いわばDevOpsの反対の仕組みで、非常に生産性が低い開発手法です。
このようなことを続けてきた結果、日本のIT業界は没落してしまいました。
受発注構造の技術な話
- 納品する時に動けばいい
- サーバーをすぐに増やせる体制にする必要はない
- テストコードを書く必要はない
受発注構造のチームの話
- 開発者は、(IT音痴の)運用者に言われたことだけをやる
- 開発者は、(IT音痴の)運用者に意見を言っても意味がないので、何も言わない
- 開発者は、サービスの利益のことは考えないで、子会社の利益だけを考える
まとめ
この記事では、DevOpsの仕組みと、日本企業ではDevOpsが採用されない理由を説明しました。
「ウチの会社もちょっと怪しいかも?」と思った人は、チーム内でいくつの項目が当てはまるか確認してみましょう。
ちなみに、Web業界ではDevOpsが採用されている会社も多くあります。
DevOpsをやりたい人は、日本の伝統的な会社ではなくてWeb業界に就職しましょう^^
Good luck with your engineer life!
受発注構造がなぜ駄目なのか詳しく知りたい人は、この本を読んでみて下さい。
▼ アジャイル開発について興味がある人には、この記事がおすすめです
-
アジャイル開発とスクラム開発でおすすめの本【2023年最新】
目次1 初心者向け2 中級者向け 初心者向け アジャイルサムライ−達人開発者への道 アジャイル開発の定番本です。 アジャイル開発の心構えや実務のコツを啓蒙してくれる良書です。 いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支え ...
▼ エンジニアの組織論について興味がある人には、この記事がおすすめです
-
エンジニア組織を作る時におすすめの本【2023年最新】
Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス Googleのエンジニア達が培ってきたノウハウが、600ページ以上にわたって書かれた本です。 Googleの現役ソフトウェアエ ...
▼ プロダクトマネジメントについて興味がある人は、この記事を読んで下さい
-
プロダクトマネジメントをする人におすすめの本【2023年最新】
プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで プロダクトマネジメントに必要となる極めて広汎な知識領域について、基礎知識や著名なフレームワークを解説しています。 プロダクトマネジメン ...