小山内 裕

気付けばデータベースエンジニア

ブックルックチーム代表の小山内です。
今日は私がIT未経験の新社会人としてテクニカルサポートから出発し、データベースエンジニアになるまでの道のりと、データベースエンジニアとしての経験を紹介したいと思います。

データベースエンジニアになるまで主に次の3つのステップがありました。

1つ目がクライアントPCの基本的な技術の獲得

2つ目がネットワークとサーバーサイドの知識と経験

3つ目がデータベースエンジニアの知識と経験

それぞれのステップとステップの間には「ツナギ」となる仕事がありました。必然的偶然のようなツナギの仕事です。
ツナギの仕事がデータベースエンジニアへと私を導きました。
突然データベースエンジニアになったわけではありません。自然と、本当に気付いたら、データベースエンジニアになっていたというのはそういうことだからです。
振り返れば、これら「ツナギ」の仕事がいかに重要だったかがわかります。

後半はデータベースエンジニアとしての失敗談や苦手なデータベース操作についてもお話しします。

悲鳴を上げるECサイト、1つしかないデータベース

2000年初期、米デル(現、デル・テクノロジーズ)の日本向けECサイトはいつも悲鳴を上げていました。
毎日何万の人がサイトに訪れ、何百ものパソコンがオーダーされます。
人手ではとうてい対応しきれないほどの注文が絶え間なく自動的に入ってきます。
そのため営業部門はサイトの24時間稼働は当然のことと考えていました。
それなのに、ちょっとした躓きでサービスダウンが発生する、という毎日でした。

ECサイトのWEBサーバーを増やし、いくら負荷分散したところで、サイトのパフォーマンスは改善されません。
なぜならば、データベースはたったの1台。
1台しかないデータベースは、フロント(ECサイト)を構成する複数のサーバーからのリクエスト処理がやってくるだけでなく、バックエンドで実行されているバッチ処理数だけでが毎日数千あり、リクエスト数は数えきれないほどありました。
そのため当時のデータベースサーバーは最高水準のスペックでしたが、常に高負荷になっていました。

この山に真正面から向かい、越えられたことが私のデータベースエンジニアとしてのスキルと経験を飛躍的に高める結果となりました。

ITエンジニアになったきっかけ

私がITエンジニアになったきっかけは、デルとの出会いが大いに関係しています。
その出会いに先駆けて、1995年、私は当時2部上場のトランス・コスモスに入社することとなり、入社前の2月頃から同期数十名と一緒に技術研修を受けました。
学生時代からパソコンに慣れ親しんでいる同期は当然のこととして話を聞いていました。
私はパソコンにほとんど触れたことがなく、見聞きすることが初めてのことばかりでした。
研修後も毎日、機械慣れしていない女子たちと一緒に、詳しい男子に教えてもらっていました。

筆者が新人研修の時の研修日誌

そうこうしていると4月になり、同期のみんなは某プリンタメーカーのサポート業務部門に配属されていきました。
スタートから出遅れていた私だけが本社に取り残されました。
この先どうなるのかと心配しましたが、ゴールデンウイーク明けになってようやくデルでのパソコンのテクニカルサポートの仕事があてがわれました。

それは1995年、デルの日本進出2年目でした。当時の社名はデル・コンピュータ。
デルでは、「立ち止まって考えるな、走りながら考えろ」、「早くやれ、完璧は求めない、8割できれば成功だ」、「自分で判断しろ、人に聞くなら自分の答えを決めてからにしろ」という個人のパフォーマンスと成長を優先する合理的な行動をよく求められました。
私にとってはとても理解し易い、シンプルな考え方に思えました。しかも、多くのことを任せてもらえるし、やりがいもありました。

デルはハードウェアメーカーですが、仕事に必要な知識は非常に広範囲でした。
マザーボード、CPU、メモリ、ハードディスクに留まらず、OS、ネットワーク、サーバー、プリンター、ディスプレイアダプタ、サウンドカード、SCSI機器など。毎日毎日聞いたことのない単語がサポートを求めるお客様から出てきてその度に調べていました。
本で読んで実機で試すことを繰り返し行いました。ハードウェアとソフトウェアの関係性を学ぶことも多くありました。
一定の知識がなければ即刻退場となる厳しい環境でしたから必死で知識を身に付けました。

でもこれはまだステップ1。ハードウェアとソフトウェアの基本的な技術、つまり主にクライアントPCを使うために必要な知識の獲得に過ぎませんでした。

サーバーサイドのスキルアップ

データベースエンジニアにたどり着くまでにもう2段階あります。
ステップ2は、ネットワークとサーバーサイドの知識と経験の獲得です。

2年目になると私はテクニカルサポートに必要な知識を身に付け、チーム内で常にナンバーワンの業績を出すようになりました。
一方で、鳴りやまないお客様からの電話対応に疲れ果てていました。
私の仕事量を減らすにはどうしたらよいか考えました。それは私以外のメンバーがもっとたくさんの電話を取ってくれることです。

私がナンバーワンを維持する秘訣である自作のQ&A集を社内に公開することにしました。
私は電話で問い合わせを受けたらFAXで回答を送ることで、1件あたりの対応時間の短縮を図っていました。
1度作成したドキュメントは保存しておき、同じ問い合わせが来たらFAXで送信するだけ、ということを繰り返していました。

社内の情報共有はNotesで行われていましたが、大小100以上あるドキュメントの更新や検索のし易さの点で、HTMLで作成して共有することとしました。

これがツナギの仕事です。ステップ1とステップ2をつなぐきっかけになったのです。
クライアントPCからネットワークやサーバーサイドへ行かざるを得なくなったのです。

当時の米Yahooを真似てディレクトリ型のページを作成しました。複数カテゴリへの登録、ドキュメント間のリンクなど今では当たり前ですが、当時は画期的でした。
それでも目的のドキュメントが見つからない、とメンバーから何度も言われ、私が検索して見つけて渡すということが度々ありました。

そんなこんなでデルでの2年半の仕事の後、ソニーのVAIOのコールセンターの立ち上げを行うこととなりました。
VAIOのコールセンターはデルの何倍もの人数の部隊でした。
私はデルでの業績を買われ、メンバーを支援する後方部隊の仕事を任されました。
同じように「こういうお問い合わせにはこう答えましょう」というQ&A集「chaco」を提供しました。
chacoは私が小学生のときに飼っていたメスの三毛猫の名前です。

chacoの設計書の一部

chacoはVAIOのお客様の特性に合わせ発展させていきました。
BIOSのシミュレーション画面や、パソコンに同梱される物やソフトウェアの情報なども追加し、実機が手元に無くても電話でサポートできるようにしました。
間もなくHTMLでは対応しきれなくなり、WEBサーバーを構築し、サーバーサイドのコーディングが必要になりました。
プログラミングもしたことがなかったので、社内の誰か出来る人がいないかと本社にお願いしましたが、そこまでできないということで、最初のやり方だけ教えてもらいました。
あとは本を片手に試行錯誤でとりあえず構築しました。

しかし、見様見真似だけではわからないことが多く、一から本を読んで勉強する必要性を実感し、ネットワークの基礎、Windows Server、TCP/IP、IISなど手近なところからやりました。

ここまでで、ステップ1(パソコンの基本スキル)、ステップ2(ネットワーク/サーバーの知識と経験)と来たわけですが、これが次のステップ3(データベースエンジニア)へと進む大きな自信になりました。

WEBサイト管理のコアはデータベース

ソニーVAIOコールセンターでサポートシステムchacoが軌道に乗ったところで転職活動をしたらたまたまデルに入社することとなりました。2000年1月のことです。
chacoのことは後輩に任せましたが、その後10年ほど進化しながら利用され続けたと聞きました。

デルではカスタマーサポート部に配属され、サポートサイトで公開するコンテンツ開発を行いました。
よくあるお問い合わせをコールセンターから仕入れドキュメント化し、WEBで公開する仕事です。サーバーも触らないし、コーディングもしません。

しかしこれがステップ3へのツナギの仕事になったのです。

サポートサイトではどれほどコンテンツを追加しても、コールセンターへの電話の数は減ることはありませんでした。その原因を追究していくとサイトのユーザビリティに行きつきました。
欲しい情報がすぐ見つかる、使い易いサイトを目指し改善を重ねました。

一方で、私は社内用のコールセンター向けのコンテンツサーバーを立上げ、検索エンジンを導入し、社内イントラサーバーの開発を行っていました。

しばらくすると同じ部署でサーバーを管理していたエンジニアが退職することになりました。
そのため私が外部向けのサポートサイトを構成する複数のサーバーを管理することになりました。

やがて私はカスタマーサポート部から、それらサーバーと一緒にIT部門に異動することになり、ECサイトも面倒を見ることとなりました。
IT部門に異動した当初はWEBサイト管理ということで、サーバー単位で管理していました。
当時はまだクラウドのサービスは一般的ではなく、データセンターに物理サーバーを置いていた時代です。
サーバー単位なので、ハードウェア、OS、ミドルウェア(WEBサーバーとデータベースサーバー)が責任範囲でした。データベースはMicrosoftのSQL Server。
その時のECサイトは先ほど述べた通りで、ほぼ毎日事件(システム障害)続きでした。

毎日起こるシステム障害。『これは何とかしなければならない』と半ば強引に対策を施しました。
対策のメインはデータベース。チューニング、一極集中する状況の打破、システムの見える化、キャパシティプランニングなど、できることはないか、すべきことはないかとデータベースの勉強をしながら行いました。

データベースのマニュアルや教科書を読みながら、効果がありそうなことを見つけたら実際に試してみることを繰り返すことで、データベースエンジニア、データベース管理者としてのスキルと経験を身に着けていきました。

当然この私のデータベースエンジニアとしての仕事だけではありませんが、事件続きのECサイトを安定稼働させることができるようになりました。安心できるようになるまで1~2年はかかったと思います。

筆者のデータベースの勉強をしながら書き溜めたノート

いよいよデータベースエンジニア

ECサイトが安定稼働したことで、社内のその他のデータベースも面倒を見ることになりました。
MicrosoftのSQL Serverだけでなく、Oracleも含まれ、またもやチャレンジングな状況になってしまいました。

サーバー30台、データベース300以上あったと思います。
その中にまさにビッグデータがありました。世間でその単語が取り上げられるよりも先に取り扱っていました。
社内ではこのビッグデータを使ってガリガリ、ガリガリと分析をする人たちが大勢いて、頻繁に「遅い」、「時間がかかる」、「処理が終わらない」、「結果が返ってこない」、「どうやってデータを結合したらいいのか」、「欲しいデータがない」などなど私のところへ要望、質問、文句が山ほど寄せられました。

システム障害は起こらないものの、社内ユーザーからの同じことの繰り返しの問い合わせに、またもや『これは何とかしなければならない』と立ち上がるに至りました。
ビッグデータのデータベースはOracle。手法は異なるものの原理はSQL Serverと同じ。
データベースファイルの配置、インデックスの管理、バッチの管理などを見直しました。

全社のデータ分析、レポーティング業務をほぼ1日止めてしまったこともあります。
パフォーマンスチューニングのためにインデックスの再作成したのですが、データ量が多すぎて一晩経っても終わらなかったのです。
朝になり、皆が出勤してくるとどんどんリクエストがやってきてCPUを消費され、インデックスの作成が滞り、さらに時間がかかるという状況になりました。
ユーザーに謝罪しつつ、ひたすら手動でリクエストを切断し続け、ようやく午後3時ころに完了したのを覚えています。

筆者のデータベースノートの中身

データベースにまつわる人為的ミスといえば、データベースエンジニアなら1度は経験したことがあるのではないでしょうか。それはデータ削除です。
データ削除は、データの完全性を担保すべきデータベースエンジニアとして最悪なミスです。
データ削除とは、データを間違って削除したり上書きしたり、中にはデータベースを丸ごと削除したり、バックアップで本番データベースを上書きしてしまったりすることです。
バックアップから復元できればまだましです。利用頻度が高いデータベースでは、バックアップからだけでは復元できないことがあります。
実は私も1度だけあります。レコード8行を間違って削除してしまい、慌ててバックアップから復元を試みたものの、2行はどんなデータだったかもわからず永久に失われてしまいました。
間違って削除したことに気付いた瞬間、血の気が全部引きました。体温が低下し、緊張のあまり手を震わせながらデータベース操作をしました。

データベースエンジニアとして最も重要な仕事は何かと聞かれれば、私はバックアップとリカバリだと思います。
必要なバックアップを取り、万が一の時に迅速にリカバリすることができれば怖いものはだいぶ減ります。
しかし、個人的にOracleデータベースのリカバリは何度やっても慣れませんでした。
SQL ServerとOracleを管理していたのですが、前者はほぼ目をつむっていてもリカバリできます。しかし後者は確認事項が多くうまくいかないこともありました。
まず、バックアップ対象が複数あり、漏れなくバックアップをしておくことから始まります。
人が管理していたものだとそれが不十分なことがしばしばありました。SWITCH LOGを実行してからバックアップをしていないとか、初期化パラメータファイルがないとか。。。
そのためリカバリは気を使います。すべてのデータファイルが同じSCNを持っているかとか、REDOログどうするかとか。
ビッグデータを保管するデータベースの場合、試しに他のサーバーでバックアップからリカバリできるか確認するということができなかったので、リカバリしなければならないような事態にならないことを祈るだけでした。

データベースエンジニアの重要性

今やデータベースは必要不可欠な機能です。
一番最初にあった出来事のように、複数のECサーバーやバックエンドシステムからも参照されます。
常にデータの整合性、完全性、可用性、安全性を担保するシステムが求められます。

ブックルックチームでは、物理サーバーは管理していません。AWSといったクラウドのサービスを利用しています。クラウドのサービス管理は物理サーバーのそれとは比べ物にならないほど楽です。びっくりするくらい楽です。そのためエンジニアリングにより多くの時間を割くことができるようになりました。

基本的にはMySQLがメインです。しかし、リレーショナルデータベースだけでなく、アプリケーションの求めに対しNoSQLを採用したり、AuroraやRedshiftといったAWSのサービスを使ってみたりしながら最適解を探しています。

データベースエンジニアの採用情報

データベースエンジニアとして活躍したい方、是非ご応募ください。
データベースエンジニアはこのようなニーズに応えるとてもやりがいのある仕事です。
未経験の方もお気軽にお問い合わせください。最初から何でもできる人はいません。まずは出来ることをやり続け、時にチャレンジすることで経験が積み上がります。そうして気づけば高い所に立っているものです。

データベースエンジニア (DBA) の募集要項

ブックルックチーム アジャイル開発の実際

アジャイル開発を得意とするブックルックチーム

ブックルックチームはWEBシステム開発・運用を主力事業としておりますが、特に得意とするのはアジャイルというシステム開発手法を取り入れたやり方です。
アジャイル(agile)とは「機敏な」とか「動きが早い」という意味です。
改めてブックルックチームのアジャイル開発の実態をお話したいと思います。

防衛省がアジャイル開発?!

つい先日、防衛省が自衛隊で使う防衛装備品開発をウォーターフォールモデルからアジャイルモデルに変更するというニュースが流れてきました。
アジャイル開発をウォーターフォール開発と比較して、乱暴に一言でいってしまえば、スピード優先の修正前提の後戻りもあるリスクを最小限にした短期間開発です。

命にも関わる防衛装備品を直しながら開発するなんて大丈夫なのでしょうか?
いや、むしろそのリスクを取ってでもアジャイルによって得られるリターンの方が多いということなのでしょう。

着実に前進するウォーターフォール開発

ウォーターフォールによるシステム開発は、ヒアリング、方針決定、概要設計、詳細設計、機能設計、ユーザーインターフェース設計、コーディング、単体テスト、結合テスト、検品、合否判定、納品といったステップを1歩ずつ、まさに踏みしめながら進みます。
要所要所ではクライアント様に「この内容で間違いありません。今後変更する場合は別途費用をお支払いします。」と書かれた紙にハンコを押すことを求めますので、担当者様もよく内容を確認しなければなりません。
設計者や開発者についても、クライアントがGOサインを出した仕様書をよく確認し、その通りにシステム開発を進めます。
後戻りをしない、上から下に流れ落ちる滝のように進める、それがウォーターフォール開発です。
このようにクライアント様とシステム開発会社間でお互いに確認をしながら進めますので、着実に進められ、クライアント様が求めるシステムをきちんと開発できる可能性がとても高いのです。

颯爽と進むアジャイル開発

アジャイル開発を採用するクライアント様は、システムの利用メリットが見込めるならば、必須機能のみを備えたシステムを1日でも早く使った方が良いと考えます。
来年とか再来年とか、時間をかけて開発され、出来上がりを待っているその時間で、違うなと思うところがあれば修正し、より良くするアイデアがあれば機能追加していこう、と考えます。
時間とともに不確実性が高まる今の時代ならではの考え方です。
だからといってウォーターフォール開発で採るステップを省略するわけではなく、アジャイル開発は1歩1歩を足早に颯爽と進めるのです。

ブックルックチームのアジャイル開発

アジャイル開発を得意とするブックルックチームは、目安として1か月程度で開発できるシステムを提案します。
そのくらいであれば、担当者様も仕様や動作確認を日常業務の空いた時間でできます。
また、担当者様には大きな裁量が与えられていますので、1つ1つの機能についていちいち誰かの承認を得る必要もありません。
システム設計者は担当者様とのやり取りを通して「ゆれ」(将来仕様が変更される可能性)を感じたならば、容易に修正できるように変数を持たせて設計します。そのため、納品後に修正を求められた場合でも「待ってました」とばかりに簡単に対応できます。
最初のフェーズで開発されたシステムは、クライアント様とシステム開発会社にとって、今後話を進める上での共通基盤となります。
次のフェーズでの機能追加や変更はこの共通基盤上で話し合われるため想定ケースが少なく、検討の時間、コミュニケーションの時間が大幅に削減されることになります。

ウォーターフォールを採用すべきではないケース

ウォーターフォール開発に話を戻します。
ウォーターフォール開発は後戻りをしないことが前提ですから、ステップ毎の確認・決定作業は当然慎重になり時間もかけることになります。
設計段階で半年、1年とかけることは珍しくありません。
その内に、ユーザー業務の進め方が変わったり、新しいより良い技術が利用可能になったり、競合する企業が新たな方法で売上を伸ばし始めたり、(日本国内では少ないでしょうが)突然法律が変更されたりした場合、また最初からやり始めることにもなり兼ねません。
言い換えれば、そのような可能性があるならばウォーターフォール開発を採用すべきではありません。

成熟した変化の少ない確立された業務においてなら、ウォーターフォール開発は向いています。
しかし、外部からもたらされる変化の多い昨今では、なかなか難しい開発手法となるでしょう。

防衛省の防衛装備品開発は、これまでウォーターフォール型を採用していたため、実用されるまで10~20年もかかっていたそうです。
その間に周辺国は新たな武器を開発したり、より良い技術が開発されたりして、いざ使い始めようとしたら「もう威力が相対的に低く、国民を守り切れません」となる懸念が想定されたのでしょう。
他国の武力行使の可能性が高まり、ドローンやAIに代表されるような新技術がどんどん出てくるような今は、アジャイル開発が最適だと判断したのでしょう。

IT業界のシステム開発

ウォーターフォール開発は、特に工程後半のシステム開発者にとってストレスが少ないというメリットはあります。特に優秀なIT人材不足が深刻な現在の状況においては悪くない選択に見えます。
他方、クライアント様にとってはウォーターフォール開発で時間を取られているうちに競合企業に追い越される可能性があります。その結果、システム開発会社はお客様を失うかもしれない、という側面を心配するのは大袈裟なことではないと思います。

ビジネスの世界は常に競合企業と対峙しています。
IT業界はクラウド、AI、高速通信、RPA、ブロックチェーン、IoT、量子コンピュータといった新技術が登場しています。
そんな中では、後戻りさえも選択肢に持ちながら、機敏に、迅速に行動できる方が競争優位に立てる確率が高まります。

あなたもアジャイル!

ということで、長々と説明しましたが、そんなアジャイル開発を得意とするブックルックチームでプロジェクトマネージャ(PM)、システムエンジニア(SE)、プログラマー(PG)として活躍したい人材を募集しています。
また、今回新たにデータベース管理者(DBA)の募集も開始しました。
奮ってご応募ください!

今のような変化の多い時代はいつまでも続くものではありません。また必ずどこかで安定がやってきます。
その前に、このエキサイティングな状況を、1度きりの人生で1回くらいは体験してみてはいかがでしょうか!

プロゴルファー 荒井陸プロモーションサイトをローンチ

ブックルックチームが応援しているツアープロゴルファー 荒井陸選手のプロモーションサイトをローンチしました。

荒井陸プロモーションサイト(https://arai-riku.booklook.jp/)

プロモーションサイトでは、荒井陸選手の試合結果を公開していきます。
また、荒井陸選手のインタビューから、お菓子が欲しくてゴルフを始めた話や、その後の悔しい思い出なども掲載しています。

荒井陸選手は、東京都出身、日本大学卒業で現在25歳。プロ3年目です。
まずは予選通過すること、そして予選通過したらシード権を得られる結果を出すこと。それが目標です。

ブックルックチームではツアープロゴルファーである荒井陸選手を応援しております。
荒井陸選手 はブックルックチームのゴルフ部メンバーと毎月一緒にラウンドしたり、食事を共にしたりしています。

荒井陸選手はとても気さくでオープンマインドを持ったプロゴルファーです。ブックルックチームもオープンな社風なので、そこは両者すぐに意気投合しました。

ゴルフに興味のある方もそうじゃない方も、荒井陸選手の応援をお願いします。

今話題のインドアゴルフの内側~ゴルフ場をラウンド

前回までではショットデータを見ながらドライビングレンジでの練習アプローチとパター練習をしました。
今回はラウンジレンジ麻布十番で、ゴルフ シミュレーター ダンロップ SDRを使って、ゴルフ場をラウンドしたいと思います。

リアルに近いレベル5設定

ゴルフ シミュレーター ダンロップ SDRは、ショットデータを計測し、それをシミュレーションに反映させる仕組みなのですが、取得したデータをどのように反映させるか5段階で設定ができます。
レベル1は曲がりが最も少なくなります。例えば、スライスが多めの人はシミュレーション上少なくなります。
レベル5はリアルに近くなります。大きく曲げる人は大きく曲がることになります。
私は当然、レベル5に設定してプレーします。

レベルの設定は、ラウンドを始める前に行います。
モード選択画面で[ラウンド&練習]を選択します。

次のログイン画面で[ゲスト入場]ボタンをクリックします。

ゲスト登録画面でプレーヤーのニックネームを入力します。デフォルトのままで良いでしょう。そのまま[OK]ボタンをクリックします。

[レベル]ボタンが表示されるのでクリックし、「レベル5」を選択します。

これでリアルに近いレベル設定が完了しました。
なお、ティーの高さがデフォルト「55mm」になっています。これをもっと高くしたい、低くしたいという場合は[ティーの高さ」で設定できます。

また、2人以上でラウンドすることもできます。
右に表示された[ゲスト入場]をクリックして、先ほどと同じようにプレーヤーのニックネームを設定して進めます。

ゴルフ場の選択

次にラウンドしたいゴルフ場を選びます。
SDRに搭載されているゴルフコースは、SDRホームページによると、国内42、制作中2、承認申請中が19のゴルフ場だそうです(2022年10月11日現在)。

搭載ゴルフコース一覧

小樽カントリークラブ(北海道)
​桂ゴルフ倶楽部(北海道)
​札幌国際カントリークラブ 島松コース(北海道)
​北海道クラシックゴルフクラブ(北海道)
​ザノースカントリーゴルフクラブ(北海道)
北海道ブルックスカントリークラブ(北海道)
グランディ那須白河ゴルフクラブ(福島県)
利府ゴルフ倶楽部(宮城県)
​夏泊ゴルフリンクス(青森県)
茨城ゴルフ倶楽部 東コース(茨城県)
茨城ゴルフ倶楽部 西コース(茨城県)
グレートアイランド倶楽部(千葉県)
​大箱根カントリークラブ(神奈川県)
習志野ゴルフクラブ クイーンコース(千葉県)
​成田ゴルフクラブ(千葉県)
富士クラシック(山梨県)
キングフィールズゴルフクラブ(千葉県)
総武カントリークラブ 総武コース(千葉県)
習志野ゴルフクラブ キングコース(千葉県)
鳴沢ゴルフ倶楽部(山梨県)
浜野ゴルフ倶楽部(千葉県)
磯子カンツリークラブ(神奈川県)
軽井沢72ゴルフ 北コース(長野県)
川奈ホテルゴルフコース 富士コース(静岡県)
グランディ浜名湖ゴルフクラブ(静岡県)
涼仙ゴルフ倶楽部(三重県)
​東名カントリークラブ 裾野・桃園(静岡県)
​中京ゴルフ倶楽部 石野コース(愛知県)
茨木国際ゴルフ倶楽部(大阪府)
瀬田ゴルフコース 北コース(滋賀県)
ダンロップゴルフコース(兵庫県)
​六甲国際ゴルフ倶楽部(兵庫県)
土佐カントリークラブ(高知県)
熊本空港カントリークラブ(熊本県)
ザ・サザンリンクスゴルフクラブ(沖縄県)
フェニックスカントリークラブ 高千穂・住吉(宮崎県)
宮崎カントリークラブ(宮崎県)
PGMゴルフリゾート沖縄(沖縄県)
​福岡カンツリー倶楽部 和白コース(福岡県)
琉球ゴルフ倶楽部(沖縄県)
UMKカントリークラブ(宮崎県)
阿蘇スカイブルーリゾート(熊本県)

制作中のゴルフコース

飯能グリーンカントリークラブ(埼玉県)
加西インターカントリークラブ(兵庫県)

ゴルフ場を決めたら、グリーンの速さやカップの位置、風力などを設定します。こだわりがなければデフォルトのままで良いでしょう。
ゴルフ シミュレーター初心者に1つだけ設定をお勧めするのは、パッティングの際のOKの距離です。[コンシード]ボタンがあるので、長い距離「5m」に設定します。
ゴルフ シミュレーションは目から得られる情報が限られており、距離感、アップダウンが判定しづらいためです。画面上に数値は出ていますので、数値で判断できる場合は別です。ゴルフの上手い人やプロゴルファーは数値から合わせることは難しくないようです。

ラウンド前の設定が完了したら開始です。

ラウンド開始

1ホール目

Par 4、391ヤード、打ち下ろしです。
打ち下ろしかどうかは画面に映し出された景色でわかりますが、画面左下にアップダウンが表示されていますので、それを参考にします。

ティーショットです。

セカンド。ライがつま先下がり。スタンスプレートのかかと側が上がっています。
残り170ヤードちょっとありますが、下りを考慮すると167ヤードです。
上り下りを考慮した距離は「キャディー推奨距離」として表示されます。

セカンドは残念ながらグリーンに届かず、ガードバンカーに入ってしまいました。
ピンまで約20ヤード。 「キャディー推奨距離」が36ヤードと表示されていますが、私は実際のラウンドでもそうですが、バンカーは通常10ヤード追加して打ちますので、30ヤードのつもりで打ちます。
スイングも実際のラウンドと同じく、フェースを開き、腰を低くして、左足体重で行います。
グリーンの低い方からのショットなので、バンカーから脱出することが第一です。

バンカーショットの結果、ピンを超えて高い位置につけてしまいました。ショットが大きかったかな?
カップまで残り8ヤード、下り、スライス。 「キャディー推奨距離」 は約5ヤード、カップ1個左とのこと。
下りがきついので、私は3ヤードくらいのつもりで打ちました。

ボールは惜しくもカップ左を通り過ぎ、5cmくらいのところで止まりました。
OKをもらい、コンシード。3オン2パットでボギーでした。

2ホール目

Par 5、532ヤード。緩い下り。
ティーショットは200ヤード飛びました。

セカンド。残りは300ヤードあります。
左足下がりなのでスライスが出やすいので、少し左側を狙って3番ウッドを振りました。
ショット後よろけながら160ヤード。思ったよりも飛ばなかったけど、実際もこんなものかな、と思いました。

3打目。残り140ヤード。つま先下がり。
グリーンは手前と左右にガードバンカーがあって、ピンが奥にあります。
ここは思い切ってグリーンを飛び越すくらいの気持ちで打ちます。

ボールはカップまで3メートルの位置に付き、コンシード バーディ!

3ホール目

ショート。170ヤード。ピンはグリーン中央。
グリーン直前に池があって、キャリーで150ヤードくらい飛ばさないと池ポチャ。

そして残念ながら、グリーンまで全然届かず池ポチャ!1ペナルティ。

3打目は池手前から60ヤード。左足下がりのつま先上がり。

これもなぜか残念ながらグリーンまで届かず!なんで?

4打目。残り11ヤード、上り。 3打目と同じようなライ、左足下がりのつま先上がり。 ショートアイアンで。

これがうまくピンに寄り、OKパットを貰って4オン1パットのダブルボギー。

こんな感じで、良いことも悪いこともあったラウンド。実際のゴルフコースでありがちなシチュエーションでした。

実は先日、会社仲間とラウンジレンジ麻布十番でラウンドしました。
お互いにゴルフ場でよくやるミスを連発しながらいい勝負ができました。
スコアも同じ。ゴルフ シミュレーター ダンロップ SDRはそれくらいリアルに近いんだな、と思わせるものでした。

次回は予約システムに焦点をあててみたいと思います。

今話題のインドアゴルフの内側シリーズ