機能・画面は一貫性を保とう
ココらへんの話ってどのくらい認知されてるんでしょうか?
機能や画面というのは、どういうルートで入ってきても一貫性を持った結果が出せるととても良い状態です。
文脈依存性がないとも言えます。
文脈依存はなぜ良くないか
別に良くないというほどじゃないんですが、上図を見ると分かる通り、この機能は実質2機能です。
内部で何割かは共通化されているでしょうが、2機能です。
2機能だと、1機能に比べて色々大変です(ざっくりw)
文脈は、状態数を爆発させる
2機能、というと違和感があるかもしれません。
1機能2状態でもいいです。
そして文脈は状態数を爆発させます。
この時はこういう状態で、あのときはこういう状態、と増やしていくと、文脈と文脈は掛け算されていつの間にか数十状態ということもありえます。
そうするともはや仕様がおもすぎて何もできなくなります。バグも多いですしテストも多いです。コードもスパゲティになります(仕様がスパゲティなんです)
仕様を決める際には、慎重に状態数を減らさなければなりません。
補足
一貫性というのはあくまでルールです。出力が1つじゃないといけないというわけではありません。
また、クラス、関数、機能、画面内で無用な分岐を減らしていくことで、状態数爆発にすぐ気づくことができるようになります。
安易な共通化は本当に悪としか思えません。
一方で、文脈に応じて柔軟な出力を出せるとユーザーフレンドリーでもあります。ただ、仕様上の状態数をあまり増やさずに、多種多様な出力に見せることは可能です。そこに頭を捻る必要があります。ちょっとした追加機能で状態数を増やすのは避けるべきです。
IT業界の見積もりの特殊性、外れて当たり前な事情
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
これ読んでてふと思い出したんですが、IT業界(特にWeb系)特有の見積もり事情というのがあります。
未経験技術に挑むことが多い
プログラミングの特殊性ではなく、IT業界のスピード由来の特殊性です。
言及先ブログでは「製造ではなく設計なのだ」と言っていますが、設計ですらなく調査から始まるケースが多いと思います。
他社もやってるし、たぶん実現可能だからスタートしよう、さあ見積もって。
みたいな、よくよく考えたら狂ってるとしか思えない状況が結構発生するのです。
どこをどうすれば実現できるのか、どうやるのが正しいのかも、フワフワしたままゴーサインが出ます。
どうしてフワフワしながらスタートするのか
普通なら完全に調べてから始めるのが当たり前ですが、ITの常識が変わる速度や、新機能が出る速度が速すぎて、作ってるうちにどんどん刷新されていくわけです。
なのでマゴマゴしていたら、調べているうちにレガシーになってしまいます。ある程度あたりを付けて特攻するのは致し方ない気がします(※IT内でも信頼性が重要になってくる界隈では少しだけ話が変わりますが)
調査フェーズ、設計フェーズ、製造フェーズ
調査・分析フェーズというのは、「さあ作るぞ」というところより前の状態で、不確実性が高いです。(不確実性コーン - Google 検索 の左側)
IT特にWeb系ではこの調査フェーズを内在したままプロジェクトが走るので、それはもう不確実です。
コンサル業務や要件定義業務に近いでしょう。
コンサル業務は不確実性をどうコントロールしているか
受託会社で働いたことがある人は覚えがあるかもしれませんが、受託開発でも開発業務とコンサル・要件定義業務で契約を分けていることがあります。
不確実性が高い方は、一括請負ではなく時間払いのケースが多いのではないでしょうか。例えば1人張り付きで1ヶ月100万円など。成果物ではなく労働力の提供ですね。
これによって見積もりが外れてもお互いに損をしない仕組みができています。
そう考えると、IT特にWeb系で、不確実性が高い案件をやるときはやはり張り付き月幾らで契約した方が理に適っているのかもしれません。
って、そういえばソニックガーデンってそういう会社でしたね。
まあただの再確認でした。
個人サービス開発に必要なもの
一にアイディア、二に根性、三四が根性、五に根性
こんなスマートじゃないこと言いたくないんですが
金とチームというリソースがない(少ない)週末起業家はこんな感じになりそうです
どおりで成功者を見かけないわけだ
しんどい
でも一番はアイディアだと思います
なぜなら膨大な時間を掛けている内に何度も何度も迷うからです
アイディアに疑いを持ったらそこで詰みます(自分の気力が)
こんなことやっても意味ない!と絶対投げ出します
アイディアの良し悪しっていうより自分の納得感ですね
プロダクトって妙に高尚なものが多いイメージがありますが
それもそのはず、高尚じゃないとやってられないんですよね
そのアイディアを信じられる人がチームに1人居れば強いです、2人居ればかなり強いです
私も相方も本業がかなり忙しいので何度も停滞があったのですが、少し手が空いた時に前にすすめるかどうかはやっぱ自信があるかどうかなのかもしれません
まあそんな自信を持ってリリースしたものが全然流行らないという第二の関門が待ち受けているんですが
私はそれを体験済みなのでそこでは折れないと思っています
2年は鳴かず飛ばずの覚悟で挑みますw
(iOS)Wikipediaアプリのソースコード
MITライセンスなんですねこれ
GitHub - wikimedia/wikipedia-ios: The official Wikipedia iOS app.
WikipediaをWebViewで表示しようとして参考にしようと落としたんですが割りと難解でしたw かろうじて読める程度
シンプルなように見えて結構エグいですね
でも一般的に出回ってるアプリで中を見れるのは貴重かも
設計周りで参考になるかもしれません。
(日記)疲労
疲労がヤバイです
PCしてる体を支えられない
休憩しながらコーディングできないてますかね?
頭も働かないんですが
受託新規開発と、内製継続開発の体制の差
観測数が少ないんですが、私の見た限りこういうのが多かった。というものと、その課題について。少し考えたこと。
受託・新規開発
だいたいこんなだと思います。
受託・新規開発で社会人デビューしたので、こちらが一般的だと信じ込んでいました。
PM、あるいはPMとディレクターがPO(プロダクトオーナー、つまりお客さん)との間に入って調整してくれます。
内製・継続開発
内製・継続開発的な会社に入った時、下図のような感じで割りと面食らいました。
案件はチケット単位で走ります。1チケットは軽いものだと1日で、重いものだと2ヶ月くらいです。
重くても新規開発の1プロジェクトの大きさには満たないので、エンジニアが割りと全面に出ることを求められます。
結果的に「エンジニア=ディレクター+PG」的な動きとなります。
PO側も非常に奇妙に感じました。お客さんに相当する人は部門であることが多いです。例えばQA、企画、広報、法務部など。いろんなところからいろんな要望が出て、それに対応するのがメイン業務となります(6割位?)
もちろんサービス自体の改善もあります。それが残りの業務です。
この体制の問題点
図を見ればわかると思いますが、情報の導線がカオスです。
これがどういう問題の顕在化に繋がるかというと。
- 全体を把握しづらい、戦略的に動きづらい
- 一貫した方針でプロダクトを作りづらくなる
- 質の担保がエンジニアの感覚値になる
- 無限に仕事が発生する
- 無限に複雑度が上がる
- エンジニア負担が大きい
- ディレクションまでできるエンジニアが必要
- 誰の認識している仕様が正しいのか迷子に成りがち
もっとある気がしますが、こんな感じでしょうか。
「よくわからない」状態になります。
もっと良い体制はないものか?
プログラムの設計に似ています。
誰に何を担わせるのか、どことどこを分けるのか。
まだ考え中ですが、こんな体制だとどうでしょう。
結局一般的なスクラム体制なんですが。やはりPMとSMをどう設計するか次第で良し悪しが決まりそうです。
正直物量を考えると、この中間層が2人でいいか自体疑問です。
3、4人はほしくないですか?
数値を計測する人、情報の流れを管理する人も欲しいです。
またそのうち書きます。
サービスアイディア思いついちゃった時どうすればいいか
まるで時間もないし金もないんですが
思いついてしまった時は苦しいですね
しかも実現可能性が高かったりすると
まあ大抵どこかでコケるんでしょうけど(その時点でサービスが存在していない時点で何かしら見えていない罠があるはず)