並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1106件

新着順 人気順

運用保守の検索結果1 - 40 件 / 1106件

  • 見積・提案書に書いておくと不幸を減らせる前提条件

    はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません(うろ覚えで書いてたり、大人の事情) これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる

      見積・提案書に書いておくと不幸を減らせる前提条件
    • 【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画

      「chatgptを使って要件定義の工数を削減したい」 「そもそもchatgptを使って質の高い要件定義ができるのだろうか」 とお悩みなのではないだろうか。 結論、chatgptで質の高い要件定義を短時間で実現することは可能だ。 実際に私もchatgptを使って下記のような要件定義書を完成させた。 通常この要件定義書を0から自力で作ろうと思うと40時間はかかるが、chatgptを使う事によって4時間で完成させることができた。 しかし、ただプロンプトをなんとな投げ掛ければ良いというわけではない。 目的を達成するために綿密に設計をしたプロンプトを投げかける必要がある。 また、要件定義の中でも ・chatgptに丸投げして良いところ ・自分で手直しをした方が良いところ を精査することも大切だ そこで今回は上記のような要件定義書を4時間で完成させるために、私がchatgptへ投げかけたプロンプトを全

        【テンプレ付】chatgptを使ってツールの要件定義をしたら工数が40時間→4時間になった - みんなのシステム企画
      • プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0

        TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案(やってよかったこと) 1stスクリーニング(やってよかったこと) コミュニケーション チームへのリスペクト(やってよかったこと) 話す <<< 聞く(改善余地あり) 即決する(やってよかったこと) 自分で各論まで見る(やってよかったこと) 発散→収束でディスカッション(改善余地あり) イラストで話す(改善余地あり) 日次ミーティング(やってよかったこと) 議事録を書く(改善余地あり) 得た情報を共有する(改善余地あり) 想定納期を示す(改善余地あり) カレンダー招待&日程確約コメントを転記(改善余地あり) プロセス管理 仮説

          プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
        • プロジェクトリーダーというお仕事 - Qiita

          概要 そろそろ年度末だし、新年度からプロジェクトリーダーとしてやっていく人もいるかと思うので、プロジェクトリーダーはどういうことをしないといけないかと、心得的なものを投稿しようと思います。今業界全体的にリーダー不足になってるんで、プロジェクトリーダーという役割について興味持ってくれる人が増えると嬉しいです。 ※ここでのプロジェクトとはシステム開発等IT関連のプロジェクトを指すものとします。 軽く自己紹介 2013年頃から7年くらいプロジェクトリーダーとして請負業務などの仕事をしてきました。最近はプロジェクトマネージャーも兼ねてやっていたり、うまくいっていないプロジェクトにコンサルとして入って立て直すというようなこともしています。 レジュメ https://www.resume.id/branch まずは結論から プロジェクトリーダーの使命 「担当するプロジェクトを成功へと導く」 「プロジェ

            プロジェクトリーダーというお仕事 - Qiita
          • Amazon VPCを「これでもか!」というくらい丁寧に解説 - Qiita

            はじめに AWS上で仮想ネットワークを構築できるAmazon VPCは、多くのAWSサービスが動作する基盤となる、非常に重要かつ多機能なサービスです。 多機能ゆえに公式ドキュメントやネット上の記事も断片的な機能の解説が多く、全体像を把握することが難しいサービスとも言えます。 そこで本記事はVPCの全体像を理解できるよう、各機能のつながりや動作原理を丁寧に解説し、 「VPC界の百科事典」 (あくまで例えですが…笑) となるような記事を目指したいと思います。 【追記】 実践編の記事を追加しました VPCの実画面での構築方法は、以下の別記事にまとめました。「VPCを実際に触ってみたい!」という方は、こちらもご一読いただけると嬉しいです。 VPCとは 「Virtual Private Cloud」の略で、クラウド上に仮想的なネットワークを構築するためのサービスです。 例えば、オンプレ環境でWebア

              Amazon VPCを「これでもか!」というくらい丁寧に解説 - Qiita
            • 接触確認アプリCOCOAからの教訓|情報処理学会・学会誌「情報処理」

              楠 正憲(内閣官房 政府CIO 補佐官) 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた.筆者は 2020年4月から接触確認アプリの導入について,有志での議論に参加し,有識者会議のメンバとして,また途中から政府CIO補佐官として, 接触確認アプリの導入を支援してきた.本稿では接触確認アプリCOCOAの開発と運用について,どのような課題があったかについて振り返る. 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年(2020年)3月頃のことである.ちょうどシンガポールのTrace Togetherが話題となって,日本でも接触確認アプリをリリースできないかといった話題で,いくつかのコミュニティが盛り上がり始めた. Androidのシェアが高いシンガポールに対して,日本ではiPhoneのシェアが非常に高く,iP

                接触確認アプリCOCOAからの教訓|情報処理学会・学会誌「情報処理」
              • 社内ドキュメントはなぜ更新されないのか?情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog

                はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた

                  社内ドキュメントはなぜ更新されないのか?情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
                • 文化シヤッターのシステム開発頓挫で、日本IBMが19.8億円の賠償を命ぜられた理由

                  システム開発の頓挫を巡る、文化シヤッターと日本IBMとの間の裁判で、東京地方裁判所は日本IBM側に19億8000万円の支払いを命じた。米セールスフォースのPaaSを用いた販売管理システムの構築を目指し、2015年に始めた開発プロジェクトだったが、2017年にストップしていた。東京地裁は開発失敗の原因をどう認定したのか。裁判記録をもとに読み解く。 文化シヤッターが、20年以上前から使用していた販売管理システムを刷新するプロジェクトを本格的に始動させたのは2015年1月のことだ。日本IBMに提案依頼書(RFP)の作成を委託。そのRFPを基に複数ベンダーから提案を受けた上で、日本IBMを開発委託先として選定した。 日本IBMの提案はシステム構築に米セールスフォースのPaaS(プラットフォーム・アズ・ア・サービス)である「Salesforce1 Platform」を用いるものだった。RFPでは標準

                    文化シヤッターのシステム開発頓挫で、日本IBMが19.8億円の賠償を命ぜられた理由
                  • Webデザイン100トレース | Hypertext Candy

                    こんにちわ!最近はフロント開発も担当させていただいてます、Yamamotoです。 今回はエンジニアがデザインを学ぶべく、100のWebサイトのデザイントレースをして、学んだことをまとめてみました。 エンジニアまたは未経験だけど、Webデザインにも興味があるという方の、何かのきっかけになれば幸いです。 目次 なぜ Webデザインを学ぼうと思ったのか デザイントレースについて 100トレースして学んだこと なぜWebデザインを学ぼうと思ったのか ざっくりですが、実務を行いながら以下のように思うことがありました。 細部のデザイン指示がなく、開発の手が止まってしまう どう実装するか目線の発想・提案しか浮かばない 綺麗なコードだけではなく、視野を広げてより良いものを作りたい などなど... デザイナーとエンジニアの業務は差別化されてはいますが、互いに近接し交わる部分も多くあります。そんな中で、業務効

                      Webデザイン100トレース | Hypertext Candy
                    • 未経験から1ヶ月でWeb系企業に就職する勉強法

                      取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。 重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。 逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、(基礎的な部分を)調べながら使うようではエンジニア失格ということ。 基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。 以下に挙げた技術(①⑤⑥は他の言語やフレームワークで代替可能)が身に付いていなければまともな企業に就職することは難しい(もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが)。 経験者でも、これらができない/わからないのは、相当恥ずかしいことだ

                        未経験から1ヶ月でWeb系企業に就職する勉強法
                      • クラウドエンジニア(AWS)ロードマップ2021 - Qiita

                        お知らせ 2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル:AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス

                          クラウドエンジニア(AWS)ロードマップ2021 - Qiita
                        • 専門職と視座

                          こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。 大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座!視座!」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。 私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するというこ

                            専門職と視座
                          • 日米OSDN離合集散、苦闘の21年史

                            さて、ついに退職エントリだ。私は米国のオープンソース・ムーブメントを日本で再現するためのコアを作るために民間企業へやってきたはずだった。それから21年、随分と長い航海になってしまったが、結局様々な尻拭いを続けてきたという感慨ばかりが起きてくる。一つの歴史として書き残すいいタイミングなのでその苦闘を振り返っておこう。 なお、長く付き合いが続いてしまう米国側法人は下記のように名称が変化している。なるべく頭に米国と付けて日本側法人と区別しやすいように記述するが、突然名称が変わったりするので注意してほしい。多くがもはや消滅した法人のことなので、さすがに一気読みするような酔狂な人はほぼいないと思うが。 VA Research      Andover.net ↓         ↙︎ (VAによる買収) VA Linux Systems ↓        ↘︎ (Andoverから社名変更) VA

                              日米OSDN離合集散、苦闘の21年史
                            • プログラマと出世 - megamouthの葬列

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

                              • 見たいエンジニアの職務経歴書の書き方 - Qiita

                                前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから5年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは?と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた観点での話になります。 今回もWeb系の大手企業に入る観点での職務経歴書という前提が付くかもしれません。 しばしば見る、情報が足りない職務経歴書 採用を決めるマネージャがエンジニアでない場合や技術の深さに疎い場合、技術に関してそれなりの評価しか出来ません。

                                  見たいエンジニアの職務経歴書の書き方 - Qiita
                                • Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"

                                  COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k

                                    Masanori Kusunoki / 楠 正憲 on Twitter: "COCOAは途中まで私たち補佐官も入っていたので、決して運用保守を軽視したつもりはなかったのですが、EN API自体のプライバシー哲学に沿おうとすると既存のデバッグ用ツールがほぼ使えなくなってしまったのと、EN APIの更新がスマ… https://t.co/iQ5kltAo9k"
                                  • クラスメソッド、技術情報共有サービス「Zenn」の買収に関する契約を締結〜誰かのために、自分のために知見を共有するプラットフォームの開発を加速〜 | クラスメソッド株式会社

                                    クラスメソッドのAWS総合支援 コスト最適化からセキュリティ、構築支援、運用保守まで、AWS活用を支援します。

                                      クラスメソッド、技術情報共有サービス「Zenn」の買収に関する契約を締結〜誰かのために、自分のために知見を共有するプラットフォームの開発を加速〜 | クラスメソッド株式会社
                                    • エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ

                                      みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識/運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ

                                        エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
                                      • エンジニア職に就いたあと辞めたポエム

                                        補足→ https://anond.hatelabo.jp/20191205212350 これは退職者アドベントカレンダー2019 (https://adventar.org/calendars/4051) 5日目の記事です。最初は自分のブログに書くつもりでしたが、書いてるうちにどこまで筆が滑っているのかわからなくなったので増田に投げることしました。そしたら余計にタガが外れたのはご愛嬌。 What's thisよく見かける「未経験からエンジニアへ!」ストーリーの、あまりなさそうなルートです。よくあるルートのほうはなぜかTwitterで報告して「○○系エンジニア」的な命名をしてから入社その後の動向が闇に葬られているのをかなりの確度で見かけますが、まあ、なんか、いろいろあるんでしょう。逆にそういう成功(?)体験の生存バイアスを強化する情報ばかりあふれていると情報として健全でないように感じます。

                                          エンジニア職に就いたあと辞めたポエム
                                        • NTTビジネスソリューションズ元派遣社員による顧客情報の不正な持ち出しについてまとめてみた - piyolog

                                          2023年10月17日、NTTビジネスソリューションズは同社の元派遣社員が顧客情報の不正な持ち出しを行っていたと公表しました。持ち出された顧客情報はコールセンターのシステムに保存されていたもので、元派遣社員は2013年より不正な行為を及んでいたとみられています。ここでは関連する情報をまとめます。 10年近く前から顧客情報を不正に持ち出し 不正な行為を行っていたのはNTTビジネスソリューションズに2008年6月より派遣されていた元派遣社員(公表時点で派遣会社から退職済)で、コールセンターシステムの運用保守管理を担当していた。10年間で100回以上にわたって不正な取得行為を行っていた。*1 NTTビジネスソリューションズはNTTマーケティングアクトProCXが利用していたコールセンターシステムのシステム運用を行っており、元派遣社員によって不正に持ち出されていた情報はNTTマーケティングアクトP

                                            NTTビジネスソリューションズ元派遣社員による顧客情報の不正な持ち出しについてまとめてみた - piyolog
                                          • 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ | コーソルDatabaseエンジニアのBlog

                                            Microsoft SQL ServerMySQLOracle DatabasePostgreSQLSolarWinds DPAデータベース運用主要RDBMS製品の比較 2022.09.01 渡部 亮太 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ Oracle ACE Proの渡部です。 主要なRDBMS製品についてアーキテクチャを比較します。 大枠を整理することが最大の目的です。細かい例外事項や拡張機能は適宜記載を割愛しています。 2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。 時間ができた時に随時追記予定です。 もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot

                                            • Webサイト制作の要件定義書の確認項目|重松佑 / Shhh inc.

                                              プロジェクトのキックオフ前後に作成する要件定義書。確認の抜け漏れを最小限に抑えるには、どのようなことを記載しておくべきか。そして、メンバーへのスムーズな共有と、その後の円滑なプロジェクト進行のための、良い要件定義書とはどのようなものだろう。自分たち用のメモも兼ねて「Webサイト制作プロジェクトの要件定義書」の確認項目をnoteに整理してみます。 1. プロジェクト概要1-1. 背景プロジェクトを発案するに至った背景です。現状の課題、ビジネス要件の変化、ユーザーの変化、社会的要請など、プロジェクトの存在意義や必要性を記載します。 1-2. ゴールゴールとは「完了条件」です。何を達成すれば終わるのか、どこに行けば終わるのかを記載します。通常は5W1Hのうち、WHATやWHEREをゴールとします。 1-3. 目的プロジェクトを何のために進めるのかという意図です。ゴールよりも広い視野で捉えます。5

                                                Webサイト制作の要件定義書の確認項目|重松佑 / Shhh inc.
                                              • クラウドシステム構築時に活用できる非機能要件チェックリストを公開しました | クラスメソッド株式会社

                                                クラスメソッドのAWS総合支援 コスト最適化からセキュリティ、構築支援、運用保守まで、AWS活用を支援します。

                                                  クラウドシステム構築時に活用できる非機能要件チェックリストを公開しました | クラスメソッド株式会社
                                                • 【Web】知っておきたいWebエンジニアリング各分野の基礎知見80

                                                  この記事は? それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W

                                                    【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
                                                  • スプリント1を始める前にどんな準備をするか

                                                    みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい

                                                      スプリント1を始める前にどんな準備をするか
                                                    • 運用・保守 インフラエンジニアの時によく使ってたLinuxコマンド - Qiita

                                                      概要 Linuxのコマンドって多種多様にあるけど、 どういうのを知ってたら良いのかという情報があんまり無いなと思ったので、 インフラエンジニアで運用と保守を経験してよく使うコマンドと、どういう時に使ってたかを書いて行こうと思います。 注意 Linuxのディストリビューション(種類)はRHEL、CentOSです。他のディストリビューションだとパスが違ったり使えないコマンドだったりするのでご留意ください。多分そんなに多く無いはず。。 オプションとかは基本書いてないので、内容読んで興味あれば調べてみてください。需要あれば実行例もあげますが。。 運用・保守でよく使ってたLinuxコマンド 指定したパスにあるファイル、ディレクトリを拡張子 .tar.gz で一つにまとめられます。 あとは解凍も出来ます。zipみたいなもんです。Linuxサーバで取得した情報をひとまとめにしてローカルに持ってくるという

                                                        運用・保守 インフラエンジニアの時によく使ってたLinuxコマンド - Qiita
                                                      • テストの自動化とテスト駆動開発

                                                        組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい: ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのかたに向け、 ・テスト自動化が自分たちのメリットになると納得してもらい、 ・その道筋として2つのアプローチを紹介して、 - テスト駆動開発 - ペアプログラミング ・組織的・長期的に取り組む価値を感じてもらう アジェンダ: 1.自動化したい理由 2.必要な人材を考える 3.テスト自動化の端緒 ~テスト駆動開発について~ 4.深めつつ広げる鍵 ~ペアプログラミングについて~ 5.見る夢について

                                                          テストの自動化とテスト駆動開発
                                                        • オリンピック・パラリンピック関係システムの調達に関する私の発言につきまして “English as follow.” | 平井卓也[ひらいたくや] デジタル改革担当大臣 自民党 衆議院議員

                                                          オリンピック・パラリンピック関係システムの調達に関する私の発言につきまして “English as follow.” 一部の報道で政府のシステム調達に関する私の発言が問題だと指摘がありました。 私は、かねてより政府のシステム調達に関して大きな問題意識を持っており、国民の血税をお預かりする立場として、国民に説明ができる調達しかしないという強い気持ちと覚悟を持っております。 私自身は、直接事業者との交渉に臨む立場ではありませんが、今回の契約の見直しに際しても、必要な機能に見合った契約金額の圧縮となるよう、担当責任者には詳細に検討を行うよう強く指示してきました。 報道されている音声データにつきましては、契約見直しに当たっての自分の考えを、10年来一緒に仕事をして来て自分の真意が分かる幹部職員へ対面で檄を飛ばしたものであり、事業者への脅しでは決してありません。しかし、幹部職員に対する発言だったとし

                                                            オリンピック・パラリンピック関係システムの調達に関する私の発言につきまして “English as follow.” | 平井卓也[ひらいたくや] デジタル改革担当大臣 自民党 衆議院議員
                                                          • Webフルスタックエンジニアになるためのチェックリスト

                                                            Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという

                                                              Webフルスタックエンジニアになるためのチェックリスト
                                                            • テストコード導入奮闘記~私はこうやってプロジェクトにテストコードを導入しました~ - Qiita

                                                              導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね?しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ?

                                                                テストコード導入奮闘記~私はこうやってプロジェクトにテストコードを導入しました~ - Qiita
                                                              • 【初心者必見】プログラミング未経験から3年間のPython学習ロードマップ完全版 - 仮想サーファーの日常

                                                                近年、Pythonの求人数・案件数が増加すると同時に単価も上がってきており、エンジニアの中で人気が高まっています。 これからプログラミング言語Pythonを学んで、Webアプリケーション開発エンジニアや機械学習エンジニアになりたいと思っている方も多いのではないでしょうか。 この記事では以下のような方向けに、Pythonを未経験からどのような手順で学びPythonエンジニアになるのか、またPythonエンジニアになった後にどのように学び続けていけばいいのか、具体的な方法をまとめています。 この記事の対象読者 エンジニアではないけど、未経験からPythonエンジニアに転職したい方 エンジニアではないけど、未経験からPythonでデータ分析や業務効率化をしたい方 非Web系の会社で働いているけど、Web系のPythonエンジニアに転職したい方 Pythonとは Pythonとは何か Python

                                                                  【初心者必見】プログラミング未経験から3年間のPython学習ロードマップ完全版 - 仮想サーファーの日常
                                                                • 【書評】「インフラ設計のセオリー」新人インフラエンジニアが押さえておくべき内容が詰まった一冊 | DevelopersIO

                                                                  「難しい本ばっかり読んで眠くなってませんか?いい本ありますよ!」 ご機嫌いかがでしょうか、豊崎です。 育成チームのリーダーを行なっている都合から、エントリー向けのインフラエンジニアの書籍を読むことが多くなっています。本日は、その中で読んだ、「インフラ設計のセオリー」という本についてご紹介させていただきます。 基本的にはIPAの非機能要求グレードに沿って特に重要な項目を説明していく内容になっています。 インフラエンジニアを始めるときに、教科書として読んでおけば 成長曲線が変わったんじゃないかな? と感じました。それくらい基礎的な知識の習得とイメージ付けには最適だと思います。 具体的には、非常に有益なドキュメントではあるものの、圧倒的な文章量で睡魔を送り込んでくる非機能要求グレードの活用について図や絵を多く交えて非常に理解しやすい文章で説明をしてくれます。 内容はしっかりしているのに、とても読

                                                                    【書評】「インフラ設計のセオリー」新人インフラエンジニアが押さえておくべき内容が詰まった一冊 | DevelopersIO
                                                                  • ITフリーランスを対象とした国の労災保険「特別加入制度」が今日からスタート。フリーランスでも通勤や仕事によるケガ、病気、障害、死亡など補償

                                                                    フリーランスのプログラマやWebデザイナーなどの、いわゆるITフリーランスが通勤や仕事で被ったケガや病気、障害、死亡などに対して補償が行われる、国による労災保険の特別加入の対象拡大が今日、2021年9月1日からスタートしました。 労災保険とは、通勤や仕事において被るケガや病気、障害、死亡に対して、治療費などの療養費、休業する際の休業期間の給付、治療後に障害が残った場合の給付、死亡した場合の遺族への給付などを行うもので、国が管掌しています。病気やケガの際の医療費を一部負担する社会保険(健康保険)や国民健康保険などの国民皆保険制度とは別の制度です。 労災保険は、労働者を一人でも雇用する会社には労働者災害補償保険法によって加入が義務付けられており、保険料の全額を会社が負担することになっています。つまり、会社員やアルバイト、パートなど会社に雇用されている立場である労働者は、自動的に労災保険の対象と

                                                                      ITフリーランスを対象とした国の労災保険「特別加入制度」が今日からスタート。フリーランスでも通勤や仕事によるケガ、病気、障害、死亡など補償
                                                                    • 五輪観客用“オリ観アプリ”のデタラメ 血税73億円垂れ流し|日刊ゲンダイDIGITAL

                                                                      東京五輪開催が危ぶまれる中、観客向けの専用アプリ開発が進められている。五輪がポシャった場合の転用はビミョーで、巨額の税金をドブに捨てる可能性が出てきた。 問題のアプリは、内閣官房が調達を進める「オリンピック・パラリンピック観客等向けアプリ(仮称)」(オリ観アプリ)だ。観客受け入れに関する検討が昨年11月ごろから本格化したのを受け、感染防止を目的として今年1月から開発が始まった。海外からのアスリートや大会関係者、観客ら120万人の利用を想定しているという。 ア然とするのは、その開発費用だ。運用・保守もあわせ、総額73億円。新型コロナウイルス感染者との接触を通知するアプリ「COCOA」の開発費が約4億円だから、その20倍近い血税がつぎ込まれているのだ。 費用は妥当なのか。有用性は担保されているのか。内閣官房に問い合わせたが、「担当者不在のため答えられない」(IT総合戦略室)と、ケンもホロロ。

                                                                        五輪観客用“オリ観アプリ”のデタラメ 血税73億円垂れ流し|日刊ゲンダイDIGITAL
                                                                      • なぜオフショア開発でベトナムがひとり勝ちしているのか?

                                                                        あなたは今、オフショアを検討しているが、様々な国の選択肢がある中で、なぜ「ベトナム」というワードをよく聞くのか気になっているところではないでしょうか。まず大前提として「ベトナム」を第一候補として取り上げるのは間違いないと言えるでしょう。 それではなぜ、ベトナムを第一候補として取り上げて良いのか?まさに、ベトナムにオフショア拠点としてラボを開設してから10年経ち、東建コーポレーション様やカインズ様といった誰でも耳にしたことあるような会社との取引を多数実績として持っている会社に所属している私がその背景とともに、ベトナムの魅力を紹介したいと思います。 そして、ベトナムに魅力を感じていただいたうえで、ベトナムの会社選びのポイントや開発を進めていく上で気を付けておきたいポイントを併せて紹介いたします。 1.なぜベトナム?オフショアでベトナムがひとり勝ちしている理由 オフショアといえばベトナムと言われ

                                                                        • ゼロトラストアーキテクチャ 適用方針

                                                                          ゼロトラストアーキテクチャ 適用方針 2022 年(令和 4 年)6 月 30 日 デジタル庁 〔標準ガイドライン群ID〕 DS-210 〔キーワード〕 ゼロトラスト、ゼロトラストアーキテクチャ、 〔概要〕 政府情報システムのシステム方式について、より堅牢なシステム構築の観 点からゼロトラストアーキテクチャの適用方針を示す。 改定履歴 改定年月日 改定箇所 改定内容 2022年6月30日 初版決定 i 目次 1 はじめに ......................................................... 1 1.1 背景と目的 .................................................. 1 1.2 適用対象 .................................................... 1

                                                                          • そろそろSQLのウィンドウ関数を理解したい - 連載1/3話 - Qiita

                                                                            はじめに データ分析とデータ品質改善に従事してきた筆者が、SQLを用いた分析の基本である「ウィンドウ関数」の使い方とデータ品質の調査改善を行う手法をまとめてみようと思います。 こちらの記事は、SQLの知識向上と振り返りを主題としているので、ABC分析、バスケット分析、RFM分析などの「データ分析の手法」について説明している記事ではありません。(反響やコメントによって別投稿するかもしれません) 背景 SQLはエンジニアの大多数が利用しており、多くの方はWebサービス開発などでデータの登録画面や検索画面を作る際にSQLを利用したり、またはシステムの運用保守で障害の原因調査のためにSQLを利用して原因を特定すると思います。そのため、テーブル結合・サブクエリ・集計関数といったSQL構文は理解されている人が多いと思いますが、分析関数を理解して使っている人となると、ぐっと減ると思います。 私は以前、社

                                                                              そろそろSQLのウィンドウ関数を理解したい - 連載1/3話 - Qiita
                                                                            • マイクロソフト、「Azure Cosmos DB」がずっと無料で使える「Free Tier」を発表。地球規模の分散データベースを最大5GBまで

                                                                              マイクロソフト、「Azure Cosmos DB」がずっと無料で使える「Free Tier」を発表。地球規模の分散データベースを最大5GBまで マイクロソフトは、分散NoSQLデータベース「Azure Cosmos DB」が期限なく無料で使える「Free Tier」を発表しました。 Activate Free Tier on a new #azurecosmosdb account to get 400 RU/s throughput and 5 GBs storage free each month, for the life of your account. What will you build? #appdev #nosql https://t.co/BmfoWyYcbW — Azure Cosmos DB (@AzureCosmosDB) March 7, 2020 Azure

                                                                                マイクロソフト、「Azure Cosmos DB」がずっと無料で使える「Free Tier」を発表。地球規模の分散データベースを最大5GBまで
                                                                              • RDBMS in Action

                                                                                RDBMS 理解度の壁: プロダクションや運用保守で困らないシステムを作れる知識 <<<それっぽく動くものを作れる知識 実際のシステムで遭遇・見聞きした事象をもとに、上記のスキマにある各種 RDBMS 知識を説明します。 RDBMS 本体の運用よりも、現実のアプリケーションにおける設計・実装上のハマリどころが中心。

                                                                                  RDBMS in Action
                                                                                • チケットの書き方 - Qiita

                                                                                  メンバーの一部がスムーズに情報共有できるチケットを書けず 苦戦しており、相談を受けた時に色々言った内容を 書き起こしたもの。 荒いけど誰かの参考になるかもしれないので共有。 2019/09/07 宣伝追記 技術書典サークル参加します。 チーム運営どう考えて何をやったかまとめた本とセキュリティの 入門書を頒布するので気になった方は是非。 https://techbookfest.org/event/tbf07/circle/5671044488626176 書いた人の環境 業務ツールとしてチャット、Redmine、Wikiを使用。 チャットで会話して相談・整理・調整する。 タスク、課題はチケット化して管理。 ナレッジはWikiに書いて共有。 業務内容はシステム開発と運用保守でソフトウェア開発ではない。 Redmineはタスク・課題管理に使用。 以下、メンバーに伝えたことを清書したもの。 前提

                                                                                    チケットの書き方 - Qiita