dokckerのnginx-proxyコンテナ内で http://www.nginx-web に対してcurlしたら内容が見えるのに、ブラウザで開けなくて困っている時にワンチャン参考になるやつ
結論
nginx設定の再読み込みコマンドを実行する。
$ docker exec nginx-proxy nginx -s reload
詳細
例えば、http://nginx-webに対してcurlしたときの内容が以下の通りだったとする。
$ docker compose logs -f nginx-proxy nginx-proxy | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration nginx-proxy | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ nginx-proxy | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh nginx-proxy | 10-listen-on-ipv6-by-default.sh: info: can not modify /etc/nginx/conf.d/default.conf (read-only file system?) nginx-proxy | /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh nginx-proxy | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh nginx-proxy | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh nginx-proxy | /docker-entrypoint.sh: Configuration complete; ready for start up nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: using the "epoll" event method nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: nginx/1.29.0 nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14+deb12u1) nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: OS: Linux 6.6.87.2-microsoft-standard-WSL2 nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: start worker processes nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: start worker process 21 (中略) nginx-proxy | 2025/10/07 09:36:59 [notice] 1#1: start worker process 36
nginx-proxyコンテナ内からcurlでhttp://nginx-webにアクセスできるのに、外部（ブラウザなど）からアクセスできない場合、ネットワークやポートの設定、nginxの設定、またはボリュームのマウント方法に問題がある可能性が考えられる。
主なチェックポイント
dockerでnextcloudを動かす練習中にハマったので、その前提の環境構築があるとして。
(わかる人向け：2025年の処理研のネサバ研の8回目の内容)
services:
cloud:
build:
context: ./
container_name: cloud
image: nextcloud:31.0.2
restart: always
environment:
- MYSQL_HOST=cloud-db
- MYSQL_PASSWORD=${CLOUD_DB_PASSWORD}
- MYSQL_DATABASE=${CLOUD_DATABASE}
- MYSQL_USER=${CLOUD_DB_USER}
- PHP_MEMORY_LIMIT=1024M
- PHP_UPLOAD_MAX_FILESIZE=10G
volumes:
- cloud:/var/www/html
links:
- cloud-db
- redis
cloud-db:
container_name: cloud-db
image: mariadb:11.4
restart: always
environment:
- MARIADB_DATABASE=${CLOUD_DATABASE}
- MARIADB_USER=${CLOUD_DB_USER}
- MARIADB_PASSWORD=${CLOUD_DB_PASSWORD}
- MARIADB_ROOT_PASSWORD=${CLOUD_DB_ROOT_PASSWORD}
tty: true
volumes:
- cloud-db:/var/lib/mysql
redis:
image: redis
container_name: redis
restart: always
ports:
- "6379:6379"
volumes:
- redis-data:/data
nginx-proxy:
image: nginx
container_name: nginx-proxy
restart: always
ports:
- "80:80"
volumes:
- ./default.conf:/etc/nginx/conf.d/default.conf:ro
depends_on:
- cloud
nginx-web:
image: nginx
container_name: web
restart: always
volumes:
- ./webContents:/usr/share/nginx/html
depends_on:
- nginx-proxy
volumes:
cloud:
driver: local
driver_opts:
type: none
device: ./cloud-app
o: bind
cloud-db:
driver: local
driver_opts:
type: none
device: ./cloud-db
o: bind
redis-data:
driver: local
server {
listen 80;
server_name _;
client_max_body_size 10G;
proxy_connect_timeout 3600;
proxy_read_timeout 3600;
send_timeout 3600;
location ~ /nextcloud {
rewrite ^/nextcloud/(.*)$ /$1 break;
proxy_pass http://cloud;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://nginx-web;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
error_page 404 /404.html;
location = /404.html {
root /var/www/html/errors;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www/html/errors;
}
}
例えばdefault.confなどに上記のような設定が含まれる場合、
- nginx-proxyのlocationはhttp://nginx-webにproxy_passしているのでnginx-proxy経由でnginx-webにアクセスできるはず。
- docker-compose.ymlでnginx-proxyはポート80をホストに公開している（"80:80"）。
- nginx-webはdepends_onでnginx-proxyに依存しているが、ポート公開設定がない（ports:がない）。
この場合にわかることは、nginx-webは外部に直接公開されておらず、nginx-proxy経由でのみアクセス可能であるということ。
curlでnginx-proxyコンテナ内からhttp://nginx-webにアクセスできるのは、Docker内部ネットワークで名前解決できるため。
しかし、外部（ホストPCやブラウザ）から http://localhost:80 でアクセスした場合、nginx-proxyがnginx-webにproxyする際に、nginx-webの設定やwebContentsの中身、またはnginx-webのdefault.confの設定によっては正しく表示されないことがある。
よくある原因
- nginx-webのdefault.confが正しく設定されていない（index.htmlのパスやrootディレクティブの問題）
- webContentsディレクトリの中身が空、またはindex.htmlが存在しない
- nginx-webのdefault.confがデフォルトのままで、webContentsが正しくrootに設定されていない
問題解決アプローチ (GPT-5による)
nginx-webコンテナ内のnginx設定ファイルを確認してみます。まず、nginx-webコンテナが実行中かどうか確認し、その中の設定ファイルを探してみましょう。
$ docker compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS cloud nextcloud:31.0.2 "/entrypoint.sh apac…" cloud 8 minutes ago Up 8 minutes 80/tcp cloud-db mariadb:11.4 "docker-entrypoint.s…" cloud-db 8 minutes ago Up 8 minutes 3306/tcp nginx-proxy nginx "/docker-entrypoint.…" nginx-proxy 8 minutes ago Up 8 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp redis redis "docker-entrypoint.s…" redis 8 minutes ago Up 8 minutes 0.0.0.0:6379->6379/tcp, [::]:6379->6379/tcp web nginx "/docker-entrypoint.…" nginx-web 8 minutes ago Up 8 minutes 80/tcp
nginx-webコンテナ（webという名前）が動いているので、その中のnginx設定ファイルを確認してみます。
$ docker exec web cat /etc/nginx/conf.d/default.conf
server {
listen 80;
listen [::]:80;
server_name localhost;
#access_log /var/log/nginx/host.access.log main;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
このファイルによると:
* root /usr/share/nginx/html; でドキュメントルートが設定されている
* index index.html index.htm; でindex.htmlまたはindex.htmをデフォルトページとして設定されている
問題が何なのか、実際にブラウザでアクセスした時の状況を確認してみましょう。まず、nginx-proxyとnginx-webのログを確認してみます。
$ docker compose logs nginx-web web | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration web | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ web | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh web | 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf web | 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf web | /docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh web | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh web | /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh web | /docker-entrypoint.sh: Configuration complete; ready for start up web | 2025/10/07 09:36:59 [notice] 1#1: using the "epoll" event method web | 2025/10/07 09:36:59 [notice] 1#1: nginx/1.29.0 web | 2025/10/07 09:36:59 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14+deb12u1) web | 2025/10/07 09:36:59 [notice] 1#1: OS: Linux 6.6.87.2-microsoft-standard-WSL2 web | 2025/10/07 09:36:59 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576 web | 2025/10/07 09:36:59 [notice] 1#1: start worker processes web | 2025/10/07 09:36:59 [notice] 1#1: start worker process 29 web | 2025/10/07 09:36:59 [notice] 1#1: start worker process 30 web | 2025/10/07 09:36:59 [notice] 1#1: start worker process 31 (中略) web | 2025/10/07 09:36:59 [notice] 1#1: start worker process 43 web | 2025/10/07 09:36:59 [notice] 1#1: start worker process 44
nginx-webのログも正常に見えます。実際にlocalhost経由でアクセスして動作確認してみましょう。
$ curl -I http://localhost/ HTTP/1.1 307 Temporary Redirect Server: nginx/1.29.0 Date: Tue, 07 Oct 2025 09:47:10 GMT Content-Type: text/html; charset=utf-8 Connection: keep-alive Location: https://localhost/
おお！問題が見つかりました！
HTTP（port 80）でアクセスすると、HTTPSにリダイレクト（307 Temporary Redirect）されています。これは、nginx-webまたはnginx-proxyのどこかでHTTPS強制リダイレクトが設定されていることを意味します。
しかし、HTTPS（port 443）は設定されていないため、ブラウザでアクセスしようとすると接続できません。
この307リダイレクトがどこから来ているのか確認してみましょう。nginx-proxyコンテナ内から直接nginx-webにアクセスしてみます。
$ docker exec nginx-proxy curl -I http://nginx-web/
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 6148 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
HTTP/1.1 200 OK
Server: nginx/1.29.0
Date: Tue, 07 Oct 2025 09:47:21 GMT
Content-Type: text/html
Content-Length: 6148
Last-Modified: Tue, 07 Oct 2025 08:09:18 GMT
Connection: keep-alive
ETag: "68e4caae-1804"
Accept-Ranges: bytes
nginx-webは正常にHTTP 200を返していますが、nginx-proxy経由でアクセスすると307リダイレクトが発生しています。
これは、nginx-proxyコンテナ内のnginx設定に何かHTTPS強制リダイレクトの設定があるか、もしくはnginxのデフォルト動作に何か問題がある可能性があります。
nginx-proxyコンテナ内の他の設定ファイルを確認してみましょう。
$ docker exec nginx-proxy find /etc/nginx -name "*.conf" -type f /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
$ docker exec nginx-proxy cat /etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log notice;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
メイン設定ファイルは標準的です。問題の原因を特定するために、nginxのアクセスログとエラーログを確認してみましょう。
$ docker exec nginx-proxy tail -n 20 /var/log/nginx/access.log
$ curl -v http://localhost/ 2>&1 | head -n 20
$ docker exec nginx-proxy curl http://nginx-web/ 2>/dev/null | head -n 10
nginx-webは正常にHTMLを返しています。問題はnginx-proxyの設定または動作にあります。
よく考えてみると、docker-compose.ymlでnginx-proxyの設定を見ると、default.conf がread-onlyでマウントされていますが、nginxのログに「read-only file system?」という警告が出ていました。
また、curlの結果で307リダイレクトが発生している原因を突き止める必要があります。
リダイレクトの内容を詳しく見てみましょう。
$ curl http://localhost/ 2>/dev/null
予想では、nginx-webコンテナ自体がHTTPS強制リダイレクトを行っている可能性があります。nginx-webコンテナ内でもう少し詳しく調査してみましょう。
$ docker exec web find /etc/nginx -name "*.conf" -type f /etc/nginx -name "*.conf" -type f /etc/nginx/nginx.conf /etc/nginx/conf.d/default.conf
$ docker exec web cat /etc/nginx/nginx.conf
/etc/nginx/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log notice;
pid /run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
nginx-webの設定ファイルも標準的です。
それでは、リダイレクトがnginx-proxy段階で起きているのかnginx-web段階で起きているのかを特定してみましょう。nginx-proxyから直接nginx-webにアクセスして、レスポンスヘッダーを詳しく見てみます。
$ docker exec nginx-proxy curl -v http://nginx-web/ 2>&1 | grep -E "(< |> |HTTP)" > GET / HTTP/1.1 > Host: nginx-web > User-Agent: curl/7.88.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.29.0 < Date: Tue, 07 Oct 2025 09:55:05 GMT < Content-Type: text/html < Content-Length: 6148 < Last-Modified: Tue, 07 Oct 2025 08:09:18 GMT < Connection: keep-alive < ETag: "68e4caae-1804" < Accept-Ranges: bytes <
nginx-webは正常にHTTP 200を返しています。つまり、307リダイレクトはnginx-proxyが生成しています。
これは非常に奇妙です。nginx-proxyの設定（default.conf）を再度確認してみても、HTTPSへのリダイレクト設定は記載されていません。
もう一度、nginx-proxyコンテナ内の現在有効になっている設定を確認してみましょう。
$ docker exec nginx-proxy cat /etc/nginx/conf.d/default.conf
server {
listen 80;
server_name _;
client_max_body_size 10G;
proxy_connect_timeout 3600;
proxy_read_timeout 3600;
send_timeout 3600;
location ~ /nextcloud {
rewrite ^/nextcloud/(.*)$ /$1 break;
proxy_pass http://cloud;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://nginx-web;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
error_page 404 /404.html;
location = /404.html {
root /var/www/html/errors;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /var/www/html/errors;
}
}
設定ファイルには問題ありません。
もしかすると、proxy_set_header X-Forwarded-Proto $scheme; が関係しているかもしれません。nginx-webが X-Forwarded-Proto ヘッダーを受け取って、それに基づいてHTTPSリダイレクトを行っている可能性があります。
この仮説を検証してみましょう。
$ docker exec nginx-proxy curl -v -H "Host: localhost" http://nginx-web/ 2>&1 | grep -E "(< |> |HTTP)" > GET / HTTP/1.1 > Host: nginx-web > User-Agent: curl/7.88.1 > Accept: */* > < HTTP/1.1 200 OK < Server: nginx/1.29.0 < Date: Tue, 07 Oct 2025 09:55:05 GMT < Content-Type: text/html < Content-Length: 6148 < Last-Modified: Tue, 07 Oct 2025 08:09:18 GMT < Connection: keep-alive < ETag: "68e4caae-1804" < Accept-Ranges: bytes <
nginx-webは常にHTTP 200を返しています。
では、nginx-proxyが何らかの理由で307を返しているのを詳しく調べてみましょう。nginx-proxyのnginx設定を再読み込みして、問題が解決するかテストしてみます。
$ docker exec nginx-proxy nginx -s reload 2025/10/07 09:56:52 [notice] 101#101: signal process started umiwatarin@LAPTOP-D0SRT900:~/dev/my-cloud-service$ curl -I http://localhost/ HTTP/1.1 200 OK Server: nginx/1.29.0 Date: Tue, 07 Oct 2025 09:56:56 GMT Content-Type: text/html Content-Length: 6148 Connection: keep-alive Last-Modified: Tue, 07 Oct 2025 08:09:18 GMT ETag: "68e4caae-1804" Accept-Ranges: bytes
$ curl -I http://localhost/
2>/dev/null | head -n 5
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
素晴らしい！問題が解決しました！
nginx設定の再読み込み（nginx -s reload）によって、307リダイレクトの問題が解消され、正常にHTTP 200が返されるようになりました。
実際にブラウザでアクセスできるかも確認してみましょう。
$ curl http://localhost/ 2>/dev/null | head -n 5
完璧です！HTMLが正常に返されています。
解決策の総括
問題の原因： nginx-proxyが何らかの理由で設定の読み込みに問題があり、正しく動作していませんでした。nginx-proxyコンテナ内からnginx-webへの直接アクセスは正常でしたが、外部からnginx-proxy経由でのアクセス時に307 HTTPSリダイレクトが発生していました。
解決方法
$ docker exec nginx-proxy nginx -s reload
nginx設定の再読み込みコマンドを実行することで、問題が解決しました。
今後の予防策
- docker-compose.ymlでnginx-proxyコンテナを再起動する際は、設定が正しく読み込まれているか確認する
- nginx設定ファイルを変更した場合は、必ずreloadまたはrestartを実行する
- ログメッセージに「read-only file system?」という警告が出ている場合は、設定のマウント方法を確認する
マクドナルド理論を解説：ネタを選ぶ技術
この記事は
UDHI-LAB++; Advent Calendar 2024
の3日目の記事です
さて、この記事を書くにあたって、「私に何を書いて欲しいかリクエストを募集します」とUDHI-LABメンバーに伝えたところ、「何でもいいですよ」と甘ったれた回答を寄越してきやがりました。
違うんですよ、リクエストを募集したのは、私の技能に期待されているものを知りたいとかそういうことばかりではなく、ここでメンバーに求めていることは、いわゆる「マクドナルド理論」と呼ばれるもので、私が確実に実現できるネタの中で最低の出来になりそうなボーダーラインを示してもらうことで、自らそれよりマシなネタをブログで取り上げようとするためのサンドバックになってもらうことなのです。
いやサンドバックにする事が主題ではないですよ？
と、何でもいいですよって答えられると困るよという話をネタにすればいいじゃないかと閃き、今日は「マクドナルド理論」を取り上げたいと思います。
続きを読む
遊休ブログ Advent Calendar 2024 を開催します！
この記事は「遊休ブログ Advent Calendar 2024」の1日目の記事です。
1日目の記事にします。
なんか久々にブログ書いたし、せっかくこの季節だから趣旨に合ったアドベントカレンダーにでも参加しようと思って探したのですが、いい感じのがなかったので、フリースタイル枠を設けました。
小僧の頃の自分は、中川翔子さん *1 や上地雄輔さん *2 のブログに憧れていたもので、いっぱい書けばええんやろの精神でいました。
しかし、成長するにつれて、ネットワークリテラシーなるものが身に付き、リアルタイムな情報発信のリスクを気にするようになったり、個人情報の安売りみたいな情報の出し方に違和感を覚えるようになってしまいました*3。
そうやってブログに書くことを吟味なんかしだしたら、悩み事とかも書かなくなるし、今目の前で食べているご飯の話や今いる場所の話も当然しなくなります。
多分そういうのはSNSに情報を流すようになって、そこからさらにSNSにもリアルタイムには情報を出さなくなって、つまるところ何も情報を出さなくなってしまいました。
後から情報を出そうにも、思い出すことや記録を遡ることも億劫になってしまいました。
悲しい。これはきっと悲しい。もったいない。
こうなったら何でもいいからブログを書くぞのお気持ちだけで手を動かしたい。
頭で何を書こうか考えなくてもいいやつがいい。
初速が大事。
桜井さんも言ってた。
というわけで、フリースタイルブロギングです。
YOU BLOG!!!!!!!!
エントリーと概要はこちら↓
TechRAMENでスタッフやりながら皆様の発表見てました #techramen24conf
あれから早4ヵ月。まだ4ヵ月。4ヵ月もあれば広葉樹もハゲ散らかして山に布団を被せてあったかくしてあげる時期にもなります。初雪も降ったし。
只今、スタッフ合宿で石狩沼田に初めて滞在しているのですが、「合宿ならブログ書け」という実行委員長 （@tomio2480） のありがたいお言葉により、この合宿中に消化しようと思っていた研究を進めることと、来週のプログラミングコンテストの司会台本を書く仕事をいったん放りだして、今このブログを書き出した次第にございます。
中間発表を待っている人と、台本待っている人、ごめんなさい。
これ書いたらやります書きますので、間に合うことをお祈りください。
。
続きを読む
勤続200日達成記念・k-Hack 在職エントリ「大学院に入学します」
現職にて、200回の出勤を達成したので、在職エントリ（？？？）を書きます。
（とある地方ITコミュニティ盛り上げ大臣主催の強制的にアウトプットを生み出す会に参加している最中なので）
さて、いきなりですが、大学院に合格しました。
来月（あと2週間ほどですね）から、日本最北の国立大学にて、博士後期課程に入学します。
会社側も、受験時期から応援いただき、合格の際には雇用状態の調整をしてくれることになりました。
入社半年を過ぎたばかりの新卒に斯様な手厚い対応を頂いていること、会社には誠に感謝しております。
また、関係会社の方にも、稼働少ない新人の不思議なマニューバをご理解いただき誠にありがたい処遇を頂いております。
業務としては私が技術や見識に暗いところもあったこともあり、初めて尽くしで経験を積まさせていただいているところで、環境として恵まれていることと思っております。
年末には大手町で1か月ほど社員研修を受けさせていただいたりと、新卒のスタートとしては手厚く面倒を見ていただいていると思います。
...とまあ、会社に感謝してばかりなのですが、私めの成長速度というか、学習能力は比較的に亀の歩みなので、仕事以外でも会社に（あるいは他の社員の方に）還元できるように頑張っていこうと思います。
具体的には、（200日もなかったけど）アウトプットを社員に向けて行ったり、社外に向けて行ったりしたいと思います。
というわけで、宣伝。
3月30日に、札幌で JMLT vol.7 が行われます。
毎度（なぜか）好評のJMLT、次回もなんと参加枠が残すところあと1つでございます。
私もアウトプットを行いたいと思いますが、あと一人の方も是非アウトプットしに来て下さい。お待ちしております。
牛乳界隈に声出して笑ってしまった https://t.co/ivzFXuyOGd
— 旭川から小平市をはじめ各地に飛び立つ地方ITコミュニティ盛り上げ大臣とみお (@tomio2480) 2024年3月22日
これはこのイベントが浸透してきている結果
k-Hack 入社エントリ
9月1日より、株式会社k-Hackに正社員雇用されました。
世の中の入社エントリがどのような事柄を書いているのか、今この行を書いている段階では存じ上げないので、ちょっと読み込んでみます。
...
... ...
... ... ...
なるほど。
大体の入社エントリは、実績をあげているつよつよなエンジニアの皆様が、（転職などで）入社した会社の強みとか製品のアピールをしているそうですね。
なので（新卒で入社した）弊社のアピールをちょっとしようと思います。
---
弊社は国内初の官民連携により設立したIT開発を担う会社であります。
地元の高等教育機関と連携し、IT人材の育成と採用に取り組むことを掲げています。
弊社の魅力は、地方にもこんなITコミュニティを作ることができるんだよというモデルケースたる存在になっていくことが挙げられ、人材育成の方針などが明確になっている点も魅力的だと思います。
それから、CTOが考えた会社のロゴのデザインがイカシテマス。
---
その他に、入社エントリとは何かを見ると...
入社エントリは「実際に入社してみてどうだったか」という感想を書くことが多いので、入社後しばらく経過してから投稿されるといった特徴があります。
とか、
入社エントリの内容は人それぞれですが、一般的には以下のようなトピックが書かれています。
- 転職を考えたきっかけ
- 企業選びや就職活動で心掛けたこと
- 採用面接やテストに向けて行った対策
- その企業への入社を決めた経緯
- 今回の就職活動で得た知見やノウハウの公開
- 入社してからの感想
- 今後この会社で取り組みたいことや目標
ということらしいです。
というわけで、入社初日にして早速書いていくことにします。
さて、事の経緯は立ち上げの時期にCTOにお声がけいただいたところから始まります。
その時に、会社としての成長方針や社員の育成方針、会社の将来性等に惹かれ、正社員での雇用を希望しました。
面接でCEOに尋ねられたことは、当時の自分では直ぐに答えることができない、一本気のある芯が固い意志を示さねばなりませんでした。
CEOから答えを用意する時間を頂いたもののさて困ったと思ったとき、ちょうど山籠りの予定がありました。
そこで、その山場にて、とある地方ITコミュニティ盛り上げ大臣に仕事に対する姿勢などを教えてもらい、深夜のビデオ通話に居合わせたとある偉い人にも会社とはどういう生き物なのか、新卒を雇い入れるとはどういうことかを懇切丁寧に教えていただき、CEOに投げかけられた「問い」に対する「答え」を出しました。
後日CEOに示したその「答え」は、CEOを納得させるに足る答えとなったようで、この度の正社員雇用と相成りました。
そうして、本日の初出勤からの初仕事となりましたが...
オフィスの開所日でもありました。
なので(?)、最初の業務は取材を受けることでした。
新聞一面載ったどー。
オフィス開きに祝いに駆けつけて下さった方や報道陣を見るに、弊社への期待の大きさを感じ取ることができました。
なので(??)、真新しいオフィスで、真新しいOA製品に囲まれ、すさまじい湿気に立ち向かう除湿器も全力でぶん回ってました。
場所柄、湿気ることが茶飯事なのでこれからも除湿器は全力で立ち向かって行ってくれることでしょう。
ここまで読んでいただいた方で、この新卒入社エントリが一般的な就活フローに全く則っていないことで、大いに役に立たないと感じられた方もいらっしゃるでしょう。
多分それはそう。申し訳ございません。そういうパターンもあると思って :pray:
初日のお仕事としては、取材の後、お仕事用のMacbook（CTOが機材の選定をとても頑張って良いものにしたとか）を貰って環境をセットアップし、業務の打ち合わせをして、指示された学習項目を進めるなどしました。
退勤後には、オフィス開き祝い（と入社祝いを兼ねていたかも）でチーフなんちゃらオフィサー陣がご飯をたらふく食べさせてくれました。具体的には3軒はしごしたし天辺も回った。
弊社の偉い人達、全員が草鞋を二足以上履いている人たちなので、忙しい仕事を捌きまくってるすごい人たちなのですよね。
そんな人たちから仕事のノウハウや姿勢を学べるまたとない機会なので、ぺーぺーの新卒社員として役に立てる人材になるところを目指して頑張りたいと思います。
以後よろしくお願いします。
空飛ぶクルマの展示のお手伝いをした話。
書き出し
先般、『G7札幌 気候・エネルギー・環境大臣会合』を受けたイベント、『環境広場ほっかいどう2023』がありました。
そちらのイベントで、「空飛ぶクルマ」が2種類展示されておりました。
SkyDrive社の機体と、今回お手伝いしたteTra aviation社の機体。
イベント会場入口に金剛力士像の如く並べられていたので、来場者が受けるインパクトとしては強力なものだったと思います。
後ろに燃料電池自動車も構えていましたし。
「空飛ぶクルマ」って何？
まずは言葉の説明から。
「空飛ぶクルマ」というのが法的な区分があってそう呼称しているという話では（現段階では）ありません。括り的には航空機です。
「空飛ぶクルマ」というのは意匠的な意味合いがあり、「将来的には自家用車のように個人が所有し個人が移動するために用いられる乗り物になりたい」という願いが込められているとのことです。
操縦資格とか車庫証明とか国内法回りの事は国交省や経産省とのOHANASHIが待たれるところだと思います。
今回展示した両社とも、次の大阪万博で試験飛行する予定だそうです。楽しみですね。
機体の紹介
さて、今回お手伝いした『teTra MK-5』を紹介します。
機体番号：N155TA（米国で認定）
販売時期：2023年中（米国より販売開始・予約販売は実施中）
販売価格：USD 400,000
機体スペックなどの詳細はせっかくなので公式をご覧ください。
機体と来場者に触れた所感
機体の搬入から組立、説明員、解体、搬出までやりました。
固定翼の取り付け角度がすべて異なっていたり、機能分散による安全設計など、機能美を感じられる点が多く、ハードウェアの作りこみに感服いたしました。
来場者の方にも、回転翼の多さに驚き、安全面からの機能性に感心される方が多かったです。
他方、機体の大きさや主翼の数、電動での動力性能や搭乗人数などに興味を示す方もいらっしゃり、今後の機体開発の展望を尋ねられる方もいらっしゃいました。
「これを見たくて来たの！」と歓喜されている方もいらっしゃいました。
老若男女、多くの方にご覧いただいた展示でしたが、やはり空への憧れが強い世代の機体への期待の寄せ方は印象深かったです。
イベントの話
近未来な展示品で来場者を出迎え、環境保全への取り組み活動や研究報告などで啓蒙し、ステージ講演や体験型展示で考えたりとお堅さと面白さを兼ね備えたイベントであったと思います。
基本ブースで応対していたので、イベントを詳細に見て回ることはできませんでしたが、楽しい・ためになるコンテンツが充実していたと思います。
母校の入試担当の事務員が仕事で来ていたっぽいことには驚きましたが。
まとめ
空飛ぶクルマ、そろそろ飛ぶよ！
関連リンク
