howto-tech-docs.md 技術文書の書き方 このメモは、私(@ymmt2005)が長年にわたってソフトウェアプロダクト開発に関わってきて 2022年現在こうしたほうが良いと考えているベストプラクティスです。 科学的な分析等に基づくわけではない経験則であるため、今後も随時見直すことがありますし、 ここに書いてあることが常に正しいわけでもあらゆるソフトウェア開発に適するわけでもありません。 しかしながら、実務経験が豊富で、モダンな技術スタックに明るいエンジニアの経験則は一定の 役に立つのではないかと考えて記します。 技術文書とは ここでは、ソフトウェア開発で技術者が書くべき文書ということにします。 ソフトウェアエンジニアにも役割がいろいろあり、アーキテクトと independent contributor では書く文書が違うということはあるでしょうけれど、ここではごっちゃにします。
ソフトウェア開発者でなくとも、セキュリティ・バイ・デザインという言葉は聞いたことがあると思います。しかし、セキュリティ・バイ・デザインが十分に実施できていると言える組織は多くないのではないでしょうか。 いざセキュリティ・バイ・デザインを実施しようとしても「何をすればよいのだろう?」「どうやれば良いのだろう?」となかなか手が動かない。そんな状況の一助となるよう、我々がセキュリティ・バイ・デザインを学び、実践した内容を文書化し公開する運びとしました。 セキュリティ初心者でも読みやすいように、以下の特徴を念頭において本書を執筆しました。 軽快な文章 図表を多用したグラフィカルな見た目 キャラクターのセリフに共感しながら理解ができる 1章 セキュリティ・バイ・デザイン -セキュリティ・バイ・デザインの概要や必要性の説明 2章 脅威分析 -組織やシステムに対する脅威分析の実施方法 3章 セキュリティ
はじめに ちょっとつぶやいたら思いのほか需要がありそうだったので、簡単にまとめておきます。 おことわり これを書いておけば、すべての不幸を避けられるというものではありません 提出先との関係性次第では、書かないほうがいいこともあるかも 私自身が普段提案している内容が、すべて記載されているわけでもありません(うろ覚えで書いてたり、大人の事情) これを流用しておこったすべての事項について、何らかの責任をとることはできません 本稿では請負による開発を想定しています でも共有することで、この業界の不幸が減ればいいなということでつらつら書いてみます。 他にもあるようなら、Twitterなりコメントなりで提案してもらえると嬉しいです。 前提条件を書く目的 見積・提案書通りに、実施するために必要な条件を明確にする 条件を逸脱したときに、どうなるのかハッキリさせる 上記は概ねつぎのとおり 実現が不可能になる
7月をもってVPoEを退任しますiCAREでVPoEをしております安田です。 私は2020年7月よりiCAREのVPoEを努めてまいりましたが、今年7月をもって、VPoEを退任し、後任の方に役職をお譲りします。後任は未定で社内外に広く募集をかけているところです。(求人情報は記事下部をご覧ください) なお、退任後ですが、iCAREにおいて新たな役割を担い、組織としても個人としても新たな挑戦、冒険に乗り出す予定です。その詳細についてはまた別の機会にご紹介したいと考えております。 なぜ退任するのか?についてはこの新たな挑戦の話抜きには語れませんので、今日はiCAREでのVPoEとしての取り組みについて振り返りつつ、後を継いでくださる方に向けて、このVPoEという仕事の魅力、iCAREの開発組織の魅力、そして今抱えている課題についてお話してみたいと思います。 開発組織の拡大、成長上述しましたとおり
A closed platform, walled garden, or closed ecosystem[1][2] is a software system wherein the carrier or service provider has control over applications, content, and/or media, and restricts convenient access to non-approved applicants or content. This is in contrast to an open platform, wherein consumers generally have unrestricted access to applications and content. Overview[edit] For example, in
「日本のエンジニアは不足しているというけれど本当? その原因は?」 「わが社でもエンジニアが不足していて困っている、何かよい解決法はないか?」 いまこの記事を読んでいる方は、そのような疑問や悩みを持っているのではないでしょうか? 「エンジニア不足というのはウソだ」と主張する向きもありますが、実際にデータを見ると確実にエンジニアは不足しています。 2018年時点の調査で22万人、このままいけば最悪の場合は2030年時点で79万人が不足すると予想されているのです。 原因として考えられるのは以下のようなことです。 ・IT市場が急成長している ・技術革新のスピードが速い ・エンジニアの高齢化が進んでいる ・IT業界の労働環境がよくない そして、この解決のために企業がとれる対策としては、以下が挙げられます。 ・エンジニアの待遇を改善する ・社内で人材を育成する ・海外人材を活用する そこでこの記事で
Learn about Moodle's products, like Moodle LMS or Moodle Worplace, or find a Moodle Certified Service Provider. Moodle.com Our social network to share and curate open educational resources. MoodleNet Courses and programs to develop your skills as a Moodle educator, administrator, designer or developer. Moodle Academy Moodle.com Learn about Moodle's products, like Moodle LMS or Moodle Worplace, or
会社から支給されたPCがショボい。 メモリ8GB、ウン世代前のcore i5、フルHD以下のディスプレイ。 贅沢言うなよ、もっと酷いのごまんとあるよ、という感想は全くもってその通りで、「使えなくもない」スペックだからこそ上司に訴えても適当にあしらわれた。 ・3人以上のリモート会議をすると動作がカクつくが「使えなくもない」 ・ディスプレイの解像度が低く視野角も狭く暗いが「使えなくもない」 ・4K出力はできないが「使えなくもない」 ・重いし熱いし電池持ちも悪いが「使えなくもない」 Twitterでまれにみる起動に10分かかるみたいな酷さではないけど、こういったストレスは毎日蓄積されて精神的疲労に繋がる。 自分はエンジニアだから、PCは自分の手足のように使っている。 手枷足枷が付けられた状態で仕事は出来なくもないが、それは中長期的に見て好ましいものであろうか? コストの話をすれば、20万のPCが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く