最近アプリディレクターという職種の採用を始めました。 世間一般でいうPMO、PM補佐にあたる役割の職種になります。 なぜこの職種の採用を始めたのか経緯を紹介します。 エンジニアがPM/PMOの役割を兼任した時代クライアントワーク事業を本格的にやり始めてからは基本的にはエンジニアをやりたい層を採用していました。 そして人数が増えるにつれて全員エンジニアという触れ込みでエンジニアが開発もしつつ、PM/PMOとしてクライアントと直接やりとりをしている状況が続いていました。 オ
エンジニアとして働き始めた頃から「開発と営業は違う生き物ではないか」と感じていました。 「またビジネスサイドから無茶な機能追加の要望が上がってきた」 「この機能は売り上げに大きく関わるのにリリース時期を伸ばすのはありせない」 というような愚痴は皆さんも一度は聞いたことがあるのではないでしょうでしょうか。 「お互いの立場に立って考えれば分かり合えるのに」と至極真っ当な意見が出てきそうですが、この違いは思考の癖の違いに由来するもので頭を切り替えて両者の立場で考えるのは中々難し
最近は立場上、内定式や入社式で数分話す機会をもらうことがあります。 そういった機会で話していることを紹介したいと思います。 1. 制限のある中でパフォーマンスを出していくことが求められる チーム開発をしているとリソース、期限、開発言語・フレームワークなど様々な制約が出てきます。特にエンジニアが気にしている技術的負債は作った瞬間から発生しています。 このような状況で既存のやり方を否定して俺の考えたベストプラクティスを考えることは簡単です。しかし、代案を提案をしてみるという
本日はこれまで経験したシステム・アプリ開発で本当にあった怖い話の第2弾をご紹介したいと思います。 Z世代エンジニア3年ほど前の話ですが、業務用アプリの機能開発の一環で新しくAPIサーバーと管理画面を開発することになりました。 リードエンジニアのRuby on Railsを使えるBackEndエンジニアはアサインできましたが、当時社内のBackEndエンジニアが多くなかったこともあり、業務委託の募集をすることになりました。 候補者の経歴は某大手メガベンチャーで1年〜2年開発
最近社内の書籍を整理していた際に古い書籍ばかりになっていることに気がついたので大幅に入れ替えを実施しました。 その時に購入した書籍の一部を紹介します。 元々Android/iOSやRuby on Railsなど開発でよく使う技術スタックであったり、リーダブルコードなどいわゆる古典的な書籍は結構ありました。 ただ、新卒メンバーが増えてきた・特定のプラットフォームだけの知識に偏って欲しくないこともあり、アプリ開発に関連する様々なジャンルの書籍を購入しました。 個人的に読んだ
本日はこれまで経験したシステム・アプリ開発で本当にあった怖い話をご紹介したいと思います。 幻のエンジニアあれは確か4年くらい前のことだと思います。 当時 Objective-Cを用いた開発が得意なiOSエンジニアが社内に少なかったこともあり、業務委託のメンバーを募集をしていました。 お任せするのはtoC向けのAndroid/iOSアプリの保守開発プロジェクト 某大手企業の数年運用されていてユーザー数もいるようなアプリでした。 当時でも絶滅危惧種であったObjective
「WebアプリとNativeアプリのどちらを開発した方がいいですか？」というご相談をよくいただきます。 近年、ノーコード・ローコード開発、PWA（Progressive Web Apps）開発、Flutter開発など、アプリを開発する選択肢は多岐に渡っています。 Nativeアプリ開発（以下の記事だとモバイルアプリ開発）の概要については以下の記事をご覧ください。 本記事では、よくあるお問い合わせの一つである「Webアプリとして開発したサービスのNativeアプリ版を作りた
ここ2年ほど、Web業界におけるアジャイル開発の設計（ウォーターフォール開発でいう詳細設計の役割）について、どのようなアプローチが最も効果的なのか疑問に思っていました。 設計から実装までエンジニアに任せられるのがいい点ではあるのですが、 従来のウォーターフォール開発と比べて、アジャイル開発は仕様の可視化（ドキュメント化）が不十分に感じることがあります。特に、詳細設計が抽象的で、結果として細かいバグが発生しやすいという印象があります。 以下のような状況に一度は遭遇したことが
「人当たりもよくて話も面白いからビジネスサイドとのコミュニケーションもうまくやってくれそう」 一見するとそのように感じますが経験的にあまり当てはまっていないように思います なぜかというと、いわゆる飲み会でのコミュニケーション（弊社では音の伝達と呼んでいます）がうまいだけで情報の伝達が適切にできているとは限らないからです 逆に無口で愛想のないエンジニアの方が、ビジネスコミュニケーション（弊社では情報の伝達と呼んでいます）として、必要な情報を伝える・聞き出すのがうまいことが
エンジニアをプロジェクトに参画させる際、選定の基準は主に2つあります スキル コミュニケーション力」 「スキル」に関しては、主にハードスキルを指し、これまでの経歴や経験、スキルセットを基に判断します 一方で、「コミュニケーション力」はやや抽象的ですが、情報伝達の正確さや、タイムマネジメント、協調力などのソフトスキルを含んでいます ソフトスキルの評価は難しいものです。ハードスキルが優れていても、プロジェクトを進める中で、プロジェクトマネージャ（PM）からエンジニアに対す
お話させていただく前に経歴等知っておいてもらった方が話もスムーズかと思いましたので私の簡単なプロフィール及び経歴を紹介します。 概要1990年生まれ。 出身は神奈川県藤沢市。 趣味は食べ飲み、テニスなど 開発部部長という名のプロジェクト管理、開発、採用、調達、教育、営業など色々やっているなんでも屋さんです。 開発では主にiOS/Androidアプリ開発をやってきて直近数年はWebアプリのプロジェクトにも参画しています。 組織の状況に応じてリソースが足りてないところを
