ビジネス、開発、四方山｜naoya
今度のカンファレンスで以下のようなことを聞かれそうなので、最近の出来事とともに、記憶に刻むためにも書いてみる。あんまり推敲はしてない、だらだらと。 ソフトウェア開発において、ビジネスの人と開発の人とでなんか意識が合わないみたいなことの根源はどこにあるのか? みたいなのが最近少しわかったことがある。(ビジネス / 開発と区分けすること自体がそもそもなんだけど、それ言い出すと考察が進まないので、あえて分ける) ビジネスの人は、そもそもがそのビジネスの実現だったり顧客の問題解決だったりが最初から目的なので、簡単にいえば「早く顧客の問題を解決してビジネスを実現したい」と自然に思っている。これは当たり前。 たとえば自分が自宅にお客さんを招くときには「そのお客さんに快適に過ごして帰ってほしい」と思って、家を掃除したり振る舞う食事の献立を考えたり、食後にするゲームは何にするか、などを考えたりする。動機は
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
コードが読めるソフトウェア開発者 - As a Futurist...
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
90. テストの目的 その② - テスターちゃん【4コマ漫画】
90. テストの目的 その② 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する 「バグの発見」と書いたけど、シラバスに書かれている文章は上記の通り。 バグを見つけて、それを修正することで市場に出たときのリスクを軽減することができます。 「おいおい、見つけまくって全部直すのかよ！？」みたいに言う人もいるけど、これはまた別の回の「ステークホルダーへの意思決定のための情報提供」の話でやろうとも考えています。 先出しすると、見つけたバグについては「こういうリスクがあるよ」ということがわかるわけです。 そのうえで、どこまでリスクを許容するのかという考え方もあります。 「これだと大きなリスクはないし、次のスプリントで修正」ってことも全然ありなワケです。 けど例えばカーナビみたいな市場に出た後直せないやつだと、次、がなかったりもします。 ユニットテスト、統合（結合）テスト、シス
Software Engineer Salaries in Japan | OpenSalary
テクニカル・コーディングインタビューを任されるには シニアソフトウェアエンジニアです。コーディングインタビューを「する側」として担当したことがありません...
メテオフォール型開発 - 実践ゲーム製作メモ帳2
今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな
プロダクトに必要なスキルを10年維持するために――「スキルマップ」と「ソフトウェア式年遷宮」
プロダクトチームにおけるスキル維持の難しさ プロダクトの運用には、さまざまな知識やスキルが必要です。プロダクトに対するドメイン知識や、プロダクトを実装するために用いているプログラミング言語。アプリケーションフレームワークやミドルウェア、インフラなど数え上げればキリがありません。プロダクトを長い期間運用していくためには、これらの知識やスキルをどのようにチーム内にとどめておくか、ということを考えていく必要があります。 これらは、さまざまな要因でチームから失われていきます。改修や機能追加などで頻繁に手が入るところは良いのですが、あまり手が入らない領域は時間とともに記憶から消えていきます。ドキュメンテーションをしっかりすることである程度防げますが、それでも失われる暗黙知は存在します。また、異動や退職などによって人がチームから去ることもあります。異動や退職の際に、ほとんどの現場では引き継ぎが行われる
個人的なアプリケーション設計のバイブル3選 - Runner in the High
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
