Xcodeでプロジェクトを作ってgitignoreを追加するまで

• Create Git Repository on Hogeにチェックを入れてプロジェクト作成
• 下記コマンドを実行し、.gitignoreファイルを追加。
  このコマンドを実行するにはこちらの設定をしておく。

$ git ignore osx swift xcode > .gitignore

アジャイルサムライからエンジニアのキャリアを考える

アジャイルサムライ−達人開発者への道−

本記事ではアジャイルサムライの中で紹介されている役割分担からエンジニアのキャリアについて考えてみます。

アジャイルサムライの中で定義されている役割

アジャイルサムライでは役割を以下の2つに分類しています。

• 顧客
• 開発チーム

そして開発チームについては更に以下のように詳細な役割について紹介しています。

• アナリスト
• プログラマ
• テスター
• プロジェクトマネージャ
• UXデザイナ

開発チームのメンバーはこれらの役割を複数こなしたり、日によって別に役割をこなしたりします。
ただ、全てを中途半端に身に着けてもキャリアを築いていくことは難しいと思いますので、それぞれ単体で考えていきます。

アナリスト

顧客と開発チームをつなぐ仕事をします。プロダクトの規模が大きくなると、顧客はプロダクト責任者が全体の方向性を決め、アナリストが詳細な仕様を決めていくことになるのでしょう。
アナリストにはエンジニアリングよりもビジネスサイドのスキルが求められる気がしますが、アナリストは様々なデータを駆使して分析する必要がある役割だと思います。
エンジニアリングの要素の中ではデータ分析のスキルを伸ばしていくと良いと思います。

プログラマ

プログラムの設計やコーディングを行います。
プログラマは組織内で優秀であってもその活動がオープンでなければ成果が見えづらくアピールしづらい環境にあります。
プログラマとしてのキャリアの築いていくには、OSSプロジェクトに参加し貢献していくなどの、オープンな場での活動が必要になると思います。

テスター

プロダクトのクオリティに責任を持ちます。
テスターはプログラマに比べてOSSプロジェクトでの活動が難しいと思います。なぜならあまり大きくないOSSプロジェクトであテスターが活躍する場がないからです。
テストの領域はアカデミック色が強く、様々な手法が一般化されており、それらをに身に付けていく必要があると思います。
そしてそれらの手法を実践に投入し、知識を向上させることで、キャリアを築いていけると思います。

プロジェクトマネージャ

開発チームの生産性が上がる仕事をなんでもやります。
プロジェクトマネージャの仕事の中にはコミュニケーションの改善や他部署との調整など、エンジニアリングが関係ない仕事もありますが、開発現場ではチームを見える化するツールや、CIツールなど、エンジニアリンングが求められる仕事もたくさんあります。
それらのスキルはプロダクト開発とは少し違うスキルになります。
また、生産性を上げるプラクティスもXPのように一般化されており、それらのプラクティスを身に付け、現場に投入し、知識を向上させることで、キャリアを築いていけると思います。

UXデザイナ

レイアウトだけではなくユーザ体験をデザインすることが求めれてきています。
UXデザイナにはソフトウェア開発に関係ない、一般的なデザイナに求められる、人間工学などの専門スキルが求められます。
また、現在や未来にどういうものがなぜ求められているのかというマーケティングも必要になります。
さらには、作り込んだUIがプログラムに落とし込めなかったり、想定外にコストがかかったりするなどの問題も出てきています。
UXデザイナとしてのキャリアを考える場合は、より抽象度の高いデザイナよりのデザイナか、プログラマよりのデザイナかのどちらかに軸足をおくことになると思います。

最後に

アジャイルサムライでは今回紹介した役割以外にも、データベース管理者、システム管理者、テクニカルライター、トレーナー、業務改善担当、インフラ管理者、ネットワーク管理者、などなど様々な役割があると書かれています。
それらについてはアジャイルサムライ内でも詳しく書かれていませんでしたので、今回は考察しませんでしたが、これらについてもどこかの機会で考察してみたいと思います。

以上です。

Scrumからエンジニアのキャリアを考える

本記事ではエンジニアのキャリアについてScrumで定義されているロールから考えてみます。

3つのロール

Scrumでは3つのロールが定義されています。

• プロダクトオーナー
• 開発チーム
• スクラムマスター

それぞれのロールをエンジニアのキャリアという視点で考えていきます。

プロダクトオーナー

プロダクトオーナーとは

• プロダクトオーナーはプロダクトの責任者
• エンジニア以外が担うこともある

プロダクトオーナーとしてのキャリア

一般的なエンジニアに求められるスキルよりも、マーケティング等のビジネスサイドのスキルが求められると思います。
ただし、プロダクトの全体のリスクに占めるエンジニアリングリスクの割合も高いと思いますので、エンジニアの知識があるとよい場面も多いと思います。
また、プロダクトオーナーはエンジニアに比べてその人の能力が見えづらいため、具体的な成功実績がエンジニアよりも重要になると思います。
成功しているプロダクトの一部のプロダクトオーナーとして経験を積めばこのようなリスクをヘッジできるかもしれません。

開発チーム

開発チームとは

• プロダクトの生産者

開発チームとしてのキャリア

開発チームはいわゆるエンジニアのキャリアとして考えればいいと思います。
インフラ、ソフト、DB、ネットワークなどの専門知識をより深く伸ばしていったり、これを全て身につけるように知識を増やしていったりスルことになると思います。 それらの領域はスクラムでは定義されていませんので本記事では開発チームの詳細については考察しません。

スクラムマスター

スクラムマスターとは

• スクラムのプロセスが上手にまわるようにします。
• スクラムのプラクティスを熟知

スクラムマスターとしてのキャリア

スクラムマスターという名前ではありますが、スクラムではあまり多くのプラクティスが定義されていないため、開発を生産的に行うためのプラクティスを多く身に着けておく必要があると思います。
生産的にするための手法の中には、CI環境等のエンジニアリングの要素も多くあるため、エンジニアのスキルが必要になる場面は多いと思います。 ただ、自己組織化された開発チームでは、スクラムマスターの必要性が低くなります。
スクラムマスターとしてのキャリアを考えるならば、様々なプロダクトに関われる環境にいる必要があると思います。
従って、組織内のプロダクトが少ない場合は、スクラムマスターだけのキャリアを考えることは難しいかもしれません。

まとめ

• プロダクトオーナーとしてのキャリアはエンジニアよりもビジネスより。
• 開発チームとしてのキャリアはいわゆるエンジニアのキャリア。
• スクラムマスターとしてのキャリアを考える場合、様々なプロダクトに関われる環境にいる必要がある。

参考にした書籍

SCRUM BOOT CAMP THE BOOK

アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

「学習する組織 改訂版によせて」読書メモ

学習する組織――システム思考で未来を創造する

改訂版によせて

サマリ

学習する組織の本題に入る前に全体像について触れられている。

• 学習する組織の5つのディシプリン(FIFTH DESCIPLINE)
• 5つのディシプリンの分類
• 学習する組織の前提になるその組織の単位について。

メモ

• 学習する組織の3つの中核的な学習能力と5つの領域。
  • 志の育成
    • 自己マスタリー
    • 共有ビジョン
  • 内省的な会話の展開
    • メンタル・モデル
    • ダイアログ
  • 複雑性の理解
    • システム思考
• 組織の基本的な学習単位は仕事チーム（ある結果を生み出すためにお互いを必要とする人たち）
• 学習する組織の弊害となるマネジメント体型
  • 評価によるマネジメント
  • 追従を基盤にした文化
  • 結果の管理
  • 「正しい答え」対「誤った答え」
  • 画一性
  • 予測とコントロールが可能であること
    • 変化をコントロールするのではなく適用するって感じだろうか？
  • 過剰な競争と不信
  • 全体性の喪失
• 何よりも変化にエネルギーを与えるのは、開放性、内省、より深い会話、自己マスタリー、共有ビジョンであり、システム全体を見て問題の原因を理解することが決定的に重要である。

「学習する組織 日本語版 訳者まえがき」読書メモ

学習する組織――システム思考で未来を創造する

日本語版 訳者まえがき

サマリ

学習する組織が求められる社会的な背景、相互依存で複雑、変化が激しい、事を紹介し、学習する組織の導入になっている。

メモ

• 学習する組織には唯一完全の姿があるわけではない。
• 変化の激しい環境下でその変化に適応し、学習し、自らをデザインして進化し続ける組織が学習する組織。
• かつてないほど「相互依存」の時代を生きている。
• 相互依存であるから複雑な社会。
• 複雑で変化の激しい時代には、多様な関係者が真の対話を重ね、複雑な現実を見つめ未来のビジョンを共有することで、自ら創造し、再生し続ける組織が必要。
• 安定成長の時代には、効率改善や標準化が常套手段である。しかし、複雑に激しく変化する時代には、しなやかさ（リジリアンス）や多様性を強化することで、長期的な効率の最適化を図る。
• 安定した成長の時代に私たちの思考や行動の前提として染み付いたメンタル・モデルを浮かび上がらせ、それがこれからの環境や課題状況にあったものかを組織として精査するために、物事を多面的に見て多様性を創造につなげる対話が欠かせないのだ。
• ただ話し合うばかりでは、皆が望む結果を出せる組織は作れない。どんな未来を作りたいのかの具体的なビジョンを共有し、一人ひとりがそのビジョンを自分ごととして創造的に取り組まなければ前進できない。

PublisherAdViewに動的に広告IDを設定する

PublisherAdViewはGoogleDFP広告ライブラリの広告Viewのクラスです。
このクラスのインスタンスに、広告ID(adUnitId)を設定し、広告リクエストを投げると広告が表示されます。
この広告IDを動的に設定しようとした際に、次のエラーが発生しました。

• XML上でdatabindingを使ってadUnitIdに対して値を設定すると、Viewには一度しか広告がadUnitIdを設定できないというエラー。
• XMLでの指定はせずに、コードからfindByViewIdでViewを取得して、adUnitIdに値を設定すると、xmlにはAdUnitIdは必須というエラー。

どうやらコードでレイアウト組み立てるしか方法はなさそうです。

関連する投稿

LINE DEVELOPER DAY 2016 に参加してきました。

参加してきたので簡単にまとめておきます。

雰囲気や印象

• メイン開場の収容人数が1000人程で、ほぼ満席でした。
• LINEの海外のエンジニアの方も多く参加されていました。
• ノベルティが豪華だったり、ヒカリエ11Fのカフェを貸し切っていたりと予算からも本気度がうかがえました。
• ほとんどの発表が日本語でした。
• 至る所にLINE要素が盛り込まれていました。
  • このイベント用のLINE@
    • 事前受付の連絡
    • 当日受付で使うバーコードの送信
    • 資料公開の連絡
    • Beaconイベントの紹介
    • アンケート回答
  • BeaconとLINE
• LINEはWebよりもアプリの会社という事もあり、発表の随所でアプリに関する内容が出てきたことが印象的でした。

午前

• 午前はオープニングトークとキーノートです。
• キーノートでは新しくリリースされたサービについて紹介されていました。
• 詳しくはこちらを参照下さい。

午後

• 午後はLINEエンジニアの方の発表でした。
• 発表資料はこちらにまとまっています。
• 発表動画はLINE LIVEで見れるようです。
• 非常に具体的な内容が多かったので詳細は資料等を確認頂くとして、私が見た発表について簡単に非常に紹介します。
• 午後の整理していないメモも一応公開しているのでリンクを張っておきます。

LINEが乗り越えてきた困難な問題

• 2016/3/11に発生したサービスダウンについて

LINE Login - LINE Platform

• LINE Loginについて
• LINE Loginのロードマップ

Security x LINE Platform

• メッセージや通話のセキュリティについて
• アプリのセキュリティについて

LINE LIVE を支えるアーキテクチャ

• 動画サービスのアーキテクチャについて

New stream processing platform with Apache Flink

• LINE LIVEの視聴者数をどのようなシステムで実現しているか

A True Agile Team - Global LINE News

• 海外のLINE NewsをAgile Teamで開発した話

LINEのエンジニアが働く環境と文化

• LINEエンジニアが働く環境について
• 開発文化について
• 基本的なマインドについて