はてなブックマーク

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

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

» Python実践データ分析100本ノック | 下山輝昌, 松田雄馬, 三木孝行 はじめに この本を手にした動機 元々データ分析に以前から興味があったものの、次に繋げられなかった 非エンジニアがR言語を始めるときの手引き｜Kaggle Masterによるデータ分析技術者養成講座【R言語版】Day1メモ｜中野ヤスオ｜ARI ｜note 2021年10月から12月まで受講した初級Python講座で得たことをなにか繋げたかった 講座受講の経緯等こちら：若手エンジニア成長支援No1企業を目指して｜中野ヤスオ｜ARI ｜note コードを書くことが楽しくなってきたので、毎日少しづつ出来るテーマを見つけたかった 今回の読み方 冒頭にある「本書の効果的な使い方」を参照し、それに準拠 各章各ノックの内容を「写経」しつつ、本文とコードを読み進め、分からないところをGoogleで調べる感じ 人それぞれだが、

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

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

これって何？ 政府CIOとは、内閣から任命され日本行政のシステム全体を統括する「日本政府のCIO」です。この政府CIOをサポートするのが各省庁を担当する50名近い政府CIO補佐官からなる政府CIOチームです。（組織としては、内閣官房　情報通信技術（ＩＴ）総合戦略室というようです） この政府CIOチームがとりまとめた政府職員向けのIT調達とシステム導入に関する標準が「デジタル・ガバメント推進標準ガイドライン」です。 このガイドラインは「本編」「解説書」「実践ガイド」の3点構成になっています。 中でも今日ご紹介したいのが上図一番右の「実践ガイドブック」です。 これを読むと何が手に入るのか？ 一言でいえば、「システム開発プロジェクトの歩き方」です。（一言でいう必要なかったか） 組織で商用のシステムを企画して開発・導入・そして維持運用していくための基本所作（型）を知ることができます。 （あくまでも

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

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

はじめに B2Cサービスの場合ではモックアップや専用ツールを利用したプロトタイピングを行うケースが増えてきましたが、業務システムの場合はどうでしょうか？業務担保が最優先になってしまい利用者の利便性が後回しになってしまうことは少なくありません。逆に担当者個人の好みに過剰に寄り添いすぎてしまうこともあります。結果として、一覧画面と詳細画面という無機質な機能の塊ができたり、1画面に過剰に機能が盛り込まれ長い目でみると運用しにくい画面になってしまうこともあります。 ここでは特に数十人月～100人月規模の業務システムの開発に最適だと考えているUI/UXを最適化する上流工程のアプローチを紹介します。 ドキュメントは人をまじめにさせ、動くソフトウェアは人を本気（マジ）にする システム開発が目指すべき目標の本質は、「正しいものを正しく作る」ことです。 正しく作れそうかは仕様書や設計書といったドキュメントで

はじめに 企業内でシステム開発に携わる方々に向け、以前こちらの記事で日本CTO協会の「DX Criteria」をご紹介しました。 技術負債の削減に向けた提案～「DX Criteria」の活用～ - Qiita この「DX Criteria」は、DXに前進させる上で有益な指針かつチェックリストであり、弊社でも積極的に活用しています。 ただ資料中には前提知識を要する言葉もいくつか登場し、経験年数や職種を超え幅広いメンバーが正しく理解を深めるには一定の時間がかかりました。 そこでより多くの企業やチームの方に「DX Criteria」を活用読んでいただくために、弊社内で用意した資料に出てくる用語や背景をまとめたメモを、再構成の上こちらで公開することにしました。 今回は5つのテーマの中から、「チーム」についてご紹介します。他のテーマについても順次公開していきたいと思います。お役に立てば幸いです。 関

システム開発にドキュメントは欠かせません。ドキュメントが得意になれば活躍の幅が大いに広がりますよね。 この記事では、まず冒頭でドキュメントの作成に求められると思うことを整理した上で、そのスキル獲得に役立つと思われる記事や書籍を集めてみました。もちろん他にもあると思うので、もしお薦めのものがあれば是非コメントで教えて下さい 更新履歴 ・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

はじめに DX（Digital Transformation）に対する期待とニーズは日増しに高まり、企業ITを司るCIO/CTOならびに情シス部門の皆様からも多くご相談を頂いています。 中でも「技術負債にどう向き合っていくべきか？」というテーマは、非常に重要かつ悩ましい課題の1つです。 デジタル時代の昨今、何らかの施策の実現にITは欠かせません。新規や既存の種類を問わず各企業で日々様々なシステム開発が進んでいます。つまり今現在も、未来の技術負債が増え続けている可能性があるのです。 まずこの発生を食い止めることが最優先課題だと考えています。ここではそのための1つの施策を紹介したいと思います。 技術負債の正体 技術負債を考える際に重要な視点が「内部品質」です。利用者からは見えないこの「内部品質」への考慮不足こそ、技術負債を生み続ける根本原因です。 結果的に外部品質そしてユーザー品質をも劣化させ