今回から現場が生き生きと働くためのチーム運営術を連載する。ベースとするのはトヨタ自動車で培われたマネジメント手法「TMS」や開発と運用を密に連携させて、システムを短期間でリリースする手法である「DevOps」をビジネス全体で使えるように発展させた「DevOps2.0」だ。
現場に元気が無い――。世の中には生産性を高める優れた開発技術や開発方法論がたくさんありますが、これらを使っても、現場に活気が無かったり技術者が自信なさそうにしていたりしています。この連載では、現場の技術者が自分たちの知識や技術に自信を持ち、元気のある現場に戻していく“技”や方法をお伝えします。
筆者はソフト開発業界に約40年身を置いてきました。直近の10年間は、アジャイル開発チームの立ち上げ支援や基幹系システムのアジャイル開発プロジェクトのマネジメント支援、ウォーターフォール開発の見える化支援、ホワイトカラーの職場改善支援などに従事しています。
基本となる思想・方法はトヨタ自動車の生産方式やマネジメントを基にした「TMS（トヨタ・マネジメント・システム）」です。TMSは基本的な働き方や仕事の仕方の習慣をつくるためのプログラムです。
日本企業に合ったやり方で現場を支援する一方、2016年は市場の変化に柔軟に対応するためのシステム開発・運用手法である「DevOps」の適用範囲を、ビジネスの企画からサービス提供終了時まで拡大した「DevOps2.0」の定義や推進支援にも携わりました。
こうした経験や知識を基に、「現場が元気になり、自信を取り戻す」実践項目を具体的に解説していきます。何らかのヒントになれば幸いです。
第1回は元気が無い職場の見分け方と、改善の大まかな方向性を解説します。にぎやかな現場だから元気があるわけでもなく、静かだからと言って元気が無いわけでもありません。
「仕事はつらいもの」なのか
筆者が支援業務で訪れる現場では最初に研修を実施しますが、ほとんどで感じるのが、「また研修か」「こんなことより早く業務に戻りたい」「面倒だな」といったマイナスの雰囲気です。皆さんが研修に飽きているのだなと感じると同時に、研修が仕事に役立ってないのだなとも感じます。
技術者として、従業員として、確実に仕事をしているという個々のプライドを感じることもあります。ですが、「仕事が個人に依存していて、チームで実施されていない」という状況が透けて見えて、寂しさも感じます。
さらに、研修生の皆さんは「忙しい」「疲れている」と自己アピールをしがちです。確かに現場は忙しい。当然疲れているでしょう。こうした状況を改善できるような相談相手がいないのだとすればつらいのも当たり前です。
このような現場で「仕事を楽しんでいますか？」と質問すると、皆さん、苦虫をかみ潰したような表情になります。
ある現場では「仕事なんだからつらくて当たり前です！お金をもらうっていうのはそういうことです」と話す技術者がいました。確かに、自分の仕事に見合った対価として給与があるのですから、その考えは成り立つでしょう。
他には「趣味のためにつらくても頑張って仕事をする」と話す方もいました。共通するのは「仕事はつらいもの・嫌なもの」という考えです。
20歳そこそこで仕事に就き、65歳でリタイアするとしたら、40年以上のほとんどを仕事に費やすのです。仕事がつらいとしたら、人生がとてもつらくなりませんか？
つらいからこそ心の病を患ったり、体調を壊したりもします。「病は気から」とも言いますし。病気にならないまでも、つらければ元気も自信も出ない。「好きこそものの上手なれ」とも言いますよね。
最近、書店に行くと、メンタルヘルスや働き方、対人関係といった類いをテーマにした書籍が山積みです。これは多くの人が「仕事＝つらい」と考えていて、書籍に解を求めているとも考えられます。
ですから、筆者は現場の皆さんに「楽しく仕事し、仕事を楽しむようにしましょう」と話し掛けて、どうやったら楽しさを感じられるかを想像してもらい、行動から実感してもらうことを大切にしています。
あいさつが元気を呼ぶ
どんな現場だと元気が無いのでしょうか。筆者が見てきた「元気のない職場」には共通する四つのサインがありました（図1）。
サイン1：あいさつが無い
現場で最も多く感じる違和感は「あいさつが無い」ことです。たとえあっても「声が小さい」のです。
現場を仲が良い友人たちとの集まりに置き換えて考えてみてください。会ったらまずあいさつをしますよね。言葉でなくても、手を振ったり、お互いのゲンコツを軽くぶつけ合ったりするのも立派なあいさつです。
どんな年代、どんな嗜好の集まりでも、仲間とはあいさつするでしょう。あいさつには尊敬や信頼、友情といった様々なお互いの思いが込められています。
あいさつが無い現場は、メンバー相互で尊敬や信頼、友情を含めたコミュニケーションを取れていないと考えられます。たとえあいさつしても声が小さければ相手には届きませんので、していないのと同じでしょう。
このような現場は、個人商店・個人プレーで仕事が進んでいて、“チーム”ではないといえます。隣の人の仕事に一切関心がない、だから会話もしないし連絡はメールで済ませるという間柄になっていきます。
「あいさつする」とは、本質的にはチームのメンバーがお互いに興味を持つことです。チームメンバーがお互いに興味を持つようになることが、現場に元気を取り戻す最初の一歩です。
サイン2：やらない理由ばかり言う
「私は良い施策と考えていますが、今は難しいです」「○○なので、できません」「○○になったら、できると思います」――。こうしたフレーズを現場で耳にしたことはありませんか？ これは「自分はできません」「自分はやりたくない」という意思表示です。
メンバー自らが「やりたい」と感じるためにも、まず身近で小さな行動を起こしましょう。「話し合い」です。
例えば、コードの品質が悪いチームにいきなり「コードの品質を上げろ」と言っても、やらない理由のオンパレードになるだけです。
なぜコード品質が悪くなるのかをメンバーと話し合い、原因を見つけて対策を考えることが先です。例えば「集中力が落ちて品質が悪くなった」という理由が出たのであれば、「50分コーディング、10分休憩」というように、簡単に実施できる対策を見つけて実施に移すようにします。
サイン3：「常識だよね」症候群
何か問題を起こした当人と話す際、「そんなの常識でしょう」「当たり前のことだろう」と話していませんか？
「常識」や「当たり前」は便利な言葉ですが、チーム内で影響力を持つ人が連発するとチーム全体の士気が低下します。結果、孤独感を強めるメンバーが現れ、ハラスメントに発展する可能性もあります。
暗黙知をないがしろにしない
人はそれぞれの経験や嗜好から知識を得て、それが価値観や行動を左右します。この知識、すなわち「暗黙知」はそれぞれ異なるものです。
何が常識で何が当たり前なのか、常にお互いの暗黙知を見える（確認できる）ようにする行動が必要なのです。暗黙知は理解してもらうのに多くの説明を要するため、意識合わせは面倒かもしれませんが、チームで動くためには全員で挑戦しなければならない活動の一つです。
サイン4：正解を探して行動しない
経験上、どの現場でも“正解を探し続けて、行動しない”ことがほぼ確実に起こっています。我々は小学校から大学までの教育で「必ず正解がある」と教えられ、短時間に多くの正解を導きだせる人を“優秀”としてきました。
ただ、世の中や社会、ビジネスに正解はありません。だから有効なやり方を自ら導き出す必要があるのです。
10年前に成功したやり方で、今も成功できるとも限りません。数年前にはなかったビジネスがあっという間に広まることは珍しくないのです。
正解を求めようとすればするほど、ビジネスのスピードを落とす足かせになります。そうではなく、小さくても仮説を立てて、行動し、結果（フィードバック）から次の行動を考えて実行する――。こうした姿勢を持つことが欠かせません。
小さい活動、小さいチームで足がかりを得て、少しずつ大きくしていくのです。正解主義は根が深く厄介ですが打破しましょう。
ただ、個人評価、チーム評価という人事制度にも関わる部分でもあります。どのような組織をどう評価するのかを考慮することも欠かせません。
行動を変えれば組織文化も変わる
皆さんにとって思い当たるようなサインはあったでしょうか。こうしたサインは組織の文化とは不可分で、長年の積み重ねから出てきたものと言えるでしょう。
四つのサインについて「どうすれば解消できるか」という行動を書きましたが、もちろん長年の組織文化を変えるのは周囲から協力を得られないことがあったりして大変です。
だからといって、変えなければいけないような状況になったとき、「変えられない」では話になりません。変えるべき時に変われない企業の行く末は想像できるのではないでしょうか。
組織文化は海面から見える氷山のほんの一部のようなもの（図2）。行動を変えてもすぐに組織文化が変わるわけではありません。
ですが、行動はいわばボディブローのようにじわじわと効果が出てくるものです。面倒でも小さな一歩からまずは行動していきましょう。
ただ、組織文化の変革にはゴールがありません。時代の変化に合わせて常に永遠に変化し続ける文化を受け入れる組織こそが強い組織・強いチームなのです。
DevOpsだからうまくいく？
一つのチームだけではなく、組織全体で行動を変えるためにはどうすればいいのでしょうか。各組織が前向きに協力してビジネススピードを上げるように組織文化を変えていき、各現場で働く人々が仕事を通じて生き甲斐や達成感を得るような元気な現場に変わるにはどうすればいいのでしょうか。
筆者はある現場の成功体験から、全体最適を実現できる「DevOps2.0」に着目しています。DevOps2.0はメンバーがお互いの専門性を尊敬して協力し合い、ビジネスの継続性という同じ目標を成し遂げるチームを目指します。自律には相互信頼が必要で、相互信頼があるとハラスメントの無い、明るく元気な組織になっていきます。
そもそもDevOpsは「開発系組織・運用系組織を一緒にして、ツールで自動化する」手法だと思われていますが、実はそれだけでは開発と運用の組織が個別最適に陥りやすいのです。
DevOpsを実践できるようにするための必須要素として「CALMSモデル」が定義されています（図3）。コラボレーションやコミュニケーションを推進する「Culture」、手作業を無くす「Automation」、サイクル周期を速める「Lean」、全てを計測する「Metrics」、経験を共有する「Sharing」の頭文字を取ったものです。
Automationがあるため、自動化ツールに話題が集中しがちですが、それ以外の項目は全ての人に関係します。つまり人の行動習慣を変える必要があるのです。次回以降、TMSやDevOps2.0で行動習慣を変えるためのやり方を解説していきます。
戦略スタッフ・サービス 取締役 エグゼクティブコンサルタント
