受託開発とか自社開発とか言うけれど、会社のカルチャー違いや個人差の方が大きい。

この記事は Calendar for Akerun | Advent Calendar 2022 - Qiita の 19日目の記事です。 こんにちはyuyakmです。今回はEM目線での記事を投稿します。

弊社は自社サービス開発がやりたい!という動機で入社する方が多いです。新卒/中途どちらにおいても受託開発と自社開発でどちらが良いかと迷う方が多い印象ですので触れてみたいと思います。

前提

私のスタンス

  • 自社にサービスを開発・運営する組織があることを理想としている
  • 手放しで受託より自社開発が良いと聞くとそれは違うと言いたい
  • 部分的に開発を委託している立場でもある。委託領域もチームの一部

どのような組織を目指しているか

  • PMとエンジニアが1つのプロダクトチームとして日々コミュニケーションを取りながらプロダクトの成功のために協力している
  • 世の中にないものをつくることができる
  • 中長期目線を持ち継続的にサービスを育てる

参考 ユニコーン企業のひみつ www.oreilly.co.jp

参考 プロダクトマネジメントクライテリア - プロダクトをつくるチームのチェックリスト productmanagement-criteria.com

就職先としての受託開発 vs 自社開発

就職活動において、受託開発と自社開発は何かと比較されがちです。 例えば「受託開発はいろんな案件が経験できて良いけど仕様に口出しできないからつまらない」という話はよく聞きます。

就活目線での、自社サービス開発に対してよくある期待とズレ

仕様に対して口出しできる

こうした方が良いのではないかという提案ができるというのはYes。顧客も含めて不要だと思っているが仕様書に記載しているから検収のためだけに用意するというような請負特有の悲しい話も回避可能です。

口出しできる=全て自分の好きなようにできるという期待であればNo。全部好きにできるのは全ての責任を負う社長だけです。自分で起業して自分で資金調達するのが一番確実です。 社内でのキャリアパスとしては、プロダクトビジョンの実現と収益に責任を負うプロダクトマネージャーになるという選択肢もあります。

提案は、開発しているサービスが誰のどのような課題を解決するものなのかを理解した上で、技術的な背景を理解した立場として目的を達成できる方法を提案する流れだとうまくいくことが多いです。開発コストパフォーマンスや既存システムとの依存関係等を考慮することも求められます。 このような提案は受託でも求められていると思います。

自社プロダクトは納期を守らなくて良い

No。自社だからスケジュールの概念がないということはありません。 見込み顧客の要求スケジュールやアライアンスのスケジュール、製造委託先等の外部要因もありますし、完全に自社に閉じていたとしてもスケジュールの目標がないプロジェクトはありません。 受託よりも厳しい状況、例えば仕様を追加しても納期は変えられないという状況もあり得ます。例えば、会社のフェーズによってはPMFするための要求が判明したがバーンレートを考慮すると納期は変えられないという状況もあります。この場合はやるか解散するかの二択です。弊社も創業初期はそういうこともありました。

一方で、社内だからこそ関係者と方針を協議しやすいというのはあるかもしれません。開発プロジェクトは様々な不確実性があるので都度プロダクトマネージャーや事業責任者とリスクについて情報交換し、例えば開発スコープやスケジュールを変更することは理由次第で可能です。

自社サービスだからやりがいがある

Yesです。 自社サービスならではのやりがいの例

  • ローンチした後にユーザーからのFBや利用実態を見ることができる
  • CSやセールス等の他部門と会話することができる
  • プロダクトビジョンや事業成長を考慮して中長期のロードマップを描くことができる

一方で、チームや個人の状態によってNoとなってしまう可能性もあります。 Jiraに割り振られたチケットをリモートワークで処理するだけの毎日というようなことになると自社プロダクトであってもやりがいは感じにくくなります。

また、受託であっても社会的に意義があったり顧客が喜ぶ姿が見えるようなやりがいがあるプロジェクトも多くあるはずです。受託/自社云々よりも会社のカルチャーや自分の関わり方の方が影響が大きいと思います。

採用目線で考えを改めたこと

自社サービスの経験がないと自社サービス開発は難しいというのは誤りだった

自社サービスを開発するにあたって、中途採用においてはこれまでのバックグラウンドにおいて自社サービスの経験がないと難しいのではないかと考えていた時期がありました。しかし、様々なバックグラウンドを持つ方が入社して活躍するのを見た結果考えを改めました。むしろ、受託開発バックグラウンドしかなかったエンジニアも多数リーダーシップを発揮して活躍しています。 結局のところ個人差の方が大きいと感じたポイントです。

例えばこのようなマインドがあるかどうかは前職の業態は関係ないのでは

  • 技術が好き。技術を主体的に学んで何ができるか提案する
  • 専門外の技術があったとしても領域横断で課題を解決しにいく
  • プロダクトビジョン観点での課題を提起して中長期的な設計に取り入れる
  • 属人化しないように設計や手順をドキュメント化する
  • プロダクトやチームの課題を見つけて解決しようとする

「受託やってたから言われたことしかやらない」というのはステレオタイプなイメージです。むしろ受託をやっている会社の方が、クライアントから次の案件をもらうために課題提起や解決策の提案を行っており課題を見つけて提案する姿勢が強いというパターンもあります。

さいごに

受託開発と自社開発の違いについて考えることを書きました。結論としては、受託開発か自社開発かどうかではなく会社と各個人のカルチャーフィットの方が差が大きいのではないかと考えています。 就職先の候補を見つけた際は、カジュアル面談等で相互理解するための時間を十分に取ると良いと思います。


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp

オフィス運営やシェアスペース運営、賃貸住宅の物件管理をお考えの際はAkerunにお気軽にご相談ください。 akerun.com

2022年度版 設計書に最適なドローツールは何なのかベストプラクティスを探す終わらない旅

はじめに

この記事は Akerun Advent Calendar 2022 - Qiita の18日目の記事です。

設計書に最適なドローツールは何なのかベストプラクティスを探す

終わらない旅です。

  • ドキュメントとしての管理・公開スキーム
  • シームレスなドキュメント作成と図の編集
  • バージョン・変更管理

にフォーカスしたベスプラを今年も探してきました。

結論だけ知りたい人むけ

Markdown + Honkit + plantuml + VSCode + draw.ioプラグイン が結果最高でした 🎉

Honkitについて

以前、gitbookで設計書を書くお話をブログにしましたが、OSSとしての提供は終了してしまいました。

Gitbook Legacy

As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is no longer under active development.
All content supported by the CLI are mostly supported by our GitBook.com / GitHub integration.
Content hosted on the legacy.gitbook.com will continue working until further notice. For differences with the new vesion, check out our documentation.

ですが、非常にありがたいことにフォークしたHonkitというツールがメンテされ続けています。

移行も簡単なので弊社も光の速さで移行しました

ドローツール

よく見かけるドローツール

パッケージソフトウェア・Webサービスそれぞれ特徴があります(お値段も) 描画するツールとしてはどれも良いのですが、

画像の編集とドキュメントへの埋めこみをシームレスにできるツールは残念ながら公式ではほぼありませんでした。

MS WordとVisioの組み合わせならできそうですが、ドキュメントが大きくなった際のWordの重さがボトルネックです(閲覧者にとってドキュメントを開くまでの時間は重要な体験)。

その中で、draw.io については以前のブログでも紹介しましたが、更に進化を遂げていました。

  • 比較的軽量
  • 構成図を書くためのアセットが準備されている(アイコンやクラウドサービスのシンボルなど)
  • 操作が直感的
  • VSCodeプラグインが最&高 ← 主にココ

このプラグイン(非公式ながら)が、前述の「画像の編集とドキュメントへの埋めこみをシームレスに」を実現してくれます。

また、draw.io のもう一つ進化したポイントが、Webで使用した場合、同時編集が可能になりホワイトボードのような使い方ができるようになりました。これで他のツールに比べて弱点がほぼなくなったと思います。(ステマではありません)

公式ブログより

Draw.io integration プラグイン

図を保存するディレクトリに、 [ファイル名].drawio.[画像ファイル拡張子] の形式でファイルを作成します。例えば overview.drawio.png とか。

そうすると、あら不思議。VSCode上でdrawioを操作して作図できるようになります。

これで、VSCode上で

  • Draw.ioインテグレーションで図を作成
  • Markdownでドキュメント作成

が可能になりました。個人的にとても気持ちいい。

コードベースUML

システム構成やクラス図など配置に気を遣う・おしゃれに書きたい場合はドローツールをつかいたいですが、シーケンス図・アクティビティ図はコードベースで書くのがおすすめです。 理由は主に経験則ですが、ちょい変で構成全体に手が入るような場合、コードベースで書いておいた方がメンテしやすいです。好みもあると思います。

現在主流は以下の2つ。

  • plantuml
  • mermaid

この中では plantuml に軍配です。mermaidは表現が狭い。やたら図がでかくなるなど、まだまだ課題ありです。GithubのREADMEページがmermaid記法をサポートしたので、ちょっとした図を仕込むにはいいかもしれません。plantumlもサポートしてくれ。

Honkitはumlプラグインを導入することで、plantuml形式で書けます。また、Markdown Preview Enhancedを追加すれば、Markdownプレビューで一緒に表示してくれます。便利です。

ドキュメントの公開

Honkitでビルドした静的ファイルをホスティングすれば、Webブラウザで閲覧できる設計書のできあがりです。

簡単にやるなら GithubActionsでビルドしてGitHubPagesで公開するのが最もお手軽です。

ただし、GithubPagesはユーザー認証できない(たぶん)ので、情報漏えいにご注意ください。 さすがに設計書を一般公開するわけにはいかないので、弊社では AWSを活用し、S3にデプロイ・Cloud FrontとLambda@Edgeで認証+HTTPSでのアクセスになるよう設定しています。

今回このブログもHonkit形式にしてGithubで公開してみました。

完成形がイメージできてるのもありますが、とても簡単に公開までできました。

終わらない旅

ツールは日々進化するし、使い慣れたツールが突然使えなくなることもある。ベスプラ探しの旅は来年も続きます。


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co

Akerun Proにご興味のある方はこちらから akerun.com

エンジニア採用担当者のこころえ

こんにちは。 フォトシンスでエンジニア採用をやっております@YUKI_0405と申します。

フォトシンスのエンジニア採用担当者として今回、こちらにブログを書かせていただくことになりました。

このブログでは、私個人としての 「エンジニア採用担当者のこころえ」 を綴りたいと思います。

【目次】

1. 初めに

前提として、お役にたてる情報は特にないと思いますので、目次からご興味が湧かない方は、ここでご拝読を終了していただくことをお勧めいたしますm( )m

まず最初に、私の自己紹介を簡単にさせていただきます。

結論から申し上げますと、人事のキャリアは約10年ほどあるものの、 採用担当としての経験はまだまだひよっこ🐥レベルです・・ 。 なので、これから書き連ねることに対しても、温かい目で読んでいただけますと幸いです。

私の人事としてのキャリアは、前職からスタートしました。
前職は人材派遣/営業代行の会社で、そこで未経験から労務を始めて約4年間、フォトシンス 入社2年目まで通算約6年間、労務領域にいました。
今から3年前に、キャリア採用担当としてエンジニア職を含む全職種の採用をした後、 現在は主にエンジニア採用をミッションに日々奮闘をしています。

何をやっているか


  • 採用戦略策定
    ・採用手法の計画立案

具体的には・・

「このポジョションはエージェントさんの方がターゲット見つけやすいよね」や、 「ダイレクトリクルーティング媒体はこれよりあっちの方がターゲットいそうだよね」 など 部門からのバックオーダーに基づいて効果性が高そうな手法のバランスの道筋を概ね立てます。 (とはいえ、現実は全ての手法を全網羅的にやらないと難しいですが..)

  • 部門と求人の擦り合わせ
    ・ターゲットのペルソナヒアリング ・スカウトの基準設定

  • スカウト文の作成&エージェントさんとの打ち合わせ
    ・ダイレクトリクルーティング: ポジションごとにテンプレートを作成
    ・エージェントさん: 部門とすり合わせをした求人内容やペルソナについて、ターゲット目線と乖離が出ないよう具体的にすり合わせをして、よりマッチ度が高い候補者を見つけていただく準備をする

  • スカウト&候補者進捗

  • カジュアル面談or面接(※面接はエンジニアの方が担当)

  • クロージング


細かいところはまだまだありますが、大枠は上記のようなフローで採用活動をしています。

2. エンジニア採用担当になってまずやったこと

採用担当になって3年経ち、今でこそ基本の知識はわかるものの(まだまだ勉強することは沢山ありますが)、エンジニア採用を始めた頃は「コードって何?」のレベルからのスタートで、本当にダメダメでした。

そんなレベルの奴が、「最低限の知識だけは身につけたい、開発についてもっと知りたい」といった単なる私の探究心と興味と担当者としての責務の想いから、【エンジニア採用担当者のこころえ】として、まずは3つのことを実施しました。

・エンジニア採用の本を読みまくる
・つてを使ってエンジニア採用をやっている人事の方に、やっていること、成功事例などの話を聞きまくる
・エンジニア採用に特化したエージェントさんに市況感やターゲットデータベースなどを聞きまくる

実施してよかったこと

・「勉強」の観点でやっていなかったため、すぐに実務に落とし込めるイメージが湧き、その分、吸収力が抜群によかったこと

・同職種の方々の苦戦していること、実体験のお話で、これから来るであろう波に対してある程度の心の準備ができたこと(これめっちゃ大事でした)

・成功事例を真似してみて、自社や自分のやり方と合っているかの検証ができた

・プロであるエージェントさんのお話しや提案などを聞いたりある意味、壁打ち相手ができたこと

非エンジニアの担当者が、「コードについて詳しく話して!」と言われた場合、Google先生に味方をしてもらったとしても、技術本を読んだとしてもきっとちんぷんかんぷんです。 ですが、わからないなりにもエンジニア採用担当者としての基礎知識は覚えていた方が、面談時にエンジニアの方とのお話もスムーズになると思いますし、スカウト作業や採用実務できっと役に立つと思います。もし、これから1人体制でエンジニア採用を始められる方がいらっしゃいましたら、まずはこちらを実践いただくと知識だけでなく気持ちも楽になるかもしれません。

私がエンジニア採用のスタートとして読んだ本の一部をご紹介します。有名な本なので読んだことがあるエンジニア採用担当者は多いと思いますが、技術や基本的な開発環境に対して優しく説明されていて読みやすいです。

参考本

https://www.amazon.co.jp/%E4%BD%9C%E3%82%8B%E3%82%82%E3%81%AE%E3%83%BB%E4%BD%9C%E3%82%8B%E4%BA%BA%E3%83%BB%E4%BD%9C%E3%82%8A%E6%96%B9%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6-%E6%8E%A1%E7%94%A8%E3%83%BB%E4%BA%BA%E4%BA%8B%E6%8B%85%E5%BD%93%E8%80%85%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AEIT%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E5%9F%BA%E6%9C%AC%E3%81%8C%E3%82%8F%E3%81%8B%E3%82%8B%E6%9C%AC-%E4%B8%AD%E5%B3%B6-%E4%BD%91%E6%82%9F/dp/479816531X/ref=asc_df_479816531X/?tag=jpgo-22&linkCode=df0&hvadid=342595526565&hvpos=&hvnetw=g&hvrand=14978878202848301864&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009343&hvtargid=pla-901708087633&psc=1&th=1&psc=1www.amazon.co.jp

https://www.amazon.co.jp/%E9%9D%9E%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E4%BA%BA%E4%BA%8B%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E6%8E%A1%E7%94%A8%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%EF%BD%9E%E3%83%80%E3%82%A4%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%82%AF%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AE%E5%A7%8B%E3%82%81%E6%96%B9%EF%BD%9E-%E6%A0%AA%E5%BC%8F%E4%BC%9A%E7%A4%BEJELLYFISH/dp/4814925298/ref=asc_df_4814925298/?tag=jpgo-22&linkCode=df0&hvadid=588980016217&hvpos=&hvnetw=g&hvrand=836347945083156382&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1028853&hvtargid=pla-1648058463088&psc=1&th=1&psc=1www.amazon.co.jp

3. エンジニア採用への想い

現在の市場感として、エンジニア採用は高難度と言われていて、私自身も本当にそう感じます。
採用がうまくいっている企業さまのお話を聞いても、同じようなことを網羅的にやっている気がしてならず、「あとは何をやったら良いのか」、「何をやるべきなのか」、「やれることってあるの?(ないわけないじゃん。と自分でツッコミ入れてますが)」などなど、採用戦略的なところで悩んでいる事は、本音としてあります。

でも、私はエンジニア採用が楽しくて仕方がないのです。エンジニア採用のご縁をいただけて有り難いと思いますし、これからもやっていきたいと思っています。

なぜ?とよく言われますし、周りから見たら苦悩しかないと思われているかもしれません。ですが、人からどう思われていようとも、私はエンジニア採用が楽しくて仕方ないです。(2回言った!)

理由は沢山あるのですが、大きくは2つあります。


理由① 現場と協業して採用活動ができること

理由② 難易度が高い分のやりがいと達成感があること

▼理由① 現場と協業して採用活動ができる

企業さまによって様々だとは思いますが、フォトシンスは採用と現場の距離が近くそれぞれの役割を分担して採用活動をしています。

私は、採用において最も大事なことが、これだと思っています。「点と点がつながり線になっていく」一点だけでは線にならないので、個々の協力があってこそ採用成功ができるものだと考えています。

開発採用に関してでいうと、例えば組み込みエンジニアの方のクロージング面談などにWEBエンジニアに参加していただいたり、逆も然りのようなことが当社では常にあり、人事⇆募集職種のエンジニアだけでなく、全職種のエンジニアが一体となり領域を超え協力し合いながら採用活動をしています。

非エンジニアの担当者が技術のことを話すことは難しいと前述させていただきましたが、 採用担当としての役割は他にもたくさんあるので、個々の役割を最大限に出しながら同じ目的に向かって一緒に活動する。 企業カルチャーにも起因することなので、これが正解!はないですが、私個人の“こころえ“としては、

「エンジニアにはなれないけれど、自社の開発環境についてできる限りのインプットをして、 採用に対して最大限のアウトプットをしていく。」 エンジニア採用担当としての出来うる範囲以上のことを常に考え実行していくこと。を大切にしています。

▼理由②難易度が高い分のやりがいと達成感がある

“達成感“をどこに置くかは人それぞれだと思いますが、わかりやすいところでいうと、入社の意思決定(内定承諾)をいただけた時でしょうか。

まず、当社のエンジニア採用手法としては大きくは下記の2つです。

・ダイレクトリクルーティング
・人材紹介会社経由

一般的にエンジニア採用は、ダイレクトリクルーティングの比重が高くなるかと思います。 当社でも同じ感覚です。
ダイレクトリクルーティングでは、一般的なフローと同じく主に下記の流れと気持ちで進めています。


  • 1.ターゲットにスカウト送信

→1人のエンジニアに対して数十社の企業から受信されている想定でいる

  • 2.スカウトの返信がくる

→送信数に対して返信数は数%のレベルなので、とっても嬉しい!
(けれど、当社だけではないでしょう・・)

  • 3.カジュアル面談

→興味を持っていただくために自社のアピール頑張る時間

  • 4.選考意思をいただく

→ちょうど転職の時期だったこと、興味を持っていただけたことのタイミングが重なりここで初めて選考進捗となる
(だけど、当社だけではないでしょう・・)

  • 5.選考フェーズ(当社は選考2回~3回)

→他社との選考スケジュールも鑑みながら候補者様と接点を持ち意欲を保っていただきながら進捗を進めていく。また、技術だけではなくカルチャーマッチも必要になってくるので、双方のマッチ度が高くないと双方またはどちらかが選考継続しないこともあります。

  • 6.内定フェーズ

→オファー!!と喜ぶのも束の間、オファーを出す企業は当社だけではないので、意思決定をいただくための最終クロージングに尽力する


私のこころえとしては、入社の意思決定をいただくことが採用のゴールではないので、入社後のミスマッチが出ないように、アピールだけでなく課題や現状もちゃんと話すことを念頭に置いています。

どのタイミングでも、沢山のライバル企業が常に隣にいる状況なのでその分、意思決定をいただく可能性も低くなってきます。

もちろんこれはエンジニア採用だけに限ったことではないですが、1人のエンジニアに対して数十社のライバルがいるこの現実で、当社に入社を決めていただく事は簡単ではないです。

ですが、意思決定いただけた時の嬉しさは壁が高い分に大きいものだと思います。

それが、私がエンジニア採用をやっているモチベーションの一つになっているのです。

(では、どうやったら採用成功まで辿り着くのか・・の議論はまたの機会にしたいと思います。)

4. 最後に

ここまで読んでいただきありがとうございました。

エンジニア採用は結果が中々出ない分、苦しいことも多い。とよく聞きますが、自社で働くエンジニアの方々のために。と思えば、その苦しさも糧になるのではないでしょうか。

締めが精神論みたいになってしまいましたが、 自分のこころえを決めて実行してみると、意外と楽しいものです。

採用のプロだね!と言われるようにこれからも精進したいと思います。


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co

Akerun Proにご興味のある方はこちらから akerun.com

皆どのようにしてコードを書いてるのか?

この記事は Calendar for Akerun | Advent Calendar 2022 - Qiita の 24日目の記事です。 こんにちはEsper0328 - Qiitaです。ファームウェアの開発を担当してますが、最近nodeJSとGoを触ることが多いです。

背景

コードを書くときって皆どんなプロセスで書いてるのか気になりませんか。自分は気になってます。 個人的にはこれまで複合機、電子黒板、車載カメラ、SSD、スマートロック等の組み込みソフト寄りの開発をしてきましたが、 製品、業界、開発のフェーズ(研究・要素開発よりから製品開発、運用・保守までのどこか)等によって、 ソフトウェアのコンストラクション*1の仕方が異なります。 そこで、まずは改めて自分がどのようにしてソースコードを書いているのか整理してみました。

内容

仕様と既存の設計(というかソースコード)を読んで、要求を整理した後、(可能であれば)クラス図を書いて、どのクラスに何をさせるか整理します。 その後、ソースコードを書くより前に単体テストを書いてソースコードを書いてます。 ソースコードを書くまでに下記の設計の成果物までは書きたい派です。 実際に書くかどうかは開発期間、プロジェクトの状況、会社の文化だったりその時々によります。 以下はソースコードを書いていく過程でアウトプットとして意識する成果物のフォーマットの一例です。

成果物フォーマットの一例

背景
目的
スコープ(どの機種・プロジェクトに適用されるのか)
要求分析
テスト設計
  • テスト仕様書
分析
  • クラス図(責務分担)
設計
  • 設計指針
  • クラス図
  • シーケンス図
  • 状態遷移図
実装
テスト
  • テスト結果報告書

下記は上記の成果物に対して私が思うところです。

成果物 内容 何故必要か
要求分析 やることリスト プログラミングをすることで実現する振る舞いのリストを書く。 ソフトウェアを書くことでどんな振る舞いを実現するのか明確にするため
テスト仕様 主に実機テスト仕様を書く(なるべくテストファーストで(ソースコードを書く前に)書く)。可能なら他の人が見て同じ手順を実行できるレベルで書くのが理想。 評価の視点を明確にするため。評価項目に漏れがないことを確認するため。評価手順を明確にするため。
ユースケース図(ユースケース記述) システムに関わるステークホルダを明確にする。ユースケースに関わるシナリオを明確にする。 ユーザの使い方や運用を含めたシステム全体のシナリオを意識するため
分析 クラス図(責務分担) 各クラスの責務を整理する 特定のクラスに責務が集中してコードが複雑になったり、密結合になったり、ソースコードの可読性が下がるのを避けるため
設計 クラス図 データ構造やデータの有効範囲、スコープ、責務の整理を行う ソースコードが複雑になったり、ソースコードの可読性が下がるのを避けるため
状態遷移図 各状態に応じたイベントの有無、イベントに対する振る舞いを明確にする 状態に応じた複雑な振る舞いをバグらずに書くため
シーケンス図 ソフトウェアの動的な振る舞いを記述する インスタンスの処理の流れを明確にするため
実装 ソースコード 関数やメソッドの詳細を実装する ないとソフトウェアは動かないため
静的解析結果 lintやQACを実施する バグを回避するため。Warningが多いとより危険なWarningを見落とすことがあるため。
テスト 単体テスト報告書 単体テストカバレッジレポート どのパスがテストされていてどのパスがテストされていないかを明確にするため。カバレッジ(%)は参考値。
結合テスト報告書 実機で動作確認した結果を書く。エビデンスのログを残す。 評価のエビデンスを残すため。テストチームへの参考資料として共有するため。

所感

こうして書いてみると全部やるのはなかなか大変ですね。でも、

  • 自分たちが作っているのは製品ではなくサービスなので、ユーザシナリオや運用、セキュリティ含めてサービスやシステム全体のシナリオをもっと意識して要求分析の成果物を残しつつコードを書きたい
  • 責務を明確にして設計が複雑にならないようにするためにクラス図を書くことを大事にしていきたい
  • コマンドを打ってクラスやメソッドの説明が出てくると調査に便利なのでGoDocのようなものを残していきたい

と思いました。他のエンジニアがどのようにしてコードを書いてるかぜひ知りたいです。

参考文献

CODE COMPLETE 第2版 上 完全なプログラミングを目指して | スティーブ マコネル, McConnell,Steve, クイープ |本 | 通販 | Amazon


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co

Akerun Proにご興味のある方はこちらから akerun.com

*1:CODE COMPLETE 第2版上に「ソフトウェアを作るプロセスを意味する用語で、詳細設計、コーディング、統合、単体テスト、統合テストが主なアクティビティである」旨が記載されている

【選考基準】「あなたが○○○のQAエンジニアだったら?」

この記事は Calendar for Akerun | Advent Calendar 2022 - Qiita の 23日目の記事です。

今回はフォトシンスでソフトウェアQAエンジニアをしている @yoheioka が担当します。 二年ぶり、二回目の登場です。

【1】はじめに

私がフォトシンスに入社したのは2020年の10月で、気づけば二年以上経過しておりました。 入社してから多くの業務を経験してきましたが、入社前に初めてフォトシンスを知ってから入社するまでのことも、覚えています。 会社に就職する上で避けては通れないイベント、それが面接です。本日は、この面接に関連したお話です。

私もフォトシンスに入社して半年程経過した頃から、ソフトウェアQAエンジニアの採用面接に同席させてもらうようになりました。 面接官として面接をしていて難しいと感じるのは「どんな質問をすれば十分に情報を引き出せるか?」という点です。

面接官は誰しも「落とすための質問ではなく、採用するための質問」をしていると思ってます。最初の頃はとりあえず思いついた質問事項をリストアップし、それを元に面接を行なっていましたが「採用に必要な情報を引き出せるだけの質問を十分にできてるのか?」という猜疑心が拭えませんでした。例えば質問が応募者のスキルや経験に関するものに偏って、他の要素については十分に質問できていなかったり。過去のことばかり質問して、未来のことを聞けていなかったり。

こういった反省から、質問には根拠が必要であると考えました。根拠を用意するために、まずは質問の軸から考え、それらの組み合わせによって質問の網羅性を高めることにしました。いかにもQAエンジニアらしい考え方ですよね。 考えた結果、用意した軸が次で紹介する二つです。

【2】質問の二つの軸

ここから二つの軸を紹介しますが、前提として、下記の基準はソフトウェアQAエンジニアの採用の基準としてソフトウェアQAエンジニアの選考担当である@yoheiokaが設定したもので、必ずしも会社の基準及び他職種の基準にも当てはまるわけではないことをご承知おきください。

「要件へのマッチ度」

一つ目の軸は「要件へのマッチ度」です。これは下記の三つの要素で構成されます。

  • 動機マッチ
  • カルチャーマッチ
  • スキルマッチ
1. 動機マッチ

これは「応募者の転職理由や仕事に対するモチベーションが、フォトシンスにマッチするか」等を見るための要素です。 入社後にギャップを感じて即モチベーション低下、という事態を避けるために面接で見ています。

2. カルチャーマッチ

これは「フォトシンスのカルチャーにマッチするか、または新しいカルチャーを持ち込んでくれるか」等を見るための要素です。 会社のミッションやマインドに対する共感から、組織のあり方や仕事の進め方に順応できるか等まで、幅広く見ています。 フォトシンスは成長途上の会社なので、ただ順応するだけではなく、会社が成長するために新しいカルチャーを持ち込んでくれる人だとより良いです。

3. スキルマッチ

これは「会社のやりたいことを実現するためのスキルを持っているか?」等を見るための要素です。 当然、その職種に期待される業務の遂行や成果を出せると見込めるスキルを持っていないと、採用は難しいです。 ただ、必ずしも即戦力だけを求めているわけではないため、仮にすぐの活躍は難しそうでも、中長期的にスキルが身につくポテンシャルはあると判断できれば、私としてはOKと判断しています。

「時制」

二つ目の軸は「時制」です。これは下記の三つの要素で構成されます。

  • 過去
  • 現在
  • 未来
1. 過去

これは「これまでにどんな経験をし、そこから何を学んだか? どんな結果を残したか?」等を知るためのものです。 実績や成果について、ふんだんに語ってほしいところです。

2. 現在

これは「現在のあなたはどんな人だと自己分析しているか?」等を知るためのものです。 例えば「今、どんな強みを持っているのか?」「今、何に興味があるのか?」等を聞いたりします。 今のあなたを教えてください。

3. 未来

これは「将来的に何を目指しているのか?」等を知るためのものです。 例えば、応募者が思い描く未来像とフォトシンスが思い描く未来像に、重なる部分があるかどうかを考えてます。

また、これら三つの要素をバランスよく聞きながら、過去→現在→未来のストーリーが成り立っているか?も気にしています。

「9パターンの質問」

上述の通り「要件へのマッチ度」の三要素と「時制」の三要素を掛け合わせると、全部で9パターンの質問ができます。 例えば「動機」に時制の三要素を掛け合わせた場合、下記の三つの質問を思いつきました。

  • 動機×過去:「これまでのキャリアを振り返って、自分自身のキャリアをどう思いますか?」
  • 動機×現在:「何故、開発者ではなく、QAエンジニアなんですか?」
  • 動機×未来:「10年後、20年後にどんな仕事をしていたいですか?」

1パターンにつき1つだけではなく、3〜5個程度の質問を用意しているため合計では30個以上の質問をリスト化してあります。 これら全てを毎回の面接で聞くことはできないため、面接の時、その場で聞いてみたいと思った質問事項をピックアップしています。 リスト外でも、その時思い浮かんだ質問をすることももちろんあります。

しかし、9パターンの質問をバランスよくすることを心がけるようになったことで、以前と比較して応募者のことを広く深く知ることができるようになったと感じています。

【3】選考基準

ここまで質問を構成する軸とその要素について話してきました。 この場ではこれ以上詳細な質問事項までは紹介できませんが、最後に一つだけ、私が重要視している質問事項を紹介したいと思います。

それは、

もしあなたが弊社で1人目のQAエンジニアだったら、まずは何からやりますか?

というものです。

弊社の場合、実際はすでに数名のQAエンジニアが在籍しているため、もし入社することになっても1人目となることはないです。 にも関わらずこのような質問をするのは、この質問への回答に、その人のQAエンジニアリングに関する思想が色濃く出ると考えるためです。

1人目として入社する。それは知らない土地を一人で開拓していくようなものです。 地図や看板は存在しないか、もしあっても読めないものです。その土地を、多くの人が暮らせるように開拓し、地図や看板も、誰もが読める言語で作り直していくことが求められます。詳細な指示は誰もしてくれず、ミッションだけが存在します。

あなたは、まず何からやりますか?


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co

Akerun Proの購入はこちらから akerun.com

Xcode14から不要になったbitcodeに関して

この記事は Akerun Advent Calendar 2022 - Qiita の22日目の記事です。

本年度2回目の出番となります、Web開発グループの小森です。主にiOSアプリケーションの開発を担当しています。

前回以下のような記事を書きました。

akerun.hateblo.jp

本記事は、前回記事とは違い少し技術寄りなことを書こうと思います。

Xcode14からのbitcode

Xcode13系で開発していた時までbitcodeを含めた実行バイナリを生成し、それをAppleに提出することができました。 しかしXcode14にて不要になり、Appleに提出するバイナリにbitcodeを含められなくなったようです。*1

Akerunアプリでもbitcodeを含めてバイナリを生成していたことと、bitcodeそのものの理解がやや曖昧だったため、周辺知識を整理してみました。

bitcodeとは何か

こちら*2にある通り、コンパイルされたプログラムの中間表現です。

具体的にはLLVMが使用するテキストベースの中間表現であるLLVM IR のバイナリ表現のことで、LLVM IR ⇄ bitcode の双方向に変換が可能です。LLVMは、特定のCPUアーキテクチャに依存することはなく独立しているので、LLVM IR によって複数のCPUアーキテクチャ向けのバイナリが生成できます。

bitcodeで何ができそうか

互換性のないCPUアーキテクチャスマホに同様のアプリケーション(バイナリ)を展開する必要がある場合、開発者がそれに対して特別作業することなく、Apple側でそのCPUに対応するバイナリを準備することが可能になると思われます。

大まかなイメージとしては図のようなものです。

なかなか便利な仕組みですが、32bit cpu である唯一のデバイスが64bitに移行したことで、将来的なことを見据える必要性が薄れ*3、その影響でbitcodeが役目を終えたように思われます。

bitcodeについて、なんとなく存在理由がわかったところで、次はbitcodeが不要になったことで開発者側として気にした方が良さそうな、App Store Connect上で作成される dSYM(デバックシンボル)についても補足します。

App Store Connect上でdSYMが生成されなくなる

App Store Connect上でdSYM(デバッグシンボル)をダウンロードして、それをFirebase Crashlyticsにアップロードすることは、多くのiOSエンジニアの方が経験済みだと思います。

bitcodeが不要になると、App Store Connect上で新しいdSYMが吐き出されることがなくなったので、リリースビルド(アーカイブ)時に一緒に生成されたdSYMをFirebase Crashlyticsにアップロードすることになりそうです。App Store Connect上にいちいち吐き出されるまで待つ必要が無くなったことは嬉しいです。

bitcodeをオンにしていた場合、バイナリをAppleに提出した際に再コンパイルされ、その影響でビルドUUIDが異なるバイナリとdSYMが生成されます。そのためアーカイブ時点で作成したdSYMとビルドUUIDの整合性がとれずCrashlyticsにログが上がってこない状況が発生する可能性があります。

以上を図でまとめると以下のようなイメージとなります。

参考: https://developer.apple.com/documentation/xcode/building-your-app-to-include-debugging-information

最後に

bitcodeをoffにして Apple に提出することは今後ないので、上記のようにまで整理する必要性はないかもしれません。しかしLLVMやdSYM, CPUなど普段見ないレイヤも踏まえながら思考整理しつつ、Appleがなぜbitcodeを含めようとしたのかほんのりわかったような気がしてよかったです。


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co

Akerun Proにご興味のある方はこちらから akerun.com

プロダクトへの要望の視える化をした話

この記事は Calendar for Akerun | Advent Calendar 2022 - Qiita の 21 日目の記事です。

こんにちは。プロダクトマネージャーのHiShionoyaです。

最近プロダクトマネージャーがやっている、 「いただいた要望への対応・管理方法」を変えたことについて書いてみたいと思います。

ありがたいことに、「Akerunでこれをやってほしい」という要望が日々たくさん届きます。 お客様からいただくフィードバックもあれば、営業の方やカスタマーサクセスの方からいただくものもあります。

逆に要望が多すぎて、要望の量 > 答える量 となってしまい、 要望したものがどう実現したか、そもそも要望がその後どうなったかが見えづらくなっていました。

こうなると、営業やカスタマーサクセスのメンバーからは 「なんで要望したのに実現されないのだ!」 と思われてしまいがちです。

これが続くと「要望を出しても仕方ない」となり、 プロダクト全体にとってもよくありません。

それを解消するため、
* 要望の集約
* 要望の視える化

を実現することにしました。

大きくわけて4つのステップで実現していきました。


1) かんたんに投稿できるようにする

以前の投稿フォームはGoogleフォームで、入れる項目が10項目以上あり、入れるハードルがやや高めでした。 そこで、slackのワークフローに変更し、改善案/アイデアだけを投稿できるように変更しました。

2) 要望を集約する

ドキュメント管理ツールとして使っているNotionに、要望を集約するデータベースを作ることにしました。 これによって、プロダクトマネージャーとしては、要望が漏れてしまうことがなくなります。 また、全社員が見れるように権限を出すことで、自分の要望が受け取られたことがわかるようになります。

3)回答する

そのデータベース上でプロダクトマネージャーとしての回答を書いていきます。 「やる」「やらない」とその理由について回答していきます。

4)優先順位を付けて実現していく

「やる」と回答したものについて、プロダクト全体にとっての「重要度」を付けていきます。 改善要望としての数・ビジネスインパクト・プロダクトビジョンとの整合といったところから判断をつけていきます。


この4ステップによって、「簡単に要望」ができ、 「要望とそれに対するプロダクトマネージャーとしての回答の視える化」がされ、 「今実現しようとしているのかそうではないのか」がわかりやすくなりました。

結果として、チームの内外に対して要望の状況が視える状況を作ることができました。

最後に・・・この活動をすることで、これまで積み重なってきた要望を棚卸しするという作業ができました。 時間が経過して不要になったものの精査ができ、プロダクトにとって本当に必要なもの要望だけを残すことができました。

式年遷宮」のように、いただいた要望を毎年引っ越していくという作業は意味がありそうだと思いました。 プロダクトマネージャーの皆さんぜひ試してみてください。


株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co

クラウド入退室管理システム「Akerun」の概要はこちら akerun.com