皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
2019/10/31 を持って８年間勤めてきたドワンゴを退職しました。 ドワンゴ退職エントリの旬は過ぎているよう気もしますし、こんな何年も放置していたブログで今更何をと思わなくもないですが、なんとなく自分の気持ちの整理もかねて適当に綴ってみようと思います。 何をやってきたか 各種のゲームデバイス、PS Vita, Wii U, 3DS, Nintendo Switch 上でのニコニコプレイヤーの実装をずっとやってきていました。 それぞれのデバイスでのシステム部分というか、ゲームデバイス上での非ゲームアプリケーションフレームワーク、そんなものを作り続けてきた感じです。 これらのニコニコ動画クライアントは、私の手を完全に離れてしまうことになります。 もっとできることはたくさんあるし、改善すべき点もたくさんある。愛用してくれているユーザーに対して自分が出来るはずのすべてを提供することができなかっ
この1年ほど、プロジェクトのリードを任せてもらえるようになりました。2017年の夏くらいから「プロジェクト推進役」→「PJO」→「Tech Lead」, 「Project Lead」など、正式ではないものの「肩書」のようなものがついていますが、実際にやっていることは「プロダクトの成功に向かってプロジェクトを行動で引っ張っていくこと」で統一されています。 これは別に偉くなったとかではなくて、そういう責任を持ってPJに関わる役割だと思って臨んでいますし、実際マネージャーからもそのように言われています。 自分なりに試行錯誤をして時には成功し、時には失敗しながらなんとかかんとかやってきていているのですが、「あー、この本に救われた」とか「ちょっと前にこの本読んでおけばよかった...」という本があったので何冊か紹介したいと思います。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリフ
2. プロセスやツール よりも 個人と対話を、 包括的なドキュメント よりも 動くソフトウェアを、 契約交渉 よりも 顧客との協調を、 計画に従うこと よりも 変化への対応を、 アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだ そうとしている。この活動を通して、私たちは以下の価値に至った。 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。
開発知識に加え、マネジメントスキルも求められるプロダクトマネージャーが最速・最高のアウトプットを生み出すにはどうすればいいのでしょうか。そこで、これまで2社のCTOと5社の技術顧問を経験してきた一休の伊藤直也氏による「1人CTO Night」を開催。主催は転職サイト「DODA」を運営する、株式会社インテリジェンス。本パートでは、参加者から寄せられたお悩み「エンジニアの採用問題」「メンバーの責任感問題」などについて、伊藤氏とソラコム・玉川憲氏が回答しています。 工数管理とメンバーの責任感問題 質問者6：（1）ビジネスサイドとの調整に関する問題についてです。 ビジネスサイドのスタッフが、なにを開発するにしても工数を最小化しようとしてきます。現状、エンジニアが工数の根拠や、その施策の効果見込みを可能な限り数値化して説明していますが、説明にエネルギーがかかっており、エンジニアが疲弊してしまっていま
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。 この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。 ※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。 特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。 はじめに 始めた理由 CTOの不在 品質面に対するレビュー不足 技術広報の不足 それぞれの施策の結果 時間がかかってみんなストレスが溜まる新規レビュー 当たり障りの無いことしか表現できない運用レビュー 兼任状態が続き、進まない新規技術検証 やる必要の薄い「全社」広報 終わった理由 成果が出せなくて、そもそも証明出来ないかもしれない 問題解決は組織じゃなくても出来ると気が
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
趣味でも業務でも日々Webサービスを開発しているzaruです。こんにちは。ついにアドベントカレンダーも最終日です。まだサンタとしての仕事が残っています。さて今回は仕事としてWebサービスを開発するときに気をつけたいポイントを紹介します。まぁ仕事に限った話じゃないですが…参考になれば幸いです。特に新卒プログラマあたりに読んでもらえればと思います😀 なお僕の業務上インフラ周りはAWSが多いです。 RASISという指標 RASISという指標があります。コンピュータシステムの評価指標5つの頭文字を取ったものです。 Reliability（信頼性） Availability（可用性） Serviceability（保守性） Integrity（保全性） Security（機密性） 今回はこの5つの指標に沿ってポイントを紹介していきます。RASIS自体については色々なところで解説されていると思うので
こんにちは、ユニファ株式会社CTOの赤沼です。ちょっと前に2016年になったと思ったのに、もう今年も終わってしまいますね。秋葉原オフィス周辺も今はすっかりクリスマスムードですが、25日が過ぎると一気にお正月モードに変わるんでしょうね。 さて、本日からユニファ開発者ブログをスタートします。システム開発部のメンバーが持ち回りで、弊社サービス開発に関係する技術的な内容や、それぞれ興味を持っている技術的なトピック、開発プロセス、開発体制、社内の文化などについてゆるく書いていきます。どんなメンバーがどんな風に開発しているのかを知ってもらう場になればと思っています。 今回は初回ということで、ユニファの開発体制について簡単に紹介させていただこうと思います。 メンバー構成 2016年12月現在、ユニファ全体での正社員数は（グループウェアの名簿を数えたところ）32名、パートタイムのメンバーも含めると40名を
Photo by shaz wildcat こんにちは、吉岡（@yoshiokatsuneo）です。 動きの速いIT業界において、良い製品やサービスをどれだけ素早く生み出せるかは大変重要なことです。 そのためには、エンジニアにとって質が高く、成長できる開発環境が欠かせません。 では、開発チームの質はどうすればわかるのでしょうか？ 開発チームの質を調べる方法の一つとして、Stack Overflowの創業者であるジョエル・スポルスキーさんが提案する、 「ジョエル・テスト」と呼ばれる方法があります。 (ジョエルさんは、その他Microsoft Excelの元プログラムマネージャ、Trelloの作者、著名ブロガーとして知られています。) http://japanese.joelonsoftware.com/Articles/TheJoelTest.html 「ジョエル・テスト」では、プログラムの
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
