スタッフBLOG

おはようございます。新人PLのM・Oです。

もう３月が終わりを迎え、あっという間の４月ですね！
近頃は暖かくなり、通勤の途中で春を感じさせる花々を目にすることが増えてきました。

今日はゲーム制作の仕事上、必ずある『バグ』についてお話しようかと思います。
プランナーが受け持つバグには様々な種類があります。

まず、『仕様書のバグ』について。
これはゲームのバグではなく、プランナーが作成した仕様書のバグになります。
例えば、仕様書の記載ミスや仕様の矛盾などがあります。
これらは、仕様書を修正するだけで問題はありません。
（もちろん、バグを作ってしまった問題はあります）

仕様書のバグの中でも、仕様漏れが発覚し、仕様の練り直しや
新しく仕様の搭載など、大きな修正に繋がる場合もあります。

プランナーは仕様書を書く上で、仕様漏れがないようにする必要があります。
完璧に書くことは難しいですが、がんばってミスを減らしましょう。

次に、『実装ミス』
仕様書のミスとは違い、自分が作業しそれが間違っている場合に発生します。
自分だけで担当しているものであれば、原因がわかりやすく、修正も行いやすいと
思います。
ですが、冒頭で書いたようにチームでゲーム制作を行っているので、
動かす素材はモデル担当やモーション担当の人がいて、それらを表示させる
プログラマーがいます。

関わっている人が多いほど、誰がミスをしてバグを発生させているか、というのが
見えにくくなります。

そして、多くの人が「自分はミスしていない」という先入観を持っています。
書いている私もそうですが、作業をしている段階では視野が狭く、バグの報告が
きても、すぐに冷静にはなれず自分のミスだとは考えられないものです。

バグが発生した場合はつねに冷静かつ、他に発生していないか確認が必要ですね！
バグを未然に防ぐためにチェックリストを作成し、客観的にチェックすることも、
とても大事なことになります。

数日前の先輩プランナーの記事にもありましたが、
今更ですが、自分が作業担当のところは、責任を持って最後まで注意して
務めることが大事だと実感しています。

おはようございます。

広報係などのタントウジャナァイ普通のプランナー兼
本日のブログ当番のJ.Hです。

ACCESS GAMES公式Twitterアカウント等でも告知されておりました
ニコニコ生放送関連の"ゲーム実況プレイ"配信の方は
ご覧いただけましたでしょうか？

ドグマ風見さんによる『Deadly Premonition　レッドシーズプロファイル　
コンプリートエディション』の"ゲーム実況プレイ"や、
「DIEC京都ゲーム実況フェス」での『D4: Dark Dreams Don't Die』の
"ゲーム実況プレイ"などが配信されておりました。

実況プレイの様子をディレクターのSWERYが直々に解説をしておりましては、
ゲーム内容を別角度からも知ることができる珍しい機会でもありますので、
見逃した方はアーカイブやタイムシフト視聴などで是非ご覧くださいませ！

昨今は「ゲーム実況プレイ配信」や「プロゲーマー」といった
個人が顔出しをしてゲームをプレイすることを生業とする方々も増え、
そういう意味ではゲーム界隈が年々華やかになってきているように感じます。

今のゲームハードは、録画や配信ができるシステム環境が備わっているため
容易に配信できる、ということが後押しとなっています。

観ているだけで楽しい"ゲーム実況プレイ"の配信や動画ではありますが、
実際にプレイをしてみないと分からない、伝わらないことがいっぱい有る
というのもゲームではよく有ることだと思います。

極端に言うと、ボタンを１つ押した時のリアクションだけでも
面白いと感じることがゲームにはまま有りますし、
操作の複雑さが怖さの表現になっていたり
実際の動作をしているように体感できたりもします。
ですが、そういった事は実況プレイを観ているだけでは
伝わりにくいのではないでしょうか。

逆に"ゲーム実況プレイ"配信は自身がプレイ済みのゲームだと
配信者と共感できることが多くなり、より視聴することを楽しめる
というのもまた然りです。

これから流行りそうなVR(バーチャルリアリティ)体験というのも
動画では全く醍醐味を味わえないというのも間違いありません。

新しいゲームソフトやVRなど、機会を作ってでも体験してみてください。
自分や体験者の様子からして興奮することはお墨付きです！

そして、ゲームはプレイする側だけでなく、
開発をするというのもまた体験の連続です。

ゲーム開発は地味な作業で大変な部分が有ることも確かですが、
構想や妄想、進行形で形にしていく過程などもまた体験することができます。

４月も近づき、職場での新しい出会いや
新しいプロジェクトなども体験し始められる時期。
みなさま体験の共有の際は何卒よろしくお願い致します。

おはようございます。本日の当番、新人プランナーのY.W,Srです。
３月も終わりに近づき、暖かい日が続いたかと思えば急に冷え込んだり…。
まさに三寒四温といった様子で、春が近づいてくるのを実感する今日この頃
皆さん如何お過ごしでしょうか。

さて、前回はＴＲＰＧ関連のネタから「ゴブリンのジレンマ」のお話をしましたが、
今回は「常識とルールの違い」について紹介したいと思います。

常識とルールの違いとは何かというと、ゲームにおいて往々にして発生する
システムと常識のズレに関する古典的命題のことです。

例えば、「悪人が人質にナイフを突き付ける」というよくあるシチュエーション。
この「ナイフを突き付ける」という行為が、
ゲーム的にプレイヤーへの脅しとなりうるか？というのが常識とルールの違いなのです。

常識で考えた場合、ナイフを突きつけられると、致命傷になりかねません。
そのため、このような状況下だとプレイヤーは大胆な行動を
控えざるをえません。

しかし、ゲームシステムの観点から見るとどうでしょうか。
一般的なゲームでは、ナイフはゲームに登場する武器の中でも弱い部類に入ります。
人質のパラメータにもよりますが、攻撃一回分のダメージならば
恐らく耐えられる可能性が高いでしょう。
こうなると、プレイヤーは行動を躊躇する必要がなくなり、脅しとして成立しないことになります。

もしキャラクターが簡単に蘇生できるゲームでは、
人質はさらにナンセンスなものとなります。
究極的に言えば、人質が倒されたとしても蘇生すれば良いのですから。
この場合は、人質が簡単に蘇生できない理由が必要となります。

以上が、常識とルールの違いです。
ＴＲＰＧはその進化の歴史のなかで、この問題に対応するべく
様々なルールを生み出してきました。

ビデオゲームでも、このような違いを避けるために様々な工夫が行われてきました。
例えば、「戦闘を行うパート」と「イベントや演出を行うパート」を
明確に分けることで、システムを無視しても違和感が無いように工夫されていたり、
前もってキャラクターのセリフなどでシステムを無視することが示唆するといった
こともよく見られます。

前述の例に当てはめると、
例えば、敵が仲間Aをナイフで脅す一連の流れをデモやイベントで行い、
ナイフを突き立てれば仲間Aは倒されて、いなくなることをセリフで示唆するといった具合でしょうか。

ゲームというのは基本的には、遊びやすさや気持ちよさを優先して作られます。
しかし、そういったことを優先しつつも、ゲーム内での出来事がシステム的にも
常識的にも不自然さのないように見せるという工夫が必要となります。

皆さんもゲームを遊ぶ時に、そういうちょっとした工夫に気をつけてみると
また違った面白さに気づくことがあるかもしれません。

おはようございますプランナーのY.Wです。
だんだんと暖かくなり、春らしくなってきましたね。
春はなにか新しいことを始めてみたいような、そんな季節です。

アクセスゲームズはもちろん、現在もたくさんの“新しいこと”が進行中です。

僕もプランナーとして、新しいゲームの企画書を作らせて頂くことがあります。
企画をたてる上で、僕なりに気をつけようと思っていることは、
その企画が実現することによって、“プレイする人は何を感じるのか”です。

初心の企画者は、まずどんなゲームにするかを一生懸命考えてしまいがちです。
そして細かくマニアックなディティールの仕様へ……。
当然、ゲームの企画書なのだからそれが当たり前と言えますが……。

ですが、ゼロからの企画であればまず完成したゲーム画面ではなく、
画面の前にいるプレイヤーのリアクションを想像することが先に立つべきです。
「敵倒しまくりのオレって強い！」「経営めっちゃ上手くいくし、才能あるかも！」
「怖いけど、続きが気になってやめられない！」「とにかくモテモテで楽しい！」
などを感じさせるために、こんな遊びにしたいんですという流れで作りましょう。

（体験させたい感覚を知っているからこそ作れるもの・語れるものが良くなります
　ので、企画は普段から楽しいと思えるものを積極的に体験していきましょう）

プレイヤーに感じさせたいことがわかれば、それでゲームの軸ができあがります。
ゲームの軸とは、コンセプト、根幹、基調となる考えとも思ってかまいません。

ゲームの企画は最初の企画書だけでは終わりません。
大小様々な場面で、要素や調整の取捨選択を迫られます。
自分なりにでも判断を下せるということは、企画にとっては非常に重要なことです。

そんなとき、ゲームの軸があれば自ずと答えが出ることでしょう。
「このゲームは地上戦の泥臭い感じがいいんだから、ジャンプはいらないよ」とか
「確定申告はリアルでは実際いるけど、お金を回す楽しさには繋がらないから不要」
という判断の基準になり、ゲーム制作をしっかりと進めることが出来るのです。
（こうあるべき！みたいな）
目指したい方向がチームに理解されていれば、助言を受けることもあるかと思います。

というようなことから、プレイヤーが何を感じるのかに気をつけようと考えるのです。

どんなゲームにするかを先に作ったアナタも、
今からでもプレイヤーに感じて欲しいことを設定しましょう。
プレイしている人を思い浮かべて……。
男性か女性か、子どもなのか大人なのか。
そこにどんな会話が生まれるのかなどを想像してみます。
そうすれば、少なくとも一人よがりなゲームからは脱却できるでしょう。

これは企画書についての考えの一つですが、
このブログを見ている方の企画書作りの一助になれば幸いです。

お世話になっております、プランナーのY.Sです。
月日の流れは早いもので、僕がアクセスゲームズに入社して
そろそろ4年が経とうとしています。
「新人」という枠組みから外れてもうしばらくですが、そのせいか
最近よく考えるようになったのが「責任」というものについてです。

もちろん、新人だった頃も責任について考えなかったわけではありません。
自分が担当になった仕事は自分に全ての責任があると考えて
それを全うすることに全身全霊をかけておりました。
しかし、最近はそれだけではダメだと思うようになりました。
「言われた仕事を言われたとおりに遂行すれば責任を果たしたことになる」
そんなふうに考えていた時期が、僕にもあったということです…

ゲームづくりというチームプレイにおいて「個人の責任」というミクロな視点で
物事を考えてしまうと作業が円滑に進まなくなります。

例えばこんなチームがあったとします。

「〇〇の期限が明日までです。」

「〇〇の作業担当者は？」

「□□さんですが、本日は体調不良でお休みです」

「ふーん。まぁ何とかするんだろう」

酷いですね。ここまで極端な例は、まぁ無いとは思いますが
こんなチームでものづくりが上手くいくとは到底思えません。

個人の作業の遅れはやがてチーム全体の遅れへと繋がっていきます。
自分がチームの一員である以上、「〇〇は□□さんの責任」などと
割りきって考えることは決して出来ないのです。

僕もまだまだ、忙しい時期や作業が立て込んでいる時は
自分の責任と他人の責任をパッキリ分けて考えてしまいがちです。
常に自分がチームの一員であるという自覚を持ち
チーム全体の責任を意識するよう心がけていきたいと思います。

おはようございます。
本日の当番、プランナーのM.Yです。

動画配信サイトやハードの動画投稿機能で、
ゲームのプレイ動画を簡単に見ることが出来るようになりました。

特にSteamの台頭が著しい昨今、
Steamゲームのプレイ動画は情報収集のツールとしてとても役立っています。

他にも、日本より先に英語版が発売されるゲームタイトルでは、
海外ユーザーが投稿したプレイ動画で一足先にゲーム内容を知ることが出来て、
とても助かります。

また、自分がプレイしているゲームの動画では、
他人のプレイを見て新たな遊び方を気付かされることもあり、
仕様を考える際、いろいろなプレイスタイルを想定することの重要性を
再確認しました。

ゲームのプレイ動画を共有する流れは今後も拡大していくと思いますので、
それを意識したゲーム作りというのも意識していきたいですね。

3月も残り1週間とちょっと。
そろそろお花見の計画を立てているころでしょうか？
おはようございます。本日の当番、プランナーのS.101です。
休暇や出張が重なって、久々の登場となります。

実は今週末の3/29（日）に京都で行われます「DIEC京都ゲーム実況フェス」 に
ACCESS GAMESよりD4体験ブースの出展とディレクターSWERYによる実況プレイが
行われます！
○○ゲームショー出展！○○講演！というイベントより、開発者とユーザーの
距離が近いイベントになるのではないかなっと思っています。


結構探してみると、今回のようなゲーム関係のイベントが開催されています。
普段からアンテナを張っていると、様々な情報をキャッチできます。
情報サイトやSNSなど、世間には情報が溢れています。
その中で自分の興味のある、又は有意義なタメになる物事…見逃すのは
もったいないです。
大事なことは、キャッチした情報を情報を分析し、どう判断し、
活かすのか？ではないでしょうか。


さぁ、このブログを見た貴方！イベントの情報を仕入れましたね。
この週末は春の陽気にあわせて京都へ行こう！
（当日晴れますよーに！）

おはようございます。だいぶ暖かくなって春はすぐそこって感じですね。
４月頭にはアクセスゲームズ恒例イベントの花見が開催されるので、
つぼみの膨らみ具合がとても気になる本日の当番、プランナーのK.Mです。

アクセスゲームズ社内には結構な映画ファンが集って（つどって）います。
社内でも特にベテラン陣は、ほぼ全員映画マニアと言えるのではないでしょうか？
きっとゲーム作りに直接的にも間接的にも役立っているはず。

自分もその一人です。っていうような事をずっと以前に書いた気がするので
ブログページを漁ってみました。

[ LINK ] http://www.accessgames-blog.com/blog/2008/01/post_1458.html

↑アイアンマンで再ブレイクする前のＪｒさんに着目するなんて、
僕もなかなか通ですね。（マニアは「目利き」を自画自賛するものです）

[ LINK ] http://www.accessgames-blog.com/blog/2012/03/post-c8d8.html

↑プランナー勉強会で映画を取り上げたこともありました。

プランナー内でもよく映画話をよくするのですが、

気がつくとベテランだけで盛り上がっている…なんて事があります。

若手も最新の映画にはアンテナ張っているようですが、

リアルタイム世代じゃない作品は、なかなか手をつけにくいようです。
昔と違ってＴＶ地上波で映画をバンバン放送してませんしね。

映画の話についていけるようになりたい！とよく若手プランナーが言ってるので、
それぞれの人物像をプロファイリングした上で、K.Mコレクションからチョイスし
貸してあげることにしました。


どんな映画かというと…
-----
■ペーパー・ムーン（1973）
　ライアン＆テータム・オニール親子が詐欺師を演じる白黒ロード・ムービー。
　原作小説から改題したタイトルが内容にぴったりはまっていて秀逸。
-----
■王と鳥（1980）
　1952年公開のフランスアニメ「やぶにらみの暴君」の完全版。
　特に構図がアート的。今観ると、のちの日本アニメに影響大だったのが分かる。
-----
■麻雀放浪記（1984）
　真田広之主演で、一癖ある賭雀士達が魅力的な白黒博打映画。
　洋画ばかり観ていた頃、自己破滅型な男達の生き様に痺れ、邦画の良さを知った。
-----
■潮風のいたずら（1987）
　ゴールディ・ホーンとカート・ラッセルのホームドラマ風ラブコメ。
　嫌なセレブ女が思いやりある女性に変わっていくさまが嫌味なく描かれている。
-----
■シラノ・ド・ベルジュラック（1990）
　有名戯曲をジェラール・ドパルデューの「付け鼻」で映画化。
　剣豪にして詩人…豪快にして繊細な主人公キャラが秀逸。マント姿カッコイイ。
-----
■ノーバディーズ・フール（1994）
　老いても丸くならない不良老人をポール・ニューマンが演じるヒューマンドラマ。
　Ｐ・ニューマンと同格で張り合う若い雇い主のＢ・ウィリス。その関係性がいい。
-----
■キューティ・ブロンド（2001）
　リーズ・ウィザースプーンのガールズ・ムービー。バカにされながらも、
　あくまでど派手な自分流を貫く、本当はけなげで努力家の主人公に元気を貰える。
-----
■アフタースクール（2008）
　大泉洋主演のジャンル分け不可能な映画。敢えて言うならミステリー・コメディ？
　複雑に入り組んだシナリオがとてもスリリング。続けて２度観たくなる映画。
-----

これらはどれもマイベスト１０…って程ではないけど、

数年に１回は見直したくなる愛すべき映画達です。

７０年代が１本、８０年代が３本、９０年代１本、００年代２本ですか。
８０年代のうち1本は５０年代とも言えますし…。

若手プランナーにとってリアルタイム世代じゃない映画の紹介…

というコンセプトからすれば良いバランス、なかなか素敵なセレクションじゃないですか！
（自画自賛！！）

自分の知らない価値観や世界に触れて見識を深め、

ゲーム作りに役立ててくれればな…と願います。


映画プロファイラーが自分にマッチする作品を貸してくれるアクセスゲームズ。
あなたも入社してみませんか？

2015年3月12日にPS Storeにて発売されました
「Deadly Premonition レッドシーズプロファイル コンプリートエディション」
の不具合についてのお知らせです。

本製品のイベントシーンにおいて字幕表示に関する不具合が確認されております。
本件は、発売元のトイボックス株式会社にて対応を進めております。

「ご購入者様へ 大切なお知らせ | トイボックス株式会社」
http://www.toybox-games.jp/info150316.html

楽しんで頂いているファンの皆様には大変ご不便をおかけしまして、
誠に申し訳ございません。

早急な対応が進められておりますので、
今後とも「Deadly Premonition レッドシーズプロファイル コンプリートエディション」
を宜しくお願い致します。

2015年3月17日

株式会社アクセスゲームズ

おはようございます、アシスタントマネージャーのY.Sです。

今年初のブログ当番です。

いやそれがわからんからレシピ見てるんよ、と思ってしまうんですが、慣れたらその「適量」がわかるようになるんでしょうね。早くそのレベルに達したいものです。

とてもいい社会見学になりました。


今回の設立記念日は、ものすごく濃い一日を過ごすことができたと思います。

次にブログを書くのが大体3ヶ月後なので、その頃にはもうちょっと料理も上達していたらいいな…！

おはようございます。本日の当番、プロデューサーのやすなみです。

あっという間に春ですね！
目鼻が即レス。ああ悩ましき花粉症の季節。

くしゃみ連発の中、社員ブログは「会議室をいじってみようかと」シリーズ、その4をお送りしたかったのですが、前回から会議室をいじれてません・・・・・・。

その間、やすなみ工務店は何をやっていたかと言うと、所属するチーム「GM開発推進室」のレイアウト変更を行っていました。

今まで開発室の片隅で、巨人の襲来から身を守るため高ーいパーティションで区切られた狭ーい空間に閉じ込められていた（!?）のですが、SWERYの粋な計らいで、広ーく明るいスペースを用意してもらいました。

机や椅子はもちろん、棚やキャビネット、そしておもちゃの数々といった備品や私物を総移動して、床の配線もいじりなおす大がかりなものとなりました。

おかげさまで、レイアウト変更後は担当しているプロジェクトのスタッフを一堂に見渡すことができるベストポジションに陣取っています。

みんなの活躍が手に取るように一望できて、いやーほんと、いいですねー。すばらしいですねー。

そんなホクホクした大きな顔が、バランスボールでボヨンボヨンと跳ねているわけですから、スタッフからすれば見苦しいことこの上ないはず。
目をそらすため開発画面に集中することができて、作業効率が三倍向上していることでしょう！

ふふふ。

世界中のみなさんに楽しんでいただけること間違いなし！な新作を鋭意開発中ですので、引き続きアクセスゲームズをチェックしてみてくださいね。

ではまた次回。

おはようございます。
最近活字依存症の新人プログラマーのS,Tです。

先日、十数冊の文庫小説をネットで注文したのですが、
住所の入力に不備がありほとんど届きませんでした。
なぜ注文内容確認画面でしっかり確認をしておかなかったのか…。
再度注文しなおし、それらの小説は既に読み終えました。
そして先日、アメリカの英雄の映画を観て来たのですが映画だけでは
情報が少なかった為、 さらに原作の翻訳本を買ってきて、今読んでいます。
やはり活字の方が情報が多く、感情移入度が高まります。

活字最高！！

凄く当たり前のことですが、冒頭での失敗を回避するには確認作業はとても
大事です。
これはどのような場面でも言えることです。
少し前ですが、私はバグの対応で首が回らない状況になっていました。
現在は先輩方に手を貸して頂き、落ち着いていますが…。
そもそも、そのような状況に陥らないようにしてゆく必要があります。
原因は主に、当時実装した部分の確認作業の精度が低くバグが多く残っていた為、
そのまま皺寄せとして自分に降りかかった事です。

私は私生活でも確認作業をさぼる傾向にあるので、今後改善してゆく必要があります。
どのように工夫すれば改善できるかはまだ見えていないので、また模索の日々です。

さて今回のブログで今年度の私の担当は最後となります。
来年度も同じくらい更新があると思うのでよろしくお願いします。

あっ映画はとても良かったですよ！
原書を読み終えたらもう1度観に行こうと思います！

突然ではありますが…
本日、「Deadly Premonition　レッドシーズプロファイル　コンプリートエディション」が
PlayStation®Plusの3月配信コンテンツに登場しました
日英版両方のタイトル名を合体！まさにコンプリートの名に相応しい　;-)
まだ未プレイのの方は是非お試しあれ。

配信日：
2015年3月12日（木）～2015年3月31日(火)

タイトル：
Deadly Premonition　レッドシーズプロファイル　コンプリートエディション

ジャンル：
オープンワールド・ミステリーアドベンチャー

対応ハード：
PlayStation®3

プレイ人数：
1人

発売元：
トイボックス株式会社

おはようございます。
週頭にGDC2015の視察から帰ってきた本日のブログ当番、プログラマーのT.Tです。
GDCの話はWebレポートでするので一旦スルーしましょう。
（実をいうとまだそんなにまとまってねーんだ！）

ゲームには説明書と呼ばれるものがあります。
最近は紙ではなくデータになってたりもします。

いつの時代からか、
読まずにゲームを始めても遊べるようになりました。
斜め読みで全部読まずに雰囲気だけ理解してゲーム始める人が増えたからです。

それは全然良いんです。

説明書を読むのがゲームではないからです。
実際に遊んでナンボです。

ただそれをしていいのは「遊ぶユーザーだけ」です。
開発側は絶対にダメです。

企画書や仕様書。
SDK、ミドルウェアのドキュメント。
書かれているコードやコメント。

斜め読みして雰囲気だけ理解しただけでプログラムを書いてはいけません。

ゲーム自体はふわふわして楽しいものでも、
底にあるプログラム部分は常に強固なものでなければならず、
なぁなぁでやっていると一瞬でバグストームです。

自分の作ったモノの構造を他人に説明できるようになる。

までが自分の作業になるようにしていきましょう。

おはようございます。
本日のブログ当番、プログラマーのS,Mです。

早いもので、来年度から入社して3年目になります。
アクセスゲームズでは、入社してから2年間は、
新人として仕事をこなしていきます。
来年度からは、新人という立場ではなくなり、
いままでに、経験したことがない仕事もしていくことになると思います。
まだまだ、一人前とは言えませんが、これまでの経験を活かして、
仕事に取り組んでいきます。

これまでの2年間を思い返すと、自分が失敗したことばかり思い出します。
入社当初は、右も左もわからず、毎日慌てふためいておりました。
2年目になると、仕事にも慣れてきて、
出来る作業が増えてきて、毎日慌てふためいておりました。
そして3年目にさしかかろうととしている、
今日この頃は、やはり毎日慌てふためいております。
慌てふためくという言葉には、
思いがけない物事に出会って、落ち着きを失ってうろたえる
という意味があり、自分のこれまでを思い返してぴったりの言葉だなと思いました。

プログラムを作っていて、思いがけない出来事などは、たびたび起こります。
作成したプログラムで不具合が発生したり、
仕様変更により、プログラムの修正が必要になったり、
思いがけない出来事というのはプログラミングに限らず、
どんな仕事でも起こりうることだと思いますが、
大事なのは、思いがけない出来事に出会った後どうするのかです。
慌てふためくの言葉通りに、ただうろたえているだけでは、なにも解決はしません。
一瞬で気持ちを切り替えて、問題解決に向けて作業を開始する事や、
その問題を解決した経験を活かして、
その後の作業で問題がでないように工夫する事を考えたり、
出来ることは、たくさんあります。
これまで、自分が失敗したことを多く経験してきましたが、
失敗して慌てふためくだけで終わる事無く、
次の成功につなげていくことで、一人前に近づくことができると思います。

おはようございます。
現在、絶賛悩み中です。
本日の当番、プログラマーのT.Mです。

何を悩んでいるかというと、
このブログは当番制になっていて、
今回は私が当番なんですがネタが無いんですよ・・・。

いつもは身の周りで起きた出来事をネタにするのですが、
今回は見つけられませんでした。

こういった物はいたる所で落ちているはずですし、
もっと拾い上げれる様にしたいです。

プログラミングでも同様です。
一見分かり辛いバグでも現象発生時の状況やログを
読むことで解決の糸口が見つかる事が多々あります。

ログなら自分で出力させることもできますしね。

日常でも業務でも様々な情報を拾えるようにしていきたいと思います。

・・・・"ネタが無い事"をネタにするのって最終手段ですよね。

おはようございます。
本日の当番、プログラマーのT.Fです。


最近は日曜日ぐらいしかガッツリ腰を据えてゲームをする時間が無いので、
ゲームをしながらココはこうした方が、
効率よくプレイできるなとか考えながらゲームしてしまいます。

特に何十回も倒したボスとなると攻撃パターンとギミックをかなり把握しているので、
次の攻撃を予測して回避を行いやすい位置に事前に移動するなど、
操作に余裕ができて楽に倒せるようになりました。


まあ、慣れすぎたせいで攻撃をくらって、場外にはじき出されたりしますが・・・


慣れることによって失敗することも有りますが、
普通は慣れることによって無駄が省かれていくので、
プログラムを組み立てる時間を短く済ましたり、バグが生まれにくいコードを書いていくようになります。

慣れ以外にも仕事をしやすい環境を整えたりします。
例えば、モニターの高さを作業しやすい高さにするための台を用意したりします。
工夫して作業のし易い環境を用意すれば、落ち着いて仕事ができます。

おはようございます。本日の当番、プログラマーのT.Hです。

ついさっきの話ですが、コンビニに入ってお菓子コーナーに向かい、
目当てのお菓子を手にとってレジに向かいました。
値札を見て値段はわかっていたので、お釣りが無いように122円を出そうとすると、
「131円になります」
ん…？と1秒ほど考え、消費税ということに気付きましたが、
記憶では値札に大きく書かれていたのは122円だったような気がします。

わかりにくい！！！！！！

とまあこんな経験は皆さんも多かれ少なかれあると思います。
というわけで、今回は若手がよくやってるのを目にする、いくつかの
「わかりにくい」ものをどうすればいいのかをいくつか上げたいと思います。

・口頭での報告がわかりにくい
これは一番よくあるのですが、何かを報告する時に、
要点だけをうまく伝えることができず、遠回りしながら喋ってしまい、
聞き終わっても「結局何が言いたいのかがわかりにくい…」となることがあります。
これは報告前に一度自分の中で報告内容を文章化し、自分に情報がない状態で
報告内容を聞いて理解できるかを考えると、他の人にもわかりやすくなります。

・文章がわかりにくい
バグの内容、修正方法等を書くときに、どうしても内容が複雑で、
文章が長くなってしまうことがあります。
そんな時にあるのが、句点がほとんどなく、読点だけで区切られている文章です。
一文が長くなってしまうと、文章を余計に長く感じてしまい、
何が言いたいのかがわかりにくくなってしまいます。
～ですが、とかが連続で続いたりするともう訳がわかりません。
適度に文章を区切ることで読む側も考えながら読むことができるので、
伝えたいこともわかりやすくなります。

・プログラムがわかりにくい
バグチェックの時期になったりすると、自分が作った箇所に他の人の修正が
入ることがあります。自分で書いた箇所は自分だけ分かっていればいいと思って、
変数を使い回したり、コメントを書かずにいると、他の人がわかりにくいし、
他の人にその箇所を任せにくくなり、結局自分の首をしめることになります。
これはもう普段からコメントを書く癖をつけて、読みやすいプログラムを
書くことを意識することで、徐々に改善していくしかないです。

こんな文章を書いてて、あれ、俺ってもう若手じゃない…？
とか思った業界8年目突入直前の3月上旬でした。

おはようございます。
プログラマーのG.Iです。

3月に突入してもまだまだ、寒いですね。
早く温かくなってほしいです。起きるのがつらい。

最近、仕事が忙しくなってまいりました。
周りの新人スタッフを見ても、焦りが見えてたりして大丈夫かなーとか思うことも
多々あります。まあ、誰でもそういう時期はありますよね。

今日のネタはそんなことからふっと思いだしたことです。

いくつか問題を抱えている場合に、
それらを乗り越える上で一番重要なアドバイスです。


ズバリ言いますが、それはそれぞれの問題を、
ひとつづつみなおして、さらに小さい問題に分ける、、ということです。

これで、今日の話は終わってもいいのですが、
さすがに短くてさみしいのと、意味わからない人がいると思うのでもう少し
詳しく説明しますね。


まず、基本的にどんな問題も、小さな問題の集合体です。
例えば、大きな一つの問題は、4つの中くらいの問題に分けることができ
その中くらいの問題はさらに10個の小さい問題に分けることができるということです。
当たり前ですよね。

ですが、僕がみる限りは悩んでいる人の大半はこの切り分けができてません。
自分が悩んでいる大きな問題がある場合は、まずはしっかりと、
問題を切り分けて、自分が解決しなくてはいけない小さな問題が、あといくつあるのかを把握することが大事です。

そうすることで、何がわかるようになるかというと
自分がこの問題に対してどこまで進んでいるのかが把握できるようになります。

大きな問題としてみると、解決できていませんが、上記のように切り分けて考えると
実はすでに半分くらい解決していたりする場合もあります。
そうすることで、ゴールまでの道のりというか距離感みたいなものがわかるので
気持ち的にも安心できるし、自分が集中すべき問題箇所もはっきりとします。
また、自分なりに考えて時間がかかりそうな小さな問題を飛ばして
別の小さい問題を先に解決できる場合や、そこだけ先輩や上司、同僚に
相談して一緒に解決していく方法もありますよね。

つまり、問題を切り分けるということは、自分が抱えている問題を明確にし、
解決に対して自分が取り得る選択肢を大幅に増やすということです。

この考え方は、自分の問題解決だけではなく、スケジューリングの考えとも
非常に似てます。
色々なところで使えると思いますので、皆さんも実践してみてください。


終わり

おはようございます。本日の当番、プログラマーのM.Oです。

物事について計画だてて進める事になりますが、不透明な事、難度の高い事に対して、
思考停止の状況に陥り、まったく進展しなくなる事があります。

何をするべきか、その場合に発生する問題は何か？
上記の事を頭の中で想定し続ける事は難しいため、ある程度考慮した段階で
とりあえずやってみる事を提案します。

このやってみるというのも、闇雲にやるわけではなく、事前に考慮した内容に沿って
進める事になります。その中で不透明だった部分が判明し、想定外の問題が起こり、
新たな情報を収集できるでしょう。

やってみた結果を受けて計画を修正することで健全化します。
より確度があがった状態でもまだ問題はあるでしょうが、
繰り返す事で解決していきます。

また、他の人に意見を求めるのも有効です。その人が過去に似た問題を
解決した経験があるかもしれませんし、説明中に不透明だった部分が自分の中で
整理される事もあります。

という訳で皆さん、考え込むのではなく、どんどんやってみましょう。

寒風吹き荒ぶ山々のリア充どもが奔放な性欲をまき散らす今日この頃、皆様いかがお過ごしでしょうか？
日々「爆ぜろリア充！」とか言いまくっているくせに、いざ花粉嚢が爆ぜまくりやがった途端に、リアル涙目のプログラマ、M.L.Kです（LはLinnerのLです。Linner&Binary!)。
う～ん、毎年この時期にブログ当番が回ってきて、同じことを言っている気がするわ～。
てか…マンネリ？ワンパターン？

さて、プログラミングを生業にしていますと、何か沢山あるモノの中に、ある特定の条件のモノがあるかどうかを調べるような処理を書くことが、ままに起こります。

世の中にはリスト探索アルゴリズムと呼ばれるものが昔から幾つか存在しており、調べるモノの量やら調べる速さ、はたまた必要なメモリの量などを見て、どんなアルゴリズムを利用するかを決めるのが一般的です。

ただ、最近、自分でプログラミングをしていて思うのですが、線形探索と呼ばれる方法を用いることが多くなっているように思います（あくまでも、自分がプログラミングする時の話です）。

線形探索というのは、簡単に言うと、沢山あるものを頭から順番に見ていく、という、極めて素朴な方法です（一直線に並べたものを一直線に調べ進めていくのに似た様を指して、“線形”探索と呼ばれます）。

昔は、もっと素敵でややこしいアルゴリズムなんかを実装して悦に入ったりしていたのですが、最近はめっきり線形探索一択です。

なんでかな～、と思って考えたのですが、最近のマシンが余りに処理速度が高くなったお陰で、ゲームなんかで扱う程度のモノの量では、素敵アルゴリズムのややこしさに掛かる時間と、頭からガーっと調べて下手すると最後まで行っちゃう時間とを比べると、その実、あんまり変わらなかったりするからかな～、と思います。

あと、以前と比べてメモリ容量が潤沢になったこともあり、調べる条件に当てはまり得る個数分だけの入れ物を用意して、そこに放り込んでいき、必要になったらその入れ物を覗きに行く、という方法をとっていることも多いです。

例えば、昔は1万個の箱を用意するのは、かなり躊躇われたりしたのですが、昨今ですと、「1万個？ポインタサイズでも64Kバイトやん。安！」てなカンジ。
とんだインフレーションです。

てか、もはや探索しているとも言い難いですし。

だからと言って、昔から追究されてきた探索アルゴリズムを知らなくても大丈夫などと言っていると、足元をすくわれるのが恐ろしいところなのですが…。
（もっと複雑な探索、例えばＡＩの経路探索のようなものに対処するアルゴリズムの利用は、リスト探索アルゴリズムを理解していることを前提としているので）

最近のプログラミングの傾向として、技術を提供する側と利用する側のギャップが物凄いな～と、最近巷で話題になっているr＞gを眺めながら、何となく思ったりしたのでした。

おはようございます。本日の当番、プログラマのY.Hです。

先日、自宅のネット環境をＡＤＳＬから光回線にしました。

過去にも何度か光回線へ移行しようと試みたのですが、
工事やら設定やらが必要との事だったので、
二の足を踏んでいたのです。

少し前に、リフレッシュ休暇を頂く機会があり、
良い機会だったので、光回線に移行することにしました。

工事自体は、回線を屋内に引きいれる作業が思い通りに行かず、
スムーズには進まなかったのですが、
回線の敷設ルートをやりくりして、なんとか完了しました。

早速、容量が大きめのゲームをダウンロードしてみた所…
おっ、やっぱり早いですね！
容量の大きいゲームも気兼ねなくダウンロードできます！

最近はダウンロード販売も多くなってきているので、
工事の手続きやら、立ち会いやらが少々面倒でしたが、
良い選択だったと思います。

このように、後々の事を考えて必要そうな事は、
面倒なことでも早めに片づけておくのが良いですね。

上記に当てはまるものとして、
プログラム的に真っ先に思いつくのはデバッグ機能でしょうか。

作成が多少面倒でも、開発前半に充実させておけば、
中版～終盤の開発効率がアップしますよね。

デバッグ機能以外でも、
頻繁に使いそうな処理を
ライブラリとして用意しておくのも良いでしょう。

まぁプログラムに限ったことではないですが、
いろいろ準備しておくのは大切ですね。

さて、自宅の光回線の話に戻りますが…
ダウンロードしやすくなったのは良いことなのですが、
逆にお金を使いすぎないように気を付けないと（笑