E太郎 AE歴10年。普段はアニメ関係のお仕事をしています。 某アニメスタジオで新人さん向けにAEの講師を担当した経験を生かして、超ビギナーの方でもわかりやすいようにAEの使い方を解説していきます！
AfterEffectのプロが徹底解説 | 超難解AE！
E太郎 AE歴10年。普段はアニメ関係のお仕事をしています。 某アニメスタジオで新人さん向けにAEの講師を担当した経験を生かして、超ビギナーの方でもわかりやすいようにAEの使い方を解説していきます！
ChatGPTに要件定義をお願いしたらハンパなかった | DevelopersIO
架空の営業管理システムを作ってもらう前提で、ChatGPTに要件定義をお願いしてみました。 実験として軽く試すレベルで始めてみたのですが、予想を超えるクオリティでしたので、一部始終を皆様にもご紹介します。 ChatGPTとのやりとり まず、ざっくりと必要な機能の洗い出しをお願いしてみました。 あっという間に必要な機能を網羅的にリストアップしてくれまた。私自身、SFA/CRMをいくつか触った経験がありますが、適切な内容だと思います。 中には、「データのインポート・エクスポート機能」のように、検討初期段階ではつい忘れそうな機能も含まれています。さらに頼んでもいないのにオススメの検討プロセスまで教えてくれました。気が利いてます。 機能ベースだと要件の妥当性が判断しにくく思ったので、画面ベースで要件定義してもらことにしました。 「図で教えて」とできないことをお願いしたところ、やんわり断りつつ、意図
ITエンジニアの年収と責務の関係について体験交えて解説していくか｜しのゆ
Photo by Giorgio Trovato on Unsplash 年収800万は普通のエンジニアか否か。火種はいつものTwitterでしたが、いろんな意見が飛び交う興味深い話に各所でなっていたようですね。うーん、様式美。 ちなみに私の感覚だとこんな感じで、年収800万といえば、一般的なWEB開発においては複数プロジェクトの技術設計を行うアーキテクト級で、SIerではおそらく課長-部長級の給与になると思っております。年収800万はそういうラインです。 年収340 → 新卒 年収400 → 2年目(転職サイトゴロゴロ 年収500 → 普通のエンジニア 年収800 → アーキテクト、テックリード 年収1000 → PM、一部スタートアップエンジニア 私の感覚だとこれですね https://t.co/1bXuiPexRj — shinoyu (@shinoyu) February 9, 2
【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に！もう元の開発体制には戻れないデンソー流のアジャイル開発
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
学生とIT業界トップの公開対談で胸を衝かれたこと---IT産業を呪縛する“変われない日本”：ITpro
IPAのイベントで2008年5月28日に行われた学生とIT業界トップの公開対談を聞いていて，一瞬胸を衝かれた。IPA理事長で元NEC 代表取締役社長の西垣浩司氏のこの言葉を聞いたときのことだ。 コンピュータを作ることが本業ではなくなったメーカー 「数として欲しいのは，金融システムなど企業の大型システムに従事する人間。こういった領域では，個人の能力よりは業務ノウハウが重要。プログラマとして優秀であっても，業務を理解しないと，よいシステムができない。技術だけを評価して処遇することは企業としては難しい。天才プログラマのように技術を極めるのであればそれを生かす道に行くべきであって，企業に入って大型システムを開発するのはもったいないか，向いてない」(西垣氏） 必要とされているのは技術ではなく，プロジェクト・マネジメント能力や調整能力。求められているのはメーカーの人材像ではなく，ゼネコンやエンジニアリ
現場の叫びで分かった嫌われるプロマネの正体 － ＠IT自分戦略研究所
プロジェクトをマネジメントするどころか、メンバーを地獄に陥れるようなプロマネの正体を暴く。現場の悲痛な叫びはプロマネに届いているだろうか。（Tech総研／リクルートの記事を再編集して掲載） 複雑化・高度化した現代の技術。1人のエンジニアが、1つの案件を仕上げることができるケースなどほとんどない。そこで重要になってくるのが、メンバーを率い、プロジェクトをまとめ上げるプロジェクトマネージャ（プロマネ）の力量だ。しかし……。 Tech総研が、主にIT分野のエンジニア100人に行ったアンケート調査によれば、これまでにプロマネの下でスムーズに進めることができたプロジェクトは5割に満たないと答えたエンジニアが、何と88％にも上っている（図1）。しかも、そのうち79％が、別のプロマネであればうまくいったはずと答えているのである（図2）。
プログラミングの6大10項目リスト
Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの｢エゴレスプログラミングの十戒｣ 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに｢空手｣を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯
SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
ニッポンIT業界絶望論:江島健太郎 / Kenn's Clairvoyance - CNET Japan
日本のIT業界は救いようがない。絶望的としか言いようがない。 IT業界不人気なんて、この業界に重くのしかかる決して晴れることのない暗雲の氷山の一角に過ぎない。はてなの匿名ダイアリーにもどうせ理系出身者なんていらねえんだよ。なんて書かれていたけど、これが現実なのだよ、学生諸君。 ちょっと補足しておくけど、ここでIT業界っていうのは、SIerのことだ。お客さんの要件をヒアリングして、その要求に沿ったシステムを受託開発するっていうビジネスのことを指している。 ぼくもその昔、その世界のループに組み込まれていた。そして華麗なるコミュニケーション能力とやらをいかんなく発揮し、場の空気を読み、生意気なぐらいのチャレンジ精神で、それなりに仕事のできるよい子だったようだ。 いや、正直に言うよ。正直に言うとだね、結構楽しかった。 だって、考えてみてごらん。お客さんのところに出向いて行って、その業界のことをじっ
ユメのチカラ: 開発工程を別々に担当してはいけない
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
大迫正治 REPEDANT BLOG > 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む : ITmedia オルタナティブ・ブログ
日本のソフトウェア産業は「製造業」よりも「サービス業」に分類される。なぜなら、革新的なプロダクトを研究開発し、一気呵成に市場に展開するよりも、顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流となっているからだ。 創業期は受託開発で糊口をしのぎ、徐々に自社製品の研究開発に資金を回して、いつかは自社ブランドで世界を席巻する、というストーリーは巷にあふれるが、これは結局のところローリスクでスタートしながらハイリターンを得ようとする野望であり、実現へのハードルは低くない。その理由は、中毒性のある受託開発と、ソフトウェア産業の悲惨この上ない「重層下請け構造」にある。 １．受託開発では「技術」が蓄積しない 住信インベストメントの辻俊彦氏はご自身のブログで次のように述べている。「クオリティの高い受託開発力は、オリジナリティ溢れる尖った自社開発力を生み出す素地になると思っている。投資
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
受託からサービスへの移行に必要なこと。
よくwebの受託をメインにやっている会社さんが、儲からないという理由でサービスに行きたいとの話を聞く。 しかし結構、難しいですよね、と、ついつい言ってしまう。 理由のコアは、下記エントリーに書いてあった。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む １．受託開発では「技術」が蓄積しない ２．受託開発では「人材」が蓄積しない ３．受託開発では「資金」が蓄積しない 技術が蓄積されないのは自社の役割や案件次第では？と思うこと以外は、結構同意だ。 （受託は、自社では実現できない案件に関われることなどが魅力で、そこに技術やノウハウ習得のチャンスは転がっていると思うし。） 一番重要なのは、キャッシュフローが安定しないところではないだろうか。 サービスと受託の大きな違いは、 「受託は技術を売る仕事」 「サービスは、文字通りサービスを売る仕事」 である。 サービスは、お客様がつくと継続的に
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> `�s�U �q��U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
顧客の機能要求に折れないこと!
Kathy Sierra /青木靖 訳 2006年5月10日 製品やサービスが成功するほど、ユーザの要望を受け入れるようにというプレッシャーは強くなる。ユーザが多くなるほど、要望の範囲は広がっていく。あるユーザにとっての ｢それがないんだったら買わない｣機能が、別のユーザには取引をぶちこわすものになる。そしてあなたの製品やサービスが人気になるほど、そういった要望は、要求と最後通牒へと変わっていき、ついには痛烈な批判になる。 私たちになしえる最悪のことは、それに折れるということだ。しかし要望/要求や批判が強く、怒りを帯びたものになるほど、誘惑に抵抗するのは難しくなる——｢この1個だけ付け加えれば･･･きっとあの連中もおとなしくなってくれる｣ しかしあらゆる色を1つに混ぜ合わせて泥色のしみを作るなら、誰も私たちのすることを嫌わなくなるが、同時に誰も喜びも、興奮も、魅了もされなくなる。そうして私
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
子供のスマホ知恵袋
空いた時間にWEBシステム(ホームページだけでもいい)を(バイト感覚?で)受注する為の情報サイトを探しています。 PHP,Perl,MYSQL等は触れます。基本は、土、日、祝日を使っ.. - 人力検索はてな