並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 73 件 / 73件

新着順 人気順

仕様書とはの検索結果41 - 73 件 / 73件

  • 予算の作り方|和田洋一

    経営の重要なツールである予算につき私見を書いてみる。 世に予算を「正確に策定する」議論は多く見受けられるものの、なぜ予算を建てるかに対してストレートに述べたものはあまり見ない。 「なぜ」がなければ「どのように」は導けない。 予算とは経営からのメッセージ予算は、スタッフの行動を促すための仕様書 CEOは、これを肝に銘ずるべき。 「見通し」で予算数値を作る人は経営していないと宣言しているのと同じ。 一方、単なる気合を書いてしまう人も、メクラ運転になるのでハタ迷惑。 仕様書は以下の二つの機能を持つ。 ① 経営の方向をメッセージとして打ち出す 予算は言語表現であると割り切る。 ・大幅増益としたい場合 会社や置かれているステージによって「大幅」を表現する数値は異なり(30%増、倍増等)、スタッフの感覚と一致しなければ効果は半減する。 ・次年度以降の飛躍のため、あえて踏み固めることを伝える場合 前年度

      予算の作り方|和田洋一
    • Webサイト制作をどれくらいの粒度で分解してタスク化するか|重松佑 / Shhh inc.

      プロジェクトが始まるときにかなり初期の段階でWBSを作ることは多いとおもいます。そのWBSの作成、プロマネやディレクターに任せっぱなしになっていないでしょうか。WBSはスケジュールをガントチャートで表したものを指していると思われがちですが、実はスケジュールだけでなく見積もりやアサインを精度高く行うためにも重要なものです。 たとえば「Webデザイン作成」というスコープにどのような実作業が含まれているかはWBSを作ることによって見える化しプロジェクトメンバーやクライアントと共有できるようになります。ときどき下記のように書かれたWBSを見ることがあります。 Webデザイン作成 ・作成 ・確認 ・修正 ・確認2 ・修正2 ・確定 しかし、これでは「Webデザイン作成」に必要な知識、さらには作業量・スケジュール・予算も分かりません。Webデザイン作成の例を続けると、下記のように「作成」のスコープを分

        Webサイト制作をどれくらいの粒度で分解してタスク化するか|重松佑 / Shhh inc.
      • 続:45歳多重派遣プログラマの退職エントリ

        前エントリが思いの他読んで貰えて「まぁ、こんなものか」と思っていた20数年の枯れたプログラマ人生に幾許かの水を挿して貰った気分になった。ありがとう。 続きを書いて欲しいという声もちらほら頂いたので調子にのって書いてみた。 ↓前エントリ https://anond.hatelabo.jp/20210130001953 年収が高いのでは?という声をそれなりに頂いた。 最初に所属した会社が倒産をして先輩の起業に付いていったのだが、その会社が完全歩合制の会社だった為、多重派遣としては良い方の収入だったように思う。 例えば、月単価から2割が会社のお金、8割が自分の取り分というようなシステムである。勿論、仕事が無い時は収入はゼロ。 前エントリでも書いたが、個人でフリーでいるより単価交渉をしやすく、将来貰えるかは解らないが年金も2階建てに出来る。 現状ではある程度キャリアのある人達にとっては悪くないシス

          続:45歳多重派遣プログラマの退職エントリ
        • ラバーダッキング法とは?悩みや問題解決に効果的な実践方法をご紹介!

          ラバーダッキングとは問題解決手法の1つに、「ラバーダッキング」というものがあります。IT用語的にいうと「ラバーダック・デバッグ」とも呼びます。ラバーダックはゴム製のアヒルの玩具で、幼児がお風呂に浮かべて遊ぶ姿を見たことがあると思いますが、あのアヒルの玩具です。そんなものが問題解決にどう役立つのか信じられない方もいますよね。 ここでは、ラバーダッキング法を活用した問題解決方法について紹介していきます。 やり方は非常にシンプルです。 ・机の上など、目につくところにラバーダックを置きます。(ラバーダックが入手できなければ、小さなマスコットキャラクターでも可) ・現在、頭を悩ませていることをラバーダックに向かって、声を出しながら話します。 ただこれだけのことですが、声に出して悩みを説明する過程で、「何について悩んでいるのか」「その解決策は何か」ということが次第に見えてきます。 IT系のエンジニアな

            ラバーダッキング法とは?悩みや問題解決に効果的な実践方法をご紹介!
          • 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

              ITエンジニアの年収と責務の関係について体験交えて解説していくか|しのゆ
            • 9時10分前を理解できない若手を生んだ日本語軽視のツケ

              先日、講演会後の懇親会で、管理職が20代の社員たちの日本語能力に悩まされているという話で盛り上がった。 「9時スタートの研修会なのに1分前にドサドサと入ってきて、5分、10分の遅刻は当たり前。なので『9時10分前には集合するように』と言ったら、キョトンとした顔をされてしまって。ま、まさかと思いつつ『8時50分に来るのよ』と念押ししたんです。そしたら、『あ、そういうこと』って。もう、わけが分かりません」 こんな“珍事件”に面食らった上司たちの嘆きが、「これでもか!」というくらい飛び出したのである。 確かに、私自身、店で領収書をもらおうとしたときに、「???」という事態に何度か出くわしたことがある。 【ケース1】 河合「領収書をお願いします」 店員「宛名はどうしますか?」 河合「上、でいいです」 店員「うえで、ですね!」←自信満々感満載 河合「……は、はい」 するとなんとその店員は宛名の部分に

                9時10分前を理解できない若手を生んだ日本語軽視のツケ
              • しなくていい失敗を回避する『プロジェクトマネジメントの基本が全部わかる本』

                プロジェクトマネジメント(PM)の重要性は、あまり認知されていないように見える。 うまく回っているときは「あたりまえ」扱いでスルーされ、いざ暗礁に乗り上げたときに「どうなってるんだ!?」と糾弾の的となる。 プロジェクトをうまく回していくコツというか勘所は確かにあり、相応のトレーニングが必要だ。にもかかわらず、なぜか蔑ろにされている。ろくに訓練もしないまま、「見て学べ」「やって覚えよ」と実践に放り込み、メンタルをやられず生き延びた者が幹部になる。 これは悪手だ。 よく、「失敗から学ぶほうがより身につく」などと唱える輩がいるが、しなくていい失敗は避けたほうがいいに決まってる。そして、この「しなくていい失敗」のほとんどは、基本を押さえるだけで回避できる。 この、PMの基本を押さえているのが本書だ。 『プロジェクトマネジメントの基本が全部わかる本』には、プロジェクトを回していくために「あたりまえ」

                  しなくていい失敗を回避する『プロジェクトマネジメントの基本が全部わかる本』
                • 日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ

                  今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル

                    日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ
                  • プロダクトの成功に必要な 3 つのステージと 20 のタスクについて:現場の動き方をまとめました|Fritz | Lead Product Manager @ Mercari

                    こんにちは、フリッツ です。プロダクトマネージャー(以下 PM)になってから相当の年月が経ち、特に、現職の US メルカリにおいては「 UIUX 強化型 PM 」として認知されるようになりました(ありがたい)。 ただ、最近は自分があまりにもいま持っているスキル・経験に立脚しすぎているなぁ、と感じており、強みの分野を広げようとお勉強中。 ということで、旅の序盤として、本記事では「プロダクトの成功」を導くために必要とされる、問題定義・優先順位決定・実行 という 3 つのステージを PM 視点から 20 項目にわけてみました。できるかぎり、(自分の今までの)現場の動き方に沿うようにまとめました。割と基本的な内容ではありつつも、特に実行のパートにおいては、現場で役立つような個人的知見を多少含められたはず…。 プロダクトに関わる方、および・駆け出し~数年目の PM の方のお役に立てる記事になっていれ

                      プロダクトの成功に必要な 3 つのステージと 20 のタスクについて:現場の動き方をまとめました|Fritz | Lead Product Manager @ Mercari
                    • エンジニアの辛い仕事をいい感じにする技術 - コンサルの仕事術・思想から学べること - Lean Baseball

                      エンジニアの辛い仕事を消す本かも(多分) 2014年の秋にリクルートに転職してから何社か経て今も自社サービスのエンジニアとして働いてるマンです. リクルートに入ったとき, そしてその後の転職先*1などなどで, 社内外問わずのコミュニケーションの辛さ. 社内調整, 顧客折衝etc... コードじゃなくて, ドキュメントを書く仕事の辛さ. プレゼンテーション・説明そのもの. 技術わかんない上司に説明(ry*2 みたいな経験をたくさんしました&これはエンジニアをやってたら誰でも直面する事態かなと思います, 自社サービス企業だろうがSIer/受託開発の企業だろうが. そもそも, 昔の調査にもそんな雰囲気ありますし, おそらく今もさほど変わらないでしょう. ...ということを, 前回のブログの執筆中および反響で改めて思い*3, そういえば自分はこの辺, 元々ITコンサルタント*4だった時に学んだこと

                        エンジニアの辛い仕事をいい感じにする技術 - コンサルの仕事術・思想から学べること - Lean Baseball
                      • GitHubでの業務ソースコード流出 背景にIT業界の二極化と多重下請け構造|楠 正憲(デジタル庁統括官)

                        45歳のプログラマーの男が仕事で書いたコードを年収判定のためGitHubに上げて、複数企業の業務で使われていたコードの一部が流出した。GitHubは本来、公開して構わないオープンソース等のコードを共有する場で、年収判定サイトは、コミュニティでの活動を評価に結びつけようというコンセプトだった。しかし男は業務として開発した商業機密として保護すべき顧客のソースコードを不当に持ち出して、自分の年収を判定してもらうために丸ごと公開してしまった。 GAFAはじめネット企業を中心に、自社サービスを構成する部品で汎用的に使えるコードをGitHubなどを通じてオープンソースとして公開する動きが広がっている。一方で伝統的なシステム開発では、ソースコードは委託した業務の重要な成果物、秘匿すべき商業機密として組織内で管理することが一般的で、開発環境からはGitHubなどのサイトにアクセスできないよう遮断している場

                          GitHubでの業務ソースコード流出 背景にIT業界の二極化と多重下請け構造|楠 正憲(デジタル庁統括官)
                        • 新型コロナ/定額給付金、神戸市はたったひとりの職員が1週間で、申請状況確認サイトを構築 (1/7)

                          今回のひとこと 「行政がITシステムの仕様書を作って発注し、入札を行い、請負契約を結ぶという時代は終わりつつあることを強く感じた。特別定額給付金の申請状況等確認サービスは、神戸市の職員自らが構築した。行政サービスを作り上げるひとつの試みであり、今後、広げていきたい」 特別定額給付金の申請状況を確認できるサービス 神戸市が、日本マイクロソフトの「Microsoft Power Platform」を活用して、新型コロナウイルス感染症対策に関する住民サービスの提供を開始している。 そのうちのひとつが、5月29日からサービスを開始した「特別定額給付金の申請状況等確認サービス」である。特別定額給付金の⼿続き状況を⾒える化し、それを住民が確認できるサービスだ。 神戸市は、5月14日に、特特別定額給付⾦の申請書の郵送を開始。100万⼈以上の都市では全国最速の対応が注目を集めたが、全国の自治体と同様に、コ

                            新型コロナ/定額給付金、神戸市はたったひとりの職員が1週間で、申請状況確認サイトを構築 (1/7)
                          • プログラマと出世 - megamouthの葬列

                            就職することになって、つまりは私が職業プログラマになって、それを聞き知った叔父が私を訪ねてきた。 「プログラマってのは、若いうちはいいが、長くはできないんだろう?」 リビングの炬燵に潜り込んだ叔父は寒そうに体を震わすと、最初にそう尋ねた。 当時、業界には「プログラマ35歳定年説」というのがあった。 郵便局員をしている叔父が知っていたというのだから、有名な話だったのだろう。 私は訳知り顔で微笑むと、業界1年目のひよっこなりに考えた、この話のカラクリを説明した。 ―――プログラマというのは、システム開発に伴う仕事の中で、単価が最も安い。ようするに給料が一番安いんです。でも、35歳にもなれば、まさか20代と同じ給料というわけにはいかない。35歳相応の給与を貰うためには、プログラマより単価の高い仕事、つまり管理職に「出世」するしかない。つまりプログラマだった人もある時が来ると出世してどこかの管理職

                            • 基本4情報での名寄せは難しい|MORIDaisuke

                              先日は住所の件でお楽しみでしたね。 私も楽しくなってしょうもないツイートをしたところ、@masanorkさんから有用な情報をいただいてしまいました。 異体字に加えて外字も根深いですし、日付型に収まらない住基の生年月日とか、屋号を含んだ個人事業主の口座名義とか、外国人氏名における住民登録のアルファベットと口座名義のカタカナとの解離とか、旧姓併記の例外処理とか、文字列型に刻まれたバッドノウハウの塊ですね https://t.co/GOaytijfst — Masanori Kusunoki / 楠 正憲 (@masanork) June 6, 2023 このとき、私はごく簡単な「名寄せの難しさ」の社内研修資料を作っている最中だったのですが、この情報が大変参考になりました。 一方、私だけが得をしているのがなんとなくムズムズしてきたので、ここにアウトプットしてスッキリしようと思います。 なお、住所

                                基本4情報での名寄せは難しい|MORIDaisuke
                              • 仕事で作業クオリティが低いと言われ話を聞くと不思議な世界になっていった「仕様に書いてないが普通のエンジニアならできるでしょ」

                                あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 仕事で作業クオリティが低いってコメント来たので話聞いてみると不思議な世界が広がっていた 相手「仕様に書いてないが、普通のエンジニアならできるでしょ」 私「仕様に書いてないならやれません。仕様確認会などあったのでしょうか?」 相手「そんなものない。わからなかったら確認するでしょ」 続 2022-03-16 10:02:09 あれっくす@フロントエンド x デジタルマーケティング @MHTcode_Alex 私「わからないところは都度確認してますが、仕様に記載されていないものを作ることはできませんし、確認すらやりようがありません」 相手「テストでいっぱい不具合出てくる」 私「クオリティコントロールの仕組みがないから当たり前では?」 相手「こっちが確認してないのが悪いってこと?」 続 2022-03-16 10:

                                  仕事で作業クオリティが低いと言われ話を聞くと不思議な世界になっていった「仕様に書いてないが普通のエンジニアならできるでしょ」
                                • 『タクティクスオウガ』のマップはなぜ、圧倒的なクオリティと規格外のボリュームを両立できたのか? その裏には業界最古のゲームエンジン「HERMIT」の存在があった

                                  『タクティクスオウガ』。その名を耳にして思い浮かぶのは、発売から25年以上の年月が経った今もなお、圧倒的な支持と人気を得ているという、スーパーファミコン後期の名作タクティカルRPGとしての確固たる姿だろう。 © 1995 SQUARE ENIX CO., LTD. All Rights Reserved.(画像は『タクティクスオウガ』公式サイトより) そんな『タクティクスオウガ』の開発には「HERMIT」(ハーミット)なるものが用いられていたことはご存じだろうか。 「HERMIT」とは、『タクティクスオウガ』を販売・開発した株式会社クエストが独自に作り上げた開発ツール……今で言う「ゲームエンジン」に相当する存在だ。この謎のゲームエンジンが、実は『タクティクスオウガ』の開発にあたって大活躍をしていたという。 ではこの「HERMIT」は、いったい何がすごかったのか? まずひとつ目のポイントは、

                                    『タクティクスオウガ』のマップはなぜ、圧倒的なクオリティと規格外のボリュームを両立できたのか? その裏には業界最古のゲームエンジン「HERMIT」の存在があった
                                  • 『ガンパレ』の企画書、ついに公開━初代PSの伝説的タイトルは、なぜ生まれたのか?そして『LOOP8』へ受け継がれたもの【ゲームの企画書】

                                    私は今も『ガンパレード・マーチ』の企画説明会のことを思い出しては、一人で笑う時があります。社長よりも誰よりも偉そうな芝村が、人の魂をPSの上に出現させると宣言したときの会議場の沈黙と静寂を、私はハッキリと、覚えています。 『電撃ガンパレード・マーチ』 スタッフコメントより 2000年、9月28日。そんな初代プレイステーションの最末期、まさに「人の魂をPSの上に出現させた」タイトルがあった。その名も『高機動幻想 ガンパレード・マーチ』(以下、『ガンパレ』)。 熊本を舞台に、謎の生命体「幻獣」との戦いに動員される学生の姿を描くシミュレーションでありながら、特筆すべきはその「自由度の高さ」。 ものすごく端的に言えば、「生き残りさえすればゲーム中は何をやってもいい」という全く制限を感じさせない自由度の高さに加え、AIによって制御された「人間味のあるNPC」も、その学園生活と独自のゲーム体験を彩る。

                                      『ガンパレ』の企画書、ついに公開━初代PSの伝説的タイトルは、なぜ生まれたのか?そして『LOOP8』へ受け継がれたもの【ゲームの企画書】
                                    • SIerに生息する「おじさんSE」の生態を知る - Qiita

                                      ここでいうおじさんSEとは、主にSIerに生息する、 ・30歳以上で ・モダンな技術を知らない ・レガシーな技術しか知らない ・主に設計書などのドキュメント類を弄っており、コーディングをしない ・現状から変わる気がない(キャリアアップに対し具体的なアクションがない) 人たちを指す。 決して単に妙齢のエンジニアを一括りにしているわけではない。 「おじさんSE」より良い呼び方があれば、ぜひご提案いただきたい。 第1章 おじさんSEの仕事内容 おじさんSEは、コードを書くことはほぼ無い。 これは現場にもよるので、全く無いというわけではないが、 多くのおじさんSEはコーディングはしない。 ではおじさんSEは何をやっているのかというと、 ・内部設計書、外部設計書、詳細設計書の記述 ・結合試験以降の試験項目票の作成 ・試験結果のレビュー 大抵はこの3つになる。 99.9%はウォーターフォール型である。

                                        SIerに生息する「おじさんSE」の生態を知る - Qiita
                                      • エンジニアが「PMも兼任して」と言われたときの心構え

                                        この記事は プロダクトマネージャー Advent Calendar 2020 17日目の記事です🎄 カンタンに自己紹介 名古屋の企業でフロントエンドエンジニア兼PMをやってます、amakawaです。2年ほど前に事務員からエンジニアに転職して、総勢50名ほどのベンチャーで2年近くバックエンド〜フロントエンドを書きつつ、プロダクトマネジメント・プロジェクトマネジメント業務も担当してきました。 東京へ転居して、2月からディレクターとしてプロダクトマネジメント・プロジェクトマネジメントをメインにやっていく予定です。 どうしてこの記事を書いたか 弊社は少人数のベンチャーということもあり、1人のエンジニアが複数プロダクトの開発を兼任します。さらに専任のPMはいないので、エンジニア・デザイナーは自然とプロダクトマネジメント・プロジェクトマネジメントをやることになります。私も社内ツールを2、3つほど保守

                                          エンジニアが「PMも兼任して」と言われたときの心構え
                                        • ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita

                                          システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・2021/04/16:文章術系にリンクを追加しました。 ・2020/11/28:文章術系にリンクを追加しました。 ・2020/07/24:文章術系にリンクを追加しました。 ・2020/05/24:文章術系にリンクを追加しました。 ・2020/05/14:スライドデザイン系にリンクを追加しました。 ・2020/04/29:スライドデザイン系にリンクを追加しました。 ・2020/04/17:文章術系にリンクを追加しました。 ・2020/04/12:関連するTwit

                                            ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
                                          • AIはどのような仕事ができるようになったのか?ChatGPTで変わる「優秀な人材」

                                            この図はざっくりと3つの領域に分かれます。まず左下が従来のプログラミングの領域です。これは簡単に言うと「プログラムは間違ってはいけない定形な仕事を奪う」ということです。次にその上の士業が責任を取る領域です。これは「責任」を取る人がいないと成立しない仕事です。ミスが発生した際に罰則を与えるという形で、ミスの発生を防いでいます。最後に右側のホワイトカラーの仕事の領域です。ホワイトカラーの仕事は入出力が不定形であり、作業フローも非定型であったりします。そのため、多少のミスはあっても仕方ないという前提の上で仕事が行われています。 機械学習がビジネスに組み込まれるにつれ、ホワイトカラーの仕事領域はそれらによって少しずつ代替されつつあります。その図がこちらになります。 ホワイトカラーの担っていた領域は、表データの機械学習(重回帰や、Lasso回帰、SVM、RandomForest、LightGBMなど

                                              AIはどのような仕事ができるようになったのか?ChatGPTで変わる「優秀な人材」
                                            • プログラマーのための原則(2 万字) - Qiita

                                              はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』(1999 年)で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同

                                                プログラマーのための原則(2 万字) - Qiita
                                              • 「私たちは慣れに支配され、使いにくさに気づいていない」 UI研究者・増井俊之氏が語る“使いやすさ”の本質

                                                機能とUIの進化はなぜ比例しない? UI研究者に聞く、使いやすさの本質とUIのこれから 「私たちは慣れに支配され、使いにくさに気づいていない」 UI研究者・増井俊之氏が語る“使いやすさ”の本質 誰もが気軽に電子機器を持つようになった今、私たちの生活はデジタルの恩恵で確実に便利になっています。しかし、UIは“よりよさ”を求めた結果、期待した評価とは正反対の声が集まること少なくありません。 そこで今回は、慶應義塾大学環境情報学部の教授で、予測型テキスト入力システム「POBox」やiPhoneのフリック日本語入力システムの開発者であるUI研究者の増井俊之氏に、UIの本質についてお話をうかがいました。まずは増井氏がUIに関わることになったきっかけと、使いやすさの本質について。 UI研究に関わるようになった流れ ーー学生時代には電子工作やソフトウェアに興味をお持ちで、現在のUIにつながる研究は社会人

                                                  「私たちは慣れに支配され、使いにくさに気づいていない」 UI研究者・増井俊之氏が語る“使いやすさ”の本質
                                                • (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book

                                                  本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl

                                                    (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
                                                  • ものを縫ったりなどすることに多少の造詣のある者でございます。 結論とい..

                                                    ものを縫ったりなどすることに多少の造詣のある者でございます。 結論といたしましては、5千円の鞄を5千円以内で直してほしいと言われましても、それはなかなか難しいことが多いでしょうとしか言わざるを得ません。 ファスナーを修理するには、まず、もとのファスナーを外す必要があります。最低でも鞄の表地・ファスナー・裏地が重なっているはずですが、余計な傷を絶対に付けないよう、慎重に分解しなければなりません。 鞄は洋服と違って洗濯するものではありませんから、見えない部分にボンドや両面テープなどが使われていることも多々ございます。貼り付け方によっては、分解の支障になります。 布が破れたということは、それなりに長期間お使いになっていたものと思います。直接破れた部分以外も、生地が全体的に弱っている可能性があります。つまり、新品に比べて、柔らかくなっていたり破れやすくなっており、それを触るのは大変気を遣う作業にな

                                                      ものを縫ったりなどすることに多少の造詣のある者でございます。 結論とい..
                                                    • 何故『共産党に繋がりがある』と自治体からお金を引っ張れるのか(一般論)

                                                      昔地方公務員として勤務していた体験談と、当時聞いた話を書いておこうと思う。 あくまで一般論であり、今話題の、仁藤さん率いるColaboの疑惑とは無関係だ。 幹部職員と共産党の関係多くの自治体において、一定の役職(どこの自治体もだいたい課長級くらいからが多いと思う)になると赤旗を購読する者が多い。 多いと言うか一定の部署だとほぼ全幹部が購読していたりする。 何故俺が知っているのかって? 毎月毎月、赤旗の担当者が来庁して各部署を周り、集金していくからだ。もちろん一般職員は購読していないので幹部の机を周るわけだから目立つ。 何故か。 別に幹部たちは赤旗を読みたいわけではない。部署ごとに新聞(赤旗も)をとっているので、読みたければそれを読めば良いだけだ。 そうではなく、共産党の覚えをよくしておかない業務上困るから、表面上仲良くする、そのために赤旗を購読しているというわけだ。 何故共産党と仲良くしな

                                                        何故『共産党に繋がりがある』と自治体からお金を引っ張れるのか(一般論)
                                                      • セブンペイ問題の根本要因。日本の悪習慣「ウォーターフォール」 - まぐまぐニュース!

                                                        鳴り物入りで導入されるもすぐに大規模な不正アクセスが発生、セブンイレブンという企業自体のITリテラシーを疑われる事態にまで発展してしまった、セブンペイ問題。なぜこんなことになってしまったのでしょうか。世界的エンジニアでアメリカ在住の中島聡さんは今回、自身のメルマガ『週刊 Life is beautiful』で、いびつで時代遅れな開発体制を持つ日本ITゼネコンと、そんな組織にセブンイレブンが開発を委託したところに根本の原因があると指摘しています。 ※ 本記事は有料メルマガ『週刊 Life is beautiful』2019年7月16日号の一部抜粋です。ご興味をお持ちの方はぜひこの機会に初月無料のお試し購読をどうぞ。 プロフィール:中島聡(なかじま・さとし) ブロガー/起業家/ソフトウェア・エンジニア、工学修士(早稲田大学)/MBA(ワシントン大学)。NTT通信研究所/マイクロソフト日本法人/

                                                          セブンペイ問題の根本要因。日本の悪習慣「ウォーターフォール」 - まぐまぐニュース!
                                                        • ウェブアクセシビリティ導入ガイドブック|デジタル庁

                                                          デジタル庁では「誰一人取り残されない、人に優しいデジタル化」を実現するため、継続的に「ウェブアクセシビリティ」の向上に取り組んでいます。この度、ウェブアクセシビリティに初めて取り組む行政官の方や事業者向けに、ウェブアクセシビリティの考え方、取り組み方のポイントを解説する、ゼロから学ぶ初心者向けのガイドブックを公開します。 優しいサービスのつくり手になる一助として、ぜひご活用ください。 公開の背景ウェブアクセシビリティの向上に取り組むには、非常に専門的な複数の規格とガイドラインをそれぞれ確認する必要があります。そのため、適切なやり方がわからないままに、現在は間違っている対応の踏襲、不要・過剰な対応、不適切な対応をしてしまうことがあります。ウェブサイトだけではなく、申請・手続等のデジタルサービスの重要性が増す中で、最新の技術動向を踏まえた、初心者が学習できる行政機関向けの研修資料が不足していま

                                                            ウェブアクセシビリティ導入ガイドブック|デジタル庁
                                                          • 文章生成AI利活用に関するガイドライン.pdf

                                                            文章生成AI 利活用 ガイドライン Version 2.0 令和6年(2024年)4月 東京都デジタルサービス局 2 はじめに このガイドラインは、東京都で初めてとなる文章生成AI の利活用ガイドラインです。 ChatGPTをはじめとする文章生成AIは、都職員の業務 のあり方を大きく変革する可能性を秘めている一方、 様々なリスクも指摘されています。このため、業務での 活用にあたり期待する効果を得るためには、その特性を よく理解し、正しく利用することが重要です。 東京都では、デジタルサービス局に検討プロジェクト チームを設置して、文章生成AIの利活用について議論を 重ね、令和5年8月、検討の成果をガイドライン (Version 1.0)としてまとめ、文章生成AIの全庁利用 を開始しました。 その後、10月に利用状況についてアンケートを行った ところ、活用事例やプロンプト例を求める声が多かった

                                                            • 「東京五輪の日当は35万円」 国会で暴露された東急エージェンシー、パソナへの“厚遇” | AERA dot. (アエラドット)

                                                              国会で丸川珠代五輪相に声をかける橋本聖子・五輪組織委会長(C)朝日新聞社 東京五輪・パラリンピックの大会運営に当たるディレクターなどの日当がなんと35万円―-。 【写真】東京五輪・組織委と東急エージェンシーが交わした業務委託契約書はこちら 驚くような金額が明かされたのは5月26日に開かれた国会の衆議院文部科学委員会だ。立憲民主党の斉木武志衆院議員が委員会に示した東京五輪・パラリンピック組織委員会と大手広告代理店「東急エージェンシー」が交わした業務委託契約書にそう明記されていたのだ。 大会期間中、武蔵野の森総合スポーツプラザでの準備・運営にかかわるディレクター、サブディレクター、アシスタントディレクター、サービススタッフらのマネジメントなどの業務を委託するという内容で、契約が締結されたのは2019年12月17日。 当初の予定だった2020年7月の五輪開催からみれば、半年ほど前になる。業務委託

                                                                「東京五輪の日当は35万円」 国会で暴露された東急エージェンシー、パソナへの“厚遇” | AERA dot. (アエラドット)
                                                              • プログラミングスクール通うくらいならチートスキル身につけたほうが百億倍楽やぞ|erukiti

                                                                皆さん異世界転生ラノベをご存知ですか?チートし放題な主人公たち好き勝手しやがってとか思っています?最近は「初級魔法で無双する」「生活魔法で無双する」みたいな話流行ってますよね。 でも、別に異世界なんていかなくても、転生しなくても、プログラミングのチートスキルなんて簡単に身につけられるんですよ。 ※ここでいうチートスキルは本来の意味のチートではないのでご注意ください。そっちのスキル身につけるのは楽しいかもしれませんが、本筋ではありません。 ※ここでいう「初級魔法」はラノベ読まない人の想像する初級魔法ではないことがほとんどなのでご注意を 特定のプログラミングスキルを身につけると、派生スキルが勝手にポコポコ生えてきたり、派生スキルの習得コストが圧倒的に安くなります。 たとえば、なにか一つのプログラミング言語をマスターした人なら、他のプログラミング言語を覚えるときのコストが低くなるというのは直感的

                                                                  プログラミングスクール通うくらいならチートスキル身につけたほうが百億倍楽やぞ|erukiti
                                                                • QiitaやZennよりも便利? IPAの資料を読もう!

                                                                  はじめに 飲み物じゃないIPAをご存じでしょうか? 漢字でいうと、独立行政法人 情報処理推進機構ですね。情報処理技術者試験を実施いる謎の組織という認識の方も多いと思います。 実はIPAはいろんなドキュメントを公開していてQiitaやZenn以上にお役立ちなサイトなのです。 まあ、AWSをどうこうとか、FireabaseやNext.jsのようなキラキラした奴は基本載ってないので特に代替えするものではないですが、ブログとかはまた種類の違った情報があるので個人的には結構使うことあります。しかも 「日本語」! こういう感じの事をTwitterでつぶやいたところ意外にイイねをされたので、せっかくだしどんなドキュメントがあるかちょっと紹介したいと思います。 セキュリティ関連NIST文書 まずはNISTドキュメントの翻訳版! これは良いですよね。NISTはアメリカの米国国立標準技術研究所で、セキュリティ

                                                                    QiitaやZennよりも便利? IPAの資料を読もう!
                                                                  • 『失敗の責任は私にあります』と言えない責任者たちの話。

                                                                    昔、あるメーカーで経営企画職を担当していた時のことだ。 営業部の部長から、 「ウチの商品が絶対に安心で安全という証明書って発行できませんかね・・・」 と相談を受けたことがある。 聞けば、大口顧客との取引が受注寸前で、最後にそのような証明書を出せれば契約してもいいと言われているようだ。 しかし仕様書や保証書ならともかく、絶対に安心安全な証明書などどうしろというのか。 安心安全に使えるガスボンベだって火の中に放り込んだら爆発するし、腹痛を治してくれる胃薬でも用法・用量を守らなければ命に関わる。 どういうものを書いてよいのかわからず、先方ともう少し要件を詰めて欲しいと押し返すと、 「絶対安心安全の証明が要件なんですよ・・・」 と埒が明かない。 やむを得ず、一度部長に同行し先方の会社を訪れ、どのような証明を求めているのかをヒアリングすることにした。 応対に出てくれたのは、若い現場主任だ。 熱気と熱

                                                                      『失敗の責任は私にあります』と言えない責任者たちの話。