2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
おはようございます。@komagataです。 弊社にデザイナーインターンの@Horaotokoが来てくれたので、説明を兼ねて現時点の僕らの会社で使ってる正直なところのツールと開発フローをまとめておこうと思います。（有料のツールやサービスについては値段とプラン名を明記します。） 真面目か！（aka トシ@タカアンドトシ） インフラ CIサーバーとstagingサーバーはさくらのVPS 1G (980円/月)に同居しています。怖話 (kowabana.jp)のproductionはさくらのVPS 8G (7980円/月)を使っています。オフィスのBGMは確認用のiPhoneで流しています。 webサービス Google Apps Google Analytics AMoAd PivotalTracker STARTUP Sプラン ($7/month) Github Organization B
経営本部部門に異動して開発環境の整備に専念 アプリケーションやサービスの開発、あるいはWebサイトの制作などにおいて、欠かせないツールとなっているのがバージョン管理システムです。とくに多人数で開発を行う際、いつ誰がどのファイルを編集したのかをすばやく把握できる、あるいはファイルに加えた変更履歴を簡単に参照できるといったメリットを持つバージョン管理システムは、プロジェクトを円滑に進めるうえで極めて有用です。 サイバーエージェントのアメーバ事業では、このバージョン管理システムとしてApache Subversion（SVN）をメインで使っていましたが、エンジニアの間から「Git」を使いたいという声が高まり、それに応える形で「GitHub Enterprise」を導入、2013年4月から本格的に運用を開始しています。この導入プロジェクトを主導した奥田順子氏は、そもそものきっかけを次のように説明し
NECは、ソフトウェア開発の品質やコスト、納期の改善を目的として、ソフトウェア生産革新活動を推進しており、「ソフトウェアファクトリ」はソフトウェア生産革新活動のプロジェクト管理と、技法・ツール等のエンジニアリング面において、中心的な役割を果たしている。 「ソフトウェアファクトリ」の使用によって、開発プロセスや方法論、ツールの標準化や、ソースコードおよび仕様書などを共有が可能になるとともに、セキュリティ脆弱性検査やバグ検出などの自動化を促進して、生産性と品質の向上を目指す。また、開発状況のリアルタイムでの「見える化」によって、マネジメント力の強化を実現する。 「ソフトウェアファクトリ」の利用が拡大した結果、拠点が国内外に分散している場合でも、開発環境や仕様書などの共有によって作業のやり直しなどが減り、製造やテスト工程のコストを10～20％削減した。また、ハードウェアの用意や、プロジェクトごと
OSSの世界で一大ムーブメントとなっているソーシャルコーディング。400人以上のエンジニアを擁するグリーでも、さまざまな開発課題への対策として2012年よりGitHubを採用し、ソーシャルコーディングを実践している。本セッションでは、同社でGitHub導入を推進してきた開発本部 CTO室の大場光一郎氏が、ソーシャルコーディングの企業導入にあたっての課題や留意点、グリーで実際に得られた効果などを紹介した。 誰もが自由にプログラムを変更・公開し、開発元へ還元できる！ 大場氏はまず、GitHub導入以前にグリーが抱えていた開発の課題として、「急激な増員」「業種の増加」「国際化」の3つを挙げた。 急成長する企業の宿命ともいえるが、2010年には200人程度だった社員数が毎月50人のペースで増え続け、2012年には約1400人の規模にまで拡大。グリーでは以前から社内でスカイプのチャットなどをよく活用
富士通グループと大和ハウス工業は、現在進行中の基幹系再構築プロジェクトにCCPM（クリティカルチェーン・プロジェクトマネジメント）という管理手法を適用した。この結果、開発フェーズとテストフェーズでそれぞれ3割近い工期短縮に成功した。2012年4月の稼働開始に向けて、現在は既存システムからの移行準備と運用テストを進めている。 プロジェクトの遅延が当たり前、とも言われているシステム開発分野において、3割ほどの工期短縮は珍しい。そこで本連載では、CCPMがどのように効果的だったのか、マネジメントをどう工夫したのかなどを3回にわたって詳しく解説していく。第1回では、プロジェクトの概要を紹介するとともに、CCPMとは何か、CCPM採用の経緯、導入効果などについて、プロジェクトリーダーたちの声を交えながら探る。 富士通グループと大和ハウス工業は2010年1月から、大和ハウス工業の基幹系システムの再構築
1. 届け先を管理する新設のDBサーバーで、バッチ処理時間が想定の6～7倍と判明 2. 一括ロードツールを使い、メモリー上での処理を活用して1時間以内に収めた 3. SOAサービスの粒度は、カスタマイズの手間を減らすため単純な機能単位にした 「1時間が要件のバッチ処理に当初、6～7時間もかかった。工夫を重ねて、ようやく時間内に収められた」（ヤマトシステム開発 グループソリューションカンパニー 次期NEKOプロジェクト マネージャー 田中諭氏）。 ヤマト運輸が5年ぶりの刷新を進めている基幹システム「第7次NEKOシステム」。住宅に送る「宅配」から、住宅に住む個人の都合に合わせて送る「個配」を目指したものだ。2010年9月には、送り状に記載された届け先の個人名や住所などを登録した「届け先DBサーバー」を新たに稼働させた。これまで送り状に書かれた届け先は、郵便番号など一部の情報しかシステムに登録
「とんでもなくテストが難しくなっている」──。 2010年春、ある製造業のシステム開発プロジェクトを担当したISIDインターテクノロジーの山本卓也氏（開発二部 プロジェクトディレクター グループマネージャー）は、そう感じざるを得なかった。大量のテストケースを、従来の半分近い期間でさばかなくてはいけない。外部システムとの連携も多く、ライブラリやフレームワークも多用しており、アーキテクチャーは複雑だった。「今までのテストのやり方では立ち行かなくなる」。危機感を募らせた山本氏は、テストの方法を見直す決意を固めた。 まず、テストの体制をバグの発見と修正の2チームに分け、迅速かつ確実にバグをなくすことを目指した。結合テストの自動化も検討。操作ログをスクリプト化するExcelマクロを活用した。テスト担当者が設計フェーズに参加し、テスト計画を共同で作ることも試みた。すべて過去のテストでは実践しなかった対
開発するオンラインアプリケーションは二つある。損保ジャパンと代理店の間で、契約手続きや事務処理といった作業進捗を管理する「ToDoリスト」と、代理店向けの連絡事項を伝えるための「お知らせ」だ。電話やファクシミリを使った従来のやり方よりも、効率よく情報共有することを狙う。 一方のバッチアプリケーションは、オンラインで必要なデータを、保険事務や契約管理などの社内の基幹系システムから、日々取り込むためのもの。対象データは1日に50万件にもなる。 企画段階では、SJSが損保ジャパンに適用した実績を持つSaaSサービス「Salesforce CRM」の採用も検討した。しかし、画面のデザインを代理店ポータルに合わせる必要があるため、今回はForce.comでの開発が決まった。 制約に起因する課題に二度も直面 佐々木氏は開発で十数人のメンバーを率いる。開発に先立って、損保ジャパンや約4万6000の代理店
システム開発プロジェクトにかかわらず、普段の仕事のなかで時折「ん？」と、思考が一旦止まってしまうことがある。その時によって多少変わるが、「これは何かおかしくないか？」「大丈夫かな？」と感じているのだ。 そのほとんどがちょっとした疑問であり、取り越し苦労で終わることも少なくない。しかし、そのちょっとした疑問を放置したために、後々になって取り返しのつかないことになってしまうケースが存在するのもまた事実である。 この思考が一旦止まる「ん？」というポイントは人それぞれである。全く気がつかずに通り過ぎる人も入れば、一旦立ち止まってはみたものの「大したことはない」と通り過ぎてしまう人もいる。どんなに小さな疑問であっても、「念のため手を打っておこう」と取り上げる人もいる。 そうした「ん？」が、プロジェクト運営に全く影響を及ぼさないささいなことであれば問題ないが、そうでない場合には小さいながらも「異常」と
東京証券取引所の株式売買システム「arrowhead」。ミリ秒レベルで応答する高速性が話題になったが、それは注文を受け付ける処理のことである。同システムでは約定処理もレスポンスの高速化を図っており、可用性も高い。プロジェクトに携わったNTTデータの平田氏と東京証券取引所の田倉氏に、その仕組みと取り組みを解説してもらう。 株式売買システムの「arrowhead」が行っていることは、その昔、取引所の立会場で人手で行っていた業務を写し取ったものと考えるとよい。取引参加者（証券会社）からの注文を受け付け、銘柄ごとに分かれた板へ登録後、売り注文・買い注文の付け合わせを行って約定させ、約定した結果を通知する流れとなる。立会場のころであれば、取引所の職員と場立ちの人が注文をやり取りすることで事足りた。 現在は、数千万件/日の注文を処理しつつ、数ミリ秒の速度を要求されるため、世界の取引所では高速、大容量の
1. 1日の処理量が1000万件にも達する株式売買システムを新たに開発 2. 要件定義書から要素を洗い出したチェックリストを作り，設計書をレビュー 3. 取引結果の書き込み処理時間が想定外の長さ。処理の分散を図って乗り切った 2010年1月4日，稼働を開始したシステムがある。東京証券取引所の株式売買システム「arrowhead（アローヘッド）」だ。「ITエンジニアとして20年以上のキャリアがあるが，こんな“静かな”カットオーバーは初めてだ」。こう語るのは，arrowhead開発プロジェクトのリーダーを務めた，東京証券取引所の宇治浩明氏（IT開発部 株式売買システム部長）である。 開発プロジェクトには，東京証券取引所側から最大で70人，開発ベンダーである富士通側から最大500人が参加。初期投資だけで130億円に上る大規模なプロジェクトである。 arrowheadは，100社ほどの証券会社から
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
