管理職のための役職引退マニュアル | DevelopersIO
はじめに クラスメソッド株式会社で取締役及びAWS事業本部の本部長を努めております、佐々木と申します。 私は2014年1月にソリューションアーキテクトとして入社後、2015年7月よりAWSエンジニア部門の部長になりました。また事業拡大に伴って営業部門などを集約することとなり、2018年7月よりAWS事業本部の本部長となりました。この6年間、AWS事業部門のトップとして業務に従事しておりましたが、この度2021年6月をもって本部長を引退することにしました。 部長や本部長などの事業責任者は引退が難しいポジションのように思えるかもしれませんが、きちんと順序だてて計画すればスムーズに引退することが出来ます。この記事では、役職をどのようにして引退したら良いのかをご紹介します。 なぜ役職を引退するのか 最も大きな理由は「キャリアの固定化を防ぐこと」です。 私は本部長という役職で、事業本部の中に部があり
Developers.IO 2018 で「API 設計」の話をしてきた #cmdevio2018 | DevelopersIO
緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた
管理職のためのエンジニア組織構築マニュアル | DevelopersIO
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
ジョブスケジューラ「Rundeck」を試してみる | DevelopersIO
森永です。 最近は大逆転裁判をやりながら寝落ちするという毎日を送っています。 サーバ構築する上で、ジョブをどうするかというのは考慮が必要な点です。 簡単に実現するにはcronを使えばいいのですが、要件によってはジョブスケジューラを使わないと厳しいということがあります。 かと言って、エンタープライズで使われている本格的なジョブスケジューラを使うのも大げさすぎる、というのもわかります。 そこで今回は、簡単に構築ができてそれなりに痒いところには手が届くジョブスケジューラ「Rundeck」を試してみます。 Rundeckとは OSSのジョブスケジューラです。 特徴として以下の様なものがあげられます。 エージェントレス SSH接続できればジョブを実行できます。 なので、別サブネットはもちろん、別VPCでも別AWSアカウントでもはたまたオンプレでもRundeckサーバからSSH接続とジョブを実行できる
これからAWSを始める人は一読すべき「AWS運用チェックリスト」を読んでみた | DevelopersIO
はじめに こんにちは植木和樹です。AWSでは各種ホワイトペーパーなどの資料を多数公開しています。 AWS アーキテクチャーセンター | アマゾン ウェブ サービス（AWS 日本語） 今回は上記ページからダウンロードできる「AWS 運用チェックリスト（PDFファイル）」を読んでみました。運用チェックリストという名前ではありますが、AWSを利用する方は一度目を通しておくのをお勧めする内容でした。 チェックリストは大きく3つ「ベーシック」「エンタープライズ」「セキュリティ監査」に分かれています。このうちベーシックは15項目程とコンパクトにまとまっていて、簡易チェックリストとしてお手頃です。 残念ながらまだ日本語訳がされていないようですので、今回ベーシック部分だけをザックリ読んで簡単なコメントを書いてみました。 ベーシック運用チェックリスト 原文は「我々は〜〜〜を設定しています（理解しています）」
【営業さん必見！】iOS/Androidアプリ開発で事前に合意しておくべき7つのポイント | DevelopersIO
※1.X系は開発対象になることがほとんどないため、表から除外しています。 3.ネットワーク オフライン、3G、wi-fi、LTEとスマートフォンではネットワークの種類がいくつかあります。何もここまでと思う方もいらっしゃると思いますが、3Gとwi-fiで動きが異なるということも実際あったので、開発対象のアプリがどのネットワークを対象としているのかは明確にしておく必要があります。 4．テスト範囲 端末とOSのバージョンを組み合わせただけで相当数のパターンができます。全ての端末、全てのOSのバージョン、全てのネットワークの組み合わせでのテストは現実的には不可能ですので、開発でのテストの範囲を決めておきましょう。またテスト範囲には、弊社諏訪が書いた記事「Androidの結合テスト」で書いていましたが、どこまでテストを深くやるのかも決めておくべきです。 5．リリース 開発までで終わりなのか？ストアの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
