学ぶ機会を待たない。社員が勉強会をつくる会社で、知識はどう広がるのか
「AWSのことを、もう少し分かるようになりたい」
「SQLを読めなくて、確認に時間がかかっている」
「SAP BASISとABAPの違いを、うまく説明できない」
現場にいると、こうした「分からない」が出てきますよね。
研修を受けたから気づくのではありません。目の前の仕事を進めようとして、手が止まったときに見えてきます。
説明を読んでもシステムの構成がつかめない。障害が起きても、どこから確認すればよいか分からない。専門の担当者へ聞きたいけれど、何を質問すればよいのか整理できない。一人で資格の勉強を始めたものの、途中で止まってしまうこともあります。
必要な知識は、会社の研修計画より先に、現場で姿を現すことがあります。
では、その学びを会社が用意してくれるまで待つのでしょうか。
ディーシステムでは、必要だと感じた社員が、自分たちで勉強会や学習会をつくることがあります。
扱うテーマは、データベースやSQL、AWS、Linux、コンテナ、SAPなど。資格試験の学習や、他のプロジェクトで得た事例を共有する場もあります。
ただ、勉強会を開いたこと自体が成果ではありません。
そこで得た知識が、現場での確認や判断をどう変えたのか。別の社員や、別の案件でも使える形になったのか。
学ぶ場は、そのための途中にあります。
必要なテーマは、現場の「分からない」から生まれる
何を学ぶかを決めるとき、研修一覧から興味のある講座を選ぶ方法もあります。
それも、一つの学び方です。
でも、現場で必要になるテーマは、もう少し切実な形で現れることがあります。
顧客へ説明しようとして言葉に詰まった。障害の原因を調べても候補を絞れなかった。専門の担当者から説明を受けたものの、前提知識が足りず、内容を理解できなかった。
新しい案件へ入る前に、そこで扱う技術を知っておく必要が出てきたり、他のプロジェクトでは同じような業務をどう進めているのか知りたくなったりすることもあります。
そんな経験が、「次はここを学びたい」というテーマになります。
学ぶテーマは、研修一覧から選ぶだけのものではありません。現場で迷ったことが、次に何を学ぶべきかを教えてくれます。
たとえば、SQLを読めずに確認へ時間がかかったとします。
このとき、SQLの構文を覚えることだけが目的ではありません。
どのデータを見ればよいのか。検索条件によって結果がどう変わり、その処理が業務のどこにつながっているのか。
そこまで見えるようになると、単に技術知識が増えるだけでなく、現場での確認方法そのものが変わります。
学びの入口は、「知識を増やしたい」だけではないんですよね。
今の仕事を、もう少し前へ進めたい。
その気持ちから生まれることがあります。
技術を深めると、質問の仕方も変わる
勉強会では、データベースやSQL、AWS、Linux、コンテナ、マイクロサービス、SAP BASIS、SAP ABAPなど、さまざまな技術を扱います。
こう聞くと、「全部、自分でできるようになるための勉強なのかな」と思うかもしれません。
でも、必ずしもそうではありません。
すべての技術を、一人で扱えるようになる必要はないんです。
専門外の分野でも、システムがどのような構成になっているのかが分かれば、障害が起きたときに確認すべき領域の見当をつけられます。
専門の担当者へ何を聞けばよいかを整理し、顧客に対しても、自分が説明できる範囲と確認が必要な範囲を分けて伝えられるようになります。新しい技術を、改善案の一つとして比較することもできます。
そこまで進めば、現場での動き方は変わります。
たとえば、AWSについて詳しくない担当者が、クラウド上の障害へ対応するとします。
何も分からなければ、「動きません」と専門担当者へ渡すしかありません。
少しでも構成を理解していれば、ネットワークなのか、権限なのか、インスタンスなのか、確認すべき候補を整理できます。
自分で解決できなくても、
「この設定変更の後から接続できなくなっています」
「権限とネットワークまでは確認しています」
と伝えられれば、次の担当者も動きやすくなります。
すべてを自分で解決できるようになる必要はありません。専門家へ相談するときに、何を確認し、何を伝えるべきか分かるだけでも、現場での動き方は変わります。
技術学習は、専門家になる人だけのものではありません。
専門家と仕事を進めるためにも、基礎知識は役に立ちます。
一人では続けにくい学びを、場で支える
勉強を始めたときは、やる気があるんですよね。
教材を用意して学習計画を立て、最初の数日は順調に進む。
でも、仕事が忙しくなったり、分からない箇所が増えたりすると、少しずつ手が止まってしまいます。
一人で学び続けるのは、簡単ではありません。
そこで、もくもく会や資格学習会のような場が役に立ちます。
同じ時間に集まり、最初に今日取り組むことを言葉にした上で、それぞれの学習を進める。分からないことがあれば質問し、最後にどこまで進んだかを共有します。
学ぶ内容は一人ひとり違っていても、「この時間は学ぶ」と決めることで、止まっていた学習を再開しやすくなります。
基本情報技術者試験のように範囲が広い学習では、どこから手をつければよいか迷うこともありますよね。
同じ試験を学んでいる人がいれば、使っている教材や、理解しにくかった分野について話せます。自分だけが止まっているように感じていたところが、ほかの人も迷う場所だと分かることもあります。
学習会の価値は、答えを教えてくれる人がいることだけではありません。
学ぶ時間を確保し、目標を口にして、途中で止まっても戻るきっかけを持てること。
一人では続けにくい学びを、場が少し支えてくれます。
会社が用意する環境と、社員がつくる場
会社は、資格取得の支援やスキルアップ支援制度を用意しています。開発言語を学べる環境もあり、全社員が申請によって利用できるようになっており、多くの主要言語を学ぶことができるような環境になっています。
勉強会や知識共有も、評価対象となる行動の一つです。学んだことを実務へつなげる機会をつくることも、会社の役割です。
しかし、どの技術で困っているのか。次の案件へ向けて何を知りたくて、現場ではどのような質問が増えているのか。
それを最初に知るのは、仕事をしている社員です。社員がテーマを持ち寄り、勉強会やもくもく会をつくります。その中で質問しやすい関係を育て、学んだことをどう現場へ戻すか考えます。
会社が用意する環境と、社員がつくる場には、それぞれ別の役割があります。
会社が研修を用意するだけでも、社員の自主性だけでも、学習文化は成り立ちません。
会社は始めやすい環境をつくり、社員は現場で必要なテーマを見つけて動く。
どちらか片方だけでは、学びは広がりにくいと考えています。
他のプロジェクトを知ると、「別のやり方」が見えてくる
一つの現場に長くいると、その現場の方法が当たり前になります。
問い合わせは決められた順番で確認し、障害が起きたら特定の担当者へ連絡する。運用変更については、いつもの会議で決める。
それが悪いというわけではありませんが、別の現場では、違う進め方をしているかもしれませんよね。
ディーシステムでは、技術の勉強会だけでなく、他のプロジェクトでどのような仕事をしているのかを共有する場もあります。
別の運用方法や役割分担、顧客から寄せられた要望、障害発生時の確認手順、業務改善の進め方。
こうした事例を知ることで、今の方法が唯一ではないと気づけます。
成功した話だけが役に立つわけでもありません。
判断に迷ったことや、うまく進まなかったこと。改善したかったけれど、条件が合わずに実現できなかったことも、別の現場では判断材料になります。
「別の案件では、こうしていた」
「この方法はうまくいったけれど、この条件では使えなかった」
そうした知識があれば、目の前の課題に対して考えられる選択肢が増えます。
事例共有は、他のプロジェクトを知るための見学会ではありません。
自分の現場を、別の角度から見直すための材料になります。
勉強会で分かっただけでは、学びはまだ途中
勉強会に参加すると、知らなかった用語が分かるようになり、技術の仕組みも少し見えてきます。質問できる相手が見つかることもあります。
それは、大切な変化です。
でも、そこで終わってよいのでしょうか。
勉強会で分かったことが増えても、現場での確認や判断が変わらなければ、学びはまだ途中です。
学んだSQLを使って必要なデータを確認できるようになった。AWSの構成を知ったことで、障害時に確認する候補を絞れるようになった。
SAP BASISとABAPの違いを理解し、誰へ何を相談すべきか分かるようになったり、コンテナやマイクロサービスの考え方を知り、新しい構成を改善案として比較できるようになったりすることもあります。
他のプロジェクトの事例を、自分の現場の見直しへ使うこともできます。
こうして現場での動きが変わったとき、勉強会で得た知識が仕事へ戻ります。
必ず、大きな改善につながるわけではありません。すぐに新しい技術を導入できるとも限りません。
それでも、質問が具体的になり、確認する順番が変わる。顧客へ説明できる範囲が増え、複数の方法を比べられるようになる。
そうした小さな変化が、次の仕事につながります。
勉強会の成果を、開催回数や参加人数だけで見ると、この変化は見えにくいですよね。
見るべきなのは、学んだ後に、誰の仕事がどう変わったかです。
開催して終わらせず、次の行動へ戻す
現場で迷ったとき、何が分からなかったのかを振り返ると、不足している知識が見えてきます。
その内容を勉強会や学習環境で学び、現場へ戻って試した後、結果をもう一度振り返る。
学習は、この循環の中にあります。
ディーシステムでは、Dsystem Cycleを通じて、現場で得た経験を次の行動へ戻すことも大切にしています。
何がうまくいき、何に失敗したのか。どのように判断し、顧客からどのような反応があったのか。そこから何に気づき、次は何を変えるのか。
それらを振り返ることで、一度の経験が次の学習テーマになります。
勉強会で学んだ内容も同じです。
試したものの思ったように使えず、別の知識が必要だと分かることがあります。専門の担当者へ質問したことで、自分の前提理解が足りていなかったと気づくこともあります。
その結果を共有すれば、次の勉強会のテーマになるかもしれません。
学習の場は、現場から離れた場所ではありません。現場で生まれた疑問を持ち込み、学んだことをまた現場へ戻す、循環の途中にあります。
勉強会を開いた、参加した、資料を読んだ。
そこで終わらず、次に何を試すのかまで考えることで、学びは一度のイベントではなくなります。
教える人も、そこで学び直している
勉強会を開く人を見ると、その分野を何でも知っている人のように感じるかもしれません。
でも、教える側も、すべてを理解しているわけではありません。
誰かへ説明しようとすると、自分が曖昧に理解していた部分が見えてきます。
なぜこの設定が必要なのか。初めて聞く人へ、この用語をどう説明するのか。その説明を理解するために、どのような前提知識が必要なのか。
質問を受けたときに、自分の説明に足りないものが見つかることもあります。
説明の準備をする中で、自分の知識も整理し直されます。
参加者から、自分が考えていなかった質問が出ることもあります。分からないことは、その場で分からないと伝え、後で調べて次の機会に共有する。
それも学習です。
だから、勉強会は、詳しい人が一方的に教える場だけではありません。
教える人も、質問する人も、聞いている人も、それぞれ違う場所で学んでいます。
開催者だけが主人公ではないんですよね。
質問した人の一言で、全員の理解が深まることもあります。
知識を、一人の中に閉じない
会社が学び始めやすい環境を用意し、社員が現場で感じた不足からテーマを見つける。
勉強会やもくもく会で周囲と学び、現場へ戻って試す。その結果を共有し、別の社員や別の案件へ渡していく。
ディーシステムの学習文化は、この流れの中にあります。
勉強会がたくさん開かれているだけで、学習文化が生まれるわけではありません。
社員が自主的だからといって、自然に知識が広がるわけでもありません。
現場の「分からない」が学習テーマになり、学んだことが仕事へ戻り、その経験が次の人へ渡っていく。
その循環が続くことで、個人の学習が組織の知識になります。そして、その知識が顧客の課題に対する確認や判断、選択肢へ変わります。
学ぶ場をつくることが成果なのではありません。そこで得た知識が現場での確認や判断を変え、別の社員や別の案件でも使える形になったとき、個人の学習は組織と顧客への価値へ変わります。
学びを、現場と周囲へ戻す
分からないことが出てきたとき、自分だけで抱えるのか。誰かが教えてくれるのを待つのか。それとも、周囲と学べる場をつくるのか。
ディーシステムでは、会社が用意する学習環境に加えて、社員が現場で必要だと感じたテーマを持ち寄り、学び、共有する取り組みがあります。
どのような人が、どのように知識を広げ、仕事へつなげているのか。ディーシステムの働き方や人材育成については、採用情報でも紹介しています。
