急にゲーム
筆者、携帯のソーシャルゲームが結構好きです。
現時点でまだサービスが続いていて有名なものだと白猫プロジェクトとか、スーパーガンダムロワイヤルとか、モンスターストライクなどは数年レベルでやっていました。
（今はやっていませんが）
サービス開始ごろから4年近くやっていて、今でもまだ続いているのがサモンズボードです。
これ面白いんです。
簡単に表現すると、将棋にパッシブスキル・アクティブスキルや攻撃力などが付与される感じです。
（分かりづらい）
コンテンツが少々少なくて、慣れた人で運が良ければ半年も掛けずにほとんどのコンテンツを埋められてしまうんですが…。
なんかこう、固定手順じゃない条件で、すごく難しいステージをクリアしたときって興奮しますよね。
正直既にやることはないんですが、未だに続いています。
プロデューサーが叩かれているようですが、ゲームの素材はかなり良いので頑張って欲しいところです。
あとは、結構新しいものだとグラフィティスマッシュ。
システムはそれだけ見れば正直「モンストじゃん」って感じますが…。
単純にサービスが始まって間もないので丁寧にサービスが進められている感じがします。
モンストを新規で今始めるならこっちじゃないかなと。
ちょっと急にオススメしたくなってきたので書いてみました。
会社行ってきます。
運用・保守フェーズと開発フェーズはどちらの方が楽しいか
筆者は開発フェーズと運用保守フェーズ、両方の経験があります。
印象としては
■開発フェーズ■
・納期に追われやすい
・仕様書などの資料をまともに作らないといけない
・開発力はもちろん、ポジションによってはかなり広範囲の知識が必要
・工数感が掴みやすい
■運用保守フェーズ
・納期に追われにくい（調整しやすい）
・資料が雑になりやすい
・そのシステムだけに向けた知識があれば対応可能
・調査業務が多い（工数感が掴みにくい）
という感じだと思います。
楽だったのは運用フェーズです。
書いてある通りで例えば運用対象システムを利用しているお客さんに「こういう機能を追加してくれ～」と言われたときに「４月にリリースする予定で動きます」と回答していても「すみません間に合わないので５月で・・・」が意外と簡単に効いた印象です。
（もちろんそれなりの理由は要りますが）
月次や年次で何かシステム的にデータなどを入れ替えないといけない、確実にやらないといけないタスクもあると思いますが開発に比べたら無いようなものです。
また、運用保守チームにいたメンバーははっきり言ってかなり能力が低かったと思います。
保守しているシステム数が少ない人間なんて「そのシステム一生見ていくの？」って思っていました。
本当に世の中、システム的な箇所は全く触らないでデータのみを管理しているのに自称SEだったり、そのシステムの改造のみ大得意だっていうプログラマもいますしね。
開発フェーズを経験してからは「あの保守業務はなんだったんだ」と強く感じました。
必要な知識量が違いすぎる。それに開発案件ごとにコロコロとプログラム言語も環境もメンバーも変わるんですもん。
そりゃあ後者の方が叩き上げでスキルは向上しますよ。現場の人って叩き上げの人の方が好きな人多いですし、開発は経験した方が良いです。
その分ストレス量とか、見えない部分でダメージは受けやすいですが…。
長持ちなシステムだと運用保守の方が経験長い人がいるから、明らかに自分よりスキルが低いのにシステムに詳しいってだけで給料めちゃくちゃ高い人とかもいますしね。
脳内仕様書的な。筆者は「それが評価されるのはくだらね～」と思ってますが。
で、楽だとか経験値になるとかは置いといて楽しさですが…
これだけ叩いといて楽しさは運用保守の方が上だったと思います。
メンタルほとんど削られないですし何より現状維持の中での小さい変化ってのは人間、何でもやってる感を持っちゃうんですよね。
皆さんは開発フェーズの方が楽しかったりしますか？
最近感想が多いですが、以上っ。
大変に感じること
筆者はプログラマー上がりで、大学でもプログラミングばかりしていたので
社会人になってからプログラミングを苦痛に感じることはないですし、正直言って誰でも出来ることだと思っています。
だって何らかの設計書や方針があって、それに向けて作るだけですし。
それに合わせて見やすいソースコードとか無駄がない処理とか意識しない人は、頭もあまり使わないんじゃないかと。
やりたいこと調べればどう書けばいいか大体出ますし、そんなレベルの内容の組み合わせだけでも売れるシステムは作れますもんね。
動いて「やったー」なら学生でも出来るって話です。
筆者的には、コーディングよりも顧客との調整周りの方が大変に感じます。
コミュニケーションが得意だとしても、うまくいくとは限らない。
いくら頑張っても、顧客がこちらの会社やあるいは自分自身を気に入るとは限らない。
営業だってそうですよね。はっきり言って中規模以下の会社だったらプログラマより営業の方が大変だと思います。
何故こう愚痴染みているかといと、プログラミングばかりやっている年上の社員がいるんです。
別にすごい腕があるわけでもなく、ソースコードがめちゃくちゃ綺麗とか、すごく効率的な処理を書くとか、1ステップ当たりの作成時間が最高に早いとか、そういうわけでもない。
なのに異常に大変ぶって、社内のメンバーの立場の低い人と偉そうに工程調整などをして盛り上がる。そして肝心の顧客との調整は年下にやらせるわけです。
そういう人はコーディングの才能ないので、早く上の工程に行けよと内心思っています。
何が大変かと聞かれると、普段大体自分がやっている工程を答えるのがIT業界だと思います。
筆者も最近やっと上流工程をやり始めましたが本当にプログラミングだけやってる間は、時間が掛ろうが楽だったなあと。
これで更に上の工程の社内メンバーのマネジメントをもし経験したら、今度はそれが一番大変って言いだすのかなぁ…
意識が高いだのなんだの
日本…と言わず世界的になんでしょうか。
何故か意識が高い人ってバカにされるというか。
「なんだあいつ」感がすごく出ますよね。
ただ、世界や国を変えてきたのは意識が高い人間だというのを忘れてはならない（ｷﾘｯ
１企業の中でも意識が高い人は何人かいると思います。
筆者は意識高い側に属してしまうと思いますが、何か提案しても誰も乗ってこない感じとか、全員に問いかけてるのに反応がないとか、正直すごく寂しいです。
うちの場合は自分以外の意識高い人ももちろんスルーされてるので、メンバーの意識がそもそも低いんですけど。
意識は低いのに、自分が得意な業務でだけ偉そうな人や
単純に所属年数が長いから偉そうな人など
偉そうなだけであって、お前らは今まで「何か」を変えてきたのかって感じです。
ちょっと何が言いたいのか分からない内容になりましたが、
意識高い人をバカにして笑うのはせいぜい学生までにしましょうや。
自社サービスへ向けた動向
筆者はかなり小さい規模の企業に在籍しています。
仕事は大きい企業から業務委託を受けるか、作成したシステムやサイトを見て依頼していただくケースが大体です。
それと技術者派遣がないのがIT企業としては良いところですが、あわせて逆に言うと安定して売り上げが出る顧客が居ないのです。
社内的には、意識の高いメンバーは自社サービスを立ち上げないと安定しようがないと頑張っています。
ただ、どちらかというと今の顧客で十分という「今だけ」の安定思考が強いメンバーもいるのも確か。
これまでと同じく派遣業はせず、リスクの高い継続業務を実施しない方針を揺らがないようにするとなると、筆者としても自社サービスは必要だと思います。
いま社内で動向があるのは、とあるツールの販売です。
ツールとしては確かに上々なものですが、如何せん売り込み方が分からないのです。そして競合ツールも多数出ている世の中。
筆者は売れないと感じていますが立場的にも低いので特に何も言っていません。
これ、自社サービスを検討するだけで現状は基本赤字なわけですから良いところで切り上げないと余計に安定感なくなるんですよね。
ツールを売り込むんじゃなく、ツールを使ってやれる業務を定期的に行うとか、ちょっと違う路線をいかないと難しいんじゃないかな・・。
自社サービスの始め方、なんて調べる人はいくらでもいると思います。
始めることはいくらでも出来ると思いますが、結局売れるかどうかが大事なわけで、始める事だけに焦点を置いてほしくないなぁと感じるこの頃でした。
初PLを経験して②
さて、前回記事の続きです。
設計工程で遅延。
既に私はこの時点で狂うかのように焦っていました。
③ 製作
実際に制作するプログラミングの工程です。
今までは私はここを担当していましたが今回は担当が別にいたのもあり、ノータッチ。
関連業務に慣れている方に担当して貰ったのもありほとんど難なく進行。
ただし実作業者は仕様に変更があった場合に自ら確認してくれることはなかったため、どんなに細かい修正でも伝える必要があると思ったところです。
ここで不足していたのはコミュニケーションです。大小問わず何かあれば細かく伝えようと思いました。
④ テスト
前工程③の成果物に対してのテストです。
ここはプロジェクト人数が少ないのもあり私が担当しました。
UT、CTのチェックリストを私が作成したのですが、ここでまた問題が。
実際にテストを開始してみると、思ったより工数が掛かった
チェックリストの件数や規模だけで見てはいけないです。
実際にやりだすと事前準備で確認するのと同じぐらい時間が必要だったり、バグがありテスト全件やり直しになったりで全く進みませんでした。
ここは自分で出来る範囲の見積もりの失敗です。これのせいで終盤かなりギリギリになりました。
そして、お客さんと約束した納期には無事リリース。
結果的には納まったものの全体を通してギリギリ感が否めません。
今回は
・社内外問わずコミュニケーションは密に
・自分が出来る範囲をキッチリ定める
・文章力を上げる
この辺りを徹底しないと本当に話にならないと感じたところです。
元々失敗すると落ち込みやすいタイプなのでかなり苦労しました。
SEとしては初心者臭い内容かもしれませんが
読んで頂いた方、ありがとうございます。
初PLを経験して①
プロジェクトが立ち上がるとき、そこには
・実作業をする「作業者」
・細かいレベルの実業務をまとめる「リーダー」
・工期・工程や要員、進捗などの業務の全体を管理する「マネージャー」
が居ます。
（簡単に言っていますが）
もちろん規模によっては、リーダーが実作業も担当するなど、重複することもあると思います。
今まではIT系の企業でプログラミングメインで「作業者」でいた筆者が、今回は約３か月半のプロジェクトで初のリーダーを経験しました。
そこで起きた問題や失敗と、感想を綴ろうと思います。
① 初回打合せ
プロジェクト開始の初回の打ち合わせです。基本的な方針など、マネージャがやる仕事が多いのではないでしょうか。今回は私は先に以下の内容を決めておき、報告するだけになれば楽だと思いつつ参加しました。
・プロジェクトメンバー（体制）
・進捗の管理と報告頻度、打ち合わせの頻度
・課題管理方法
・納品物の取り決め
・納品物（主にソース、仕様書など）の管理方法
・納期の確認
結果的にほぼ先に決めていた通りになりました。ここは準備しておけばあまり失敗しないところだと思いました。
② 要件定義の確認と設計
お客さんからの要件を確認し、実際に設計書（仕様書）として落とし込むところです。
今回はあまり時間がないのもあり、基本設計・詳細設計が合わさって実施される形になりました。
今回は１つ目としてここに大きい穴がありました。
要件についてはお客さんが既に固めており、私としては物を頂いて設計し、仕様書として作成するところですが・・・
ここでまさかの、要件がすべて出切っておらず設計完了ごろに追加で要件が。
更に筆者がここまでプログラマでやってきたのもあってか文章力が低いとのお怒りが。
前者は私のせいではないが・・・
うーむ、後者は確かに。それは仰る通り。
自分でも文章力の低さは認識していますが、かと言ってお客さんには「練習中です」なんて言うわけもなく修正の嵐。
設計は10日程度を予定していたものの、結果的に完了してみればほぼ倍かかっていました。
ここで既に私の考えていた工程からズレ始め、焦り始めます。
１記事が長くなってしまうので、今回はここまで。
次の記事に続きます。
