はてなブックマーク

先日以下のイベントにお声がけいただき、LT登壇をさせていただきました。 今回はエンジニアリングマネジメントという括りでもあり、我々ARIで行っている若手技術者育成の取組みをご紹介させていただきました。 登壇資料はこちらで公開しておりますが、サマリーや補足用にこちらの記事を用意しました。 我々が目指す理想の技術者像 ずばり「事業をエンジニアリングできる技術者」です。 ベストセラーとなった「事業をエンジニアリングする技術者たち」で紹介されている「フルサイクルエンジニア」の概念がまさに理想像です。 引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 事業ドメインに関心を持ち、社会や顧客の課題を解決できること。 技術をビジネス価値を変換できる力の高い技術者を理想とし、そうした技術者を多く輩出できる組織を目指しています。 ち

はじめに 最近こちらの本を読みました。 改訂改題前の「Engineers in VOYAGE」から厚みを増した本作。既存の各章ごとに「その後」が追加されたり、新しい章も加筆されるなど大幅な改訂になっています。前作は「ITエンジニア本大賞2021年」の「技術書部門大賞」を受賞した作品ですので、ご存じの方も多いと思います。 私も改訂版を改めて手に取らせてもらい、前作部分も含めて再読しました。自身の環境変化の影響か、今だからこそ刺さる部分もありました。世間の評価に違わず、エンジニアのみならずソフトウェアに関連する事業に関わる方に、広くお薦めしたい一冊であることは間違いありません。 さて、私が思うこの書籍の魅力は、その解説記事と丁寧な脚注にあると言っても過言ではありません。その解説により、生々しいインタビューの事象が抽象化され、読者が自身の環境に適用しやすくなっています。 今回本書を読むにあたり、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? » Python実践データ分析100本ノック | 下山輝昌, 松田雄馬, 三木孝行 はじめに この本を手にした動機 元々データ分析に以前から興味があったものの、次に繋げられなかった 非エンジニアがR言語を始めるときの手引き｜Kaggle Masterによるデータ分析技術者養成講座【R言語版】Day1メモ｜中野ヤスオ｜ARI ｜note 2021年10月から12月まで受講した初級Python講座で得たことをなにか繋げたかった 講座受講の経緯等こちら：若手エンジニア成長支援No1企業を目指して｜中野ヤスオ｜ARI ｜note コードを書くこ

はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが

はじめに 仕事の品質を高める上で、知見のある方にレビューをしてもらうプロセスは欠かせません。 ただこのレビュー、やり方や意見の伝え方によっては、期待した効果が得られなかったり、ネガティブな効果を生み出しかねません。そうした結果、レビューという行為自体が開催されにくくなることは、チームにとって非常にマイナスです。 全員のレビューへの期待を整えておくために、レビューの心構えや望ましい運営方法などを、レビューに関わる全ての人が共通認識化しておくことは、非常に重要だと考えています。 今回、このレビューを効果的に進めるポイントをまとめた、とても良い資料を見つけたのでご紹介します。 レビュープロセス - AWS Well-Architected フレームワーク この資料をおすすめしたい方 エンジニアに限らず、仕事で他者の成果物をレビューをする人、および他者からレビューを受ける人（そう考えると、仕事をす

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #これって何？ 政府CIOとは、内閣から任命され日本行政のシステム全体を統括する「日本政府のCIO」です。この政府CIOをサポートするのが各省庁を担当する50名近い政府CIO補佐官からなる政府CIOチームです。（組織としては、内閣官房　情報通信技術（ＩＴ）総合戦略室というようです） この政府CIOチームがとりまとめた政府職員向けのIT調達とシステム導入に関する標準が「デジタル・ガバメント推進標準ガイドライン」です。 このガイドラインは「本編」「解説書」「実践ガイド」の3点構成になっています。 中でも今日ご紹介したいのが上図一番右の**「

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習し

はじめに エンジニアにとって、仕様書などの技術的な文章を書くこと（テクニカルライティングとも言います）は避けて通れません。ただ20年来多くのエンジニアの方々と同僚として接してきて思うことは、エンジニアの方の中には「文章を書く」ということに苦手意識がある方が一定数いるということです。 でもこの「テクニカルライティング」のスキルは、才能というよりは一種の「技能」だと思うんです。ある一定の原理原則を理解して実践を繰り返すことで、必ず一定レベルで習得できるものだと著者は信じています。 もしこのテクニカルライティングの原理原則をまだ体系的に学習したことがない、または過去学習したが改めて再学習したいという方に、お勧めのコンテンツを見つけたのでご紹介します。 https://developers.google.com/tech-writing Every engineer is also a write

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに B2Cサービスの場合ではモックアップや専用ツールを利用したプロトタイピングを行うケースが増えてきましたが、業務システムの場合はどうでしょうか？業務担保が最優先になってしまい利用者の利便性が後回しになってしまうことは少なくありません。逆に担当者個人の好みに過剰に寄り添いすぎてしまうこともあります。結果として、一覧画面と詳細画面という無機質な機能の塊ができたり、1画面に過剰に機能が盛り込まれ長い目でみると運用しにくい画面になってしまうこともあります。 ここでは特に数十人月～100人月規模の業務システムの開発に最適だと考えているU

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 企業内でシステム開発に携わる方々に向け、以前こちらの記事で日本CTO協会の「DX Criteria」をご紹介しました。 技術負債の削減に向けた提案～「DX Criteria」の活用～ - Qiita この「DX Criteria」は、DXに前進させる上で有益な指針かつチェックリストであり、弊社でも積極的に活用しています。 ただ資料中には前提知識を要する言葉もいくつか登場し、経験年数や職種を超え幅広いメンバーが正しく理解を深めるには一定の時間がかかりました。 そこでより多くの企業やチームの方に「DX Criteria」を活用読ん

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・2021/04/16：文章術系にリンクを追加しました。 ・2020/11/28：文章術系にリンクを追加しました。 ・2020/07/24：文章術系にリンクを追加しました。 ・2020/05/24：文章術系に

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに DX（Digital Transformation）に対する期待とニーズは日増しに高まり、企業ITを司るCIO/CTOならびに情シス部門の皆様からも多くご相談を頂いています。 中でも「技術負債にどう向き合っていくべきか？」というテーマは、非常に重要かつ悩ましい課題の1つです。 デジタル時代の昨今、何らかの施策の実現にITは欠かせません。新規や既存の種類を問わず各企業で日々様々なシステム開発が進んでいます。つまり今現在も、未来の技術負債が増え続けている可能性があるのです。 まずこの発生を食い止めることが最優先課題だと考えています