Raccoon Tech Blog [株式会社ラクーン 技術戦略部ブログ]

株式会社ラクーン 技術戦略部より、tipsやノウハウなど技術的な話題を発信いたします。

Sisimaiによるバウンスメール解析の自動化

こんにちは。管理チームのいとうです。
私は主にインフラの運用管理を担当しています。

今回は弊社でも利用している、"Sisimai" によるバウンスメール解析についてご紹介します。

大規模なメール配信を行っていると、ユーザのメールアドレス登録間違いや、メールアドレス変更の未通知などでバウンスメールが度々発生します。
少数であれば管理者がバウンスメールを確認し、対応を手動で行えばよいかもしれませんが、それが数十~数百アカウントともなれば、到底作業が追いつくはずもありません。
そこで、バウンスメール解析とその後の処理を自動化することで、管理者の負担を減らすことができると考えられます。

本記事では、まず一般的なメールシステムにSisimaiを利用した簡易的なバウンスメール解析アプリケーションを組み込むことで、バウンスメールの情報を扱いやすい形で集約するところまでを目標とします。
また、幾つかのパターンでバウンス解析を行い、結果がどのように出てくるのかについても検証したいと思います。

Sisimaiについて

Sisimaiは株式会社キュービックルート様が開発している、オープンソースのバウンスメール解析用ライブラリです。

製品URL: libsisimai.org

2016年9月8日現在の最新版はv4.18.0です。
mbox形式もしくはMaildir形式のメールを読込み、バウンスメールの内容を解析して出力することができます。
Ruby版とPerl版がリリースされていますが、今回の記事ではRuby版を使用しています。

Ruby版の環境条件

公式サイトにも記載されている通り、Ruby2.1以降もしくはJRuby9.0.4.0以降が必要です。
また、JSON出力用にojが依存ライブラリとしてインストールされます。

余談ですが、以前はbounceHammerという、バウンスメール解析ライブラリと管理用UIがセットになったプロダクトが存在していたのですが、こちらはEOLとなっています(2016年9月現在新規ダウンロードもできないようです)。

Sisimaiの導入

それでは早速Sisimaiを導入していきましょう。
今回は以下の環境で検証を行いました。

検証環境

  • CentOS 6.8
  • Ruby 2.3.1 p112
  • jq (必須ではありませんが、JSON形式の出力を見やすく整形するために利用します。)

  • 導入手順

    jqはCentOSの標準リポジトリには存在しないため、EPELから入手します。
    # yum -y install epel-release
    # yum -y install jq
    

    次にSisimaiを導入します。
    # gem install sisimai
    

    動作確認

    sisimaiの導入が完了したので、早速動作を確認してみましょう。
    sisimaiのgemが導入されたディレクトリ内にset-of-emailsというディレクトリがあります。
    こちらにテスト用に利用できるメールが格納されているので、利用します。
    以下に示すように簡単なワンライナーで、バウンスメールの解析を行うことができます。
    出力される内容は、Sisimaiのデータ構造に詳しく説明されていますので、そちらを参照ください。

    # ruby -r 'sisimai' -e 'puts Sisimai.dump($*.shift)' "set-of-emails/maildir/bsd/x1-01.eml" | jq .
    [
    {
      "timestamp": 1272551685,
      "recipient": "kijitora@example.co.jp",
      "addresser": "shironeko@example.jp",
      "timezoneoffset": "+0900",
      "deliverystatus": "5.0.910",
      "diagnostictype": "",
      "diagnosticcode": "User unknown",
      "subject": "Nyaaaaan",
      "action": "",
      "reason": "filtered",
      "listid": "",
      "alias": "",
      "rhost": "",
      "lhost": "",
      "token": "40c0e0d40e8d1192fb7e4a8e52eee2725fd91671",
      "messageid": "000000000000000000000000000000000000@example.jp",
      "replycode": "",
      "smtpagent": "X1",
      "softbounce": 1,
      "smtpcommand": "",
      "destination": "example.co.jp",
      "senderdomain": "example.jp",
      "feedbacktype": ""
    }
    ]
    

    jqを通すことで、JSONが整形されるのでわかりやすいですね。
    これでSisimaiを利用する環境の準備はOKです。

    バウンスメール解析用プログラムを作る

    それではsisimaiを利用して、バウンスメール解析を自動化するプログラムを作成してみます。
    このシステムでは、解析したデータをデータベースに蓄積していく仕組みを取るようにします。
    今回は、手頃なところでMySQLを利用することにしました。Sequelというgemを利用することで、
    簡単にテーブルにinsertを行えるので、こちらを利用します。
    追加でsequelとmysql2のgemをインストールしておきましょう。
    また、MySQLに以下のような定義のテーブルを持つスキーマを作成しておいてください。

    スキーマ名 sisimai
    テーブル名 bouncemails

    カラム名データ型制約
    idINTPRIMARY KEY, AUTO_INCREMENT
    timestampINT
    recipientVARCHAR(255)
    addresserVARCHAR(255)
    timezone_offsetVARCHAR(32)
    delivery_statusVARCHAR(32)
    diagnostic_typeTEXT
    diagnostic_codeTEXT
    subjectTEXT
    actionVARCHAR(32)
    reasonVARCHAR(32)
    listidVARCHAR(255)
    aliasVARCHAR(255)
    rhostVARCHAR(255)
    lhostVARCHAR(255)
    tokenVARCHAR(255)
    message_idVARCHAR(255)
    reply_codeVARCHAR(32)
    smtp_agentVARCHAR(32)
    softbounceINT
    smtp_commandVARCHAR(32)
    destinationVARCHAR(255)
    sender_domainVARCHAR(32)
    feedback_typeVARCHAR(255)

    次に検証に利用するプログラムを以下に示します。検証用のため、エラー処理などは省いています。

    バウンスメール取り込み用プログラム

    メールボックスのあるサーバに解析プログラムを配置し、直接メールを取り込んでも良いのですが、今回はリモートのサーバからPOP3でアクセスし、メールを取得することにしました。
    以下のプログラムでバウンスメール解析用サーバの適当なディレクトリにメールファイルをダウンロードしてきます。

    bounce-receiver.rb
    # coding: utf-8
    require 'net/pop'
    
    basedir = '/var/apps/bounce-parser'
    mailstore = basedir + '/mailstore'
    
    host = 'mail.example.com'
    port = 110
    user = 'bounce'
    password = 'bounce'
    
    # Connect to pop3 server
    pop = Net::POP3.new(host, port)
    pop.start(user, password)
    
    # Receive mails
    unless pop.mails.empty?
      pop.mails.each do |mail|
        filename = "#{mailstore}/" + Time.now.strftime('%Y%m%d%H%M%S%L') + ".eml"
        fd = File.open(filename, 'w')
        fd.write mail.pop
        mail.delete
        sleep 1
      end
    end
    
    pop.finish
    

    次に、Sisimaiでメールの解析を行うプログラムのサンプルです。
    先ほどダウンロードしたメールのディレクトリを指定することで、ディレクトリ内に存在するメールを一括で解析し、結果をSisimai::Dataオブジェクトに変換してくれます。
    このオブジェクトに対しdamnメソッドを実行すると、hash形式で結果を取り出すことができます。
    取り出したデータはsequelのinsertメソッドを利用し、データベースに投入されます。

    bounce-parser.rb
    # coding: utf-8
    require 'sisimai'
    require 'sequel'
    require 'mysql2'
    
    basedir = '/var/apps/bounce-parser'
    mailstore = basedir + '/mailstore'
    database = 'bounce'
    host = 'localhost'
    port = 3306
    user = 'bounce'
    password = 'bounce'
    encoding = 'utf8'
    
    parsed_records = []
    
    bounce_mails = Sisimai.make(mailstore)
    
    unless bounce_mails.nil?
      bounce_mails.each do |bounce_mail|
        parsed_records << bounce_mail.damn
      end
    else
      puts "mail not found"
      exit(0)
    end
    
    DB = Sequel.mysql2(
           :database => database,
           :host     => host,
           :port     => port,
           :user     => user,
           :password => password,
           :encoding => encoding
         )
    
    unless parsed_records.nil?
      parsed_records.each do |record|
        DB[:mail_logs].insert(
          :timestamp       => record['timestamp'],
          :recipient       => record['recipient'],
          :addresser       => record['addresser'],
          :timezone_offset => record['timezoneoffset'],
          :delivery_status => record['deliverystatus'],
          :diagnostic_type => record['diagnostictype'],
          :diagnostic_code => record['diagnosticcode'],
          :subject         => record['subject'],
          :action          => record['action'],
          :reason          => record['reason'],
          :listid          => record['listid'],
          :alias           => record['alias'],
          :rhost           => record['rhost'],
          :lhost           => record['lhost'],
          :token           => record['token'],
          :message_id      => record['messageid'],
          :reply_code      => record['replycode'],
          :smtp_agent      => record['smtpagent'],
          :softbounce      => record['softbounce'],
          :smtp_command    => record['smtpcommand'],
          :destination     => record['destination'],
          :sender_domain   => record['senderdomain'],
          :feedback_type   => record['feedbacktype']
        )
      end
    end
    

    これで結果の解析からデータの集約まで行うことができました。
    2つの簡易なプログラムで一通りの作業を行えるので楽ですね。
    次のセクションでは、実際にメールシステムに組み込んで検証を行ってみたいと思います。

    メールシステムに組み込んで検証してみる


    よくあるシステム構成パターンに組み込んで動作を確認してみたいと思います。
    今回は検証用に以下のようなメールシステムを構築してみました。
    LAN内にクローズなメール環境を構築したため、他にもアクターは存在しますが、単純化するため一部を省略しています。
    overview
     
    次にサーバの役割をドメイン毎に軽く説明します。

    example.comのメールシステム

    こちらがメール送信元のメールシステムになります。
    メールゲートウェイサーバがメールボックスも受け持つ、シンプルな構成です。
    また、バウンスメール解析用のプログラムを配置したサーバを用意しています。

    メールゲートウェイサーバ
  • postfix
  • dovecot

  • バウンスメール解析サーバ
  • bounce-receiver.rb (pop受信プログラム)
  • bounce-parser.rb (解析プログラム)

  • example.co.jpのメールシステム

    こちらが送信されたメールの宛先となるシステムです。
    外部との接点になるゲートウェイサーバと配信用サーバは別に分かれているという想定です。

    メールゲートウェイサーバ
  • postfix
  • メール配信サーバ
  • postfix
  • dovecot

  • 正常にメールが配信される場合

    まずはメールが正常に配信される場合を見てみましょう。
    delivered

    1. example.comのGWサーバはexample.co.jpのGWサーバにメールをリレーします。
    2. メールを受け取ったexample.co.jpのGWサーバは、自ドメイン宛のメールなので、メール配信サーバへとリレーを行います。
    3. メール配信サーバはGWサーバからのSMTP接続を受け付け、対象のアカウントが存在することを確認し、メールをローカルのメールボックスへ配送します。

    メールがバウンスとなる場合

    次にメールがバウンスとなる場合を見てみましょう。
    メールがバウンスになるパターンは様々ですが、ここでは宛先アカウントが存在しない場合のバウンスメールの流れを例に取ります。
    bounce

    1. example.comのGWサーバはexample.co.jpのGWサーバにメールをリレーする。
    2. メールを受け取ったexample.co.jpのGWサーバは、自ドメイン宛のメールなので、メール配信サーバへリレーしようとする。
    3. 配信サーバはexample.co.jpのGWサーバのSMTP接続を受け付けるが、対象のアカウントが存在しないので、エラーを通知する。
    4. example.co.jpのGWサーバは元メールのEnvelope From宛にバウンスメールを送信する。
    5. example.comのGWサーバはメールを受け取り、対象アカウントのメールボックスにストアする。
    6. バウンスメール解析サーバは、定期的にバウンスメール受信用アカウントのメールボックスをチェックし、取り込みと解析を行う。
    流れがやや複雑ですが、このようにして送信したメールがバウンスメールとなって戻ってきます。

    パターン別でバウンス解析結果を検証する


    今回は以下の3パターンで返されたバウンスメールに対し、Sisimaiの解析結果がどう変化するかを検証してみます。

    パターン1: ハードバウンス
    宛先となるアカウントが存在しなかったり宛先のドメインがないなど、
    恒久的な理由でメール配送されず戻ってきたパターンです。

    パターン2: ソフトバウンス
    宛先となるアカウントは存在するがメールボックスの容量が超過しているため受信できないなど、
    一時的な理由でメールが配送できず戻ってきたパターンです。

    パターン3: ML配信におけるバウンス
    1対1のパターンだけでなく、メーリングリストにメールを送信するパターンも確認してみます。
    今回はML内の一部のアカウントが存在しないという想定で試してみます。

    1. ハードバウンス

    ますはじめにハードバウンスのパターンを確認してみます。
    以下のように、存在しない宛先に向けてメールを送信してみます。

  • 送信元: test@example.com
  • 宛先: john@example.co.jp(実際には存在しない宛先)

  • このパターンでは宛先john@example.co.jpが存在しないので、ハードバウンスとなってメールが返ってくると想定されます。
    では、解析プログラムを通した結果をDBから参照してみましょう。

    pattern1

    結果のカラム数が多いため5行に分割していますがご了承ください。
    バウンスメールに関して、かなり詳細な情報が取得できているようですね。
    この結果を元に、バウンスメールの内容をざっくりと解析してみたいと思います。
    1. addresserとrecipientの内容から、test@example.comが送信元でjohn@example.co.jpが宛先だということがわかります。
    2. reply_codeおよびdelivery_statusが550/5.1.1ということから、「宛先ユーザアカウントが正しくないためメール送信に失敗した」ということがわかります。
    3. softbounceの値は0(ハードバウンス), 1(ソフトバウンス), -1(不明)の3値を取りますが、ここでは"0"となっているので、ハードバウンスであることがわかります。
    4. rhost, lhostに着目するとバウンス発生時にSMTP通信を行っていたリモートホストとローカルホストが分かるので、メールの経路上どこでバウンスになってしまったかがわかります。
    確かに宛先ユーザが存在しないため、ハードバウンスになって返ってきていることがわかりますね。

    2. ソフトバウンス

    次にソフトバウンスのパターンを検証してみます。
    以下に示す宛先に対し、メール配信サーバの受信可能サイズを制限して、メールを送信してみます。

  • 送信元: test@example.com
  • 宛先: paul@example.co.jp

  • このパターンでは、宛先paul@example.co.jpは存在しますが、メール配信サーバの受信サイズ制限に引っかかってしまいます。
    ただ、メールサイズを小さくすれば正常に配信が可能ですので、ソフトバウンスとして返ってくることが想定されます。
    では、解析プログラムの結果を確認しましょう。

    pattern2

    1. addresserとrecipientの内容から、test@example.comが送信元でjohn@example.co.jpが宛先だということがわかります。
    2. reply_codeはNULL(値が取得できなかった)ですが、delivery_statusが5.3.4でありdiagnostic_codeの'message size xxxx exceeds size limit xxx of server ...'の記述から、宛先メールサーバのサイズ制限に引っかかっていることがわかります。
    3. softbounceの値が"1"となっているので、ソフトバウンスであることがわかります。

    3. ML配信におけるバウンス

    最後にメーリングリストにあててメールを送信したパターンを確認します。

  • 送信元: test@example.com
  • 宛先: ml@example.co.jp (john@example.co.jp, paul@example.co.jpのエイリアス)

  • このパターンではml@example.co.jpはjohnとpaulのアカウントのaliasとなっています。
    しかしながらjohnのアカウントは存在しないため、johnに送信されたメールはハードバウンスとして返ってきます。
    次に解析プログラムの結果を確認します。

    pattern3

    パターン1の場合と似た内容ですが、recipientはjohn@example.co.jpに、aliasはml@example.co.jpになっています。
    この内容から、エイリアスから転送を受けたアカウントが存在しないためバウンスメールが発生していることがわかります。
    また、softbounceが"0"であることから、ハードバウンスであることがわかります。

    まとめ

    今回はSisimaiによるバウンスメール解析について紹介しました。
    実際のメールシステムを模した構成で、3パターンでバウンスメール解析の検証を行ってみましたが、いかがでしたか?
    ハードバウンス・ソフトバウンスの判定ができたり、ML所属アカウントからのバウンスもいい感じに解析できるので、
    バウンスメール処理の自動化に活用できるのではないかと思います。
    ユースケースとしては、

  • 定期バッチで特定アカウントからのバウンスメールの数が閾値を超えたら、メール配信を停止する
  • ユーザのメールアドレス登録間違いを検知し、管理者に通知する
  • 日々バウンスデータを取り込み、送達率向上の施策を取るための材料にする

  • など、様々な使いみちが考えられます。
    導入も簡単なので、ぜひ一度試してみてはいかがでしょうか?

    自動化やスクレイピングに使えるやつ XPath

    開発チームの下田です。

    XMLの特定の部分を指定するためのXML Path Language(以下、XPathと表記します)という言語があります。
    HTMLを解析して自動テストの作成やスクレイピング、XML設定ファイルの書き換えに使います。簡単な割に、覚えておくと地味に便利なやつです。

    とりあえず書いてみる

    何はともあれ、覚えるためには書いてみます。

    ブラウザが一番手軽なXPathの実行環境だと思います。FirefoxとChromeはXPathが実装されています。コンソールで次のコードを実行してみてください。コンソールはF12を押せば開きます。

    document.evaluate('//html/head/title', document, null, XPathResult.STRING_TYPE, null).stringValue

    正常に実行できれば、開いているページのタイトルが表示されます。
    続きを読む

    AWS LambdaとAPI Gatewayを利用し、PagerDutyのインシデント発生時にSlackに専用チャンネルを作成する #3

    こんにちは、インフラ及びシステム運用を担当している田中です。

    前回の記事ではPagerDutyのWebhookをLambda関数で受け、SlackのIncident専用のチャンネルを作成してメッセージをpostしたり、IncidentがResolvedになったら専用チャンネルをarchiveしたりするところまでご紹介しました。

    大まかにまとめると、下記のシーケンス図のような仕組みになります。

    sequence_1

    しかし、専用チャンネルまで作成したのにpostしたメッセージは簡単なテキストだけで、見栄えもぱっとしなければ、大した情報も含まれていませんでした。

    そこで今回は、Slackにpostするメッセージの見栄えを改善したり、障害対応に必要な情報をメッセージに含めるなど、前回作ったプログラムに機能を追加していきます。

    また、せっかくLambdaを使用しているのに他のAWSの機能を使わないのはもったいないので、Node.jsのAWS SDKを利用してAWSの機能を利用する方法についても説明していきたいと思います。
    続きを読む

    ゼロから始める新人エンジニア研修

    こんにちは。たむらです。
    今回は、ラクーンで行っている「新人エンジニア研修」について書きたいと思います。
    2016年春に入社した新人も今まさに受講しているホットなトピックになっています。

    ◆新人研修を用意した背景

     ラクーン技術部では数年前迄はほぼ新卒採用がなく、中途採用メインで仲間を増やしていました。その為、ある程度の開発力や調査力が新人さん側にあることも多くて、教育はいきなりOJT。「分からないところは聴くか、自分で調べていってね~」という感じでいわゆる研修にあたるものは無きに等しい状態(注.1)でした。「経験者だし、調査能力はエンジニアの能力としても必要だからその鍛錬を含んでいるんだ」と言えばそれっぽく聞こえますが、受け入れ側としてはやはり怠慢な部分が大きかったのではないかと思います。当然ですけど、環境面やラクーン独自の仕様・ポリシー、概要など始めに教えておけばすむことや、聴いた方が効率が良いことは沢山ありますもんね。

     そして時代は流れて、2015年度より技術部でも新卒採用を定期的に行うようになりました。さすがに中途採用メインだった時の様にいきなりのOJTではなく、誰もが必要最低限の知識を身に付け、成長の階段を素直に登れる仕組みを用意する必要があると考えられるようになりました。また、中途採用市場でも時代的な変化があり研修の必要性が高まっていることも後押ししました。というのは、昔であればSIerで開発を経験していればLAMPに代表されるような、何かしらのプログラム言語+RDBMS+Linux+HTMLを経験していることが多かったのですが、トレンドの技術も非常に多様になり、RDBMSは触ったことないけどNoSQLは知ってるなどという人材もでてきて中途採用でも一定の研修ニーズが生まれていたからです。

    注.1 会社的な社会人研修やサービスについての研修は勿論あります。技術的なスキルを身に付ける体系だった研修がないという意味です。


    ◆研修のゴール

     上記の様な背景を踏まえて、研修のゴールを以下の様に定義しました。

    最低限のプログラミング能力の修得ができる

     研修の主目的その1。弊社で実際に利用している言語やフレームワークを中心に研修します。研修にも時間的な制約がある中、知識の深さと広さのどちらをとっていくかも悩ましいところですが、より深い知識や理解をする部分は個人の努力で補える部分が大きいと思うので、どちらかといったら「広さ」をとる方向でいくこともポリシーにしています。

    最低限のシステム開発の仕組みを理解できる

     研修の主目的その2。こちらも上記と同様弊社で実際に利用しているものをベースに研修します。開発フローや利用している開発ツールなどの他、テスト環境やCI環境など、実用的な知識を得る部分です。

    エンジニアとしての問題解決の思考を習得できる

     どの職種でもそうだとは思いますが、業務では様々な問題に直面することになります。その際に自分で解決していける様に問題解決の方法を知っておくことも重要なことです。Webでの調べ方や問題の切り分け方などの他、ログの解析やデバッグの仕方などを研修を通して学んでもらいます。この問題解決能力は得てして経験やセンスで身につける部分だと考えられがちかもしれませんが、実際には学んで得る部分が殆どなんじゃないかと思っています。

    成長を実感でき、自信を持てる

     やはり研修をやり終わった時には、自信をもって業務に臨める様な「やる気」が形成できていて欲しいと思います。当然スキル的な意味もありますが、周りのメンバーとのコミュニケーション関係が構築できることだったり、組織として受け入れる姿勢があることも重要なポイントなのではないかと思っています。

    ◆実際の研修の概要

     では、実際に研修はどの様にやっているかというと、一言で言ってしまえば「個別指導+スタンプラリー形式の研修」を行っています。

    具体的には・・・

    • 1新人1ユニットチーム過去記事参照)で、ユニットチームがメンターになる
    • 学んでもらうべき項目は習得項目としてリストで管理
    • 習得項目がまんべんなく学べる研修課題を用意
    • 研修課題の区切りや終了時にはレビュー会を開き、フィードバックを実施
    • 習得項目を十分マスターできていたらメンターは終了印を押す
    • 苦手な部分や詰まっている部分があればフォローアップを行う
    • 全ての習得項目の終了印を集めたら研修修了

    という様なものにしています。研修の進捗は個人に合わせたものになるので、できる部分はさっさと、余り知らない部分はじっくり取り組むことができます。また、新人さんの研修の進捗状況や質問内容、体調含めた様子などすべて記録を残し、研修後のフォローや研修自体のブラッシュアップができる様にしています。

    習得項目リスト
    0621_sheet
    スタンプラリーシートとして本人にも渡していて、何を学んでもらいたいかの他、今の研修の状況や自分の成長が把握できるようにしています。タイトルは・・・まぁ遊び心で(笑)。


    研修課題の準備
    0621_make
    シニアエンジニアが真・善・美に適った
    (?)課題とその模範開発例を作ります。実業務ではなく研修課題をしっかり用意することで習得項目に沿った体系的な研修を実施することができます。また、業務の掛け持ちで実施するメンター側の負担を減らすことにも繋がります。


    研修風景
    0621_kensyu2
    メンターのとなりで研修します。説明+KPT用のホワイトボードも近くに置いてます。

    メンターとソースを確認しつつ振返り中
    0621_kpi
    朝会、夕会を日次で開き、メンターと本日やることの確認やKPTによる振返りを行っています。
    KPTは最終的に自身の成長を視覚的にみせ、自信に繋がることを狙っています。


    ◆研修をやってみて

     実はこの研修ですが、昨年位から試行錯誤しつつ準備を始めて今年初めて運用しているできたてホヤホヤのものです。冒頭に書いた通り、6月現在で春入社の新卒エンジニアがまさに今受講しています。まだブラッシュアップどころか終わってもないのを偉そうに書いてしまいすみません
     ただ、感触としては研修の仕組みも教育としても概ね順調にいっているようです。勿論、改善点も今後色々出てくると思うので、適宜見直しつつより良いものにしていきたいと思っています。

     なお、今回弊社で用意した研修ですが、研修の骨子は2014/02/13 Developers Summit2014で登壇された関口亮一さんの講演「新卒エンジニア研修でできることすべきこと」をめちゃくちゃ参考にさせて頂いております。非常に洗練された研修と講演だったので是非そちらもご参照下さい。

     以上、ラクーンの新卒エンジニア研修についての紹介でした。

    技術雑誌のススメ

    こんにちは技術戦略部の釣り人の人です。

    新社会人のみなさん。就職おめでとうございます。もちろんラクーンにも新卒生が入社してくれました。嬉しいことにその中には若手エンジニアが2名含まれています。

    さて、この時期の新卒若手エンジニアのみなさんは研修期間真只中かと思います。研修が終わると業務が待っています。目の前の業務をこなしつつ、技術を身に付けて先輩エンジニアに追いつくことに精一杯の毎日となるでしょう。
    しかし私達が住んでいる「ウェブ業界」は日々新しい技術が生まれては消えていくサイクルがとにかく短いので、せっかく勉強した技術が明日使われなくなったということも珍しくないし、今勉強しているその技術や手法が実は時代遅れだったということもあるかもしれません。技術情報のトレンドを追いかけつつ取捨選択できることもエンジニアには必要なスキルとなります。

    そんな無茶なことがよく言われています。

    ご安心してください。

    いきなり取捨選択なんて出来なくて当然です。

    そんな若手エンジニアが情報収集する手段の提案として「技術雑誌を読むこと」をオススメします。

     

    技術雑誌の特徴

    技術雑誌を読むメリットとなる代表的な特徴を私見として3つあげます。

    1.毎年若手エンジニア向けの基本的な技術入門記事が掲載されている。
    2.トレンドに沿ったオープンソース系技術の入門記事がある。
    3.ウェブ業界で有名な現場エンジニアが現場の事例を紹介する記事がある。

    基本的な技術入門記事は時代やトレンドに合わせてブラッシュアップされているので若手エンジニアでなくても発見があり侮れない記事です。知識のアップデートや新人研修のネタとしても使える記事は多いと思います。


    技術雑誌の紹介

    ラクーンが定期購読している代表的な3冊の技術雑誌の特徴を紹介します。


    ウェブ系エンジニアであればとりあえずこの雑誌に目を通しているだけでトレンドとなっている技術情報は入ってきます。ウェブアプリケーションの開発エンジニアに向けた記事の量が多いのですが、インフラエンジニアも参考にできる記事も多いのが特徴です。また現場エンジニアがライターをされている事例紹介もよく掲載されています。


    こちらもウェブ系エンジニア向けの雑誌です。WEB+DB PRESSよりもインフラエンジニアに向けた記事が多めなのが特徴です。私が若手だった頃はこちらとUNIX MAGAZINE、UNIX USERの3誌が必読書でした。まだまだ続いてほしい雑誌です。


    Windows系の情報が多く、社内情シス部門と呼ばれるエンジニアにも好まれる雑誌です。雑誌タイトルのとおりネットワークに関するインフラエンジニア向けの情報が広く掲載されています。ライトな内容の記事が比較的多いのも特徴です。



    特にこの時期は若手エンジニアに向けた記事が多く掲載されているので複数誌に目を通しておくことをオススメします。



    情報の収集の方法としては技術雑誌の他にも、「技術専門書」、「ニュース系ウェブサイト」、「Qiitaや有名エンジニア個人のブログやSNS」、「技術勉強会やセミナーイベントへの参加」といったものがあります。

    若手エンジニアのみなさんは、是非いろいろと試して自分に合った情報収集や勉強方法を見つけて下さい。


    ちなみにラクーンでは「技術サポート制度」というものがあり、各エンジニア毎に年間10万円の補助金が用意されています。そのため毎月数冊の技術雑誌と技術書、数回のイベント参加費を会社に請求してもまだ余りがありそうです。あら素敵。
     
    記事検索