お金が返ってくるオンライン英語レッスン・Lingoda Sprintを3ヶ月走りきった

英語 教育

はじめに

2020年の4月から3ヶ月間、1回1時間の英語のレッスンを週4~5のペースでやりきったので、熱が冷めないうちにやってみての感想を書いてみようと思い、1年以上ぶりにブログを書いてます。

書いてる人について

英語に苦手意識を持っている28才の男
ソフトウェアエンジニアとして働いています。

Lingoda Sprintってなに？

Lingodaというのはオンライン言語学習サービスのことで、 ドイツにあるLingoda社が提供しています。
日本語でのサービス紹介やプロモーションはまだやっていないようで、国内の認知度はそこまで高くなさそうです。
対応言語は英語、ビジネス英語、スペイン語、フランス語、ドイツ語の5種類です。

Lingoda SprintというのはLingodaが提供するサービスの1つで、3ヶ月間一定のルールに沿って英語のレッスンを受けるとお金が返ってくるサービスのことです。

Lingoda SprintにはSprintとSuper Sprintという2種類あり、それぞれ内容や返ってくるお金の割合が異なります。

  • Sprintは1ヶ月に1回1時間のグループレッスンを15回 x 3ヶ月やりきると受講料の50%が返ってくる
  • Super Sprintは1ヶ月に1回1時間のグループレッスンを30回 x 3ヶ月やりきると受講料の100%が返ってくる

受講料が返ってくるにはSprintもSuper Sprintもクラスは1日1つまでしか受けられない制限があるので、Sprintは2日に1回・Super Sprintは毎日レッスンがある感じです。

なぜLingoda Sprintに参加したのか

私は英語が昔からあまり好きではなく、やらなきゃいけないのは分かっているが、苦手意識がありなかなか勉強が進まない状態でした。

一時期はスタディサプリのTOEICコースを使用していたこともありましたがあまり長続きせずやめてしまいました。 またListeningとReadingよりもSpeakingとWritingを大学卒業以来(正確には大学3年くらいから)全くやっておらず、正直危機感を感じ始めていたため、英語の勉強をしようと思って始めたのがLingoda Sprintでした。

もともとLingodaというサービスは全く知らず、たまたまYoutubeで海外の英語系Youtuberの方が紹介していたのをみて知った程度で、 お金が返ってくるんだ！ラッキーくらい軽いノリで始めました。

Lingoda Sprintに参加してみて

英語のレベルについて

LingodaではThe Common European Framework of Reference for Languages (CEFR) (ヨーロッパ言語共通参照枠) と呼ばれるガイドラインが出しているレベル分けにならってレベル分けがされています。 レベルはA1, A2, B1, B2, C1とあり以下のようなレベル感になっています。

レベル レベル感 TOEICでいうとこれくらいの点数
A1 初学者 225未満
A2 初心者 225くらい
B1 中級者 550くらい
B2 準上級者 785くらい
C1 上級者 945くらい

※CEFRとTOEICのレベルの紐付けはこちらを参考にしました

Comparison of CEF levels of English language exams: IELTS, TOEFL, TOEIC, Cambridge ESOL (CAE, FCE, PET, KET, CPE, BULATS, BEC), PTE and Michigan Test.

レベルは事前にこちらのテストを受けて自分のレベルにあうコースを選択します。

私はB2レベルだったので、B2レベルの英語レッスンを3ヶ月受けていました。

レッスンについて

レッスンの内容

Lingodaでは先生と1対1のプライベートレッスンと先生一人に対して生徒が3~5人程度いるグループレッスンの2種類があります。 Sprintのレッスンは全てグループレッスンでした。

事前にLingodaの予約画面から自分の都合の良い時間で絞り、受けたいレッスンを選んで予約します。

レッスンは全てZoom上で行われました。 レッスンが始まる時間にマイページからZoomのリンクを開きそのままレッスンに参加する感じです。

LingodaではレッスンがGrammar, Reading, Writing, Speaking, Skillsの5つに別れており、全てのレッスンにテーマとPDFの教材がついています。

例えばGrammarレッスンだと"The Past Perfect(過去完了形)" とかReadingだと"Feng shui and Zen(風水と禅)" みたいなテーマ別のレッスンがあり、5種類をバランスよく受けていくことで英語の総合力をあげていくようなレッスンになっています。

f:id:tofu0511:20200708225225p:plain
レッスンの一例、中には「動物園は道徳上正しいか？」といった題材でディスカッションするクラスもあります

レッスンの内容はかなりしっかり作り込まれている印象です。 基本的にどの先生も教材に沿って進めるのであまり外れのレッスンや内容が薄いレッスンはありませんでした。

むしろ事前に単語の意味を予習しておいたり、テキストの内容を把握しておかないとついていくのに厳しいレッスンもありました。

参加者について

私は平日の19時から23時くらいでレッスンを受けていました。 それらの時間帯では台湾・香港・ロシアの方と一緒にレッスンを受けることが多かったです。
中にはサウジアラビアやベラルーシ、ボスニアヘルツェゴビナ、コロンビア出身の方などもおり、かなりグローバルな環境でした。(小並ですが世界の人と繋がれてインターネットってスゲー！って思いました。)
日本の方はLingodaがあまり有名じゃないからか、3ヶ月のレッスンで3,4名くらいの人しか見かけませんでした。

英語力については基本的にレベル分けがされているので明らかにレベルが合わない人が参加することはありませんでしたが、英語の発音は出身国によって特有の訛りがあり、言っている事を理解するのに苦労することもありました。（特に生徒同士でディスカッションをするようなクラスだとめっちゃ集中しないと何言っているか分からないです）

先生について

他の英語サービスを知らないので比較はできませんが、Lingodaの先生のレベルは高いと思います。 基本的に全員英語はネイティブスピーカーで英語を教えた経験がある人(オンライン・オフライン)しかいませんでした。

中にはもう10年以上ある航空会社のパイロット向けに英語を教えているようなベテランの先生もいました。

レッスンの進め方は先生によってまちまちで、参加者を順場に当てていく先生もいれば、ランダムに当てていく先生もいて、進め方はある程度先生に任されているようです。（ただ教材はLingodaのものを使う）

先生によっては発音や文法のミスをちゃんと指摘してくれる先生もいれば、ある程度は流す先生もおり、この辺りも先生によって異なる感じです。 日本人あるあるだと思いますが、私はLとRの発音でよく指摘を受けました。

ちなみにレッスンの先生は事前に変わる可能性があります。 Lingodaではレッスンの予約はできますが、予約時の先生が変わってしまっても再予約などはできない(キャンセルすると予約してから30分以内じゃないとクレジットが返ってきません)ので注意してください。

レッスンを受けてみて

Sprintをはじめてから数年ぶりに英語で他者と会話をしたので、最初は自分が言いたいことをいうのにだいぶ苦労しました。 単語が出てこなかったり文法が出てこなかったりするのは当たり前で、事前に少し準備していないとレッスン始めたては全然中身のある会話をできませんでした。

しかし1ヶ月くらいたつと少しずつ英語が出てきたり、準備しなくても少しは自分の言いたいことが言えるようなってきました。今まで1ヶ月以上スピーキングやライティングを集中して学んだことがなかったのですが、1ヶ月で上達を体感できて英語学習を続けるモチベーションが湧いてきた事を覚えています。

また毎回知らない人と一緒にレッスンを受けるというのも自分には良い点でした。 よく知る人や友達と英語を話すのって少し恥ずかしくないですか？ 発音や文法が間違ってたらどうしようとか余計なことに気がいってしまって英語学習に集中できないことが学生時代は多かったのですが、Lingodaでは毎回違う人とレッスンを受けるので、そういった変な恥ずかしさみたいなものを感じずに進められたのは始める前は想像もしていなかった点でした。

ただ何よりも良いのはやはり返金制度がある事です。 正直返金制度がなければ途中でレッスンをサボっていたと思います。モチベーションがわかない時も、「今日のレッスンに出ないとお金が返ってこない」と思うと渋々レッスンに出るようになり、レッスンに継続して出る事で上達し、モチベーションが上がるという良いサイクルになっているとてもうまいサービスの設計だと思いました。

今回のLingoda Sprintに参加して1番の収穫は英語力アップそのものよりも英語学習に対しての抵抗感がなくなったことかもしれません。

Sprintの結果は？

Sprintの結果は参加者が多いので9月ごろ?に結果が出るそうですが、1回だけどうしても仕事の都合で参加できないレッスンがあったので返金はおそらくされません😭

しかし英語学習の抵抗感を無くしモチベーションをあげてくれた事を考えると返金がなくても十分良いサービスだったと思います。

今後の英語学習はどうするか

今後はだいたい下記の方針で英語学習を進めていこうと考えています

  • Mediumで気になる記事を読んで英語で情報のインプットをする
  • Software Engineering DailyやYoutubeで生の英語を聞く
  • Lingodaが知らない間に課金されていたのでレッスンは週1~2回ほどの頻度で継続する
  • Brightureというオンラインのサービスを使ってみる

実はBrighture代表の松井さんに英語学習相談をして上の方針を決めました。

松井さんからは生の英語(試験の教材のように殺菌されていない英語)に触れてインプットをすること、日本人にしては単語発音が良いが逆に音のつなぎはもっと上達できること、仕事で英語を使うならしっかりとしてWritingが重要との3つのアドバイスをいただいたので、上の方針で進めていこうと思っています。 (ちなみに発音は昔英語耳という本で練習したのでそこそこ発音はできるようになってました)

Lingodaでは(特に)英語を書く機会が思っていたよりも少なかったのと、発音や文章を流暢に読むような練習をするレッスンはなかったのでこれらを鍛えるためにBrightureを使ってみようと思っています。

Lingodaを使ってみようかなと思った方

Lingoda Sprintをやってみようと思った方

返金されるには守らないといけないルールがあるので事前にしっかり読む事をオススメします！ レッスンは1日1回までなど学習を計画を立てる上で必要な情報があるためです。

またSprintやSuper Sprintは取らないといけないレッスンの数が決められていますが、レッスンの予約が取れることは保証していません。 レッスンを受けたい時間にレッスンがあるとは限らないので、学習のための時間がしっかり取れるか確かめたのちにプランを決める事をオススメします。

Sprintじゃなくてとりあえず試したい方

Lingodaでは登録すると7日間無料でレッスンを受けられます(グループレッスン3回 or プライベートレッスン1回)

登録時に以下のコードを使うと50ユーロ(6000円くらい)分の割引があるのでよかったら使ってみてください

43vcme

最後に

3ヶ月よくやった！えらい！

これからも頑張るぞ💪

ソフトウェア開発とリーダーシップ

組織 エンジニア

はじめに

この記事はただの集団 AdventCalendar PtW.2019の10日目の記事です。
昨日はInaさんのパターン部分一致の文字列検索 でした。

GoogleやSalesforceの世界を代表するIT企業のエンジニアには、技術力そのもの以上にリーダーシップが求められるし、実際の評価でもそのような項目を重視していると聞きました。(マネージャーに限らず)

確かにリーダーシップがあった方が良いのはわかりますが、なぜそれらがエンジニアに求められているのか、そもそもリーダーシップとは一体どういったもので、エンジニアが個々人がリーダーシップ発揮していくにはどうしたら良いのかについて調べてみました。

要約

  • リーダーシップとマネジメントは同じではなく補完し合うものである
  • 複雑な状況にうまく対処する(複雑な企業に秩序をもたらす)のがマネジメントの役割
  • 役割は変化に対処することがリーダーシップの役割
  • 変化の激しいIT業界ではリーダーシップが必要だし求められている
  • リーダーシップには7つの段階がある
  • リーダーシップを獲得するには自己の本質の認識が必要不可欠

リーダーシップとは？ 〜マネジメントとリーダーシップの違い〜

リーダーシップと聞くとなんとなくイメージはできるが具体的な要素をあげていけと言われると困る人も多いのではないかと思います。

例えば、議論を引っ張ることであったり、的確に指示を出すことであったり、あるいはカリスマ性など個人の資質であったり・・・と人や場面においてリーダーシップと言われても様々な要素がありそうです。

またリーダーシップとは別にマネジメントという言葉もあります。
マネージャーがリーダーシップを発揮してくれないと嘆くかたもいるかもしれませんが、そもそもリーダーシップとマネジメントとは同じものではなく、相互に補完し合うものです。

ここではリーダーシップとマネジメントとは一体どのようなものでなぜ必要なのかを見ていこうと思います。

マネジメントとは複雑な状況に対処するためのもの

マネジメントとは大企業の出現によって生まれたもので、 複雑な状況をうまく対応するためのものです。

製品の品質や収益性などの重要な領域において、秩序がなければ企業を存続させることが困難になるため、複雑な企業においてうまく対応するために必要となります。

逆にマネジメントがお粗末だと、会社自体の存続そのものが脅かされることもありえます。

マネジメントにおいて行うことは以下のようなことがあげられます。

  • 計画と予算の作成と資源の分配
  • 立案した計画を達成するための組織作りと人員配置
  • 統制および問題解決を通じて計画の達成を確実にする

リーダーシップとは変化に対処すること

リーダーシップの役割は変化に対処することです。

VUCAの時代とも言われているように近年のビジネス環境は競争と変化の激しさが増しています。

そういった外部環境の変化に対して、組織が変化し対応していく必要があります。

そうした状況においてリーダーシップというものが必要になっていきます。

リーダーシップにおいて行うことは以下のようなことがあげられます。

  • 組織を変えるための方向性を決める
  • 組織メンバーの心を1つにする
    • ビジョンを伝え、理解することを助ける
  • ビジョンを達成するために、動機付けを行い、メンバーを正しい方向へ導く

なぜリーダーシップがソフトウェア開発において求められるのか

ここまで読めばなぜアメリカを代表する巨大IT企業がリーダーシップを求めているかわかると思います。

ビジネス環境の中でも特に変化の激しいIT分野において、世界のトップを走り続けるには競合よりも素早く変化に対応していかなかればなりません。

ガートナーの調査によれば、2020年までに、チームのケイパビリティを変革していないCIO(Chief Information Officer: 最高情報責任者)の半数は、デジタル戦略に基づいたリーダーシップが確立されチームから外されることになると述べています。

またDevOpsの調査結果（LeanとDevOpsの科学）によると、ソフトウェアデリバリのパフォーマンスとリーダーシップには高い相関性があることを明らかにしています。

特にハイパフォーマーのチーム、ミディアムパフォーマーのチーム、ローパフォーマーのチームではリーダーシップの特性に顕著な差が見られ、リーダーシップをもつリーダーがほとんどいないチームがハイパフォーマーになる可能性はほとんどないと指摘しています。

リーダーシップを発揮できるようになるにはどうすればよいのか

ここまでリーダーシップとはどのようなもので、なぜ必要になっているのかについて説明してきました。

しかしリーダーシップがなんたるかを理解してもそれを発揮できなければあまり意味がありません。

次により優れたリーダーシップを発揮する人、リーダーとなるにはどうすればよいのかについてみていきます。

リーダシップには7つの段階がある

発達心理学の研究者によれば、リーダーの能力格差の原因は内なる「行動論理」すなわち、どのように周囲の状況を理解し、自分の権力や安全が脅かされた時にどのように反応するかによるとしています。

ハートヒル・コンサルティング パートナーのデイビッド・ルークとボストン・カレッジ キャロルスクール・オブ・マネジメント 教授のウィリアム R. トーバートはその行動論理には7つの種類に分類できること、調査から明らかにしました。

以下が調査から明らかになった7つの行動論理です。

  1. 他者利用型
  2. 利害調整型
  3. 専門家型
  4. 目標達成型
  5. 個人尊重型
  6. 戦略家型
  7. 改革者型

またこの調査では行動論理によって企業や個人のパフォーマンスに差が生じることも明らかになりました。

他者利用型、利害調整型、専門家型は特に平均以下のパフォーマンスと結びやすく、目標達成型よりも明らかに低く、イノベーションを続け、組織を変革していく能力を安定して示したのは、個人尊重型、戦略家型、改革者型の3種類であることが明らかになりました。

7つの行動論理

引き続き、7つの行動論理の詳細について見ていきましょう。
下記の表は「ハーバード・ビジネス・レビュー リーダーシップ論文ベスト10 リーダーシップの教科書」からの引用です。

行動論理 特性 強み 調査全体に占める割合
他者利用型 どんな手を使ってでも勝とうとする。自己中心的で、人を操りたがる。「力こそ正義」 緊急事態や営業に役にたつ 5%
利害調整型 不可避の衝突を避けようとする。集団の規範に従う。現状打破には消極的。 オフィス内の「接着剤」として機能し、集団の一体感を高める 12%
専門家型 論理性と専門知識を第一義におく。理性的に効率を求める。 個人としての貢献度は高い。 38%
目標達成型 戦略目標を実現する。複数のチームをまとめて目標を達成される。マネージャーとしての責任と市場からの要求をバランスさせる。 管理職に向いている。行動志向であり、また目標志向である。 30%
個人尊重型 人間と組織の様々な行動論理を統合させることができる。戦略計画と実績の差を埋めるために、独自の仕組みを考え出す。 起業やコンサルティングに向いている。 10%
戦略家型 組織や個人の変革を生み出せる。短期的にも長期的にも、仲間との間で互いに問いかけや警告、弱点について指摘し合う。 変革リーダーに適任である。 4%
改革者型 社会の変革を生み出せる。物質的な変革、精神的な変革、社会的な変革を総合的に進める。 世の中の改革を指導できる。 1%

重要なことは、これら7つの行動論理の中で自分はどのような行動論理で活動をしているかを自己認識して、自ら次のステージへと進歩しようと努力することでリーダーシップを高めることができるということです。

自分らしいリーダーシップを求めて

7つの行動論理について分かったところで、今度は自身がそのステップを上がるために何ができるかについて見ていきます。

一人一人異なるリーダーシップ

ハーバード・ビジネス・スクール教授のビル・ジョージをはじめとする4名*1 は理想のリーダー像に共通するスタイル、特性、資質を描き出した研究は1つもないことを明らかにしました。

リーダシップには様々なスタイルがあり、誰かの真似をすれば得られるものではなく、ありのままの自分を表現できているときに得られるものであることを指摘しています。

そして自分らしいリーダーシップを発揮するためには「自らの本質とは何か」について理解する（あるいは理解しようと努力する）ことが必要です。

自らの本質を理解することでブレないリーダーシップを得ることができます。

つまり自己認識が自分らしいリーダーシップを発揮するために必要になるということです。

自らの本質を探るための問い

自分らしさを知るためには自分史を整理して、どのような経験が自身の信じる価値観や原則の基となっているか、特に起こった事実に対して、自身がどのように意味づけを行なっているかが、価値観や原則の基になっています。

自分らしいリーダーシップを獲得するために参考となる質問を「ハーバード・ビジネス・レビュー リーダーシップ論文ベスト10 リーダーシップの教科書」からの引用しました。
下記の質問を使い、自分の本質を理解し、またその本質が7つある行動論理のどれに則しているかを理解することで、これから自分らしさを持ちつつ、組織を動かしていくリーダーシップの獲得に役にたつはずです。

  1. これまでの人生を振り返って、自身がもっとも影響を受けたのは、どのような人物、あるいはどのような経験か。
  2. 自己認識力を高めるために、どのようなことを心がけているか。本当の自分はどのような人間か。本当の自分だと思えるのはどのような瞬間か。
  3. 自分の奥底にある価値観はいかなるものか。それは何に起因するのか。子供の頃と比べて価値観は大きく変わっているか。その価値観がどのような行動に結びついているか。
  4. 自分を動かす外発的な動機は何か、あるいは内発的な動機は何か。人生において、外発的な動機と内発的な動機をどのようにバランスさせているか。
  5. 周囲にどのような応援団がいるか。自分らしさを貫くリーダーシップを実現するために、応援団はどのように役に立っているか。視野を広げるためにチームの多様性を高めるにはどうすればよいか。
  6. 自分の生活態度は一貫しているか。生活のあらゆる場面、例えば職場、職場以外、家族の前、コミュニティの中で、いつも同じ人間でいられるか。そうれないとすれば、何が障害となっているのか。
  7. 自分らしくあることは、人生においてどういう意味があるか。自分自身であることでリーダーとしての能力が高まっているか。自分らしさを貫くリーダーであることで、何かを犠牲にしたことはあるか。その価値はあったか。
  8. 自分らしさを大切にしたリーダーとして成長していくために、今日、明日、そして今後1年の間に何ができるか。

また上記の質問以外ではマイゴールという書籍の質問リストもとても役にたちます。気になるかたは下記リンクも見てみてください

danjinda-diary.seesaa.net

終わりに

今回はリーダーシップについてそれが何であるか、なぜ必要か、自分らしさを持ちながら獲得するにはどうすればよいかについて書いてきました。

リーダーシップを獲得する道のりは簡単ではありませんが、獲得しようと努力することで、辛いこともあれど、最終的に自身の人生をより豊かにできるものだと思っています。

今年のゴールデンウィークは終わってしまいますが、時間を見つけて自分を見つめ直してみようと思います。

最後まで読んでいただきありがとうございました😊

追記

過去の偉人と呼ばれる人たちが自身の経験と外発的な動機・内発的な動機を絶えず内省して、結果として偉業を成し遂げたり、リーダーシップを獲得した物語を知りたい人には あなたの人生の意味――先人に学ぶ「惜しまれる生き方」 という本がオススメです。
ビル・ゲイツが2015年のベスト書籍として選んだだけのことはあり、自身の人生を振り返る参考になります。

参考資料

*1:ハーバード・ビジネス・スクール教授 ビル・ジョージ、元スタンフォード経営大学院講師 ピーター・シムズ、元ハーバード・ビジネス・スクール研究員 アンドリュー N. マクリーン、元シティグループ 執行役員 ダイアナ・メイヤー

2018年に読んだ本とはてブを振り返る

本

2018年に読んだ本たち

2018年に新たに読んだ本は約97冊でした。

2016年、2017年共に100冊超えのペースで読んできたのですが、今年はわずかに100冊には届きませんでした。(読み直しを含めると100冊はいっていると思います)

今年は自己啓発系の本を読むことが少なくなり、代わりに技術書・ビジネス書・組織系の本を読むことが多かったように思います。

おそらく転職をきっかけにキャリアの悩みが一旦解消されたことと、転職先の組織での組織変革が原因かなと思います。

ちなみに今まで読んできた本の一覧はこちらです。

tofu511の本棚 (tofu511) - ブクログ

2018年に読んでよかった本たち

一流の頭脳

運動（特に有酸素運動）が脳の働きを高めることを科学的に検証した本。
読んだ後に運動を始め出したのだが最近は運動できていないのでそろそろ始めよう。

一流の頭脳

一流の頭脳

AI vs 教科書が読めない子どもたち

シンギュラリティは来るか？という疑問に対する1つの回答を見せてくれた。

AIは意味を理解できないというのはAIを理解する上でとても役に立った。

またそれ以上に子供たちの中で教科書を読めていない、理解できていない層が一定数あることに驚いた。

この本を読んでから自分は意味を理解できるか気にするようになった気がする。

AI vs. 教科書が読めない子どもたち

AI vs. 教科書が読めない子どもたち

その悩み、哲学者がすでに答えを出しています

世界の偉人たちが日々抱えるような悩みに答えていくという本。
特別何か悩みがある中で読んだわけではなかったが、読んだ後に「自分には世界の哲学者たちがついているんだ」という感覚になれたのがよかったです。

その悩み、哲学者がすでに答えを出しています

その悩み、哲学者がすでに答えを出しています

日本の国難　２０２０年からの賃金・雇用・企業

少子化がもたらす問題をイヤというほど見させられた1冊でした。

少子化対策が効果を発揮するまでの時間的ラグという今まで考えたことがなかった視点を与えてくれました。

また技術革新による生産性向上は労働者を増やさないという事実を突きつけられ手放しで喜べないということを理解できました。

日本が抱える問題をハッキリと突きつけられるとどうしても暗くなってしまいますが、これを解決していくのは自分たちであるということを忘れずに過ごしていきたいと思います。

日本の国難 2020年からの賃金・雇用・企業 (講談社現代新書)

日本の国難 2020年からの賃金・雇用・企業 (講談社現代新書)

朝日ぎらい　よりよい世界のためのリベラル進化論

朝日新聞をはじめとするいわゆる日本のリベラル層がなぜ支持されなくなったか、なぜ世界ではトランプ支持者がいる一方でトランプを激しく非難する人たちがいるのか。
こうした日本や世界を取り巻く状況をうまくするのが橘玲さんは本当にうまいと思う。
安倍政権が保守層を取り込みながらリベラルな政策をうてている理由を理解するのにとても役にたちました。

朝日ぎらい よりよい世界のためのリベラル進化論 (朝日新書)

朝日ぎらい よりよい世界のためのリベラル進化論 (朝日新書)

ファイナンス思考 日本企業を蝕む病と、再生の戦略論

日本企業を蝕む病とは一言でいうと短期的な利益を追求するPL脳だと論じています。
東芝や神戸製鋼の不祥事などPL脳が引き起こしているだろう不祥事が目立ってきた中で、帳簿上の利益を作るようなことはキャリアにおいてやりたくないと強く思った1冊。

ファイナンス思考 日本企業を蝕む病と、再生の戦略論

ファイナンス思考 日本企業を蝕む病と、再生の戦略論

テスト駆動開発

TDDをしっかり学びたいと思って読んだ1冊。
1章が短く作られているので写経にはもってこいでした。
最後の付録にあるt-wadaさんの現在におけるTDDの立ち位置についての解説はTDDの目的や生まれた背景を理解する上でとてもためになる解説でした。

テスト駆動開発

テスト駆動開発

決断の本質

決断の質は結果では測ることができないという衝撃の事実を突きつけられた1冊。
結果で測れないからこそプロセスにこだわり、より質の高い意思決定にするためのプラクティスが色々書かれており、スクラム導入のフェーズでとても役にたちました。

決断の本質 プロセス志向の意思決定マネジメント (ウォートン経営戦略シリーズ)

決断の本質 プロセス志向の意思決定マネジメント (ウォートン経営戦略シリーズ)

Web開発者のための大規模サービス技術入門

はてなの事例から大規模サービスに必要な知識を身につけるという本。
ISUCONで予選敗退した後に読んだのだが、出る前に読んでおけばよかったと激しく後悔しました。

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)

アジャイル開発とスクラム

スクラムの元になる概念が日本で生まれ、アメリカで体系化され、それがまた日本に戻って来るまでを知るのにとても役に立ちました。
野中郁次郎先生へのインタビューとその内容にとても感動し、スクラムの本質が見えた気がしました。

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

ティール組織

組織づくりを考える上で読みだした1冊。 まだ読みきっていないがティールな組織にできたら日々の仕事がもっと楽しくなりそうだと妄想しつつ、どのように組織を変えていくか模索しています。

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

リーン開発の本質

リーンという言葉が至る所で使われていたが本当の意味を理解していなかった自分にとって、意味を理解する上でとても役に立った1冊です。
トヨタ生産方式の歴史から今のソフトウェア開発での応用までをとてもわかりやすく説明しています。

リーン開発の本質

リーン開発の本質

今いる場所で突き抜けろ！――強みに気づいて自由に働く４つのルール

「好きなことを仕事にしようなんてやめろ！」というYouTuberたちを敵にまわすようなことを主張する本。
好きなことをやるよりもまずお前自身が突き抜けた人間になれというメッセージはとても納得できるものでした。

今いる場所で突き抜けろ！――強みに気づいて自由に働く４つのルール

今いる場所で突き抜けろ！――強みに気づいて自由に働く４つのルール

LeanとDevOpsの科学 テクノロジーの戦略的活用が組織変革を加速する

今年読んだ中で一番かもしれない。
正直DevOpsは一種のバズワードだと思っていた自分に、アジャイル・リーンの技術的な帰結がDevOpsだと気がつかせてくれた1冊。
2019年はDevOpsな組織づくりをやっていきたい。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

異端の時代－正統のかたちを求めて

森本あんり先生の本はどれも面白いのだが、今回は少し自分には難解だった。
ただ、正統とは何か・異端とは何かを理解することはできた。
中でも正統は正統であるがゆえに、正統である間はなかなか正統であると気が付けないという性質（自己隠蔽能力）を知っておくことは、今後何においても役に立ちそうだと感じた。

個人的にこれが正統か！と感じたエピソードが一つ。
以前はてブを見ていて、「オブジェクト指向にメリットはない」的な発言をしている人の記事を読んだ。
内容的にはオブジェクト指向の本質をやや取り違えているように感じたのだが、オブジェクト指向が当たり前で今やソフトウェア開発の「正統」になっているからこそオブジェクト指向というものがより見えづらくなっているんだと、正統がもつ自己隠蔽能力を垣間見た気がしました。

異端の時代――正統のかたちを求めて (岩波新書)

異端の時代――正統のかたちを求めて (岩波新書)

決算資料からビジネスの仕組みが見えてくる

普段我々が使っているサービスを運営している会社のIRからビジネスを捉えた本。
なるほど！と思うことがたくさんあったので、著者のシバタさんのようにIRを読めるようになりたいと思った1冊です。

決算資料からビジネスの仕組みが見えてくる (スマート新書)

決算資料からビジネスの仕組みが見えてくる (スマート新書)

2018年にブクマした記事たち

今年のブクマ数は約60個でした。
※ 自分はWebで読んだ記事でよかったと思うものしかブクマしてないのであまり数は多くないです。

ブクマを見ると当時自分がどんなことを考えていたかがわかってなかなか面白かったです。

2018年に読んでよかった記事たち

「なぜ関数プログラミングは重要か」を要約してみた（その１） - Okapies' Archive

「関数型プログラミングが優れているのは、高階関数と遅延評価という、モジュール同士を貼り合わせる強力な『糊』を持っているからだ」

この一言に思わず「なるほど！！」と感動したことを覚えています。
なおブログにあるコードの例はまだ全て理解できてません😇

okapies.hateblo.jp

システムソフトウェアに対する攻撃の歴史と傾向 - 高度標的型攻撃や国家に支援された攻撃の仕組み - - るくすの日記 ~ Out_Of_Range ~

とにかく長くて読み応えたっぷりです。

rkx1209.hatenablog.com

2018年なぜ私達はコンテナ/Dockerを使うのか | cloudpack.media

Dockerについていまいちしっくりきていなかった自分にとってとても為になりました。

cloudpack.media

Linux コンテナの基礎 / OSC2017 Osaka - Speaker Deck

チームの人に「Docerを知りたいならまずLinuxコンテナを知るといいよ！」とのアドバイスをもらって読んだスライド。
「なるほどDockerってLinuxコンテナの1つで、それを実現しているのはnamespaceとcgroupなのね」と理解が一段深まった資料です。

speakerdeck.com

リレーショナルデータベースの仕組み (1/3) | POSTD

こちらも読み応えたっぷりですが、とても分かりやすくスイスイ読んでいけます。

postd.cc

MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？ - Quora

コンピュータサイエンスは、そういうことではなく、たとえばリニアな問題を対数の問題に変換する、つまりO(n)の問題をO(log n)の問題にするのが真髄です。

この回答にしびれました。
上の「リレーショナルデータベースの仕組み」と合わせて読むのがおすすめです。

MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？ - Quora

Clojureと「Simple Made Easy」 - 紙箱

SimpleとEasyの違いを意識するようになったきっかけ。
全てのエンジニアにオススメです。

boxofpapers.hatenablog.com

THE VALUE OF VALUES

値とは？ということを意識するようになったきっかけ。
上のSimple Made Easyも、このTHE VALUE OF VALUESもClojureを作ったリッチヒッキーのものだと知って、2019年はClojureをやってみようと思うようになりました。

gitpitch.com

2018年を振り返って

転職

今年を振り返って

平成最後の年は自分にとってキャリアのターニングポイントでした。

5月に前職のSIerを退職し、Web系ベンチャーのバックエンドエンジニアとして入社しました。

新しい会社はSIer時代と環境・働き方・技術など様々な面で異なっていたので、キャッチアップには苦労しましたが、苦労以上に得るものが多い日々を過ごすことができました。

各月毎に振り返る2018年

1月

  • 正月休みを使ってScalaとPlayを使ってアプリを作る。(転職活動でアピールするため)
  • 転職活動を開始。書類が通ったり通らなかったりする。
  • (オンラインで)通っている通信大学の後期科目試験を受ける。
  • プロジェクトの見積もりをやらかし長時間労働のフラグが立つ。

2月

  • プロジェクト管理、レビューなどにひたすら追われる。
  • 長時間労働の中どうにかやりくりして書類が通った企業の面接を受け始める。
  • 第一志望企業から内定をもらう✌️
  • 前職の上司に転職する旨を伝える。引き止めとかが全くなく拍子抜けする。

3月

  • プロジェクト管理、レビュー、バグ修正などにひたすら追われる。
  • 担当プロジェクトが結合テストフェーズに入ってバグを出しまくる。残念な気持ちになる。
  • 初めてScala Matsuriに参加する。圏論入門のセッションで圏論が理解できず残念な気持ちになる。

4月

  • 引き継ぎ資料をたくさん作る。
  • プロジェクトの人たち・前職の人たちに送別会を開いてもらう。

5月

  • ゴールデンウィークを使ってAngularを学ぶ。Reactにしておけばよかった。
  • 入社する。前職より同期が増える。
  • 中途の研修が充実していて感動する。
  • 仕事でMacが使えるようになり地味に感動する。
  • ウォーターフォールじゃなくなり普通に感動する。
  • ペアプロ、モブプロを初めて経験する。
  • オンプレからAWSを通り越してGCPを触るようになり色々困惑する。
  • Webアプリのサーバーサイドをやるかと思っていたらデータ処理周りをガッツリやることになって色々困惑する。
  • ドメイン知識不足で色々困惑する。

6月

  • 今後入社する人向けのキャッチアッププログラム的なモノを作ろうとしたが結局不要になってしまう。
  • チームには慣れてきたが、業務には慣れない日々が続く。
  • 足りない知識を補うために勉強会やもくもく会にたくさん参加する。

7月

  • CSD(Certified Scrum Developer)研修に会社のお金で参加させてもらう。今までの開発観を変える経験をする。
  • スタディサプリで英語の勉強を始める。

8月

  • スクラムが本格的に導入され組織がカオスなことになる。
  • スクラム以前の課題が大量に出てきて困惑する。
  • 人生で初めて奥多摩に行く。
  • 友人にISUCONに誘われる。
  • スタディサプリでの英語学習に価値を見出せなくなり残念な気持ちになる。

9月

  • スクラムを実践するのに日々が精一杯。
  • 仕事がハードだったからか通勤が億劫になり引っ越し先を探し始める。
  • 初めてのISUCONで予選敗退する。パフォーマンスについてもっとしっかり学ぶことを決意する。

10月

  • 住み慣れた横浜を離れ世田谷区に引っ越す。
  • 数年ぶりにTOEICを受ける。

11月

  • スクラムが徐々にまわせるようになってくる。

12月

SIerからWeb系企業に転職するとなぜしがなくなるのか組織的な観点から調べてみた

エンジニア 組織 転職

この記事は #しがないラジオ 2 Advent Calendar 2018 - Adventar の24日目の記事となります。

この記事について

私は2018年の5月に約3年勤めたSESをビジネスの主体とするSIerを辞め、HRを主とするWeb系ベンチャー企業にサーバーサイドエンジニアとして転職しました。

転職後の開発組織ではSIer時代とは比べ物にならないくらい楽しく仕事ができていたり、転職後の会社でちょうど組織体制の変更などもあり、開発組織と組織論というものに興味を持ちました。

本記事では組織論的な観点からエンジニアにとってどのような組織が楽しく働きやすいかということについて、State of DevOps Report というレポートおよび上記レポートの日本語訳であるLeanとDevOpsの科学という書籍、さらに自身の経験を元に書いていきます。

SIerからWeb系の企業に転職したい人やよりよい組織を探していたり、作っていこうとしている人の参考になれば幸いです。

TL;DR

  • 官僚的な(ルール志向の)組織より創造的な(パフォーマンス志向の)組織の方が、燃え尽きが少なく、職務満足度も高い
  • 個人的経験からSIer時代は燃え尽きに陥る原因が多くあり、転職後のWeb系企業では燃え尽きに陥るようなことは少ない
  • これから転職する人はDevOpsやLeanのプラクティスを取り入れているかどうかである程度その組織が創造的かどうかを見極めることができる

目次

私について

SIer時代(2015/4 ~ 2018/4)

2015年に新卒でSESをビジネスの主体とするSIerにエンジニアとして入社しました。 約2ヶ月の研修を終えたのち、約3年間お客様先に常駐し、飲食系Webアプリの改修や保守・運用などを行なっていました。

常駐先では自社以外に様々なSIerが入っており、SIer間での政治的な取引も多い現場でした。
開発フローはウォーターフォール型で、月一度リリースがある現場でした。

組織体制はいわゆる官僚型の組織で、リリース時などには基本的に許可が必要な組織でした。

Web系ベンチャー時代(2018/5 ~ now)

2018年5月に転職し、HR系のWebベンチャー企業に転職しました。
今は求人検索プロダクトの主にサーバーサイドとインフラ周りのエンジニアをやっています。

転職前に常駐していた企業とは異なり、今の組織ではSIerに開発を外注することはなく、プロダクト開発は全て自社の社員で開発しています。
開発フローはスクラムを用いており、1週間のスプリントで開発を行なっています。

組織体制は官僚的な組織になりつつありましたが、スクラム導入とともに自己組織化された組織となるべく絶賛組織改革中です。

組織の種類

さてここから組織について踏み込んでいきます。

先に紹介したState of DevOps Report というレポートは名前の通りDevOpsについての調査レポートです。
レポートではDevOpsやLeanのプラクティスを使用することでより開発を加速させることが可能ということが調査結果を元に書かれています。

そしてこのレポートの中でDevOpsやLeanプラクティスを用いることでより創造的な組織にできるということも書かれています。

このレポートでは米国の社会学者Ron Westrumが定義したモデル を使用しているため、まずその組織モデルについて紹介をします。

タイプ別にみる組織形態

Ron Westrumは自身の研究から組織は3つのタイプに分類できるとしました。

  • 不健全な(権力志向の)組織
  • 官僚的な(ルール志向の)組織
  • 創造的な(パフォーマンス志向の)組織

上記の組織は下記の表にあるような特徴を持ちます。

不健全な(権力志向の)組織 官僚的な(ルール志向の)組織 創造的な(パフォーマンス志向の)組織
協力態勢が悪い ほどほどの協力態勢 協力態勢が確立
情報伝達を阻止 情報伝達を軽視 情報伝達に熟達
責任逃れ 責任範囲が狭い リスクを共有
仲介を阻止 仲介を許容 仲介を奨励
失敗は責任転嫁へ 失敗は裁きへ 失敗は調査へ
新規性を潰す 新規性を問題化 新規性を実装

これらのタイプの中で、創造的な組織であればあるほど、組織のソフトウェアデリバリのパフォーマンスは上がり、職務満足度を向上させることが明らかになっています。

組織のあり方が職務満足度を変える

創造的な組織であるほど職務満足度を向上させるという点についてもう少し細かく見ていきましょう。

燃え尽きを防ぐ

燃え尽き(バーンアウト)とは、過労やストレスによる心身や感情面での極度の疲労のことをさします。
燃え尽きの原因には以下のような理由があります。

  • 過重労働(働かせすぎ)
  • 自律性の欠如(自分の仕事の意思決定を自分ができない)
  • 不十分な報奨(経済的、社会的、組織的な見返りが不十分)
  • 人間関係の断絶(精神的な支えがない)
  • 公平性の欠如(意思決定のプロセスが公平性にかける)
  • 価値観のズレ(個人の価値観と組織の価値観が一致しない)

創造的な組織は燃え尽きの原因である過重労働や人間関係の断絶、価値観のズレなどを多くの場合は解消できます。
組織内での協力態勢が確立していたり、本質的でない仕事を極力無くしていることが予想できるからです。

職務満足度

創造的な組織は燃え尽き防止のみならず、職務満足度をあげることも調査結果から明らかになっています。
具体的にはより創造的な組織ほど以下に賛同できることが明らかになっています。

  • 他ならぬ今の組織を職場として選んだことを嬉しく思っている
  • 自分の組織は職場として最高だと友人に話している
  • 自組織の成功のためには、期待させる以上の貢献努力を惜しまないつもりだ
  • 自分の価値観は組織の価値観にとても近い
  • 自分の組織の構成員は総じて同じ1つの目標を見据えて作業を進めている
  • 組織は私のことを気にかけてくれている

個人的経験からみるSIerとWeb系の働き方の違い

こうして組織について調べる中でSIer時代は燃え尽きになる原因が職場においてとても多かったと気づきました。
対照的に今の働き方では燃え尽きることはほとんどなく、楽しく働けています。

SIer時代

  • 納期が近くなれば過重労働になることもある
  • 会社間の政治などで自身の仕事について意思決定できない(新規技術導入など)
  • 金銭的な報酬や技術的な学びは多くない
  • 各社の政治的やり取りから現場における意思決定に公平性や合理性いがない
  • メンバーとの会話はそこまでない。少なくとも精神的な支えにはならない

Web系ベンチャー時代

  • リリースをコントロールしているため過重労働になることはほとんどない
  • 自身やチームの仕事についての意思決定は当事者が行う
  • 日々チームメンバーと協力しながら仕事を行なっているため人間関係の断絶に陥ることもない
  • プロダクト全体や組織全体に関わる意思決定の場は組織の全員が参加することができる
  • 金銭的な報酬と技術的な報酬も前職より貰えており、市場全体と比較しても妥当な額である。

これから転職する人が気をつけるべきポイント

State of DevOps Report ではDevOpsとLeanのプラクティスを行うことで組織をより創造的にさせること示されています。
DevOpsやLeanのプラクティスを導入している企業は創造的な組織になっている可能性が高く、より楽しく働ける組織になっていることが予想できます。
これから転職をする人(特にSIerからWeb系に転職しようとしている人)は以下のようなことを確認することで転職しようとしている会社の開発組織がどの程度創造的か測ることができると思います。

技術的な面

  • 継続的デリバリを行なっているか
  • 継続的インテグレーションを行なっているか
  • コードのバージョン管理を行なっているか
  • テストを自動化しているかどうか
  • トランクベースの開発を行なっているかどうか*1
  • チーム外の人物の許可なく開発者がリリースできるか
  • 通常業務時間内でリリースができるか
  • ツールの選択権限がチームに与えられているか

事業的な面

  • 顧客フィードバックの収集と活用を行なっているか
  • 1週間未満で作業ができるような細分化が行われているか

組織的な面

  • 創造的な組織にしようとしているか
  • 学びと奨励を支援しているか
  • チーム間の協働の支援と促進を行なっているか

最後に

明日でAdvent Calendarラストです！
トリを飾っていただくのは zuckey_17 さんです！

参考資料

*1:https://www.infoq.com/jp/news/2018/05/trunk-based-development

ソフトウェア開発を加速させるために知っておきたい組織論とより創造的な開発組織になるのためのプラクティス

エンジニア 組織 DevOps リーン

この記事について

このエントリは ただの集団 Advent Calendar 2018 の12日目です。
昨日は tk628496 さんの 認定スクラムマスター（CSM）研修について でした。

私が現在所属している開発組織では、「変化に強い自己組織化された組織」になるべく、今年の8月からスクラムが本格的に導入されました。
スクラムの導入されてから

  • そもそもなぜ変化に強い組織にならなければならないか？
  • 今の組織構造にはどのような利点や欠点があるのか？
  • より変化に強い組織になるためには何をすれば良いのか？

ということに興味を持つことが多くなり、スクラム、Lean、DevOpsなど色々調べてみたことを自分の知識として統合するためにまとめてみた記事になります。
本記事ではタイトルにある通り、エンジニアがソフトウェア開発を加速させるために知っておきたい組織論とより創造的な組織になるのためのプラクティスについて書いていきます。
本記事が組織改善の役に立てれば幸いです。

TL;DR

  • 組織変革に先立って我々を取り巻く環境や市場の変化がある
  • 今はVUCAの時代とも言われるように不確実で先が見えない中でビジネスをしなくてはならない
  • VUCA時代に対して、組織の多くは官僚的組織であり、不確実なビジネス環境に適した組織でないことが多い
  • ソフトウェア開発組織に限っていうと、DevOpsやリーンのプラクティスを導入することでよりRon Westrumが提唱する創造的な組織に近づくことができる
    • 特にデプロイの負荷を下げることが創造的な組織になるために効果あることが明らかになっている

目次

前提条件としてのビジネス環境の変化

本題の組織論とDevOpsやリーンのプラクティスに入る前に前提として理解しておくべきビジネス環境の変化から説明していきます。

VUCA

現代のビジネス環境は一言で表すと「VUCAの時代」となっています。
VUCAとは下記の頭文字をとって作られた言葉です。

  • 変動性(Volatility)
  • 不確実性(Uncertainty)
  • 複雑性(Complexity)
  • 曖昧性(Ambiguity)

VUCAの時代を一言で表現すると「先が読めない時代」になっているということです。

bizhint.jp

変化が求められる組織

先が読めないVUCAの時代に対応する1つ方法として組織変革が挙げられます。

組織変革とは、組織の 「構造」および「文化」、「運営方法」などを見直し、抜本的な改革を成し遂げることをいいます。(組織変革とは？ 組織変革のプロセスやフレームワークのポイント より引用)

先の読めない時代になぜ組織変革が必要なのでしょうか？
それを知るためにはまず多くの企業がどのような組織体で運営され、どのようなメリットとデメリットを抱えているか理解することが大切です。

組織論について

組織とは

組織論で取り扱う組織とは以下のようなものです。

ヒトやモノ、カネ、そして情報などの資源を有効に活用して、少しでも多くの、良質の成果を得るようにするための仕掛けである。(よくわかる組織論 より引用)

営利企業の場合、組織が持続することを前提としているため、基本的に利益を得ることが上記の定義における「良質の成果」に当たります。（しかしながら、利益のみが良質な成果かと言われるとそういうわけでもありませんが）

ある営利企業において自組織の経営資源を有効に活用できない組織形態になっている場合、組織変革と通じて経営資源をより有効に活用し良質な成果を得ることができないと組織としての持続が難しくなってしまいます。

組織論で取り扱う組織は営利企業のみを対象としているわけではありませんが、この記事では組織 = 営利企業の組織というのを前提として話を進めていきます。

タイプ別にみる組織形態

組織形態については様々な学者が組織をタイプ別に分けていますが、この記事では米国の社会学者Ron Westrumが定義したモデルを紹介します。

Ron Westrumは自身の研究から組織は3つのタイプに分類できるとしました。

  • 不健全な(権力志向の)組織
  • 官僚的な(ルール志向の)組織
  • 創造的な(パフォーマンス志向の)組織

上記の組織は下記の表にあるような特徴を持ちます。

不健全な(権力志向の)組織 官僚的な(ルール志向の)組織 創造的な(パフォーマンス志向の)組織
協力態勢が悪い ほどほどの協力態勢 協力態勢が確立
情報伝達を阻止 情報伝達を軽視 情報伝達に熟達
責任逃れ 責任範囲が狭い リスクを共有
仲介を阻止 仲介を許容 仲介を奨励
失敗は責任転嫁へ 失敗は裁きへ 失敗は調査へ
新規性を潰す 新規性を問題化 新規性を実装

みなさんが所属する組織は不健全な組織まではいかなくとも、官僚的な組織であることが多いのではないでしょうか？
大企業のような組織規模が大きい組織や規模を拡大している組織は組織管理のためにルールによるコントロールシステムが整備され、徐々に官僚的な企業になっていきます。
組織変革を必要としている組織は多くの場合、大企業のような官僚的な組織であることが多いため、次に官僚的な組織の利点と欠点について説明します。

官僚的な組織の利点と欠点

官僚的な組織は意図の有り無しに関わらず、企業をより合理的に運営していくために官僚的な組織になることが多くあります。しかしながら合理性を求めた結果、官僚的な組織が非合理な組織になってしまうこともありえます。
官僚的組織には先に紹介した表の特徴の他に以下のような特徴も持ちます。

  • 規則による管理を重視する
  • 職務の専門化が高度に進んでいる
  • 権限と責任が職位に対して付与され、それが階層をなす形で組織が編成されている

これらの特徴を揃えた官僚的な組織は タテの命令系統で規則に基づき大規模で定型的な業務を遂行すること には向いていますが、急激に変化する環境に柔軟に適応するために、新たな製品・サービス、仕組みを作り出すイノベーションや改革が行いづらい という欠点も抱えています。

なぜイノベーションが起こりづらいかというと、規則を重視するあまり自由な発想が生まれづらく、組織のヨコでの協力も生まれづらいことが挙げられます。

先に今は先の読めない時代になっていることを書きましたが、官僚的組織が今の時代と相容れないのはこの点においてです。
先が読めない時代においては失敗をある程度許容しつつ、規則にないような新たな製品や活動を行っていく必要がありますが、官僚的組織形態がそれを阻害しているのです。

官僚的な(ソフトウェア開発)組織から創造的な(ソフトウェア開発)組織へ

官僚的組織から創造的な組織になるために組織変革を行う必要が出てきます。
ここまではソフトウェア開発組織などに限定せず一般的な組織の形態を見てきましたが、 以降では官僚的なソフトウェア開発組織から創造的なソフトウェア開発組織になるためのDevOpsプラクティスを紹介していきます。
DevOpsプラクティスの導入はあくまで官僚的な組織から創造的な組織へとなるための手段の一つにすぎません。
本来の目的はより時代に適した組織となることです。
本来の目的を忘れ、プラクティスを導入することが目的になってしまうと本末転倒ですが、組織論的な背景を知ることでプラクティスが目的ではなく手段とすることができるはずです。

創造的な組織になるのためのプラクティス

ここからは創造的な組織になるのためのDevOpsプラクティスとリーン製品開発に基づくプラクティスを紹介していきます。
なおこれから紹介するプラクティスはLeanとDevOpsの科学という書籍にて全て紹介されていますので、より詳しく知りたいかたは書籍を当たっていただければと思います。

DevOpsとは？

まずDevOpsについて簡単に説明します。
DevOpsとは以下の概念のことを言います。

「開発チーム（Development）と運用チーム（Operations）がお互いに協調し合うことで、開発・運用するソフトウェア／システムによってビジネスの価値をより高めるだけでなく、そのビジネスの価値をより確実かつ迅速にエンドユーザーに届け続ける」という概念である。 (「DevOpsとは何か？ そのツールと組織文化、アジャイルとの違い」より)

通常、DevOpsのプラクティスはビジネスの価値を確実かつ迅速にエンドユーザーに届けるために実施されますが、DevOpsのプラクティスを実施することで、より創造的な組織になることを促進するすることが、書籍の著者およびPuppet社の調査と研究から明らかになりました。

リーン製品開発（リーンソフトウェア開発）とは？

続いてリーン製品開発について簡単に説明します。

リーンソフトウェア開発は、製造業を中心に展開されているリーン生産方式を、ソフトウェア製品に適用した開発手法で、メアリー・ポッペンディークとトム・ポッペンディークが提唱しアジャイル開発手法の１つになっている。リーン生産方式は、日本の自動車産業の強さを探るため、特にトヨタ生産方式（TPS）を研究し、それを一般化・再体系化した際に付けられた名称である。（「リーンソフトウェア開発の７つの原則」より）

またリーン製品開発には7つの原則があります。

  1. ムダをなくす
  2. 品質を作り込む
  3. 知識を作り出す
  4. 決定を遅らせる
  5. 速く提供する
  6. 人を尊重する
  7. 全体を最適化する

リーン製品開発のプラクティスもDevOpsのプラクティス同様に、より創造的な組織になることを促進するすることが、書籍の著者およびPuppet社の調査と研究から明らかになりました。

24のケイパビリティ5つのカテゴリー

「LeanとDevOpsの科学」によると、ソフトウェアデリバリのパフォーマンスを改善する効果の高いケイパビリティ（組織全体やグループとして保持する機能や能力）は24個存在し、その24個のケイパビリティは5つのカテゴリーに分類できます。

  1. 継続的デリバリ
  2. アーキテクチャ
  3. 製品とプロセス
  4. リーン思考に基づく管理と監視
  5. 組織文化

これらの中で、より創造的な組織になるためのプラクティスのカテゴリーとして「継続的デリバリ」、「リーン思考に基づく管理と監視」「組織文化」があります。
まず継続的デリバリから見ていきましょう。

継続的デリバリ

継続的デリバリとは『機能の追加、構成の変更、バグの修正、各種試行など、さまざまな変更を、安全かつ迅速かつ持続可能な形で本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティからなる手法』のことです。
継続的デリバリは以下の5つの基本原則を柱としています。

  1. 「品質」の概念を生産工程の最初から組み込んでいく
  2. 作業はバッチ処理で進める
  3. 反復作業はコンピュータに任せて人間は問題解決に当たる
  4. 徹底した改善努力を継続的に行う
  5. 全員が責任を担う

注目すべきは「全員が責任を担う」という点です。
官僚的組織では組織全体の目標より部署や所属チームの目標を重視する傾向がありますが、継続的デリバリを実践する過程で、ソフトウェアデリバリに関わる全関係者が協力できるようにしなければ継続的にソフトウェアをデリバリすることはできません。
継続的デリバリの実践を通じてそこそこの協力態勢からより確立した協力態勢の構築が期待できます。

継続的デリバリの実践には以下の作業基盤を整備が必須になります。

  • 自動化したビルド／テスト／デプロイを行うための包括的な構成管理
  • より素早く統合を行うための継続的インテグレーション(CI)
  • 継続的テスト

また継続的デリバリを実践する上で開発者に以下の権限を与えることも必要になります。

  • 問題発生を即座に察知するためのツール
  • そのツールを開発するための時間と資源
  • 問題を直ちに修正できる権限

継続的デリバリを実践しデプロイ関連の負荷を下げることができればチームの燃え尽き症候群を軽減し、職務満足度を高めることも明らかとなっています。

リーン思考に基づく管理と監視

リーン製品開発におけるマネジメントのプラクティスには以下の4つのプラクティスがあります。

  • 進行中の作業(WIP)の制限
  • 品質と生産性に関する重要な数値指標の可視化
  • ワークフローの可視化
  • 負担の軽い変更承認プロセス

これらのプラクティスの中で注目すべきは「負担の軽い変更承認プロセス」です。
ソフトウェアデリバリにおいて、コードレビューなどの変更承認プロセスを踏むことはよくありますが、調査の結果、「チーム外の人や組織の承認を得なければならない場合、本番システムの安定性は向上せず、むしろ確実に作業の遅れを招く」ことが明らかになりました。 また継続的デリバリでも少し触れたようにデプロイ負荷と創造的な組織には相関があり、コードデプロイの負荷が増せば増すほど組織文化の質が下がることも調査から明らかになりました。

組織文化

組織文化の醸成はより創造的な組織になるために大きく関わっています。
以下の4つの組織文化の醸成がソフトウェアデリバリのパフォーマンスを改善することが調査から判明しており、またソフトウェアデリバリのパフォーマンス改善が組織変革に効果があることがわかっています。

  1. 学びの奨励と支援
  2. チーム間の協働の支援と促進
  3. 有意義な仕事を可能にするツール類の資源の提供
  4. 改善を推進するリーダーシップの実現や支援

これらの組織文化の醸成には投資などが絡むため、組織のマネジメント層のコミットメントが重要になります。

まとめ

ビジネス環境の変化から始まり、組織論やDevOps・リーンのプラクティスについて色々書いてきたので若干まとまりのない文章になってしまいました。。
本記事では現在のビジネス環境が先が読めないことから始まり、官僚的組織が現在のビジネス環境に適した形態でないこと、開発組織変革にあたり、DevOpsとリーンのプラクティスが創造的組織となるために効果があることを書きました。

本文でも紹介したLeanとDevOpsの科学ですが、本書には本記事では紹介しきれなかったプラクティスが数多くあります。
個人的2018年に読んだ本のTop3に入る良い書籍だったので、より良い開発組織を創ろうとしている全ての方にぜひ読んでいただきたいです。 最後まで読んでいただきありがとうございます。

参考資料

「Zero to One」を読み返したので雑な要約をしてみた

本 書評

Paypalを作ったピーター・ティールが書いた「Zero to One」を2015年に読んでから久しく放置していたのだが、久しぶりに読み返したところ、いろいろ学びがあったので雑なメモとして残す。

www.amazon.co.jp

要点

  • 「賛成する人がほとんどいない、大切な真実はなんだろう？」という問い
    • 視点が未来に近くほどいい答えになる
  • 進歩には2つの形がある
    • 垂直的／集中的進歩
      • 何か新しいことを行う
      • テクノロジー
      • 0 to 1
    • 水平的／拡張的進歩
      • 成功例をコピーする
      • グローバリゼーション
      • 1 to n
  • グローバリゼーションよりテクノロジーの方が世界の未来を左右する
  • ドットコムバブルの教訓が現在のビジネスの前提になっている
    • 少しずつ段階的に進むこと
    • 無駄なく柔軟であること
    • ライバルのものを改良すること
    • 販売ではなくプロダクトに集中すること
  • 正しいのは上の前提の逆
    • 小さな違いを追いかけるより大胆にかけた方がいい
    • できの悪い計画でもないよりはいい
    • 競争の激しい市場では収益が消失する
    • 販売はプロダクトと同じくらい大切だ
  • 完全競争下では長期的に利益を出す企業は存在しない
    • 資本主義は資本の蓄積を前提に成り立つが完全競争下ではすべての商品が消滅する
    • コモディティビジネスを行ってはならない
  • 非独占企業は自社の独自性、独占を誇張する
  • 独占企業は自社の市場を幾つかの市場の総和と定義することで独占をカモフラージュする
  • 独占が成功企業の条件
  • 競争はイデオロギー
  • 企業価値は将来のキャッシュフローを創出する能力できまる
    • 「このビジネスは１０年後も存続しているか？」
  • 独占企業の特徴
  • 独占は小さな市場から始める
    • 小さな市場の方が独占しやすい
  • 小さな市場を支配したら拡大する
  • 市場を最後に独占するのが大切
    • ファーストムーバーでなくて良い
  • リーンであることは手段であって目的ではない
    • 大胆な計画のない反復はゼロから１を生み出さない

雑な感想

普段、仕事をしているとどうしても目先のタスクや短期的な成果を求めがちになってしまうが、そもそも「今のプロダクトは独占できるか？」「このビジネスは10年後も存続しているか？」「２番手より１０倍優れているか？」という目線を失いがちだったと反省。これからはマーケットや技術動向を含めもっと俯瞰的に見れるようになりたい。