信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • 旅行

    渋谷最高峰

    こんにちは。さえです。夏休み以来山に行けていないので、高所欲を満たしに渋谷の最高峰、渋谷スカイに登ってきました。周囲に高い建物がないせいか高度以上に高度感あります。山で言うと荒船山の艫岩くらいでしょうか。渋谷の谷底から見上げる夜景。代々公ってこんな大きかったの…もちろん弊社(の入っているビル)も見えます(真ん中あたり)仕事帰りにいつでも夜景眺めに来れますね!コアテックでは仕事帰りに渋谷で遊びたいエンジニアの皆さんも絶賛募集中です!https://core-tech.jp/jobs/posts/
  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =後(プログラム改修編)=

    こんにちわ。パグと申します。前編はこちら→https://core-tech.jp/blog/article469/今回は新人プログラマーが「WEBサイトの改修」を命じられた場合の、具体的な作業工程を書きます。もしもあなたが1〜2年目の新人、新卒で、作業をまとめて大量にふられたときに、何からしたら良いのか、わからなくなってしまったら、「情報を整理すること」から始めてください。1.調査をするメモ書きなのか、きちんとした仕様書で来るのかは不明ですが、仕様の確認フェーズでは、・修正をする範囲を洗い出す作業・QAを洗い出す作業の2点を行います。例えば、このページにバナーを追加してください、といった作業の場合・・・・PC/SPなど両UAに入れるのか?・類似画面がないかを確認します。画面名指定のない場合は同じような画面がないか、などQAとしてリーダーやお客様に確認します。例えば、このページのこの情報を削除してください、といった作業の場合・・・・その情報はTBLから出力されているのか、ベタで書いてあるのか・TBLから情報を出している場合は、使用しているカラムや文言で、プロジェクトファイル全体をGrepし、影響範囲をメモなどにまとめておきましょう。そして、その内容に誤りがないか、QAとしてリーダーやお客様に確認します。紐づく情報でGrepしたり・・・、類似Contollerを探したり・・・それらをまとめてQAで出し、自分が実際作業に入る前に聞きたいことをまとめておきます。ここまでが調査のフェーズです。2.詳細設計をする通常、詳細設計の前に基本設計や方式設計などをすると思いますが、今回はPG向けに記載しているため、事前にそれらが完了していることを前提に書いています。設計工数を取ってくれるチームの場合は、設計書のテンプレートがあると思いますので、それに従って行いましょう。設計工数をくれないような小さな作業の場合は、修正対応するContollerやClassに、コメントで作業をかいていきます。//XXXModelを呼び出す//Dataを加工する//Viewに渡すなどのコメントを記載したら、もっと細分化します。//XXXModelを呼び出す//Model内のメソッドの In(変数はXXID)//Outはどんな形か //Notfoundの場合はどうするか//Dataを加工する//1の場合はXXという文字列にする//2の場合はXXという文字列にする・・・//Viewに渡す//渡す変数が未使用か調べる//どのような形で渡すか・・文字列なのか、配列なのか、オブジェクトなのか・・・まとめて考えて混乱する場合は、とにかく細分化していきます。特に良く見るのが、AJAXの機能を書こうとして混乱している人です。AJAXの場合、JS、PHP(などのサーバーサイド言語)、HTMLと分かれているので混乱するかと思いますが・・・こんな風に分割します。HTML・どんなタグがトリガーになるか、Classなのか、Idで呼ぶのか、どんなイベントか・どこに値を戻すのか、Divなのか、Spanなのか、それとも何かの子NodeなのかJS・イベントをかく、ボタンクリックなのか、値変更なのか・イベント詳細を書く、Inは何かOutはどうしたいか、GetなのかPostなのか、どのURLに渡すのか・想定する文字列が戻ってきたら、どこのタグに出力するのかPHP(サーバーサイド言語)・PostまたはGetでなにを受け取るのか、それとも受け取らないのか・受け取った値をどうするのか(例えばModelなどを呼び出し値を取得するとか)・Outするときに加工するか(RestContollerなどの場合はResponse戻しやEchoしないと出ない場合などに気をつける)上記を順番に書いていき、自分が理解のできる「最小の処理」まで分解します。基本的に「代入とIF文と繰り返し」が書ければほとんどの処理がかけます。どんなに大きな案件も、代入とIFと繰り返しで成っています。(これはあくまで自論です。)なので、新しく触った言語で一番最初に覚えることは、代入方法、分岐の書き方、ループの書き方です。3.細分化された単位にPGをあてていく細分化すると、何度も書いているような処理は、関数にしたほうがいいな、とか細かいところが見えてきます。あとは、書いたコメントと同じ処理をPGで1行1行書いていくと、作業が完了します。このときに絶対に焦ってはいけません。焦って色々な方向に気を散らすと完成しないので、自分が最小化させた単位でかける部分だけをどんどん書いていきます。うまく書けない部分は飛ばしても良いのです。4.細分化した単位でテスト仕様書を作成する単体テストっていうのは、PG単位でのテストです。手動でやってませ〜んとか言わない。そいうことじゃない!!プラスで、修正していない範囲のテストができていれば完璧です。テスト仕様書を書きながら、うまくできなかった部分や、考慮が足りない部分を修正して、CD完了です。最後に詳細設計の工数をくれない案件も少なくはないですが、いきなりプログラムを書き始めるよりも、コメントでも良いので、詳細設計をしたほうが、結果的に戻りが少なく、矛盾が少なく、工数的には短く済むので、案件をもらうととりあえずパニックになる人は、調査と詳細設計をぜひやってみていただきたいと思います。次回は新規作成編を書きます。ではまた・・・。
  • テクログ

    PC交換

    来年windows7の更新期限が終わるのでPC入れ替えに大忙しです。ギリギリ使えるwindows7はアップデート作業を行っている最中でその他のPCは入れ替えの為の打ち合わせが始まった。会社単位だと20~等台数が多いのでインストール作業やバックアップ作業で大忙しです。しかし費用面がかさむので急いで必要がないPCを後回しにするなど問題は山積みです。しかし、銀行系を扱うPCはそうはいきません。銀行のHPにwindows7だとダメとか色々あるので規格にあったものでないと業務に支障が出る為細々修正をするよりも買い換えた方が無難です。windows10マンスリーアップデートもあり、すでにwindows10をいれているPCもアップデートの必要がありますのでそちらも平行作業ですすめています。しかし、数台がインストールに失敗し調べた結果1つに絞って入れないとうまくいかない事もあり時間をとられました。アップデートはお早めに。
  • テクログ

    AWSが新しいディスカウントプランを発表しました

    こんにちは、おっしーです。皆さん、AWSって使ってますか?だいたいEC2、RDSあたりがよく使われると思うのですが、正直、AWSの料金体系って難しいですよね。予めスペックに対して決まった金額を払うものもあれば、使用した分だけ払う従量課金制のものもあります。小さな規模のサービスを作るなら別ですが、それでもお金がかかるものなのできちんと自分の使用目的と照らし合わせて料金を確認したいところです。そんな中でAWSが新たにディスカウントプランを発表しました!もともとリザーブドインスタンスという料金体系があります。(RI)リザーブドインスタンスというのは、予め一定の額を払っておくと、決まった期間安く使えるよというものです。電車やバスの定期券のようなものですね。そちらに似たものですが、今回2つのプランが追加されました。○Compute Savings Plansリージョンやインスタンスファミリー、サイズなどに関わらず、EC2とFargateが最大66%引きになるプラン○EC2 Savings Plansリージョンやインスタンスファミリーは制限されるが、EC2が最大72%割引になるプラン料金計算をするのは難しく、スマホの各キャリアが打ち出すプランのように複雑ですがこういったものがあると知っておくだけでも幅が広がってより適したプランを選ぶことが出来ますね。無駄なお金は使わない方がいいです。ということで、皆さんも良いAWSライフを!
  • 旅行

    箱根日帰り温泉

    こんにちは。寒くなりましたね。今年は暑さが長引きましたが、ここ1ヶ月ほどで肌寒くなってきましたね。で 寒いということで日帰り温泉に行ってきました。思いつきだったので場所は何かとちょうどいい「箱根」です。昼くらいに小田急ロマンスカーに乗車。はいロマンスカードーン。で1時間30分くらいで箱根に到着。駅を出るとなんかザワついていて人だかりのほうに向かうとはい某大物芸能人ドーンなんとか行列みたいな感じのお祭りが催されていました。で箱根のお土産店を適当に散策しながらカフェとか寄りつつ観光気分を味わいながら、いい感じの風景を撮影して適当に時間を潰して温泉に。。。箱根駅前からバスで10分くらいで到着。はいエントランスドーンいい感じの門構えです。構内が結構広く中庭とかあったりして、ご飯も食べれます。もちろんサウナ完備で至れり尽くせりの温泉でした。帰りのロマンスカードーン十分満喫して都内に帰りました箱根日帰り温泉オススメです。
  • テクログ

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=

    新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=こんにちわ。パグと申します。最初に、簡単に自己紹介をすると、私は新人PGではありません。SIerに出向して5年ほどはスタンドアロン型のシステム開発をしていました。WEB未経験から、WEBサイト制作をメインとしているコアテックに転職して、7年経過するSEです。そんな私は、最近新人PGの進捗管理をする機会が多いのですが、手が止まってしまう新人が多いのを目撃して、また、自分も同じように新人の頃、手が止まることが多かったので、あの時、こうしてれば・・・と思ったことを前半後半に分けて書いてみました。仕事って一言で言っても様々で、ツールの講習会開いて欲しいとか、システム(サイト)作って欲しいとかSQL書いて欲しいとか、社内環境整備して欲しいとか様々なのですが、今回は、WEBサイト制作に関して、自分の中でルーティン化しているものをまとめます。(事前準備)案件アサイン前に、その企業(チーム)の環境などを展開されると思います。私の場合はどの現場(チーム)に行く場合も大体その現場の言語やツール関連の本を2〜3冊、知らないフレームワークの場合はマニュアルをざっくりと読んでから、そのチームに参画していました。1、まずは改修、新規作成のスコープをはっきりさせる今渡されている作業が、細分化されているものの一部なのか、この案件の全てなのか、つまり、これを作ったら案件完了なのか、自分が作っても他の人が終わってなければ完了にならないかを認識します。初めての現場でドキュメントや引き継ぎ事項に「納品物」がはっきりと書いてない場合は、直接関係者に聞いておきましょう。これは会社によっても会社内のチームによっても異なるからです。(納品物の例)・ソースだけで良い→ソース管理ツールにPUSHしたら終わり→物理的にファイルが欲しい→サーバーにアップして欲しいなど・テスト仕様書も欲しい→Excelで欲しい→特定のフォーマットで欲しい→スクリプトが欲しい・テスト仕様書にエビデンスも欲しい→同上など、納品物も案件によって異なります。2、自分の担当部分のスケジュールをはっきりさせましょう渡された期日が、コーディング完了日なのか、テスト完了日なのか、リリース日なのか、顧客引き渡し日なのかは出向先やチームによって異なりますが、勝手にスケジュールを引いて間に合わないとなると困るので、自分の作業を完了し、渡す日がいつなのかって部分を、PM、PLまたは顧客ときちんとネゴって文章に起こしておくといいと思います。文章に起こすっていうのはチャットでもメールでもいいんですけど、口頭でやり取りした場合言った言わない問題が発生しないようにするため、口頭で話をした後に関係者をCCに入れたメールなどで再確認した方がいいです。それは相手を信頼していないからではありません。自分自身で期日が間違えていないかを再認識するためでもあります。期日を入れる例は以下のとおり。——X月X日X時 コーディング、単体テスト完了X月X日X時 受入テストX月X日X時 リリース日——3、大枠の作業の洗い出しをしますすごいざっくりとした作業工程の洗い出しをします。今回はWEBサイト制作のPGのフェーズなので、簡単に以下のような行程に分かれるかと思います。・詳細設計・CD→作成する機能の大枠を考える・単体テスト・結合テスト4、現行システムを把握するお見積もりを作るような立場の人だと、現行システムを把握するのは、スケジュールを切る前にやりますがPGでしたら、案件開始前に把握できれば良いかと思います。運用案件の場合、渡された仕様書以外に修正が必要な点がないかを把握することが大事です。それによりスケジュールの達成可否が大きく変わるためです。・現行システム全体を把握→このフェーズでは全体像をざっくり捉えるのが大事です。→インフラ構成だとか→全体画面数だとか→TBL構成だとか・機能追加部分の現行ソースを読む→コード規約だとか→命名ルールだとか・案件進行ルールを把握しておきます5、終わるのか終わらないかを考えてみる。ここまでで、X月X日までに何を作らないといけないかってところが割と具体的になっています。スケジュールが鬼のようにきつい案件も勿論たくさんあります。その場合は、「できない」っていう勇気が大事です。私が経験した企業は10社あるかないか(上場企業から20名程度の小さな会社まで規模は様々)ですが、どの企業様でも、仕事なんだからできないっていうな、とか体育会系的なことを言われることはありませんでした。伝える際には、・ここまでなら終わる・X日あれば終わる・なぜ無理なのかを具体的に伝えてください。ただ「こんなんおわんないっす〜」では伝わらないのでダメです。これとこれは終わりますが、この部分だけ、後出しにしてくださいなどの提案がないと、PL(PM)もじゃあどれくらいやってもらえるのかな?というのを想像できないためです。ちなみにこの工程は、残業時間を含めない状態で考えた方がいいです。残業すれば終わる工数というのは、すでにスケジュールに無理があるからです。————————最後にプロジェクトのリーダーは作業をふるときに通常、作業が終わらないことを想定して、保険をかけながらスケジュール作成しますので、自分で無理かもしれないと思ったときには、正直に伝えてもらったほうが予定を組みやすいです。仮に、できる!と思って作業を始めても、終わらないと思った時点で、速やかに伝えることが大事です。渡された仕事が仮に全て終わらなかったとしても、自分でそれを伝えられていれば、あなたの評価が下がることはありません。周りの人が巻き取ったとしても、それはあなたの責任ではありません。新人のうちは、他者と協力しながらでも良いので、自分でできることを、できる限り順番にこなしていく、というのを意識して仕事をします。もちろん、そんなに優しくない企業もシチュエーションも沢山あると思いますので、思い通りにいかないことも理不尽なことも沢山ありますが、誠意を持って対応することで、理解してくれる上司や同僚は、多いと思います。次回は具体的にコーディングや設計に入るところを記載していきます。ではまた・・・。