さて、そんなmmjの何が魅力的なのか？私なりの視点でいくつかご紹介します！

フレキシブルに働ける

mmjは今年から完全にオフィスレスに切り替えました！とはいえ元々全員リモートワークだったので、特に変化はないのですが。
やはり通勤時間がないことで自分の自由時間が増えることが最大のメリットだなと感じています。
また、通院や子供の学校行事などでちょっと抜けられるのも便利で、仕事を効率よくこなせています。

整った環境

リモートワークの実績は10年以上あるので、環境はすごく整っています！
自宅に作業スペースと机、椅子、通信環境さえあれば、会社から貸与されるPC等をセットアップするだけ。
デュアルモニターやヘッドセット等の備品も必要に応じて購入できるため、自分に合った快適な環境で集中して働けます。

同僚との適度な距離感

mmjに入社する前は、物理的に離れた環境で働くことへの不安な気持ちがありました。
でも実際は、様々なツールを適切に活用し、オンラインでスムーズにコミュニケーションできています。毎日の朝会や定期的なオンラインミーティングもあるため、孤立感を感じることも全くありません。

それに年に数回リアルで集まる場もあり、いつも和やかで楽しい雰囲気です。
社員同士がすごく仲が良いというわけではないですが、仲が悪いわけでもない。
ほどよい距離感が心地良いです。

意見が通りやすい

社員の意見やアイデアがちゃんと聞いてもらえる文化が根付いています！
新しい技術のトライや業務改善のアイデアも気軽に共有できるし、実際に取り入れられることも多く、失敗を恐れずチャレンジできる環境は本当に貴重だなと思います。
技術勉強会やミーティングでも、お互いを否定せず、みんなが話しやすい雰囲気を大事にしています。

また、3カ月に一度の社長との1on1ミーティングも、どんな小さな困りごとでも聞き入れてくれますしすぐに改善してくださるので、働きがいにつながっていると感じています。

休みを取りやすい

必要なときに必要なだけ気軽に休みを取得できる仕組みになっているため、みんな計画的に休みを取りリフレッシュしています。
休暇取得の推奨日もありますし、夏休みや年末年始に有休を合わせて長期で休むことも推奨しています。

以上が、私が感じるmmjの推しポイントです。
社員一人ひとりが自分のペースで最大限のパフォーマンスを発揮できる、「この会社、推せる！」と思える環境がここにはあります。
ここまで読んで「mmjって意外といいかも!?」と思った方おられましたら、一度お話だけでも聞いてみませんか？
ご応募お待ちしております！

The post mmjの推しポイント first appeared on メディアマックスジャパン求人採用情報.

こんにちは。QAチームです。
もはやお花見ブログ担当みたいになっている私。今年も恒例のお花見が開催されましたのでさっそくレポします！

例年であればオフィス周辺の川沿いにピクニックシートを敷いて…のスタイルなのですが、3月末に本社がレンタルオフィスへ移転したため、今回はカフェスペースをお借りしてのお花見会となりました。
当日はあいにくの曇り空で、桜の満開時期には少し出遅れてしまったものの、窓を開けるとすぐ横に高瀬川と桜が。なんとも京都らしい風情あるロケーションです。

桜を見ながら朝会スタート

mmjでは毎朝11時に朝会を実施しています。メンバーがTeams会議で集まり、その日の作業予定などの共有を行います。この日もお花見前に朝会が行われ、各自が担当しているプロジェクトの情報共有や今後の展望など、いつもよりも少し拡大しての朝会となりました。
現地に来られなかったメンバーへは画面越しのお裾分けでしたが、みんなで桜を楽しみながらの朝会は予定時間をオーバーして盛り上がりました。

古民家風の和室スペースで朝会

お待ちかねのランチタイム

お弁当を囲みながら、和やかな時間が流れました。仕事の話から趣味の話まで、普段のオンライン会議ではなかなか聞けないような会話も飛び出し、改めて“リアルで集まる良さ”を感じました。

開放的な窓のあるダイニングスペース。高瀬川沿いを散歩中の観光客から注目の的でした。

春満載のお弁当。今回は食べる前にちゃんと写真撮りました。

これからのmmj

リモートワークが中心の働き方でも、チームとしての一体感や信頼関係を育むことを大切にしているmmj。
レンタルオフィスに移転したことでさらに高まった柔軟性を活かし、お花見に限らず、オフサイトミーティングや研修などリアルで交流する機会が今後より一層充実していく見込みです。

The post 京都オフィスお花見2025 first appeared on メディアマックスジャパン求人採用情報.

プロジェクト管理ツールのおさらい

プロジェクト管理ツールにはいろいろな種類があります。以下がその一例になります。

• コンテンツ・ナレッジ共有ツール
• スケジュール・進捗管理ツール
• バグ管理ツール
• 総合的なシステム開発のプロジェクト管理ツール
• アジャイル開発に特化したプロジェクト管理ツール
• システム開発以外で利用しやすいプロジェクト管理ツール

「これってどんなことができるツールだったかな？」の詳しい説明は前回の記事をご覧ください。

コンテンツ・ナレッジ共有ツール Confluence

mmjでは情報共有のために、アトラシアン社の提供するConfluenceを利用しています。
前回の記事で紹介した、PukiWikiに近い機能をもっています。

https://www.atlassian.com/ja/software/confluence

mmjのConfluenceの使い方

Confluenceでは「スペース」という単位で情報をまとめています。
システム開発プロジェクト毎のスペースがあるのはもちろんのこと、私たちQAチームでの情報をまとめるスペースや、現在mmjで取得しているISOに関する情報をまとめたスペースなど、システム開発情報に限らないすべての情報をConfluenceにアウトプットできます。

Confluenceのスペースの一例

Confluenceミーティング議事録機能

よく利用する機能の例の一つにミーティング議事録機能があります。
ミーティング議事録のようなよく利用する形式は、あらかじめテンプレートで用意されています。
テンプレートの利用で情報を短時間でまとめあげることができます。

QAチームの定期ミーティングも、このミーティング議事録機能を使っています。
ミーティングに関してはテンプレート機能だけではなく、各議事録や議事録に書き出したタスクを一覧化する機能も用意されています。

QAチームでは担当者へ確認したり依頼をするといった作業がよく発生するため、そういったちょっとしたタスクをConfluenceのミーティング議事録に記録しています。
コミュニケーションをとるだけでは終わらないような時間のかかるタスクは、Confluenceと同じアトラシアン社製のJiraでチケット化して管理しています。
続いてタスク管理でも利用しているJiraをご紹介します。

タスク・バグ・進捗などいろいろ管理できるJira

Jiraはタスクもバグも要件も管理できるツールです。
前回の記事で紹介した例にある、MantisやPivotal Trackerに相当する機能をもっています。
また様々なプラグインがありJiraへ機能を追加することも可能です。
例えば、GanttProjectのようなガントチャート作成ができる機能のプラグインもあります。

https://www.atlassian.com/ja/software/jira

mmjのjiraの使い方

Confluenceと同じようにプロジェクト毎のタスクやバグだけではなく、会社で利用するツールの調査など全てのタスクをJiraで管理することができます。
Confluenceでは「スペース」単位で管理していますが、Jiraでは「プロジェクト」単位での管理になります。
以降、QAチームで利用しているプロジェクトを例にmmjでのJiraの使い方をご紹介します。

Jira チケット機能

JiraにはMantisのようなチケット登録機能があります。
QAチームのプロジェクトのタスクチケットを例にご紹介します。
こちらはISOもしくはその他のプロセスを導入する調査タスクとして登録したチケットです。
mmjではISOの導入が完了しているためチケットのステータスは完了となっています。

チケットには説明だけではなく、関連するConfluenceページへのリンクや他のチケットへのリンク、コメントも設定できます。
QAチームチケットはソースコードの紐づけがないタスクですが、システム開発プロジェクトのチケットの場合はGithubとJiraを連携してチケットとGithubを紐づけています。
どのタスク（もしくはバグ）チケットで何のソースコードが影響を受けたかをGithubで確認ができるようになっています。

このようにタスクやバグをどんどんチケットへ登録しています。
そして沢山のチケットを登録していくと、それらの管理をどうするか？という問題が発生します。
続きまして、チケットを管理する機能例として、Jiraのかんばん機能とWBSガントチャート機能をご紹介します。

Jira かんばん機能

Jiraには Pivotal Trackerのようなかんばん機能があります。
mmjではバグチケットの管理でもタスクチケットの管理でも、このかんばん機能を利用することが多いです。
こちらがQAチーム用のJiraプロジェクトのかんばんです。

それぞれのチケットのステータスが一目でわかるのでQAチームのタスクの確認にはとても向いています。
一方でシステム開発プロジェクトの場合は、ステータスだけではなく各タスクの進捗状態・優先度・スケジュールも一覧で把握したいことがあります。
その場合はJiraのプラグインのWBSガントチャート機能を利用します。

Jira プラグイン WBSガントチャート 機能

Jira本体にはWBSやガントチャートを作る機能がないためプラグインを利用します。
wbsガントチャート for jira プラグインでGanttProjectのようなガントチャートが作成できます。
実際の開発プロジェクトは公開できないため、以下はWBSガントチャートを利用したサンプル例になります。

このプラグインを利用することで、チケットを工程の順に並べたりチケットの進捗状況（完了の場合は進捗率100%）を確認することができます。
タスクも管理もスケジュールも管理できて、これだけでも管理機能が大変充実しているのですが、Jiraにはなんと工数の管理機能を備えたプラグインもあります。
続いて、mmjで利用している工数管理のJiraのプラグインをご紹介します。

Jira プラグイン Tempo 工数管理機能

このプラグインは前回の記事で紹介したRedmineにあるような、予定工数と実作業工数を管理できる機能です。
mmjでは2つのJiraプラグインを連携して予定工数と実作業工数を管理しています。
まず最初に2つのプラグインを使って予実工数表示したイメージからご覧ください。

予定と実績が並んでいて簡単に比較ができます。
続いて、予定工数と実際の作業工数を設定するために利用しているJiraプラグインをご紹介します。

予定工数の管理 Tempo Planner

予定工数はJiraプラグインのTempo Plannerを利用しています。
予定工数を設定するチケットを選んで、Plan Time 機能から予定工数を設定していきます。

Plan Timeから設定した工数が、予実工数のP（Planの略）の部分で確認できるようになっています。

実作業時間の管理 Tempo Timesheets

実作業時間はJiraプラグインのTempo Timesheetsで設定しています。
予実工数のサンプルにある「記録時間」をどう記録しているかのイメージがこちらです。

作業時間を設定するやり方は何通りかありますが、mmjではこのように作業日ごとに時間を記録する方法を利用しています。
作業日ごとの時間の累計を記録時間として集計して出力してくれます。

色々管理できる ConfluenceとJira

mmjでは情報共有からタスク管理、スケジュール管理、工数管理までConfluenceとJiraを使っています。
ご紹介した機能はConfluenceとJiraでできることのほんの一部で、まだまだ便利な機能がたくさんあります。
全部はご紹介できないため、最後にひとつ、同じアトラシアン社のツールだからこそできるConfluenceとJiraの連携機能の活用例をご紹介します。

ConfluenceとJiraの連携

Jiraの情報をConfluenceに出力する機能がいくつかあります。
1つのチケットをリンクして出力することはもちろん、複数チケットを出力する方法もいくつか用意されています。

QAチームではこの機能をフル活用して、不具合や課題の分析をしています。

ConfluenceとJiraの連携を活用した分析

こちらがサイト制作案件の分析結果サンプルです。
サンプルのようなサイト制作案件の場合は、画像やCSSなどのデザイン調整が必要な不具合の割合が高いことが多いことがグラフから一目でわかります。

mmjではJiraチケットのラベルを分析用に利用しています。
ラベルの値として、分析で分類したい値を設定しており、案件の性質によって分類値を変えています。
例えばサンプルにあげたサイト制作案件の場合は、WordPressと組み合わせて利用する機能が動作できるかも確認しているため、組み合わせて利用している「テーマ」や「プラグイン」といった分類を利用しました。
システム開発案件の場合は、「外部連携」に関する不具合や改修の「デグレード」といった分類を設定しています。
あらかじめ分類が決まっているツールもありますが、Jiraの場合は各項目の自由度が高く各案件で使いやすいように設定ができるので、mmjのような多種多様な業種のシステムやサイト制作をする業務に役立っています。

グループウェア Microsoft 365

ここまでは主にプロジェクト管理ツールとしてConfluenceとJiraの活用例をご紹介しました。
mmjではConfluenceとJiraとは別にMicrosoft365も利用しています。
前回の記事で紹介したサイボウズOfficeと比較されることが多いシステムです。

Microsoft365のOutlook Teams連携

mmjでは会議スケジュールの設定にMicrosoft365のOutlookカレンダーを活用しています。
また、リモートワークには欠かせないチャットや会議ツールはMicrosoft Teamsを利用しています。
Microsoft365は2020年サブスクリプションサービスが開始された比較的新しいサービスとなっていて、mmjでも数年前まではチャット・リモート会議・カレンダーをMicrosoft365ではないそれぞれ別のツールで対応していました。
それらをMicrosoft365に一本化したことで、あれこれツールをを切り替える必要がなくなりました。
例えば、Teamsのチャット上で会話をしながらTeams上からOutlookカレンダーに会議を設定し、会議時間になったらTeamsの会議が開始するといった流れがMicrosoft365だけで完結します。

QAチームの定例ミーティングは、Confluenceで議事録ページ作成してTeamsで共有して、Teams経由でOutlookカレンダーに予定の設定を行っています。
そしてOutlookカレンダーに設定した会議の予定日時になると、Teamsが自動で会議を立ち上げてくれます。

効率アップを目指して継続的改善

mmjで取得しているISO9001には継続的改善という概念があります。
PDCAのサイクルを回す枠組みです。
Microsoft365のように新しいツールが発表されることもあれば、TeamsのWiki機能のように廃止される機能もあり、ツールは日々変わっていくため、導入して終わりではなく継続的改善が必要です。
今回ご紹介したツールについても、利用状況の確認や類似ツールの調査、場合によっては新ツールの検証およびトライアル運用といった改善活動を行っており、ISOの審査でもその活動を高く評価していただいています。

 

プロジェクト管理ツールをご紹介して

プロジェクト管理ツールの記事は今回でいったん終了ですが、また便利なツールを導入した際にはブログでご紹介できればと思います。

mmjでは継続的改善意欲の高い方を募集しております。 色々なツールを試せるmmjにご興味がある方のご応募をお待ちしております。

The post mmjが利用するプロジェクト管理ツール first appeared on メディアマックスジャパン求人採用情報.

その対応時間捻出のため毎朝５時半に起きるようになりました。
（まだ始めて１ヶ月ちょっとですが。）
日中は残暑も厳しいですが、朝晩は涼しくなり、
起床後窓を全開にして涼しい中静かな時間を過ごすと、なかなかに集中できて良い！です。
７時に家族が起きて来てわちゃわちゃしてくるまでの間。
日の出も見れるし。日の出も1ヶ月間で少しづつ遅くなってます。

昔勤めていた会社の先輩が出社の一番マニアで、よく早起きの徳を説いてくれてた記憶があります。
当時若かった私は右から左に受け流しており全く内容を憶えてないですが、
今ならわかる！ような気がする。。

今のところ３ヶ月継続が目標です。
（でもなー、寒くなると起きるの辛くなるかもなー　と継続できなかった時の保険も掲載。）

早起きして出たゆとりは勉強時間に充てたり、急ぎの残務に充てたりもできますし
前日に病院へ行ったり、この送迎で削られたフルフレックスの不足時間も調整できます。
ぜひ習慣化したいです。

The post 早起きっていいですよね first appeared on メディアマックスジャパン求人採用情報.

1. フレキシブルな勤務体制の提供

当社ではフレキシブルな勤務体制を導入しています。エンジニアは、リモートワークやフレックスタイム制度を活用し、自身の生活スタイルやプロジェクトのニーズに合わせて働くことができます。これにより、通勤ストレスの軽減や家庭・育児との両立が容易になり、生産性の向上にもつながっています。

当社のフレックスタイム制はコアタイムが11:00～15:00で、標準労働時間は8時間です。朝が苦手な方は11時～始業、早起きが得意で夜に自由な時間を確保したい方は早朝から仕事するなど、各自の生活スタイルに合わせて勤務時間をコントロールできますし、プライベートの予定に合わせて毎日バラバラの勤務時間にすることも可能です。

2. ワークライフバランスの推進

エンジニアのワークライフバランスを支援するために、年間休日は120日で、基本的に残業・土日出勤はありません。プロジェクトの進行に支障がなければ有給休暇は非常に取得しやすく、直前の申請でも取得可能です。

労働基準法で定められた日数の有給休暇に加えて、毎年3日間の夏季休暇が付与され、8～10月の間の好きなタイミングで休暇を取ることができます。

また、年1回、定期健康診断を実施しているなど、健康とウェルビーイングを重視した環境を整えています。

3. スキルアップとキャリアパスのサポート

当社ではエンジニアが技術スキルを維持し、成長するためのトレーニングや勉強会を定期的に開催しています。さらに、キャリアパスの透明性を高め、エンジニアが将来の目標を達成できるよう支援しています。これにより、モチベーションの維持と定着率の向上を図っています

ちなみに、当社のWebエンジニアの平均勤続年数は11年です。直近3年間（2021～2023年）の平均離職率は7.5％で、日本の全事業者平均離職率15.0％（※）のちょうど半分という低い数字です。当社の定着率の高さがお分かりいただけると思います。
※出典：厚生労働省 令和4年 雇用動向調査結果の概要

4. コミュニティとのつながり強化

当社ではエンジニア同士の交流を促進するため、毎日のオンライン朝礼に加えて、定期的なオンラインミーティングやテクニカルセミナーを開催しています。

また、オンラインコミュニティの活性化も図り、知識共有と連携を深める場を提供しています。これにより、エンジニアのスキル向上だけでなく、仕事に対する意欲とアイデンティティの強化を支援しています。

更に、リモートワークのスタッフが多いため、対面で親睦を深める目的で、新年会・忘年会、花見などの季節イベントのほか、3ヵ月に一度の社長面談の際にスタッフが集まっての食事会なども実施しています。

mmjが目指していること

エンジニアのライフワークバランスを実現するためには、多面的な支援が必要です。当社では、柔軟な働き方、健康管理、スキルアップの機会、そしてコミュニティ活動の充実といったアプローチを通じて、エンジニアが充実したキャリアと満足感ある生活を両立できる環境を提供しています。

これにより、エンジニアが長期間にわたり成長し続け、企業とともに価値を創造していくことを目指しています。

The post Webエンジニアのワークライフバランスを実現する当社の取り組み first appeared on メディアマックスジャパン求人採用情報.

この記事では、エンジニアの転職活動において、転職サイト・エージェント経由と直接応募のそれぞれのメリット・デメリットを比較し、どちらが有利かを考察します。

尚、弊社では転職サイト経由と直接応募の両方でエンジニアを募集しています。この記事ではまず最初に客観的な視点での分析、そして最後に弊社の見解をお伝えします。

転職サイト・エージェント経由の応募

メリット

専門的なサポート

転職エージェントは、履歴書の添削や面接のアドバイスなど、専門的なサポートを提供します。エンジニア特有のスキルや経験を適切にアピールする方法を指導してくれるため、選考を通過する確率が高まります。

非公開求人へのアクセス

エージェントを通じてのみ応募できる非公開求人が多数存在します。これらの求人は、企業が競争を避けるためや特定のスキルを持つ人材を探すために公開されないものが多く、直接応募ではアクセスできないケースが多いです。

交渉力の向上

給与や勤務条件の交渉をエージェントが代行してくれるため、自分では言い出しにくい要望を伝えやすくなります。特に、給与アップやリモートワークの交渉など、エンジニアにとって重要な条件を引き出す際に有利です。

デメリット

手数料の問題

企業側がエージェントに支払う手数料が発生するため、企業によってはエージェント経由の採用を避ける場合があります。これにより、選択肢が狭まる可能性があります。

コミュニケーションの手間

エージェントを介することで、情報伝達が遅れることがあります。直接応募に比べて、意思決定が遅れることがあるため、スピード感が求められる場合には不利です。

直接応募

メリット

迅速な対応

企業に直接応募することで、迅速に応募プロセスを進めることができます。エージェントを介さないため、コミュニケーションがスムーズで、面接の日程調整などもスピーディーに進行します。

企業との直接のつながり

転職サイトやエージェントが用意している画一的な応募フォームとは違い、自由な書式で個性をアピールできます。また、企業の採用担当者と直接やり取りすることで、自分の熱意や意欲を直接伝えることができます。これにより、エージェントを介した場合よりも強い印象を与えることができる場合があります。

手数料が不要

企業がエージェントに支払う手数料が発生しないため、企業側にとってもコスト面でメリットがあります。そのため、直接応募を歓迎する企業も多いです。

デメリット

限られたサポート

履歴書の添削や面接対策など、エージェントが提供する専門的なサポートを受けられません。全てを自分で準備する必要があるため、特に転職活動に不慣れな方にとってはハードルが高いです。

非公開求人へのアクセスがない

直接応募では、非公開求人にアクセスすることができません。これにより、応募可能な求人の範囲が限定されることがあります。尚、非公開求人の有無は企業によって異なります。弊社では非公開求人は存在していません。

交渉の難しさ

給与や勤務条件の交渉を自分で行う必要があります。交渉力に自信がない場合や、具体的な条件を引き出すのが難しいと感じる場合には、不利になることがあります。

どちらが有利？【一般論】

エンジニアの転職活動において、転職サイト・エージェント経由と直接応募のどちらが有利かは、個々の状況や目指すキャリアパスによって異なります。以下のように考えると良いでしょう。

どちらが有利？【メディアマックスジャパンの見解】

弊社の場合は、採用に至るまでの費用より、「人材のスキルとパーソナリティ」が最大の合否判断ポイントですので、転職サイト・エージェント経由と直接応募のどちらの方が採用されやすくて有利ということは一切ありません。

ただし、書類選考用の書類に記載されている情報が全く同じ内容という前提の場合に限ります。もし、転職サイト経由で送られてきた履歴書や職務経歴書の内容が、転職サイトが定めたフォーマットに則って作成されていて、採用判断にプラスになる情報が掲載されている場合は、そちらの方が有利ということになるでしょう。

そうならないためには、直接応募用に、転職サイトで用意されている履歴書や職務経歴書のフォーマットを参考にして、もれなくご自分についてアピールした書類を用意しておくのがおすすめです。そうすれば、応募方法による有利・不利の差はなくなります。

一般的には、転職サイト経由の応募だと、企業がサイトに紹介料を払わなければならないので、紹介料を払う必要がない直接応募の方が有利だという解説もありますが、弊社の場合はそれは関係ありません。

そもそも紹介料を払いたくなければ最初から直接応募だけにしていますし、会社の発展に貢献してくれる良い人材を「紹介料を払いたくないから」という理由で採用しないということはあり得ません。転職サイトは、良い人材と出会える可能性を広げるという大切な役割を果たしてくれる存在ですので、お金を払ってでも利用する価値があります。

尚、転職サイト・エージェントでは複数の企業に簡単に一括応募できるので手間はかかりませんが、直接応募は1社ずつ念入りに調べるという手間暇をかけて応募してくださるわけですから、直接応募の方が応募者の入社への熱意が高いという印象がプラスに働くことはあります。

もし弊社に関心を持っていただいて、直接応募で入社された方には下記の2つの特典をご用意しています。

• 最短5日スピード選考
• 新生活応援手当合計10万円支給

弊社に在籍しているエンジニアの50％は直接応募で入社しています。また、全エンジニアの平均勤続年数は11年ですので、長く安定的に勤務しているのがお分かりいただけると思います。

まとめ

エンジニアの転職活動では、転職サイト・エージェント経由と直接応募の両方をバランス良く活用することが理想的です。自分のニーズや状況に応じて、最適な方法を選択し、キャリアアップを目指しましょう。各方法のメリットとデメリットを理解し、自分にとって最も効果的な転職活動を行うことが、成功への鍵です。

メディアマックスジャパンでは中途採用・新卒のエンジニアを募集しています。フレックスタイム制でフルリモートワークも可能な、ワークライフバランスが整った職場で一緒に働きませんか？弊社への入社をご希望のエンジニアの方は、採用エントリーをお待ちしています。

The post エンジニアの転職サイト・エージェント経由と直接応募はどちらが有利？ first appeared on メディアマックスジャパン求人採用情報.

結論からいうと、恥ずかしい話、mac m1 proでの開発環境づくりを諦めました。

まず、開発言語はちょっと古いバージョンを使って、dockerで開発環境を統一したいという前提です。新しいプロジェクトで最新の環境をつくることは、おそらく問題ないと思います。

力不足で申し訳ございませんが、皆さんの参考になればと思い、恥ずかしながら理由をお話します。

前篇では、頑張れば、m1でも開発できることを述べました。

しかし、x86のLinuxとarm64（mac m1）と2台を同時に使うとすると、求めることは２つあります。

１つ目、2台とも同じレベルのスピードでビルド、開発できることです。一方だけ遅くなると、そちらを使いたくない気持ちが出てきます。
m1でx86のシミュレーターを使えば、楽に環境を作れますが、スピードはガタ落ちて、ストレスを感じますね。

２つ目、なるべく環境づくりに2倍の労力は使わないことです。x86のシミュレーターを使わず、頑張ってrosettaを使って、x86のLinuxと同等のスピードでビルドができることは確認しました。しかし苦労して設定や、ライブラリをいじることが必要です。x86の環境づくりとarm64の環境づくりを両方する必要があると考えると、辛い。
まずは環境によって、設定ファイル、ライブラリの管理が必要となります。
次に、ライブラリや設定の変更のとき、両方の修正とテストが必要となります。もともと必要としない手間なので、よほど興味がない限り、やりたくないのが一般的ですよね。

以上の2点は同時に満足できなかったという理由で、今回はmac m1 proで開発環境を作ることを断念しました。

私の考えとしては、サーバーと同じCPUアーキテクチャを使うのがおすすめします。同じCPUアーキテクチャ、同じOSが一番楽だと思います。

macのarm64アーキテクチャで開発環境を作ることを進めるのは、1台しか環境を作る場合、あるいは複数の環境を作るけど、どれも同じarm64であれば、一つの環境だけに対応すれば大丈夫ですね。私のように、x86とarm64両方対応しようとすれば、仮に最初は環境作ったとしても、一方だけメンテナンスし続けると、もう一方は使えなくなるので、私はおすすめしません。

ここまで読んで頂いて、ありがとうございました。

The post mac m1 proの開発環境作りの最後 first appeared on メディアマックスジャパン求人採用情報.

教育体系がどういう流れで、どういうものが大事とされてたのか、詳しく学んだことはないし、数冊読んだ本がすべてではないですが、社会主体の教育からこども主体の教育に変わってきてる？印象を受けました。私のさっくりとした理解では、上から見下ろした「みんな一緒」から同じ目線での「みんな違う」への変化。
流行りの歌の歌詞では、オンリーワンとかよく耳にしますけど、実際は自分と違う人間をたたきがちだし、皆同じことをしていないと不安といった価値観の日本社会かなと思っていたのですが、
言われてみれは、バックグランドも違うし、体系も好みも何もかも違うのだから、
こども本人が、何のために遊ぶ（学ぶ）、何を遊ぶ（学ぶ）、どうやって遊ぶ（学ぶ）かをそれぞれが決めるのも当たり前ですよね。

さらに、幼稚園の説明会でも聞きましたが、こども達が大きくなった頃はグローバル化・情報化・人口知能化が今より進み、全体の半分以上が未知の職業に就くことになるのを想定し、21世紀型スキルとやらが必要になるそうです。
なんでも批判的思考・コミュニケーション・創造性・協働を学ぶことを柱とした教育なのだとか。
私の受けた教育は必ず正解があって、それを反射的に答える訓練みたいな感じでしたが、
正解がない物事をまず色んな見方から捉えて、皆で話し合い協力しあうとか、昨今の時事問題でも
めちゃ必要なスキルであることはわかりますよね。競争社会から協力社会か。こどもも減ってるしな。こどもの世界は意識改革が進んでるんだなーなんて驚きました。

しかし、この感覚は前にもどこかで。。既視感。はたとMMJに入社した頃の自分を思い出しました。
がっちり管理されたところからMMJに入ったため、え！そこから？という場面が多発してました。
皆ばらばらの時間にやって来て、好きなように仕事をして個々が自由に過ごしているのですが、
いざ物事を決めるとなると、終結しそもそもその物事がなぜあるのかから話し合うみたいな。
上から降ってきた物事を疑問なくただこなしていくんじゃないんだなと
会社による価値観の違いに気後れしたのを覚えています。こんな近くにいたロールモデル。

結論としては、MMJの環境みたいに我が家も個別最適化を目指すと良いのかなと思いました。
管理支配しようと目論むからこっちが振り回されてたことから、
こどもとは言え、自分とは違う人間なので、基本的には好きにやってもらうことが
今自分にできる事だと悟りました。しかし相手のペースを尊重しつつも、
こっちのやって欲しい事もやってもらおうとすると、なかなかのストレスがこっちに降りかかってきます。
ずっと見てたらイライラしてしまうので、それはそれとして受け入れつつ、自分にできる別の事を考え行動に移し気を紛らす。会社でも良くあるよなこの場面。。精神面で鍛えられます。

The post 最近考えたこと first appeared on メディアマックスジャパン求人採用情報.

現在MMJではJiraとConfluenceというツールを使って管理しております。前職で様々な客先での常駐作業があったので色々なプロジェクト管理ツールには触れた経験があるのですが、JiraとConfluenceに触れたのはMMJに来てからが初めてでした。今ではJiraとConfluence無しではどう仕事をしたらよいかわからない体になってしまったと言っても過言ではありません。

そんなJiraとConfluenceの素晴らしさを語る前に、今回はプロジェクト管理ツールにはどのような種類があるかを実際に利用したことがあるツールを例にして、いくつかご紹介しようと思います。

OSS・有償ツール

プロジェクト管理ツールには、無料で使えるOSS（オープンソースソフトウェア）と、有償のツールがあります。OSSは無料の代わりに、保守がない・不具合対応や開発継続の保証がない・長年利用されているツールはUIや機能が少し古いなどいくつかのデメリットもあります。実際に過去に使っていたOSSで、継続開発が行われず現在は利用できないものもいくつかあります。
一方、有償ツールは保守やサポートがあり、不具合や新しい環境への対応も行われるので安定して利用できます。MMJで利用しているJiraとConfluenceはオーストラリアにあるAtlassian社の有償ツールです。

コンテンツ・ナレッジ共有ツール

プロジェクトを進めるために必要な知識・経験・ノウハウを共有できるツールが、コンテンツ・ナレッジ共有ツールです。業務の効率アップや属人化防止に役立ちます。MMJで利用しているConfluenceは、このコンテンツ共有ツールに分類されます。今回は実際に利用したことのあるOSSコンテンツ・ナレッジ共有ツールであるPukiWikiをご紹介します。

PukiWiki

https://pukiwiki.osdn.jp/

コンテンツ・ナレッジ共有ツールのなかでも、自由にページを編集できるツールCMS（コンテンツ管理システム)と呼ばれるツールです。Webアプリです。こちらは日本で開発されたツールのため導入からカスタマイズまで日本語の情報が充実しています。また、OSSはプログラミングの知識が必要なものが多いのですが、PukiWikiはDBがいらないため導入も移植も比較的簡単です。手軽にコンテンツ共有をしたい場合にとても便利なツールです。
私が利用した時はプロジェクト毎に１つのPukiWikiをインストールする方法で運用していました。複数のプロジェクトのコンテンツを横断的に管理したい場合は後にご紹介するRedmineが便利です。

スケジュール・進捗管理ツール

スケジュールや進捗管理に特化したツールです。スプレッドシートで管理することもできますが、専用のツールを使うことで日付の入力だけで簡単に線を引けたり、予定の関連性を表現できるなどのメリットもあります。
MMJではJiraのプラグインであるWBSガントチャートを使ってスケジュールや進捗管理をしています。今回は実際に利用したことのあるOSSのGanttProjectをご紹介します。

GanttProject

https://www.ganttproject.biz/

プロジェクトのスケジュールや進捗の管理でよく利用されているガントチャートの作成に特化したツールです。こちらはWebアプリではなくネイティブアプリのため各端末へのインストールが必要になります。HTMLやPDF出力機能も兼ね備えています。
定期的に行う進捗報告をガントチャートに反映し、先にご紹介したPukiWikiに掲載するという進捗状況の議事録として利用していました。

バグ管理ツール

コンテンツ共有やスケジュール管理ツールだけでは対応できない、バグの管理に特化したツールです。スプレッドシートに課題管理票を作りバグを管理する方法もありますが、バグ管理専用のツールを使うことでバグの状態の管理や、変更ソースとの紐づけ、バグ同士の関連性の紐づけなどもできるようになります。ツールを使うことにより、1ファイルでの管理ではないのでファイル保存時のコンフリクトを気にすることなく、複数人で同時に書き込みできることもメリットです。

MMJで利用しているJiraが、このバグ管理のシステムも兼ね備えています。今回は実際に利用したことのある国産OSSのMantisをご紹介します。

Mantis

https://www.mantisbt.org/

バグトラッキングシステムと呼ばれる、バグの状態管理や追跡に特化したシステムです。こちらもPukiWiki同様に国産システムのため、日本語の情報が充実しています。GitやSVNなどのバージョン管理ツールと連携して、バグに対してのソースコードの変更を紐づけることもできます。バグ（虫）を食べるカマキリが名前の由来なところからして、バグを駆逐するという強い意志を感じますが、バグの管理だけではなくチケット駆動開発スタイルのプロジェクトではタスク管理システムとして利用することもありました。
こちらもPukiWikiのようにプロジェクト毎に１つのMantsをインストールする方法で利用していました。Mantisと同じようなバグやチケットを管理できるシステムには後にご紹介するRedmineがあり、こちらは複数のプロジェクトのバグを1つのRedmineで横断的に管理できます。

複合的なプロジェクト管理ツール

ここまでは、コンテンツ共有・スケジュール管理・バグ管理などそれぞれの管理対象ごとに特化したツールをご紹介しました。しかし、管理したいものごとにツールを分けることは手間に感じることもあります。そこで全部の機能を兼ね備えたツールの出番です。
無料で使えるOSSでも全部を兼ね備えたツールがあるのでご紹介します。

redmine

https://redmine.jp/

ここまでで紹介した、各機能の全部ができるツールがこちらのRedmineです。こちらもOSSのため無料です。Webアプリです。また、複数のプロジェクトを1つのRedmineサイトで管理できる、マルチプロジェクトに対応しています。管理したいものごとにツールをわけなくてよいだけでなく、プロジェクトごとにインストールする必要もないので楽ではあるのですが、色々な機能が１つのツールに入っているため設定は複雑になります。
また、ウォーターフォール開発全盛期に生まれたシステムのため、アジャイル開発に必要なカンバンなどの機能はありません。カンバン機能を利用したい場合はプラグインを別途入れる必要があります。逆に言えばOSSのため各自が自由にプラグイン開発ができ、多種多様なプラグインが開発コミュニティーメンバーにより生み出されています。

アジャイル開発に特化したプロジェクト管理ツール

ここまでは、OSSかつウォーターフォール開発全盛期に作られたツールをご紹介しました。しかし、今はアジャイル開発の特にスクラム開発が主流とも言われています。
ここからはアジャイルにも対応できるプロジェクト管理ツールで、私が実際に利用した経験のあるPivotal Trackerをご紹介します。

Pivotal Tracker

https://www.pivotaltracker.com/

こちらのPivotal Trackerはアジャイル開発向けの有償ツールです。MantisやRedmineのようにチケットでのタスク管理ができます。バグやタスクではなくストーリーを軸にした管理ができるなどのアジャイルに特化した機能をもっています。逆に、アジャイルと相性が悪いと言われているガントチャートのようなスケジュール管理機能は持っていません。スプリント管理やバーンダウンチャート機能などのアジャイル開発に絞ったシンプルな機能だけを持っています。
MMJで利用しているJiraはPivotal Trackerに搭載されているアジャイルに特化した機能もすべて網羅していて、１つのツールでウォーターフォール開発もアジャイル開発にも対応しています。

システム開発以外でも導入しやすいプロジェクト管理ツール

ここまでは、システム開発メインのプロジェクト管理ツールをご紹介しました。システムエンジニアには見た目がシンプルで最低限の機能が好まれる傾向がありますが、他部署のメンバーからはどうしても「難しそう」「わかりにくい」という声があがることがあります。そんな、システム開発だけではなく、営業・経理・デザイナーなどの様々な業務の割合が高い企業で全職種一緒に利用していたプロジェクト管理ツールをご紹介します。

サイボウズOffice

https://office.cybozu.co.jp/

プロジェクト管理もできるグループウェアのサイボウズOffice。2023年のグループウェアシェア率2位を誇り、利用者がとても多い有償ツールです。他のQAチームメンバーもMMJに転職する前に使ったことがあるというツールですが、バグ管理などのシステム開発に特化した機能やアジャイル開発に必要なタスク管理機能はないため、足りない部分は別のツールで補う必要があります。私が経験したのは、全社的にはサイボウズを利用し、開発部はRedmineにてサイボウズで足りない部分の管理するという運用でした。
複数のツール利用で一部機能が重複する場合は、どちらのツールで何を管理するかという運用ルールを決めたり、データ連携できるプラグインを別途用意しなければ情報が二重管理になるという新たな問題も発生します。ですので必ずしも色々な機能が入ったツールが使いやすいというわけではなく、運用にあったツールを選択する必要があると思いました。

プロジェクト管理ツールを調査して

沢山の開発スタイルのプロジェクトがあるように、プロジェクト管理ツールも多種多少なものがあります。また、ウォーターフォール開発からアジャイル開発が主流になったように、開発スタイルも時代とともに変化し、それらのスタイルに合わせた新しいツールやプラグインも日々登場しています。

MMJではJiraとConfluenceを利用しておりますが、改めて他のツールとの比較を行うことで今利用しているツールのメリット・デメリットや、使い方を見直すことができました。べた褒めしたJiraとConfluenceの話を今回の記事の中では語りつくせないため、次回のご紹介になってしまう点、大変心苦しいところです。次回の記事ではここでご紹介した色々なツールのどの機能をJiraとConfluenceで対応できるのかや、実際の業務で利用しているかをご紹介できればと思います。

プロジェクト管理ツールは、プロジェクトにかかわるすべてのメンバーにとって影響のある大切なツールです。見直しを行う社風は改善指向の高いMMJの一つの特徴ではないかと思います。効率の良い環境で一緒に働いてくださる方のご応募をお待ちしております。

The post プロジェクト管理ツール first appeared on メディアマックスジャパン求人採用情報.

今、mmjの社内ではエンジニア達によって、今後のAI全盛期における新たな立ち回り方を模索しながら、ChatGPTやCopilotに関する情報交換が活発におこなわれています。この記事では、現役のエンジニアが今実際にどんなことを感じて考えているのか、生の声をご紹介します。

今後のWebシステム開発エンジニアの在り方や、効率的なプログラミングをするためのヒントが見つかりますので、ぜひご一読ください。

ChatGPTにCopilotについて聞いてみた

まず最初に、Copilotについて知らない方がいるかもしれないので、ChatGPTに質問してみた回答を引用しておきます。既に知っているという方はここは読み飛ばしてください。

Q．Copilotについて教えて

Copilotは、GitHubが開発したプログラミング支援ツールです。これは、人工知能（AI）を活用してコーディングのサポートを行うもので、開発者がコードを書く際にリアルタイムでヒントや提案を行います。

Copilotは、オープンソースのコードベースから学習したAIモデルを使用しており、コーディング中にコンテキストを把握し、関数、クラス、変数などのコード断片を自動的に提案します。これにより、開発者はコードをより迅速に記述し、効率的に問題を解決することができます。

ただし、Copilotは提案を行うだけであり、完全な自動化ではなく、開発者が提案されたコードを検討し、必要に応じて変更する必要があります。また、利用者のコードやコメントなど、GitHub上の多くの情報を学習しており、プライバシーやセキュリティに関する懸念も議論されています。

Copilotは、開発者の作業を効率化し、新しいアイデアを探求するのに役立つことができますが、その利用法には注意が必要です。

ChatGPT

ではここから、エンジニア達が社内のteams上でおこなっている、Copilotに関する意見交換の一部をご紹介していきます。

LLMの活用

　　エンジニアI

LLMをソフトウェア開発に活用するということは、もうこれからの必須スキルになると思います。とはいってもしばらくは発散フェーズで色々な活用方法が模索される時期でしょうから、ここで全力フルスイングしてもすぐに時代遅れになったりして消耗しますので、適度に熟れた部分だけつまみ食いする程度の付き合い方が良いのではないかと思います。

私の活用方法の例を一つあげると「xxというライブラリのyyというクラスはどういうものですか？」という質問をすると、そのクラスの概要について説明してくれます。ある程度使われているライブラリならそれなりに上手くいく感触です。

これはソースコードが長くて切り貼りできないような場合でもそのクラスの概要を教えてくれるので、ライブラリの実装の詳細を理解したい場合には個人的には結構役に立っています。

新しいコードを読む時に、
・そのコードを読むためには、そのコードが一体何をしているのかの概略が無いと辛い
・その概略を得るためにはコードを読まないといけない
というジレンマが発生することがありますが、この方法を使うと、AIがこのループを断ち切ってくれます。

AIにコードを別言語に翻訳させてみた

　エンジニアI

うまく行かなかった事例の共有なのですが、AI にコードを別言語に翻訳させたら、配列のインデックスに使っているリテラル値をこっそり別のものに変えられていて、そのバグ見つけるのにかなり時間を使ってしまいました。

こういう細部のミスはよく起きる印象なので自動生成されたコードを鵜呑みにするのは避けたいですね。

プログラミングでAIを使った所感

　エンジニアS

今SASプログラム（データ解析用言語）をPython化する案件（どっちの言語も不慣れ）を担当していますが、SASプログラムの理解や、pythonコードを書いたりライブラリ選定でChatGPTが大活躍しています。そもそも僕は要らなかったのでは？と思うぐらいになっています。

AIの補助があれば不慣れな領域でもなんとかやれそうですね。もちろん勉強は平行して進めないといけないですが、勉強（言語やライブラリのイディオム）とかもChatGPTに聞けばいいので、はかどりすぎます。

P.S　と言ってたら盛大にChatGPTに嘘付かれたので、やっぱり僕は要りますね(笑)。

　エンジニアI

既存コードを理解するのにはめちゃ便利ですよね。今まで磨いてきた問題解決の技術が価値を失いつつあるのを感じます。特に検索エンジンを使いこなして効率的に調査・問題解決する技術は昔は重要なスキルでしたが、今では全人類標準装備になりつつありますね。侍が銃器の戦いに直面した時もこんな感じだったんですかね。

ただ、間違いを紛れ込ませてくるのでそこはかなり注意が必要だと思います。よく知らない分野で難しいバグを取るのはめちゃ難易度高いと感じました。

一方でよくわからない分野でもそれなりに仕事ができるようになる可能性があるのでプログラマの守備範囲が大きく広がっていく可能性はありますね。

それから、基本的にテキストベースである以上、以下のような状況に弱いです。
・バージョンやプラットフォームなどによって動作が変わる場合
・同じ名前が複数のライブラリや言語で使われている場合

こういう場合、異なる話題が混ざって使い物にならない回答が返ってくることがあります。
・aws-sdk の使い方を聞いたら古いSDKのコードが返ってくる
・MacOS の dd の使い方を知りたかったのに Linux の dd の使い方が返ってくる

　エンジニアS

コード品質って可読性やメンテ性のために上げたいものなので、既存コードと改修内容読んでAIが改修するようになったらコード品質の価値も変わってきますね。コード品質はAIが理解しやすいコードという定義になるのでしょうか。さすがにそこまで到達するのはまだ先だと思いたいです。

　エンジニアI

それは僕も思います。良いプログラミング言語の定義とか完全に変わりますよね。文法が明快で安定していて、かつ学習データが大量にある言語、がAIと相性の良い言語になると思っています。

最近は 複数のAIに同じ質問をしてダブルチェックするということを試みるようにしました。答えが食い違っている場合に嘘の回答を検知できるので少し便利です。

うまくいったコード修正の話

　エンジニアI

unity の c# コードを書いていて、よくわからない syntax error が出たので該当コード部分を張り付けてどこを直せばよい？と聞いたら何とかなりました。

Google時代はエラーメッセージ＞原因＞解決策という思考のステップを踏む必要がありましたが、どう直せばよいのかの答えがワンステップで出てくるのは便利な一方で、浅い理解のまま突き進むようになりそうです。これからの若いエンジニアは勉強が大変になる気がします。

GPT-4 Turbo は大きなドキュメントも入力として与えられるようになったみたいなので、「仕様のドキュメントを全部読ませて〇〇する」ということができるようになるかもしれませんね。

＜参考記事＞
GPT-4 Turboでいちばん嬉しいのは、300ページ相当の長文をまるっと読み込めること

GitHub Copilot Chat 使ったコード生成

　エンジニアK

事例の紹介です。GitHub Copilot Chat を使ってコード生成してみたところ、かなりうまくいきました。

・ドメインモデルからDTOを生成
・DTOからドメインモデルへの変換関数を生成
・変換関数のunit testを生成

これらをかなりいい感じで実現できました。シリアライズ用のDTOは、腐敗防止層として働かせるために作ったほうがベター、というのは多くの人が合意すると思うのですが、ほぼ同じデータ構造を定義、変換関数を作らないといけないので、その実装作業が煩わしくて敬遠されることが多々有りました。

これをAIに実装を任せることができるのであれば、DTOを導入するハードルがぐっと下がりそうです。コードが生成されるまで多少時間がかかりますが、人間が手で実装するよりはかなり速い、という感じでした。

使ったコマンド

使ったコマンドを共有します。unit test のダミー値も生成してくれるのはすごく便利でした。

• このファイルに定義されたクラスのDtoクラスを実装してください。
• enum class への参照は String にせず、enum classへの参照のままにしてください。
• data class への参照は、XxxDto のように Dtoを末尾につけたクラス名への参照にしてください。
• ただしその data classがすでに @Serializable アノテーションを持っているなら、クラス名は変更しないでください
• KyotuSheetDto から KyotuSheet への変換関数を実装してください。
• convertDtoToKyotuSheet の挙動を確認する unit test を実装してください。
• パラメータの初期値には適当な値をセットしてください。
• assertion ですべてのプロパティの値のチェックを行ってください。

所感

• 回答が長くなりすぎると途中でタイムアウトで中断されてしまうことがありました。
• 開いているファイルの情報を入力元にしているようで、開いてないファイルの情報はあまり使ってない感じでした。将来的にはリポジトリに含まれる全ファイルを入力元にして回答するように進化してくれるとうれしいですね。

まとめ

いかがでしたでしょうか？

現在、様々なジャンルでAIが世界を席巻しています。プログラミングの世界でも、ChatGPTとの競争・共存は既に始まっており、エンジニアとして淘汰されないためには、AIとの上手な付き合い方を探り、活用できる部分は積極的に活用するというスタンスが必要なようです。

メディアマックスジャパンには、最新の情報を共有しながら、よりレベルの高いスキル獲得に向けて切磋琢磨できるエンジニア仲間がたくさんいます。プログラミングが大好き、プログラムを極めたい、というエンジニア・プログラマーの方は弊社求人へのご応募をお待ちしています。

The post 現役エンジニアがChatGPT、Copilotを使った所感 first appeared on メディアマックスジャパン求人採用情報.