dotrikunの日記

日々マンガを読んだりプログラムを書いたりしています。

『建設的に議論できる能力』はもっと評価されるべき

開発するために議論する機会はめちゃくちゃあって、

建設的に議論できることって開発生産性にかなり影響すると思ってます。

以下、建設的じゃないなーと思った体験。

混ぜっ返す

その場で議論不可能なぐらい議論の対象を見境なく広げたり、遡ったりする現実逃避的な行為。

根底から覆す一言を発したい気持ちが空振りしていたり、

結局目の前の事象から目を逸しているだけだって私は気づいたのです。

想像や仮説を事実のように話す

情報を正確に伝えずと判断を歪めてしまう行為。

無意識にバイアスがかかるのはしゃーない。

だからこそできるだけ正確に伝えることを心がけたい。自戒込めて。

自明なことをあえて議題にしようとする

なんらかの意図で議論を遅延させようとする時に起こりがち。

やりたくない、通したくないのであればちゃんと理由を説明して理解を得るのが正道じゃないでしょうか。

それが大変だという意見は同意です。

感情的になる

自身の意見が否定されることに過剰反応する行為。

私が否定しているのはあなたの意見であってあなた自身ではないのです。

私が述べているのは批判であって批難ではないのです。

できるだけ配慮するけど遠慮はしません。傷つけてごめん。

でも問題を解決したいという気持ちはきっと同じはず。


なんだかんだ言って、人間と人間が話し合うことでシナジーが発生すると信じているし、それ自体は普遍的な価値観だと思ってますよ。

A friend in need is a friend indeed.

タイトなスケジュール、それなりの開発規模、タスクの同時並行がかなり多い、

そういった追い込まれた環境だと人間の底力みたいなものが輝いて見える時がある。

頭の回転キレッキレなタイプじゃなかったり、普段はそんなに評価されてない人でも

  • 取り乱さない
  • 追い込まれた中でも力を発揮できる
  • 自分にできることはないか模索する

といった意志、行動力が物事を前に進める馬力を発生させてくれて、

「ああ、この人は本当に信頼できる人だな」と思える。

無論プロジェクトがそんな状態に陥らないのが一番であることは言うまでもないし、

そんな状態を作り出したり、状況をさらに悪化させるような人物を信用してはいけないということだけは確信できる。

シビアなプロジェクトは信頼すべき人を教えてくれる機会でもあるわけですな。

「Swift の良いところってどんなところだと思いますか?」

仕事で iOSアプリ開発者の面接を担当しています。

一昔前に比べてiOSアプリ開発の裾野が広がったのか、 応募も増えてSwiftに触ったことがない人の方が少ないぐらいです。

面接の場で必ず聞くようにしているのが

「Swift の良いところってどんなところだと思いますか?」

という質問です。

みたいことや、納得感やユニークさがある回答とかなんでもOKなんですが、意外に説明できる人が少ないです。

(良いプログラマが弊社を受けに来ていないという可能性もおおいにありますが…)

効率厨と心理的安全性

心理的安全性というワードに時節に遅れた上に踊らされている方を見かけたのでちょっと考えた。

心理的安全性を担保して意見吸い上げまくって、 それをもとにアクション起こして効率良くして成果に繋げるのがやりたいことであって、 成果を求める集団において心理的安全性だけあってもしゃーないですわ、ってばっちゃが言ってた

あと心理的安全性が担保されてても「こいつに言っても無駄やな」と思ったら相談とかしませんし。

相談を受けて口先でうまく丸め込んだつもりでいると、相手も上辺だけ納得した顔をしてフィードバックの源泉を失っていくんじゃないでしょうか。

まとめると

  • 効率のための和気あいあいであって、その逆ではない
  • 改善の実行力が伴ってはじめて相談相手として成立する
  • Googleの人が言ってることを鵜呑みにしない

かな!

UITableViewCellに付け外し可能なチェックマークを置く時の話

この記事はSansan Advent Calendar 2016の16日目のやつです。

仕事でiOS8のサポートがまだまだ切れなくてUIStackViewを使えないから、UITableViewCellの小ネタでもどうぞ。

概要

AutoLayout対応してるUITableViewCellに、 UITableViewCellAccessoryTypeで付け外しするチェックマークを実現して失敗したお話。

UITableViewCellにチェックマーク置きたい

リストセルの選択状態を表現するために、セルの右端にチェックマークを出したい時があります。

f:id:dotrikun:20161214182702p:plain

UITableViewCellにはaccessoryTypeという気の利いたプロパティが用意されていて、 定義されたEnumを指定するだけでいい感じのチェックマークを表示することができます。

typedef NS_ENUM(NSInteger, UITableViewCellAccessoryType) {
    UITableViewCellAccessoryNone,                                                      // don't show any accessory view
    UITableViewCellAccessoryDisclosureIndicator,                                       // regular chevron. doesn't track
    UITableViewCellAccessoryDetailDisclosureButton __TVOS_PROHIBITED,                 // info button w/ chevron. tracks
    UITableViewCellAccessoryCheckmark,                                                 // checkmark. doesn't track
    UITableViewCellAccessoryDetailButton NS_ENUM_AVAILABLE_IOS(7_0)  __TVOS_PROHIBITED // info button. tracks
};

なにが起こったか

先に書いたやり方でチェックマークの表示/非表示を切り換えを実装すると、セルの横幅に合わせたラベルが伸び縮みしてキモい。

f:id:dotrikun:20161214182500g:plain

なんでこうなるかというと、accessoryTypeに UITableViewCellAccessoryNone 以外を指定するとContentViewの横幅が自動的に狭まるから。 LabelはAutoLayoutでContentViewの右端からマージン取ってるので、ContentViewの幅が変わるとみょんみょんしてしまう。

結論

付け外し可能なチェックマークを実装したい場合、 accessoryType は使わずにUITableViewCellのContentViewに自前でチェックマーク画像のimageViewを置いてレイアウトを組みましょう!ということです。

(みょんみょんするのを気にしない場合はその限りではない)

SwiftのテストクラスでObjective-Cのプライベートメソッドをテストする

この記事は Sansan Advent Calendar 2015の20日目です。

こんにちは。

2015年が終わろうとしている現在もObjective-Cで消耗している者です。

ちなみに2016年も絶賛消耗する見込みです。

地獄の業火に焼かれながら、それでもSwiftに憧れる

本当はSwiftiOSアプリ開発したい!

でもプロダクトコードに入れるにはちょっと(///

という訳でまずはユニットテストだけSwiftで書くことになりました。

ユニットテストだけSwiftで書く場合

普通にSwiftでテストクラスを追加し、

テストしたいObjective-CのクラスをBridging-HeaderでimportすればOKです。

以下はHogeObjcClassというObjective-CのクラスのisValidメソッドをテストしたい場合の例です。

/*
     Bridging-Header
*/

#import "HogeObjcClass.h"
/*
     Swiftで書いたテストクラス
*/

import XCTest

class HogeObjcClassTests:XCTestCase {
    
    func testObjcMethod(){
        XCTAssertTrue(HogeObjcClass.isValid())
    }
}

プライベードメソッドをテストしたい場合

で、ちょっとめんどくさいのがテストしたいメソッドObjective-Cのクラスでプライベートな場合です。

そんな場合はHogeObjcClassのカテゴリを作成し、

/*
     プライベートメソッドテスト用のカテゴリ
*/
#import "HogeObjcClass.h"

@interface HogeObjcClass (PrivateTest)

+ (BOOL)privateMethod;

@end

さらにBridging-Headerで作ったカテゴリをimportします。

/*
     Bridging-Header
*/

#import "HogeObjcClass.h"
#import "HogeObjcClass+PrivateTest.h"

こうしてあげるとSwiftのテストクラスでObjective-Cのプライベートメソッドが使えるようになります。

/*
     Swiftで書いたテストクラス
*/

import XCTest

class HogeObjcClassTests:XCTestCase {
    
    func testObjcMethod(){
        // プライベートメソッドが使える
        XCTAssertTrue(HogeObjcClass.privateMethod())
    }
}

新しくプロジェクト作る場合はおとなしくSwiftで書きましょうということで、、、

Sansan株式会社に入社しました

2015年11月20日付でアシアル株式会社を退職し、11月24日にSansan株式会社に入社していました。

Sansan株式会社では「名刺管理Sansan」iOSアプリ開発を担当します。

Sansan株式会社に入社した理由

前提としてベンチャー企業に限定していました。 時代を動かそうとしている流れの中心に行きたいという思いがあって、 その中でも明確なビジョンとビジネス戦略を持ち、技術に対する考え方が共感できたことがSansan株式会社に入社した理由です。

技術に対する考え方

これまで仕事でいろいろなタイプのエンジニアと出会いました。 技術を表現の手段と捉えていたり、学術的な興味から技術をとことん探求する人など様々です。

自分にとっての技術とは「問題を解決する手段の一つ」です。

最も現実的な手段の選択としてのシステム/アプリケーションを開発する者でありたい、 そういった価値観を持つ人々と価値創造に取り組みたかったという感じです。

入社して嬉しかったこと

最新のMacBookProが用意されていた

入社前には希望するキーボード配列しか聞かれなかったのでちょっと不安だったのですが、 15インチMacBook Pro Retinaディスプレイモデルの搭載メモリを16GBにアップグレードしたバージョンが用意されていました。

メモリ8GBでXcode動かすとかかなり厳しいので、入社した時点で「この会社は分かってる!」と安堵しました。

ソースコード管理がGithub

開発するソースコードGithubのプライベートリポジトリで行われており、 コードレビューなどもPullRequestベースなので違和感なく開発サイクルに合流することができました。

エンジニア向けの福利厚生が充実している

技術書籍だけじゃなく個人のモバイル端末の購入補助があると知って驚きました。

確かにモバイルアプリの開発者は最新の端末を普段から使って新機能を知らないといけないので、 モバイルアプリ開発をやっている会社は同じような制度を設けてほしいですね。

毎週木曜日は技術顧問の方にいろんなことを教わることができるのも大きいです。

エンジニアのモチベーションが高い

当然初期に作られた部分の技術負債などはあるわけですが、 それに対するエンジニア陣の「絶対直してやる」という決意、エネルギーがすごいです。 エンジニアは周囲からすごく期待されるポジションなので、仕事に燃えたいタイプの方は非常に合うと思います。

今後

勉強会など通じてどんどん発信していきますのでよろしくです。